Feature suggestion - Measurement/display of carrier frequency
I am not sure if this is even possible, but I figure I would ask...
For MW DXing, it is often useful to know the exact carrier frequency of the station being received, as this can be (sometimes) used to ID the station in question. By exact I mean 1 Hz or better. Since in theory KiwiSDRs have a GPS locked A/D clock, the accuracy should be fairly high. While some sort of graphical display zoomed in to the tuned center frequency +/- 50 or 100 Hz would be neat (basically a hi-res FFT), even a text display of the strongest carrier present could be useful, updated every so often.
By way of example for the graphical method, this is what my Carrier Sleuth program does, fed with I/Q recording files: https://www.blackcatsystems.com/software/medium_wave_carrier_display_app.html
For MW DXing, it is often useful to know the exact carrier frequency of the station being received, as this can be (sometimes) used to ID the station in question. By exact I mean 1 Hz or better. Since in theory KiwiSDRs have a GPS locked A/D clock, the accuracy should be fairly high. While some sort of graphical display zoomed in to the tuned center frequency +/- 50 or 100 Hz would be neat (basically a hi-res FFT), even a text display of the strongest carrier present could be useful, updated every so often.
By way of example for the graphical method, this is what my Carrier Sleuth program does, fed with I/Q recording files: https://www.blackcatsystems.com/software/medium_wave_carrier_display_app.html
Comments
Attachments:
https://forum.kiwisdr.com/uploads/Uploader/c7/2e0ecc186b9f6c92ea066591929787.jpg
I use this for setting the frequencies of AM transmitters as you can turn the tx off, measure the co channel offset then switch yours back on and trim it in within fractions of a Hz.
Same module also is good for checking peak deviation.
Ron
KA7U
A lot of the pieces of code to implement a high-resolution audio FFT are already there. You just have to find them, which is where documentation would be handy. For what you're interested in you might look at the "integrate" extension which shows how to write pixel data to a canvas at the top area of the display fed by data from the Beagle which could come from an FFT.
Extensions have two parts: C++ code on the Beagle (extensions/ directory) and javascript code on the browser (web/extensions/ directory). You have to decide where it is appropriate for different parts of your extension to reside depending on what they do/need. UI stuff will obviously be in Javascript on the browser side. If your signal processing can also be done in Javascript using the hooks to access the Kiwi audio stream on the browser then the Beagle side might be completely trivial. On the other hand, if you need the very efficient FFTs provided by FFTW on the Beagle then the C++ code might be more complex. And you'll be sending display data over the provided extension web socket to the Javascript side.
There are other considerations. C++ Beagle code has to meet the Kiwi realtime requirements by calling NextTask() at strategic preemption points throughout the code. Your code can't run for more than a few milliseconds without yielding.
On the Javascript side you can use pure HTML/CSS for the UI, but there is also a set of routines called w3_*() which is vaguely similar to JQuery. These are meant to be an extension to the existing framework called W3.CSS (https://www.w3schools.com/w3css/default.asp). A set of routines called ext_*() is for common extension-related operations (e.g. getting the current frequency/passband, displaying the help panel). And there are a bunch of general utility functions called kiwi_*().