V1 653

PE1OPQPE1OPQ
in Software release information

hi

I see that from V1 649 the dBm display is no longer correct. There is a difference of 6 to 8 dBm between what the value should really be.

Also, playback in Fire Fox stops after a few minutes.

Do more people have this problem?

Comments

  • jksjks

    I see that from V1 649 the dBm display is no longer correct. There is a difference of 6 to 8 dBm between what the value should really be.

    Which dBm display? S-meter or spectrum?

    The history of the audio gain problems (hence S-meter) is summarized in the image below (thanks HB9VQQ/K and wspr.live). At the time of v1.647 it wasn't understood that the true gain reduction was 4.5 dB. So it took a couple of tries to get it back to normal.

    v1.647_4.5dB.png


    Also, playback in Fire Fox stops after a few minutes.

    Anyone else having that problem? I'm not.

  • PE1OPQPE1OPQ

    I look at the dBm meter, never the S meter :-)

    I run a station on 918 KHz and use the kiwi as a distance meter.

    The correct dBm is min 48 dBm but it is now around min 43 dBm


    Theo

  • G8JNJG8JNJ

    Just checked mine with a signal generator and CW setting on the KiWi, and it is reading correctly at frequencies >10MHz, but it does vary slightly across the whole range.

    The worst case being 2dB low at 1MHz.

    I'm using an S-Meter calibration of -18dB and a waterfall of -13dB, I haven't changed these since I performed the initial calibration some time ago.

    Beware if you are using AM that the bandwidth and modulation can affect the measured level, also sometimes broadcast stations run on reduced power for various reasons (one being transmitter maintenance if they are running pairs) and can use dynamic carrier control to improve efficiency and reduce power consumption (generally only the high power ones).

    No problems with Firefox either.

    Regards,

    Martin (ex Broadcast Transmission Engineer)

  • jksjks

    As Martin points out, be sure the S-meter calibration value on the admin page, config tab, hasn't changed somehow.

  • n6gnn6gn

    Trying to update both a local and a remote KiwiSDR to 1.653 in order to compare reported frequency of a known OTA FST4W LOS signal to see how much error a 66.66 MHz clock introduces with the newest code.

    The local seems to be proceeding OK but the remote seems unhappy with the amount of space on the SD card, if I understand this correctly. It refuses to proceed:

    >      colordiff -br $(GITDIFF_EXCLUDE2) ../../../sdr/KiwiSDR/$(REPO_NAME) . || true
1692,1693c1744,1745
< # DANGER: "count=2400M" below (i.e. 1.6 GB) must be larger than the partition size (currently ~2.1 GB)
< # computed by the tools/kiwiSDR-make-microSD-flasher-from-eMMC.sh script.
---
> # DANGER: "DD_SIZE := 2700M" below must be ~200 MB larger than the partition "used" size
> # (currently ~2.5 GB) computed by the "d.mb" command alias.
1697,1698c1749,1752
< DEBIAN_VER := 10.11
< USE_MMC := 0
---
> DISTRO_DEBIAN_VER := 11.7
> SD_CARD_MMC := 0
> DD_SIZE := 2700M
> 
1703c1757,1758
<      @echo "CAUTION: USE_MMC = $(USE_MMC) -- VERIFY THIS ABOVE"
---
>      @echo "CAUTION: SD_CARD_MMC = $(SD_CARD_MMC)"
>      @echo "CAUTION: VERIFY FROM THE LIST ABOVE THAT THE SD CARD IS THE MMC NUMBER SHOWN"
1708,1709c1763,1764
<      dd if=/dev/mmcblk$(USE_MMC) bs=1M iflag=count_bytes count=2400M | xz --verbose > ~/KiwiSDR_$(VER)_BBB_Debian_$(DEBIAN_VER).img.xz
<      sha256sum ~/KiwiSDR_$(VER)_BBB_Debian_$(DEBIAN_VER).img.xz
---
>      dd if=/dev/mmcblk$(SD_CARD_MMC) bs=1M iflag=count_bytes count=$(DD_SIZE) | xz --verbose > ~/KiwiSDR_$(VER)_BBB_Debian_$(DISTRO_DEBIAN_VER).img.xz
>      sha256sum ~/KiwiSDR_$(VER)_BBB_Debian_$(DISTRO_DEBIAN_VER).img.xz
======== version check complete

    Am I understanding this correctly? If so, what do you suggest?

  • jksjks

    So, the diff of /root/Beagle_SDR_GPS/Makefile that you're showing there, has nothing to do with anything.

    Those differences are for the Makefile target called create_img_from_sd: which is something only I use when creating the Kiwi distro image files on the website. Nothing in that target gets run when a normal Kiwi update occurs.

    What's the actual error you are getting on your remote Kiwi?

  • n6gnn6gn

    OK, didn't know how you used the diff.

    But that's the end of an attempted update on the console. Nothing more happens, no update and no error other than it didn't update. The local Kiwi updated fine.

    I can send you the entire console output if it helps.

  • jksjks
    edited January 11

    The messages from the build are not contained in the console log. They are contained in a separate file called /root/build.log

    So from the admin console tab you could do a cat ../build.log and email me that entire output (very long). However the file is overwritten every time an update check occurs. So the messages from the particular build that failed may not remain. You might have to force another manual build and then collect the file content soon after that.

    Also, what version is this Kiwi currently running?

  • n6gnn6gn

    It's on a remote with v1.616 and external GNSSDO 66.66 MHz clock. I was attempting to update it but have since thought better of the idea and done some experiments on a similar system here at the QTH, looking at boundary spurs and phase noise.

    Running with an external GNSS reference at 66.672 MHz and the Kiwi:config alerted to that fact, I find everything fine. Groundwave NIST transmissions show a stable dot on the IQ extension at WWV25.

    Then to see how baseband fared I pointed wsprdaemon's schedule at it and measured a local 14 MHz QDX also having a GNSS reference and believed to be quite accurate. wsprdaemon was configured with the 'standard' SPOT_FREQ_ADJ_HZ=".1" correction left engaged from before the ADC clock QSY.

    The new report, (with only 100 milliHz resolution) was 200 mHz low. This is against your stated expectation of about 250 millHz error so the standing 100 mHz of correction shouldn't actually matter. Without more study it is difficult to say more.

    Since I can't get physical access to the remote to change the clock easily (it's a Bodnar rather than my own networked REference) I realized I really don't want to change things up there until Springtime anyway. Temperature is headed for -24C/-10F down here in the next few days and I expect up there it will be even colder. I hope NZ is warmer than this!

    build.log sent via email.

    Glenn n6gn

  • WA2TPWA2TP

    I am just noticing that if you navigate to the kiwi status page, ADC OV counter function does not appear to be working in version 1.653.

    Is anyone else seeing this?

    None of my 7 Kiwi which are generally hit with ADC OV during morning an evening hours, are no longer showing any ADC OV's after being up for just under a week.

  • jksjks
    edited January 14

    Hmm. Might be a bug from adding the RF attn reminder indicator (Kiwi-2 only). Let me check.

  • jksjks
    edited January 14

    Okay, should be fixed in v1.657.

    Thanks for spotting this!

Sign In or Register to comment.