I am going to transmit the complex data produced from matlab by using usrp b210 and gnuradio on windows.
gnuradio flowgraph is following:
Here, data type is complex.
Problem:
I want sample-rate is 20MHz or 30.72MHz, but gnuradio is stoped, logging out 'UUUUUUU...' or 'UUOUUUUU...'.
why?, and how to fix it? please help me. thanks.
GRC will even warn you that you must not use a throttle block in your flow graph if you have hardware. Read the console log!
Other than that, you're expecting your storage to read and write simultaneously 16 MS/s · (32 bit I + 32 bit Q) = 1.024 Gb/s, reliably. It's also not very likely it's fast enough to do that.
Related
I have two USRP B200 connected to two Raspberry Pi's that I want to communicate via AX.25. Here are the flowgraphs:
TX:
RX:
They work well and are able to communicate. However, if I change the samp_rate to 200k on both the TX and RX, the RX is not able to receive the messages sent. However, if I use Direwolf with RTL-SDR, I am able to receive the messages sent at 200k. Can anybody help me how to receive the data sent at 200k?
Thanks!
This is really an outdated version of GNU Radio. gr-ax25 is ported to GNU Radio 3.9 and 3.8; please use a modern GNU Radio (3.8 or 3.9), that solves a lot of problems you'd otherwise run into later on.
Also, as UHD will print to the console, 150 kS/s is lower than any sampling rate than any USRP actually supports, and hence is substituted for a different one – which works, because both ends of the communication do the same!
It's still not "proper". You need use a higher rate (recommendation: 1 MS/s) and use a resampler to go down to the very low AX.25 rates; the "rational resampler" block will do that!
Then, you misconfigured both your NBFM TX and RX – your quadrature rate is not the 48 kHz you configured, but your actual sampling rate / 4.
Of course, as long as both ends of the communication are "wrong in the same way", they have a chance of working together. But any actually correct receiver implementation won't be able to make out what you meant to send.
I'd recommend you look into the apps/ subofolder of dl1ksv's gr-ax25. That contains a properly set up APRS transceiver, for a sampling rate of 192 kS/s; I'd recommend you replace the fcdproplus blocks with your UHD USRP source/sink blocks and use a rational resampler, so that at the USRP Source you decimate by 16, and on the USRP Sink you interpolate by 16. Your sampling rate for both Sink and Source would then be 192000*16.
I am working on a project to transmit and receive the binary data by using QPSK modulation and demodulation technique on GNURadio via SDR (BladeRFx40). Here is the sketch of the task to be implemented.
The flow graph is simple and workable when the intent is not to use bladeRF or is solely to modulate and demodulate binary data as the image shows
But problem arises when using osmocom source and sink (i.e. QPSK transceiver via BladeRFx40).
Few Important Questions and Problems Regarding the Working:
On the receiver side, the osmocom source(or the received signal) when tested directly using FFT plot gives no signal. How can this be made to work successfully?
Theoretically, QPSK modulation is mapping plus up-conversion, but in GNURadio, QPSK Mod block only shows mapping but no up-conversion, does the purpose of up-conversion is fulfilled itself when osmocom sink block is used(since it shows frequency at which signal is to be transmitted)? Or the up-conversion is done separately by multiplying QPSK Mod Block output with sinosoid along with osmocom sink block? Precisely how is up-conversion done on GNURadio for such a task?
If only i do modulation and demodulation without transmitting and receiving on SDR platform, then i must up-convert and down-convert it separately according to my understanding. Even then, i am unable to get the binary data: here is the attachment for it too, Kindly rectify me for any misplacement or misuse of the blocks and recommend for any changes needed in the flow graph of image.
I recommend that you visit the following link (if you have not seen it yet). When we talk about digital modulations, and these are transmitted / received by a USRP, HackRF, etc., the recovery of the signal is not as easy as in FM or AM.
I do not fully understand your question because I just entered the world of SDR, but in the sdr sinks (UHD or OSMOCON) is where the RF frequency is configured (M / GHz).
If you want to simulate the TX / RX process, you do not need to configure the RF frequency because it will not transmit this signal to the air. You will be working in Baseband
I'm using a USB-6356 DAQ board to control an IC via SPI.
I'm using parts of the NI SPI Digital Waveform library to create the digital waveform, then a small wrapper VI to transmit the code.
My IC measures temperature on an RTD, and currently the controlling VI has a 'push for single measurement' style button.
When I push it, the temperature is returned by a series of other VIs running the SPI communication.
After some number of pushes (clicking the button very quickly makes this happen more quickly in time, but not necessarily in number of clicks), the VI generates an error -200361, which is nominally FIFO buffer overflow on the DAQ board.
It's unclear to me if that could actually be the cause of the problem, but I don't think so...
An NI guide describing this error for USB-600{0,8,9} devices looks promising, but following the suggestions didn't help me. I substituted 'DI.UsbXferReqCount' for the analog equivalent, since my read task is digital. Reading the default returned 4, so I changed the property to write and selected '1', but this made no difference.
I tried uninstalling the DAQ board using the Device Manager, unplugging and replugging, but this also didn't change anything.
My guess is that additional clock samples are generated after the end of the 'Finite Samples' part for the Read and Write tasks, and that these might be adding blank data that overflows, but the temperatures returned don't indicate strange data, and I'd have assumed that if this were the case, my VIs would be unable to interpret the data read in as the correct temperature.
I've attached an image of the block diagram for the Transmit VI I'm using, but actually getting it to run would require an entire library of VIs.
The controlling VI is attached to a nearly identical forum post at NI forums.
I think USB-6356 don't have output buffers used for Digital signal. You can try it by NI-MAX, if you select the digital output, you may find that there is no parameters for Samples. It's only output a bool-value(0 or 1) in one time.
You can also use DAQ Assistant in LabVIEW, when you config Digital output, if you select N-Samples or Continuous samples, then push OK button, here comes a Dialog that tell you there is no buffer for lines that you selected.
I am trying to set up 5 USRP1 and some daughterboards on 2.4 and 5 GHz.
Some of them are out of order and some work properly, but I don't know which is which. I am trying to send a symbol (QAM modulation) sequence then I am trying to pass it with a file source to both a USRP sink and an FFT sink.
I am trying to find articles and tutorials, how sample rates are connected and how to set up them but I can't understand what am I missing. Could somebody please help with the schemes?
128 MS/s is not a rate that is possible with the USRP1. The console will contain a UHD warning that a differen, possible rate was chosen (most likely, 8MS/s).
Now, you contradict that rate by having a "Throttle" block in your flow graph - that block's job is only (and nothing more) to slow down the average rate at which samples are being let through – and that is something your "USRP Sink" already does. In fact, modern versions of GRC will warn you that using a throttle block in the same flow graph as a hardware sink or source is a bad idea.
Now, you'll say "ok, if the USRP sink actually needs to consume but 8MS/s, and my interpolator makes 128 MS/s out of my nominally 1M/s flow (really, signals within GNU Radio don't have a sampling rate), then that's gotta be fast enough to satisfy the 8MS/s demand!".
But the fact is that a 128-interpolator is really a CPU-intense thing, and the resulting rate might not be that high, made even worse by the choppy nature of how Throttle works.
In fact, your interpolator is totally unnecessary. The USRP internally has proper interpolators for integer fractions of its master clock rate 64MS/s, which means that you can set the USRP Sink to a sampling rate of 1MS/s and just directly connect the file source to it.
The N210 is connected to the RF frontend, which gets configured using the GNU Radio Companion.
I can see the signal with the FFT plot; I need the received signal (usrp2 output) as digital numbers.The usrp_sense_spectrum.py output the power and noise_floor as digital numbers as well.
I would appreciate any help from your side.
Answer from the USRP/GNU Radio mailing lists:
Dear Abs,
you've asked this question on discuss-gnuradio and already got two
answers. In case you've missed those, and to avoid that people tell
you what you already know:
Sylvain wrote that, due to a large number of factors contributing to
what you see as digital amplitude, you will need to calibrate
yourself, using exactly the system you want to use to measure power:
You mean you want the signal power as a dBm value ?
Just won't happen ... Too many things in the chain, you'd have to
calibrate it for a specific freq / board / gain / temp / phase of the
moon / ...
And I explained that if you have a mathematical representation of how
your estimator works, you might be able to write a custom estimator
block for both of your values of interest:
>
I assume you already have definite formulas that define the estimator for these two numbers.
Unless you can directly "click together" that estimator in GRC, you will most likely have to implement it.
In many cases, doing this in Python is rather easy (especially if you come from a python or matlab background),
so I'd recommend reading at least the first 3 chapters of
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
If these answers didn't help you out, I think it would be wise to
explain what these answers are lacking, instead of just re-posting the
same question.
Best regards, Marcus
I suggest that you write a python application and stream raw UDP bytes from the USRP block. Simply add a UDP Sink block and connect it to the output of the UDH: USRP Source block. Select an appropriate port and stream to 127.0.0.1 (localhost)
Now in your python application open a listening UDP socket on the same port and receive the data. Each sample from the UDH: USRP Source is a complex pair of single prevision floats. This means 8 bytes per sample. The I float is first, followed by the Q float.
Note that the you need to pay special attention to the Payload Size field in the UDP Sink. Since you are streaming localhost, you can use a very large value here. I suggest you use something like 1024*8 here. This means that each packet will contain 1024 IQ Pairs.
I suggest you first connect a Signal Source and just pipe a sin() wave over the UDP socket into your Python or C application. This will allow you to verify that you are getting the float bytes correct. Make sure to check for glitches due to overflowing buffers. (this will be your biggest problem).
Please comment or update your post if you have further questions.