Simple API question

STUPID STUPID STUPID… pointer problems… Must have been too late in the day and I could not see it.

I am reading the API document and I am trying to understand what I need to do to get the BB60C into zero-span mode.

Basically, I am wanting to try and decode that 2FSK signal I mentioned earlier using Labview. I have it now working with your demodulator using the clipboard copy paste. I also have it working with the raw IQ data now with the file save under zero-span. Next step is just to pull the data directly from the BB60C.

Also, I did not see anything in the API for triggers. Does this mean that the triggers in Spike were all at a higher level?

Yes, that was a big miss on my part.

With Spike being so rich in features, I wonder if you have considered adding a way for customers to hook into it rather than writing their own full blown programs. Ability to save the data to disk, post process the data from the demodulator, more advanced triggers would be very nice. In my case, if I use the demodulation, I have to use the clipboard to copy the binary data into a text editor, then save that to a text file where I can then do what I want and display it. It would be pretty cool to be able to do all this within Spike so I could leverage what you have written. Just a thought.

Thanks for the information on the triggers.

A few more questions about streaming the data.

Does the bbQueryStreamInfo need to be called prior to each call of the bbFetchRaw to know the amount of data sent, or will bbFetchRaw wait until the buffer is filled?

It seems to always send the same amount of data no matter how fast I make the call.

Is there a way to turn off the Q data stream and capture twice the amount of I data?

If there is no way to change the sample rate or increase the data length independently (aside from decimation) and it is up to the software to stich segments together, is there anything special that needs to be done to guarantee there is no loss of data between the segments?

The one you linked has the same revision in the release_notes.txt as the one I am using.

Yes, I saw the bbFetchRaw was deprecated. I was not sure with the bbGetIQ that it would buffer up the data.

Looks like stitching the data back together is the answer. I’ll give that a try.

Does the bbGetIQ have the same internal buffer size then? The document only seems to mention this with the bbFetchRaw.

I now have a similar video trigger as Spike where I wait for the radio to turn on before I start collecting the data. I then stiched multiple records together to form the packet. I then have my pattern trigger and decode the packet. This seems to work just fine. It’s pretty cool really! I am impressed!

Thanks for all the help.