[aprssig] High density timeslotting
Phillip B. Pacier
ad6nh at arrl.net
Thu Jun 8 23:29:58 EDT 2006
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
>
>
>
More information about the aprssig
mailing list