1. Wsprdaemon
  2. Topics

3 letter call sign for special event

jks
 

Bruce KX4AZ
 

Thanks Rob, that's what I had begun to surmise, just wanted to re-confirm before I push any further with the WSJT-x groups.io.  I posted the problem there the other day before I fully understood the nuances of what was happening and how the Type 1/2/3 messages are encoded/decoded. Armed with this knowledge and your confirmation that wsprd is what needs "fixing", I'll start a new thread there.
73,
Bruce KX4AZ
Rob Robinett
 

WD executes the binary 'wsprd' taken from the WSJT-x distribution.  So if WSJT-x reports 'N1D' Wd should also report it.
So I would encourage you to post your problem to the WSJT-x developers forum and report back to us when it is fixed there.

On Sat, Apr 23, 2022 at 8:34 AM Bruce KX4AZ <bruce@...> wrote:
Just a follow up, running the 'N1D/4' special event WSPR beacon with the (compound) call sign is working well for spots from the array of decoders out there.  I am curious whether the future 3.0 wsprdaemon version will have the ability to decode/upload 1x1 call signs (i.e. Type 1 messages) like N1D.  Or does that ability await a "fix" from the folks who work on WSJT-x?



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896
Bruce KX4AZ
 

Just a follow up, running the 'N1D/4' special event WSPR beacon with the (compound) call sign is working well for spots from the array of decoders out there.  I am curious whether the future 3.0 wsprdaemon version will have the ability to decode/upload 1x1 call signs (i.e. Type 1 messages) like N1D.  Or does that ability await a "fix" from the folks who work on WSJT-x?
Jim Lill
 

ignore my last.... too early here and didn't read all the received messages thoroughly!

On 4/20/22 20:47, Bruce KX4AZ wrote:

This afternoon I switched to using 'N1D/4' for the call sign, which is working OK., the '4' symbolizing the US call region 4.   Wasn't my first choice since it requires 2 cycles for a complete "spot", but it does the job, enabling spots by the full array of decoders out there.  And indeed I have verified the same decode problem with the 1x1 N1D call sign happens in the WSJT-x software, even though transmitting with just 'N1D' seems to be permitted, given that the Kiwi 1.3 decoder spots it.  So this is not a wsprdaemon issue per se, just the core decoder. 

Jim Lill
 

Can you receive yourself on a 2nd radio with wsjt-x and see if it decodes your ZackTech correctly?

On 4/20/22 20:47, Bruce KX4AZ wrote:

This afternoon I switched to using 'N1D/4' for the call sign, which is working OK., the '4' symbolizing the US call region 4.   Wasn't my first choice since it requires 2 cycles for a complete "spot", but it does the job, enabling spots by the full array of decoders out there.  And indeed I have verified the same decode problem with the 1x1 N1D call sign happens in the WSJT-x software, even though transmitting with just 'N1D' seems to be permitted, given that the Kiwi 1.3 decoder spots it.  So this is not a wsprdaemon issue per se, just the core decoder. 

Bruce KX4AZ
 

This afternoon I switched to using 'N1D/4' for the call sign, which is working OK., the '4' symbolizing the US call region 4.   Wasn't my first choice since it requires 2 cycles for a complete "spot", but it does the job, enabling spots by the full array of decoders out there.  And indeed I have verified the same decode problem with the 1x1 N1D call sign happens in the WSJT-x software, even though transmitting with just 'N1D' seems to be permitted, given that the Kiwi 1.3 decoder spots it.  So this is not a wsprdaemon issue per se, just the core decoder. 
Rob Robinett
 

Wsprdaemon takes the spots added to ALL_WSPR.TXT by running the WSPR binary taken from the WDJT-x distribution.  WD then removes only spots with the tx call sign “<…>” from that list and uploads the spot list to wsprnet.org.  WD checks the upload response from wsprnet to compare the number of spots accepted by wsprnet against the number of spots offered by WD.  If they differ, WD records an ERROR line to its log file.  As long as the curl  upload is successful, WD flushes its cache of all the spots it offered no matter how many spots were accepted, since the rejected spots will never be accepted.  
In practice I almost never see rejected spots when using this upload mechanism 

On Wed, Apr 20, 2022 at 1:04 PM John Loftus <vk4emm@...> wrote:
Hi Bruce,

One work around may be to use N1D/1

Recently, I added a filter to only upload reports with more than 42 characters. I did so while chasing a bug in my own software.
The filter solved my problem at that time. Since then I tracked down the root cause and re-wrote the software module from scratch.
Just as a safety precaution I have kept the filter in place. The problem in my software allowed uploading of corrupt spot data.
I mention this because others my have had a similar problem which can be treated with the same filter.

Regards,
John VK4CT / VK4EMM

--
Rob Robinett
AI6VN
mobile: +1 650 218 8896
John Loftus
 

Hi Bruce,

One work around may be to use N1D/1

Recently, I added a filter to only upload reports with more than 42 characters. I did so while chasing a bug in my own software.
The filter solved my problem at that time. Since then I tracked down the root cause and re-wrote the software module from scratch.
Just as a safety precaution I have kept the filter in place. The problem in my software allowed uploading of corrupt spot data.
I mention this because others my have had a similar problem which can be treated with the same filter.

Regards,
John VK4CT / VK4EMM
Jim Lill
 

this data from wspr rocks shows that decoders other than just kiwi are doing the job.  N1D is also in the data I download from the database at wsprdaemon.org for http://www.jimlill.com:8088  .  Rob would have to comment on situation wsprdaemon client decoding and posting

2022-04-19 11:20 N1D EM83hw N9AWU EM69sm 7.040095 0.2 -21 0 679 337 2 3395 1415 1.3 Kiwi
2022-04-19 11:20 N1D EM83hw N4TTN FM05pm 7.040029 0.2 -20 0 461 66 2 2305 1024 1.3 Kiwi
2022-04-19 11:12 N1D EM83hw KE8BPV EN82ch 10.140214 0.5 -22 0 932 358 2 1864 725 0.2r_wsprd
2022-04-19 11:12 N1D EM83hw N4TTN FM05pm 7.040145 0.2 -18 0 461 66 2 2305 1153 1.3 Kiwi
2022-04-19 11:12 N1D EM83hw N2AJX FN13eb 10.140181 0.5 -26 0 1131 24 2 2262 628 2.0_r1714
2022-04-19 11:12 N1D EM83hw KX4AZ/T EN74gc 10.140183 0.5 -19 0 1145 352 2 2290 1081 1.3 Kiwi
2022-04-19 11:12 N1D EM83hw KD9QZO EN52xi 10.140145 0.5 -23 0 1021 338 2 2042 737 1.3 Kiwi
2022-04-19 11:12 N1D EM83hw W1VK FM17 10.140144 0.5 -3 0 694 54 2 1388 1272 1.3 Kiwi
2022-04-19 11:12 N1D EM83hw N9AWU EM69sm 10.140297 0.5 0 0 679 337 2 1358 1358 1.3 Kiwi
2022-04-19 11:12 N1D EM83hw W4KEL FM08qh 10.140199 0.5 -8 0 647 40 2 1294 1006 1.3 Kiwi
2022-04-19 11:12 N1D EM83hw KD2CLR FN13gb 10.140199 0.5 -19 0 1137 25 2 2274 1074 1.3 Kiwi
2022-04-19 11:12 N1D EM83hw W3LLA DN70ln 10.140193 0.5 -20 0 2048 297 2 4096 1820 1.3 Kiwi
2022-04-19 11:10 N1D EM83hw N4TTN FM05pm 7.040039 0.2 -18 0 461 66 2 2305 1153 1.3 Kiwi
2022-04-19 11:10 N1D EM83hw KE8BPV EN82ch 10.140215 0.5 -23 0 932 358 2 1864 673 0.2r_wsprd
2022-04-19 11:10 N1D EM83hw KD9QZO EN52xi 10.140145 0.5 -26 -1 1021 338 2 2042 567 1.3 Kiwi
2022-04-19 11:10 N1D EM83hw KE5HPY EL29 10.140212 0.5 -23 -1 1209 249 2 2418 873 2.0_r1714
2022-04-19 11:10 N1D EM83hw W1VK FM17 10.140144 0.5 -6 -1 694 54 2 1388 1157 1.3 Kiwi
2022-04-19 11:10 N1D EM83hw N9AWU EM69sm 10.140298 0.5 -3 -1 679 337 2 1358 1245 1.3 Kiwi
2022-04-19 11:10 N1D EM83hw KD2CLR FN13gb 10.1402 0.5


On 4/19/22 11:45, Jim Lill wrote:

your spots from today are not in the daily wsprnet database that shows decoder type yet.

On 4/19/22 11:39, Jim Lill wrote:

the kiwi extension uses the wsprd decoder albeit an earlier version IIRC.  wsprdaemon uses wsprd also. Let me look at some raw data.

On 4/19/22 11:04, Bruce KX4AZ wrote:
On Tue, Apr 19, 2022 at 10:53 AM, Jim Lill wrote:

A quick look at all the active TX stations shows no other 3-char TX stations.  I wonder if you'd be legal using N_1_D and if that would fix the problem?

Yes, my suspicion is that a 3 character call sign is not permitted by the protocol decoder, and the Kiwi 1.3 decoder just happens to allow it.  I don't believe other characters such as underscore are allowed either.  Worst case I'll just have to add a special prefix/suffix....not my first choice but may be the only option.

Jim Lill
 

your spots from today are not in the daily wsprnet database that shows decoder type yet.

On 4/19/22 11:39, Jim Lill wrote:

the kiwi extension uses the wsprd decoder albeit an earlier version IIRC.  wsprdaemon uses wsprd also. Let me look at some raw data.

On 4/19/22 11:04, Bruce KX4AZ wrote:
On Tue, Apr 19, 2022 at 10:53 AM, Jim Lill wrote:

A quick look at all the active TX stations shows no other 3-char TX stations.  I wonder if you'd be legal using N_1_D and if that would fix the problem?

Yes, my suspicion is that a 3 character call sign is not permitted by the protocol decoder, and the Kiwi 1.3 decoder just happens to allow it.  I don't believe other characters such as underscore are allowed either.  Worst case I'll just have to add a special prefix/suffix....not my first choice but may be the only option.

Jim Lill
 

the kiwi extension uses the wsprd decoder albeit an earlier version IIRC.  wsprdaemon uses wsprd also. Let me look at some raw data.

On 4/19/22 11:04, Bruce KX4AZ wrote:

On Tue, Apr 19, 2022 at 10:53 AM, Jim Lill wrote:

A quick look at all the active TX stations shows no other 3-char TX stations.  I wonder if you'd be legal using N_1_D and if that would fix the problem?

Yes, my suspicion is that a 3 character call sign is not permitted by the protocol decoder, and the Kiwi 1.3 decoder just happens to allow it.  I don't believe other characters such as underscore are allowed either.  Worst case I'll just have to add a special prefix/suffix....not my first choice but may be the only option.

Bruce KX4AZ
 

On Tue, Apr 19, 2022 at 10:53 AM, Jim Lill wrote:

A quick look at all the active TX stations shows no other 3-char TX stations.  I wonder if you'd be legal using N_1_D and if that would fix the problem?

Yes, my suspicion is that a 3 character call sign is not permitted by the protocol decoder, and the Kiwi 1.3 decoder just happens to allow it.  I don't believe other characters such as underscore are allowed either.  Worst case I'll just have to add a special prefix/suffix....not my first choice but may be the only option.
Jim Lill
 

A quick look at all the active TX stations shows no other 3-char TX stations.  I wonder if you'd be legal using N_1_D and if that would fix the problem?

On 4/19/22 09:30, Bruce KX4AZ wrote:

I am (attempting) to run a special event WSPR beacon with "N1D" for the call sign.  So far the only spots I see are for Kiwi 1.3 decoders...so I suspect that using a 3 letter call sign is not permitted by the WSPR protocol.  The transmitter configuration software (Zachtek) also balked at the call sign until I appended a space character to it.  Open to any/all suggestions for a workaround that would enable spotting by all the wsprdaemon stations out there.

Bruce KX4AZ
 

I am (attempting) to run a special event WSPR beacon with "N1D" for the call sign.  So far the only spots I see are for Kiwi 1.3 decoders...so I suspect that using a 3 letter call sign is not permitted by the WSPR protocol.  The transmitter configuration software (Zachtek) also balked at the call sign until I appended a space character to it.  Open to any/all suggestions for a workaround that would enable spotting by all the wsprdaemon stations out there.

1 - 15 of 15