				 APRX   2.08

				TODO / Wishlist

- "[Aprx] Re: WIDE2-2/NOGATE - trace not working?"

- "[Aprx] Re: Bi-Directional Cross-band Digipeater"
  Probably heard sources accounting bucket initializing as zero,
  which was fixed recently.


- 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,
  and acknowledged(?)

- 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"
     analysis)
   - 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".


BoB:
	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
