jks

No. As I mentioned, there are hundreds (thousands?) of Kiwis out there with old frp clients that cannot just stop working.

The other problem is that the frps server claims the proxy port (8073), so there is no opportunity for a web server (we use lighttpd) to act as a load balancer on top of (in front of) the proxy service. Any port redirection has to come from the frp server code itself.

I have this working now. But now there have to be changes on the Kiwi-side to decide when to use proxy2.kiwisdr.com. Probably something like if the proxy name starts with a digit (the new Kiwi-2 auto proxy feature using the serial number as default proxy name). Since currently there are roughly as many of those as there are Kiwis with alphanumeric names (changed by their owner/admins).

Here was someone else with an nginx proxy configuration that caused problems with the VER file fetches: https://forum.kiwisdr.com/index.php?p=/discussion/comment/19796#Comment_19796

@jimjackii That particular error, where you get vundefined.undefined only occurs when your proxy setup if failing to correctly handle an XHR transaction for a file called "VER" the browser is trying to get from the Kiwi server. That file will contain a JSON response that looks something like:

{"maj":1,"min":804,"ts":4611686018441628445,"sp":1}

So open the Javascript console and network tab in your browser and see why the fetch of the VER file fails. Does it get an HTTP status of something other than 200? Is the response something other than like the above? If so, figure out why.

Also, on the admin webpage tab, toward the bottom of the page, change the "Web server caching?" setting to "No" and restart. Your Kiwi page loads will be much slower, because no web caching will be done, but it may overcome whatever shortcoming your proxy solution has.

I should also mention in connection with the voltage drop post above. I knew about the problem many years ago. One day I made up some short cables out of some random "speaker wire" I had where it wasn't immediately obvious what the wire gauge was. I was astonished when the brownout problem happened when running the admin sd card backup function! (it is known that sd card writes take a lot of additional current).

I didn't believe it until I put a scope on the power connector at the Kiwi set to trigger at lower than 4.8V... And it triggered! lol

I measured the wire gauge and it was 24 AWG or something. I used one of those online voltage drop calculators and it pretty much confirmed the problem for the length of wire I was using (given a guess at the current spike amount -- with some effort I could have measured that too).

Yes, you can re-flash using the Beagle by itself. You'll have to use a different power connection as the BBG has a micro-USB as the 5V input vs the Kiwi's DC barrel jack.

The way the code is currently, if you use a "%20" that gets translated into a space character in the Kiwi configuration itself, which is no good.

What I've done is made the "+" character get translated into a space. This is a URL standard and compatible with the fact that the field is being interpreted as a curl URL argument. An actual space character is used to separate multiple curl commands as it is now for backward compatibility.

Ugh. I don't understand. That code doesn't work at all. I tested it with Glenn's V/UHF converter and it worked fine. I'm sure of it. But looking at it now there's no way. It does everything wrong.

Give me a bit to fix it. I'll have it for the next release. Embedded spaces, default antenna mode and all..

The waterfall(s) may run slower. Depending on the total number of connections.

I didn't design these. Ask sales@kiwisdr.nz

Same as with Kiwi-1. The number of simultaneous users varies depending on the FPGA configuration selected on the admin page, "mode" tab.

But there are compromises as described in the text on that page. In 8 channel mode only 2 can have a waterfall. In 20.25 kHz wide audio bandwidth mode there can only be 3 channels etc.