Hello,

As you’ve noticed, the SA44B ARM packages in the SDK are located in the “obsolete” folder. This is because we have obsoleted/deprecated these versions of our APIs and no longer support them. We recommend Windows only due to the limitations which you can read about in this thread.

Regards,
Andrew

Hello Sachin,

You can see the Spike user manual at the link below. I apologize for the inconvenience.

https://signalhound.com/sigdownloads/Spike/Spike-User-Manual.pdf

Regards,
Andrew

Our APIs are not open source. Additionally, the FTDI library is only used in the BB60 API for the tracking generation compatibility. The BB60C itself uses libusb for USB 3.0 communication. The BB60C has a complex and proprietary protocol that we do not publish.

Regards,
Andrew

Unfortunately no progress on this.

Regards,
Andrew

Hello asvol,

Unfortunately, the BB60C is not compatible with ARM architectures and cannot be easily ported. For the time being, our devices remain x86/x64 compatible only.

Regards,
Andrew

Gary,

It looks like cmake isn’t able to find the necessary files it needs for our OOT modules.

What have you tried so far? Have you searched this issue and tried any of the troubleshooting steps found online?

Here are some hits that look relevant.

https://github.com/daniestevez/gr-satellites/issues/15
and
https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00174.html
and
https://github.com/daniestevez/gr-satellites/issues/37

Regards,
Andrew

Hello Idan,

There is no I/Q data in the SHR files, only sweep data. (Ampl over frequency data). We provide a SHR parser project that will show you the format of the SHR files. This parser project is located in our SDK, which you can download at the following link.

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

Regards,
Andrew

Hello Ton,

Signal Hound doesn’t provide any software that will run natively on Mac. Additionally, many customers experience issues when using a VM. This is mostly related to the high USB throughput nature of our products. In some cases, there might be VM settings related to USB that might help alleviate USB interruptions and data loss that results in device disconnects. Otherwise we recommend running Windows natively.

Regards,
Andrew

Hello Jolugome,

The BB60C is not compatible with the RPi. It is only compatible with x86 systems (Linux (API only) or Windows). We had support for running the SA44 on the RPi2 in the past, but no longer support this API due to USB throughput limitations.

Regards,
Andrew

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 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 ago by Andrew.
• This reply was modified 6 years 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

[Author]

Posts