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


  • I'd like to support Chris' suggestion. Offsets are very often very stable, and MW DX-ers like me use offsets to see if there can be new stations on a frequency, and to "identify" old and less interesting ones. I use this function with the Jaguar software for Perseus SDR. I have thrown in my own example as well

  • If you use the iq plugin it's displayed in the bottom left, it's already there.

    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.
  • Any tips on using the IQ plugin to do this? I can't seem to figure out the correct settings.
  • edited January 2020
    Working with this, I think I see what @samhunt is doing with the IQ extension, but a higher resolution would be needed to see overlapping carriers that are very close to on frequency.

  • edited January 2020
    I am willing to try writing an extension to do this, if someone can point me to information on making your own extension. I found the example code at https://github.com/jks-prv/Beagle_SDR_GPS/tree/master/extensions/example but need a few more scraps here, like where code goes, how it's built, etc. I'm even willing to document my steps into some sort of a tutorial, if one does not already exist. :D
  • jksjks
    edited January 2020
    The extension interface/API has never been properly documented. Mostly due to lack of time and no interest by anyone but myself (aside from Kari's antenna switch and iframe extensions and VE3SUN's IBP scanner [apologies if I'm forgetting anyone]).

    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_*().
Sign In or Register to comment.