Date   

8088 Page restored

Jim Lill
 

After a power loss related issue, a few days ago. The header of my Ranking Page is now working again.

-Jim


Re: 8 way splitter for GPS to kiwi's and GPSDO needed

Jim Lill
 

ground paths via GPS can be a real issue. I have found that the Time Machine stuff is very bad.

On 6/19/21 2:46 PM, Rob Robinett wrote:
Glen is of course right that it is desirable to not have a GPS splitter introduce ground loops between Kiwis.

However like Steve I have been very successful using simple satellite splitters like this one available from amamzon.fr for 16 euros:


At KPH and at AI6VN/KH6 I put the GPS antenna on the roof and ran 30M of RG-6 to the splitter, then directly connected the splitter output to the Kiwis and have run that way for years without problems.  The RF signal gain from having the antenna on the top of the roof more than makes up for the 12 dB signal loss in the RG-6 and the additional 10+ dB in the splitter.

I use no DC blocking.  Test the RFI level with and without the GPS connections to the Kiwis to see if introducing the splitter adds to your RFI.  If so, then a specialized splitter is of course justified.
   

On Sat, Jun 19, 2021 at 9:59 AM Glenn Elmore <n6gn@...> wrote:
Lots of splitters available but they all end up tieing grounds together which can make a bad situation worse and more complex.
Complete low frequency isolation is desireable but requires special effort.

On Jun 19, 2021 10:31 AM, KD2OM <steve@...> wrote:
Ulli,
I don’t know if an 8 port splitter is available but I am using a 4 port TVRO splitter. The ones meant for satellite TV have one DC thru port and the rest DC blocked. I would imagine the same type is available in Europe. It is 75 ohms with F connectors.

73,
Steve KD2OM 



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Re: 8 way splitter for GPS to kiwi's and GPSDO needed

Rob Robinett
 

Glen is of course right that it is desirable to not have a GPS splitter introduce ground loops between Kiwis.

However like Steve I have been very successful using simple satellite splitters like this one available from amamzon.fr for 16 euros:


At KPH and at AI6VN/KH6 I put the GPS antenna on the roof and ran 30M of RG-6 to the splitter, then directly connected the splitter output to the Kiwis and have run that way for years without problems.  The RF signal gain from having the antenna on the top of the roof more than makes up for the 12 dB signal loss in the RG-6 and the additional 10+ dB in the splitter.

I use no DC blocking.  Test the RFI level with and without the GPS connections to the Kiwis to see if introducing the splitter adds to your RFI.  If so, then a specialized splitter is of course justified.
   

On Sat, Jun 19, 2021 at 9:59 AM Glenn Elmore <n6gn@...> wrote:
Lots of splitters available but they all end up tieing grounds together which can make a bad situation worse and more complex.
Complete low frequency isolation is desireable but requires special effort.

On Jun 19, 2021 10:31 AM, KD2OM <steve@...> wrote:
Ulli,
I don’t know if an 8 port splitter is available but I am using a 4 port TVRO splitter. The ones meant for satellite TV have one DC thru port and the rest DC blocked. I would imagine the same type is available in Europe. It is 75 ohms with F connectors.

73,
Steve KD2OM 



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Re: 8 way splitter for GPS to kiwi's and GPSDO needed

Glenn Elmore
 

Lots of splitters available but they all end up tieing grounds together which can make a bad situation worse and more complex.
Complete low frequency isolation is desireable but requires special effort.

On Jun 19, 2021 10:31 AM, KD2OM <steve@...> wrote:
Ulli,
I don’t know if an 8 port splitter is available but I am using a 4 port TVRO splitter. The ones meant for satellite TV have one DC thru port and the rest DC blocked. I would imagine the same type is available in Europe. It is 75 ohms with F connectors.

73,
Steve KD2OM 


Re: 8 way splitter for GPS to kiwi's and GPSDO needed

KD2OM
 

Ulli,
I don’t know if an 8 port splitter is available but I am using a 4 port TVRO splitter. The ones meant for satellite TV have one DC thru port and the rest DC blocked. I would imagine the same type is available in Europe. It is 75 ohms with F connectors.

73,
Steve KD2OM 


Re: 8 way splitter for GPS to kiwi's and GPSDO needed

WA2TP - Tom
 

Ulli,

I had this same request and brought it to the attention of Makis SV1AFN.

He advised he is working on an 8 port with filtering (an active splitter with 4 or 8 ports, with filters against cell-phones and towers and for all GNSS bands).

I have tied him in so he is aware of the growing need and interest.

Tom
WA2TP 

On Jun 19, 2021, at 11:48 AM, Glenn Elmore <n6gn@...> wrote:



Ulli,

I think you are correct in stating your requirements.  I don't have a complete solution to recommend but I did build a DC isolating GPS board that serves to provide GPS to a single Kiwi without also adding a low frequency path.  For those running multiple Kiwi's from a single GPS source, probably an N-way version of that along with a single DC bias tee or connection to one of the GPS ports is what needs to be constructed. But then there's the question of "what is N?" and 2,4 8 way versions of the thing would need to be fab'd.

It's probably simpler to run dedicated GPS antennas on each Kiwi in situations where a good antenna location is close enough. For the general situation like you describe, an isolating filter is really what is desirable.

Glenn

On 6/19/21 4:59 AM, ON5KQ wrote:
Hi,
Can anyone recommend a 8way splitter to connect my kiwis and a GPSDO for my lab.
What technology I need to look for, to pass DC to the outside antenna but don't (DC-)connect all Kiwis together... I think the kiwis need to be (DC-)isolated to each other

I do not want to import from outside EU however, as current customs costs are horrendous...

Ulli, ON5KQ


Re: 8 way splitter for GPS to kiwi's and GPSDO needed

Glenn Elmore
 

Ulli,

I think you are correct in stating your requirements.  I don't have a complete solution to recommend but I did build a DC isolating GPS board that serves to provide GPS to a single Kiwi without also adding a low frequency path.  For those running multiple Kiwi's from a single GPS source, probably an N-way version of that along with a single DC bias tee or connection to one of the GPS ports is what needs to be constructed. But then there's the question of "what is N?" and 2,4 8 way versions of the thing would need to be fab'd.

It's probably simpler to run dedicated GPS antennas on each Kiwi in situations where a good antenna location is close enough. For the general situation like you describe, an isolating filter is really what is desirable.

Glenn

On 6/19/21 4:59 AM, ON5KQ wrote:
Hi,
Can anyone recommend a 8way splitter to connect my kiwis and a GPSDO for my lab.
What technology I need to look for, to pass DC to the outside antenna but don't (DC-)connect all Kiwis together... I think the kiwis need to be (DC-)isolated to each other

I do not want to import from outside EU however, as current customs costs are horrendous...

Ulli, ON5KQ


8 way splitter for GPS to kiwi's and GPSDO needed

ON5KQ
 

Hi,
Can anyone recommend a 8way splitter to connect my kiwis and a GPSDO for my lab.
What technology I need to look for, to pass DC to the outside antenna but don't (DC-)connect all Kiwis together... I think the kiwis need to be (DC-)isolated to each other

I do not want to import from outside EU however, as current customs costs are horrendous...

Ulli, ON5KQ


Re: One more kfs reception report after attenuators are in position again...

Rob Robinett
 

Thanks Ulli.


On Thu, Jun 17, 2021 at 6:27 AM ON5KQ <ON5KQ@...> wrote:
0h15 (just after midnight California time)

kfs report:
- port 8073
*no OV-indications
*background noise on dead bands (10m,12m...) is too high. Instead of -100dbm noiselevel, in this condition the kiwi-sdr should show -110..-108dbm at maximum (AMwide S-meter reading). As the receiver noise is roughly -115...-117dbm this would make sure that the background noise is at least 6db higher than receiver noise.
Although overloading is not visible is not visible, the bottom 10db sensitivity is useless and available dynamic range should be used for strong signals.
So additional 6db attenuation would improve the situation on low frequencies at night without effecting 10m sensitivity at all during the day.
* slight BC-IMD visible at low frequencies - every 10kHz carriers...
*20db attenuation notch on 3475kHz affects 80m CW, especially weak DX-reception (weak signals cannot be heard!)

-port 8074
*no 0V indication (ADC clipping) visible
*sensitivity on 10m is just right - background noise of -108dbm on 10m is ok
*strong IMD on low frequencies, due to signal distribution fault. Although overall signal strength is lower than on 8073, the IMD is much stronger
*1.8Mhz up to 80m (3.5Mhz) cannot be used due to the IMD at night

-port 8075
*no 0V indication
* background noise level on dead band excellent (-109dbm is just about right)
*no IMD on lowbands
*typical noise from the cellphone cabin is not visible at night although 8843 noise level is low this night (-100dbm at AM-wide)
*unfortunately no 160m...
*overall very good antenna and good set-up

- port 8076
*no 0V indication
* background noise level on dead band excellent (-110dbm is just about right)
*no IMD on lowbands
*unfortunately not usable below 3.5Mhz due to high pass filter
*typical noise from the cellphone cabin is not visible at night, in the 8Mhz band, 8843 noise level is much higher than on 8075 antenna (-89dbm at AM-wide due to high QRN)
*noise level on the low bands is by far the highest on all antennas. I wonder how often the kfs operators switch antennas at all....hi
*very pronounced directivity would be good for hamradio however...

regards,
Ulli, ON5KQ



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


One more kfs reception report after attenuators are in position again...

ON5KQ
 

0h15 (just after midnight California time)

kfs report:
- port 8073
*no OV-indications
*background noise on dead bands (10m,12m...) is too high. Instead of -100dbm noiselevel, in this condition the kiwi-sdr should show -110..-108dbm at maximum (AMwide S-meter reading). As the receiver noise is roughly -115...-117dbm this would make sure that the background noise is at least 6db higher than receiver noise.
Although overloading is not visible is not visible, the bottom 10db sensitivity is useless and available dynamic range should be used for strong signals.
So additional 6db attenuation would improve the situation on low frequencies at night without effecting 10m sensitivity at all during the day.
* slight BC-IMD visible at low frequencies - every 10kHz carriers...
*20db attenuation notch on 3475kHz affects 80m CW, especially weak DX-reception (weak signals cannot be heard!)

-port 8074
*no 0V indication (ADC clipping) visible
*sensitivity on 10m is just right - background noise of -108dbm on 10m is ok
*strong IMD on low frequencies, due to signal distribution fault. Although overall signal strength is lower than on 8073, the IMD is much stronger
*1.8Mhz up to 80m (3.5Mhz) cannot be used due to the IMD at night

-port 8075
*no 0V indication
* background noise level on dead band excellent (-109dbm is just about right)
*no IMD on lowbands
*typical noise from the cellphone cabin is not visible at night although 8843 noise level is low this night (-100dbm at AM-wide)
*unfortunately no 160m...
*overall very good antenna and good set-up

- port 8076
*no 0V indication
* background noise level on dead band excellent (-110dbm is just about right)
*no IMD on lowbands
*unfortunately not usable below 3.5Mhz due to high pass filter
*typical noise from the cellphone cabin is not visible at night, in the 8Mhz band, 8843 noise level is much higher than on 8075 antenna (-89dbm at AM-wide due to high QRN)
*noise level on the low bands is by far the highest on all antennas. I wonder how often the kfs operators switch antennas at all....hi
*very pronounced directivity would be good for hamradio however...

regards,
Ulli, ON5KQ


Re: What happens with old spots not yet uploaded (probably because of Internet failure) but stored in txt files...

Rob Robinett
 

The wsprnet upload API is not well documented and so I had to experiment with its usage and failure modes.
I found that some batch uploads are accepted by wsprnet, but in its status response wsprnet would say that it accept only some of the spots in the batch (e.g. 190 of 200 spots).
It does not identify which spots were not accepted and if I attempt to reload the whole batch it will reject them all.
Those problems are among the reasons we implemented the wsprdaemon.org extended spots database where we have complete control of the server.
Perhaps someone with more patience and/or influence with wsprnet can resolve this problem, but I think it more productive to work on V3.0

On Mon, Jun 14, 2021 at 5:41 PM WA2TP <myis300@...> wrote:
I too had seen this in the past where wsprdaemon buffered over 3000 spots while my internet was down for several hours, and when the internet connection restored, after ~15 minutes, WSPRNET accepted only 60 of those 3000 buffered spots for some reason. 

Nothing remained in any of the wsprdaemon folders. No idea where the other 2900+ spots went to.

I think I had sent this info to Rob back when this occurred.

Tom
WA2TP 


On Jun 14, 2021, at 8:00 PM, Rob Robinett <rob@...> wrote:


Yes, I think the WD upload service only looks for spot files in receivers which are currently scheduled to be running. That does seem to be a potential source of late uploaded spots, although spots are never flushed until they have been successfully uploaded.   I have added working on that to the v3.0 TODO list.


I don’t know how wsprnet handles such spots, although Glenn has reported success with uploads delayed by hours or a day.  wsprnet assigns a unique 64 bit number to each spot it receives, and in cloning the wsprnet DB I validate that there are no gaps in the spot number sequence.

On Mon, Jun 14, 2021 at 8:17 AM ON5KQ <ON5KQ@...> wrote:
Dear,
During last night I probably had an Internet connection failuer, so from 20h utc yesterday until 4h utc in the morning, there was nothing uploaded.
The wsprdaemon script created a lot of txt files instead (containing the decoded spots during that time). In the meantime the wsprdaemon.conf file switched from nighttime to daylight schedule and a little later during the new daylight schedule the Internet came back.

Because of the new daylight schedule running, the wsprdaemon script didn't realize , that from the nighttime schedule (not active anymore) there were still a lot of ,txt files containing the spots to be uploaded. 
If I remember correctly all the .txt files with the nighttime spots were in this directory
/home/wsprdaemon/uploads.d/wsprnet.d/spots.d/ ....   and channel by channel the txt files were written for every 2min of transmission.

I was wondering, why the waiting spots were not uploaded immediately as the Internet came back in the morning...

To find out,  I restarted with "./wsprdaemon.sh -vvva"  to force high verbosity to check the various log files.
I found that the script searched for txt files to be uploaded, but not in the nighttime folder, but the current job folder for the running daytime schedule - so it would not immediately find the hundreds of waiting txt files only after roughly another 12h, when the night schedule becomes active again.

However, I didn't want to wait that long so...
(I am not sure, if it was correct, what I did then....):
- to upload the waiting txt files immediately, I stopped wsprdaemon with
./wsprdaemon.sh -z
then changed wsprdaemon.conf in that way, that the nighttime schedule was resumed instead of starting the daytime schedule.
Started again with:
./wsprdaemon.sh -vvva

Now In the logs I could see, that immediately more than 300 txt files waiting for upload were found from the script
Quickly the logs also showed that after a while many many uploads were done - it must be thousands of spots...

After a while, all txt files were erased and I found in the curl-logs the confirmation of upload acceptance... again thousands. I was wondering however that all that was only a matter of minutes - the missing upload was very quick...

So, I was happy and stopped wsprdaemon, as I did not want to write too much data in the log-files with that high verbosity level.
So, I restarted with
./wsprdaemon.sh -a

Now what::
Hours later now, still there are no spots at all between 22h yesterday and 6h this morning - neither on wsprnet.org, nor on vk7jj's website...

It would be great to understand what really happened with the uploaded spots from partly today and partly from yesterday (based on utc time)

Will the missing spots ever appear ?
Why I got a confirmation of acceptance for thousands of spots in the curl-file, when these spots never appear ?
What did I wrong, that still no missing spot is delivered and how should I proceed next time to prevent data loss.

Or do just need to wait longer for the data to appear (may be one day or so ?!)
I am confused...hi

May be Rob can explain in the next zoom-meeting, how the upload of old spots really works - either because of Internet connection problems or even after portable kiwi operation in the field with later upload from home (Glenn's application ?!)

regards,
Ulli, ON5KQ



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Re: What happens with old spots not yet uploaded (probably because of Internet failure) but stored in txt files...

WA2TP - Tom
 

I too had seen this in the past where wsprdaemon buffered over 3000 spots while my internet was down for several hours, and when the internet connection restored, after ~15 minutes, WSPRNET accepted only 60 of those 3000 buffered spots for some reason. 

Nothing remained in any of the wsprdaemon folders. No idea where the other 2900+ spots went to.

I think I had sent this info to Rob back when this occurred.

Tom
WA2TP 


On Jun 14, 2021, at 8:00 PM, Rob Robinett <rob@...> wrote:


Yes, I think the WD upload service only looks for spot files in receivers which are currently scheduled to be running. That does seem to be a potential source of late uploaded spots, although spots are never flushed until they have been successfully uploaded.   I have added working on that to the v3.0 TODO list.


I don’t know how wsprnet handles such spots, although Glenn has reported success with uploads delayed by hours or a day.  wsprnet assigns a unique 64 bit number to each spot it receives, and in cloning the wsprnet DB I validate that there are no gaps in the spot number sequence.

On Mon, Jun 14, 2021 at 8:17 AM ON5KQ <ON5KQ@...> wrote:
Dear,
During last night I probably had an Internet connection failuer, so from 20h utc yesterday until 4h utc in the morning, there was nothing uploaded.
The wsprdaemon script created a lot of txt files instead (containing the decoded spots during that time). In the meantime the wsprdaemon.conf file switched from nighttime to daylight schedule and a little later during the new daylight schedule the Internet came back.

Because of the new daylight schedule running, the wsprdaemon script didn't realize , that from the nighttime schedule (not active anymore) there were still a lot of ,txt files containing the spots to be uploaded. 
If I remember correctly all the .txt files with the nighttime spots were in this directory
/home/wsprdaemon/uploads.d/wsprnet.d/spots.d/ ....   and channel by channel the txt files were written for every 2min of transmission.

I was wondering, why the waiting spots were not uploaded immediately as the Internet came back in the morning...

To find out,  I restarted with "./wsprdaemon.sh -vvva"  to force high verbosity to check the various log files.
I found that the script searched for txt files to be uploaded, but not in the nighttime folder, but the current job folder for the running daytime schedule - so it would not immediately find the hundreds of waiting txt files only after roughly another 12h, when the night schedule becomes active again.

However, I didn't want to wait that long so...
(I am not sure, if it was correct, what I did then....):
- to upload the waiting txt files immediately, I stopped wsprdaemon with
./wsprdaemon.sh -z
then changed wsprdaemon.conf in that way, that the nighttime schedule was resumed instead of starting the daytime schedule.
Started again with:
./wsprdaemon.sh -vvva

Now In the logs I could see, that immediately more than 300 txt files waiting for upload were found from the script
Quickly the logs also showed that after a while many many uploads were done - it must be thousands of spots...

After a while, all txt files were erased and I found in the curl-logs the confirmation of upload acceptance... again thousands. I was wondering however that all that was only a matter of minutes - the missing upload was very quick...

So, I was happy and stopped wsprdaemon, as I did not want to write too much data in the log-files with that high verbosity level.
So, I restarted with
./wsprdaemon.sh -a

Now what::
Hours later now, still there are no spots at all between 22h yesterday and 6h this morning - neither on wsprnet.org, nor on vk7jj's website...

It would be great to understand what really happened with the uploaded spots from partly today and partly from yesterday (based on utc time)

Will the missing spots ever appear ?
Why I got a confirmation of acceptance for thousands of spots in the curl-file, when these spots never appear ?
What did I wrong, that still no missing spot is delivered and how should I proceed next time to prevent data loss.

Or do just need to wait longer for the data to appear (may be one day or so ?!)
I am confused...hi

May be Rob can explain in the next zoom-meeting, how the upload of old spots really works - either because of Internet connection problems or even after portable kiwi operation in the field with later upload from home (Glenn's application ?!)

regards,
Ulli, ON5KQ


Re: What happens with old spots not yet uploaded (probably because of Internet failure) but stored in txt files...

Rob Robinett
 

Yes, I think the WD upload service only looks for spot files in receivers which are currently scheduled to be running. That does seem to be a potential source of late uploaded spots, although spots are never flushed until they have been successfully uploaded.   I have added working on that to the v3.0 TODO list.


I don’t know how wsprnet handles such spots, although Glenn has reported success with uploads delayed by hours or a day.  wsprnet assigns a unique 64 bit number to each spot it receives, and in cloning the wsprnet DB I validate that there are no gaps in the spot number sequence.

On Mon, Jun 14, 2021 at 8:17 AM ON5KQ <ON5KQ@...> wrote:
Dear,
During last night I probably had an Internet connection failuer, so from 20h utc yesterday until 4h utc in the morning, there was nothing uploaded.
The wsprdaemon script created a lot of txt files instead (containing the decoded spots during that time). In the meantime the wsprdaemon.conf file switched from nighttime to daylight schedule and a little later during the new daylight schedule the Internet came back.

Because of the new daylight schedule running, the wsprdaemon script didn't realize , that from the nighttime schedule (not active anymore) there were still a lot of ,txt files containing the spots to be uploaded. 
If I remember correctly all the .txt files with the nighttime spots were in this directory
/home/wsprdaemon/uploads.d/wsprnet.d/spots.d/ ....   and channel by channel the txt files were written for every 2min of transmission.

I was wondering, why the waiting spots were not uploaded immediately as the Internet came back in the morning...

To find out,  I restarted with "./wsprdaemon.sh -vvva"  to force high verbosity to check the various log files.
I found that the script searched for txt files to be uploaded, but not in the nighttime folder, but the current job folder for the running daytime schedule - so it would not immediately find the hundreds of waiting txt files only after roughly another 12h, when the night schedule becomes active again.

However, I didn't want to wait that long so...
(I am not sure, if it was correct, what I did then....):
- to upload the waiting txt files immediately, I stopped wsprdaemon with
./wsprdaemon.sh -z
then changed wsprdaemon.conf in that way, that the nighttime schedule was resumed instead of starting the daytime schedule.
Started again with:
./wsprdaemon.sh -vvva

Now In the logs I could see, that immediately more than 300 txt files waiting for upload were found from the script
Quickly the logs also showed that after a while many many uploads were done - it must be thousands of spots...

After a while, all txt files were erased and I found in the curl-logs the confirmation of upload acceptance... again thousands. I was wondering however that all that was only a matter of minutes - the missing upload was very quick...

So, I was happy and stopped wsprdaemon, as I did not want to write too much data in the log-files with that high verbosity level.
So, I restarted with
./wsprdaemon.sh -a

Now what::
Hours later now, still there are no spots at all between 22h yesterday and 6h this morning - neither on wsprnet.org, nor on vk7jj's website...

It would be great to understand what really happened with the uploaded spots from partly today and partly from yesterday (based on utc time)

Will the missing spots ever appear ?
Why I got a confirmation of acceptance for thousands of spots in the curl-file, when these spots never appear ?
What did I wrong, that still no missing spot is delivered and how should I proceed next time to prevent data loss.

Or do just need to wait longer for the data to appear (may be one day or so ?!)
I am confused...hi

May be Rob can explain in the next zoom-meeting, how the upload of old spots really works - either because of Internet connection problems or even after portable kiwi operation in the field with later upload from home (Glenn's application ?!)

regards,
Ulli, ON5KQ


What happens with old spots not yet uploaded (probably because of Internet failure) but stored in txt files...

ON5KQ
 

Dear,
During last night I probably had an Internet connection failuer, so from 20h utc yesterday until 4h utc in the morning, there was nothing uploaded.
The wsprdaemon script created a lot of txt files instead (containing the decoded spots during that time). In the meantime the wsprdaemon.conf file switched from nighttime to daylight schedule and a little later during the new daylight schedule the Internet came back.

Because of the new daylight schedule running, the wsprdaemon script didn't realize , that from the nighttime schedule (not active anymore) there were still a lot of ,txt files containing the spots to be uploaded. 
If I remember correctly all the .txt files with the nighttime spots were in this directory
/home/wsprdaemon/uploads.d/wsprnet.d/spots.d/ ....   and channel by channel the txt files were written for every 2min of transmission.

I was wondering, why the waiting spots were not uploaded immediately as the Internet came back in the morning...

To find out,  I restarted with "./wsprdaemon.sh -vvva"  to force high verbosity to check the various log files.
I found that the script searched for txt files to be uploaded, but not in the nighttime folder, but the current job folder for the running daytime schedule - so it would not immediately find the hundreds of waiting txt files only after roughly another 12h, when the night schedule becomes active again.

However, I didn't want to wait that long so...
(I am not sure, if it was correct, what I did then....):
- to upload the waiting txt files immediately, I stopped wsprdaemon with
./wsprdaemon.sh -z
then changed wsprdaemon.conf in that way, that the nighttime schedule was resumed instead of starting the daytime schedule.
Started again with:
./wsprdaemon.sh -vvva

Now In the logs I could see, that immediately more than 300 txt files waiting for upload were found from the script
Quickly the logs also showed that after a while many many uploads were done - it must be thousands of spots...

After a while, all txt files were erased and I found in the curl-logs the confirmation of upload acceptance... again thousands. I was wondering however that all that was only a matter of minutes - the missing upload was very quick...

So, I was happy and stopped wsprdaemon, as I did not want to write too much data in the log-files with that high verbosity level.
So, I restarted with
./wsprdaemon.sh -a

Now what::
Hours later now, still there are no spots at all between 22h yesterday and 6h this morning - neither on wsprnet.org, nor on vk7jj's website...

It would be great to understand what really happened with the uploaded spots from partly today and partly from yesterday (based on utc time)

Will the missing spots ever appear ?
Why I got a confirmation of acceptance for thousands of spots in the curl-file, when these spots never appear ?
What did I wrong, that still no missing spot is delivered and how should I proceed next time to prevent data loss.

Or do just need to wait longer for the data to appear (may be one day or so ?!)
I am confused...hi

May be Rob can explain in the next zoom-meeting, how the upload of old spots really works - either because of Internet connection problems or even after portable kiwi operation in the field with later upload from home (Glenn's application ?!)

regards,
Ulli, ON5KQ


Re: first time more than 3000spots/hour on all bands...

ON5KQ
 

I mean the current one, which wsprdaemon is using. However I remember the last update of wsprd decoder engine, it was said by the developers, that it should be more efficient in busy bands. Also the summer QRN is a real stress test for the decoder. The developers said, that also in summer qrn their latest decoder (which we have now for at least 6 month or so) should work better....
So nothing to do...hi

Yesterday was just a good test case to verify the robustness of the decoder - I think we must be happy to have such good software.

Today I received my first UK-station on 4m (70Mhz) over a distance of a little more than 450km - no special propagation just groundwave...
The last couple of days I am testing how to use my terminated rhombic antenna on 6m and above. It is pointing to the UK and it turns out to be very broadband. I use it from 160m to 70Mhz for reception with good results.
VSWR as measured with my DG8SAQ VNA:  (30kHz to 60Mhz trace)


Not that bad...

Ulli, ON5KQ


Re: first time more than 3000spots/hour on all bands...

WA2TP - Tom
 

Ulli,

Which new decoder are you referring to?



On Jun 11, 2021, at 2:40 AM, ON5KQ <ON5KQ@...> wrote:

Jim,
on 20m (and the higher bands) usually I hear the locals (100km distance) best, when both antennas are in the same direction (back-scatter)
So in the evening in 20m CW or SSB if stations put their beams to Northamerica, I would hear them best with the beam to Northamerica too. Although the many Germans heard like this are all in the back of the antenna...

So, I think the usually not very directive Wspr-wire antennas (both TX and RX, compared to a Yagi beam antenna) will work in the same way: Backscatter signals are usually stronger than direct ground wave propagation.

Ulli


Re: first time more than 3000spots/hour on all bands...

ON5KQ
 

Jim,
on 20m (and the higher bands) usually I hear the locals (100km distance) best, when both antennas are in the same direction (back-scatter)
So in the evening in 20m CW or SSB if stations put their beams to Northamerica, I would hear them best with the beam to Northamerica too. Although the many Germans heard like this are all in the back of the antenna...

So, I think the usually not very directive Wspr-wire antennas (both TX and RX, compared to a Yagi beam antenna) will work in the same way: Backscatter signals are usually stronger than direct ground wave propagation.

Ulli


Re: first time more than 3000spots/hour on all bands...

ON5KQ
 

yes, you can filter.... Phil's website (VK7JJ) offers the possibility.
Obviously, due to the short skip "QRM" the reception capability for the much weaker DX stations is limited. When there is so much short skip sporadic E reception often F2 reflections (being the normal propagation on shortwave) is not possible or attenuated due to absorbtion.
Yesterday the 20m band opened to North-America after the short skip signals dropped in signal strength.

I was surprised, how well the latest decoder really can cope with extremely busy bands when such propagation overloads the available wspr-frequency space with transmitting stations. I must say it is impressive, that the decoder can reliably pick more than 40stations in a 2min wspr circle from just 200Hz wide band...
How far this will develop in the coming years, when we probably will see a fully open 10m band even during the night and at the same time have good condx on the low bands ?
That is the moment, where I need a new PC for decoding...hi. The current solution with a dual CPU XEON workstation might be not enough..

The sporadic E max usable frequency yesterday was 47Mhz at about 21h (at the time of my first post above) according to the Ionosonde here in Belgium. Still not enough for opening on 6m although the regular stations were heard via tropo, I guess.

Ulli


Re: KFS reception quality - IMD and other (internal?) noise sources...

Rob Robinett
 

I have just returned from 5 hours at KFS and have time for only a brief report:

1) I removed the Nooelec AMB BF and 6/9 dB pads which were between the Qbit LNA outputs and the Kiwi RF inputs.  
    There are 2 Mhz HPF out at the antennas and I have muted the whole of the AM band, so no user can tune there on a Kiwi.  
    So the Omni Kiwis have additional 6 dB gain and the others an additional 9 dB gain.  I will monitor WD's overload log to verify those changes don't result in significant overload events.
2) I confirmed that the NW feed from the primary multicoupler is suffering from severe AM IMD in the 2-4 Mhz region, so this IMB is generated in that multicoupler or more likely by the LNA out at the antenna
    Omni A and B also show that IMD but to much lesser extent.  Fixing these will require help from ARINC
3) Thanks to Glenn's AA and the tinySA, I tracked down the source of the every 40 Khz switcher RFI:  it is a vertically polarized signal generated at the cell phone equipment shed at the base of the cell phone tower shared with the NW antenna.  Again, ARINC is going to have to get  that fixed if they care about it.  That same RFI can be heard on the Omni which is the other antenna closest to the cell phone shed (about 100M away).  The SE and SW antennas are about 200+M away from that shed and so that RFI is barely noticable on those antennas.
4)  I see other switcher RFIs, so I'm sure there are many other bugs to squash, but the signals we see on the Kiwis are pretty much what the portable Kiwi sees when connected to the primary multicouplers.  So all indications are the problems are outside the building. 
4) Glen''s AA + the portable Kiwi showed a very clean spectrum when I got 300M away from the cell shed and main building.  There is very good wifi coverage out in the fields, so I think deploying a solar powered AA + Kiwi as far as possible (e.g 400M)  from the cell shed would result in a very clean full spectrum.

I now understand the location of all the antennas and can see why the NW and Omni will always be impaired by the cell shed.

Rob


On Thu, Jun 10, 2021 at 12:33 PM ON5KQ <ON5KQ@...> wrote:
In the meantime, I must correct my report from above. There are indeed also during the night severe man-made noise sources, which I believe are produced somewhere in the signal distribution system.,,,,more detailed reports I have sent to Rob, to help to find a solution and support kfs...



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896


Re: WSPRDaemon creating empty spot files and nothing for WSPRNet

Rob Robinett
 

Duncan gave me ssh access to his Pi and I was able to see that his RaspSDR wasn't sending audio through the kiwirecorder session, nor was autowspr able to decode on the RaspSDR.  Duncan later reported that an update to his RaspSDR SW fixed those problems and WD was running fine.  However I don't know any more detail about the RaspSDR SW change.

On Thu, Jun 10, 2021 at 1:33 PM Jim Lill <jim@...> wrote:

does wsprd decoder ever run?

On 6/9/21 7:45 PM, Duncan GM5JET wrote:
Hi Rob,

There is only the entry in the log file for starting the pid and then nothing else.

I have watched the updates and I get the message that states that the files contained no spots and that the files should be flushed.  I'm rather stumped!

73
Duncan



--
Rob Robinett
AI6VN
mobile: +1 650 218 8896

681 - 700 of 981