Date
1 - 11 of 11
New install on Pi4 question
|
Very new to Linux & Pi, so being very cautious...but also not afraid to ask the very dumb questions that follow below. When I initiated a new installation of Wsprdaemon, it displayed a warning message about the /tmp/wsprdaemon directory not being configured as a RAM drive, so that every 2 minutes the WSPR write cycle will eventually wear out the microSD card in the Pi. I decided to pause the install until I get some input. So my questions are...
1) If I proceed as is, what might be a typical lifetime for a 32GB Samsung microSD card? In other words, is the warning a real concern for a new user, or more of a standard disclaimer ("I TOLD you this might wear out a solid state drive!"). 2) Is there a VERY simple set of commands (e.g. a short narrative entitled "300 MB RAM Drive Set Up for Dummies") that I can use to create the RAM drive for wsprdaemon to use? 3) If I proceed without setting up a RAM drive, is that something I can do after the wsprdaemon installation, or do I need to I halt things and do that first? Thanks in advance for any advice. I WAS able to get the new Pi4 set up with a solid wifi connection, running headless with SSH & VNC access enabled, so looking forward to giving wspr daemon a try. |
|
|
|
Jim Lill
There is also an access speed issue that the ram disk helps. this line needs to be added to the end of your /etc/fstab file tmpfs /tmp/wsprdaemon tmpfs defaults,noatime,nosuid,size=300m
0 0 you may not need 300m, I use that as I have 26 channels running
from 2 kiwi. After adding that reboot and see that you that ram
disk and then I'd simply reinstall wd On 10/14/21 4:10 PM, Bruce KX4AZ wrote:
Very new to Linux & Pi, so being very cautious...but also not afraid to ask the very dumb questions that follow below. When I initiated a new installation of Wsprdaemon, it displayed a warning message about the /tmp/wsprdaemon directory not being configured as a RAM drive, so that every 2 minutes the WSPR write cycle will eventually wear out the microSD card in the Pi. I decided to pause the install until I get some input. So my questions are... |
|
|
|
Thank you, I located the fstab file in the etc directory and will halt the wsprdaemon and add that line.....I am curious about the "0 0" after the size=300m term - what function does it serve?
|
|
|
|
Jim Lill
see man fstab On 10/14/21 5:35 PM, Bruce KX4AZ wrote:
Thank you, I located the fstab file in the etc directory and will halt the wsprdaemon and add that line.....I am curious about the "0 0" after the size=300m term - what function does it serve? |
|
|
|
When I went back and re-read the original installation message I realized it was simply asking me for permission to create a RAM drive, so I answered YES and proceeded from there. After editing the example wsprdaemon.conf file for my specific setup, I now have it running and can see that it is connected to the KiwiSDR. It's not uploading any spots so far, and when I check the status, each of the five receivers says "Got PID xxx from file, but it is not running". I am assuming I made a simple mistake somewhere along the line.
|
|
|
|
Jim Lill
I'm not sure it likes _ in the RX name or if the various people
who track spots do On 10/14/21 9:11 PM, Bruce KX4AZ wrote:
When I went back and re-read the original installation message I realized it was simply asking me for permission to create a RAM drive, so I answered YES and proceeded from there. After editing the example wsprdaemon.conf file for my specific setup, I now have it running and can see that it is connected to the KiwiSDR. It's not uploading any spots so far, and when I check the status, each of the five receivers says "Got PID xxx from file, but it is not running". I am assuming I made a simple mistake somewhere along the line. |
|
|
|
Thanks for the suggestion, I removed the _1 in the receiver name used in the conf file, rebooted and restarted wsprdaemon. Still not uploading any spots, though the status shows a longer list, with _1 in the receiver name and a "never ran" error (snapshot attached). Will continue studying the documentation from the web site, has to be something real basic that I am doing wrong.
|
|
|
|
Also, these are the current contents in the wsprdaemon.log file:
Fri 15 Oct 2021 09:40:49 AM UTC: watchdog_daemon() starting as pid 2904
Fri 15 Oct 2021 09:40:49 AM UTC: WARNING: spawn_upload_to_wsprnet_daemon() found a stale uploading.pid file with pid 1438. Deleting file /home/pi/wsprdaemon/uploads.d/wsprnet.d/spots.d/uploads.pid
Fri 15 Oct 2021 09:40:49 AM UTC: WARNING: spawn_ftp_upload_to_wsprdaemon_daemon() found a stale file '/home/pi/wsprdaemon/uploads.d/wsprdaemon.d/uploads.pid' with pid 1452, so deleting it
sed: -e expression #1, char 16: unknown option to `s'
sed: -e expression #1, char 16: unknown option to `s'
sed: -e expression #1, char 16: unknown option to `s'
sed: -e expression #1, char 16: unknown option to `s'
sed: -e expression #1, char 16: unknown option to `s'
sed: -e expression #1, char 17: unknown option to `s'
./wsprdaemon.sh: line 5375: /tmp/wsprdaemon/kiwi_gps_status/KX4AZ/T_last_gps_fixes.log: No such file or directory
cat: /tmp/wsprdaemon/kiwi_gps_status/KX4AZ/T_last_gps_fixes.log: No such file or directory
date: /tmp/wsprdaemon/kiwi_gps_status/KX4AZ/T_last_gps_fixes.log: No such file or directory
./wsprdaemon.sh: line 5381: 1634290885 - : syntax error: operand expected (error token is "- ")
|
|
|
|
I think the problem may be the names. There is no need to use a call as the receiver name. It gets the call from the config file. Your receiver names should be like Kiwi_1, Kiwi_2, etc. if is is an audio channel it must be Audio_0 or Audio_1?
toggle quoted message
Show quoted text
In the schedule you need to use MERGED_x for the list of receivers even if you are scheduling only only one receiver. My names are BE, DI, VE for the receivers and the schedule list looks like this: “MERGED_RX_1 BE KD2OM FN12GX password” “MERGED_RX_2 BE,DI,VE,AUDIO_0 KD2OM FN12GX password” Then the schedule: (“01:00 MERGED_RX_1,2200 MERGED_RX_2,20” ) Steve KD2OM On Oct 15, 2021, at 06:15, Bruce KX4AZ <bruce@...> wrote:
|
|
|
|
On Fri, Oct 15, 2021 at 08:46 AM, KD2OM wrote:
I think the problem may be the names. There is no need to use a call as the receiver name.You are correct! Right after my last post I went back to the original example conf file example (from the web site) and changed the receiver name to remove the '/T' suffix from the call sign, while leaving it present for the uploaded spots - important for me to distinguish different locations I use. After a restart the spots began uploading correctly. I also did some more editing of the example conf file to change all of the "no" values to "yes" for the noise related reporting. Hopefully that is working correctly too - I have a lot ore learning to do to figure out how to verify that. |
|
|
|
Rob Robinett
In WD 3.0 I will add checks of the receiver names to the config file validation function. Thanks for the reports On Fri, Oct 15, 2021 at 6:49 AM Bruce KX4AZ <bruce@...> wrote: On Fri, Oct 15, 2021 at 08:46 AM, KD2OM wrote: --
|
|
|
