discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Writing a custom source block, debugging incorrec


From: Yuxiao Hou
Subject: Re: [Discuss-gnuradio] Writing a custom source block, debugging incorrect output
Date: Mon, 11 Feb 2019 18:18:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

On 1/9/19 6:59 PM, Derek Kozel wrote:
Hi Yuxiao,

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.

Derek

Others: For reference here is the text from Yuxiao's first message.
Images are located here: https://lists.gnu.org/archive/html/discuss-gnuradio/2018-12/msg00003.html

""""""
# Communication State Machine:

I 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.

# Implementation Details:

As 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.


# Hardware/Software Configuration:


GNURadio version: 3.7.9
USRP 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

# Figure Illustration:

MessyCommandOrders.png: 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.
MessyCommandOrders.png: Sometimes the order of the commands is messy and does not match the state machine in the code.
NoCWTransmission.png: CW is not transmitted.


Could anyone explain about this phenomenon and how to fix this issue? Thanks!
""""


On 09/01/2019 11:51, Yuxiao Hou wrote:
Dear Derek,

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.

Best Regards,
Yuxiao


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Dear Derek,


Recently I have explored output to a file sink instead of a USRP receiver, and found that the waveform or ideal data is not consistent even for the simplest case.


I am still working on it to provide a better insight. This email has another purpose of trying to reply in this forum in the same thread. Hopefully this time it works.


I will update with you about my progress soon.


Best Regards,

Yuxiao


reply via email to

[Prev in Thread] Current Thread [Next in Thread]