>> 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?
|