It turns out that in 14 rx channel mode it appears to reduce the GPS channels to 10 to recover some CPU utilization. One of mine that was upgraded to 1.649 was an 8 rx channel mode and the other was 14rx mode.
When I switch the 14rx kiwi to 8 channel mode, it shows 12 GPS channels as it should(?)
Still the noise level on 10m is quite a bit lower (~5dbm based on kiwi display) than when I connect a kiwi running v 1.622.
As a note, All of my Kiwi are on BBAI - regardless of rx mode that they are in.
Thanks for the recovery, ZL4VO. Lesson learned: don't push buttons, just do what worked last time & maybe this won't happen again. This reminds me of a past life developing application-specific SDRs for a former employer & how scared they were of doing a software download that could potentially brick their entire pay-TV business... and the longer that went on, the more driver/middleware/applications bugs conspired with how my upstream colleagues insisted on interpreting things-DVB to make things even worse. I need to find a hobby that isn't so much of a busman's holiday...
I'm blocked in most directions so GPS reception is always marginal here & that makes it hard to judge anything, but after ~11 hours I would expect a bit more of a trail to be painted on the az/el plot than there is on mine right now.
After more careful measurement, v1.650 changes the CIC compensation filter gain correction from +3 to +4.5 dB. This is more in line with what people are seeing who do long term recording of their noise floor. The S-meter now shows the 1/10 dB digit when the value is greater than -100 dB.
The initial guess that the gain was off by 3 dB due to the change in decimation-by-2 is not quite right. What has actually changed is the gain of the two cascaded CIC stages the Kiwi audio DDC uses. This is because the decimation values changed to get the higher sample rate (2x). Previously the decimation was R1=505, R2=11 giving a total decimation of 505*11=5555, or 66.66M/5555=12k. Now, because we need 24k instead of 12k, it is R1=926, R2=3, 926*3=2778, 66.66M/2778=~24k.
CIC gain is pow((R*M), N), where M=1, and N=3 for R1 and N=5 for R2. I tried to work the numbers a few ways but never did get 4.5 dB out of that. So it's still TBD.
Sorry to add to your pain, and this really isn't urgent, but it may give a clue regarding side effects of the latest updates.
I noticed that when listening to AM broadcast stations that carry phase modulated data, such as the now defunct France Inter on 162kHz, or the soon-to-be defunct BBC Radio 4 on 198kHz, there is a very distinct low frequency 'fluttering;' type effect that can be heard modulating the carrier when the phase changes occur.
This is noticeable on both my Wessex KiWi's that are now running v1.650, but it was on the other versions post v1.647 ?
@WA2TP With v1.650 the noise floor level should return to "normal", i.e. about +4.5 dB higher than the drop that started with v1.647 when the anti-imaging filter was added. Yes, the reduction from 12 to 10 GPS channels only applies to the "rx14" mode available to multi-core hosts (BBAI, BBAI-64, etc.)
I spent the entire day yesterday bisecting the code from well before v1.647 to the present. As far as I can tell the basic GPS is functioning normally (including ADC clock correction). It's a bit difficult because my antenna sees less than half the sky so I get a lot of GDOP errors if the sats are positioned poorly.
What doesn't work apparently is the GPS time-stamping in the audio stream. Christoph is going to look at this, but he's on holiday for a while. I'll keep looking myself.
@G8JNJ Martin, I think something is up with the Wessex site. I see the issue you mentioned. But I can't find it anywhere else on Kiwis running pre-v1.647, 649 or 650, in the UK or France. Do you also note the attenuation drops every 12 seconds or so if, for example, you listen to the MSK on 62.6?
At first I thought the 1 second gain reduction every 14 seconds could have been an antenna fault, as it us very wet and windy over here, so I switched over to the reserve, and it is still occurring.
All the sdr's are fed from the same antenna and distribution amplifier and are passively split.
The two KiWi's are fed from one passive mini-circuits splitter, which in turn is fed from a four way, one of the other four way outputs feeds the Flydog at a slightly higher level, which is not exhibiting the gain reductions (or the same amount of phase flutter).
Tomorrow I'll try remotely switching off each of the KiWi's in turn to see if they are in some way interacting with each other. I really hope it isn't a fault at the site, as the weather here is pretty awful at the moment, and I don't fancy a trip up the hill.
It could of course be the two resident mice playing tricks on me, because I prodded their nest the last time I was on site, but to do it every 14 seconds seems unlikely unless they have a metronome.
Hmm, I did plug in two ultrasonic pest repellers on my last visit, I wonder if it could be them and the mice really are getting their revenge. Karma I guess...
If by "dropouts" you mean the periods when the audio goes silent and the waterfall goes black on the first (rx0) channel (just to be precise), it started with the v1.647 release and was fixed in v1.648.
The level problem wasn't completely fixed until v1.650
"Significant impact" is overstated I think. The wsprdaemon forum seems happy the problem is fixed. And there is so much junk in the wsprnet.org database that it hardly matters..
1.650 reads-72.8 dBm for my -73 dBm at 14.1 MHz source which is well below the measurement uncertainty of my old S-Meter calibrator. Noise in 10 kHz is similarly very close to expected, but of course noisy.
I have remotely experimented with the sdr's at Wessex, with no obvious conclusions.
The antenna and distribution amplifier are not the problem.
I have turned off as many individual items of equipment as possible, and the problem (although slightly reduced) remains.
Here is an S-Meter plot from the KiWi using CW
You can see the distinct amplitude dips at 7 & 14 second intervals, plus the phase related amplitude perturbations.
And one from the Flydog, fed from the same distribution system, with very slight amplitude dips and minor ripple.
I can't remotely switch off the ultrasonic rodent repellers, so it could be those somehow coupling into the system, as these are the only things I've added at the site in resent times. But it seems unlikely.
you should be able to determine if this is a problem internal to the KiwiSDR by using the signal generator, e.g., running the signal generator in RX0 and S_meter in either of RX1,2,3.
Yes it is very odd, but it must be something on the site.
It only affects the signal level and noise floor on frequencies below a few hundred kHz.
My suspicion is either the ultrasonic pest repellers or the electricity smart meter, but I added hard wired mains filters on the internal building wiring at the main distribution box, so neither of them should be a problem.
All the sdr's run from separate mains power supplies, which I can switch remotely, and this afternoon I turned off everything that I could without loosing connection to the KiWi V1, but the problem remained. It must be an earth loop or similar, as it is really only affecting just the two KiWis that share the same two way mini-circuits passive splitter.
I think it will have to wait for my next site visit, so it may be some time before I can resolve the issue.
1.649 seems to have made what I'm now calling the lip sync problem worse - can't go for more than ~2 hours before the audio as-presented differs from real-time+KiwiSDR-latency.
And that's after supposedly eliminating resampling in Python as an issue... which in itself made the lip sync problem worse: now at most can go two days, but one can just about set your watch from the daily 0625 GMT KiwiSDR glitch that trips up both kiwiclientd as well as kiwirecorder.
How to roll back to aliases? They're more preferable to the perpetual lip sync stumbles that one might not necessarily experience when it only needs to work for two minutes max....
I see a definite difference in the frequency of occurence of the lip sync problem since going from 1.620 to 1.649
Despite using what's apparently the dogs' bollocks of resamplers, it's back to maybe-2-hours-if-you're-lucky. It had been maybe-2-days-but-usually-just-1 with 1.620
Because the 0625 GMT glitch trips up kiwiclientd/kiwirecorder, my gut feeling is that the root cause of the lip sync issue is something not being there when it needs to be - just like, for instance, how pulling down the logs to see if PLA Unltd has succeeded yet at hacking my admin password or what else they're up to from where ever they're popping up from now (lately there's been a G-based IP address of Jack Ma's cloud that causes my Kiwi to reboot every time that IP rears its ugly head) can cause all users to be booted off, the DTs to jump, etc. Ironic to see what's going on, I induce the very problem I'm chasing.
So, rolling back I'm PRETTY DARN SURE (caps for emphasis) will at least put the lip sync problem back to where it was BEFORE 1.649 clearly made it WORSE.
Even with the ultimate solution to resampling with 1.620, I can stop-start kiwiclientd instances & have the DTs jump back. Sox also sux at fractional resampling, apparently. I now suspect that if it weren't for the Kiwi's screwball output sample rate, there would be no resampling issue at all. But that's just a hunch. I'm just a hardware guy who used to work very closely with STB vendors to get to the bottom of problems they didn't even know they had once I manged to convince them something wasn't quite right (that was always the hardest part).
And to top it all off, getting back will require more effort after the pahlava getting it to 1.649 in the first place. So I dunno what to do... other than scream yet again, which eventually you'll be able to hear long path from ZL as the frustrations only seem to increase. And it's still too early for a beer. Or six. ;^)
It appears to be happening on all carriers below ~1 MHz (Just as the longer periodic attenuation variation), the lower the frequency and the stronger the signal, the better audible. Towards 1 MHz it isn't audible anymore but visible in the audio FFT (using audacity).
It is an amplitude modulation of about 7.5 Hz with harmonics
Thanks for all your contributions, but I just wish to emphasise this is NOT a problem with the KiWi's, either V1 or V2.
It is something in, or close to, the Wessex hilltop site that is causing these strange effects. Earlier today it was much better and then became much worse, and then back to not quite so bad. Some of the LF signals go down in strength for about a second at 14 second intervals, whilst other IMD signals around 500kHz go up in strength.
The weather has been quite bad over the past week, and it is possible that something has been disturbed.
It could be something like rusty fencing moving around, as I have seen this before at Weston, but the regular interval suggests it is not the case this time.
I swapped the antenna over to the reserve, switched other items of equipment on and off, switched the distribution amplifier in and out of circuit, and checked the spectrum for strong out-of-band signals, but the issue still remains.
I have some theories about what it could be, and I have performed as much remote testing as I can. But it now requires a visit to the site, to see if I can identify any physical problems, such as loose or corroded connectors, faulty power supplies, etc.
Another morning & all local kiwiclient users, per Sod's Law, were hobbled by the lip sync issue shortly after I had gone to sleep.
Right - if there was some question whether or not my Kiwi would take an update after whatever it took to get it up to 1.649 from 1.620 - wouldn't it make sense to see that through? Then at least there would be something to come out of the time spent.
Since all versions prior-to-1.647 enjoy the lip sync issue, ultimately there is still the problem where once the audio goes off on walkabout, the only way to perhaps "correct" it is to kick the user. And it may need to be done several times before the audio reverts to where it should be because sox sometimes just doesn't want to cooperate (seems the better the resampler, the more difficult it is to get it back in-sync once everything steps out of line - solving one problem creates another... this is just soooooo much fun! ;^).
Right now, the only way to recover from the lip sync issue is for me to wake up & look at a computer or smartphone screen & then do something on one of them when I'm not firing on all four cylinders. Night/dark mode & reducing the amount of blue doesn't seem to help - once I look at it, that's it... I'm buggered. I end up with both not enough sleep as well as self-induced jetlag.
An admin user kick does not cause kiwiclientd to report to JTDX that the tuned frequency changed to 0 Mc & then back again, so the JT-mode hash tables don't get binned as they are on band changes in hopes of avoiding the inevitable hash collisions of the way-too-short-for-purpose 10 & 12-bit hashes.
Is there some way I could do an admin kick that I could automate? Then I could do an hourly series of kicks as preventative maintenance & lump it for now after seeing if my Kiwi will download 1.651... and more importantly would also allow me to not have to make sure I'm free to recover from the near-daily 0625 GMT KiwiSDR keel over.
Perhaps the addition of some type of watchdog feature, selectable from the admin page, might be a good option? This would allow us to enable or disable the automated kick if that were implemented?
After a very chilly site visit and a lot of messing around, I have found (but not cured) the low frequency 14 second noise / loss of sensitivity problem at Wessex.
It seems to be noise being introduced by one of the other SDR's on site (OpenWebRX & RTL dongles), which share the same passive splitters as the KiWi V1 & 2, Flydog and websdr.
For some reason (and it is not at all clear) the noise is strong enough to overcome the splitter port isolation and find its way on to the KiWi's.
Swapping splitter ports, moving cables and equipment around, all seem to make it either slightly better or slightly worse, but I can't get rid of it unless I unplug all the other kit, so for the time being the problem remains.
I tried swapping the RTL dongles for a different version, but that just introduced other problems.
It was too cold to stay on site for a lengthy period, so I have decided to see if I can replicate it in the workshop at home, and see if I can figure out how to best resolve the issues.
Comments
Same here Martin, when cheking this morning after the V1.648 update. Not sure though if this already happened earlier with the introdution of V1.647.
Cheers, Ben
@VR2BG Okay, running v1.649 now.
@G8JNJ Yes, broken for me too. I'll look at it when I can (it's 1:30 AM for me now..)
Hi John,
Nothing is urgent, so please get some rest.
Thanks for your continued hard work and this latest fix, which seems to have resolved a long-standing problem.
Regards,
Martin
Just updated 2 of my 7 kiwi to v 1.649.
One is showing 12 GPS channels while the other is showing 10. (Not locks, but actual channels)
Not trying to be vague however something is not right.
Nosie floor on 29MHz is 5dbm lower on the unit showing 12 GPS channels. GPS is way way off from all other 5 units running version 1.622
Agreed something is not right.
All of mine have updated OK, still with 12 GPS channels and the same level of noise floor.
Regards,
Martin
It turns out that in 14 rx channel mode it appears to reduce the GPS channels to 10 to recover some CPU utilization. One of mine that was upgraded to 1.649 was an 8 rx channel mode and the other was 14rx mode.
When I switch the 14rx kiwi to 8 channel mode, it shows 12 GPS channels as it should(?)
Still the noise level on 10m is quite a bit lower (~5dbm based on kiwi display) than when I connect a kiwi running v 1.622.
As a note, All of my Kiwi are on BBAI - regardless of rx mode that they are in.
Thanks for the recovery, ZL4VO. Lesson learned: don't push buttons, just do what worked last time & maybe this won't happen again. This reminds me of a past life developing application-specific SDRs for a former employer & how scared they were of doing a software download that could potentially brick their entire pay-TV business... and the longer that went on, the more driver/middleware/applications bugs conspired with how my upstream colleagues insisted on interpreting things-DVB to make things even worse. I need to find a hobby that isn't so much of a busman's holiday...
I'm blocked in most directions so GPS reception is always marginal here & that makes it hard to judge anything, but after ~11 hours I would expect a bit more of a trail to be painted on the az/el plot than there is on mine right now.
73, VR2BG.
After more careful measurement, v1.650 changes the CIC compensation filter gain correction from +3 to +4.5 dB. This is more in line with what people are seeing who do long term recording of their noise floor. The S-meter now shows the 1/10 dB digit when the value is greater than -100 dB.
The initial guess that the gain was off by 3 dB due to the change in decimation-by-2 is not quite right. What has actually changed is the gain of the two cascaded CIC stages the Kiwi audio DDC uses. This is because the decimation values changed to get the higher sample rate (2x). Previously the decimation was R1=505, R2=11 giving a total decimation of 505*11=5555, or 66.66M/5555=12k. Now, because we need 24k instead of 12k, it is R1=926, R2=3, 926*3=2778, 66.66M/2778=~24k.
CIC gain is pow((R*M), N), where M=1, and N=3 for R1 and N=5 for R2. I tried to work the numbers a few ways but never did get 4.5 dB out of that. So it's still TBD.
Hi John,
Sorry to add to your pain, and this really isn't urgent, but it may give a clue regarding side effects of the latest updates.
I noticed that when listening to AM broadcast stations that carry phase modulated data, such as the now defunct France Inter on 162kHz, or the soon-to-be defunct BBC Radio 4 on 198kHz, there is a very distinct low frequency 'fluttering;' type effect that can be heard modulating the carrier when the phase changes occur.
This is noticeable on both my Wessex KiWi's that are now running v1.650, but it was on the other versions post v1.647 ?
http://wessex.zapto.org:8073
http://wessex.zapto.org:8074
It is not noticeable on the co-sited Raspi/ Flydog running a much earlier version.
http://wessex.hopto.org:8075
Could it be that the KiWi I/Q balance needs to be adjusted or otherwise recalibrated following the changes ?
Regards,
Martin
@G8JNJ Okay, I'll take a listen for that today.
@WA2TP With v1.650 the noise floor level should return to "normal", i.e. about +4.5 dB higher than the drop that started with v1.647 when the anti-imaging filter was added. Yes, the reduction from 12 to 10 GPS channels only applies to the "rx14" mode available to multi-core hosts (BBAI, BBAI-64, etc.)
I spent the entire day yesterday bisecting the code from well before v1.647 to the present. As far as I can tell the basic GPS is functioning normally (including ADC clock correction). It's a bit difficult because my antenna sees less than half the sky so I get a lot of GDOP errors if the sats are positioned poorly.
What doesn't work apparently is the GPS time-stamping in the audio stream. Christoph is going to look at this, but he's on holiday for a while. I'll keep looking myself.
@G8JNJ Martin, I think something is up with the Wessex site. I see the issue you mentioned. But I can't find it anywhere else on Kiwis running pre-v1.647, 649 or 650, in the UK or France. Do you also note the attenuation drops every 12 seconds or so if, for example, you listen to the MSK on 62.6?
Hi John,
Thanks for spotting that, it's all very odd.
At first I thought the 1 second gain reduction every 14 seconds could have been an antenna fault, as it us very wet and windy over here, so I switched over to the reserve, and it is still occurring.
All the sdr's are fed from the same antenna and distribution amplifier and are passively split.
The two KiWi's are fed from one passive mini-circuits splitter, which in turn is fed from a four way, one of the other four way outputs feeds the Flydog at a slightly higher level, which is not exhibiting the gain reductions (or the same amount of phase flutter).
Tomorrow I'll try remotely switching off each of the KiWi's in turn to see if they are in some way interacting with each other. I really hope it isn't a fault at the site, as the weather here is pretty awful at the moment, and I don't fancy a trip up the hill.
It could of course be the two resident mice playing tricks on me, because I prodded their nest the last time I was on site, but to do it every 14 seconds seems unlikely unless they have a metronome.
Hmm, I did plug in two ultrasonic pest repellers on my last visit, I wonder if it could be them and the mice really are getting their revenge. Karma I guess...
Regards,
Martin
Hi John,
Thank you for all of your work on this.
The one question I do have, is, do we know when or about what version the audio dropouts began?
This appears to have a significant impact on WSPRDAEMON.
Thank you again
Tom
If by "dropouts" you mean the periods when the audio goes silent and the waterfall goes black on the first (rx0) channel (just to be precise), it started with the v1.647 release and was fixed in v1.648.
The level problem wasn't completely fixed until v1.650
"Significant impact" is overstated I think. The wsprdaemon forum seems happy the problem is fixed. And there is so much junk in the wsprnet.org database that it hardly matters..
1.650 reads-72.8 dBm for my -73 dBm at 14.1 MHz source which is well below the measurement uncertainty of my old S-Meter calibrator. Noise in 10 kHz is similarly very close to expected, but of course noisy.
I like the extra displayed resolution.
Hi John,
I have remotely experimented with the sdr's at Wessex, with no obvious conclusions.
The antenna and distribution amplifier are not the problem.
I have turned off as many individual items of equipment as possible, and the problem (although slightly reduced) remains.
Here is an S-Meter plot from the KiWi using CW
You can see the distinct amplitude dips at 7 & 14 second intervals, plus the phase related amplitude perturbations.
And one from the Flydog, fed from the same distribution system, with very slight amplitude dips and minor ripple.
I can't remotely switch off the ultrasonic rodent repellers, so it could be those somehow coupling into the system, as these are the only things I've added at the site in resent times. But it seems unlikely.
It is all very odd.
Regards,
Martin
To get back to the updates.
I also very much like the additional dBm resolution and the orange 'Attenuation' indicator.
Thanks,
Martin
Hi @G8JNJ ,
you should be able to determine if this is a problem internal to the KiwiSDR by using the signal generator, e.g., running the signal generator in RX0 and S_meter in either of RX1,2,3.
73s, Christoph
On the Wessex Kiwi-2 the rx0 sig gen sounds/looks fine. Simultaneously rx1 on 162 kHz still shows the problem.
Yes it is very odd, but it must be something on the site.
It only affects the signal level and noise floor on frequencies below a few hundred kHz.
My suspicion is either the ultrasonic pest repellers or the electricity smart meter, but I added hard wired mains filters on the internal building wiring at the main distribution box, so neither of them should be a problem.
All the sdr's run from separate mains power supplies, which I can switch remotely, and this afternoon I turned off everything that I could without loosing connection to the KiWi V1, but the problem remained. It must be an earth loop or similar, as it is really only affecting just the two KiWis that share the same two way mini-circuits passive splitter.
I think it will have to wait for my next site visit, so it may be some time before I can resolve the issue.
Regards,
Martin
1.649 seems to have made what I'm now calling the lip sync problem worse - can't go for more than ~2 hours before the audio as-presented differs from real-time+KiwiSDR-latency.
And that's after supposedly eliminating resampling in Python as an issue... which in itself made the lip sync problem worse: now at most can go two days, but one can just about set your watch from the daily 0625 GMT KiwiSDR glitch that trips up both kiwiclientd as well as kiwirecorder.
How to roll back to aliases? They're more preferable to the perpetual lip sync stumbles that one might not necessarily experience when it only needs to work for two minutes max....
73, VR2BG.
I can roll yours back. But I doubt it will change anything. The FIR adds a delay of 1.2 microseconds.
Send email to support@kiwisdr.com when you're ready and have changed the admin pwd to what you had previously.
I see a definite difference in the frequency of occurence of the lip sync problem since going from 1.620 to 1.649
Despite using what's apparently the dogs' bollocks of resamplers, it's back to maybe-2-hours-if-you're-lucky. It had been maybe-2-days-but-usually-just-1 with 1.620
Because the 0625 GMT glitch trips up kiwiclientd/kiwirecorder, my gut feeling is that the root cause of the lip sync issue is something not being there when it needs to be - just like, for instance, how pulling down the logs to see if PLA Unltd has succeeded yet at hacking my admin password or what else they're up to from where ever they're popping up from now (lately there's been a G-based IP address of Jack Ma's cloud that causes my Kiwi to reboot every time that IP rears its ugly head) can cause all users to be booted off, the DTs to jump, etc. Ironic to see what's going on, I induce the very problem I'm chasing.
So, rolling back I'm PRETTY DARN SURE (caps for emphasis) will at least put the lip sync problem back to where it was BEFORE 1.649 clearly made it WORSE.
Even with the ultimate solution to resampling with 1.620, I can stop-start kiwiclientd instances & have the DTs jump back. Sox also sux at fractional resampling, apparently. I now suspect that if it weren't for the Kiwi's screwball output sample rate, there would be no resampling issue at all. But that's just a hunch. I'm just a hardware guy who used to work very closely with STB vendors to get to the bottom of problems they didn't even know they had once I manged to convince them something wasn't quite right (that was always the hardest part).
And to top it all off, getting back will require more effort after the pahlava getting it to 1.649 in the first place. So I dunno what to do... other than scream yet again, which eventually you'll be able to hear long path from ZL as the frustrations only seem to increase. And it's still too early for a beer. Or six. ;^)
73, VR2BG.
Dear All,
Here in Trémolat (France), the 162kHz signal is very stable, both in AM and in CW (V1.649.
Best regards and Happy New Year 2024, all my best wishes.
@VR2BG I can roll yours back. Send email to support@kiwisdr.com when you're ready and have changed the admin pwd to what you had previously.
@G8JNJ
It appears to be happening on all carriers below ~1 MHz (Just as the longer periodic attenuation variation), the lower the frequency and the stronger the signal, the better audible. Towards 1 MHz it isn't audible anymore but visible in the audio FFT (using audacity).
It is an amplitude modulation of about 7.5 Hz with harmonics
Are there other public kiwi 2's?
Hi All,
Thanks for all your contributions, but I just wish to emphasise this is NOT a problem with the KiWi's, either V1 or V2.
It is something in, or close to, the Wessex hilltop site that is causing these strange effects. Earlier today it was much better and then became much worse, and then back to not quite so bad. Some of the LF signals go down in strength for about a second at 14 second intervals, whilst other IMD signals around 500kHz go up in strength.
The weather has been quite bad over the past week, and it is possible that something has been disturbed.
It could be something like rusty fencing moving around, as I have seen this before at Weston, but the regular interval suggests it is not the case this time.
I swapped the antenna over to the reserve, switched other items of equipment on and off, switched the distribution amplifier in and out of circuit, and checked the spectrum for strong out-of-band signals, but the issue still remains.
I have some theories about what it could be, and I have performed as much remote testing as I can. But it now requires a visit to the site, to see if I can identify any physical problems, such as loose or corroded connectors, faulty power supplies, etc.
I still blame the resident mice though...
Regards,
Martin
Another morning & all local kiwiclient users, per Sod's Law, were hobbled by the lip sync issue shortly after I had gone to sleep.
Right - if there was some question whether or not my Kiwi would take an update after whatever it took to get it up to 1.649 from 1.620 - wouldn't it make sense to see that through? Then at least there would be something to come out of the time spent.
Since all versions prior-to-1.647 enjoy the lip sync issue, ultimately there is still the problem where once the audio goes off on walkabout, the only way to perhaps "correct" it is to kick the user. And it may need to be done several times before the audio reverts to where it should be because sox sometimes just doesn't want to cooperate (seems the better the resampler, the more difficult it is to get it back in-sync once everything steps out of line - solving one problem creates another... this is just soooooo much fun! ;^).
Right now, the only way to recover from the lip sync issue is for me to wake up & look at a computer or smartphone screen & then do something on one of them when I'm not firing on all four cylinders. Night/dark mode & reducing the amount of blue doesn't seem to help - once I look at it, that's it... I'm buggered. I end up with both not enough sleep as well as self-induced jetlag.
An admin user kick does not cause kiwiclientd to report to JTDX that the tuned frequency changed to 0 Mc & then back again, so the JT-mode hash tables don't get binned as they are on band changes in hopes of avoiding the inevitable hash collisions of the way-too-short-for-purpose 10 & 12-bit hashes.
Is there some way I could do an admin kick that I could automate? Then I could do an hourly series of kicks as preventative maintenance & lump it for now after seeing if my Kiwi will download 1.651... and more importantly would also allow me to not have to make sure I'm free to recover from the near-daily 0625 GMT KiwiSDR keel over.
73, VR2BG.
Perhaps the addition of some type of watchdog feature, selectable from the admin page, might be a good option? This would allow us to enable or disable the automated kick if that were implemented?
After a very chilly site visit and a lot of messing around, I have found (but not cured) the low frequency 14 second noise / loss of sensitivity problem at Wessex.
It seems to be noise being introduced by one of the other SDR's on site (OpenWebRX & RTL dongles), which share the same passive splitters as the KiWi V1 & 2, Flydog and websdr.
For some reason (and it is not at all clear) the noise is strong enough to overcome the splitter port isolation and find its way on to the KiWi's.
Swapping splitter ports, moving cables and equipment around, all seem to make it either slightly better or slightly worse, but I can't get rid of it unless I unplug all the other kit, so for the time being the problem remains.
I tried swapping the RTL dongles for a different version, but that just introduced other problems.
It was too cold to stay on site for a lengthy period, so I have decided to see if I can replicate it in the workshop at home, and see if I can figure out how to best resolve the issues.
Regards,
Martin