Waterfall data

[mcogoni]

Hi Dmitry, thanks for your nice software! I was wondering if you could expand you code to save waterfall data. I tried to modify the audio streaming class, I sent "W/F" instead of "SND", then I receive a message ending with "wf_setup", then I'm stuck... John's rx_waterfall.cpp is a tough beast :) This could be useful to perform noise measurements on remote receivers and many other things such as MUF prediction etc.

See you! marco

[jks-prv]

I'm working on this. Give me a few hours. It's possible in principle because Pierre does it for http://rx.linkfanel.net/snr.html Although I'm not sure what code/language he uses.

[mcogoni]

Hi John, nice to read you. Yeah I've talked recently to Pierre about doing a multi band SNR evaluation of receivers. His method is useful, but all band evaluation cannot discern between a receiver performing well over all HF and one being excellent at MW but totally deaf on 10m. So I'd like to split the spectrum into several pieces and produce a more detailed report. Besides, Dmitry python program is great for doing more quantitative/automated analyses and to feed other decoders etc, so I'd like to see it grow a bit.

What I'd really like to see inside the official kiwisdr software would be the addition of a "temporary channel" to let automated systems log in for brief amounts of time (a few seconds) even with just the waterfall data. I wonder if the FPGA still has the resources to add this.

73, marco / IS0KYB

[dev-zzo]

Hi Marco, from what I recall, this should be easily doable if we store raw data (not e.g. PNGs) which should also be more useful for doing measurements. If you have preferences for the output format, please let me know.

[mcogoni]

Hi Dmitry, raw data would be perfect. I don't have any specific format in mind, I'd just like to keep the information regarding band limits and bin number to recover the absolute power density, so we can also mix spectra obtained with different binnings.

ciao, marco

[mcogoni]

Ah, I was forgetting an obvious thing: it would be nice to have the timestamp associated to the raw data.

marco

[jks-prv]

I'm still working on this. I don't know Python, so I'm having trouble getting it to do what I want..

[mcogoni]

If you need I can help, I use Python everyday, but I know nothing of websockets ;)

marco

[jks-prv]

Okay, my branch https://github.com/jks-prv/kiwiclient/commits/jks-v0.1 has waterfall streaming. See the Makefile "wf" target. Only streams data 0 - 30 MHz at 1 Hz update rate for now. Needs more work to support variable zoom levels and starting frequency. And there is no code to store the data yet.

[mcogoni]

Hi John and Dmitry, I slightly pythonized your code with numpy (the part ordering bin values) and I'm saving the data to disk. I'm not able to go over 4 fps though, the code freezes. Do you know what could be going on? So now I'm going to add a startup option to give the name of the file to which to save data and the fps rate. Maybe we could add the possibility to produce a waterfall graph image, but I personally think that a separate script doing data processing and image output would be preferable.

marco

[mcogoni]

OK, I did a mistake, I thought the rate parameter was "fps", quile of course it's a parameter from 0 to 4. so it's already working at "20fps". I did a few (manual) tests and it actually writes at about 10 fps. Now I was trying to zoom and offset the waterfall window, but it seems to just zoom, the offset is apparently doing nothing.

[jks-prv]

Offset works, but it's in very strange units of "bins" instead of a frequency offset. This is difficult to explain. It was never meant as a public API. I'll probably have to implement a proper frequency offset instead. But I already have 35 new emails this morning..

[mcogoni]

this one I suppose: float off_freq, HZperStart = ui_srate / (WF_WIDTH << MAX_ZOOM);

off_freq = start HZperStart; i_offset = (u4_t) (s4_t) (off_freq / conn->adc_clock_corrected pow(2,32)); i_offset = -i_offset; spi_set(CmdSetWFFreq, rx_chan, i_offset);

[jks-prv]

Not only that, but all the stuff in javascript on the other end that determines the value of "start" to begin with.

[dev-zzo]

Hmm, I'd suggest having a separate subclass of KiwiSDRStreamBase to deal with waterfall stream instead of modifying the one responsible for the sound stream... Most of the methods in that one are not applicable to waterfall anyway.

[jks-prv]

I wasn't sure what to do about that. There is common code in KiwiSDRStream that would be duplicated in a waterfall-specific subclass of KiwiSDRStreamBase. Perhaps that common code can be pushed down a level into KiwiSDRStreamBase to prevent duplication.