v1.592
From the CHANGE_LOG file:
v1.592 Apr 10, 2023
Reverted change causing NBFM distortion (thanks Glenn).
FT8/WSPR autorun preemption: A new menu on the autorun configuration section allows you to
specify if an autorun process is preemptible. I.e. a new incoming user connection will
kick the autorun process off the channel and take its place. Every 10 seconds autorun processes
will attempt to fill empty channels. Kiwirecorder connections should not interrupt preemptible
autoruns. Only Kiwi user connections. (thanks Martin)
WSPR extension:
Control panel height now set to 90% the height of the waterfall (thanks Eric).
Spot upload debugging: On the admin > extensions > WSPR page, when "Log spot debug info?" is
"Yes" then an additional line in the log will show the actual upload response from wsprnet.org
e.g. WSPR UPLOAD: wsprnet.org said: "1 out of 1 spot(s) added"
Upload debugging only works for WSPR autorun currently.
S-meter extension: Defaults for all control panel values can be set on the
Admin > Extensions > S-meter page (thanks Eric).
kiwiclient/kiwirecorder: Added support for URL redirection. Requires most recent version of
kiwirecorder and kiwi server v1.592 or later to be used (thanks loststation).
Kick reason: The admin control tab has a new field "Reason if kicked" that will be displayed in
a panel when a user connection is kicked. Previously a kicked connection would just stop with
no explanation (thanks Rob who suggested this some time ago I believe).
Internal connections (e.g. autorun) behavior w.r.t. disabled/kicked connections:
An internal connection will ignore the disabling of user connections and ignore the
global kick button (both on admin control tab). However individual internal connections can
still be kicked via the button on the admin status page.
Comments
Hi John,
Once again some excellent upgrades, especially the WSPR and FT mode autoruns.
This should allow even more use from the KiWi's when they would otherwise be unproductive.
The kick explanation panel is a good idea too, I've often wanted to tell users to behave themselves better when I've had to kick them off for various reasons.
Thanks again John you are a star :-)
Regards,
Martin
Unfortunately, preemption doesn't work if Kiwi uses a proxy service, a redirect loop ensues.
@ArturPL Can you be more specific about what conditions/setup you're talking about so I might be able to recreate this issue?
I've fixed the problem where a redirect incorrectly occurs when preemptible autorun processes exists. But I don't see where there is any kind of redirect "loop". Unless, of course, you have incorrectly setup a redirect loop/cycle to begin with (see the redirect instructions on the admin connect tab).
Hi John,
It also seems to stop the SNR measurement if all four channels are set as preemptable, and maybe there are no other users.
My private KiWi at home and one of my public ones have shown this behaviour.
Maybe the SNR measurement receiver needs to overide the preemptable ?
Regards,
Martin
My two KiWi's with SNR reporting problems are OK when only three channels are set aside for preemptable operation.
My other KiWi seems to be fine when all four channels being used for preemptable operation.
The only difference I can think of is that the one that works OK may be running Buster rather than Jessie, but I'm not 100% sure.
Regards,
Martin
Okay, I've got the SNR process now using the channel from a preemptible autorun. Next release..
Sorry I'm only replying now, but the holiday trip has been extended. When I wrote about looping, I meant that v.1.592 did not preempt slots and instead kiwi from proxies that work in loop A>B>C>D>A reacted properly because all slots were occupied. However, another receiver that I have without a proxy service available, preempted without a problem when I connected to it via the local network. If I connected via local IP to Kiwi with an active proxy service, I was redirected to the next sdr. Your quick release of 1.593 fixed this before I could reply here, for which of course thank you :)
The preemption modes are great, I've wished for that feature for some time. I see some of my KIWI's have varying autorun uptimes, showing preemptions and subsequent reconnections. Yet others only have a few running and several that didn't reconnect. If I manually run the autorun restart they do just that. Not doing anything unusual here. It has happened a few times but no pattern has emerged. Anyone else seeing this?
Yes I'm also observing this on one of my KiWi's running v1.594.
All four channels setup as preemptable, but only two running when there are no user connections.
Going to the extensions and forcing a autorun restart brings them back up.
I'm also still occasionally noticing 0dB SNR values when I first open up a receive session, then it seems to resolve itself. On one occasion I got a database update message, so I don't know if this is somehow related.
Nothing obvious seen in the log.
Regards,
Martin
Yeah, a bunch of problems here. Including a bug that causes FT8 itself to crash in certain circumstances when restarted after being preempted. Fix soon..
Okay, please make sure you're updated to v1.595 and let's see if these problems are fixed.
Seems like the update (many thanks for the quick update) did the job, all preempted channels returned fine. The only issue I see is that in my 8 channel configuration, some of the waterfall channels get used up so a new user gets the open channel but it might be one that isn't a waterfall one, as per the screengrab. I connected locally and got the RX7 i.e. a non waterfall channel. This might be a complex fix so I only mention this if it could be possible to shift RX0 over to RX7 and let the new user come into the RX0 waterfall slot.
I didn't look closely at the behavior for 8-ch configurations. I assumed the existing code that puts non-kiwi connections on ch2-7 first would work. But perhaps it doesn't..
I just discovered that my log is being completely overwritten with these lines, over and over:
Can I completely disable this? I do have the recent V1.595 update installed, and thought I deactivated these extentions, but the log is still being overwritten even after a reboot. My unit is set for three 20KHz channels, and is mostly private.
Thanks for pointing this out. v1.596 is available and should fix it. The good news is these messages were only part of the in-memory log and not the log kept on the filesystem.
Hi John,
Sorry, but I think I've found another problem, which is an unintended consequence of the preemptable decoders.
When selecting one of my KiWis that has all the channels setup as preemptable for use in a TDoA session it says that all channels are busy.
Removing one or more preemptable decoders to create some spare capacity fixes the problem.
I guess this is down to the way the TDoA selection works, as it doesn't 'reserve' a receive channel when a KiWi is selected for a TDoA, and it only connects for the duration of the session.
Maybe the TDoA extension needs to be able to recognise that preemptable receivers are in use rather than reporting that all of the receivers are busy.
I'm not sure if this also affects the display of available (not busy) KiWi's on the map used for their selection within the TDoA extension too.
Regards,
Martin
Okay, should be fixed in v1.597
TDoA goes through an extra check so it will "fail fast" if there are no channels. This is to avoid launching kiwirecorder only to have it fail a short time later because all the channels of a TDoA sampling host are full. But this extra check needed to take into account that preemptible now exist.
Just be sure to set the checkbox on the admin control tab that allows non-Kiwi connections to preempt autorun processes.
Hi John,
Great thanks.
I'm pleased it is set to on by default :-)
Regards,
Martin
using 1.598 on the 8 ch config, RX 0 and 1 still seem to be used up by the preemptible digital modes...
And as I tried to explain last time, this is not a bug. Provided the code is going to allow autorun processes to use the waterfall channels (rx0/rx1) at all. There are combinations of user connections arriving and leaving, and autorun restarting, that will result in the situation you show above.
The situation could be improved by implementing something that moves autoruns on rx0/rx1 to open channels on rx2-rx7 when they occur. But I'm not going to do that because such a scheme has lots of corner cases and unintended consequences, and frankly I'm sick of the whole thing.
What I'm going to do in the next release is simply not allow any autorun to ever use the waterfall channels (rx0/rx1) for the rx8_wf2 configuration. Autorun preemption will still occur in channels rx2-rx7
I certainly can see that trying to cover every combination is a complex one for sure. I think that solution will do the job fine, many thanks.
Hi John,
I'm sorry that my suggestion has caused you so much trouble.
Once again, it's one of those things that has unintended consequences, but I'm genuinely grateful for all of the hard work you have put in trying to unravel it all.
I can only hope that this additional use of the KiWi network, in what would otherwise have been unproductive downtime, will make you feel that your effort has been worthwhile.
Regards,
Martin