Re: Bug in 2.5.4 when changing bands on Yaesu FTDX-3000 #Yaesu


Eugene Morgan
 

These are all software design choices and I'm not in a position to judge. Without seeing a list of requirements I won't judge. Maybe it is a poor design choice but as I said without knowing the requirements it's hard for me to say one way or the other.

What I do know for a fact is that often what may be blamed as a software issue may be environmental. At least that's been my experience.

Gene

-----Original Message-----
From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of ky4ct@...
Sent: Friday, August 5, 2022 10:57 AM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Bug in 2.5.4 when changing bands on Yaesu FTDX-3000

Eugene,

How can it be a programming challenge when there are libraries like boost::asio and Qt's QSerialPort and plenty of open-sourced and well-tested options to work with serial ports? As a software engineer, I find it sort of a dogmatic mindset that we're polling rigs that don't need to be polled in 2022 and that libraries have provided asynchronous access to serial ports for years, and more to the point that it worked fine a few revisions ago but now absolutely refuses to work on my rig that also utilizes other hardware that relies on the rs232 communications of my radio in a manner that isn't polling my rig. Why should wsjt-x care that my radio informs another device what its meter reading is? It should only care about what my radio says its frequency is, i.e., the IF command it requested. The Cat protocol on 2.5.4 and above is naive at best.

https://www.boost.org/doc/libs/1_71_0/doc/html/boost_asio/reference/serial_port.html

https://doc.qt.io/qt-6/qserialport.html

Join main@WSJTX.groups.io to automatically receive all group messages.