[aprssig] Sub-second timeslots
bruninga at usna.edu
Thu Dec 18 11:13:54 CST 2008
How much TXD are you gettin gby with?
---- Original message ----
>Date: Wed, 17 Dec 2008 13:53:19 -0800
>From: Scott Miller <scott at opentrac.org>
>Subject: Re: [aprssig] Sub-second timeslots
>To: TAPR APRS Mailing List <aprssig at tapr.org>
>I had another firmware update due anyway, so I added the half-second
>slotting to the new release and it's available for download now. I'd
>still consider this feature experimental, though. If you get the new
>otwincfg program, you can add .5 to the slot number to transmit in the
>second half of the second. Just remember to set 'quiet time' to zero or
>it'll still hold off if the channel is busy.
>Bob Bruninga wrote:
>> 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..
>> Bob, WB4APR
>> ---- 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
>> aprssig mailing list
>> aprssig at tapr.org
>aprssig mailing list
>aprssig at tapr.org
More information about the aprssig