BUGS / TODO / Wishlist
- Digipeater working wrong:
oz1ekd> oh2mqk - it seems like KG4PID is right, aprx does not digipeat as it should, mine set to "non viscous" and "not direct-only" live log at: http://stave.dk/aprx
Subject: Re: RF beacons vs TCPIP* (was: 2.08 r593 Not digipeating correctly)
As far as I know all the digi's in this area insert their calsign in the
packet. I do see some beacons being digied and igated by other stations
just not as many as I think I should. You maybe right about receiving my
own beacon after a digipeat as I have seen that happen before. It would be
nice if it was marked somehow and what digi heard me. They look just like
the telemetry packets that I know are sent direct. Max
20140417070351,KG4PID-14>APRX28,TCPIP*,qAC,FIRENET1:>Digi/Igate kg4pid at yahoo dot com
20140417071955,KG4PID-14>APRX28,WIDE2-2,qAR,N4XWC:!3417.45N/08742.32W#PHG7250 Bear Creek, Al
- Add to RF-log all packets dropped due to bad bits; use HEX dump,
and type tag 'D'. Use type tag 'd' with text dump when APRS-IS
dropped the frame for one reason or other (network timeouts mostly)
- "[Aprx] Re: Bi-Directional Cross-band Digipeater"
Probably heard sources accounting bucket initializing as zero,
which was fixed recently. (2.07ish)
- SSL mode to talk to APRS-IS. (Aprsc speaks SSL very efficiently.)
- SCTP communication protocol to APRS-IS matching Aprsc's code
- Embedded Perl and/or Python? That would allow folks to cook up
arbitrary action scripts for who knows what purposes...
- Socket API to send/receive/monitor packets?
To get Protocol Buffer or JSON/BSON wrapped datasets of parsed frame
including lat/lon of the packet, type info, etc. ?
- BPQ32 protocol?
- AWGPE protocol?
- Copy-of-APRSIS ? (okay(ish) for monitor + transmit to APRS-IS..)
- Message destined to $MYCALL to be logged at at syslog INFO level,
- Tx-IGate filter rules (interface.c)
Tx-IGate is lacking following things, but it is already doing most
important ones ('recipient heard recently in my service area')
- figure out (at parse_aprs() ?) the number of hops a packet has
traversed so far, and log that on historydb (for recipient "locality"
- test that message recipients known coordinates are within
"my service area"
--> separate filter from adjunct-style areas or distances?
- for position-less packets, send at first a position packet for
same source callsign, if available
- Digipeater behaviour on "requested wideness exceeds allowed
max limit" and this is a directly heard packet:
- now mark all H-bits set
- ADDITION: inject transmitter callsign into first VIA slot.
- Digipeating details of non-APRS UI protocols? Some way to handle
"WIDEn-N" on selected PIDs?
- OpenTRAC support ? (UI, PID=0x77)
- Yes, on DIGIPEATER ONLY - what about WIDEn-N ? Y/N ?
- Windows port?
- Colorize debug printout (or make another tool to colorize aprx-rf.log)
- rx-packets green (or blue), tx-packets red
- port names/callsigns bolded, same with packet source callsigns
- Use internal APRS packet parser to validate beacon configurations.
This should be able to flag bad input on RAW beacon data.
- Calculate and note APRS DXes (like digi_ned does) ?
- Calculate ALOHA range, and publish it?
- Embedded SNTP client?
(Reads NTP time from 127.0.0.1:123 - or configured external source)
Supports Aprx-Aprx clustered protocol where all messages are equipped
with NTP timestamp and if in receiver's opinnion the time is too far off,
the network delays have been excessive and message is discarded.
This SNTP client _does_ _not_ adjust host system clock, only tracks
difference of it against a high(er)-quality NTP service elsewere.
The difference and drift parameters are used to convert current system
gettimeofday() result to NTP timestamp within the code, and to determine
how old something is, a NTP timestamp is compared against "current time."
If Aprx System has no time at all, one SNTP probe is made to determine
"initial system time".
This SNTP client will have two time management states:
- "current time"
- "new time"
If SNTP probes return times that agree with "current time",
the "new time" accumulator is discarded, and possible minor
drift sync is done on "current time."
If SNTP probes return times that do not agree with "current time", then
a "new time" accumulator is used to track the time. If the "new time" is
consistently tracked for 5 samples, "new time" becomes "current time".
Shucks, it would sure be nice if EVERY DIGIPEATER also had a
little smarts and could also report on its own RSSI.
That would give some people a clue what the digipeater is
hearing on its input. In its 10 minute beacon it could report:
"176RX, 109TX, 243 busy"
ON a ten minute basis (total 600 1 sec slots) this tells us that
176 packets were decoded at this site, 109 were elegible for
further digipeating, and another 243 seconds the channel was
busy with other collisions and non decodable traffic. Leaving
72 secnds the channel was clear.
by Matti Aarnio - OH2MQK - oh2mqk-at-sral-fi - 2007-2014