jks

It's a huge headache to construct sd card images of the current release. So I don't do it often. v1.390 was the last. We all depend on the autoupdate over the network.

The build is progressing now, but very slowly. Something seems to be taking a lot of cache space in main memory. I don't understand why. There are no processes that seem out of place.

A USB-to-WiFi dongle is a lot of work and grief unless you know what you're doing.

A much easier solution is to use a wired-Ethernet to WiFi mini-router: https://www.tp-link.com/en/home-networking/wifi-router/tl-wr802n More info here: http://forum.kiwisdr.com/index.php?p=/discussion/1653/connecting-kiwi-via-wifi/p1

The worst problem there is dealing with the required 5V power input as the supplied adapter is a potentially noisy switcher. Although you might be able to get 5V from the BBG/BBB USB-A "host" port. Anyone actually doing that?

There is a fix for this in the next update. It's tricky because Kiwi owners may have arbitrarily edited the definition of bands[] in config.js in ways that my fix may not have anticipated. Although my fix tries to take this into account.

The whole situation will be better addressed when the contents of config.js are absorbed into the admin user interface and config database. But that's a complicated change that will not happen anytime soon.

Beginning with v1.436 the band identifiers will not be displayed if their frequency is less than the frequency scale offset. But the remaining empty white space is not reclaimed because right now that is difficult to do (for historical reasons). It will have to wait for a major rewrite of that part of the code.

Feb 2021: Alpha "Khabarovsk" (nearest town Elban) as received from the Kiwi in Khabarovsk about 200 km distant. MSK signals VTX3 India and NWC Australia also present.

In the case of the BBAI:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#i_take_full_responsibility_for_knowing_my_beagle_is_now_insecure

I'm not an expert, but I think the short answer is no.

Forgetting about GPS time-stamping of the IQ samples for the moment, one thing the GPS does is correct for any error in the ADC clock. Improving the characteristics of that clock doesn't really matter. Maybe a clock with an improvement in the short term Allan variance (frequency stability) would be of some use. I don't know. Glenn will have something to say about this since he's done exactly what you're proposing (attaching an external Rb frequency standard).

The Kiwi has no provision for attachment of an external 1 PPS input from a GPS receiver that is specifically designed to be a timing receiver (such a distinction exists). That said, the performance of the positioning (hence timing) of the current code, thanks to Christoph's work, is pretty good. The best way to maximize GPS performance is by using a GPS active timing antenna mounted outside in the clear using good low-loss feed line.

There are many other factors that influence the accuracy and resolution of the TDoA solutions. See Christoph's 2019 SDRA talk for full details: https://www.youtube.com/watch?v=LpFoM_lBgxg

The other important point to realize is that Kiwi TDoA is not a "push button" application. It takes an amount of skill, repetition and luck to get good results, especially at HF. Professional SIGINT personnel go through considerable training to be able to manage the tools they have and interpret the results.

Thanks for pointing out that Chuck is running RaspPIs (I checked, he has one that is public and no KiwiSDRs).

So Chuck is no longer with us. He can use the RaspPi forum for his questions.

Anything new about this? Could it be related to the Comcast/Xfinity problem others have had recently?

Yes, question is too short to understand exactly what is being talked about.

But to me it sounds like it's the local (private) ip address that the router is moving around for some reason. E.g. you y initialldiscover it's 192.168.1.101 and make a connection. But then later after trying to reconnect there is no response at that address and you have to go through the rediscovery process again only to find it's now at 192.168.1.107.

This might be caused by the DHCP server in the router configured with a really short "lease time", like minute or hours instead of days or weeks. Ideally the Kiwi's Ethernet MAC address should be bound to a fixed private ip address in the DHCP static ip configuration table. But that takes some effort to setup (that's what I do here). That way the local ip addresses never move.

Make sure this is not the problem before you send him off on the goose chase that is DDNS, lol.