TNC Serial Connection Disconnects after Receiving Data

[Former user]

I tried using QTH with a serial connection to an MFJ-1274 (TNC 2 clone) running in the KISS mode. I consistently observed that every time a packet was received the serial connection would change to inactive. The packet was successfully decoded and properly displayed on the map, but a manual reconnection was required to again decode the next packet. This cycle would repeat.

I also tried this with an MFJ-1270 and a PacComm Tiny-2 TNC running in the KISS mode and observed the same failure mode.

This make QTH unusable in the current configuration with these devices.

Has this been reported before? Is there a known workaround?

[Weston Bustraan]

I believe this is the first time someone has run into this issue.

Let’s start by checking the log. It can be found at ~/Library/Logs/com.w8wjb.QTH/qth.log Can you send that to me, either by attaching it to this issue or emailing it to me at [e-mail]?

Looking in the code, the only place where the connection will stop itself is when it is no longer able to read from the serial port.

One way to test the serial port is to run a command like:

cat /dev/cu.YOURDEVICE > /path/to/capturefile.dat

This should start reading from the serial port to a capture file. Normally, with a serial port, it should read forever and you should have to stop it by sending Ctrl-C to kill the process. However, if it does not read forever and stops on its own, then that would indicate something is wrong with the serial port.

[Greg Noneman]

  <div class="preview-container wiki-content"><!-- loaded via ajax --></div>
  <div class="mask"></div>
</div>

</div> </form>

[Greg Noneman]

I don’t know if I did it right, but I think I attached a snippet of the log file. In between each one of the packets, I had to perform a manual reconnection to the serial port.

[Weston Bustraan]

Is this the device you are using? Or is it a different model? https://mfjenterprises.com/products/mfj-1270x?_pos=1&_sid=8f7e7d83e&_ss=r#description

Also, just to check, have you used it with any other APRS programs on the Mac? YAAC, etc?

[Greg Noneman]

No. What I’m using is an old TNC-2 clone. What I currently have hooked-up is an MFJ-1270B. As I had previously mentioned, I also tried an MFJ-1274 and a PacComm Tiny-2. These are old (ancient) devices but the do support KISS and have used them with other applications.

[Mark Cohen]

I’m having this same problem, I’m using a NinoTNC as well as a Kantronics TNC.. (Also happens with a TH-D74)…

‌

[Mark Cohen]

Not sure anyone is really looking at any of these bugs as the app hasn’t been updated in seemingly ages.. :(

Any wired connection seems to cause the Connections in QTH to close the / disable the connection to the Serial TNC.. The only lines seen in the DEBUG log are:

‌

18:51:38.300 DEBUG APRSManagerImpl.transmit():147 - Posting packet for transmit
18:51:38.304 DEBUG APRSConnection.didTransmit():177 - Transmitted 2 packets
18:52:35.152 DEBUG APRSManagerImpl.transmit():147 - Posting packet for transmit
18:52:35.156 DEBUG APRSConnection.didTransmit():177 - Transmitted 4 packets

[Weston Bustraan]

I am looking at the bugs, I just have limited time right now and I have not been able to reproduce this on hardware that I own.

The logs won’t really tell the whole story because QTH simply sets up an infinite read from the serial port pseudo-file. If the serial port closes for whatever reason, the OS will return a status code that indicates that no more bytes can be read. As I mentioned at the beginning, this is what will cause the connection to go inactive.

What I would like to do is take QTH out of the equation and see if the standard UNIX tools also have the same unexpected read quit, but no one who is experiencing the problem has taken these steps yet, so I don’t have any more information to go on.

[Weston Bustraan]

Updating the group. Mark sent additional details about his testing with alternate apps like YAAC or Xastir. It appears that some serial devices (Mobilinkd) work while others do not. As those other apps don’t suffer from the same issue, it confirms that there is something different about the way QTH is accessing the ports that is causing issues.

Investigating further to determine what could be different.

[Weston Bustraan]

Mark mentioned in an email that he had a NinoTNC and it was exhibiting this issue. I ordered a NinoTNC SMT and it arrived today. I did do a quick test with no radio connected. When sending a beacon, the LEDs light up on the NinoTN. It does stay connected. I’ll do a more realistic test once I’ve got a real radio connected, but I am going to have to build a cable first.

[Mark Cohen]

Hi! Funny you should test today. I decided to give it another try. I connected two NinoTNCs up (both SMT) one is Jason’s early prototype and the other is from the recent round. Both behaved perfectly this time. No issues with QTH removing the device. Then, I connected an HT (TH-F6A) that is sitting right next to the TNCs and it looks like transmitting this close is what is causing the device to be removed. In fact, both TNCs took themselves offline. So, apparently RFI getting into the USB bus causes it to reset. (I noticed that my LED lit keyboard reset itself as well. :) )

[Weston Bustraan]

I'm going to close this issue, since I think we've come to a reasonable explanation. If anyone else has the same issue, this ticket can always be re-opened