jks

That is a sure sign of the power supply not meeting the 50 millisecond "ramp up" requirement of the Beagle. That is, if you were to look at the time it takes the 5V waveform to go from 0V to 5V it would be too slow. This can happen if it is taking too long to charge the power supply output capacitor which will will look like a dead short for a period of time (especially if it is a large cap).

But when you plug the power supply into the Kiwi the cap is already charged and the waveform appears to ramp up quickly.

I will improve the input parsing for this field to prevent the problem in the future.

For those of you who struggle like me to get regular expressions working this is the greatest thing since sliced bread: https://regex101.com

Okay, I think kiwirecorder resampling works now. Update from https://github.com/jks-prv/kiwiclient.git (master or jks-v0.1 branch) and use the new "-r N" or "--resample N" option where N is the new sample rate in Hz. Works with regular and IQ-mode recordings. See the "resample" and "resample_iq" example targets in the Makefile.

I assume you mean 20 kHz. The default b/w for the "AM" mode button is 10 kHz now (+/- 5 kHz either side of carrier) and 5 kHz for "AMN" (+/- 2.5 kHz). There has been a suggestion that rather than adding a third button (e.g. "AMW", for which there is no room) a single AM button toggle between 3 or 4 b/w choices (20, 15, 10, 5 kHz?).

Adding an initial b/w field to the admin "config" tab to go along with the initial mode selection is certainly possible.

The WSPR extension decoding process (not the sampling during the two minute sampling interval) is hugely compute intensive. And if you are in an area where lots of WSPR signals are being received on multiple bands simultaneously, causing heavy decoder load, and you have other regular connections on an 8-channel system then it is possible the realtime scheduling requirements cannot be met leading to audio underruns.

This behavior is a bug, but also difficult to fix. So it probably won't be anytime soon given everything else that is being worked on.

More news from Oscar:

I will improve the input parsing for this field to prevent the problem in the future.

For those of you who struggle like me to get regular expressions working this is the greatest thing since sliced bread: https://regex101.com

Subtle problem: compared to 8073, 8074 and 8075 are both configured with an extra closing parenthesis at the end of the "Location (lat, lon)" field on the sdr.hu tab of the admin page, i.e. "gps=(53.886303,-2.621231))"

The built-in GPS is used for several tasks.

As you point out there is always some frequency offset that needs to be compensated for if you want the Kiwi frequency scale to be 100% accurate. How much offset is present is usually a function of how good the main oscillator is and how much temperature swing the room has where the Kiwi is located. During design we decided to trade off using a less expensive oscillator with greater offset variation (manufacturing tolerance and temperature coefficient) for the small cost of adding the GPS front end (front end chip, SMA connector, shield can, a few discrete components). And then use the GPS to compensate for the offset of the oscillator. The other pieces needed for the software-defined GPS came for free because we had available space in the FPGA for the required firmware (in fact the Kiwi shares several parts of the GPS firmware: the FPGA embedded processor and SPI interface).

Without GPS compensation enabled you can see exactly how much offset you have by following the manual calibration procedure described here: http://kiwisdr.com/quickstart/index.html#id-cal

But the real advantage in having on-board GPS is that you can now add very accurate timestamps to the IQ samples that external software can stream from the Kiwi. This allows some very interesting cooperative measurements to be made using multiple Kiwis where the IQ samples must be aligned via the timestamps. The most famous example of course is Christoph's TDoA direction finding algorithms to which we (and others) have added a user interface (see TDoA entry in Kiwi extension menu and the various write-ups about TDoA on the kiwisdr.com homepage).

This may be an expected condition. If at the time the Kiwi with multiple users had fewer "good" sats than you were expecting I would need to know if the "acq" status item at the lower left of the GPS page was saying "yes" or "paused". Also, is the "always acquire" switch set to "yes" on this Kiwi?

You're right that this has been discussed before, but I'll recap. There are two phases to begin processing a new sat: acquisition and then tracking once the sat is acquired. The acquisition process is very compute intensive on the Beagle. It requires a large FFT, the code of which is uninterruptible (running for many milliseconds). That has big consequences for the realtime requirements of the Kiwi. With many users connected running a large FFT, unless carefully scheduled, could cause the users to experience broken audio. Tracking is not a problem because that is done mostly in the FPGA with dedicated hardware for each GPS channel.

So there is some code to strategically decide when to do acquisitions.

The variables are:
Did the Kiwi just boot and has never had a solution? (hence no frequency calibration of the SDR part of the Kiwi)
How many users are currently connected? (external users, not internal e.g. WSPR-autorun connections)
Are there more than 4 "good" sats currently? (the minimum number required for new solutions, although this has now changed because the Kalman filter can give solutions using fewer good sats)
Is the "always acquire" switch set on the GPS admin page?

The strategy is:
1) If there have never been any solutions at all (Kiwi startup) then always acquire no matter how many connected users until there are enough solutions for the first few Kiwi oscillator corrections to occur. This is so that any large initial frequency offset due to room temperature can be removed.
2) If the "always acquire" switch is set to "yes" then always acquire no matter what.
3) If there are not too many external users (currently means fewer than two users) then always acquire.
4) If there are not enough sats to potentially generate new solutions (i.e. less than 5) then acquire.

So, what does all this mean? If you have two Kiwis connected to the same GPS antenna and one is full of users and the other is empty then the following can happen. They'll both begin acquiring sats, but the Kiwi with users will stop acquiring when the above conditions are met and just maintain roughly the minimum number of sats required for new solutions. If the users don't connect immediately then both Kiwis will load up to the same number of channels possible (e.g. all 12), but then the Kiwi with users will slowly drop down to the minimum described above as sats go out-of-range and are dropped. This is of course because the acquisition process is not running as frequently as on the Kiwi with no users.

Or what you're seeing could just be a bug I need to fix! lol