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.
Related
Currently I am working with the Ettus Research's N310 on the implementation of different PSK modulation schemes. I am interested on measuring the Bit Error Rate -BER- for each scheme when I transmit data between two USRPs located one beside the other. Therefore, I am employing GNU Radio Companion for the SW development. In the case of the BPSK transceiver, I am using a standard configuration of a vector source and a constellation modulator to create the PSK symbols, which are transmitted at 2.45GHz using the VERT2450 antennas. These antennas work in the frequency range from 2.4 - 2.5 GHz and from 4.9 - 5.9 GHz. Since I have a desktop computer with only one ethernet port, I am using the NetGear GS108 switch, which has 16Gbps bandwidth and a forwarding rate of 10Mbps port. The current SW setup is shown in the following figure:
I am using as input a vector of only zeros since I am interested to probe that my transceiver detects correctly one constellation. However, I am having continious jumps between the constellation points as you can see from the picture in the left side. I have several questions about my setup:
What is the correct baud rate for each modulation scheme? It means how many symbols per second should I use for BPSK, QPSK, 8PSK and 16 QAM.
Since the USRP N310 has a default sample rate of 125MSamples/second, and my desktop machine can only deal with 5MSamples/second, then I have a decimation rate of 25(sample_rate_usrp/sample_rate_desktop). What is the value for the sps -samples per symbol- parameter that I should assign in each block of the transceiver?
When is the CMA equalizer necessary? Since the USRPs have a static position, then there is no frequency changes due to the Doppler effect. Consequently, an equalizer should not be necessary. Why is this reasoning not correct? I suppressed the equalizer and the constellation diagram is presented as a circle.
Does the Polyphase Clock Synchonization really synchronize the received signal with the transmitted signal or can I supprime it and replace it with an equalizer?
I would really appreciate if someone could help me to bring some light to all of this questions.
Thanks in advance
See my response at https://lists.gnu.org/archive/html/discuss-gnuradio/2020-08/msg00172.html
The 'correct' baud rate is anything you want to use.
You need to check the minimum sample rate for the N310.
The CMA Equalizer is optional under your conditions. I left it out of the BPSK to simplify the flowgraph.
The Polyphase Clock Sync Block recovers the timing of the received signal. The equalization is for fading and is a separate function.
It looks like you're modulating with 8 SPS but then demodulating 16 SPS -- 8:1 on the PCSync and 2:1 on the CMA eq.
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 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.
Im currently creating a satellite ground station which will be used to control our cubesat in coming months. The modulation scheme used is GFSK and the baud rate is 9600. I have tried to run some tests by using a USRP board before I could try to communicate with the satellite by directly connecting the tx and rx blocks in the flowgraph.I was able to send and receive a png file using this flowgraph.
However, when I connect the tx and rx output to my USRP B210 TX/RX(transmission sink) and RX2(reception source) as shown below, I receive no data even though the two the source and sinks have been connected to each other carefully by RF cables with attenuators.
Below are the assumptions I took into account when I was making the second flowgraph. Please tell me if im on the right path.
Transmitter side : The packet decoder and GFSK mod blocks use 20 samples per symbol. Baud rate is 9600 and sample rate is 20*baud rate = 192K. Since the expected symbol rate by the satellite is baud_rate = 9600, I included a rational resampler and set UHD symbol rate to baud_rate. Is my logic correct?
GFSK mod and demod : For both of these blocks, I calculated sensitivity as S = Pi * Modulation_index/Samples_Per_Symbol. The default BT value of 0.5 is used. Are my calculations sound? Is there a link for to find documentation for GFSK blocks? My derivations are based on the GFSK python source code which is a poor substitute for documentation.
Packet Encoder/Decoder : The output of packet decoder is null even though the GFSK demod block give some kind of output which is rather meaningless. Is this normal? What is the meaning of the threshold variable and why its value is -1?
I'm a newbie in GNU Radio as well as GFSK in general. So please drop me any further references.
Thanks in advance.
Moses.
I was finally able to solve the problem. All I did was re-implementing the GFSK demod in GRC. If you go into source of gfsk.py, you will find out that the blocks used are Quadrature Demod --> M&M Clock recovery --> Binary slicer which can easily be connected in GRC directly. As Marcus suggested in my other thread, GFSK demodulation with Xlating filter in GNU Radio , I replaced the M&M Clock recovery block with PFB block. My flowgraph is shown below.
Even if I can not answer all of your questions, I provide below some thoughts:
When using hardware devices the Throttle MUST be removed from the flow-graph. The hardware device is now responsible for the rate limiting. Mixing hardware device and the Throttle block may break the real-time boundary of your flow-graph required by the device. Underflows or Overflows messages should be produced by the UHD driver in such a case.
Are you sure that the USRP can support the requested sampling rate? You may need also to change the master_clock_rate of the device, if the requested sampling rate is not an integer decimation of the clock. If this is not possible consider some kind of re-sampling.
EDIT: The B200 can not provide 192e3 sampling rate with the default clock. You can set the master_clock_rate at 19.2e6. The hardware will apply then the proper decimation. The master_clock_rate can be changed either by the device specific arguments or the Clock Rate field of the UHD Sink/Source blocks that presents in the latests GNU Radio versions.
I'm doing a USB device is to control stepper motors. I've done this before using a parallel port. because these ports do not exist in current motherboards, I decided to implement a USB communication between my device and the PC (host).
To achieve My objective, I endowed the freescale microcontroller the device with that has a USB module 12Mbps.
My USB device must receive 4 bytes (one for each motor driver) at a given time, because every byte is a step that should move the engine.
In the PC (Host) an application of user processes a text file with information and make the trajectory coordinates sending bytes at a certain rate for each motor (time is trivial to achieve the acceleration and speed of the motors) .
Using the parallel port was an easy the task because each byte is sent sequentially to a time determined by the user app.
doing a little research about full speed USB protocol understood that the frame is sent every 1ms.
then you can send 4 byte or many more every 1ms but I can not manage time like I did with the parallel port.
My microcontroller can send up to 64 bytes per frame (Based on transfer papers type Control, Bulk, Int, Iso ..).
question 1:
I want to know in what way I can send 4-byte packets faster than every 1 ms?
question 2:
What type of transfer can advise me for these type of devices?
Thanks.
Like Ricardo said, USB-serial will suffice.
As for the type of transfer, try implementing a CDC stack and use your SCI receiver to listen for PC commands. That will give you a receive buffer which will meet your needs.
Initialize your SCI (baud, etc)
Enable receiver and interrupt
On data receive, move it to your 4-byte command buffer
Clear receive buffer, wait for more
When you have all 4 bytes, fire off the steppers! Four bytes should take µs.
Check with Freescale to see if your processor is supported.
http://cache.freescale.com/files/microcontrollers/doc/support_info/USB_STACK_RELEASE_NOTES_V4.1.1.pdf?fpsp=1
There might even be some sample code to get you started.
-Cheers
I am achieving the same goal (driving/control CNC machines) like this:
the USB device is just synchronous I/O parallel port. Using continuous bulk transfer one pipe as input and one as output. This way I was able to achieve synchronous 64bit parallel communication with ~70KHz sample rate. It uses traffic around (i)4.27+(o)4.27 MBit/s that is limit for mine MCU and code. Bigger speeds cause jitter on the output due to USB events interrupts.
How to do it (on MCU side)
I have 2 FIFO's one for ingoing and one for outgoing data. I have timer interrupt occurring with sample rate frequency. In it I read the inputs and feed it to the first FIFO and read data from the other FIFO and send it to the outputs.
On top of that the USB task is called (inside the same interrupt) checking FIFO for sending to and incoming data from USB handling the transfer itself
I choose ATMEL AT32UC3A chips for this task. After a long and pain full research I decided these MCU's because they have enough memory for both FIFO's and program so no need for additional IC. It has FPGA package which can be used (BGA is not an option). It has HS USB (most USB MCU's have only FS like yours). It runs at 66MHz. It supports many interesting features (did interesting projects with it in the past) and of coarse I have experience with ATMEL MCU's from past
So if you want to achieve something similar then
start with bulk transfer (PC -> USB -> MCU -> output)
add FIFO if needed
do not know the sample rate you need. The old LPT's could handle from 80-196KHz depend on the manufactor. The modern ones are much much slower (which is silly and sad).
measure the critical sample rate
you need oscilloscope or very good hearing for this. The output data must be synchronous so no holes in it, no jitter, etc...
if any of these are present you have to lower the sample rate. Mine setup could handle even 1MHz sample rate but the USB jitter was present (sometimes USB event froze the sending for longer that one sample...) so I achieve only 70KHz of stable output.
if needed also inputs then add them
but only if the output is working as it should. Do not forget to lower the sample rate after this too ... Use separate bulk pipes and FIFOs for input and output.