jks

This has been a problem in the past, but is not known to be an issue currently.

The most sensitive test of dropped samples is to run the FAX extension. The slightest dropped sample will cause the image to become progressively more shifted (i.e. lines looking broken) as the image rendering proceeds. I tried this just now on several Kiwi running the most recent software version and all seemed well. An example image is below. All those lines should not have any offsets or breaks. The 400 pixel tall FAX viewport at 120 LPM represents 3.33 min of reception. So no dropped samples over that time period.

Have you tried different browsers? One factor in the audio is that the browser's scheduling of the Javascript audio processing must not have any realtime performance hits. Otherwise samples can be lost. But that's a browser problem not a Kiwi problem.

The audio and waterfall use completely different mechanisms and so any glitching should not be correlated. If they are that may point to network issues.

Yes, it is possible the Ethernet on the Beagle is beginning to fail. Specifically the Ethernet PHY chip. There was trouble with this some years ago that seemed to be a bad batch of PHY chips, although this was never conclusively proven.

You could consider replacing the Beagle with a new Seeed BeagleBone Green. Roughly $50 USD + VAT. Be careful not to use any other Beagle type. Specifically not the Seeed BeagleBone Green Wireless. It is not physically compatible with the Kiwi board. If you can find the older BeagleBone Black that will work also. But make sure it is a "rev C" board that has 4 GB eMMC (not 2 GB).

Okay, I fixed this. Wasn't too bad. Will be in the next release.

Will allow any future internal extensions that use the waterfall to work also (currently our WSPR and FT8 internal extensions only use the audio stream).

If it's really only two characters it might be that operating at 9600 baud will be okay. You'd just have to try it and see what happens as far as any realtime impact.

From the CHANGE_LOG file:

I checked the code, and I had added something. But in looking at it I see what I did wasn't quite right.

So I have something now that I think will work. Will be in the next release..

I have the web server log and that's all I need. tcpdump when anything more specific required.

I'm not going to continue talking about this since we don't know who's reading the forum.

Not following this in detail because I'm so busy. But try and run this at 115k baud at least to avoid impacting the Kiwi realtime performance (i.e. causing the audio to break). That was my experience when I added the CAT output option that also used /dev/ttyUSB0 (and /dev/ttyASB0 if necessary).

There was a discussion about this recently over on the wsprdaemon forum: groups.io/g/wsprdaemon/topic/vlsl_telecom_network/112581272?dir=asc

I've told this story before but will repeat it in case anyone has self-interference problems.

Before my apartment building was wired for fiber (FTTP) all we had was VDSL2 from a pedestal on the street over the crappy building CAT3 telephone cable. I had some noise, even after adding some toroids, around -95 to -100 dBm (uncalibrated) as shown in the first image. Not too bad.

One day one of the VDSL band segments jumped up almost 15 dB in signal strength. I looked at the VDSL statistics page on the modem and the "downstream" transmit power from the line card in the pedestal was at +14 dBm compared to the usual +3 dBm, which is what the statistics page said my modem was transmitting in the "upstream" direction. They were always about equal in the past.

After resetting the modem there was of course a VDSL retrain cycle and the downstream power dropped again to +3 dBm. I happened to catch this on the waterfall in the last image. Not quite as good as what I had before. But a big improvement.

As mentioned in that post, I quickly implemented the simplest, dirtiest server that followed the minimum SpyServer protocol just to get SDR++ to work (barely). My goal was to see if this concept was even possible. SDR++ was the fastest route to that goal.

I don't know anything about soapy or ka9q-radio or how difficult it might be to write a driver for them.

More importantly, this work was paused until other "pieces of tech" become available to make sending a more significant amount of spectrum possible. Like MHz instead of hundreds of kHz. That work is still ongoing..