Instant Replay

[srcejon]

Ever wanted to go back and listen to a signal that's already scrolling past on the waterfall?

This PR adds an "Instant Replay" function to RTL SDR, SDR Play V3, USRP and Airspy HF (as these are the SDRs I have - can easily be added to others - thought I'd get some feedback before doing them all).

Video showing how it works here: https://www.youtube.com/watch?v=IBIIMlKbp-8

[das-Iro]

I really appreciate this feature, something I've always wanted in an SDR. I think it would be better to implement it in the waterfall though. Currently the channel is fixed at t0. If it would be possible to select the frequency and time in the waterfall the simplicity of use would greatly be increased.

• Squelch could automatically advance the channel to be less delayed
• No additional UI (clutter) needed
• Independent of SDR source
• Channels can have different time offsets
• not missing out when removing the buffer

[srcejon]

Being able to click on the waterfall to set the offset sounds like a good idea, as it should make it easier / quicker to set the desired offset.

Doing it per-channel is a bit more complicated though.

[f4exb]

Squelch could automatically advance the channel to be less delayed

What do you mean exactly by this? You can move in the past not in the future or in that case closer to the present than the buffering allows. This is inherent to DSP running on commodity hardware. If you want true real time you have to resort to a FPGA based system.

Doing it per-channel is a bit more complicated though.

The time travel buffer could be implemented in the channelizer preferably at the end of the downconversion filter chain to minimize the memory footprint. Not impossible but as you said not easy either. Then comes the question on how to implement the controls. A point in the waterfall gives a time delay and also a frequency so theoretically it is not impossible to relate it to a channel knowing the channels frequency footprints. It does not solve overlapping channels issues though or you assume that in the overlapping case you delay all matching channels.

[srcejon]

Squelch could automatically advance the channel to be less delayed

What do you mean exactly by this?

I guess he means that if you jump 10 seconds in the past to listen to something, after that has been replayed, it could automatically jump forward in time (up to t=0 of course) to the next bit of audio above the squelch threshold.

The time travel buffer could be implemented in the channelizer preferably at the end of the downconversion filter chain to minimize the memory footprint.

Yeah. I did think should I do it before or after device decimation. I choose before, as I wanted the ability to go back and be able to change the decimation setting. This uses more memory - but I have plenty :)

[das-Iro]

Squelch could automatically advance the channel to be less delayed
What do you mean exactly by this?
I guess he means that if you jump 10 seconds in the past to listen to something, after that has been replayed, it could automatically jump forward in time (up to t=0 of course) to the next bit of audio above the squelch threshold.

exactly

The time travel buffer could be implemented in the channelizer preferably at the end of the downconversion filter chain to minimize the memory footprint.

Yeah. I did think should I do it before or after device decimation. I choose before, as I wanted the ability to go back and be able to change the decimation setting. This uses more memory - but I have plenty :)

agreed

SDR - replay buffer - chanelizer (with time delay from replay buffer) - channel
Would be my approach, if I can be of assistance I would gladly hop on.

[f4exb]

For channel replay as you don't control the decimation (it is driven by channel requirements and channel position in the passband) the replay buffer could well be at the end of the filter chain.

Be careful when you move the channel around in the passband as the effective sample rate after decimation can possibly change. This can make buffering at the input of the decimation chain easier to implement. You still have to care about the device decimation.

[srcejon]

Being able to click on the waterfall to set the offset sounds like a good idea, as it should make it easier / quicker to set the desired offset.

Just tried adding this (Ctrl+left click on waterfall to set time offset). It works as you'd expect when the time offset is zero - but not really possible to make it work when there is already an offset, as we don't currently have any meta data with the samples. So it's not really possible to work out what the offset is for the waterfall line that was clicked.