On Wed, Nov 3, 2021 at 03:53 PM, Reino Talarmo wrote: If GM1BAN sends 4 character locator, how the receiving entity can provide 6 character locator to the spot

Reading this thread piqued my intrigue, so went and had a look at the manual for my FT817ND. The CAT command for getting frequency is there, but has the feeling of having been added as an

It might be worth asking the WSJT-X developers to add the option of setting frequency limits for each band. That way there would be no risk of transmitting out of band

Hi Roland, If GM1BAN sends 4 character locator, how the receiving entity can provide 6 character locator to the spot collector? By the way could the spot collector check the validity of the call -

Thanks Bill 73 Dave G3UEG

Absolutely no luck I'm afraid. Installed flrig for Mac (v "bs"). Chose G90 as rig, 19200, /dev/tty.usbserial110 seems to be the port. Every time Ihit "init" the program crashes.. Will keep fiddling

Many are already registered members on qrz.com (free or paid sub). In order to use the XML API you need to have an XML subscription (USD29.95/year). I use the service for several other HAM-related

Mike, your point #2 is not quite correct, it doesn't care what the mode other than it must be one that is expected, i.e. within the set of valid modes. This was a

Mike, other than the hash code table, the WSPR decoder is stateless and very rarely provides decodes with correct calls but corrupt grids. This can indeed happen with Type

The FT847 does not have a get_vfo function. The FT817 does now have a get_vfo function which apparently is not supported by that rig. So looks like you need to use the FT847. Mike W9MDB

Do I not understand Mode=None in WJST-X then? I thought it meant two things. #1 WSJT-X makes no attempt to set mode #2 WSJT-X makes no read of mode (or shouldn't care). Is one of those assumptions

Mike, QRZ.COM callsign data lookups are not a free service, we have no intention of requiring that WSJT-X WSPR spotters use such a service. Caching such lookup data seems unwise

There are two points...one is bad decodes...the other is inaccurate grid reports which perhaps come from some internal error like not clearing the grid when a new call is decoded so an old grid gets

Mike, please review the thread so far, you may have missed the point. 73 Bill G4WJS. On 03/11/2021 13:43, Michael Black via groups.io

Mike, that's not correct. If an application emulates another application then it should do so accurately, if it doesn't then a client can't be expected to behave exactly as it

My post is about invalid locators/callsign pairs. GM1BAN is a correct callsign.

I have been going crazy. I jerked around with my setup for the CQWW SSB contest over the weekend and since then things have been weird. I cannot fathom how anything I did could cause the problem I

On Wed, Nov 3, 2021 at 02:01 PM, Bill Somerville wrote: Many of the large volume WSPR spotting sources are not using WSJT-X so I guess they are forming spots from their own decoders, or more likely

If you set mode to None you can do whatever you want on the rig. Mike W9MDB On Wednesday, November 3, 2021,

We're trying to avoid bad decodes with bogus callsigns...not grids which could be a rover or somebody temporarily operating who frequently does not update their QRZ location. The examples given were