I installed the new release of RadioMail version 1.6 this morning. I sent a message using a VHF packet connection via my Mobilnkd TNC4 & Yaesu FTM-400D using the same settings that worked prior to updating RadioMail.
The message sent successfully; however, I noticed that the radio was stuck in TX after the RadioMail session had ended. I repeated the same connection to confirm the issue and had the same problem with subsequent connections. I also noticed that I could hear the Winlink gateway sending repeated disconnect attempts, suggesting that it did not receive the final disconnect packet from RadioMail.
I did also use the Mobilinkd config app to confirm that the PTT was functioning normally and it did seem to work just fine.
Curious if anyone else has experienced the same issue or can reproduce it?
A stuck PTT is usually caused by RFI coming back into the Mobilinkd. RadioMail does not control PTT directly when using a TNC, the TNC does. Try positioning the Mobilinkd away from the antenna or place some ferrite on the audio cable.
Thanks for your reply, Georges. I thought the same about this being a Mobilinkd/radio/RFI issue, but it seemed too coincidental that the PTT hang up was occurring every time on the final packet when I would expect RadioMail to be sending a disconnect.
Tonight I dug into it a bit further using both RadioMail 1.6.0 on my iPhone and RadioMail 1.5.3 on my iPad to make a packet connection using the same hardware with both (Mobilinkd TNC4 & Yaesu FTM-400D). I had no issues with 1.5.3 on my iPad and no PTT hang on the final packet. With 1.6.0 I can reproduce this with every connection.
I am attaching 2 screenshots of a Direwolf instance that was monitoring the connection from both devices. With RadioMail 1.6.0, the “DISC cmd” packet doesn’t appear to be sent - the last packet from RadioMail is the “FF” message. Interestingly, RadioMail advances to the screen you would expect to see when the connection is complete (with the Done button). Presumably the PTT hangs when the “DISC cmd” packet would be sent. The gateway times out sending “DISC cmd” messages at this point.
Is there any additional information I can provide to help troubleshoot? Maybe this is an issue unique to my hardware configuration?
I tried a packet connection with RadioMail 1.6.0 and a different hardware setup - Direwolf/DIY cm108 USB soundcard/Kenwood TM-V71A. This connection worked fine, no PTT hang and the “DISC cmd” is sent (screenshot attached).
It seems like the combination of RadioMail 1.6.0 and the Mobilinkd TNC is where the issue is occurring.
Just tried again with another configuration - Mobilinkd TNC4/Yaesu VX-5 HT. I had the same result as with the FTM-400D, the connection with RadioMail 1.6.0 ends with the PTT stuck on. Using RadioMail 1.5.3, the connection completes and ends as expected.
I did notice this time that the Bluetooth connection to the Mobilinkd appears to terminate just as the radio goes into transmit, but I am not setup to monitor the Bluetooth traffic to verify the timing of this.
Thanks for the troubleshooting and confirming the behavior. I’m able to reproduce the problem.
The Mobilinkd seems stuck in a that state, even though RadioMail has disconnected from bluetooth. You can quit the app or unplug the audio cable and it still in PTT until you power cycle the Mobilinkd. Weird.
Test build 1.6.1 which fix a premature BLE connection teardown that could cause Mobilinkd PTT to lock up has been published on TestFlight: Join the RadioMail beta - TestFlight - Apple
Thank you for the quick responses! My Mobilinkd TNC is still on firmware version 2.5.9, the update process isn’t very elegant.
I will wait for the 1.6.1 TestFlight build to become available and try that first before updating my Mobilinkd to 2.5.14 and that way I can test both potential solutions. I’ll report back here with the results.
Thanks for letting me know, I just installed RadioMail 1.6.1 with TestFlight and made a packet connection with my Mobilinkd. The session ended “normally” with a disconnect and no stuck PTT. This update has resolved the issue - thank you!
I will also try updating the Mobilinkd to the latest firmware and report back on its performance with RadioMail 1.6.0 and 1.6.1.
I upgraded my Mobilinkd firmware to 2.5.14 and confirmed the RadioMail 1.6.1 packet connection is working as expected with this combination.
I then reverted to RadioMail 1.6.0 to test the behaviour with Mobilinkd firmware 2.5.14. On my first packet session there was no noticeable PTT hang at disconnect, but the “DISC cmd” packet was not sent from the client side and the gateway continued to send DISC packets waiting for the response. On a subsequent packet session, I noticed that there was short PTT hang on disconnect but that the TNC did revert to dropping the PTT after a second or two. The “DISC cmd” was again not sent from the client (RadioMail) and the gateway continued to transmit, still looking for a response.
All this to say that your fix implemented in RadioMail 1.6.1 seems to be the solution!
Awesome. Thank you so much for the thorough regression test. 1.6 tightened the exchange session up removing some wait loop which surfaced that problem. Most other BLE TNC are radios that support restoring frequency at the end of the session, so the code path is a bit different than mobilinkd.
