On 1/9/19 6:59 PM, Derek Kozel wrote:
Your messages have gotten spread out over several threads now, so
lets get it all in one place. We've been talking off-list about
how the list is setup and how to reply, hopefully it works now.
Please do test the output of your custom block and TX flowgraph by
using the file sink and plotting the results. Many many things can
go wrong when actually using radios and wireless links, make sure
that your generated signal is correct before trying to transmit
and receive it over the air.
Others: For reference here is the text from Yuxiao's first
Images are located here:
Communication State Machine:
create a OOT module that uses a state machine structure to
implement a wireless transmission protocol (i.e., command
sequences in the air) that communicate with a backscatter
device. The commands are in the following order: (CMD 1 + CW)
-> (CMD2 + CW) -> POWER_DOWN -> (CMD 1 + CW), in
which CW is the carrier wave signal (i.e., constant bit 1s)
and POWER_DOWN is constant bit 0s. I add a power_down state
because otherwise CW amplitudes will continuously fall down to
nearly zero. Please refer to the trend in the figure
MessyCommandOrders.png even if POWER_DOWN state is added.
GNURadio OOT module does not support a source block, I create
a dummy source block like a low-frequency SIN wave and connect
it to my OOT block, and ignore the input in the forecast() and
general_work() functions. In the apps/ folder, I create a
python code that uses two independent hierarchical blocks to
configure the Tx and Rx path respectively. In the Tx path, I
connect my OOT block to amplifier, float_to_complex and USRP
sink. The frequency of the dummy source block is 100Hz. The
sampling rate of both the OOT block and USRP sink is around
3.33e6. The timing of command durations in the air is made by
creating enough number of bits based on this sampling rate. In
the Rx path, I simply connect a USRP source block to a file
sink. The sampling rate of USRP source is 20e6. I have
inspected the state machine execution using gr_log function
and it seems that the state machine functions well. However,
when I look at the waveform of the received samples, the
commands become disordered after some rounds.
N210 + SBX Board Rev. 5.1 (daughterboard)
Operating system: Ubuntu 16.04
Antenna: Laird S8658PR, 865-868 MHz (can operate in 915MHz
band), 8 dBic
Operating frequency: 915MHz
after several rounds the waveform of a command changes
polarity: a bit 1 becomes low amplitude and a bit 0 becomes
high amplitude. Sometimes only part of the command waveform
can be observed; it seems that the USRP suddenly stops
transmitting the command and goes to the next one.
Sometimes the order of the commands is messy and does not
match the state machine in the code.
CW is not transmitted.
anyone explain about this phenomenon and how to fix this
On 09/01/2019 11:51, Yuxiao Hou
Thank you for your reply. I have attached
two graphs, one is the example command waveform, another is
the flow graph of my application.
As for your questions, first I think I
encountered some “U” letters,I was not aware of its
indication; I have thought about dumping the transmitted
signal to a file trace, but I have not done this yet; I
think 20MS/s may be the highest receiver sampling rate that
is allowed by USRPN210 for a valid file record. I have
tested with this rate and it works fine sometimes, for other
times I am not sure.
I will test with file sink output and have
a look at the gr-osmosdr example and update my latest
progress with you here.
Discuss-gnuradio mailing list
Discuss-gnuradio mailing list
I forgot if I click the send button or not. Apology for this test