[aprssig] Sub-second timeslots

[Bob Bruninga]

How much TXD are you gettin gby with?
Bob, WB4APR


---- 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.
>
>http://argentdata.com/support/otplus.html
>
>Scott
>N1VG
>
>Bob Bruninga wrote:
>> Scott,
>> 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.
>>>
>>>Scott
>>>N1VG
>>>
>>>
>>>
>>>_______________________________________________
>>>aprssig mailing list
>>>aprssig at tapr.org
>>>https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>> 
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>> 
>> 
>
>
>_______________________________________________
>aprssig mailing list
>aprssig at tapr.org
>https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig