jks

About

Username
jks
Joined
Visits
32,325
Last Active
Roles
Member, Administrator, Moderator
Points
331
  • IQ Display of VLF stations no longer stable? [fixed in v1.344]

    Yeah, something is broken. I tried building older releases and discovered v1.296 (July 5) works. So now I'm going to have to painfully bisect all the versions in-between and figure out what's happened.

    Pretty much all those mil VLF stations use cesium (or better) frequency standards.
    WA2ZKDHB9TMC
  • Waterfall filtering? [added in v1.337]

    Today's v1.337 update adds waterfall filtering (averaging). The filtering methods and adjustments parallel those used for the spectrum filtering, although the range of slider values is slightly different based on practical experience. The waterfall and spectrum filtering are independently adjustable.
    PowernumptyHB9TMCG0LUJ
  • BeagleBone AI

    Below shows progress with an experiment to get a 14-channel configuration working using a BeagleBone AI. The challenge is to move as much processing to the second cpu core of the AI as possible so as not to impact the realtime requirements of serving the 14 audio channels (plus the usual 12-channel GPS etc.) It seems to work. A 14 audio DDC + 1 waterfall DDC configuration (rx14_wf1) was made to fit in the FPGA (LUTs now 97% full) by reducing the amount of CIC filtering logic slightly.

    Note below that the processor temperature and clock speed are displayed. The cores are currently running at rate automatically adjusted based on temperature between 1.0 - 1.5 GHz due to the reduced cooling configuration I'm testing.

    image

    The Kiwi's internal WSPR extension is running on all 14 channels as a worst-case test since WSPR decoding is so cpu intensive. The fact that this works does not change the fact that Rob's wsprdaemon is the superior solution for anything but casual WSPR monitoring. In fact 14 channels was chosen in support of getting a single Kiwi to work in an all-band wsprdaemon setup.

    Below is output from the Linux "ht" command. It shows how certain components of the software have been moved to new Linux processes separate from the main Kiwi process and "locked" to the second core of the processor. "kiwid" is the main process and is locked to cpu0 as seen in the "cpu" column. The other "kiwi.xxx" processes are locked to cpu1. Of interest here is the "kiwi.wsp" process which runs the collective WSPR decoding of all 14 channels.

    image

    This is just a progress report. There is a long list of work to do.
    PowernumptyChrisSmolinskiWA2ZKDHB9TMCKA7UG0LUJrz3dvpWA2TP
  • Kiwi BBAI software installation instructions [updated 4-Mar-24]

    The Kiwi repo "dev" and "master" branches are now closely synchronized again after dev having held the AI stuff exclusively for a long time. I think it will automatically revert to the usual update scheme because the current version number on the master branch (v1.338) is greater than what was in the last dev branch you manually pulled (335 or 336). So you shouldn't have to do anything I think.
    Powernumpty
  • wspr autorun is crashing my kiwi v1.337 [fixed in v1.338]

    Fixed in v1.338.
    Powernumpty
  • Waterfall filtering? [added in v1.337]

    Today's v1.337 update adds waterfall filtering (averaging). The filtering methods and adjustments parallel those used for the spectrum filtering, although the range of slider values is slightly different based on practical experience. The waterfall and spectrum filtering are independently adjustable.
    PowernumptyHB9TMCG0LUJ
  • Waterfall filtering? [added in v1.337]

    Today's v1.337 update adds waterfall filtering (averaging). The filtering methods and adjustments parallel those used for the spectrum filtering, although the range of slider values is slightly different based on practical experience. The waterfall and spectrum filtering are independently adjustable.
    PowernumptyHB9TMCG0LUJ
  • Reading signal strength from shell [option added to kiwirecorder]

    Okay, if you update to the latest kiwiclient / kiwirecorder then when in S-meter mode:

    "--dt-sec=sec" will average (as fast as possible) for that many seconds and then print a measurement result. This is different from "--s-meter=value_greater_than_zero" which averages for a specific number of averages. Naturally it is a conflict to use both --dt-sec > 0 and --s-meter > 0. If you are using --dt_sec you want --s-meter=0.

    "--ts", "--tstamp" or "--timestamp" will prefix the output with a timestamp. "--stats" works as before showing you the actual number of averages/sec obtained.

    Sample output. See the Makefile for command line examples.
    python kiwirecorder.py -s kiwi -p 8074 --s-meter=0 --ts --dt-sec=2 --tlimit=10 --stats
    26-Oct-2019 19:24:32 UTC RSSI: -111.2 3.0 meas/sec
    26-Oct-2019 19:24:34 UTC RSSI: -111.2 6.0 meas/sec
    26-Oct-2019 19:24:36 UTC RSSI: -111.2 6.0 meas/sec
    26-Oct-2019 19:24:38 UTC RSSI: -111.2 5.0 meas/sec
    26-Oct-2019 19:24:40 UTC RSSI: -110.9 6.0 meas/sec
    5.9 meas/sec
    
    WA2ZKDbensonHB9TMC
  • Reading signal strength from shell [option added to kiwirecorder]

    Okay, if you update to the latest kiwiclient / kiwirecorder then when in S-meter mode:

    "--dt-sec=sec" will average (as fast as possible) for that many seconds and then print a measurement result. This is different from "--s-meter=value_greater_than_zero" which averages for a specific number of averages. Naturally it is a conflict to use both --dt-sec > 0 and --s-meter > 0. If you are using --dt_sec you want --s-meter=0.

    "--ts", "--tstamp" or "--timestamp" will prefix the output with a timestamp. "--stats" works as before showing you the actual number of averages/sec obtained.

    Sample output. See the Makefile for command line examples.
    python kiwirecorder.py -s kiwi -p 8074 --s-meter=0 --ts --dt-sec=2 --tlimit=10 --stats
    26-Oct-2019 19:24:32 UTC RSSI: -111.2 3.0 meas/sec
    26-Oct-2019 19:24:34 UTC RSSI: -111.2 6.0 meas/sec
    26-Oct-2019 19:24:36 UTC RSSI: -111.2 6.0 meas/sec
    26-Oct-2019 19:24:38 UTC RSSI: -111.2 5.0 meas/sec
    26-Oct-2019 19:24:40 UTC RSSI: -110.9 6.0 meas/sec
    5.9 meas/sec
    
    WA2ZKDbensonHB9TMC
  • Reading signal strength from shell [option added to kiwirecorder]

    Okay, if you update to the latest kiwiclient / kiwirecorder then when in S-meter mode:

    "--dt-sec=sec" will average (as fast as possible) for that many seconds and then print a measurement result. This is different from "--s-meter=value_greater_than_zero" which averages for a specific number of averages. Naturally it is a conflict to use both --dt-sec > 0 and --s-meter > 0. If you are using --dt_sec you want --s-meter=0.

    "--ts", "--tstamp" or "--timestamp" will prefix the output with a timestamp. "--stats" works as before showing you the actual number of averages/sec obtained.

    Sample output. See the Makefile for command line examples.
    python kiwirecorder.py -s kiwi -p 8074 --s-meter=0 --ts --dt-sec=2 --tlimit=10 --stats
    26-Oct-2019 19:24:32 UTC RSSI: -111.2 3.0 meas/sec
    26-Oct-2019 19:24:34 UTC RSSI: -111.2 6.0 meas/sec
    26-Oct-2019 19:24:36 UTC RSSI: -111.2 6.0 meas/sec
    26-Oct-2019 19:24:38 UTC RSSI: -111.2 5.0 meas/sec
    26-Oct-2019 19:24:40 UTC RSSI: -110.9 6.0 meas/sec
    5.9 meas/sec
    
    WA2ZKDbensonHB9TMC