Date   

logs1 wsprdaemon_spots table - service interruption 11-12 August 2021 - new table name

Gwyn Griffiths
 

I will be carrying out maintenance and a change to the wsprdaemon_spots table on logs1.wsprdaemon.org today.
The table may stop updating while the work is underway and you are advised to use logs2.wsprdaemon.org.

I will post a note after the work is complete, and as for the noise table, there will be a new table wsprdaemon_spots_s with an autosequence number.

thank you
Gwyn G3ZIL


Re: logs1 wsprdaemon_noise table - service interruption 10 August 2021 - new table name

Gwyn Griffiths
 

The work on the noise table on logs1 is now complete.

The work was to add an automatically generated incrementing sequence number to each noise line uploaded.
The noise table on logs1 that is now being updated is wsprdaemon_noise_s  the 's' added to indicate 'with sequence number'.
If you access the noise table on this server please be aware of this change. The noise table is still there with data up to 1104 UTC 10 August 2021.

Any issues, please let me know. I will be repeating this with wsprdaemon_spots on logs1 and will post a message at the time.

thank you
Gwyn G3ZIL


logs1 wsprdaemon_noise table - service interruption 10 August 2021

Gwyn Griffiths
 

Please be aware that I am testing out some changes to the wsprdaemon_noise table on logs1.wsprdaemon.org today.

The wsprdaemon_noise table will stop updating at times and there will be gaps in the data. 

If this affects you, please access wsprdaemon_noise on the server logs2.wsprdaemon.org that should be unaffected.

thank you
Gwyn G3ZIL


Re: WD 2.10k has been checked in. Please upgrade to it

Rolf Ekstrand
 

Thank you Rob

Completed here too, no issues

Rolf  K9DZT


KiwiSDR forum back (read-only)

Glenn Elmore
 

I just noticed that JKS has made the forum available again, though read only for now.

http://forum.kiwisdr.com/index.php?p=/categories/kiwisdr-discussion


Re: WD 2.10k has been checked in. Please upgrade to it

WA2TP - Tom
 

Thank you Rob
Completed on my end, no issues.

Tom


Re: WD 2.10k has been checked in. Please upgrade to it

Rob Robinett
 

Your WD directories were not created with git
Save your conf files snd do a clean installation using git

On Mon, Aug 9, 2021 at 1:14 PM Glenn Elmore <n6gn@...> wrote:

fatal: not a git repository (or any of the parent directories): .git

On two systems. Was this because I downloaded via wpsrdaemon site?  Where/when does the repository get set

On 8/9/21 12:35 PM, Rob Robinett wrote:
This version adds WD's SW version number to the spots it uploads to wsprnet.org.  That site doesn't display those version numbers, but wspr.rocks will print that version number field.
Also, version 2.10j added use of WSJT-x 2.3.0 binaries which may be downloaded when your first run this new WD.

So it is a little more important than usual that you upgrade by:

1) cd ~/wsprdaemon
2) stop wsprdaemon with:  ./wsprdaemon.sh -z
3) then get the 2.10k code with:  git pull
4) then start wsprdaemon with: ./wsprdaemon.sh -a

If done within a few seconds, that proceed should cause you to miss no more than one or two wspr cycles.

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


Re: WD 2.10k has been checked in. Please upgrade to it

Jim Lill
 

Worked fine here

On 8/9/21 4:13 PM, Glenn Elmore wrote:

fatal: not a git repository (or any of the parent directories): .git

On two systems. Was this because I downloaded via wpsrdaemon site?  Where/when does the repository get set

On 8/9/21 12:35 PM, Rob Robinett wrote:
This version adds WD's SW version number to the spots it uploads to wsprnet.org.  That site doesn't display those version numbers, but wspr.rocks will print that version number field.
Also, version 2.10j added use of WSJT-x 2.3.0 binaries which may be downloaded when your first run this new WD.

So it is a little more important than usual that you upgrade by:

1) cd ~/wsprdaemon
2) stop wsprdaemon with:  ./wsprdaemon.sh -z
3) then get the 2.10k code with:  git pull
4) then start wsprdaemon with: ./wsprdaemon.sh -a

If done within a few seconds, that proceed should cause you to miss no more than one or two wspr cycles.


Re: WD 2.10k has been checked in. Please upgrade to it

Glenn Elmore
 

fatal: not a git repository (or any of the parent directories): .git

On two systems. Was this because I downloaded via wpsrdaemon site?  Where/when does the repository get set

On 8/9/21 12:35 PM, Rob Robinett wrote:
This version adds WD's SW version number to the spots it uploads to wsprnet.org.  That site doesn't display those version numbers, but wspr.rocks will print that version number field.
Also, version 2.10j added use of WSJT-x 2.3.0 binaries which may be downloaded when your first run this new WD.

So it is a little more important than usual that you upgrade by:

1) cd ~/wsprdaemon
2) stop wsprdaemon with:  ./wsprdaemon.sh -z
3) then get the 2.10k code with:  git pull
4) then start wsprdaemon with: ./wsprdaemon.sh -a

If done within a few seconds, that proceed should cause you to miss no more than one or two wspr cycles.


Re: WD 2.10k has been checked in. Please upgrade to it

KD2OM
 

Thank you Rob,
Just did it, went fine.

Steve


On Aug 9, 2021, at 14:35, Rob Robinett <rob@...> wrote:

This version adds WD's SW version number to the spots it uploads to wsprnet.org.  That site doesn't display those version numbers, but wspr.rocks will print that version number field.
Also, version 2.10j added use of WSJT-x 2.3.0 binaries which may be downloaded when your first run this new WD.

So it is a little more important than usual that you upgrade by:

1) cd ~/wsprdaemon
2) stop wsprdaemon with:  ./wsprdaemon.sh -z
3) then get the 2.10k code with:  git pull
4) then start wsprdaemon with: ./wsprdaemon.sh -a

If done within a few seconds, that proceed should cause you to miss no more than one or two wspr cycles.


WD 2.10k has been checked in. Please upgrade to it

Rob Robinett
 

This version adds WD's SW version number to the spots it uploads to wsprnet.org.  That site doesn't display those version numbers, but wspr.rocks will print that version number field.
Also, version 2.10j added use of WSJT-x 2.3.0 binaries which may be downloaded when your first run this new WD.

So it is a little more important than usual that you upgrade by:

1) cd ~/wsprdaemon
2) stop wsprdaemon with:  ./wsprdaemon.sh -z
3) then get the 2.10k code with:  git pull
4) then start wsprdaemon with: ./wsprdaemon.sh -a

If done within a few seconds, that proceed should cause you to miss no more than one or two wspr cycles.


More noise graphs now being displayed

Rob Robinett
 

Thanks to an observation by Clint KA7OEI, I found and fixed a problem in the WD server which caused noise graph files to not be displayed.  

The WD server wakes up every 5 seconds, gets a list of .png files and then validates them.  But if the png was in the process of being uploaded it would be flagged as invalid and immediately deleted.  
So sites with large png files, slow upload speeds, and/or those which are configured to limit upload bandwidth might never finish the png upload in the 5 second window and thus their noise graphs would never be displayed.

I have modified the server to flush pngs files only if they are older than 120 seconds which fixed uploads from KA7OEI-1 and perhaps those of several other WD client sites.

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


DigiSkimmer

G7ELK
 
Edited

Has anyone looked at DigiSkimmer?

https://github.com/lazywalker/DigiSkimmer

Seems to be using a similar approach to Wsprdaemon to deliver the basic WSPR spotting functionality (none of the clever noise stuff)  as well as acting as  an FT8 skimmer.  Clearly not as fully developed as wsprdaemon, but is there anything of interest there?

Also (and slightly off topic I realize) spent much of Sunday playing with OpenWebRX using a RSP1a and PI4.  As many will be aware, the Kiwi inherited much from an earlier incarnation of OpenWebRX, however what has been done recently is interesting - it includes WSPR decoding using WSJT-X and also a similar FT8 skimmer capability.  Seems to work pretty well...

Regards,

                Rob


Re: The Pi in the FiredogSDR can run 8 channel WD

Rob Robinett
 

As I understand it there is at least one RF problem because they have two RF inputs, one with a 30 MHz LPF and a second with a 60 Mhz LPF and the filter outputs are both always connected together at the input of the RF amplifier.  That results in severe interaction between the filters and a resulting dip in frequency response around 10 Mhz.  The Kiwi's RF input amplifier design is already a weakness and this double filter amplifies the problems.
Since the HW schematic is not open source and early owners report 'alpha-looking' hacks on the difficult to modify RF section, it seems the FD is really at an alpha HW development stage.
I will be testing an unmoidfied FD against a Kiwi with both fed the same RF, so in a week or two I may be able to quantify the performance difference between them.  
Perhaps the HW problems I describe won't significantly affect WD sensitivity.

On Sat, Jul 24, 2021 at 2:14 PM Rob Robinett <rob@...> wrote:
On the Kiwi I have been measuring the voltage on the USB-A port of the BBG and then adjusting the PSU to get 5V on that unloaded USB-A port. I have found that the the resulting PSU output is typically 5.5V under that condition which is when the Kiwi is running.  I recall that there is DC loss in the PSU to Kiwi cable, and then something like .25V in the DC input filter on the Kiwi board.  The cable losses were even worse when I used cheap 22ga DC pigtails.
The BBG is speced to run from 4.4 to 5.6V and is protected against overvoltage to I think 20V.  I have accidentally connected the Kiwi to a 12VDC PSU without damaging it.
So adjust your PSU while connected to a running Kiwi and measure someplace on the Kiwi, not at the PSU.

On Sat, Jul 24, 2021 at 1:06 PM VE3VXO <ve3vxo@...> wrote:

That looks pretty straight forward and yeah I already edited my local copy of your example .config file  so I wouldn't forget to set localhost:8073.  Well I guess now it's just hurry up and wait time.... I guess in the mean time I can wire up a regulator.  Do you know if the FD will like a little generous 5V like the Kiwi does or should I go for 5V bang on?

Thanks for your advice.

Joe

---------- Original Message ----------
From: Rob Robinett <rob@...>
Date: July 24, 2021 at 3:27 PM

Just log on to the Flydog's Pi as user 'flydog' password 'flydog-sdr'
execute 'sudo apt-get install git'
then follow the installation instructions on my github page.
there are many, many packages installed when you first run WD, and you may need to re-run once or twice to get the WD installation to complete.
in your conf file specify the IP:PORT of your kiwi as 'localhost:8073'


On Sat, Jul 24, 2021 at 9:51 AM VE3VXO < ve3vxo@...> wrote:
I suspected that but wasn't sure. I don't expect to see my FD arrive till September probably but in the mean time if you have any chance to write down the steps you used it will help me a lot and would be much appreciated!

Best regards...joe

 

 



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


 



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


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


Re: The Pi in the FiredogSDR can run 8 channel WD

Rob Robinett
 

On the Kiwi I have been measuring the voltage on the USB-A port of the BBG and then adjusting the PSU to get 5V on that unloaded USB-A port. I have found that the the resulting PSU output is typically 5.5V under that condition which is when the Kiwi is running.  I recall that there is DC loss in the PSU to Kiwi cable, and then something like .25V in the DC input filter on the Kiwi board.  The cable losses were even worse when I used cheap 22ga DC pigtails.
The BBG is speced to run from 4.4 to 5.6V and is protected against overvoltage to I think 20V.  I have accidentally connected the Kiwi to a 12VDC PSU without damaging it.
So adjust your PSU while connected to a running Kiwi and measure someplace on the Kiwi, not at the PSU.

On Sat, Jul 24, 2021 at 1:06 PM VE3VXO <ve3vxo@...> wrote:

That looks pretty straight forward and yeah I already edited my local copy of your example .config file  so I wouldn't forget to set localhost:8073.  Well I guess now it's just hurry up and wait time.... I guess in the mean time I can wire up a regulator.  Do you know if the FD will like a little generous 5V like the Kiwi does or should I go for 5V bang on?

Thanks for your advice.

Joe

---------- Original Message ----------
From: Rob Robinett <rob@...>
Date: July 24, 2021 at 3:27 PM

Just log on to the Flydog's Pi as user 'flydog' password 'flydog-sdr'
execute 'sudo apt-get install git'
then follow the installation instructions on my github page.
there are many, many packages installed when you first run WD, and you may need to re-run once or twice to get the WD installation to complete.
in your conf file specify the IP:PORT of your kiwi as 'localhost:8073'


On Sat, Jul 24, 2021 at 9:51 AM VE3VXO < ve3vxo@...> wrote:
I suspected that but wasn't sure. I don't expect to see my FD arrive till September probably but in the mean time if you have any chance to write down the steps you used it will help me a lot and would be much appreciated!

Best regards...joe

 

 



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


 



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


Re: The Pi in the FiredogSDR can run 8 channel WD

Rolf Ekstrand
 

Rob

Just curious about the "serious Rf problem"  on the FD cape.  I took a peek on the website and most certainly it looks to me that their enclosure is not optimal when it comes to cooling the raspi  cpu.  71 deg is pretty close to the point  where the raspi will  start throttling down the CPU.  I am running one of my rpi 4 at 2Ghz at 50 - 60 deg, but with lots of cooling and a big heat sink.  On the other hand my rpi 400 is running at 2.2 Ghz  as is and it seldom gets over 60 deg.  

One solution is to put an extension  spacer between the FD and the raspi so you could fit in a larger heat sink and design the enclosure with the fan mounted on the side so that you put he majority of the airflow between the cape and raspi.  

Well, it's an easy fix, but first what are the RF problems?

Rolf


Re: The Pi in the FiredogSDR can run 8 channel WD

VE7VXO
 

That looks pretty straight forward and yeah I already edited my local copy of your example .config file  so I wouldn't forget to set localhost:8073.  Well I guess now it's just hurry up and wait time.... I guess in the mean time I can wire up a regulator.  Do you know if the FD will like a little generous 5V like the Kiwi does or should I go for 5V bang on?

Thanks for your advice.

Joe

---------- Original Message ----------
From: Rob Robinett <rob@...>
Date: July 24, 2021 at 3:27 PM

Just log on to the Flydog's Pi as user 'flydog' password 'flydog-sdr'
execute 'sudo apt-get install git'
then follow the installation instructions on my github page.
there are many, many packages installed when you first run WD, and you may need to re-run once or twice to get the WD installation to complete.
in your conf file specify the IP:PORT of your kiwi as 'localhost:8073'


On Sat, Jul 24, 2021 at 9:51 AM VE3VXO < ve3vxo@...> wrote:
I suspected that but wasn't sure. I don't expect to see my FD arrive till September probably but in the mean time if you have any chance to write down the steps you used it will help me a lot and would be much appreciated!

Best regards...joe

 

 



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


 


Re: The Pi in the FiredogSDR can run 8 channel WD

Rob Robinett
 

Just log on to the Flydog's Pi as user 'flydog' password 'flydog-sdr'
execute 'sudo apt-get install git'
then follow the installation instructions on my github page.
there are many, many packages installed when you first run WD, and you may need to re-run once or twice to get the WD installation to complete.
in your conf file specify the IP:PORT of your kiwi as 'localhost:8073'


On Sat, Jul 24, 2021 at 9:51 AM VE3VXO <ve3vxo@...> wrote:
I suspected that but wasn't sure.  I don't expect to see my FD arrive till September probably but in the mean time if you have any chance to write down the steps you used it will help me a lot and would be much appreciated!

Best regards...joe



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


Re: Kiwi front end protection.

Rob Robinett
 

The WebSDR system seems to best address the latency issue of the Kiwi and many other SDRs and thus more popular with ham operators.

You can compare the KFS WebSDR at http://kfswebsdr.wsprdaemon.org:8901/ 

There is more information about those KFS systems at http://kfs.wsprdaemon.org:81/

The KFS antennas suffer from some switching power supply RFI created by the cell site equipment co-located on one of the HF antenna towers, but still KFS is the premier listening site on the West Coast.


On Sat, Jul 24, 2021 at 10:22 AM Glenn Elmore <n6gn@...> wrote:

I think it wasn't a Kiwi at the time, just two collocated antennas with the receiver running continuously.  The rx may have been an analog radio or an Apache/Anan dual-ADC board, I can't remember any longer, just that I could manage with a receiver running continuously while I was transmitting. It's possible that it was the Anan board with some delay.

It's possible to help a Kiwi somewhat by turning down the abuf but that doesn't solve the problem, it only helps somewhat. I often run with abuf=0.25.  Full QSK with fast CW, or even listening to one's own signal isn't very useful with any SDR I've tried.


On 7/24/21 9:50 AM, VE3VXO wrote:
On Sat, Jul 24, 2021 at 11:14 AM, Glenn Elmore wrote:
It was rather fun to be 'full QSK' on SSB or CW.
Glenn, how did you deal with the processing delay?  Here it is almost a full second through the Kiwi.  I can't handle that, my fist stops in an instant when my delayed CW hits my ears.  Turning volume knobs up and down on two sets of speakers isn't practical and is hardly QSK! I thought of using some sort of PTT/mute on the Kiwi audio but got stalled on that project.

On Kiwi protection, I added an optocoupler output to the green terminal block which is tied in with my local PTT.  The on resistance of the opto is ~5 ohms so it only gives a little extra attenuation rather than shorting the antenna directly to ground. It has handled local 500w transmitter no problem.

Joe



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


Re: Kiwi front end protection.

Glenn Elmore
 

I think it wasn't a Kiwi at the time, just two collocated antennas with the receiver running continuously.  The rx may have been an analog radio or an Apache/Anan dual-ADC board, I can't remember any longer, just that I could manage with a receiver running continuously while I was transmitting. It's possible that it was the Anan board with some delay.

It's possible to help a Kiwi somewhat by turning down the abuf but that doesn't solve the problem, it only helps somewhat. I often run with abuf=0.25.  Full QSK with fast CW, or even listening to one's own signal isn't very useful with any SDR I've tried.


On 7/24/21 9:50 AM, VE3VXO wrote:
On Sat, Jul 24, 2021 at 11:14 AM, Glenn Elmore wrote:
It was rather fun to be 'full QSK' on SSB or CW.
Glenn, how did you deal with the processing delay?  Here it is almost a full second through the Kiwi.  I can't handle that, my fist stops in an instant when my delayed CW hits my ears.  Turning volume knobs up and down on two sets of speakers isn't practical and is hardly QSK! I thought of using some sort of PTT/mute on the Kiwi audio but got stalled on that project.

On Kiwi protection, I added an optocoupler output to the green terminal block which is tied in with my local PTT.  The on resistance of the opto is ~5 ohms so it only gives a little extra attenuation rather than shorting the antenna directly to ground. It has handled local 500w transmitter no problem.

Joe

861 - 880 of 1259