Forum Replies Created
- Posts
Are you trying to use a 32-bit API with a 64-bit version of Labview?
I just tried it with LV64-bit 2020. Similar errors you show. Followed their instructions and seems fine.
2.2.3.2 Windows with 64-bit Labview
C:\Program Files\National Instruments\LabVIEW 2016\instr.lib
In the Signal Hound driver folder, you will need to rename the 64-bit DLL and either delete or rename the 32-bit DLL.
For example, for the BB series, rename bb_api.dll to bb_api-32.dll, and rename bb_api-64.dll to bb_api.dll.Hello,
I had asked about providing support to Spike for external down conversion several years ago. Looking at the latest version of Spike, it still doesn’t provide support. It would seem like an easy feature to add and would save me a lot of time.
I would expect to provide the LO, the sideband, mixer loss (or maybe a way to calibrate it).
Shown is a down-convertor for the X-band, using a 12GHz LO. For a quick demo, a LiteVNA64 was set to 5.9GHz and measure directly with the BB60C. Next the LiteVNA64 was attached to the down convertor and set to 6.1GHz. 12 – 6.1 = 5.9. Also shown are the two overlaid.
Maybe the person uses a 6GHz LO with the upper sideband, or 6.1 – 6 = 0.1G for the previous example.
Both the down converter and BB60C are referenced to my GPS. That bit of drift is the from the LiteVNA64.
I had been using the 64-bit 3111 with driver v2.12.00.
It odd as the unit has been very stable since I was able to get it running. I went to try to repeat the test and the software could not find the device. I have not seen this since I first bought the unit.
I tried it a few times and pulled the cable which I never have to do anymore. Eventually, it did located the device and started working. I rolled the drivers and software back to 3111, then tried to use the GPS reference that is used for all of my other equipment. I select the DC option and its now 992KHz off. I would expect it to be within 1Hz.
Whats really odd the more that I look at it, even using the internal oscillator, it seems to hop around. I’m not normally using it for narrow band work and maybe it always behaved this way.
Oh well, it seems like it’s back to being stable. Good enough.
What version of Labview are you using?
Do you have a specific question? You may want to upload your code that you are having problems with.
If you are just looking for a general idea how to do it, the SA example is where I started. API manual is good enough. I really have not seen too many problems that were not related to lack of sleep.
Andrew, I swapped the board out for the second one. It too has been solid. Not a single glitch and I am using the hub and extension cable as well. The BB60C has been in use a fair amount. It seems the Dell’s USB ports may just not be as clean. I guess you could buy the same PC and see if you could replicate the problem. Maybe there would be a way to allow the BB60C to auto recover. Attached my latest video with Labview. Things are a little cleaner and I have a much better understanding how to use the API now.
It did end up hanging the same way a couple of times after this last change. As a last ditched effort to get the BB60C more stable, I bought two new PCIe USB cards. One is a GIGABYTE GC-USB3.1. The car has been in the PC for a couple of weeks now and I have been using the BB60C a fair amount. So far flawless. This is with the extension cable and ANKER hub. I attempted to run a TV tuner in the same hub and even with that tuner active along with the BB60C, not a single crash. In how it hangs, I suspect there is some sort of error that is not being handled in the BB60Cs firmware and that the new boards signal integrity is just better than what was included with the Dell so the error no longer occurs. It will be a few more weeks before I call it good, but this is a huge improvement.
Video showing my BB60C running with Labview. Skip to the end if you just want to see the final result… Again, thanks for the help.
https://www.youtube.com/watch?v=f1UtLpSZ2W0&feature=youtu.be
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.
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.
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?
Looking at the return values of the bbQueryStreamInfo, the maximum length I seem to be able to return is 524288. I also seem to be unable to change the samples per second which is always 40M. So I basically have to stitch the data together.
Is there a way to decrease the sample rate or increase the length?
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.
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?
Thanks, I will triple check my work. So far, of the 12 functions I have tried it’s the only one that seemed to have a problem. I am using LabVIEW 2011. Do you have this available for testing?
I had installed 2.70 along with their latest support files and it has worked flawlessly. I am also using Windows 10 Pro. Strange.
I saw this same symptom with my brand new Dell desktop early on as well. I suspected it had something to do with how much power I was pulling from the ports but I really am not sure. I changed the ports I was using and removed everything but my mouse and keyboard and this problem went away. I since started running it from a powered hub and this seems to work fine for the most part.
Looking at the data a little closer, it appears it is actually 2.4K, not 1.2. I had assumed the preamble was 101010… With 4X I can see the data. There is no way to scroll the symbol table which would have been nice. Also just adding a way to post trigger (pattern search) and decimate the data would be helpful.
This makes sense. Yes, the signal is +/-12KHz at 1.2K BAUD.
If I record say a second of data in zero span, it looks like it’s all there. Which leads me to believe that is really is a limitation of the software and not the hardware.
I am curious why there is a limitation like this? It looks like you are pretty close to being able to just pull the digital data directly. Of course, then I would want to store the digital data rather than the copy to the clip board.
