Squelch and recordings [improved in v1.561]

Hi John,

I don't know how feasible this is, but here goes anyway.

This morning I've been trying to capture some I/Q recordings of an elusive data signal that only appears once in a while.

I have been making hour long recordings and then searching through them to see if there has been any activity.

This is fairly tedious, and I had hoped to be able to use the squelch to trigger recordings, however the problem in doing this is that the first fraction of a second, which usually contains some sort of a sync sequence is missed.

I wondered, if it was somehow possible to incorporate a short duration (<1 second) buffer containing 'non-squelched' audio, which could be used to recover the pre-squelch portion and it be included in the recording ?

This would be a bit like the 'pre-trigger' recording period that is common in many CCTV systems, allowing you to see what has initially caused a motion sensor to activate 'before' the recording started.

Regards,

Martin

Comments

  • edited September 7

    I wonder if you could use kiwi_nc.py and kiwirecorder.py from the kiwiclient tools to do this external to the kiwisdr itself?

    sox might be able to help http://sox.sourceforge.net/Docs/Features

  • G8JNJ, try to set the AGC Decay parameter to the minimum value.


  • Yes, that should be relatively easy to do (I think).

    If you care about absolute timing of squelch openings then you really need to get a decent sound processing app. I use Sound Studio for Mac. Here is a 5 second squelch open in a 30 minute recording. Easily visible even when fully zoomed out. Even a couple of 10 millisecond audio glitches are visible (not sure where these came from exactly, maybe my VAC software).


  • Hi John & All,

    Thanks for this, and the other suggestions too.

    I have decent sound precessing applications (Goldwave) & Audacity), and I can see signals when they have appeared. The problem is not absolute timing related, but is having to regularly download large typically hour long I/Q recordings, and then manually check through them for activity. This is very time consuming, especially if the signals only appear for a few seconds each day.

    kiwi_nc.py and kiwirecorder.py is certainly worth looking at, and reducing the AGC time is a another factor (AGC attack and finite record start time still distorts digital sync sequences at the start of transmissions), but ideally, for me at least (and probably other utility listeners too), it would just be much more convenient to have a pre-record buffer, so that the start of signals could be fully captured using the squelch and avoiding generating massive files that contain just noise.

    If you take a look at some of the detailed analysis that Antonio makes of digital signals, then you can see the value of fully capturing 'run in' sync periods.

    https://i56578-swl.blogspot.com/

    If the buffer was long enough, it would even allow enough time for a 'manual' record button press to capture 'interesting' activity when heard (I think one of the AOR scanning receivers, possibly in the 1980/90's ? had this capability using an SD card). But that's probably taking the idea too far.

    Thanks again for your consideration,

    Martin

  • edited September 8

    SQL and AGC corrupt the beginning of the file record. I tested on different KiwiSDR. A piece is missing from the beginning of the record, while SQL is opening. And not from the very beginning. 0.5 seconds is fine, then a fragment is missing for about 0.5 seconds, then the record is normal. This is only with SQL enabled.

    There is also a small problem with recording. It is expressed as a "hump" when a signal appears. The same "hump" is when the signal is lost.


  • Some are daunted by the kiwiclient tools

    Here's a simple line that will get you audio from your speaker

    ./kiwiclientd.py -s jimlill.com -p 8073 -f 1180 -m am -L 100 -H 3000 --ncomp --resample 44100

    you can send that to something like Audacity to record, look at the realGate plugin

  • jksjks
    edited September 10

    I have this working now.

    What are some good fixed values to put in the "pre-record length" menu? (similar to the existing "squelch tail length" menu)

  • Hi John,

    I don't think it needs a huge range of values, so using the same numbers as the squelch tail length would be a good starting point.

    If you could also manage say 5 seconds, that would be great, as it would allow sufficient time to hear something interesting and be able to manually start a recording.

    However, anything you can provide would be a positive bonus.

    I look forward to trying it out.

    Thanks again,

    Martin

Sign In or Register to comment.