				 APRX   2.09

				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 

  From: kg4pid@yahoo.com
  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

	20140417070330,KG4PID-14>APRX28,TCPIP*,qAC,FIRENET1:T#014,23.6,4.3,101.0,0.0,17.0,00000000
	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,
  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
