Raspberry Pi Serial vs. TNC-Pi2 vs. APRX

The APRX iGate program I’m using produces a hardware & software event log file:

2016-09-03 11:24:40.368 TTY /dev/serial0 read timeout. Closing TTY for later re-open.
2016-09-03 11:25:10.373 TTY /dev/serial0 Opened.
2016-09-03 11:32:05.485 CLOSE APRSIS noam.aprs2.net:14580 heartbeat timeout
2016-09-03 11:32:15.495 CLOSE APRSIS noam.aprs2.net:14580 reconnect
2016-09-03 11:32:15.776 CONNECT APRSIS noam.aprs2.net:14580
2016-09-03 12:25:11.154 TTY /dev/serial0 read timeout. Closing TTY for later re-open.
2016-09-03 12:25:46.154 TTY /dev/serial0 Opened.
2016-09-03 15:50:14.905 TTY /dev/serial0 read timeout. Closing TTY for later re-open.
2016-09-03 15:50:46.155 TTY /dev/serial0 Opened.
2016-09-03 16:50:51.155 TTY /dev/serial0 read timeout. Closing TTY for later re-open.
2016-09-03 16:51:26.155 TTY /dev/serial0 Opened.

I have no idea what’s going on with the “read timeout” messages. They seem to occur almost exactly a hour apart, except when they’re a few hours apart. The TNC-Pi2 board includes a PIC processor; maybe it loses track of something every now & again, but APRX only notices if it happens in the middle of a read operation.

The APRSIS server connection drops every few days and APRX seems well-equipped to tolerate that.

All in all, it’s working fine…


  1. #1 by madbodger on 2016-09-21 - 10:53

    It could be that it opens the port with a read timeout for some reason. You could read the port parameters with stty -a -F /dev/serial0 and look for timeout settings if you’re curious.

    • #2 by Ed on 2016-09-21 - 13:29

      Learn something new every day! That returns “time = 3;” which say it has a 3/10 second timeout.

      The APRX config file lacks an option for that and a quick check shows it’s hardcoded in the ttyreader.c file. Seems like that ought to be enough; I’m not sure boosting the timeout would change anything.

      I suppose I should bump this to the developer…

  2. #3 by scruss2 on 2016-09-21 - 12:55

    The clock on serial0 isn’t the most stable thing; that’s why the Foundation team dedicated the very stable ttyAMA0 UART to wifi and bluetooth. The core_freq=250 option might make this a bit more solid

    • #4 by Ed on 2016-09-21 - 13:34

      From what I could figure out, earlier this year they tinkered the firmware to freeze the clock whenever the serial port is in use, rendering the core_freq option superfluous. Wish I’d saved that link; IIRC it was deep in the discussion of a bug report about the clock’s effect on the serial rate.