How are Rx Samples Received in the Source Code?

[mbadders]

Hi,

I've actually deleted a previous post (posted in Software) in order to ask this question a better way - and I think it's probably more relevant to troubleshooting.

When I currently receive samples, I use bladerf_dev(), which allows so many samples to be received (eg, n=5000).

I was wondering how I would continuously receive samples? For example, if I wanted to continuously output these samples to an IQ Plot?

The reason I ask is that calling the bladerf_dev(RX) function repeatedled (e.g. in a loop) seems to cause the samples not to be flushed properly, meaning that you end up receiving old samples. I can see this happening as when I receive a transmitted signal, then turn off that transmitted signal, the bladeRF continues to receive it!. This perplexed me to say the least

NB: I'm currently using Simulink/Matlab. Is this something that needs to be done via the C code underneath the Matlab layer?

Cheers,


MB

[mbadders]

Ok, so I've kinda figured this one out for myself - although if someone could explain to me why it works this way that would be great!

(Using Matlab)
Step 1: bladeRF is opened, and a receive command (data = bladerf_dev(h, 'RX', sps, bw, c_freq, [lna rxvga1 rxvga2], n=1024);) is sent to the device.
Step 2: bladeRF receives samples, and these are stored in a buffer (holding 1 second * sample_rate maybe? I'm not sure on this... Can anyone clarify?)
Step 3: If you send another receive command to the device (where n=1024), samples are taken from the head of this buffer. New samples are received at the tail of this buffer. Even if, for example, you change the frequency, you will still be picking up the old samples until all of these old samples have been taken from the buffer (which is why I was still picking up transmissions that were no longer being transmitted.

In order to see changes in the signal you need to increase the number of samples you take in Matlab with each bladerf_dev() request

So there we go! I'll post the matlab code when I'm done, but if anyone can shed some more experienced/detailed light on the matter I'd be quite grateful.

Cheers,


MB

[poi]

Hi,

I've actually deleted a previous post (posted in Software) in order to ask this question a better way - and I think it's probably more relevant to troubleshooting.

When I currently receive samples, I use bladerf_dev(), which allows so many samples to be received (eg, n=5000).

I was wondering how I would continuously receive samples? For example, if I wanted to continuously output these samples to an IQ Plot?

The reason I ask is that calling the bladerf_dev(RX) function repeatedled (e.g. in a loop) seems to cause the samples not to be flushed properly, meaning that you end up receiving old samples. I can see this happening as when I receive a transmitted signal, then turn off that transmitted signal, the bladeRF continues to receive it!. This perplexed me to say the least

NB: I'm currently using Simulink/Matlab. Is this something that needs to be done via the C code underneath the Matlab layer?

Cheers,


MB

Hi mbadders,

I'm wondering how can I receive real time iq samples too. I'm using bladeRF-cli command promt to receive iq data. Then, I'm working on the csv file in Matlab. Now, I need to automatize receiving samples. Is there any progress in this issue?

[mbadders]

Hi, yeah sorry I forgot to check the thread when I saw someone posted

Righty, so if you are using the client then I think you need to also use something called baudline

https://github.com/Nuand/bladeRF/wiki/b ... g_RXd_data

Now I didn't use this personally, however, if you click the link above there are some instructions for "Live Viewing", and I think this is kinda the road you need to go down.

Aside from that there are a couple of different ways to stream the data as it comes in (though please correct me anyone if what I'm saying is incorrect):

1: Save data to a bin file and then use another program to take data from that bin file. I don't know if you will have multi-access issues here, and I don't know what you would do about limiting the size of the file (I think the cli actually has a limit you can set), but I'm pretty sure with a bit of jiggery-pokery this could be viable. I think this is basically what baudline is doing.

2: You can use libbladerf.h directly and use the functions there in your c/c++ code.

3: In terms of the easiest approach, I would recommend getting familiar with gnuradio and using the OsmoSDR sink/source setup. This is what I ended up using in the end as gnuradio basically processes samples as fast as your clock speed, so they are constantly coming in. On top of that you get all the additional functionality that gnuradio provides, and it's very easy to build your own python/c++ blocks in order to extend it for whatever specific task you are doing.


So yeah, long term I'd recommend no. 3

I hope this helps!


MB


----- edit ------

So I just saw you're using matlab. Now this is where I kinda got stuck as I couldn't get matlab to process the samples fast enough. Again, I'd still recommend no. 3, but if you absolutely must use matlab then probably saving to the bin and then getting matlab to read from some sort of queue is your best bet (option no. 1). It depends on your experience / time restraints really. You can build a pretty sophisticated system in gnuradio without knowing a scrap of code though.