I'm actually on 3.9.5 but I will investigate on the PDUs to know if it
could help me.
RX and TX period are completly random from hundreds of milliseconds to
several seconds.
Thanks for your help,
Best regards,
Fabien, F4CTZ.
Le 04/03/2022 à 13:31, Johannes Demel a écrit :
Hi Fabien,
Per
Hi Fabien,
Personally, I use PDUs to control when TX starts. GR 3.10 integrated a
lot more of these.
https://github.com/gnuradio/gnuradio/tree/main/gr-pdu
Besides, the gr-pdu_utils OOT might be a good reference.
https://github.com/sandialabs/gr-pdu_utils
It mentions SOB/EOB in their docs.
EOB i
Hi Johannes,
Yes this is exactly my problem : after unlocking the flowgraph, I get
some underruns (only, no overrun).
Do you have an example of code using EOB/SOB ? Ok for sending EOB before
locking but is it necessary to send a SOB also and when ?
Your suggestion of idling the TX flowgraph
Hi Fabien,
do those underruns occur after you lock/unlock and switch from TX to RX
or vice versa? Do you see overruns as well?
I'd assume the USRP expects a constant sample flow and even a short
interuption, like your lock/unlock task interrupts that flow.
Still assuming this is the root caus
Hello again,
I build a flowgraph in C++ with an RX chain and a TX chain. I'm using a
USRP N210. When I'm in RX, the TX chain is connected to a constant zero
source and feed a null sink and the RX chain is connected to USRP source
and sink. When I'm in TX, it is the opposite.
I have to keep t
I found something on the mailinglist that there might also be
SEND_MODE_ONE_PACKET function beside the SEND_MODE_FULL_BUFF but
actually it affects nothing as I replace it in the gr_uhd_usrp_sink.cc
(after recompling etc.).
In another thread it was mentioned that the transmitting buffer is not
t
> Please don't e-mail the same question to the list in multiple threads -
> it actually makes it more difficult for people to help you in a coherent
> manner.
Sorry, I thought about to specify that a little bit more to make it
findable more easily afterwards.
> It is possible that tunnel.py is
Florian -
Please don't e-mail the same question to the list in multiple threads - it
actually makes it more difficult for people to help you in a coherent
manner.
Switching between RX and TX on the XCVR daughterboard should have very
minimal overhead - certainly not 6 ms. As soon as it sees the
Trying out the tunnel.py example, we are transmitting a ping request
between two USRP2s. The receiving USRP should respond immediately with a
ping reply what the outpout is also saying.
At all, this ping reply is not send. We can bypass this by deploying a
time.sleep(0.05) at the RX-USRP before
