Order Tray | Contact Us | Home | SIG Lists

[aprssig] Sub-second timeslots

Bob Bruninga bruninga at usna.edu
Tue Dec 16 19:17:50 UTC 2008

good idea.  I wonder if the RMC is consistent across multiple GPS vendors?

But I like the idea of a spec to outline the concepts of time-slotting.  But it would be nice to test with at least one WIDEn-N path so that this technique coiuld be used through cross-band digipeaters.  I think having at least one hop should be conisdered a requirement.

So it is good you are testing higher rates..


---- Original message ----
>Date: Tue, 16 Dec 2008 10:03:13 -0800
>From: Scott Miller <scott at opentrac.org>  
>Subject: [aprssig] Sub-second timeslots  
>To: "aprssig at tapr.org >> TAPR APRS Mailing List" <aprssig at tapr.org>
>I announced on the OpenTracker list yesterday that I'd had some success
>in improving the OpenTracker's time synchronization.  With my test
>firmware, as long as GPRMC is transmitted by the GPS receiver at the top
>of the second, synchronization seems to be within about 40 ms even
>without a 1-pps signal.
>Yesterday I had two trackers running in adjacent 1-second time slots
>without interference, which was something it couldn't reliably do
>before.  Today, I've made an experimental modification to select the top
>or bottom of the second for the time slot, and I've got two trackers
>sending without collisions in a 1-second span.
>Here's an audio capture of the two trackers:  http://n1vg.net/2packets.wav
>They both finish in about .9 seconds, with .12 seconds of dead air
>between them.  They're running Base91 compressed mode (including
>course/speed) with no comment and no path.  Obviously you're not going
>to have time to digipeat packets on the same channel if you're running
>half-second time slots, so the lack of a path doesn't make much difference.
>This should be good for special events and such - you can get 10
>trackers on a channel with a 5-second update cycle.  There's more
>testing to be done (I'd like to fill several adjacent slots and do a
>long-term test) but the results so far are encouraging, and it's working
>with cheap HTs, not commercial mobiles with fast TX/RX switching.
>It'd also be nice to establish some sort of actual specification for all
>this.  I don't think anyone's ever made any effort to make sure that
>time slot implementations are compatible between vendors.  This really
>needs a clearly defined spec and some interoperability testing.
>aprssig mailing list
>aprssig at tapr.org

More information about the aprssig mailing list