The TX side of the project is still fairly primitive–they have a
hand-coded flow-graph that implements an APCO-25 4-level
FSK modulator, using an audio sink, and then carefully plugging the
audio into the guts of a physical radio, right at the [snipped]
Soundcard output direct into a TX is something we’d actually like to
have working, but as of yet it hasn’t been tested successfully by anyone
that I know of. Getting this to work would be HUGE since it would
enable use of TX RF hardware that has already received FCC certification
in various bands…
So, I decided to adapt what they’d done on the audio side to driving a
USRP directly (with an appropriate RF card, naturally).
Already done! Sorry the docs aren’t better. Check out op25_tx.py
In the case of a “real” flow-graph, taking real data in at
4800symbols/second, going to a real USRP transmitter, will it still
run in “fits and starts” or will it “do the right thing”??
It will do the right thing, assuming that all blocks “do the right
thing” and compute as much output as they are asked to. [snip]
There are of course complexities. When both ends of the flow graph are
connected to hardware, if the clocks aren’t synchronized, you get the
well-known “multiple clocks” problem. This can cause data to either
overrun or underrun the sink. This multiple-clocks problem has
been discussed previously on this list. The op25 TX app has its
“stretch” buffer, Asterisk (PBX) has its “jitter” buffering, etc.
A similar kind of issue you can run into is when local clock drift can
cause the apparent receive rate to differ somewhat from the nominal
value of 4800…
More generally, for example in the case where RF transmissions are only
intermittent, we have the question of how to keep the blocks happy
when no data is flowing. Very briefly, one place this manifests
is in GR’s UDP stuff (used in our remote TX). If you have a GR
udp source and it’s not receiving a constant flow of input, it
will give up and shutdown the entire graph. This is also something
I’ve seen mentioned on the GR list. It’s not a complaint or a
request to fix anything, just an observation…
Best Regards
Max
p.s. another interesting thing on which to speculate is the
effects of the dreaded USRP “underrun” on the overall integrity
of the transmitted spectrum. I’ve a suspicion that one could see,
shall we say, “undesired” spectral components at the instant in
time when the underrun occurs?
/ In the case of a “real” flow-graph, taking real data in at/
/> 4800symbols/second, going to a real USRP transmitter, will it still/
/> run in “fits and starts” or will it “do the right thing”??/
It will do the right thing, assuming that all blocks “do the right
thing” and compute as much output as they are asked to. [snip]
There are of course complexities. When both ends of the flow graph are
connected to hardware, if the clocks aren’t synchronized, you get the
well-known “multiple clocks” problem. This can cause data to either
overrun or underrun the sink. This multiple-clocks problem has
been discussed previously on this list. The op25 TX app has its
“stretch” buffer, Asterisk (PBX) has its “jitter” buffering,
etc.
The multi-clocks problem is nothing new. When our packet-radio group
built
a bit-regenerating 56KBPS repeater in the 1980s, we had to build in a
hardware
elastic buffer to compensate for clock-skew between Tx and Rx.
A similar kind of issue you can run into is when local clock drift can
cause the apparent receive rate to differ somewhat from the nominal
value of 4800…
More generally, for example in the case where RF transmissions are only
intermittent, we have the question of how to keep the blocks happy
when no data is flowing. Very briefly, one place this manifests
is in GR’s UDP stuff (used in our remote TX). If you have a GR
udp source and it’s not receiving a constant flow of input, it
will give up and shutdown the entire graph. This is also something
I’ve seen mentioned on the GR list. It’s not a complaint or a
request to fix anything, just an observation…
Best Regards
Max
p.s. another interesting thing on which to speculate is the
effects of the dreaded USRP “underrun” on the overall integrity
of the transmitted spectrum. I’ve a suspicion that one could see,
shall
we say, “undesired” spectral components at the instant in
time when the underrun occurs?
If those underruns happen only very occasionally, they’ll be no
different than analog noise
in a traditional analog Tx chain, I’m thinking.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.