- This topic has 1 reply, 2 voices, and was last updated 9 years, 8 months ago by
.
- Posts
Hi,
I have seen the sample programs in the BB60 API manual. All of them set up some parameters, call bbInitiate, and then call a data retrieval API like bbFetchTrace before closing the device. I want to know if the retrieval API can be called repeatedly in a loop after a single call to bbInitiate ? If this is not possible then there would be an unacceptably large delay if the bbInitiate had to be called within the loop.
This question may sound naïve but I bought a PicoScope USB oscilloscope device only to find out that it requires the equivalent of a (long latency) initiate call before each data retrieval API call. That really makes user written software run at a much lower rate than the hardware is capable of. Only the vendor supplied software exploits the full hardware capacity. I want to know if that is the case with the BB60C too. I saw another post on this forum which said there is a 1 second delay for changing the center frequency in I/Q streaming mode. Why this long latency ? Does it require a call to bbInitiate ?
Also, I have not been able to a find a GNUradio interface for BB60C. Is there GNUradio support being planned ?
Thanks for any info,
–Patrick
Hello Patrick,
Good questions. To start, no, the bbInitiate function does not need to be called for each data acquisition. If you use the initiate function to configure a particular sweep, you may continue to acquire sweeps until you call the bbInitiate function again. bbInitiate must be called to change configuration though. If you are sweeping, the bbInitiate function is nearly instantaneous (no hardware involvement is required). Most of the work done is pre-allocating memory and processing classes. So even if you need to rapidly change sweep parameters this will appear instantaneous. If you are streaming I/Q data, the initiate function takes about 17ms using BB60C firmware version 6, and ~750ms using firmware version 5 or less. The long delay for firmware version 5 is due to inefficiencies in shutting down the data stream to the PC. We have very recently corrected this and released it as a firmware update (ver 6). New units will ship with this, and old units can upgrade. You must be using the latest API to get the low I/Q switch speeds. (API version 3.0.6)
Our spectrum analyzer software uses the same exact API we provide users.
Regarding GNURadio, currently we do not have support for it, nor do we plans for building the necessary interface. We would love to, but we have limited programming resources.
Regards,
A.J.
You must be logged in to reply to this topic.