New to the list
Best regards all...joe
Joe,
You understand this correctly. Even an RPI 3 can handle simple spotting, noise and SNR measurement when used with WD. Data can be recorded apart from an Internet connection and then automatically uploaded once the RPI returns to one. This can include not only spot but noise data which can be observed and manipulated by way of various tools.
If you think you might be operating in a situation where you have multiple, busy WSPR bands to receive and decode, it might be a good idea to go for at least an RPI 4 since it is possible to over-run the capability of an RPI3 on busy bands with lots of decoding to do. Either way you will get a better decoder than the extension on the KiwiSDR by itself.
Glenn n6gn
Hello to all, I am Joe ve3vxo and have been running a Seed KiwiSDR for a couple of years now. I have been using it to evaluate low band receive antennas using the wspr extension. Recent experiments are giving me doubts that nearby conductive objects at my shack are playing havoc with the expected antenna patterns as predicted by eznec modelling and I would like to move the antennas temporarily to a remote location where there is no internet connectivity and do a run of 12 to 24 hours to get a range of spots during both day and night propagation conditions to evaluate the shape of the antenna response. This would require that spots be recorded and I could upload them to wsprnet.org later when I get home to look at the map. I just found out about wsprdaemon but have not learned all about it yet so please forgive the ignorant question, but is this something that wsprdaemon can do for me? According to Rob's (AI6VN) TAPR presentation video I just watched there was one bullet saying "cathes spots through loss of internet connectivity" so I think that suggests the answer to my question is yes, but I want to make sure this will work before I begin here as I don't have a Rpi to use for this and I am such a beginner with Linux that it will be a steep learning curve for me, but I will be happy to embark on it if someone can confirm for me this will do what I am hoping. Perhaps I should be asking if there is an easier solution as well? Logging to an SD card and later manual upload for example? A patch for the KiwiSDR code to do this directly on the Kiwi? Ideas anyone?
Best regards all...joe
Thanks for the very quick and informative response. Since I have no experience with the Pi, before I buy one do you have any other recommendations given that I intend to run this from a battery and am concerned about shielding emissions from the Pi while keeping it cool, the typical plastic cases they push at the Pi outlets are probably not what I want. I see the Pi 4B requires 3.1A, I was initially envisioning running the Kiwi on one of those 1MHz buck converters which are relatively RF quiet but I guess that idea won't work for the Pi-4B as the SMPS is rated for 3A max.
Joe
To be honest, though I have a portable system intended to approach the propagated noise floor over LF-HF I continue to learn about impediments to achieving this. My current best method, subject to change, is to only use a WiFi interface to the Kiwi. For a BBG/Kiwi I use the "YT" attached via USB, as documented on the kiwiSDR forum. For the BBG/AI I use its built-in WiFi. These are colocated with a very symmetric 2 m reference dipole active antenna of known characteristics and high common mode rejection.Even so, the power management IC within the BB's as well as other digital activity on those boards is still perhaps visible in some situations. For some measurements I have constructed a 3D printed AzEl rotor, also interfaced by WiFi and without any connections which is also used to learn about polarization and direction of signal and noise sources. I am leaning toward using only linear power supplies to convert to the various voltages needed by the Kiwi, preamps and rotator.
Doing it this way, the RPI has no wired connection to the kiwi, either by power supply or network conductors. This is important to reduce the possibility for common-mode current injection which can degrade the noise floor. I'm tending to use an access point (but not the routing function built into YT and similar wireless/routers) to communicate with the stand-alone Kiwi/AxEl rotor system and either the RPI or monitoring laptop which can be located at significant distance so don't contribute to the measurement data.
Glenn n6gn
Hi Glenn
Thanks for the very quick and informative response. Since I have no experience with the Pi, before I buy one do you have any other recommendations given that I intend to run this from a battery and am concerned about shielding emissions from the Pi while keeping it cool, the typical plastic cases they push at the Pi outlets are probably not what I want. I see the Pi 4B requires 3.1A, I was initially envisioning running the Kiwi on one of those 1MHz buck converters which are relatively RF quiet but I guess that idea won't work for the Pi-4B as the SMPS is rated for 3A max.
Joe
Joe,
To be honest, though I have a portable system intended to approach the
propagated noise floor over LF-HF I continue to learn about impediments
to achieving this. My current best method, subject to change, is to
only use a WiFi interface to the Kiwi. For a BBG/Kiwi I use the "YT"
attached via USB, as documented on the kiwiSDR forum. For the BBG/AI I
use its built-in WiFi. These are colocated with a very symmetric 2 m
reference dipole active antenna of known characteristics and high common
mode rejection.Even so, the power management IC within the BB's as well
as other digital activity on those boards is still perhaps visible in
some situations. For some measurements I have constructed a 3D printed
AzEl rotor, also interfaced by WiFi and without any connections which is
also used to learn about polarization and direction of signal and noise
sources. I am leaning toward using only linear power supplies to
convert to the various voltages needed by the Kiwi, preamps and rotator.
Doing it this way, the RPI has no wired connection to the kiwi, either
by power supply or network conductors. This is important to reduce the
possibility for common-mode current injection which can degrade the
noise floor. I'm tending to use an access point (but not the routing
function built into YT and similar wireless/routers) to communicate with
the stand-alone Kiwi/AxEl rotor system and either the RPI or monitoring
laptop which can be located at significant distance so don't contribute
to the measurement data.
Glenn n6gn
On 7/14/21 10:17 AM, VE3VXO wrote:
> Hi Glenn
>
> Thanks for the very quick and informative response. Since I have no
> experience with the Pi, before I buy one do you have any other
> recommendations given that I intend to run this from a battery and am
> concerned about shielding emissions from the Pi while keeping it cool,
> the typical plastic cases they push at the Pi outlets are probably not
> what I want. I see the Pi 4B requires 3.1A, I was initially
> envisioning running the Kiwi on one of those 1MHz buck converters
> which are relatively RF quiet but I guess that idea won't work for the
> Pi-4B as the SMPS is rated for 3A max.
>
> Joe
Thanks Rob and Glenn for your comments.
I am doing tests with a pair of phased loops so good current balance and they are each coupled to their feedline through an isolation transformer at the amtenna end and each also have a feedline choke with good common mode isolation at the frequencies of interest as well to guard against common mode noise injection at least on the feedline end of things. I think for the ground loop issues I will try to simplify and eliminate CM noise sources and ground loops as follows. I discovered a clone of the KiwiSDR called flydog which uses a Pi 3B or even 4B (but ships with a 3B). If there are enough resources there to run the Kiwi host and WD concurrently it will help a lot with these issues. I'm guessing I will need a 4B with some extra memory. Since the logging will be done without any internet whatsoever that's another noise source eliminated and I can use a substantial lithium battery which I already have with a linear regulator for the tests. I don't know if this knock off SDR is any good, but I don't have any backup for my bonafide SEED KiwiSDR so this will serve as an exploration of the clone and possible backup for the good one as well and allow it to stay safely at home. I like it too much to leave it out in a field overnight!
Joe
Thanks Rob and Glenn for your comments.
I am doing tests with a pair of phased loops so good current balance and they are each coupled to their feedline through an isolation transformer at the amtenna end and each also have a feedline choke with good common mode isolation at the frequencies of interest as well to guard against common mode noise injection at least on the feedline end of things. I think for the ground loop issues I will try to simplify and eliminate CM noise sources and ground loops as follows. I discovered a clone of the KiwiSDR called flydog which uses a Pi 3B or even 4B (but ships with a 3B). If there are enough resources there to run the Kiwi host and WD concurrently it will help a lot with these issues. I'm guessing I will need a 4B with some extra memory. Since the logging will be done without any internet whatsoever that's another noise source eliminated and I can use a substantial lithium battery which I already have with a linear regulator for the tests. I don't know if this knock off SDR is any good, but I don't have any backup for my bonafide SEED KiwiSDR so this will serve as an exploration of the clone and possible backup for the good one as well and allow it to stay safely at home. I like it too much to leave it out in a field overnight!
Joe
Joe,
Be careful not to underestimate the amount of CM rejection you may need. A Mini-Circuits T1-1 transformer, for example, has around 1 pf interwinding capacitance. That may produce less than 30 dB CM rejection. Similarly, chokes only generate a few k-ohms, at best, broadband and against the few hundred ohm source Z of many long cable/wire CM sources don't do a whole lot. If one injects a signal between the LAN-side 'ground' on a Kiwi and the SMA ground on the other end, the unwanted coupling is only around 80 dB down at midband and not more than 100 dB een down at LF> Considering the kinds of currents that may exist on longisy LAN or antenna cables, it may take a *lot* of rejection to stay below the Kiwi's -157 dBm/1-Hz (or so) noise floor.
I'd not suggest using the Kiwi decoder. It was compiled from a much older and less capable decoder and fed with the same signal does not produce as many successful decodes even if/when it can keep up with the volume of traffic.
Recording/decoding on a separate RPI connected via WiFi gets
around the interference noise source problem.
There have been some comparisons of knock-off v 'normal' Kiwis
and AFAIK, the knock offs don't seem to do any better and maybe
not even as well for most uses. KA7OEI has written
about some of this on his blog.
You may decide differently but for myself, I'm not inclined to
give freeloaders, those trying to make profit with little or no
return on others' efforts my support. I understand, but don't
know for sure, that there was even contention between a 2nd
knock-off and the first. I suspect you would get better support
from a stock Kiwi, should you stay that way.
Thanks Rob and Glenn for your comments.
I am doing tests with a pair of phased loops so good current balance and they are each coupled to their feedline through an isolation transformer at the amtenna end and each also have a feedline choke with good common mode isolation at the frequencies of interest as well to guard against common mode noise injection at least on the feedline end of things. I think for the ground loop issues I will try to simplify and eliminate CM noise sources and ground loops as follows. I discovered a clone of the KiwiSDR called flydog which uses a Pi 3B or even 4B (but ships with a 3B). If there are enough resources there to run the Kiwi host and WD concurrently it will help a lot with these issues. I'm guessing I will need a 4B with some extra memory. Since the logging will be done without any internet whatsoever that's another noise source eliminated and I can use a substantial lithium battery which I already have with a linear regulator for the tests. I don't know if this knock off SDR is any good, but I don't have any backup for my bonafide SEED KiwiSDR so this will serve as an exploration of the clone and possible backup for the good one as well and allow it to stay safely at home. I like it too much to leave it out in a field overnight!
Joe
Hi Glenn
If I can run the SDR and WD on a single Pi in a shielded box with no LAN then the only external connections will be a short battery lead and the coaxial lead in. The phased pair I described are on 50 ft double shielded LMR-100A feedlines so as short as possible and a lumped element Pi network for the phase delay feeding into a minicircuits ZFSCJ-2-1 inverting combiner. The chokes I made should give about 5k ohms at the low end of HF, will this not be sufficient?
Joe
---------- Original Message ----------
From: Glenn Elmore <n6gn@...>
Date: July 14, 2021 at 4:38 PM
Joe,
Be careful not to underestimate the amount of CM rejection you may need. A Mini-Circuits T1-1 transformer, for example, has around 1 pf interwinding capacitance. That may produce less than 30 dB CM rejection. Similarly, chokes only generate a few k-ohms, at best, broadband and against the few hundred ohm source Z of many long cable/wire CM sources don't do a whole lot. If one injects a signal between the LAN-side 'ground' on a Kiwi and the SMA ground on the other end, the unwanted coupling is only around 80 dB down at midband and not more than 100 dB een down at LF> Considering the kinds of currents that may exist on longisy LAN or antenna cables, it may take a *lot* of rejection to stay below the Kiwi's -157 dBm/1-Hz (or so) noise floor.
I'd not suggest using the Kiwi decoder. It was compiled from a much older and less capable decoder and fed with the same signal does not produce as many successful decodes even if/when it can keep up with the volume of traffic.
Recording/decoding on a separate RPI connected via WiFi gets around the interference noise source problem.
There have been some comparisons of knock-off v 'normal' Kiwis and AFAIK, the knock offs don't seem to do any better and maybe not even as well for most uses. KA7OEI has written about some of this on his blog.
You may decide differently but for myself, I'm not inclined to give freeloaders, those trying to make profit with little or no return on others' efforts my support. I understand, but don't know for sure, that there was even contention between a 2nd knock-off and the first. I suspect you would get better support from a stock Kiwi, should you stay that way.
On 7/14/21 2:06 PM, VE3VXO wrote:
Thanks Rob and Glenn for your comments.
I am doing tests with a pair of phased loops so good current balance and they are each coupled to their feedline through an isolation transformer at the amtenna end and each also have a feedline choke with good common mode isolation at the frequencies of interest as well to guard against common mode noise injection at least on the feedline end of things. I think for the ground loop issues I will try to simplify and eliminate CM noise sources and ground loops as follows. I discovered a clone of the KiwiSDR called flydog which uses a Pi 3B or even 4B (but ships with a 3B). If there are enough resources there to run the Kiwi host and WD concurrently it will help a lot with these issues. I'm guessing I will need a 4B with some extra memory. Since the logging will be done without any internet whatsoever that's another noise source eliminated and I can use a substantial lithium battery which I already have with a linear regulator for the tests. I don't know if this knock off SDR is any good, but I don't have any backup for my bonafide SEED KiwiSDR so this will serve as an exploration of the clone and possible backup for the good one as well and allow it to stay safely at home. I like it too much to leave it out in a field overnight!
Joe
If I can run the SDR and WD on a single Pi in a shielded box with no LAN then the only external connections will be a short battery lead and the coaxial lead in. The phased pair I described are on 50 ft double shielded LMR-100A feedlines so as short as possible and a lumped element Pi network for the phase delay feeding into a minicircuits ZFSCJ-2-1 inverting combiner. The chokes I made should give about 5k ohms at the low end of HF, will this not be sufficient?
Joe
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?
Joe
---------- Original Message ----------
From: Glenn Elmore <n6gn@...>
Date: July 14, 2021 at 6:28 PM
Only measurement will tell for sure but it isn't uncommon for a even a
co-located device to create a loop with power supply and wired LAN
connections. Shielding probably won't matter or help. If the entire
arrangement is within a small volume then self-capacitance can be low
and paths in one line and out another, through the Kiwi 'grounds' , may
not be enough to cause a problem but even then edges whether LAN or
SMPS may cause QRM. Try it and see. If you always have a symmetric
antenna then it may be possible to short out only the
desired/differential part and verify that any remaining CM is well below
the measurement level.
On 7/14/21 4:19 PM, VE3VXO wrote:
>
>
> If I can run the SDR and WD on a single Pi in a shielded box with no
> LAN then the only external connections will be a short battery lead
> and the coaxial lead in. The phased pair I described are on 50 ft
> double shielded LMR-100A feedlines so as short as possible and a
> lumped element Pi network for the phase delay feeding into a
> minicircuits ZFSCJ-2-1 inverting combiner. The chokes I made should
> give about 5k ohms at the low end of HF, will this not be sufficient?
>
> Joe
>
>
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?
Joe
---------- Original Message ----------
From: Glenn Elmore <n6gn@...>
Date: July 14, 2021 at 6:28 PM
Only measurement will tell for sure but it isn't uncommon for a even a
co-located device to create a loop with power supply and wired LAN
connections. Shielding probably won't matter or help. If the entire
arrangement is within a small volume then self-capacitance can be low
and paths in one line and out another, through the Kiwi 'grounds' , may
not be enough to cause a problem but even then edges whether LAN or
SMPS may cause QRM. Try it and see. If you always have a symmetric
antenna then it may be possible to short out only the
desired/differential part and verify that any remaining CM is well below
the measurement level.
On 7/14/21 4:19 PM, VE3VXO wrote:
>
>
> If I can run the SDR and WD on a single Pi in a shielded box with no
> LAN then the only external connections will be a short battery lead
> and the coaxial lead in. The phased pair I described are on 50 ft
> double shielded LMR-100A feedlines so as short as possible and a
> lumped element Pi network for the phase delay feeding into a
> minicircuits ZFSCJ-2-1 inverting combiner. The chokes I made should
> give about 5k ohms at the low end of HF, will this not be sufficient?
>
> Joe
>>
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.
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?
Yeah you are still not getting what I'm proposing Glenn, but Rob's message just now answered my question that it should be possible. In the scheme I'm proposing there is no second hardware connecting to the SDR. The wspr daemon code is executing in the same CPU as the KiwiSDR code concurrently. This might be possible on a RaspberrySDR which I should have said instead of calling it KiwiSDR. So I would just have a RaspberrySDR with WD running on it in the background sharing the same local port :8073. Get it?
Joe
---------- Original Message ----------
From: Glenn Elmore <n6gn@...>
Date: July 14, 2021 at 8:11 PM
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).
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?
>
Yeah you are still not getting what I'm proposing Glenn, but Rob's message just now answered my question that it should be possible. In the scheme I'm proposing there is no second hardware connecting to the SDR. The wspr daemon code is executing in the same CPU as the KiwiSDR code concurrently. This might be possible on a RaspberrySDR which I should have said instead of calling it KiwiSDR. So I would just have a RaspberrySDR with WD running on it in the background sharing the same local port :8073. Get it?
Joe
---------- Original Message ----------
From: Glenn Elmore <n6gn@...>
Date: July 14, 2021 at 8:11 PM
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).
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?>
Yes I think I muddied the waters by referring to KiwiSDR when I meant the RaspberrySDR. Anyways, it's all clear now and thanks to you both for being patient with me and answering my questions to the degree I am confident to go forward with this idea. And thanks for wsprdaemon Rob.
Best regards...Joe
---------- Original Message ----------
From: Rob Robinett <rob@...>
Date: July 14, 2021 at 8:30 PM
Hi Joe,
To be clear, if you are using a RaspberySDR one would configure the Kiwi's address as localhost:8073.
Glenn's configuration [Pi wifi client with its own PSU] ---- wifi ----[Yellow Thing running as Wifi AP] === USB ==== [Kiwi] , the Kiwi's IP address is 192.168.7.2:8073
Rob
On Jul 14, 2021, at 20:41, VE3VXO <ve3vxo@...> wrote:
Yes I think I muddied the waters by referring to KiwiSDR when I meant the RaspberrySDR. Anyways, it's all clear now and thanks to you both for being patient with me and answering my questions to the degree I am confident to go forward with this idea. And thanks for wsprdaemon Rob.
Best regards...Joe
---------- Original Message ----------
From: Rob Robinett <rob@...>
Date: July 14, 2021 at 8:30 PM
Hi Joe,
To be clear, if you are using a RaspberySDR one would configure the Kiwi's address as localhost:8073.
Glenn's configuration [Pi wifi client with its own PSU] ---- wifi ----[Yellow Thing running as Wifi AP] === USB ==== [Kiwi] , the Kiwi's IP address is 192.168.7.2:8073
Rob
Jumping in late but wouldn’t a KiwiSDR with a BB AI have enough horsepower to run the receiver and wsprdaemon? Cooling would have to be addressed with a heatsink addition.Steve KD2OM.On Jul 14, 2021, at 20:41, VE3VXO <ve3vxo@...> wrote:Yes I think I muddied the waters by referring to KiwiSDR when I meant the RaspberrySDR. Anyways, it's all clear now and thanks to you both for being patient with me and answering my questions to the degree I am confident to go forward with this idea. And thanks for wsprdaemon Rob.
Best regards...Joe
---------- Original Message ----------
From: Rob Robinett <rob@...>
Date: July 14, 2021 at 8:30 PM
Hi Joe,
To be clear, if you are using a RaspberySDR one would configure the Kiwi's address as localhost:8073.
Glenn's configuration [Pi wifi client with its own PSU] ---- wifi ----[Yellow Thing running as Wifi AP] === USB ==== [Kiwi] , the Kiwi's IP address is 192.168.7.2:8073
Rob
Yeah you are still not getting what I'm proposing Glenn, but Rob's message just now answered my question that it should be possible. In the scheme I'm proposing there is no second hardware connecting to the SDR. The wspr daemon code is executing in the same CPU as the KiwiSDR code concurrently. This might be possible on a RaspberrySDR which I should have said instead of calling it KiwiSDR. So I would just have a RaspberrySDR with WD running on it in the background sharing the same local port :8073. Get it?
Joe
---------- Original Message ----------
From: Glenn Elmore <n6gn@...>
Date: July 14, 2021 at 8:11 PM
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).
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?>