Two BB60C IQ streaming in the same process

Hello,

While trying to use two BB60C in the same Windows application, in IQ streaming mode, only the samples from the first started device are received. bbInitiate returns no error code, but neither bbGetIQ nor bbFetchRaw return any data or any error code for the second started device.
The test was done using API versions 3.0.11 and 3.0.14.

The same test on Linux, with API version 3.0.11, has the same end result. Even worse, on Linux even if used in separate applications the second started BB60C returns no IQ samples.

Any chance to get this fixed?

Regards, Catalin

Hi catalin_ro,

I am facing the same issues too with the new API and BB60C in a multi-instrument configuration. The older API has been more well behaved.

Infact, we had almost placed an order for several pairs of BB60C for a similar requirement. But now I think it will be worthwhile to wait and see if “multiple BB60C on the same host” issue can be resolved by Signal Hound.

To me it looks like an minor API issue. I hope it is taken care of soon.

rgds

Hello Catalin and rgds,

Looking into this now, will update you as soon as I can.

Regards,
A.J.

Hello Catalin and RGDS,

I have been experimenting with 2 BB60C receivers streaming IQ in the same process. My initial tests have both units streaming, and performing a basic average power measurement on all the IQ data, just to verify the power level on both devices are correct, and the data is valid. I am also verifying the sample rate is the one requested by dividing (totalSamplesReceived / elapsedTimeOfTest) and am seeing valid values.

Is it possible to be more descriptive when you say “bbGetIQ does not return any data”? Is it possible to send me a small C++ snippet which demonstrates this issue? You may contact me directly at
aj at signalhound dot com. I can even provide the snippet I have been using to test 2 streaming receivers.

If you guys are seeing issues with multiple device streaming, it would be nice to fix these issues. I think I’m going to need some more information at this point though, I have been unable to create a failure scenario.

I look forward to your responses and hope we can resolve the issue quickly.

Regards,
A.J.

Hello Andrew,

Based on your reply, I have re-checked the API manual (completely re-reading the first pages!) and came across the multi-threading related comment. That paragraph states that the API functions calls are not thread-safe and that they must be protected in the application.

Briefly said, my application has a C++ class that wraps all the required API functionality and provides all the multi-threading protection for one receiver. bbGetIQ/bbFetchRaw (depending on the API version!) is called from another thread that does only that.

When using two receivers, all management functions are called from the main application thread and the IQ buffers retrieving is done in two independent threads, one for each receiver. Do I have to add complete protection around bbGetIQ/bbFetchRaw so they are not called from different threads for different receivers?

Regards,
Catalin

[catalin_ro]

More to my reply…

I have been able to get it running in my application as well. In the end, after playing around connecting/disconnecting the receivers, I got it going as expected.

But, in the process, I have also seen the undocumented bbDeviceInvalidErr error code for the second receiver. While all other error codes have pretty meaningful names, this error code isn’t even documented as possible result by the API manual.

More to that, while that happened, I decided to see if the second receiver could still be used by another application instance. So I released if from the application instance that gave me the error and I had no problems starting it in a different instance of the same application.

To better understand what the application does, simply think of a radio monitoring software that allows defining hand-off receivers for the detected transmissions. I can dynamically define/undefine the hand-off receivers and I only have issues starting them. By undefining the application, I can start separate application instances for them and they always work as expected.

Catalin

• This reply was modified 8 years, 2 months ago by catalin_ro.

Hello Catalin,

It sounds like you found the source of the issue, which is that the API is not thread safe. In our software I always limit API function calls to one thread, so I can’t make any guarantees, but I believe each device could be interfaced in a different thread once open. The opening process itself is not thread safe, and you do not want to interact with one device from two different threads, for instance, don’t try to re-initiate a device from one thread when another thread is still retrieving IQ data.

The invalidDevice error that you are seeing would indicate corrupted memory and/or corrupted initialization sequence. My guess is that this is also related to thread safety. If you continue to see this issue, we might start considering corrupted internal flash memory/damaged traces/issues with microcontroller/etc.

rgds, You may contact me at the email in my previous reply if you wish, and are still experiencing issues.

Regards,
A.J.

[Author]

Posts