Modulation toolkit ASK noise demodulation

[flavius.vutan]

Why is the ASK demodulation from the toolkit demodulating signals with very low amplitude 0.00xx? how can i tell it to ignore low amplitude signals?

[Tunde_S]

Hi flavius.vutan,

Were you using a particular LabVIEW example or can you share the VI that you are trying to modify?

If your VI used the MT Generate System Parameters.vi, you’ll see that a complex value of 0+0i is in the symbol map. The demod VI is most likely associating this low amplitude signal with the bit value for the “0+0i” symbol.

Also, based on the help documentation for the MT Demodulate ASK VI, I don’t believe this VI has any control for ignoring low amplitude signals. If you don’t want to demodulate the low amplitude signal, would it be acceptable to have a case structure with a case that ignores low amplitude signals and doesn't call the demod VIs?

Regards,

[flavius.vutan]

Hello,

i am not using an example vi. We are developing our own application. Unfortunatelly we have big problems with our board USRP 2940R. I am a kind of dissapointed by this board / the board support

It's been a while since we are trying to send and receive a simple rf telegram. I have attached our vi's in this email.

We observe a lot of strange behaviour with the board. I will try to describe the problem with many details.

The board USRP 2940R has a minimum transmit IQ rate around 390K. We need to transmit at 19200 baud rate. For us to transmit correctly we need minimum

22 samples /symbol. 22 * 19200 -> 422 K Sample rate, just over the minimum IQ rate.
In the attached VI,( RF Main ASK), we tried to send a ASK telegram which appparentrly is sent

Within the RX Vi (Rf RX) we want to receive and demodulate our data but unfortunately it does not work. we cannot match the pattern and find the send data. We don't understand why when reading the signal

not all the samples are read. Nex thing is that the demodulation duration is very very slow. All that we want is to find our data in the reveived information.
I also think the overall behaviour of the board is not stable

Thanks

[ErikL]

Hello -

There are a couple basic communications principals that are very important in this application:

1. Resampling:  The IQ rate in the USRP is specified by the resampler in the FPGA.  The actual IQ rate of the radio is not so important, but you will need to match it with the data you send to the radio.  For narrow band signals you will need to use the aritrarary resampler in the Modulation Toolkit.  Once the signal is resampled from the origianl rate to a compatibleIQ rate of the radio things should work properly.  We did this in the following GPS playback example where the IQ rate of GPS is 1024MS/s which is not a USRP supported rate. We also did this in the POCSAG example. Resampling works great.

POCSAG: https://decibel.ni.com/content/docs/DOC-22067

2. The USRP has a DC offset correction filter at baseband.  This is essentially a tap at 0 that will change the sampe of ASK transmitted at DC.  This is very important to know about for AM / ASK signals, as it could prevent you from transmitting.  Luckily there is a simple solution.  You can manually set the LO to another frequency a few MHz awa and transmit your ASK signal at the desired center frequency.  This is done using a property node, and I believe there is a shipping example for this.

C:\Program Files (x86)\National Instruments\LabVIEW 2013\examples\instr\niUSRP\niUSRP EX Fine-Tune LO Frequency.vi

You'll notice that Local Oscillator (LO) and Carrier Frequency (your baseband IQ signal) can be set to different values.

3. The last thing is RX frequency drift.  The TCXO internal clock has an accuracy of 2.5 ppm, so its acceptable for the frequency to drift a few kHz over time. This is common to wireless systems and is usually tracked and compensated for by a PLL in the receiver.  The modulation toolkit has such a PLL in it.

Overall this is a great applicaiton which I have seen done many times. All of the above best practices apply to both Rx and Tx applications and are common to all software defined radio architectures.

[flavius.vutan]

Thank you EriKL for the great tips.

I was aware about the first two tips but i guess i dind't use the correctly.

For example i used the resample but i thought i have to give a very big IQ rate (~4M). Now i set the iq rate to the standard one (from FPGA)

For the LO, i set it different to my carrier frequency but only with 50 k freq drift. Now i set the low with 10M.

So the conclusion is that the TX Vi works smoother and correct

But i still have problems with the RX VI. I am setting the same system configuration parameters. as for the tx one (434 carrier, 16 Samples/symbol, iq rate ~390k )and the signal is not recognised at demodulation. I am using a simple block for matching and counting the input pattern but the pattern is not recognized. Is there something else that i am missing?

What i know is that while playing a lot at some point i did match the patern but with very strange parameter values. Now i only want to know the logic at the demodulation....

Flavius

[flavius.vutan]

I have also tried to adjust the RX VI and it only detects the data for 44 Samples / Symbol.

[Tunde_S]

Flavius,

What is the actual symbol rate of the transmitter? This is determined by dividing the coerced sample rate of the USRP by the samples per symbol for the array that you pass to the USRP Write Tx Data VI.

On the RX side, you should use the MT Resample VI and the resample rate should be the actual symbol rate of the transmitter multiplied by the transmitter's samples per symbol. Once you’ve resampled the waveform correctly, the demodulation VIs should return the correct bits that were transmitted. Since we are using the MT Resample VI, the RX IQ rate can be greater than the transmitters Symbol rate*(Samples/Symbol).

There are modulation toolkit examples for the USRP that we can reference, as well. You can find these examples in the <LabVIEW>\examles\instr\niUSRP\ModulationToolkitExamples directory.

You can also compare the RX resample complex waveform to the TX complex waveform, in order to confirm that we are correctly resampling the acquired waveform. 

Regards,