From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

USRP Software Radio

cancel
Showing results for 
Search instead for 
Did you mean: 

Signal not transmitted correctly at high IQ rate

Hi guys,

 

I am working with a USRP 2940 R which is on PCIe. I have to transmit an array of bits on one shot(somewhere at 6500 bits)

at a baud rate of 19200. The carrier frequency is 434.64. For this USRP the minimum IQ rate is ~39k so i set it to 39k and then i calculate the number of samples / symbol by : IQ rate / 19200(symbol rate) which results 22. With this settings my telegrams (which are encoded as ASK OOK with modulation toolkit) are not always recognised by my receiver.  The telegram can be seen on the osciloscope quite nice but the behaviour is not allways the same.

The problem is the following: when i try to increase the symbol rate(to have a more acurate signal) i need also to increase the IQ rate BUT for bigger IQ rates my signal is not sent correctly, there are a lot of brakes and inconsistencies.

Why is the signal sent incorect with bigger IQ rates(ex: 1M). Also the baud rate is no longer the same for biger IQ rates? Why? since i keep the formula

symbol rate X baud rate = IQ rate?

 

Thanks

0 Kudos
Message 1 of 17
(8,489 Views)

I believe you need a fractional resampler on the host.

1. generate the signals at the desired rate

2. upconvert to an integer multiple of the original sample rate that is also supported by the USRP (integer is important, as a non integer can ge messy)

3. Transmit the data

 

We do this frequently without issue for very narrow band signals.

 

The Modulation Toolkit contains a fractional resampler that works well.  I believe the VI is called MT Resample.vi

 

Erik

0 Kudos
Message 2 of 17
(8,485 Views)

Thanks Erik

 

I have added a mt resample block and set a new sample rate by multiplying the symblo rate x samples / symbol and a gain (15). So now my IQ rate was increased to

~4.5M. I can see my telegram now, but again not all the time is received. I have observed that the information that i sent is vrey sensitive to the gain of the write CDB block, to the gain from the MT resample and the

symbol rate. There is only one specific combination that sends correct information(but not all the time). For example if increase the symbol rate or lower the gain from MT block it will not work.

I have attached the VI

 

Thanks

 

0 Kudos
Message 3 of 17
(8,473 Views)

A second factor to consider for low rate signals.  There is a DC offset correction filter in the USRP's signal chain (inside the device).  I suggest tuning the local oscillator off of your intended carrier.  Any signal crossing DC, or centered around DC will be affected by both the LO leakage and the DC offset filter. (high pass filter)

 

To do this, use the property nodes just after initalization.  It will move the LO over and lock it and using a CORDIC frequency shift, move your signal to the right location.  The whole process will be transparnt to you after the property node is used.  (see attachment)

 

 

0 Kudos
Message 4 of 17
(8,466 Views)

Dear All,

 i have NI USRP 2940R i.e x310 connected to machine running Windows 7 on LabVIEW Communication system Design suite via SFP port 0. I've reprogrammed the device with jtag USB  via impact Xilinx bit file 


also by CMD

C:\Program Files (x86)\National Instruments\NI-USRP\utilities>usrp_x3xx_fpga_bur
ner --addr=192.168.10.2 --fpga-path C:\usrp_x310_fpga_HGS.bit
Win32; Microsoft Visual C++ version 10.0; Boost_105000; UHD_003.007.001-234-g52c
71523

A runtime or configuration error occurred.
Code: 2410
Details: LookupError: Path not found in tree: /mboards/0/dboards/A/rx_frontends/0/sensors/lo_locked
 
 
Attempting to find X3x0 with IP address: 192.168.10.2

UHD Warning:
   X300 unknown product code in EEPROM: 2104

UHD Warning:
   X300 unknown product code in EEPROM: 2104
Found  (HGS).

Burning image: C:\usrp_x310_fpga_HGS.bit

Progress: 100% (121/121 sectors)

Attempting to find device...
UHD Warning:
   X300 unknown product code in EEPROM: 2104

UHD Warning:
   X300 unknown product code in EEPROM: 2104
found!
Successfully burned FPGA image!

but i am getting these warning

x300 is not defined

also the tuned frequency is 000000MHz instead of have having a set target frequency.

usrp_x3xx_fpga_burner --addr=192.168.10.2 --fpga-path /home/XXXXXX/Downloads/uhd-images_003.008.001-release/share/uhd/images/usrp_x310_fpga_HGS.bit


Attempting to find device...
UHD Warning:
    X300 unknown product code in EEPROM: 2104

UHD Warning:
    X300 unknown product code in EEPROM: 2104
found!
Successfully burned FPGA image!


UHD Warning:
    Tune Request: 802.500000 MHz
      The requested RX frequency is outside of the system range, and has been clipped:
        Target Frequency: 802.500000 MHz
        Clipped Target Frequency: 0.000000 MHz
      Successfully tuned to 0.000000 MHz



Download All
0 Kudos
Message 5 of 17
(7,886 Views)

please find the attachment output of uhd_usrp_probe

0 Kudos
Message 6 of 17
(7,884 Views)

Hi junaid124,

 

A few comments.

 

First, next time you want to start a discussion about a new topic, please start a new thread on the forums.  This helps us keep our forums organized and track whether or not issues are solved or not.

 

So the error that you are seeing:

 

A runtime or configuration error occurred.
Code: 2410
Details: LookupError: Path not found in tree: /mboards/0/dboards/A/rx_frontends/0/sensors/lo_locked

 

can because for a few different reasons.  Have you removed either of the daughterboards from your X310?  I know I have seen this error when I try to install a daughterboard but no not get the connector fully mated to the motherboard connector.  This could also be caused by damaged hardware.  

 

Can you run uhd_usrp_probe and post the output?  That will help debug further because I'm not sure what in the EEPROM is programmed as 2104.  The output of uhd_usrp_probe will provide this information.  Did you change any of the EEPROM settings or know the history of this device?  Just as an FYI, even if the motherboard EEPROM product ID were to be accidentally changed to some unknown number like 2104, you will not get an error using the X310 over Ethernet with the NI-USRP host based driver.  The LabVIEW error you posted is from the daughterboard.  An issue with your daughterboard also explains the last error you posted.

 

Finally, if you would like to use the X310 with LabVIEW, please use the images found at C:\Program Files (x86)\National Instruments\NI-USRP\images.  UHD and LabVIEW are updated separately, so when you downloaded the images from the Ettus website, you downloaded a version that is not compatible with LabVIEW and can cause different errors.  If you are switching between UHD and NI-USRP, then you will need to change the images when you change driver APIs.  As you can see on the output of the NI utils on the command line, the version of the driver you are using is based on UHD 3.7.1, and looking at you images path, you are trying to run with images built for UHD 3.8.1.

 

Hope this helps to partially explain what is happening.  If you post the output of uhd_usrp_probe, it should be easier to figure out the root cause of your problem.

Sarah Yost
Senior Product Marketing Manager
0 Kudos
Message 7 of 17
(7,881 Views)

Sorry I didn't see your new post with the output of uhd_usrp_probe while I was typing my reply.

 

Based on that output, this is definitely a dboard issue.  If you look at this piece:

 

 RX Frontend: 0 
|   |   |   |   Name: Unknown (0xffff) - 0 

 

you can see that the one of your front ends is not able to be seen by UHD.  I would check to make sure that it is installed correctly.  As far as why your product ID is 2104, I have no idea.  But like I said in my last post, this should not cause an error.  It will cause a UHD warning, but LabVIEW should run fine.

Sarah Yost
Senior Product Marketing Manager
0 Kudos
Message 8 of 17
(7,878 Views)

Hi Sarah_Y,

 

Thanks for your quick response and I'll keep this in mind next time.

 

I haven't change any db I think the problem is bit file dispatched with NI USRP 14 is built for WBX 120 MHZ

But at the time I bought this device that was not available so the installed db is WBX40MHZ.

I haven't reprogrammed EEPROM you can clearly see in above attached pic of Xilinx impact.

I've change the bit file every time when I move from GNURadio to LabVIEW and so forth accordingly.

 

My few questions 

Is NI USRP 2940R is x310?

Is there any bit file for x310 with WBX 40MHz?

Is there any default SIP programming option like in N series?

 

Warm regards,

Junaid

0 Kudos
Message 9 of 17
(7,858 Views)
For clarification can you verify the following?

1. You are using x310 with 2 WBX-40 daughter boards or is this a 2940R? (Back label will say the model)
2. You are switching between FPGA images
- default shipping image (found in NI-USRP 14.0 driver)
- a different image you use in gnu radio
3. in LabVIEW Communications you using which driver?
- host based driver?
- or the project that allows fpga modification?
0 Kudos
Message 10 of 17
(7,849 Views)