jks

For me 2.05.58 has exactly the same problems as .57 on my Android tablet.

I can open both of the kiwiservers.js files in a browser fine.

No, I only have the one Galaxy A9 tablet. No Android based phone. And 1.45.04 works on the tablet. But none of the 2.05.xx versions do.

Seems odd that the license key dialog confirmation hangs with the 2.05.xx versions (valid key never turns the field entry box green, dialog box can't be cancelled). Like there's a generic problem with app network access apart from fetching kiwiservers.js file specifically.

Yes, AI reports thousand of complaints of this problem with various web apps that use web audio. There seems to be disagreement whether this is a bug or tightening of the rules over audio auto-play.

I don't run the latest version of MacOS over fear of it breaking my primary development environment (has happened in the past). So I can't test. Also, I'm in the middle of so many important projects I'm just going to let this issue sit for a while and see how it develops. Especially since using a different browser is a reasonable workaround.

Update: 1.45.04 works! I've been keeping some older .apk files on kiwisdr.com just for this purpose: http://kiwisdr.com/q/145.apk

We've had one person blow up three KiwiSDR 2s now. Antenna ports wired in parallel and connected to a large antenna. With another ham radio transmit antenna operating a few hundred feet away. No disconnect before transmit. No automatic antenna switch.

The symptom is that one of elements of the electronic attenuator on the Kiwi-2 is now shorted "on" giving a constant 20 dB of attenuation. Interestingly, the remainder of the elements seem to function normally.

So the Kiwi-2 may be somewhat less forgiving than the Kiwi-1 in this regard. The Kiwi-2 has increased protection against impulse and static charge compared to Kiwi-1. But it probably doesn't help the large RF field case very much.

Please be careful.

Re: emails from kiwisdr.com

Well, the root cause is that getting outgoing emails working from the forum software used by kiwisdr.com to large email providers like Google et al exceeds my likely remaining life span.

I spent two weeks once trying to get it to work. I implemented and tested all the usual suspects: DMARC, SPF, ... Passed all the tests. Didn't help. I gave up. Too much other important work to be done.

This is why the forum sign-up confirmation page say "if you don't get a confirmation email from us in a day or two just try logging into your account and see if it works".

From the last thread about this:

What happens when you try to access the sampling and reference station lists directly from a browser?

http://tdoa.kiwisdr.com/tdoa/files/kiwi.gps.json

http://tdoa.kiwisdr.com/tdoa/refs.cjson

Leaving off the ":8073" will only work if the client (web browser or QiwiQ) responds to an HTTP 302 or 308 redirect. That is, if a user requests xxx.proxy.kiwisdr.com it will receive a redirect to "xxx.proxy.kiwisdr.com:8073" from the proxy server on kiwisdr.com (i.e. it will be told to retry with the new URL). You might ask why I don't implement this using a URL rewrite instead of a redirect, but that's where the next paragraph comes in.

Right now this is more of a shortcut convenience so you can leave off the ":8073". But soon I'm going to load balance the proxy service between two servers and responding to 302/308 will become mandatory. A reference to yyy.kiwisdr.com[:8073] will be redirected to yyy.proxy2.kiwisdr.com:8073 if yyy happens to be hosted on the secondary proxy server.

You might have noticed I recently removed the ":8073" from any Kiwi proxy URLs shown on my.kiwisdr.com and rx.kiwisdr.com. And this is probably why this problem with QiwiQ is occurring now.

Of course I don't remove the port number from any non-Kiwi-proxy URLs (e.g. zzz.ddns.net:807x) because those need to remain.

Whatever HTTP package QiwiQ is using should have the redirect functionality someplace. This is a fundamental web standard. Might just be an issue of enabling or configuring something.

An email I sent to the guy who requested SBAS support (which will be under development for some time). SBAS is Satellite Based Augmentation System. Geostationary satellites providing GPS location improvement data.

Good introduction: https://sgu4823.wordpress.com/wp-content/uploads/2012/11/l4-2_sbas_signal.pdf

Okay, fixed in v1.824. Apologies for that.