I'm noticing the pops on CW when tuned to a carrier. I am also having a problem where the session "locks up" (waterfall and audio stop, clock/OpenWRX logo stops) but I can still pretend to adjust the frequency if I click on the waterfall.
I have tried this on Windows 10, Chrome, no other tabs or apps open, both on slow and fast computers (laptops).
All of the machines (4) that I have "lock up" problems with are running Chrome on Win 10. The kiwisdr seems to think they are still connected according to the "users" tab.
The firefox one has no pops and has not "locked up" yet.
I ran one laptop (Win10) with 2 connections to the same KiwiSDR. One on chrome the other on firefox. Both tuned to local AM station on normal AM. The chrome "locked up", the firefox did not.
Interestingly I was able to move the frequency on the chrome and it began working again. I am thinking this is because it just happened when I found it (heard the audio stop) whereas if I waited it will not recover. Again, user list shows connection working (even after one hour on another "frozen" session.
Confirmed, the same here. In addition, using null LSB/USB increases the noise on weak signals making them less audible. On the other hand, the popping is not audidble on weak signals.
I made an observation (earlier than 1.440), I don't know if it is related to this problem.
In the presence of a strong signal (can be out of the receiving frequency), the audio volume occasionally drops to zero, and the s-meter shows -127 dBm, but the waterfall looks normal and keeps scrolling. As soon as the strong signal is gone, the audio recovers.
I noticed this in SSB. But I can't reproduce it reliably.
Some random data points, maybe related, maybe not:
I run an SSTV decoder 24/7 on one of my KiwiSDRs. I do not use a browser, I have an app (KiwiKonnect) that directly connects to my KiwiSDR and routes the audio to a virtual audio cable. In the past this has worked flawlessly for long periods of time. But now, after a recent Windows update (a week or two ago?) I have noticed that after about a day of operation, sometimes less, the audio starts getting distorted, resulting in distorted decoded images. I have not had the chance to investigate the exact nature of the problem, it may be dropped samples. Again, no change to anything on the system other than the recent Windows update, and I guess whatever KiwiSDR updates have occurred. I don't think it's the KiwiSDR because resetting the connection to that, or quitting and restarting KiwiKonnect does not solve the problem, likewise just quitting and restarting my SSTV does not either, I have to quit and restart both apps, suggesting it's something in the virtual audio connection between them, or the Windows audio system itself.
Also, just this morning there was a thread on the UDXF mailing list, with several people mentioning suddenly having problems decoding digital signals, both with KiwiSDRs and the WebSDR Netherlands. Most people are reporting issues with Chrome, many with Edge, Firefox seems to be OK for most but not all.
That said, I just tuned into my local MW station on 1280 which is S9+55 or so, and I don't think I hear this popping sound (I am not sure if I have ever heard it, actually).
In addition, using null LSB/USB increases the noise on weak signals making them less audible.
Well, of course it does. You're nulling them!
The idea is to null the signal presenting the strongest carrier on-channel (the one tracked by the PLL) so that off-channel signals are more easily heard. And also so that weaker on-channel signals are more easily heard (they should be unaffected by the subtraction of the stronger signal).
I can get regular popping now on my Windows 10 laptop using Chrome. Firefox and Opera seem okay. It happens equally in all modes and settings: SAM (with and w/o channel nulling), SAS et al, IQ, other modes with and w/o compression. I can best hear it in CW with a passband of 22 Hz.
There is only one report on the Chrome bug list of this issue. Nothing on the Mozilla list.
Chris: That's very interesting. I was going to ask about people's experiences with WebSDR. I think that pretty much confirms this is not directly my fault.
I spent all day looking for more possibilities, but with no luck. For a while I thought it might be instability in the SAM PLL. But that of course doesn't explain why it also occurs in IQ mode. A quick disable of the PLL didn't change anything.
I also built several old versions including v1.436 from late February and v1.413 from last October. Same problem.
Thanks for that. I now realize my mistake when I was searching bugs.chromium.org back on March 21. I expected to find something but didn't. I just wasn't searching correctly..
So from what I could understand it seems if we just wait a little longer the problem will go away with the next Chrome stable update?
Interesting also is issue #1188901 where someone tried to fix the problem by migrating from ScriptNodeProcessor to AudioWorklet, which is the newer preferred API, but found it had similar issues.
Some external Ethernet devices can leave horrible spurs on HF frequencies so the option to force 10mb via the admin was added as that in some cases reduces low level local spurs seen with some hubs/switches. Gig speeds are unnecessary in this use and being pushed "faster" normally adds "more noise", that is not welcome.
Try running other Ethernet devices close to the HF antenna and see why a few of us on here curse the interface on many (not all) modern bits of equipment, I have CCTV that will badly degrade reception from nearly 20m away if not covered in ferrite.
I do hear what you are saying, and having been sold "faster is better" for years 10mb seems a strange if not backward step, but once I realised radio is not gaming, power is not silence, it makes sense.
All very well Canary not having the problem but Canary is somewhere even before Beta. When might we get a fix for this if we stick with released versions of Chrome? I've downloaded Firefox fro now to test and the problem is not there on Firefox. Before I found this thread, I'd swapped power supplies, dis-mantled the KiwiSDR, reloaded and rebuilt the software, swapped the GPS antenna and all sorts of other things. It's quite bad on my system. Good to have found this thread and also found it was just Chrome (or is it Win 10)?
It's not just Windows 10 as I seem to have the problem on Windows Server 2012R2, Ubuntu, and even Android. It seems to be Chrome/Chromium related. Brave has the problem, Midori and Firefox seem fine. As always, YMMV.
I ran a copy of Chrome Canary (90) on my Windows 10 machine and it worked fine. Will wait for the pushout of the next stable release of Chrome. Thanks!! I use my Kiwis every day! Firefox also works fine.
Yes, if you read this long and tortured thread one of the first things I observed was that I couldn't replicate the problem on my Mac with any browser.
Hi all, Just to note that I now have Chrome 90 installed and the popping is still there but no so loud (I think). I've just compared it with Firefox where we know the possping is not present. So Chrome 90 has not fixed it for me.
Comments
I'm noticing the pops on CW when tuned to a carrier. I am also having a problem where the session "locks up" (waterfall and audio stop, clock/OpenWRX logo stops) but I can still pretend to adjust the frequency if I click on the waterfall.
I have tried this on Windows 10, Chrome, no other tabs or apps open, both on slow and fast computers (laptops).
I will try other browsers and OS's and report.
The popping issue was not observed on a Windows 10 machine (that has been off for a while) running Firefox.
All of the machines (4) that I have "lock up" problems with are running Chrome on Win 10. The kiwisdr seems to think they are still connected according to the "users" tab.
The firefox one has no pops and has not "locked up" yet.
I ran one laptop (Win10) with 2 connections to the same KiwiSDR. One on chrome the other on firefox. Both tuned to local AM station on normal AM. The chrome "locked up", the firefox did not.
Interestingly I was able to move the frequency on the chrome and it began working again. I am thinking this is because it just happened when I found it (heard the audio stop) whereas if I waited it will not recover. Again, user list shows connection working (even after one hour on another "frozen" session.
This Edge/Chrome browser issue maybe the same problem that is affecting DRM decoding using the IQ mode.
http://forum.kiwisdr.com/index.php?p=/discussion/2245/drm-and-iq-output-no-longer-working-properly-in-latest-update
I made a new discovery. The popping stops when I select "null LSB" or "null USB" on SAM.
Confirmed, the same here. In addition, using null LSB/USB increases the noise on weak signals making them less audible. On the other hand, the popping is not audidble on weak signals.
73 Eckhard
I made an observation (earlier than 1.440), I don't know if it is related to this problem.
In the presence of a strong signal (can be out of the receiving frequency), the audio volume occasionally drops to zero, and the s-meter shows -127 dBm, but the waterfall looks normal and keeps scrolling. As soon as the strong signal is gone, the audio recovers.
I noticed this in SSB. But I can't reproduce it reliably.
@HB9TMC For info what level is the Passband overload mute set to in your Admin Config page?
Some random data points, maybe related, maybe not:
I run an SSTV decoder 24/7 on one of my KiwiSDRs. I do not use a browser, I have an app (KiwiKonnect) that directly connects to my KiwiSDR and routes the audio to a virtual audio cable. In the past this has worked flawlessly for long periods of time. But now, after a recent Windows update (a week or two ago?) I have noticed that after about a day of operation, sometimes less, the audio starts getting distorted, resulting in distorted decoded images. I have not had the chance to investigate the exact nature of the problem, it may be dropped samples. Again, no change to anything on the system other than the recent Windows update, and I guess whatever KiwiSDR updates have occurred. I don't think it's the KiwiSDR because resetting the connection to that, or quitting and restarting KiwiKonnect does not solve the problem, likewise just quitting and restarting my SSTV does not either, I have to quit and restart both apps, suggesting it's something in the virtual audio connection between them, or the Windows audio system itself.
Also, just this morning there was a thread on the UDXF mailing list, with several people mentioning suddenly having problems decoding digital signals, both with KiwiSDRs and the WebSDR Netherlands. Most people are reporting issues with Chrome, many with Edge, Firefox seems to be OK for most but not all.
That said, I just tuned into my local MW station on 1280 which is S9+55 or so, and I don't think I hear this popping sound (I am not sure if I have ever heard it, actually).
@Powernumpty Ah, thanks for the hint. That could have been responsible for my observation.
It was set to -15 dBm and the signal was exceeding that value.
In addition, using null LSB/USB increases the noise on weak signals making them less audible.
Well, of course it does. You're nulling them!
The idea is to null the signal presenting the strongest carrier on-channel (the one tracked by the PLL) so that off-channel signals are more easily heard. And also so that weaker on-channel signals are more easily heard (they should be unaffected by the subtraction of the stronger signal).
I can get regular popping now on my Windows 10 laptop using Chrome. Firefox and Opera seem okay. It happens equally in all modes and settings: SAM (with and w/o channel nulling), SAS et al, IQ, other modes with and w/o compression. I can best hear it in CW with a passband of 22 Hz.
There is only one report on the Chrome bug list of this issue. Nothing on the Mozilla list.
Chris: That's very interesting. I was going to ask about people's experiences with WebSDR. I think that pretty much confirms this is not directly my fault.
Chrome Windows 10 I/Q AGC off manual gain 100dB much popping
add redirect to other kiwi in camp page option please
I spent all day looking for more possibilities, but with no luck. For a while I thought it might be instability in the SAM PLL. But that of course doesn't explain why it also occurs in IQ mode. A quick disable of the PLL didn't change anything.
I also built several old versions including v1.436 from late February and v1.413 from last October. Same problem.
Are you sure this problem isn't caused by this confirmed Chrome bug which appeared in version 89?
Thanks for that. I now realize my mistake when I was searching bugs.chromium.org back on March 21. I expected to find something but didn't. I just wasn't searching correctly..
So from what I could understand it seems if we just wait a little longer the problem will go away with the next Chrome stable update?
Interesting also is issue #1188901 where someone tried to fix the problem by migrating from ScriptNodeProcessor to AudioWorklet, which is the newer preferred API, but found it had similar issues.
FYI, a fix for the aforementioned bug was merged into Chrome 90 last night. I no longer hear any popping on the latest Chrome Canary.
thats great to know :)
next question
i saw into the confrigure a old setting like 1
this
.
10 mbit
100 mbit
the team needs to know that in the world now more mbit is it shall be this than up to date
10 Mbit = 10 mb a sec
100 Mbit = 100 mb a sec
1 Gbit = 1000 mb a sec
.
this are standard norms in the world remember 100 mb is old to old
greets team
the Ethernet interface speed can be firmware upgrade i know that
10 / 100 is not so good for digi radio or data it runs quick out and to slow
for the rest is this Sdr exelent only a few points to work on it :)
for the pay closely 346 euro's is also the 4 users on Am to low that was nicer when it was more !
greets team :) from Hans ( ICT network engineer. netherlands )
Some external Ethernet devices can leave horrible spurs on HF frequencies so the option to force 10mb via the admin was added as that in some cases reduces low level local spurs seen with some hubs/switches. Gig speeds are unnecessary in this use and being pushed "faster" normally adds "more noise", that is not welcome.
Try running other Ethernet devices close to the HF antenna and see why a few of us on here curse the interface on many (not all) modern bits of equipment, I have CCTV that will badly degrade reception from nearly 20m away if not covered in ferrite.
I do hear what you are saying, and having been sold "faster is better" for years 10mb seems a strange if not backward step, but once I realised radio is not gaming, power is not silence, it makes sense.
Confirmed, the latest Chrome Canary does NOT have the popping problem!
@DanceWave: Too many opinions, not enough research. Start here: Design review document
All very well Canary not having the problem but Canary is somewhere even before Beta. When might we get a fix for this if we stick with released versions of Chrome? I've downloaded Firefox fro now to test and the problem is not there on Firefox. Before I found this thread, I'd swapped power supplies, dis-mantled the KiwiSDR, reloaded and rebuilt the software, swapped the GPS antenna and all sorts of other things. It's quite bad on my system. Good to have found this thread and also found it was just Chrome (or is it Win 10)?
It's not just Windows 10 as I seem to have the problem on Windows Server 2012R2, Ubuntu, and even Android. It seems to be Chrome/Chromium related. Brave has the problem, Midori and Firefox seem fine. As always, YMMV.
@Gibsonmb If you look at the last few comments of https://bugs.chromium.org/p/chromium/issues/detail?id=1187016&q=1187016&can=2 it seems the fix will be included in the Chrome 90 stable version scheduled for release on April 13: https://www.chromestatus.com/features/schedule That status page has a list of features, not bug fixes. So don't be concerned that the bug isn't in the list.
I ran a copy of Chrome Canary (90) on my Windows 10 machine and it worked fine. Will wait for the pushout of the next stable release of Chrome. Thanks!! I use my Kiwis every day! Firefox also works fine.
Thanks, that's very encouraging. Just for info, Chrome on my Macbook does not exhibit the popping problem
Yes, if you read this long and tortured thread one of the first things I observed was that I couldn't replicate the problem on my Mac with any browser.
Hi all, Just to note that I now have Chrome 90 installed and the popping is still there but no so loud (I think). I've just compared it with Firefox where we know the possping is not present. So Chrome 90 has not fixed it for me.