09-23-2014 01:53 PM
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
09-23-2014 02:35 PM
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
09-24-2014 05:28 AM
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
09-24-2014 05:55 AM
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)
02-20-2015 12:31 PM
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
02-20-2015 12:37 PM
please find the attachment output of uhd_usrp_probe
02-20-2015 12:58 PM
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_loc
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.
02-20-2015 01:06 PM
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.
02-21-2015 01:40 AM
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
02-21-2015 07:05 AM