jgauthier,

80% is a good number to use across the board. I will say, there is a trick you can use to ensure you are always getting the maximum available bandwidth. If you simply set the bandwidth equal to the sample rate (100%), then after you configure the receiver you can call the bbQueryStreamInfo function, and it will report the bandwidth that was actually used by the API. It will internally clamp to the upper bound for each given decimation.

The maximum bandwidth for any given decimation was calculated by looking at the decimation filters available at each decimation stage and making a decision about what cutoff frequency is going to give us the performance we need at that given rate.

Regards,
Andrew

Hi jraymond,

I have heard reports of this as well. We haven’t used or compiled the HDSDR project in a few years. I believe some customers have got this working by recompiling the project against the latest BB60C API. There have been hardware changes since our last HDSDR release such that the newer APIs are needed to interface BB60Cs. You could try dropping in the latest BB60C API to see if that works.

I’m not sure when we will swing back to this project. Maybe some other customers here could make some recommendations.

Regards,
Andrew

Hi Volker,

Thanks for the bug report and feedback. We are aware of this issue and have implemented a fix for this to be released in the next version of Spike. I apologize for the inconvenience. This issue was created when we introduced the new sweep plot scaling/zoom features. As you noted, this is limited to the display only, the testing on the limit lines remains unchanged. I can get you a link to a previous version of Spike if desired, or you could wait 2-4 weeks for the next release?

I look forward to your response.

Regards,
Andrew

[Andrew]

Jon,

Here is some code to get this going.

First, you will want to ensure you configure the external port to accept a rising edge (or falling) external trigger.

calllib('bb_api', 'bbConfigureIO', handle, int32(0), int32(64));

The best time to call this would be right after opening the device and only once. The 64 is taken from the header, it is the value for BB_PORT2_IN_TRIGGER_RISING_EDGE (0x40).

Then you will want to create a trigger array and count just like the iq data.

% Trigger parameters
triggerptr = libpointer('int32Ptr', zeros(4, 1));
triggercount = int32(4);

In this instance I am creating an array of 4 integers to store trigger positions. If I am only expecting 1 trigger, then an array of one will work fine.

Now I need to call bbGetIQ with these new parameters.

status = calllib('bb_api', 'bbGetIQUnpacked', handle, ...
         iqarrayptr, iqcountint, triggerptr, triggercount, purgearg, ...
         nullptr, nullptr, nullptr, nullptr);

And pull out the array when it returns

triggers = triggerptr.Value;

If a trigger occurred during this capture of I/Q, you will see it in the trigger array.

disp(triggers);

Might show

230722
        0
        0
        0

Meaning an external trigger event occurred at sample index 230722 (zero-based).

Regards,
Andrew

• This reply was modified 5 years ago by Andrew.
• This reply was modified 5 years ago by Andrew.
• This reply was modified 5 years ago by Andrew.
• This reply was modified 5 years ago by Andrew.

Thanks for the clarification.

Yes, you would need to call the vsgSubmitTrigger function from Matlab which you should find easy if you glance at the other wrapper code in VSG60 matlab class.

You could create a loop like this

while(forever) {
vsgSetFreq
vsgSubmitTrigger
vsgSubmitIQ(your_iq_cw_array)
}

The trigger is submitted inline with any other function calls to the API.

Hope this helps.

Regards,
Andrew

JGauthier,

You will need to write a dedicated function for that. A wrapper function around the GetIQ functionality should be adequate for performing any triggering on the I/Q data. You could perform video or external triggering with this function. (you didn’t specify trigger type in your message) If external triggering, there is a C++ example showing you how to detect an external trigger event, you would need to then align your capture on the trigger position and collect any additional samples required (with purge disabled to ensure continuity)

The API does not perform any triggering for the user, only provides the facilities for triggering to be performed.

Let me know if you have specific questions as you work through this.

Regards,
Andrew

[Andrew]

Hi Jgauthier,

This is a good question. The reason this is called twice has less to do with the purge parameter, and more to do with wanting to discard the first chunk of I/Q samples in the stream. Your assumptions about the purge parameter are correct. There are potentially several FIR filters (depending on settings) that are in the signal processing chain when I/Q streaming. These filters take hundreds/thousands of samples to ‘charge’ and until they do, the I/Q samples will not be amplitude accurate. By calling the function once with the purge parameter, this ensures that the first large segment of I/Q samples subject to this charge time are discarded. This is not necessary, but if you do this, doing this only once after each configure is adequate.

Another interesting component of this, the first call to GetIQ might not purge any samples, as there may not be any samples collected yet on the PC. So the worst case scenario is that the first call is just waiting until some samples arrive on the PC, and the second call is the one that actually purges that first chunk of I/Q to arrive.

Feel free to try just 1 call and see if that affects your application.

Also, waiting some small amount of time (100ms) before calling getIQ after configuring the receiver would ensure that the first call to GetIQ purges the first samples.

We chose to give these samples to the user instead of discard them in the API as they could still contain information just at a reduced amplitude.

If you are using any sort of triggering to acquire your waveform, calling the function twice is probably not necessary.

Regards,
Andrew

• This reply was modified 5 years, 1 month ago by Andrew.
• This reply was modified 5 years, 1 month ago by Andrew.

Hello Ewald,

I believe the VSG60 would be able to meet the AWGN requirement, but not the 2FSK requirement (at least with the included software). The minimum symbol rate for 2FSK will be 4kS/s on the VSG60. If you need to go lower, you would need to create your FSK waveform as an oversampled arb file and load it as an arb waveform.

You could use the VSG25, but you would need to use a multi-tone signal to simulate AWGN or create your own arb waveform for AWGN. The VSG25 also has no reconstruction filter on the DAC which will create images that might interfere in adjacent bands. Similar restrictions on the FSK signal for the VSG25 as well, except the VSG25 has only a 2k waveform size limitation, whereas the VSG60 does not. Since you will need to oversample the waveform the full waveform won’t fit in the VSG25 arb memory buffer.

The VSG60 software generates AWGN. In some configurations you might see a spurious signal. The picture below at 1524M shows an example spur as well as the adjacent channel performance of 1MHz AWGN channel. I also include a screenshot of the VSG60 software for this configuration.

Let me know if you have additional questions.

Regards,
Andrew

Attachments:

You must be logged in to view attached files.

Hi Dhivagar,

Yes, the BB60C is capable of a 27MHz real-time bandwidth in all of the frequency bands you listed. The BB60C has a 27MHz bandwidth at all center frequencies >= 20MHz.

Regards,
Andrew

Quadsat,

You can enable a channelizer in Spike to basically perform channel powers through the entire sweep before recording. You can select your channel bandwidth. Is this the functionality you need?

Dhivagar,

We recommend the use of the BB60C over the SA44B for pre-compliance measurements.

Regards

Hi Volker,

Thank you for the feedback. I think you might be interested in the peak table functionality. You can find it in the control panel along the bottom of the application in sweep mode. You can activate up to 16 peaks on the screen and measure freq/ampl deltas between those peaks. It sounds like this would satisfy your measurement requirements.

We are also looking into a dedicated intermod measurement in the future. Keep a look out in coming releases.

Regards,
Andrew

Hi Karlist,

I mirrored your settings in the latest version of Spike and saw a similar sweep time. Neither EMC precompliance or BB60C functionality has changed recently in a way that would affect the sweep times as you are seeing.

The biggest factor in sweep time for the given settings is the dwell time. You will notice that decreasing dwell time has a drastic effect on sweep speed. If somehow the dwell time has changed since you last performed this measurement, that could be the cause.

If you remember updating Spike from a much older version recently, that would be interesting to know. If it is possible to determine that older version of Spike, I could investigate that further.

Regards,
Andrew

Hi Flo,

It looks like we use the default print resolution which is 6 digits after the decimal. I can look to change this in a future release to print more digits after the decimal, or change the units to Hz.

I apologize for the inconvenience.

Regards

Mikeh,

Which one of our spectrum analyzers are you using? I will try to reproduce this with your model specifically.

Mike,

If you are not currently using the latest version of Spike, is it possible you could update to determine if that is why this is not working for you? I am seeing success with this in Spike 3.5.5.

Regards

Hi Mike,

Yes, the reference level offset is saved in presets. If you save a preset with your desired reference level offset, you can quick load it next time you launch the software using the ctrl+N shortcut.

Regards

Hi Joe,

The v2.12.00 driver you are referring to is for the SA and TG devices. It does not affect the BB60C device. The BB60C USB driver is installed during installation and has not changed since release of the BB60C.

Again, if you would like to dig deeper into this issue, feel free to email me.

Regards,
Andrew

[Andrew]

Hi Joe,

Which version of software did you update from? The last couple of versions have not introduced BB60C changes.

Can you provide a screenshot of the frequency offset including all settings? I can try to recreate the issue on my end.

We haven’t introduced a frequency offset setting yet in Spike.

The reason you see the “To Center” behavior is because the RBW is changing as you decrease the span. The frequency accuracy is subject to the RBW. As you decrease span, the frequency accuracy gets better, which is why you see an offset as you decrease span.

Feel free to follow up with me via email and we will look at your BB60C frequency offset issue.
aj at signalhound dot com

Regards

• This reply was modified 5 years, 3 months ago by Andrew.

Hello rcidade,

You will need some software to generate or receive protocol specific waveforms. We are not familiar with DMR standards.

You might review some of our third party software vendors to see if they provide the functionality you require. I would start by looking at the Decodio software.
https://signalhound.com/support/third-party-software/

Regards,
Andrew

[Author]

Posts