The short answer is, because our customers require it!
The longer answer is that these are strictly low-earth-orbit
spacecraft, communicating through a relay in geosync. So,
the round-trip time is dominated by the round-trip time to
geosync, which is around 250 mS. The new modems include all
sorts of fancy signal processing, including LDPC error correction
and direct-sequence spread spectrum. So their processing time
could easily become significant.
The whole system has an overall latency budget, and a portion of
it is allocated to the modems. They're being built out-of-house,
so we need to be able to verify their performance when we do
acceptance testing.
@(^.^)@ Ed
mle...@ripnet.com wrote:
OK, so I'm being a smartass, but why do you care about latency on a path whose
path length may be anywhere from a few 10s of milliseconds, to
several hours?
------- Original Message -------
From : Ed Criscuolo[mailto:edward.l.criscu...@nasa.gov]
Sent : 9/10/2009 1:38:07 PM
To : discuss-gnuradio@gnu.org
Cc :
Subject : RE: [Discuss-gnuradio] Latency measurement using GnuRadio
Hi all.
At work we're building some new modems for spacecraft communication,
and I've been tasked with coming up with a test set or tool for
measuring latency through each side of the modem (modulator and
demodulator).
I'd like to use GnuRadio 2 and a USRP2 to do some or all of this.
I was wondering if the sample time-stamping capability was fully
functional in version 2, and if I could use it to insure that a given
sample was transmitted at a specific time. Similarly, can I get time
stamps on received samples?
TIA
@(^.^)@ Ed
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
