Save and replay traces

[g4ixt]

Add the ability to save and replay traces. What features should it have?

[simonTx1]

Hi, I'm simon,
Thanks for your work pogramming QtTinySA. It will be great for the TinySA community. Here are a few ideas of trace management from audio analysis softwares, maybe it can help you find ideas best suited to your software.

The trace acquisition remains the same as it is, with "normal", "max" "avg" and "min" (+ "math" ?) . Each one of these "active" traces, can be independantly "captured", adding them to a list of "overlays" with the ability to name them, assign colors, show or hide, and export the trace in csv. (color and name could be written in a preamble)
--> These "overlays" traces could be used in math functions in relation with active traces. (multiplication, difference, normalize, etc..)
Importing traces from a previously saved file would send the traces to the "overlays".

Regards,

Simon

[g4ixt]

Hi Simon,

I can understand why it could be useful to store and replay traces, and to compare a stored trace with a live one (if adjusting a linearity corrector, or increasing power through an RF amplifier and looking at harmonics for example) but I don't understand performing mathematical functions between a stored trace and a live one like a modern oscilloscope can.

Bearing in mind that the TinySA measures discrete frequencies, any mathematical functions would need to align every frequency step and if you were to add or subtract one from the other it would combine the shape(s) of the resolution bandwidth filters in some arbitrary way and the display would be meaningless, unless I am missing something.

I think it would be possible for me to add a feature to 'freeze' one or more of the existing 4 traces, whilst still updating the others. I will think about it for a while.

[Ho-Ro]

any mathematical functions would need to align every frequency step

While this can easily be done using scipy's interpolation functions ...

it would combine the shape(s) of the resolution bandwidth filters in some arbitrary way

... that's the killer for my understanding (unless the imported signal has a narrower RBW and you apply some kind of low pass filtering - very unpleasant.

it would combine the shape(s) of the resolution bandwidth filters in some arbitrary way

That's my gut feeling too.

[simonTx1]

if you were to add or subtract one from the other it would combine the shape(s) of the resolution bandwidth filters in some arbitrary way and the display would be meaningless

The implications are indeed more complicated than i thougth regarding rbw filter... Again, these are ideas coming from audio time domain acquisition software (always the same sample rate and quantification), and may not transpose easily in the RF world.

I don't understand performing mathematical functions between a stored trace and a live one

While monitoring the RF environment on a large span (250MHz) with over 150 carrier frequencies, a normalize function can help identifying variations : a new signal shows up as a isolated spike on a flat line. I have been using it extensively on tinySA-App.

[g4ixt]

I understand the subtracting/normalising idea now and can see that working provided that the same sweep settings are retained and the majority of the signals are relatively steady. Have you tried the 3D "time spectrum" in QtTinySA for spotting new signals?

[simonTx1]

Hi Ian,
Here is a surveillance of live RF microphones i did yesterday :

The fixed markers are a very valuable improvement for my use ! thank you !

As you can see it can get a bit crowded and identifying a anauthorized carrier frequency can be difficult while monitoring the entire 230MHz span. This is what the substracting/normalizing function would help with since only the new perturbation would show up with a significant magnitude.
I'm not sure how they implemented this feature in TinySA-app but it seems to work ok ("SET NORM" button).

[ccera-astro]

Saving scans from QtTinySA would be incredibly useful. Perhaps offer a .csv format and some kind of bitmap image of "what the screen shows".

[g4ixt]

Scans can already be saved in various formats - see the Wiki.

[g4ixt]

But my idea is to allow them to be written to a database and then be re-played or exported to .csv, I just haven't got around to it yet.