Re: New to the list
To access the Kiwi you have a choice of a wired LAN connector (static or DHCP), USB A connector (port number statically assigned by BB). Either of these *might* be connected to a router/dongle or directly to a host computer such as the RPI. If the connection is not wireless, then the device it is connected to must have a power source. That power source *could* be it's own separate PS or it could be something in common with the Kiwi's. IF it's in common then there is either an actual ohmic COMMON path as in the case of USB or there's finite CM rejection as in the case of the LAN/RJ45 PHY. Either of these paths might create a current loop with data path. Edges from the data can end up generating non-zero current through Kiwi/BB "grounds". These paths are imperfect and have the danger of generating signal energy within the Kiwi's large measurement range. This can sometimes be a bit insidious because the currents may increase due to finite CM impedance on antenna feed line or LAN line (if either present).toggle quoted messageShow quoted text
The Kiwi *can* be run with either a direct connection to the host, through a router wired or wireless or USB.
I'm only cautioning against these somewhat 'invisible' paths. Ground is not ground. Edges have families of spectral lines. The Kiwi has a low noise floor. Watch out.
I tried to document a USB/Wifi solution to this on the forum. For that I provided WiFi router PS over the single USB A cable connecting the Kiwi/router. There was therefore no opportunity for a current loop within the kiwi/BBG or current injection from the LAN cable.
On 7/14/21 5:59 PM, VE3VXO wrote:
I think I'm missing something here. You keep mentioning wired LAN connections. I'm talking about running the SDR stand alone with wspr daemon running on the same pi that is connected to the SDR hardware and no LAN connection at all, but just logging spots to an internal file for upload at a later time. I still don't know if it is possible to run wspr daemon the way I propose and how wspr daemon software would connect to the SDR software in this case, ...I suppose through defining a common port or using a third application which acts as a virtual port, I am no expert on the like but wouldn't this get around virtually (no pun) all the connectivity issues that cause ground loops and common mode noise injection?