I would like to use my USRP E110 to generate a wave signal at aspecific frequency . I want to use the USRP as a beacon to generate this signal . I think there is a way I can do it directly on the hard drive rather than GNU radio. Could any one help in this regard please.
Thanks
This question is very broad, and unclear. You say you want to use an USRP, but not GNU Radio. Also, what is the 'wave signal' you want to generate?
I suggest taking this to the usrp-users mailing list.
Related
is there a way to implement phase modulation and demodulation in LabVIEW(using NI USRP and without MathScript). I cant seem to be able to convert the block diagrams into useful circuits.
Any help is appreciated.
There is a free toolkit for this purpose https://www.ni.com/pl-pl/support/downloads/software-products/download.labview-modulation-toolkit.html#
I am working on a Free-Space-Optics transceiver that uses the soundcard of a computer, a LED, a photodiode and a lens to transmit data over the air. At the moment I am trying to connect two transceivers with the help of GNU Radio. The GNU Radio tutorials and examples that I know of, all cover USB radio devices.
I already experimented with software called Minimodem which uses Audio Frequency Shift Keying for data transmission over the soundcard. GNU Radio offers a lot of useful blocks like Automatic Gain Control (helpful for changing signals due to light and weather conditions) etc., which is the reason I would like to use it for my experiments.
I understand that using the soundcard as the interface is a limiting factor for the achievable data rate.
I would appreciate advice of how to setup a reasonable flow graph in GNU Radio companion that enables a data transmission between the soundcards of two computers. Thank you!
You essentially need two out-of-tree modules for your soundcard in the Gnuradio. one sink(for transmitter) and one source(for receiver). If you already have some code that can send samples to your sound card, just create an oot module and put it in that module. if not, then write a C++ or Python code that can do this.
The N210 is connected to the RF frontend, which gets configured using the GNU Radio Companion.
I can see the signal with the FFT plot; I need the received signal (usrp2 output) as digital numbers.The usrp_sense_spectrum.py output the power and noise_floor as digital numbers as well.
I would appreciate any help from your side.
Answer from the USRP/GNU Radio mailing lists:
Dear Abs,
you've asked this question on discuss-gnuradio and already got two
answers. In case you've missed those, and to avoid that people tell
you what you already know:
Sylvain wrote that, due to a large number of factors contributing to
what you see as digital amplitude, you will need to calibrate
yourself, using exactly the system you want to use to measure power:
You mean you want the signal power as a dBm value ?
Just won't happen ... Too many things in the chain, you'd have to
calibrate it for a specific freq / board / gain / temp / phase of the
moon / ...
And I explained that if you have a mathematical representation of how
your estimator works, you might be able to write a custom estimator
block for both of your values of interest:
>
I assume you already have definite formulas that define the estimator for these two numbers.
Unless you can directly "click together" that estimator in GRC, you will most likely have to implement it.
In many cases, doing this in Python is rather easy (especially if you come from a python or matlab background),
so I'd recommend reading at least the first 3 chapters of
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
If these answers didn't help you out, I think it would be wise to
explain what these answers are lacking, instead of just re-posting the
same question.
Best regards, Marcus
I suggest that you write a python application and stream raw UDP bytes from the USRP block. Simply add a UDP Sink block and connect it to the output of the UDH: USRP Source block. Select an appropriate port and stream to 127.0.0.1 (localhost)
Now in your python application open a listening UDP socket on the same port and receive the data. Each sample from the UDH: USRP Source is a complex pair of single prevision floats. This means 8 bytes per sample. The I float is first, followed by the Q float.
Note that the you need to pay special attention to the Payload Size field in the UDP Sink. Since you are streaming localhost, you can use a very large value here. I suggest you use something like 1024*8 here. This means that each packet will contain 1024 IQ Pairs.
I suggest you first connect a Signal Source and just pipe a sin() wave over the UDP socket into your Python or C application. This will allow you to verify that you are getting the float bytes correct. Make sure to check for glitches due to overflowing buffers. (this will be your biggest problem).
Please comment or update your post if you have further questions.
I am going to read the PC's music output and getting basic information (beat/tone/..) of the song played (then flash the lights accordingly etc). Can NAudio be used for the purpose and any samples? Sorry for this too general question at the moment.
TIA
-d
You can access your PC's output using WasapiLoopbackCapture. However, NAudio does not include a beat detection algorithm, so you'd need to find one yourself. There is a FFT class though which could be used to determine frequencies present.
Could anyone please explain to me what the bit packing blocks in Simulink do? I am currently learning programming, Simulink and control theory so I am not very proficient. I tried using the help windows in MATLAB and also googling but I haven't found anything that explains it well.
Based on the online researching, bit packing is used to condense data packets before they are sent to another block? This way, the program runs faster?
Also, in Simulink, what is the "Bit patterns:" box used for? For example, if I type {[0:7]} what would that mean?
Edit: Where should I go to learn more about this? Are there any good documents online?
Byte packing and unpacking is used mostly for communications between a xPC Target and another device, over Ethernet for example. If bytes are coming in, they can be condensed into other data types such as singles or doubles. Conversely, if you are sending out doubles or singles, often you need to separate them into bytes first.