Thank you for the detailed response, Justin. Very helpful.

Thanks Andrew. This particular installation is not using an old version of Spike like my other one, so besides trying out the manual settings for gain/attenuation/pre-amp, I will also experiment with disabling the auto recal, just for good measure. This BB60C is indoors, but it is in a cabinet with a laptop, so I can imagine there may be temperature swings more than 2 deg C under some circumstances.

My next task was to see if the measured signal strengths are changing during the discontinuities, but as you note, they shouldn’t be, just the noise level.

Thanks for confirming that I may be on the right track.

The older version I’m running now shows 3.4.2. If it’s helpful, the “About” screen also shows BB API Version 4.2.0, SAAPI Version 3.1.4, SM API Version 2.0.2, product ID 4300-1101. This is pretty much a random version that I still had the install package sitting around my disk drive, so whatever happened was after this version. The connectivity issue started roughly a year ago. So not very exact, but that would give you a rough range. It occurred to me at the time that it would be useful if it was possible to download previous versions of drivers and Spike. Is that a thing?

An important fact is that I’m still running Windows 7 on this particular installation. So perhaps if I had a laptop running Windows 11 it wouldn’t be an issue. When I find some time I can give that a try, but I usually don’t like to mess with things that are stable.

FWIW, I have been using a USB 3 fiber extender (an Icron unit) to connect a BB60C that is on the roof right at my antenna, about 100-foot cable run away, to my computer in the lab a couple of stories below. This saves me about 7 dB of LMR-600 cable loss at 3.5 GHz, compared to locating the BB60C in the lab.

The USB 3 extender has worked very well for several years, although starting about two years ago, an update to the Signal Hound USB drivers or Spike or both caused it to become less reliable. The BB60C would disconnect every few minutes. I rolled back my drivers and Spike version and it works 100% again now. The only drawback is that now I’m “stuck” with a Spike version that is a couple years old, for this particular installation.

For deployments that are in other locations (i.e., many miles away), I connect a BB60C to a co-sited laptop, and I remote into the laptop using Splashtop. This is reliable, although the frame rate achieved on any remote application I’ve tried is not good enough to keep up with the refresh rate needed to see every single sweep in Spike. But I record the data coming from the BB60C and upload it to the cloud so I can play it back locally for full performance.

Thank you for the quick reply Andrew.

Sorry to resurrect a zombie thread. Quick question: Many new laptops are coming with one standard USB 3 slot per side (making use of the Y-cable inconvenient), but on one side, there is typically also a USB C or Thunderbolt 4 port available in addition to the regular USB 3 port. Is it possible/OK to connect the power connector of the Y cable to that port, using an adapter? Or is the voltage wrong? Or conversely, can the data connection be made through that port using an adapter, and then use the regular USB 3 port for power? Thanks. Example Dell Inspiron: https://www.dell.com/en-us/shop/dell-laptops/inspiron-14-laptop/spd/inspiron-14-5410-laptop/nn5410fljjs

Andrew, it was an error in my script. I am now seeing the flag set in recordings with decimation on if a constituent sweep shows an overload during recording. Thanks very much.

Hmmm, my script is supposed to tell me if any of the sweeps read in from my (decimated or otherwise) files have the overload flag set. It’s possible (or likely) that I screwed something up. I tested the functionality on some files that were not recorded with decimation on and it worked. Then I didn’t see any flags on files with decimation on, even though I know there were some overloads. Let me check later today. I probably screwed something up. Sorry for the apparent false alarm.

Andrew,

Thanks very much for implementing this feature! May I be bold enough to ask for one tweak? That is related to the decimation issue raised above. When recording using the decimation feature, would it be possible to set the overload flag on a decimated sweep if one or more constituent sweeps acquired during the decimation period were overloaded?

Thanks!

Andy

Andrew,

Perfect, thanks. BTW, I really appreciate all the work you put into Spike. It’s a great piece of software, and keeps getting even better with each release.

Andy

[andrewclegg]

Hi Andrew,

Thanks for the quick response.

Generally, yes, I acquire and save in Spike, and process the data in my own Python applications. I sometimes also look at the recorded data in Spike. Probably 75%/25% split. In either case, it would be good to know which sweeps are potentially corrupted (or uncalibrated) due to overload.

Preferentially, all sweeps would be kept, and those that are overloaded would be flagged. This would allow continuous data acquisition, even if some of the sweeps should be considered suspect, and then I can deal with them accordingly and as desired in post-processing.

The next best solution would be to simply not record sweeps that are overloaded, but personally I would prefer the first solution, since to me it’s always better to collect as much data as possible and deal with imperfections accordingly in post-processing. For some applications, I could imagine it’s better to have a sweep even if it’s uncal than to be missing data completely (for example, when trying to capture the exact time and general nature of an infrequent short burst, for example).

Of course, the truly ideal solution is to have both: the option to either record and flag overloaded sweeps, or not record them.

I believe there’s 16 bytes of unused data in each sweep (unint64_t reserved[2]). Could the overload condition be encoded in part of those unused bits?

By the way, when decimation is used, how are overloaded sweeps that occur during the decimation period handled? Is there any special treatment or are they handled like any other sweep? If the latter, it would probably be good to flag the affected decimated sweeps too, if they are possibly corrupted.

I always try to avoid acquiring important data in overload conditions, but sometimes I’m on the edge due to dynamic range considerations, and it would usually be good to be able to identify uncal data if it happens.

Thanks!

Andy

• This reply was modified 6 years ago by andrewclegg.

Andrew —

Yet another feature request to add to the pile!

If a max file size is set, it would be good to have an option to stop recording when that size is reached, but automatically open a new file and continue recording until the max file size is reached for that file, etc.

Thanks!

Andrew Clegg

OK, but that’s not the topic of this thread, so my assumption that you were asking about max file size in relation to reading with python scripts (the topic of this thread) seemed logical!

Max file size is an option in Spike but I suggest you start a thread under that topic if you want more details.

I find that Signal Hound files quickly exceed the memory limits of python, especially on a PC where most python installations are still limited to 32-bit. You won’t even be able to load a 1 GB SHR file completely into python on a PC, most likely.

What I do when I need to process large files is process each spectrum sweep as it is read in. For example, if I need total power across the spectrum, I sum the power across the bins, and save just that number. Then I read the next sweep, etc. I don’t try to read the whole file into memory.

If you aren’t able to do that because you actually need to operate on the full 3D array of frequency/time/amplitude, then at a minimum I recommend doing that on Linux or Mac with a large amount of memory, and still auto-saving reasonable-sized SHR files (1 GB is probably a good start). I don’t recommend doing this on a PC with a 32-bit installation of python. To keep things even more manageable for later processing, you could decimate in frequency and/or time as the files are read, unless you really need the full time/frequency resolution that’s in the SHR file. Also, keep in mind that the latest versions of Spike support decimation when saving files. It can, for example, save the average spectrum over 1-second intervals, or the max spectrum over each 100 sweeps, or various combinations. That’s a really useful feature to avoid huge file sizes when acquiring data over long time spans.

BTW, I tried the save channelized data feature on the new versions of Spike (same option screen as decimation), but it didn’t work for me. I’m not sure what happened. I have not created any scripts that support reading SHR files when channelization was used, because I didn’t get a chance to figure out what I was doing wrong to get any valid sample files. Probably my error somewhere.

BTW, I made a version of the python script that can deal with corrupted SHR files when Signal Hound crashes during data acquisition. It’s very simple — the code just avoids reading the last 2 or 3 sweeps, which are the only ones that are corrupted/incomplete when there is a crash. The rest of the data are still fine.

Mihai,

Send me an email at andrew_w_clegg@hotmail.com.

Andy

I have been searching for a USB 3 Y-cable with the locking screws, like the ones that ship with the BB60C, but no luck so far. I can only find them without the locking screws. Does Signal Hound sell the cable as a separate item? If not, is there a suggestion of where to buy them?

Thanks!

Andy

Thanks Andrew! I was already poking around this afternoon and deducing some of the new header structure and where the lat/lon/height is stored with each sweep.

BTW, the GPS feature is awesome. I have wanted that for a long time. I have been running a separate script and having to post-process to line up the logged GPS coordinates with each Spike sweep. My only request is that you might consider adding some visual indicator that GPS is working, right on or near the spectrum display. Perhaps a small “GPS” button that lights up green when GPS status is good, red when not good, and grey when GPS is not connected. That could be placed, for example, within the grey border above the spectrum or waterfall plot, next to the intensity slider. Just a thought. (If there already is a visual indicator, other than leaving the GPS Control Panel open, let me know — maybe I’m blind!)

Also, the decimation option is GREAT too. That will really help with long-term spectrum monitoring. My hard disk will be very happy.

One quick question — is the sweep time still taken from the system clock, or is it grabbed from GPS if available? I presume the former since the serial GPS output is only every second or so not very continuous.

Thanks again.

Andy

Great, thanks very much, Cory.

Andy

Andrew —

Thanks much for the explanation.

Andy

Great, thanks!

Andy

[Author]

Posts