[aprssig] High density timeslotting
Phillip B. Pacier ad6nh at arrl.netFri Jun 9 03:29:58 UTC 2006
- Previous message: [aprssig] High density timeslotting
- Next message: [aprssig] High density timeslotting
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This would be teriffic for something like the Baker to Vegas race... right now, I fire a beacon once every 3 seconds, and digipeat twice in channel. We are likely going to stop digipeating in channel next year and have that handled by a 9600 baud UHF network. But to be able to squeeze more trackers into a smaller slot is something that would be valuable to us. See http://www.b2vtracking.com/slotfiles/ to see how we currently assign beacon slots. 73 Phil - AD6NH scott at opentrac.org wrote: > I'm thinking of trying an experiment, and I was wondering if anyone's > attempted this before. > > Right now, timeslotting on the OpenTracker (and presumably the TT3 and > anything else that supports it) isn't accurate to more than a second or two > because of the way time data is presented in the incoming GPS data stream. > The practical limit would seem to be about 2-3 seconds separation between > trackers. > > With an accurate time reference, though, you could do a lot better than > that. Deluo's pin out info shows (or did the last time I was able to find > it) a 1 pulse per second output, but it turns out that at least for the > current generation of receivers it's actually a TTL version of the data > output. I'm not sure if that applies to the SiRF units as well. The Garmin > GPS18 does provide a real 1PPS output, and better yet, it's well-documented > - something you can't say for ANY of Deluo's offerings. > > Assuming you're not running something with a horribly slow TXD (like a > D700), getting two beacons per second should be pretty easy. Three looks > doable with decent transmitters, and four might be possible with good > equipment and very short packets (200 ms for a 30-byte frame and < 50 ms > TXD). > > The only hardware modification required for an OpenTracker should be an > inverter circuit for the 1PPS pulse to make it into a negative edge to > trigger the interrupt request. Actually, even that might be optional, as > long as you know exactly how long the pulse is. > > The firmware would need a bit of tweaking to synchronize the internal clock > to the 1PPS signal, and some more to make sure that it stops acquiring fixes > a second or two before it's due to transmit so it's not caught in the middle > of an incoming fix. > > Digipeating would present an interesting challenge. Obviously if the > channel utilization is over 50%, you can't digipeat in-channel. Are there > any dual-port TNCs out there that can handle full duplex digipeating, and > what transmitters would be suitable for 100% transmit duty cycle for > cross-band operation? > > It might seem like an exotic application, but I've got a few users who have > expressed interest in this sort of thing. I think they're all for races or > competitions of one sort or another - organized events where everything's > coordinated in advance, with appropriate infrastructure. Higher > timeslotting density means more tracker users and/or a faster update rate > without the added expense of multiple channels. > > Anyway, has this been tried before? Should be interesting to experiment > with. > > Scott > N1VG > > > > > _______________________________________________ > aprssig mailing list > aprssig at lists.tapr.org > https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig > > >
- Previous message: [aprssig] High density timeslotting
- Next message: [aprssig] High density timeslotting
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
