[aprssig] Sub-second timeslots
Bob Bruninga bruninga at usna.eduTue Dec 16 19:17:50 UTC 2008
- Previous message: [aprssig] Sub-second timeslots
- Next message: [aprssig] Sub-second timeslots
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [aprssig] Sub-second timeslots
- Next message: [aprssig] Sub-second timeslots
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
