Kiwirecorder doesn't work properly with Frequency Scale Offset [fixed]

I've been testing out a 0-2 GHz Frequency Extender (down-converter) for the KiwiSDR entering Frequency Scale Offset from <right click>:set frequency offset (admin).

While that works as expected and allows the Kiwi to display an IF of the downconverter frequency but with a dial reading of the converter input, once the LO frequency has been properly entered. However, this does not appear to work properly when I use Kiwirecorder, something I want to do in order to use Wsprdaemon for VHF and UHF WSPR and FST4W studies.

For example, with Scale Offset set to zero, asking Kiwirecorder to report S-Meter at 5000 kHz works fine. While it is measuring, the Users tab shows the Kiwi tuned properly and a correct value is returned. But if I then enter a Scale Offset of 100000 and run again and tell Kiwirecorder to ask for 105000 kHz, as though I had an air-band converter with a 100 MHz LO in place, Users shows kiwirecorder running with the correct mode but the indicated frequency is 205000 kHz. Other combinations show Kiwirecorder always asking the Kiwi for a frequency of 2*ScaleOffset above the IF rather than just 1*ScaleOffset as it should.

This is not simply a display issue, the Kiwi is actually tuning somewhere other than the requested IF, I presume it may be trying to go LO_frequency higher, 'topping out' at the high frequency limit though I haven't proven this.

This problem makes using the KiwiSDR with Kiwirecorder impossible when a converter is being used with ScaleOffset calibration.

Glenn n6gn


  • edited December 2022

    The thing is that kiwirecorder does not know about your frequency offset. It is for this purpose that the offset frequency was added to the address mykiwi.sdr:8073\status so that none-kiwi applications could determine this frequency. Set the frequency for the kiwirecorder as if the scale starts at 0 MHz. For example, you have an offset of 100000 kHz. If you want to hear 106200 kHz, you need to set the frequency of (106200 - 100000) = 6200 kHz for kiwirecorder.

    You can also fix the file. You need to find the line in this file

    def set_freq(self, free):

    and add your offset to the next line. For example:

    self._freq = freq - 1000000

    I just checked it out. The frequency is set correctly and the sound is recorded correctly.

  • Yes, I know that managing the offset separate from Kiwirecorder - running it only at an IF works to get the correct audio but it does it with incorrect frequency. I'm presently doing this but this causes a problem with wsprdaemon which has correct frequencies hardcoded. This is also true of the WSPR/FST4W databases. If/when I have selected, say, a 2m WSPR frequency and offset within the Kiwi I ask for a 2m spot kiwirecorder and wsprdaemon will not work. Reported frequencies will be wrong and will not go into the database(s) correctly.

    Since things DO work OK as a regular user, the kiwi with a frequency extension does act like a proper receiver on the extended frequency. It would be good for the kiwirecorder interface to do the same.

    Also because my frequency converter is flexible, it can go from 0-2GHz, modifying kiwirecorder to match a particular offset is not a good solution. It would be far better if kiwirecorder could treat the extended Kiwi the same way that user access does - as a normal VHF/UHF receiver , without user involvement. This particularly matters for my converter since it can create a very capable 0-2 GHz receive system from a KiwiSDR. I It presently has a web interface and I hope to add capabilityto use it as the 'receiver' interfaceand have it, in turn, modify the Kiwi offset so that the user or kiwirecorder can simply 'see' a very wideband receiver with all the Kiwi capability and more.

  • edited December 2022

    The entire kiwisdr program code is written so that the frequency scale starts at 0 kHz. This is especially true for the server side. The client part processes the sound and waterfall flow considering only the frequency offset that is specified in the configuration file. And that's bad. For example, dx-labels are also tied to the zero frequency. And do not change at offset frequencies. can easily find out your offset frequency using http status requests.

    I am very interested in your project of receiving wide frequencies with a tunable converter. But keep in mind, to avoid intermodulations, you need to have tunable input filters. But its is very difficult part!

  • jksjks
    edited December 2022

    Kiwirecorder requires a "baseband" frequency always be specified, i.e. 0 - 30/32M, independent of any configured frequency offset on the Kiwi.

    To make this situation easier I have added a new option -o freq_offset to the latest kiwirecorder. It simply subtracts the offset from the frequency specified in the -f freq option before sending it along to the Kiwi. So you can specify an offset frequency (e.g. 105000) to the -f option.

    Update from the repo and see the kiwirecorder help and Makefile for example usage.

  • edited December 2022

    Thanks John, I hope to try that shortly. It would seem that all the pieces are available to make it possible.

    @studentkra the tunable converter for the Kiwi receiver is a subset of a full up/down converter for converting any 10-30 MHz HF radio in any mode to/from any frequency over the audio-2 GHz range. A conversion up/down to low microwave followed by a third to 10-30 MHz gets rid of images, thus it can convert any amateur band from 2200m to 23cm, though for the Kiwi only above 30 MHz makes sense.

    The architecture is triple conversion and I've tried to keep component cost low but I do use mid-level mixers with +17 dBm LO power along with care in gain selection and distribution to maintain good dynamic range. A block diagram of the receive converter especially for the Kiwi is Here. Both the receive converter and the full transverter are working and I'm working to minimize total assembled cost. I've built yet a smaller subset that uses the GPS/10 MHz disciplined Reference circuits for Kiwi External Clocking or other similar uses.

  • Using the new -o option in kiwirecorder followed by the output of something like:

    curl -s --get 'http://[hostIP]:[port]/status' | grep freq_offset | awk -F'[=]' '{print $(NF)}'

    may not be the best or 'proper' way to do it but it seems to work and should be OK for non-offset Kiwi's as well.

  • awk '{print substr($1,13)}' is another way to pull out values etc.

  • If you update a Kiwi to v1.570, and use an updated kiwirecorder (version as of today 19 dec 2022), then the Kiwi will send any configured freq offset value to kiwirecorder automatically. Essentially, you won't need to use the "-o" option in this case.

  • Thanks very much,John. Those changes in Kiwirecorder and the Kiwi have indeed made it possible to offset and tune a Kiwi both manually and from wsprdaemon (by way of kiwirecorder). I have been successfully and correctly spotting into the database from the Kiwi's WSPR extension and Users tab shows all the correct frequencies.

    The only remaining problem I see is that wsprdaemon does not correctly spot that same frequency. Talking with Rob I find that he uses the file named and returned by kiwirecorder to establish the frequency and band. Presently that naming does not include the offset so my 432.301420 MHz spots get posted as if they came from the 12.301... MHz Kiwi IF frequency. If the offset can be used to modify the file naming I think everything may be perfect.

  • Okay, pull a new kiwiclient for a fix.

  • edited December 2022

    Again, thanks John. That fixed it. From the database:

    N6GN/H is now reporting the correct frequency ( modulo 1.3 Hz intentional offset to cover baseband and ext clock error on N6GN/K which is at a remote site, I'm actuall transmitting at 1420 Hz above dial)..

    I think all your effor has paid off. If someone reading this in the future will upgrade the Kiwi FW to v1.570 or beyond and kiwirecorder newer than 20 Dec 2022 frequency converters for both normal and kiwirecorder applications like wsprdaemon should all work fine.

    I think this thread can be closed!

    Glenn n6gn

    Fort Collins, CO

Sign In or Register to comment.