In the real world, glitches happen on analog channels.
Which is why you develop techniques to cope with them.
I see the occasional underrun/overrun as equivalent to
these glitches.
Yep - it just so happens that these are “digital” (P25) channels,
not analog ones, but robust detection/correction protocols at the
higher levels are there to cope with the occasional glitches…
In P25 there are so-called “status symbols” (SS) which are sent
at regular intervals and are interspersed in the bitstream - it’s
my guess that an underrun occurring during USRP tranmission of P25
would be observable at the receiver as a momentary glitch as you’ve
said and also (unless somehow pre-correction were done) as a sudden
random shift in the phase of these “clock” (status) symbols,
(perhaps not an everyday occurrence in production environments)…
P25 trunking uses slotted Aloha which (as I understand the current
GR state) isn’t completely precluded in USRP1 even though USRP1
doesn’t support timestamping. However once again suspect that the
slot timing would be momentarily thrown off by the occurrence of
a TX underrun.
It’s time to break down and buy a USRP2, though :-\ and WBX too
You’d rather they not happen often enough
that they seriously impact your channel BER.
Yeah - that was the previous question - precisely how to write data
towards the USRP1 sink, essentially in real-time,
“at a rate controlled by a feedback loop responding to the
observed clock mismatch.”
I too am not focusing on the occasional error, the question was a
systemic one… Perhaps the answer lies outside of GR…
73
Max
