Since Updating to the 29 October release, I'm seeing the following problems:
1. YAAC.out has long lists with messages of the following (for example): "/dev/ttyAMA0 excessively long time delay 6msec to queue 66-byte frame AX25Frame[..."
2. AX25xmit-2014-11-03.csv shows mine and several other xmit settings. However, the YAAC map never updates to show the time restarting after my transmits. A check at aprs.fi shows both position and weather packets received via TCPIP. I was showing hits via a digipeater 3 miles away and another station 4 miles away. So I know YAAC is working via the IP port, and I see transmission indicator lights on the radio and the TNC. But YAAC itself doesn't show a time reset unless I ping or trace or something.
My config: Raspberry Pi with Raspbian "wheezy" distro. Java is SE runtime 1.8.0 b132. Raspberry Pi B+ board, and TNC-Pi.
Any help appreciated
Chris, W8CWG, cwgeib at a t t dot n e t
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This can happen if the system is too slow in processing incoming packets from the serial TNC. As the Raspberry Pi is not a very fast machine, these are likely (especially if you are panning or zooming the map at the time, tying up the CPU with map re-rendering). The concern here is whether mid-frame bytes are being lost due to serial receiver overrun. I will investigate to see if some extra time is being wasted in this code area that might cause dangerously high delays.
This is normal. The age times on individual stations on the map are the time since YAAC has received something from the station, not the last time the station sent something. So, you will not see time updates for your own station unless you are receiving digipeater echo-backs of your own transmissions (are you within range of an RF digipeater?). If you only have an APRS-IS connection, you will never see an age for your own station (as the APRS-IS servers will never echo back your own transmissions). I will update the documentation to clarify this.
Andrew, KA2DDO
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since Updating to the 29 October release, I'm seeing the following problems:
1. YAAC.out has long lists with messages of the following (for example): "/dev/ttyAMA0 excessively long time delay 6msec to queue 66-byte frame AX25Frame[..."
2. AX25xmit-2014-11-03.csv shows mine and several other xmit settings. However, the YAAC map never updates to show the time restarting after my transmits. A check at aprs.fi shows both position and weather packets received via TCPIP. I was showing hits via a digipeater 3 miles away and another station 4 miles away. So I know YAAC is working via the IP port, and I see transmission indicator lights on the radio and the TNC. But YAAC itself doesn't show a time reset unless I ping or trace or something.
My config: Raspberry Pi with Raspbian "wheezy" distro. Java is SE runtime 1.8.0 b132. Raspberry Pi B+ board, and TNC-Pi.
Any help appreciated
Chris, W8CWG, cwgeib at a t t dot n e t
Regarding your questions:
This can happen if the system is too slow in processing incoming packets from the serial TNC. As the Raspberry Pi is not a very fast machine, these are likely (especially if you are panning or zooming the map at the time, tying up the CPU with map re-rendering). The concern here is whether mid-frame bytes are being lost due to serial receiver overrun. I will investigate to see if some extra time is being wasted in this code area that might cause dangerously high delays.
This is normal. The age times on individual stations on the map are the time since YAAC has received something from the station, not the last time the station sent something. So, you will not see time updates for your own station unless you are receiving digipeater echo-backs of your own transmissions (are you within range of an RF digipeater?). If you only have an APRS-IS connection, you will never see an age for your own station (as the APRS-IS servers will never echo back your own transmissions). I will update the documentation to clarify this.
Andrew, KA2DDO