Attempting to use new Simulink blocks

Discussions related to embedded firmware, driver, and user mode application software development
Post Reply
gaprice2354
Posts: 10
Joined: Sun Apr 20, 2014 8:22 am

Attempting to use new Simulink blocks

Post by gaprice2354 »

I would like to start off saying that its great to finally have Simulink support for the BladeRF. I was in the middle of having to implement my models in VHDL and was losing a lot of time on my current project. That being said I have yet to be successful in using the new toolbox blocks.

Has anyone attempted to implement anything from a simple loop back setup to anything more complex in Simulink. I have been modeling with Simulink for about 7 years now and now the program well but have never utilized it for HIL testing. I have a model of a DSCDMA transceiver that I would like to connect to the bladeRF sink and source and do a loop back to see that I'm correctly receiving the signal before I test it in a channel.

So far I receive nothing and whenever I run the model I get a command window out put saying the TX gain set to 0 dB no matter what I set it in the block to be. I am using the internal firmware loopback currently although I have tried all internal and an external with attenuator in line so as not to damage the RFIC.

Has anyone had success here. I can provide a the .mdl if needed, but if anyone has a working example of any tx/rx setups that would be great so I could see if maybe I have a hardware failure. I have don't have signal generator or spectrum analyzer handy to try and trouble shoot. I have access to them but they are 9 hours away back at my university. It would be nice to rely on the blade to be my sig gen/analyzer

-Using both Windows and Linux so support on either is fine. I have updated to the latest firmware as well.

Thanks for any help

-Greg
robert.ghilduta
Posts: 156
Joined: Thu Feb 28, 2013 11:14 pm

Re: Attempting to use new Simulink blocks

Post by robert.ghilduta »

Hi Greg,

The TX (bladeRF_sink) block has some issues we are looking at.
Just to make a quick point, what sampling rates are you trying to achieve? I would suggest not going past 1.5MSPS because Matlab has a hardtime keeping up with the radio when producing samples.

Does the demo MDL work for you? https://github.com/Nuand/Simulink-MATLA ... e_demo.mdl

-Rob
penguinyaro
Posts: 1
Joined: Sun Feb 08, 2015 7:55 pm

Re: Attempting to use new Simulink blocks

Post by penguinyaro »

I was trying to do something similar-- create a source sink loop in MATLAB.

This is my program (can't upload the slx or mdl)
flowchart.png
I am able to run either the source or the sink part separately with no problems, but when I try to run them together, I get the following error:

Code: Select all

Error reported by S-function 'bladerf_source' in 'bladerf_simulink_Test/bladerf_source':
Failed to open bladeRF device #0
I assume this has something to do with the fact that bladeRF can only be opened by one controller(sorry if wrong terminology) at a time. Is there some way to get around this?

When I use grc, I can execute a similar program to the one I desire without this issue.
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: Attempting to use new Simulink blocks

Post by jynik »

I assume this has something to do with the fact that bladeRF can only be opened by one controller(sorry if wrong terminology) at a time. Is there some way to get around this?
If each block instance is trying to get a device handle via bladerf_open(), then the first one to complete will get the handle, and the second block will likely encounter a "no device" or "device busy" error.

The way the gr-osmosdr code gets around this is by maintaining and using a static cache of open device handles, as you see here. If a gr-osmosdr block in the process tries to "open" the device after another block has already opened it (for instance, a sink block after a source block has already opened the device), the device handle will be fetched from the device cache.

I'm not too familiar with the workings of the MATLAB/Simulink code and mex, but it seems to me that the code would need to be updated to take a similar approach, if possible.
Post Reply