The frequency on the scale does not match the frequency on the waterfall. [fixed in v1.495]

I am using a downconverter. If I set the offset frequency to a not multiple of 1000 kHz (for example 106250 kHz), the frequency on the scale does not match the frequency on the waterfall. This happens when the waterfall is zoomed from 0 to 6. At zoom 7 and above, the frequency on the grid matches the frequency on the waterfall.

In this picture, the label "MSK app" corresponds to a frequency of 131.200 MHz. The received signal at this frequency is also visible. However, the frequency 131.200 MHz on the grid is located to the left.

Here is a short video.

Thanks!

Comments

  • Error in rounding frequencies of large markers.

    var scale_markers_levels

    Temporarily set always rounding in two decimal digits.

    "decimals":2

    Not very convenient, the markers are not at multiple frequencies, but this is a temporary solution.

    But now there is no error.


  • I'm looking at this now. The fundamental problem is that the frequency scale code doesn't like starting at anything other than a 1 MHz boundary. To see this set the zoom to zero, freq scale offset (admin) to 170000. The scale will start at 170 MHz.

    But if the freq scale offset is set to 169500 the scale will still start at 170 MHz and at zoom 0 everything will be off by 500 kHz.

    I didn't write this code and it's difficult to understand. So it may take me a while to fix it.

  • edited February 27

    This is an area that interests me in that I would like to see an API that will allow changing the scale programmatically to match user tuning of the 0-2 GHz Frequency Extender I have designed, built and which is now operational. I'd like this for both waterfall and dial.

    Presently although the FE can be GPS referenced and can be precisely set to almost any scale offset such that 1 MHz boundaries might be OK there is no way to communicate to the FE .The only way I have to make the FE match the Kiwi or vice versa is by way of the scale offset on the admin page.

    For less general hardware, single range receive converters. e.g. a free-running 2m rx converter with a nominal 116.000 MHz LO but one which has known error from this value, the actual offset is perhaps the free-running frequency so more resolution would no doubt be of considerable added value.

    Maybe this is best done with an extension within the Kiwi, I'm not sure? It could then allow extended frequencies and then allow setting less granular offsets or call my remote tuner via an API to allow precise dial/converter synch or simply allow the user to set the known LO value (calibrate)

    Glenn n6gn

  • edited February 27

    Thanks! I'll hope it will be fixed. I used a si5351 generator, that was fine tuned to 106.000 MHz. But it has a lot of spurs! I bought a 106.250 MHz crystal generator. Its frequency is much cleaner and I can't change it. But there was a problem with the scale.

    Thanks again!

  • @studentkra that's another good reason that a software correction of both WF and Dial would be better than a hardware one. The Si5351 can be pretty clean if/when small, even integers are used in the frequency generation plan. But if small offsets are required it must operate in Fractional-N mode with large divide values and this creates boundary spurs and other problems that vanish at 'nice' frequencies.

    Here's the User Output from my FE without GPS correction, generating 100 MHz. You can see that the crystal has about ~2 kHz error at this frequency.

    The spectrum really isn't bad at all but programming it for 100.002 MHz would probably be a very different matter.

    FWIW, the spectrum is this clean or better out to +- 10MHz offset. Not bad for an inexpensive part (when you can get them)!

    How easy it is for us to suggest work for JKS...

    Glenn n6gn

  • edited March 4

    The scale issue has been resolved. I think so )))

    Changed in function mk_freq_scale()

    var tmp_offset = 250000; // Setting the temporary offset

    var spacing = get_scale_mark_spacing(g_range);

    g_range.start = g_range.start + tmp_offset; //Set new scale start offset

    f += (cfg.freq_offset*1e3 - tmp_offset); //Change the text of markers in "var ftext = function(f)"

    g_range.start = g_range.start - tmp_offset; //Return back the start of the scale to correct the mouse click.

    tmp_offset can bee automatic calculated from offset frequensy:

    tmp_offset = (cfg.freq_offset % 1000) * 1000;


  • But still only to the nearest kHz, isn't it?

  • Yes. The offset frequency on the admin interface is still set to 1kHz. But you can use the ADC calibration for fine tuning.

  • OK, that's better than nothing but not really quite optimum since a given Kiwi may be used on both HF and and a VHF/UHF converter where HF is 'perfect' with no residual error but a converter might have some. The ADC adjustment affects both so each can't be correct at the same time.

    My interest is largely in WSPR where 1 Hz, though 1 ppb at 23 cm is still important.

  • edited March 4

    tmp_offset has a step of 1 Hz and only affects to the drawing of markers on the scale. You can try 1Hz step. It does not affect the accuracy of receiving any way.

  • First of all, thank you very much @studentkra for figuring out how to apply the sub 1 MHz fractional part of the offset to correctly draw the scale. Based on your work I was able to take it a little bit further and fix a few corner-cases.

    I think it's pretty good now. I did a bunch of testing, including with a signal generator, and verified that offsets of 1, 10, 100 and 1k Hz looked correct at zoom level 14 (max zoom). An air-band Kiwi in Japan has updated and still works. So maybe these changes are okay.

    From today's CHANGE_LOG file:

    v1.495,496 March 7, 2022

      Enhancements:

        Admin config tab:

          Based on the work of studentkra (thanks!) "frequency scale offset" values with 1 Hz

          resolution (admin config tab) are now supported. Previously were multiples of 1 MHz. 


        Band definitions when in "frequency scale offset" mode now works.

          So you can have e.g. an entry in kiwi.config/config.js like this:

          bands.push({ s:svc.A, min:144000, max:148000, region:'*', name:"2 meters" });

          The "select band" menu on the main control panel now only shows entries appropriate to

          the frequency scale.

         

        Admin config tab:

          Added option "Show user geolocation info". If unchecked shows "no location" in place

          of geolocation in connection list of main control panel and camp panel. Admin status

          tab and /users JSON query still shows geolocation.


  • In looking at it, do you see any way to remotely set the "frequency scale offset" mode, either by the URL or otherwise?

  • @jks, thank you for your work! And what do you mean about "air-band Kiwi in Japan"? Did they have the same problem?

  • And what do you mean about "air-band Kiwi in Japan"?

    There are only 3 public Kiwis configured with a non-zero offset value. All are set to cover the VHF air-band. I was just checking that one of them still worked after getting the update.

  • I understood. One of this is my receiver. However, it is not exactly a Kiwi))) I'll test it when I get an update. Thanks!

  • Ah, okay, I did not realize this. When I release software early in the morning it is in the update "window" in Japan, so http://jp1odj-air.proxy.kiwisdr.com:8073/ often gets the update soon after release, which is convenient.

  • edited March 7

    I have FlyDogSDR. Updates will come in few days or more.

Sign In or Register to comment.