Bill,
Ø are you sure you have waited long enough… Absolutely sure. I’ve been sitting on this for around 2 weeks now and have tested almost every combo possible. It has been back tested with 2.2.1 and also with the “model” Hamlib sources from 2.2.1 and 2.2.2… but based around the “master” repo as there has been a lot of work going on with the FT-8x7 series of radios… The fact that this also occurs with the IC-725 (but that messages are displayed for this) means that a referral to you is necessary (and excuse the doctor-pun ;-)). Mike W9MDB has been into the machines a number of times; Hamlib needed to be eliminated as far as is possible as a cause before referring forward to WSJTX code. 73 Steve I From: Bill Somerville <g4...@classdesign.com> Sent: Monday, 13 July 2020 7:17 PM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] Issue: v2.2.2 (and earlier) Invalid Hardware frequency ranges trying to be addressed and the handling of such anomalies #bug On 13/07/2020 10:01, Stephen VK3SIR wrote: Hi Everyone, I have noted that when you select a frequency to operate on that hardware is not capable of then a Hamlib disconnect (i.e. The Settings/Radio configuration widgets) is thrown without any console error messages being recorded. i.e. I run a FT-897D and an old IC-725 here… With either rig select 70Mhz first time … and it groans and returns to the previous state (as expected). Then select 70MHz again and a Hamlib disconnect without console warning traps being thrown on the console with both the FT-897D and the IC-725. Note that no console messages are displayed with the FT-897D; there are some messages displayed with the IC-725. Up-to-the-minute Hamlib snaps have had to be used (from the master repo) due to their being a lot of work going on in Hamlib with the FT8x7 range of Yaesu radios. I have worked this through heavily with Mike W9MDB on both Windows x64 and Linux Ubuntu 20.04 and I am very sure – backed up by responses to different radio technologies - that the issue is not with Hamlib. [ There is an appearance that the last state (i.e frequency, mode etc.) that the radio was on in WSJTX is saved rather than the last valid state. ] Its minor; few will observe this. Concern is that "Doctor...it's hurts when I do this....Doctor: then don't do that" could be responded back. That is not the point; as I have stated repeatedly many use this project as a template for programming and standards – even in the commercial world. Therefore it is our obligation to report as this small issue could cause huge issues later down the track. Thanks especially to Mike W9MDB and everyone else that has been helping and testing with my observations here. 73 Steve I VK3VM / VK3SIR Hi Steve, are you sure you have waited long enough for an error to be shown? There are several retries made before an error message is displayed, this can take tens of seconds with with some rig models. 73 Bill G4WJS.
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
