Would it be possible to signal the Kiwi to change frequency without restarting the session?

[rrobinett]

When the wsprdaemon schedule feature needs to change the receive band of a receiver, it currently kills the running session and starts a new kiwirecorder session on the new band. Doing that has the unfortunate side effect of missing recording of one complete WSPR packet during a schedule change.

So I wonder if it would be possible for kiwirecorder to signal a tuning change at the end of the current wav file recording?

[hcab14]

So I wonder if it would be possible for kiwirecorder to signal a tuning change at the end of the current wav file recording?

Sure that would be possible.

How should the information about the frequency change be propagated to kiwirecorder.py?

• read the contents of a given file before a new .wav file is created
• predefined schedule; in that case I'd propose to use a YAML file
• other ideas?

[rrobinett]

Hi Christoph, I want WD to be able to replicate the band-hopping feature recently introduced to the Kiwi. So while running Kiwirecorder with '--dt-sec=60' WD could communicate the settings for the next 60 second wav file recording by writing those settings to a configuration file which Kiwirecorder would read some time after second 50 and apply before beginning the next 60 second long recording. WD will only be changing the receive frequency, so the config file need not support all of the command line configuration controls. Would that be easy to implement? Thanks Rob

…

On Fri, Oct 8, 2021 at 12:41 PM Christoph Mayer ***@***.***> wrote: So I wonder if it would be possible for kiwirecorder to signal a tuning change at the end of the current wav file recording? Sure that would be possible. How should the information about the frequency change be propagated to kiwirecorder.py? - read the contents of a given file before a new .wav file is created - predefined schedule; in that case I'd propose to use a YAML file - other ideas? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#90 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIFAQZCOZVJCBGQ4LWWULWTUF5CODANCNFSM5FUB3Z5Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Rob Robinett AI6VN ***@***.*** mobile: +1 650 218 8896

[hcab14]

Hi Rob,

what do you think about adding an option which can be used instead of -f in which one can specify a number of YAML files. This makes it possible to record multiple streams in one kiwirecorder.py session as before. Whenever a new file is started (including the 1st one) the contents of the respective YAML file is read and applied.

As a start the YAML files will only contain the frequency, but this approach is flexible enough to enable changing more parameters in future if needed.

Christoph

[rrobinett]

Hi Christoph, WD currently invokes a separate instance of KWR for each configured Kiwi + WSPR band and keeps track of those instances, killing and invoking new KWR instances as directed by the schedule in the WD config file. That has kept schedule changes from disrupting bands which are not changed at schedule boundaries. That implementation seems to run very reliably and has minimal CPU burden, even on a Pi 3. If I understand your suggestion, I would invoke once instance of KWR and give it a list of YAML files, one for each rx session. At many WSPR receive sites there are multiple Kiwis: at KFS I have five Kiwis fed by 4 different antennas, so there are 24 simultaneous KWR listening sessions . If those YAML files included specifications for the Kiwi's IP address along with the band, then one instance could serve all the Kiwis. It would also be helpful if I could specify the desired Kiwi rx channel in each YAML file, as I have found error situations where intruders were taking over Kiwi channels and some of my 6 KWRE sessions ended up on one of the two waterfall channels. I assume that KWR would read the YAML files within a few seconds of the end of recording each wav file. That would give WD almost a minute to write out a new YAML file with settings for the following minute's recording. It would be nice if there were also a KWR status reporting mechanism, but I am using the kiwi's ./status web page to check on my KWR sessions which works well enough when I can associate a KWR session with an rx channel. I hope this discussion doesn't make my requirements seem too onerous. If so, then feel free to suggest what is simplest for you to implement. On a related topic, would it be possible to enhance the OV reporting mechanism by adding a timestamp and count to each OV line which is output by KWR? One of the valuable features of WD is documenting the number of overloads, but the current 'output a n'OV' to stdout reporting mechanism is awkward to use. thanks, rob

…

On Mon, Oct 11, 2021 at 9:52 AM Christoph Mayer ***@***.***> wrote: Hi Rob, what do you think about adding an option which can be used instead of -f in which one can specify a number of YAML files. This makes it possible to record multiple streams in one kiwirecorder.py session as before. Whenever a new file is started (including the 1st one) the contents of the respective YAML file is read and applied. As a start the YAML files will only contain the frequency, but this approach is flexible enough to enable changing more parameters in future if needed. Christoph — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#90 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIFAQZEWZAR4WRUL4N4QZULUGMI5HANCNFSM5FUB3Z5Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Rob Robinett AI6VN ***@***.*** mobile: +1 650 218 8896

[rikvanriel]

When the wsprdaemon schedule feature needs to change the receive band of a receiver, it currently kills the running session and starts a new kiwirecorder session on the new band. Doing that has the unfortunate side effect of missing recording of one complete WSPR packet during a schedule change.

It looks like the DigiSkimmer software does exactly what you want by importing the kiwiclient python files as a library, and calling the .set_mod() function with the new frequency parameter.