View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002243||2 - Next Dev List (Holding Area)||Bug||public||2017-09-10 09:23||2018-03-20 08:55|
|Summary||0002243: FT-857D Not showing and tracking Mode|
|Description||Using HRD after V 6.3.0613 Mode is no longer visible in rig control, not it will track in Logbook|
There was issues with the YAESU CAT protocol I am aware, however Mode was not one of the removed items
See screenshot, Mode is showing above the frequency.
With our latest version it is gone.
|Steps To Reproduce||N/A|
|Tags||No tags attached.|
Capture.PNG (22,615 bytes)
Capture.PNG (22,615 bytes)
||Same for a customer with a FT-897d|
||Also this with SDR https://support.ham-radio-deluxe.com/scp/tickets.php?id=11725|
I found out that in build 787 LSB and USB are removed from the default modes.
Please add them back in the defaults.
(by adding them manually, the problem is solved)
Also on FT-1000MP MKV
I need more information to take action on this bug. Please let me know:
1) How to reproduce the problem. Step-by-step instructions are necessary; please be as clear as possible.
2) What you end up seeing. How does it currently work, and why is that wrong?
3) What you expect to see. How should it work, and what needs to change?
Mike, I just added two images from my IC-7100 display showing the problem. The Rig Control is set to USB. In the Logbook ALE, with it set to track the modes, it's showing CW. It should be showing USB just like the Rig Control Screen when the "Tracking" is checked as shown in the ALE image.
Hope this helps you understand what we're seeing with several different radio models, including my Icom IC-7100
Showing CW in ALE.jpg (186,373 bytes)
Showing CW in ALE.jpg (186,373 bytes)USB IN RIG CONTROL.jpg (295,381 bytes)
Here's what I'm doing:
1) Start Rig Control
2) Get it connected to my radio. My radio happened to be in USB mode.
3) Start Logbook
4) Open my favorite database
5) Press the "Add" button in the toolbar to bring up the QSO editor
6) There, mark the "Track" checkbox next to the mode.
At this point, for me, I'm seeing that the "Mode" is set to "USB", like my radio.
7) Chaneg the radio's mode by clicking on the [USB] box above the frequency on Rig Control. Set it to "CW"
Here, I observe that the QSO editor window changes to "CW".
8) C hange the radio's mode by using the radio's controls. I switched to "PSK".
When I do so, I notice that the QSO editor window changes to "PSK31".
I'm using my IC-7610, and as far as I can tell, the code is working as intended so far.
Am I supposed to be doing different steps? Do you think the issue is unique to the radios previously listed in this bug?
In chat, I've confirmed with Tim that these steps reproduce the bug. I'm still a bit confused because this issue says that the "Mode is no longer visible in rig control", and the ticket shows screen shots with the [USB] mode box in rig control missing. That's a different issue than I reproduce in my steps, which focus on the QSO Editor Window in the Logbook not updating when the tracking box is marked.
When the mode box is not visible in Rig Control, it means that Rig Control couldn't recognize the mode response from the radio. That problem is local to Rig Control and means that the radio isn't correctly implemented in Rig Control.
When the Logbook application communicates with Rig Control to sync the QSO Editor Window controls, things are a bit more complicated. In that case, the Logbook application has connected to the Rig Control application with a socket. Occasionally, the applications communicate over the socket to exchange information about the state of the radio. When the Logbook application receives an update, the windows in the application send custom messages to each other to manage the updates of the UI.
The mechanism that seems to be failing is the socket communication layer. If a response isn't received to a socket message in 5 seconds, the thread handling the communication on the rig control side gets sick; it doesn't recover the framing of the protocol, and instead sits in a tight loop polling the socket for new connections that never come. The Logbook could close and reset the socket, but it doesn't. The applications stop exchanging updates, and nothing happens. I'm not sure how the applications get in this state in the wild, but it's conceivable that slow machines delay more than 5 seconds between reads; or that some other bug initiates the issue.
My investigation is directed and not exhaustive, so it's possible that there's also another cause.
But it seems that the resiliency of this protocol is a problem for reliability in communication between any of the applications.
|2017-09-10 09:23||PD9FER||New Issue|
|2017-09-10 09:23||PD9FER||File Added: Capture.PNG|
|2017-09-10 10:10||PD9FER||Note Added: 0004157|
|2017-09-16 12:42||PD9FER||Note Added: 0004196|
|2017-09-18 08:58||K7ZCZ||Relationship added||related to 0002248|
|2017-10-03 13:23||PD9FER||Note Added: 0004271|
|2018-03-16 12:59||PD9FER||Note Added: 0004495|
|2018-03-17 13:10||K7ZCZ||Project||1 - Backlog => 2 - Next Dev List (Holding Area)|
|2018-03-17 13:12||K7ZCZ||Assigned To||=> PD9FER|
|2018-03-17 13:12||K7ZCZ||Status||new => feedback|
|2018-03-17 13:12||K7ZCZ||Note Added: 0004504|
|2018-03-19 11:17||KB3NPH||File Added: USB IN RIG CONTROL.jpg|
|2018-03-19 11:17||KB3NPH||File Added: Showing CW in ALE.jpg|
|2018-03-19 11:17||KB3NPH||Note Added: 0004512|
|2018-03-19 13:58||K7ZCZ||Note Added: 0004513|
|2018-03-20 08:55||K7ZCZ||Note Added: 0004514|