Hello tuantuanlee,

You will need to use some sort of system audio API to play sound. We use the Windows waveout API in Spike to play audio, but there are many options.

Regards,
Andrew

Hi Gary,

Thanks for the request. In our next release we will be adding more and better ways to adjust the scales for our plots. I will see if we can enable it for this particular plot. Thanks again.

Regards

Athanasios,

vrtGetTime is unrelated.

I would start by beginning with the example SHR parser files found in the SDK. If you don’t have the latest SDK, download it from here.

https://signalhound.com/software/signal-hound-software-development-kit-sdk/

I would start by simply compiling, running, and examining the parser example and then modify it from there once you get it running.

If there is any concern that the file has been modified since it has been saved from Spike, I would regenerate a new sample recording file.

Regards,
Andrew

[Andrew]

Nick,

If you play this file back in Spike does Spike show the correct time? You can see the time displayed for each sweep right under the playback scrubber bar.

Yes, I have verified the timestamp is being set properly in the latest version of Spike (3.3.0). I have lots of files from previous versions that all appear to have valid time stamps.

I suspect your python parser is either reading this value incorrectly or is aligned improperly?

The time is in milliseconds since epoch where epoch is defined as 1-1-1970. Here is a website that shows the current millis since epoch. https://currentmillis.com/

Regards,
Andrew

• This reply was modified 6 years, 4 months ago by Andrew.

Hi Gary,

Two finger swipe up/down usually emulates mouse wheel up/down on modern laptops.

Regards,
Andrew

Hi Gary,

You can also scroll the mouse wheel in the same location where you click/drag the y-axis and this will also change the scale.

Regards

Hi Bittware,

You are correct in your assumption.

Hello Bittware,

SYST:PRES? will return 1 on success. It will power cycle the device, which will result in the LED turning off for a brief period. For most of our devices solid green indicates on and ready (but not active), while when actively making measurements you will see orange/red. Since preset will power cycle the device and return to power up conditions in the software, the device will be actively sweeping after preset and you will see red/orange LED.

I hope this helps.
Regards,
Andrew

Hello Athanasios,

What times are you seeing? As you noticed, the time is in “Milliseconds since epoch” which ~1557420094000 right now. Is this the number you are seeing?

I’ve always used the %llu print format specifier to print 64-bit uints, is this the possible issue?

Regards,

[Andrew]

Hello Romanya,

Usually when a customer sees this, it is due to an incompatibility with our software and the current GPU/GPU driver. The first step is to look up the GPU in your system and look on either the PC or GPU manufacturers website for any driver updates. If that does not work, send an email to support@signalhound.com with information about your PC, and we will see if we can work through it.

Regards,
Andrew

• This reply was modified 6 years, 4 months ago by Andrew.
• This reply was modified 6 years, 4 months ago by Andrew.

Hello Dhivagar,

I have seen your email with this question and have passed it along to Justin who will have more insight.

Regards

[Andrew]

To ensure the least amount of data loss over USB elevating the thread priority is the best(only?) way we have found to do this. As far as I know root privilege is required for this on Linux (not the case on Windows).

With multiple devices actively making measurements, you will experience data loss if this isn’t done.

I had another customer do a bit of testing with niceness levels and it never resulted in an adequate solution. (His processing would still swamp the CPU and cause data loss events while I/Q streaming despite using niceness levels and despite pulling his processing out into separate processes.)

Below is the snippet we use to do this. You are free to play around and determine if one of your solutions will work. The result of the pthread_setschedparam() will indicate when it fails due to privilege issues. We don’t push this status back out to the user, but I have a request to in a future update. That way the user can ensure the API is setting the proper priority. The API doesn’t check (or care) if it fails at the moment.

void ElevateThreadPriority(std::thread &t)
{
pthread_t this_thread = (pthread_t)t.native_handle();

struct sched_param params;
int tp = 10;
params.sched_priority = tp;

int res = pthread_setschedparam(this_thread, SCHED_FIFO, &params);
}

• This reply was modified 6 years, 4 months ago by Andrew.
• This reply was modified 6 years, 4 months ago by Andrew.

Kaiser,

Email justin at signalhound dot com with your model question. We might have something that could help.

Regards

[Andrew]

Kaiser,

We have several customers running multiple SM200s on a single PC. I’m aware of one customer running 4 SM’s streaming I/Q.

You are correct in that the biggest issue is generally USB throughput, but we have found that 2 SM’s will run just fine on a single PC (higher end desktop). You only really need to consider USB adapter cards above 2 SM’s.

If you are on Windows, everything should just work out of the box. If you are on Linux, take a look at the appendix in the latest API manual. I have some notes for multi-unit use on Linux.

How much processing power you need it really going to be dependent on what type of processing you add to the system. A standard 4 core PC will run 2 SM’s if you did not perform any processing.

Regards

• This reply was modified 6 years, 4 months ago by Andrew.

Hello,

We don’t have a function in the API that directly provides you the measurements that the “Measuring Receiver” does from Spike. I can tell you the general idea behind the it though.

You could reproduce it with the API by using basic sweep functionality with the flat-top window (default) and finding the peak value in the sweep. Reference level would then be used to adjust the sensitivity of the receiver as you adjust your input level to the receiver. You would want to measure the offset before and after a ref level change and include that offset in your final calculation.

A lower RBW on the sweep would get you finer frequency resolution if needed.

Let us know if you have additional questions.
Regards

The sample rate at 27MHz is 40MS/s I/Q.

Yes, you are correct about the step size in the playback box.

Another alternative is to use the spectrum settings to control which part of the capture is shown in the spectrum plot. If you set the offset to two different values and then calculate freq/time you could get a sweep rate. We are making improvements to this as well in the next release which should simply this process even more.

Regards

Hi Charles,

Not automatically, but could you use something like the FM vs Time plot in Zero span to calculate the time delta between the begin/end of the sweep, or maybe freq/sec? I set up a swept multi-tone signal here to try to recreate your signal. I added the FM vs Time plot plus the upcoming waterfall plot in zero-span (next release). In both plots you can see the sweep time and could calculate the sweep rate.

Regards,
Andrew

Attachments:

You must be logged in to view attached files.

Jordan,

It sounds like Spike is off screen. I’ve seen this happen when a user goes from 2->1 monitors or changes their monitor config.

You can reset the Spike default starting position by deleting the file at

C:\Users\AJ\AppData\Roaming\SignalHound\Layout.ini

Replace AJ with your user name. AppData is also a hidden folder, you will have to “Show hidden folders” to see it. Do this with Spike closed and relaunch, it should recenter the app.

There are also Windows shortcuts that move windows in focus around. If you alt-tab to the application, you can used Windows Key + (up/down/left/right) to move windows around.

Let me know if this works for you.
Regards

Quadsat,

Spike does some minimal checking of the format to verify that it can parse it.

– It checks the file signature, if you have managed to alter it in the process of parsing the file yourself, this could cause it.
– It checks the SHR file version. The current version of the Spike software will parse file versions 1 and 2.

Up until now, we have stayed backwards compatible, meaning files generated in older versions of the software can be parsed in newer versions of Spike, but older versions of Spike will not be able to parse the newer versions of the SHR files. Is that the possible case here?

Regards,
Andrew

We do not have plans to develop a Linux API for the VSG25A at this point.

Regards

[Author]

Posts