That's interesting.  I tried modelling several different variations but for the phased pair I found that deviating from the corner driven diamond shape resulted in degredation to the pattern either in the RDF or degrading the low elevation response.

Before this thread is done I just wanted to rspond to you Glenn on your good points about supporting the original design and the ongoing development which I do take seriously.  Please remember I do already have a genuine KiwiSDR bought through Seed Studio so I have given financial support to the designer already.  It was hard to get at the time and for us canucks with worthless currency the price differential is substantial so that might be a deciding factor for some folks.  For me right now, as you now understand I'm trying to go for something very specific leveraging the ability to run more code on the cpu and avoid ground loops for one and also have something simple and compact that is easy to deploy in a remote location with no internet while logging spots to a file for later upload, and the original kiwiSDR won't do latent uploads although I did request this as a feature for consideration twice on the valentfx forum in the time since I've owned one and there was no response to it whatsoever.  If my original KiwiSDR could simply run as a reporter without web connectivity and upload when the web is available I wouldn't be considering any other option at all. So it looks like this newer design might be the better choice for me in this particular instance. I hope so, time will tell.

Joe

Yes well, it may be a while but I will certainly do so.  This started out with me trying to use a phased pair of LoG antennas to improve reception of europeans on 160m to my tiny noisy suburban lot without towers and huge antennas.  KK5JY suggests a phased pair of LoG's can give a cardioid pattern with a broad backside null.  I am getting some deep nulling but in an unexpected direction and it doesn't appear that the pattern is what I had hoped and I'm guessing local conductive objects and maybe the TX antenna are destroying the patten of the pair.  Or maybe something else is messing with me like the fact that the antennas are sitting on a high K dielectric which means that the effective separation distance isn't the same as the physical separation??  So getting out in the clear might help clear this up (pun intended).  Hopefully I can plow through setting all this up before 160m season is upon us.  One thing I have wished for is that in setting up the search terms for the map one could specify the TX power level of the spotted stations which would help with making the map more representative of the antenna pattern.  There are a lot of factors along the path and at the TX end that can play havoc with what I am trying to do obviously but now that I see the power of these newer data analysis tools I think there may be something to the idea at least I should give it a try.

Thanks for your help and encouragement guys....Joe

---------- Original Message ----------
From: Rob Robinett <rob@...>
Date: July 14, 2021 at 11:06 PM

Joe,

Please report your results!

Rob

OK. My mail out of synch on phone so not seeing corrections properly.

Rpi of a flydog or similar rpi kiwi and without any external network interface doesn't have the same cm potential. 

It does still have local rpi interference potential though so system still needs to be examined to assure adequate floor compared to KTB in antenna's radiation resistance as coupled to the kiwi input.

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?

>

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?

>

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
>

>