[aprssig] NextGen

[Dave Baxter]

Hi..
 
The problem (as always) is not encoding the stuff and transmitting it.
But reliably receiving, and decoding it.  In general, the faster the bit
rate the more bandwidth is needed, though that can be mitigated at the
expense of a much more involved signal coding scheme, as I'm sure you
already know.
 
Also, the tolerance to noise goes down somewhat with increasing bit
rate.  Again, there are methods for helping that out too, one obvious
way is to transmit the information multiple times, and average the
result at the receiver, but that sort of defeats the microsecond single
posit TX time, as does adding lots of redundant check bits.  There are
many others.
 
However. doing some of that on "simple" non DSP hardware, such as
Atmel's and PIC's etc (yes, I know there are DSP capable variants) is
less than trivial, also it can get power hungry.   However, check out
what the latest Bluetooth systems use.  OK, only up to (Maximum) about
10 to 20m range, but extremely short burst times and often quite a lot
of data.  Perhaps all that can be scaled?  Lower bit rate, better RF
antennas, more power, etc.  (Just dreaming.)   Then there is WiMax and
the coding that uses.
 
Until we all move to a much more sophisticated coding and modulation
scheme, I think there will always be "Congestion" on APRS in some
locations.  I can't see that improoving anytime soon though.   Also, in
some countries, there might be some interesting licensing issues.  There
was a recent thread on another (non APRS) list I monitor, something
about in the US there is a 300bd limit on amateur "Text" transmission?
But I think that was in regards to HF use (not VHF/UHF low uWave.)
Somone said class it as "Data" and use another digital alphabet to get
round that...
 
Another way, and possibly doable with existing technology, is to perhaps
use the timing abilities of the GPS system, and allow Digi's to command
APRS sources in range to use a specific timeslot?   However, managing
all that in a multiple to multiple system would I think need some extra
backbone infrastructure, not dissimilar to the mobile phone system, and
of course a "back channel" that does not itself congest the main APRS
"Forward" channel...

And of course, as Bob B keeps pointing out, its the simplicity and the
potential self contained ability of APRS, not necessarily reliant on the
IS to form a workable information passing network, that can make it
valuable when all heck unexpectedly happens, and the "lights go out".
With a minimal bit of foresight and planning, APRS will continue to work
and provde a valuable service.  For that, at present, 1200bd packet is
in truth just so easy to setup and keep going in such situations.
 
Don't stop experimenting though, far from it, carry on!
 
73.  (Tin hat on!)
 
Dave G0WBX.
 

________________________________

	From: Andrew Rich (Home) [mailto:vk4tec at tech-software.net] 
	Sent: 19 August 2009 21:48
	To: TAPR APRS Mailing List
	Subject: [aprssig] NextGen
	
	
	Do you think 1200 baud will do us ?
	 
	I have been playing with 19k2 manchester encoding I can send my
position in ms
	 
	I have been looking at PPM Pulse Position Modulation you can
send you posisition in us
	 
	Do we have congestion on packet freq ?
	 
	 
	----------------------------------------------------------
	Andrew Rich 
	Amateur Radio Callsign VK4TEC
	email: vk4tec at tech-software.net
	web: www.tech-software.net