I have the attached simple flow graph in gnu-radio. I'm using two b200 mini SDR cards and both are connected to the computer. I want gnu-radio to run them both at the same time and I want to be able to compare their received signals at the same time.
Surprisingly, gnu-radio runs only one SDR card (with no errors) even though the graph clearly shows two. I can completely detach one of them and the graph runs with no errors. This of course not what I want because the graph seems to use one SDR card instead of the two.
I looked online for an example of using multiple SDR cards at the same time but didn't find anything helpful. I found a question with a similar flow graph on Stack overflow but wasn't able to comprehend the given answer.
I also found this question on stack overflow where I had two USRP sources each with Num Mbords = 1, and Num Channels = 1, but I had no luck.
Any help is appreciated, and thank you very much.
I was able to fix the issue by specifying the device serial number in the USRP Source block.
1- In terminal type uhd_find_devices then get the serial number of your connected SDRs. Assume they are A1B2C3 and 3C2B1A.
2- Double click on the 1st UHD: USRP source block, then in the properties window, put "serial=A1B2C3", then click ok.
3- Double click on the 2st UHD: USRP source block, then in the properties window, put "serial=3C2B1A", then click ok.
In this way both SDR cards will be used.
Related
I'm a newbie using LabView for my project. So I'm developing a program that gathers data from sensors that attach in the DAQmx board and also a spectrometer from STS-VIS ocean optic. At the first developing, I combine both devices in one loop inside the same flat structure, but I got an error saying: "The application is not able to keep up with the hardware acquisition." I cannot get the data showing on the graph for both devices, but it was just fine if I run it separately. And I found the solution saying that I need to separate both devices in a different while loop process because it may have different buffer size (?). I did it and it worked that all the sensors are showing in each graph. But the weird thing is, I need to stop the program first at the first run, then run it again for the second time for getting the graph showing in the application. Can anyone tell me what I did wrong and give me a solution? Due to the project rule I cannot share my Vi here publicly, but if anyone interested to help, I'd like to share it personally. Thank you.
you are doing right thing but you have to understand how Data acquisition work in LabVIEW and hardware.
you can increase hardware buffer Programmatically using property node or try to read fast as possible then you dont need two separate loop.
NI
I work currently with a NI DAQmx device too and became desprate using LabView because there is not good documentation and/or examples. Then I started to use Python which I found more intuitively. The only disadvantage is that the userinterface is not so easily generated, but for this one can use the QT Designer (open source programm avaiable online).
I have a four channel LED system where I'd like to control LED intensity and time-on for each LED separately- with specific number of iterations of this stimulus (see diagram below).
We're using an A/O module on cDAQ system to control each individual LED and zero frequency sine waves to set up the LED voltages (snippets attached) - each LED also has a specific 0V pre and post stimulus time. The LEDs need to have the same timing so that each waveform executes at the same time and the stimulus needs to be repeated several times (controlled by the front panel and a loop). Ive set up a subVI which ensures all the waveforms are of equal length (MakeWavelengthEqual(SubVI)) as well as one subVI to generate a digital output for the duration of the LED on time (TrigOutGen(SubVI)) to trigger out data acquisition equipment.
The VI creates these Waveforms and output them to each individual channel, whilst also repeating them. However I keep having an issue where the LED outputs don't quite correlate to the waveforms I've set up - and the final LED output repetition seems to create a situation where the LED stays on even after the VI completes its run. See VI below:
I'm new to labview so troubleshooting these issues is very difficult to me, I get no errors, the waveforms look correct when plotted and the task is set up to clear outside of the loop so I'm not sure where the problem with the final output occurs. I'd really appreciate any help anyone can provide.
I am using Mindstorms and build a Robot with two Motors and a IR Sensor.
1) I made a program which lets the Robot follow a IR signal and stops when reaching it.
2) I made a program to remote control the robot with the IR control.
Both program work. But when combining them, program 1 does not work anymore.
It gives eratic results from the IR sensor. It seams the detecting a IR-Button is not compatible with measuring the signal in the same program. Anyone has similar experiance or know how to deal with it?
This is the program which works:
Introducing another Selection around it which senses a IR Button does not work anymore:
The result is, that the program follows to the right section, but the IR measurements of distance and directions give random results.
Anyone has any Idea?
If you have already tried another sensor and there is still a problem it could possibly be a bug with the software. I would post your example on the the NI MINDSTORMS support board so that they can look into the bug.
http://forums.ni.com/t5/LabVIEW-for-LEGO-MINDSTORMS-and/bd-p/460
I'm using a USB-6356 DAQ board to control an IC via SPI.
I'm using parts of the NI SPI Digital Waveform library to create the digital waveform, then a small wrapper VI to transmit the code.
My IC measures temperature on an RTD, and currently the controlling VI has a 'push for single measurement' style button.
When I push it, the temperature is returned by a series of other VIs running the SPI communication.
After some number of pushes (clicking the button very quickly makes this happen more quickly in time, but not necessarily in number of clicks), the VI generates an error -200361, which is nominally FIFO buffer overflow on the DAQ board.
It's unclear to me if that could actually be the cause of the problem, but I don't think so...
An NI guide describing this error for USB-600{0,8,9} devices looks promising, but following the suggestions didn't help me. I substituted 'DI.UsbXferReqCount' for the analog equivalent, since my read task is digital. Reading the default returned 4, so I changed the property to write and selected '1', but this made no difference.
I tried uninstalling the DAQ board using the Device Manager, unplugging and replugging, but this also didn't change anything.
My guess is that additional clock samples are generated after the end of the 'Finite Samples' part for the Read and Write tasks, and that these might be adding blank data that overflows, but the temperatures returned don't indicate strange data, and I'd have assumed that if this were the case, my VIs would be unable to interpret the data read in as the correct temperature.
I've attached an image of the block diagram for the Transmit VI I'm using, but actually getting it to run would require an entire library of VIs.
The controlling VI is attached to a nearly identical forum post at NI forums.
I think USB-6356 don't have output buffers used for Digital signal. You can try it by NI-MAX, if you select the digital output, you may find that there is no parameters for Samples. It's only output a bool-value(0 or 1) in one time.
You can also use DAQ Assistant in LabVIEW, when you config Digital output, if you select N-Samples or Continuous samples, then push OK button, here comes a Dialog that tell you there is no buffer for lines that you selected.
We want to jam on 3G using our USRP 1 and GNU radio, is this possible ?
There are many ways to jam a signal, the easiest of which is obviously just to transmit over the signal you want to jam. Since USRPs can transmit, that essentially answers your question.
Please note, however, that transmitting (and thus jamming) signals in spectrum that you don't have permission to use is illegal in almost every country in the world. You will likely not get responses on how to do these things without giving details about what you are doing - nobody wants to enable illegal activity.
There are two ways to do this. The simple way is to simply jam the radio band in use. However, if you do this and the state takes exception, you have made it dead easy to find you. If you don't want to make high powered RF transmissions then you need to get a good book on UMTS and learn how a intercell handoff works when a mobile phone passes from one cell to the next. You could broadcast handoff signals causing user equipment to attempt to change cells. Since the new cell actually isn't expecting the user equipment the changeovers will fail and the phones will effectively jam each other.
If I were you I wouldn't do this without written official permission because harder to find isn't the same as impossible to find.