[aprssig] Sub-second timeslots

[Scott Miller]

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
> 
>