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

People are moving, changing locations for many reasons. Therefore I think a year is a long period of time for a client-side call/locator cache.

The QRZ cache can be for a VERY long time...maybe a year or more. The probability that what was a good callsign (silent key or changed) shows up in a bad decode is almost nil. Mike W9DMB

On Wed, Nov 3, 2021 at 02:03 PM, Michael Black wrote: It could be filtered with a QRZ lookup. I have a filter for the JTAlert email interface that does a QRZ lookup to avoid bad decodes like this and

Every Operator is responsible for his own Data