Sampling rate concerning my GNU Radio source block - gnuradio

I'm using a lime sdr mini for my source block with a defined sampling rate of let's say (x) Msps. I know from the spec sheet that the lime sdr mini hardware itself samples at around 30Msps. Also let's assume that x < 30. Does GNU radio just drop samples since the sampling rate is less then that provided by the lime sdr hardware or is there some buffer of sampled data that GNU radio holds and then eventually releases to my flowgraph to compensate for the mismatched sample rates?
I suppose the 'Sample Rate' in the source block is to set the RX of the lime sdr hardware itself? So for the lime sdr mini the sample rate must be no more than 30.72 MS/s.

GNU Radio itself — the framework that manages interconnections between blocks — knows nothing about sample rates; it just passes buffers between blocks as they are available. It will never drop samples.
In all cases I am aware of, a hardware source block which has a sample rate parameter will produce samples at the specified rate. This might internally involve resampling to produce the desired rate, or it might be directly controlling the hardware's sampling clock — in either case, the result in GNU Radio is the same.
(A software source, like the standard Signal Source block, does not obey any clock, and always produces enough samples to keep its downstream buffer full; the sample rate parameter in this case is just a convenience telling it how to convert frequency to phase-increment-per-sample, so you can specify the desired waveform in terms of time rather than samples.)

Related

PSK Modulation in GNU Radio in USRP N310

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.

Usrp1 and Gnuradio

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.

GFSK modulation/demodulation with GNU Radio and USRP

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.

two analog channel affect each other in pic

Iam doing a project to recognize gestures by reading adc values in pic 16f73 using embedded c. Everything works fine while using single adc channel. When i use multiple channels, values are affected each other. is this a hardware error or software problem?
Probably. It's very likely to be one, or the other, or both. Split problem in half.
Eliminate one at a time. Scope/meter on both analog inputs. Change one input - does the other change too? If it does, there is a hardware issue at least. If not, it's software.
This is debugging 101.
It's a hardware effect, but not an error.
From the datasheet:
11.1 A/D Acquisition Requirements
For the A/D converter to meet its specified accuracy,
the charge holding capacitor (CHOLD) must be allowed
to fully charge to the input channel voltage level. The
analog input model is shown in Figure 11-2. The source
impedance (RS) and the internal sampling switch (RSS)
impedance directly affect the time required to charge
the capacitor CHOLD. The sampling switch (RSS)
impedance varies over the device voltage (VDD), see
Figure 11-2. The source impedance affects the offset
voltage at the analog input (due to pin leakage current).
The maximum recommended impedance for analog sources is 10 kΩ. After the analog input channel is
selected (changed), the acquisition period must pass
before the conversion can be started.
To calculate the minimum acquisition time, TACQ, see
the PICmicro™ Mid-Range MCU Family Reference
Manual (DS33023). In general, however, given a maximum source impedance of 10 kΩ and at a temperature
of 100°C, TACQ will be no more than 16 µsec.
It will likely be because you have high impedance sources driving all the ADC pins. When the multiplexer switches from one input to the next, any charge that is stored on the sampling capacitor of the ADC from the previous input will still be there.
If you drive each input with the output of a suitable op amp, when the ADC's multiplexer switches, the op amp is able to drive charge in or suck charge out of the sampling capacitor and the time needed for the new input you are reading can be significantly reduced. Plus, with this method you are not loading the voltage you are wanting to read.
If you cannot drive with a low impedance source, then ensure you have plenty of time for the new input's value to settle.

Regeneration of sine wave using microcontroller

I don't have much knowledge about microcontrollers. In my project, I need to shift the sine wave. Here, I want to know, if I feed pure sine at port A pin 2. Then, will i get the shifted version of pure sine wave at port B pin 2 . will the following instruction work?
Inialise port A as input and port B as output
call delay
portb=porta
we can generate sine wave using DAC in microcontroller. But, as it is not perfect, it wont meet required conditions.
First of all the input needs to be to an ADC, and the output needs to be from a DAC (or a PWM with appropriate output filtering). It is not clear from your question that the pins you have chosen are appropriate for that.
If you are generating the sine from the DAC, why would you apply it to an input only to output it again? If you need two sine waves shifted in phase, why not simply generate calculated outputs from two DAC or PWM? Either way you need two analogue outputs, but that way you do not need any input. A PWM will need greater analogue filtering than a DAC and is likely to support lower bandwidth, but most microcontroller have more PWMs than DACs.
You cannot simply call a delay than copy port a to port b, that would be simply be a copy of a to b after a delay. You need to take samples from A and place then in a FIFO buffer, then apply the output of the FIFO to B. The length of the FIFO determines the delay.
A microcontroller is not an analogue device, you cannot put in an analogue signal on just any old pin and and transfer that signal to another pin. Most pins are digital GPIO, they except just two states representing 0 or 1. No matter what voltage you apply, it will be interpreted as either high or low.
Rather you will have to use an ADC input, sample at sufficiently high frequency, delay the samples through a FIFO, then apply the delayed samples to a DAC. Reconstruction of a "pure" sine wave from the quantized DAC output requires analogue filtering circuitry. With a filter cut-off lower than half the sampling rate you will recover a reasonably good representation of the original signal (which can be any signal with components below half the sampling frequency - it need not be a sine wave). If you do use a more complex signal, you will need to analogue filter the input to remove components above half the sampling rate to avoid aliasing.
It might be possible to do all that on one chip using a Cypress PSoC, since these are hybrid chips with reconfigurable analogue elements as well as a microcontroller.