The KiwiSDR 2 online store is open for orders! Please visit
Today's v1.694 update is hopefully a working version of the failed v1.691,692 release of a few days ago.
See the first post of the "v1.694" thread below for the CHANGE_LOG notes.
Please visit (documentation) and (online store)

Placing my own labels on my KiwiSDR

I am currently running one KiwiSDR with a 70 cm transverter (only used the RX downconverter part).

Thanks to the extension of the RX to 32 MHz I can now tune between 430 MHz (at 25 MHz) and 437 MHz (at 32 MHz)

I would like to remove the current labels and attach my own labels for the converted frequency.

Or even perhaps when possible a converter setting so the KiwiSDR shows the actual frequency 

Any thoughts on this ?

Thanks for your attention,

Ben - PE2BZ


  • The label system needs a complete overhaul, but that's a separate topic.

    To do what you need there are a couple of options. If you're running a recent release (we're on v1.10 currently) you can edit the labels directly with the browser UI. See here:

    But that's kind of cumbersome because you'd have to delete each label, one-at-a-time, from 25 MHz up. Or worse, all of them since none would apply if you only have a transverter connected. So try editing the database file directly. FIrst, login to the Beagle with ssh or PuTTY as root. Type 'cdp' to go the project build directory. 'mst' to stop the server. 'cd ~/kiwi.config'. Make a backup copy: 'cp dx.json dx.json.bak' Then edit the file dx.json using whatever text editor on Debian you can deal with. 'nano' is not too bad. It uses control characters for commands. It has on-screen help. The dx.json file entries are sorted by frequency, so delete the ones you want. Restart the server by doing a 'cdp' and 'ku'.

    Your idea about adding an offset to the displayed frequencies is a good one and I'll add it to the wish list.

  • Thanks, works OK now.

    A little argument about Kiwi not starting because of errors in de dx.json. It really does not like spaces ? %20 did work :-)

    on the other hand, on the wish list: ku showed starting the service, no errors on screen but did not run until I fixed the dx.json. Some improvement for error message when dx.json is not ok ?

    Nano and I are friends. VIM is a pita for me ;-)

    Kind regards,
  • Yes, dx.json is not meant to be directly editable just for that reason. So errors in the JSON format are not introduced. There is a placeholder in the admin webpage for bulk-editing of the dx list, but of course it is currently unimplemented. In dx.json strings additionally use URI encoding to allow Unicode and internal quotation. But this makes direct editing of the file painful.

    WebSDR has this neat new feature that saves and restores the user label list as a .csv file. We should do something similar.

  • I'm a professional web developer and perfectly comfortable editing JSON files (or more likely, setting up databases to output JSON files). Is there any documentation on the fields in dx.json? It's not all that difficult to reverse engineer, but documentation would help.


    Obviously, frequency, mode, label (URI encoded), I assume a label of some sort (exposed as "Notes"?), and then type. It would be helpful to know what the possible values mean, particularly for type (I can figure out what the possible values are for mode, and what they mean).

  • jksjks
    edited October 2016
    The "notes" field gets stored into the html title attribute of each label and shows as a tooltip on mouseover.

    There are flags inside the object description at the end: WL: watch list, SB: sub-band (e.g. WSPR sub-band inside ham band), DG: DGPS, NoN: Night of Nights (MRHS event), XX: interference signal. Mostly these just determine the label color. Also "o": +/- offset Hz, that's lowercase letter oh, is the carrier offset for the special hack with NDB listings e.g. [350.00,"CWN", …, {"o":-1030}] will show the triangular carrier symbol on 350 kHz but center the cwn passband on 350 kHz - 1030 Hz = 348.97 kHz. This hack is so that in a crowded NDB band you can see which carrier is associated with the cw sideband you're listening to.

    Generate your json file in frequency-sorted order. Yes, URI encoded to solve the embedded quote and Unicode character problems.

  • Thanks, John, that's tremendously helpful.
  • Having had my KiwiSDR for all of 5 hours I'm already wanting to tinker :-)

    I'd like to be able to import the .csv files from the swskeds Yahoo Group.

    These import directly into the Elad SDR software I've been using and I'd like to
    do the same thing with the KiwiSDR software.

    Not sure where to start though (yet) and don't want to reinvent the wheel if
    someone has already looked at this.

    Cheers, Chris

  • WebSDR now allows upload/download of private user .csv files. I've added this to the wish list.
    I think it needs to be a part of a complete re-think of the label system rather than tacked on to the current code (which is a bit of a mess right now).

  • Let me chime in as being interested in being able to add markers easily via a csv or other file.
  • last year, I used a tool to convert json to csv, brought it into a spreadsheet, worked on it, then reversed the process. Can't recall tool name though
  • It would be nice if those labels could somehow be dynamically refreshed, crowd sourced and customized by geographical area
  • Most of those ideas are on the bug list and have been for a long time..
  • I would like to react to jks' comment:
    {"o":-1030}] will show the triangular carrier symbol on 350 kHz but center the cwn passband on 350 kHz - 1030 Hz = 348.97 kHz. This hack is so that in a crowded NDB band you can see which carrier is associated with the cw sideband you're listening to."

    When creating my own labels I found that, dependent on the "mode", the guideline of the label (pointing to the frquency) is not positioned correctly.
    • in LSB and USB modes the label is moved 1.5kHz to the side. Regardless of the actual boundaries/width of the passband. If the implementation would haven been consistent this should be "at the center of the actual passband")
    • in (N)CW mode the label seems to be on the centre of the passband.
    • in (N)AM mode the label is centered on the carrier.
    To me the "NDB hack" mentioned by "jks" seems overly complex and not needed.
    My suggestion for a future overhaul of the labelsystem would be:
    • always use the traditional convention that the frequency of the signal is the frequency of the (suppressed or not) carrier.
    • for people who want to move the label to the center of the passband, shift the position of the label by the value entered in "offset" WITHOUT changing the actual set value in "frequency" and the "boundary values" entered in "passband".
    In this case crowded NDB bands would not be confusing. The label would always be over the center frequency. The little vertical yellow line would indicate the carrier-frequency. The "upside down yellow bathtub" would show exactly which part of the spectrum is demodulated.

    It seems that "(N)CW mode" is not actual CW decoding (which would sound a tone dependent on the presence or absence of a carrier), but in fact a form of USB/LSB decoding. The hight of the perceived tone depends on the difference between the actual transmit frequency and the tuned frequency.
    With CW the indicated frequency should be the exact frequency of the carrier. In this case "Offset" could be (mis)used as some sort of BFO/Clarifier. Frequency should indicate where the center of the passband is. The little yellow line should be at Frequency+Offset (Offset can be negative). The user can set the hight of the tone with "offset" and the center of the label would be exactly over the transmit frequency.

    Jan / PE1OSQ

    Note: for people who are not familiar with "NDB".
    NDB's are Non Directional Beacons used to indicate the position of landing strips in aviation.
    NDB's transmit an AM signal with a frequency around 300-500kHz (NDB utility band) and a bandwith of about 1kHz.
    NDB's identify themselves by modulating their AM carrier with a three letter morse code in audio (i.e ROT is Rotterdam and ONW is the id
    of Antwerp airport).
    Because morse is a single tone the AM sidebands are very narrow. There is lots of QRM on longwave so listening to NDB's in USB makes a
    lot of sense. Normally I use USB decoding with a carrier frequency at the frequency of the beacon and a passband of about 50Hz centered
    on where you can see the sideband in the waterfall.
    If you get the hang of it hunting for NDB's of far away airports can be a lot of fun (and with Kiwi's all over the world your can listen everywhere)
  • I have 100's of NDB logged (although here in US they are taking them off the air one by one) and use the scheme shown below. the 400 Hz offset is for Canadian station, US would be 1000 Hz

  • It's not wrong just because you don't like it.
    See the dozens (if not a hundred) other comments about this issue earlier in the forum.
  • In the first place, it was not my intention to be disrespectful.
    If my posting was percieved as such, then I am truly sorry.
    English is not my first language...

    I merely tried to illustrate that sticking to the "official way" (frequency = suppressed carrier) would prevent confusion.

    I am very much aware that different people have different preferences.
    On my ICOM SDR there even is a menu setting to switch between the "frequency = carrier" and
    "frequency = passband center" representation. In my opinion, implementing this on the Kiwi would
    be overkill and a terrible waste of time.

    So, no problem at all if the Kiwi continues the "frequency=passband center" representation.
    But in that case, in USB/LSB mode, please let the frequency always be the center of the actual
    passband. (I mean the passband you can set with the "upper- and lower boundaries")
    Now it seems there is a standard offset of +1,5KHz (for all USB) or -1,5KHz (for all LSB).
    This would only be correct for the [100-3000] passband commonly used to listen to SSB
    voice transmissions.

    Jan (PE1OSQ)
  • Some of this discussion is a result of the confusion as to what is a given frequency. Even in the professional community we suffer due to misinterpretation as to the terms used to describe the use of a frequency. The one that I seldom see in the hobbyist community is Center of Intelligence (COI). I deal with FCC licenses for experimental stations, there we are given the COI and must do the math for a particular occupied bandwidth. The result of that math may mean the dial frequency changes depending on mode. With BW of CW up through 48 KHz on HF, frequency management can be a chore. All the while the radio's dial freq. remains at the carrier frequency and we have to adjust it per the FCC value etc. If all parties involved don't understand how to do that, they can chase each other on the band.
Sign In or Register to comment.