Date   

Re: failed install libgfortran5

Rob Robinett
 

run 'find / -name wsprd' to find where wsjt-x puts it

On Sat, May 29, 2021 at 6:12 AM John via groups.io <n0ure=yahoo.com@groups.io> wrote:
Nope, did not work. wsjtx installed with no errors. I ran wsjtx and got two displays. The control display would not stretch to give a proper field display.
There is no wsprd file in the bin folder to copy? I will look for a wsprd on a x86 laptop as the only other copy I have is for aarch64 machine.



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


Re: failed install libgfortran5

John
 

Nope, did not work. wsjtx installed with no errors. I ran wsjtx and got two displays. The control display would not stretch to give a proper field display.
There is no wsprd file in the bin folder to copy? I will look for a wsprd on a x86 laptop as the only other copy I have is for aarch64 machine.


Re: failed install libgfortran5

Rob Robinett
 

I have no Ubuntu 16.x systems to test installation.
If you can successfully install WSJT-x and run it on that machine, you could try to copy /usr/local/bin/wsprd to ~/wsprdaemon/bin/.  

On Fri, May 28, 2021 at 7:39 PM jimcny2 <jimcny@...> wrote:

[Edited Message Follows]

sudo apt install wsjtx 
get more errors do
sudo apt-get --fix-broken install
try install again



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


Re: failed install libgfortran5

jimcny2
 
Edited

sudo apt install wsjtx 
get more errors do
sudo apt-get --fix-broken install
try install again


failed install libgfortran5

John
 

building wsprdaemon server on UBUNTU 16.04  x86 system. I am getting failed to install libgfortran5 when wd -V.
Ideas to fix?
John


Re: Transient missing spots events may require WD server CPU upgrade

Jim Lill
 

The NUC may not be enough...    I use a single Odroid XU4 to handle 26 channels worth of WD and haven't seen issues yet (but you look more carefully now)

On 5/25/21 5:02 PM, Edward Hammond wrote:
Okay. I guess it's time to suck it up and install Ubuntu on that old Intel NUC!

EH


On 5/25/21 4:10 PM, Rob Robinett wrote:
In WD V3.0 I will be adding support for FST4W 120/300/900/1800 and using those modes, especially the 900/1800, will surely require more CPU than any Pi can offer.

On Tue, May 25, 2021 at 1:06 PM Edward Hammond <manager@muskrat.farm> wrote:

    Sorry, a correction.  It was FT8 that was pushing my Pi to its limits
    then, not WSPR.  But I would think overclocking would similarly
    help in
    this situation.

    EH


    On 5/25/21 3:29 PM, Edward Hammond wrote:
    >
    > I noticed last year that my decode cycles were pushing the Pi's
    > limits.  Your mileage may vary, and it certainly will void any
    > warranty, but overclocking the Pi4 is also a possibility.
    >
    > I experimented with that option and, on my example at least, I
    could
    > dial in a ~12-14% clock speed boost stably (IIRC). This did
    shorten
    > the decoding cycle.
    >
    > Any higher clock rate, again on my particular Pi, and it started
    > behaving erratically.
    >
    > Edward
    >
    >
    >
    > On 5/25/21 12:37 PM, Rob Robinett wrote:
    >> This kind of problem has been reported by others in the
    Wednesday WD
    >> Zoom call and fixed by upgrading to a more powerful CPU than
    the ARM
    >> on the Pi4.  It appears that with the summer months and increasing
    >> sunspot cycle, the Pi CPUs can't keep up decoding the number of
    spots
    >> in the wav file captures.  However it is hard to observe those
    'out
    >> of CPU' events.
    >> Most of the top spotting sites have migrated from Pi4s to i86
    >> servers.  An inexpensive, low power and high performance option is
    >> the Lenovo M93P Tiny PC (don't get the larger model) with i5 CPU
    >> which can be purchased used or refurbished for $100 or less on
    ebay:
    >> https://tinyurl.com/emrjnw <https://tinyurl.com/emrjnw> The
    M93P consumes 12W peaking at 36W
    >> while decoding spots.
    >> WD requires very little RAM space, so a 2 or 4GB machine would be
    >> fine.  I bought mine without HD and added a SSD and installed
    Ubuntu
    >> 20.04 LTS. But since WD does very little disk  IO to the root file
    >> system, using a rotating HD might be a better choice for longer
    life.
    >>
    >
    >








--
Rob Robinett
AI6VN
rob@robinett.us <mailto:rob@robinett.us>
mobile: +1 650 218 8896





Re: Intl. WSPR Beacon Project - Grafana Dashboards

Roland
 
Edited

Hi Rob, glad you like the Project. Jost replied to your email. Still looking for participants from strategic locations like Japan, Scandinavia and Russia. Many countries/regions already on the candidate list like Alaska, Australia, Europe and South Africa.

73
Roland


Re: Intl. WSPR Beacon Project - Grafana Dashboards

Rob Robinett
 

Welcome Roland.  I am excited to hear about your project and could host one of your transmitters at my rural Maui site near where my friend Tom Worthington deployed and maintains the RBN site.


Intl. WSPR Beacon Project - Grafana Dashboards

Roland
 

We are kicking off a global WSPR Beacon Project https://github.com/HB9VQQ/WSPRBeacon with around 20-30 permanently installed Beacons around the globe with the same TX schedule and the same Beacon Hardware. Now the idea is to set up some sort of Grafana dashboard similar to this one https://grafana.gafner.net/d/vt3ILoxGz/international-cw-beacon-monitor-athb9vqq?orgId=1&from=now-24h&to=now Really looking for some help to migrate the CW Beacon Monitor to WSPR.

Came across wsprl.live website today and find it pretty amazing. great job, particularly liking the radiation pattern view, wow.

So if anybody is interested please reach out to me.

73
Roland
HB9VQQ


Re: Transient missing spots events may require WD server CPU upgrade

Edward Hammond
 

Okay.  I guess it's time to suck it up and install Ubuntu on that old Intel NUC!

EH

On 5/25/21 4:10 PM, Rob Robinett wrote:
In WD V3.0 I will be adding support for FST4W 120/300/900/1800 and using those modes, especially the 900/1800, will surely require more CPU than any Pi can offer.

On Tue, May 25, 2021 at 1:06 PM Edward Hammond <manager@muskrat.farm> wrote:

Sorry, a correction.  It was FT8 that was pushing my Pi to its limits
then, not WSPR.  But I would think overclocking would similarly
help in
this situation.

EH


On 5/25/21 3:29 PM, Edward Hammond wrote:
>
> I noticed last year that my decode cycles were pushing the Pi's
> limits.  Your mileage may vary, and it certainly will void any
> warranty, but overclocking the Pi4 is also a possibility.
>
> I experimented with that option and, on my example at least, I
could
> dial in a ~12-14% clock speed boost stably (IIRC).  This did
shorten
> the decoding cycle.
>
> Any higher clock rate, again on my particular Pi, and it started
> behaving erratically.
>
> Edward
>
>
>
> On 5/25/21 12:37 PM, Rob Robinett wrote:
>> This kind of problem has been reported by others in the
Wednesday WD
>> Zoom call and fixed by upgrading to a more powerful CPU than
the ARM
>> on the Pi4.  It appears that with the summer months and increasing
>> sunspot cycle, the Pi CPUs can't keep up decoding the number of
spots
>> in the wav file captures.  However it is hard to observe those
'out
>> of CPU' events.
>> Most of the top spotting sites have migrated from Pi4s to i86
>> servers.  An inexpensive, low power and high performance option is
>> the Lenovo M93P Tiny PC (don't get the larger model) with i5 CPU
>> which can be purchased used or refurbished for $100 or less on
ebay:
>> https://tinyurl.com/emrjnw <https://tinyurl.com/emrjnw> The
M93P consumes 12W peaking at 36W
>> while decoding spots.
>> WD requires very little RAM space, so a 2 or 4GB machine would be
>> fine.  I bought mine without HD and added a SSD and installed
Ubuntu
>> 20.04 LTS. But since WD does very little disk  IO to the root file
>> system, using a rotating HD might be a better choice for longer
life.
>>
>
>








--
Rob Robinett
AI6VN
rob@robinett.us <mailto:rob@robinett.us>
mobile: +1 650 218 8896


Re: Transient missing spots events may require WD server CPU upgrade

Rob Robinett
 

In WD V3.0 I will be adding support for FST4W 120/300/900/1800 and using those modes, especially the 900/1800, will surely require more CPU than any Pi can offer.

On Tue, May 25, 2021 at 1:06 PM Edward Hammond <manager@...> wrote:
Sorry, a correction.  It was FT8 that was pushing my Pi to its limits
then, not WSPR.  But I would think overclocking would similarly help in
this situation.

EH


On 5/25/21 3:29 PM, Edward Hammond wrote:
>
> I noticed last year that my decode cycles were pushing the Pi's
> limits.  Your mileage may vary, and it certainly will void any
> warranty, but overclocking the Pi4 is also a possibility.
>
> I experimented with that option and, on my example at least, I could
> dial in a ~12-14% clock speed boost stably (IIRC).  This did shorten
> the decoding cycle.
>
> Any higher clock rate, again on my particular Pi, and it started
> behaving erratically.
>
> Edward
>
>
>
> On 5/25/21 12:37 PM, Rob Robinett wrote:
>> This kind of problem has been reported by others in the Wednesday WD
>> Zoom call and fixed by upgrading to a more powerful CPU than the ARM
>> on the Pi4.  It appears that with the summer months and increasing
>> sunspot cycle, the Pi CPUs can't keep up decoding the number of spots
>> in the wav file captures.  However it is hard to observe those 'out
>> of CPU' events.
>> Most of the top spotting sites have migrated from Pi4s to i86
>> servers.  An inexpensive, low power and high performance option is
>> the Lenovo M93P Tiny PC (don't get the larger model) with i5 CPU
>> which can be purchased used or refurbished for $100 or less on ebay:
>> https://tinyurl.com/emrjnw  The M93P consumes 12W peaking at 36W
>> while decoding spots.
>> WD requires very little RAM space, so a 2 or 4GB machine would be
>> fine.  I bought mine without HD and added a SSD and installed Ubuntu
>> 20.04 LTS. But since WD does very little disk  IO to the root file
>> system, using a rotating HD might be a better choice for longer life.
>>
>
>








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


Re: Transient missing spots events may require WD server CPU upgrade

Edward Hammond
 

Sorry, a correction.  It was FT8 that was pushing my Pi to its limits then, not WSPR.  But I would think overclocking would similarly help in this situation.

EH

On 5/25/21 3:29 PM, Edward Hammond wrote:

I noticed last year that my decode cycles were pushing the Pi's limits.  Your mileage may vary, and it certainly will void any warranty, but overclocking the Pi4 is also a possibility.

I experimented with that option and, on my example at least, I could dial in a ~12-14% clock speed boost stably (IIRC).  This did shorten the decoding cycle.

Any higher clock rate, again on my particular Pi, and it started behaving erratically.

Edward



On 5/25/21 12:37 PM, Rob Robinett wrote:
This kind of problem has been reported by others in the Wednesday WD Zoom call and fixed by upgrading to a more powerful CPU than the ARM on the Pi4.  It appears that with the summer months and increasing sunspot cycle, the Pi CPUs can't keep up decoding the number of spots in the wav file captures.  However it is hard to observe those 'out of CPU' events.
Most of the top spotting sites have migrated from Pi4s to i86 servers.  An inexpensive, low power and high performance option is the Lenovo M93P Tiny PC (don't get the larger model) with i5 CPU which can be purchased used or refurbished for $100 or less on ebay: https://tinyurl.com/emrjnw  The M93P consumes 12W peaking at 36W while decoding spots.
WD requires very little RAM space, so a 2 or 4GB machine would be fine.  I bought mine without HD and added a SSD and installed Ubuntu 20.04 LTS. But since WD does very little disk  IO to the root file system, using a rotating HD might be a better choice for longer life.


Re: Transient missing spots events may require WD server CPU upgrade

Edward Hammond
 

I noticed last year that my decode cycles were pushing the Pi's limits.  Your mileage may vary, and it certainly will void any warranty, but overclocking the Pi4 is also a possibility.

I experimented with that option and, on my example at least, I could dial in a ~12-14% clock speed boost stably (IIRC).  This did shorten the decoding cycle.

Any higher clock rate, again on my particular Pi, and it started behaving erratically.

Edward

On 5/25/21 12:37 PM, Rob Robinett wrote:
This kind of problem has been reported by others in the Wednesday WD Zoom call and fixed by upgrading to a more powerful CPU than the ARM on the Pi4.  It appears that with the summer months and increasing sunspot cycle, the Pi CPUs can't keep up decoding the number of spots in the wav file captures.  However it is hard to observe those 'out of CPU' events.
Most of the top spotting sites have migrated from Pi4s to i86 servers.  An inexpensive, low power and high performance option is the Lenovo M93P Tiny PC (don't get the larger model) with i5 CPU which can be purchased used or refurbished for $100 or less on ebay: https://tinyurl.com/emrjnw  The M93P consumes 12W peaking at 36W while decoding spots.
WD requires very little RAM space, so a 2 or 4GB machine would be fine.  I bought mine without HD and added a SSD and installed Ubuntu 20.04 LTS. But since WD does very little disk  IO to the root file system, using a rotating HD might be a better choice for longer life.


Transient missing spots events may require WD server CPU upgrade

Rob Robinett
 

This kind of problem has been reported by others in the Wednesday WD Zoom call and fixed by upgrading to a more powerful CPU than the ARM on the Pi4.  It appears that with the summer months and increasing sunspot cycle, the Pi CPUs can't keep up decoding the number of spots in the wav file captures.  However it is hard to observe those 'out of CPU' events.
 
Most of the top spotting sites have migrated from Pi4s to i86 servers.  An inexpensive, low power and high performance option is the Lenovo M93P Tiny PC (don't get the larger model) with i5 CPU which can be purchased used or refurbished for $100 or less on ebay:  https://tinyurl.com/emrjnw  The M93P consumes 12W peaking at 36W while decoding spots.
 
WD requires very little RAM space, so a 2 or 4GB machine would be fine.  I bought mine without HD and added a SSD and installed Ubuntu 20.04 LTS. But since WD does very little disk  IO to the root file system, using a rotating HD might be a better choice for longer life.
 


Re: recent c2_level very low on some bands

Rob Robinett
 

I hope the new CPU fixes your problem.
It is great to have help with OS support.


On Sat, May 22, 2021 at 3:21 PM hf_linkz <ounaid@...> wrote:
I would like to thanks Rob and company for the analysis of my setup the other day (via the Zoom meeting)
It appeared that my Raspberry Pi 3B+ was too weak for a 12 chan monitoring, it used to work fine in the past so maybe the newer OS release was a bit too heavy that time .. who knows

But today I have modified the script to run on a more powerful computer, running an Archlinux distro
Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz (bogomips ~5700, it was 40 on the pi3 HI HI) - 4GB RAM - SSD drive

It's now 2310z on 22 may 2021 and wsprdaemon.sh is running on this computer
I will have a look on the logs to see if something is wrong and if it's OK then I'll fork the git code and commit the modified version for that specific OS, mods are mostly s/apt-get/pacman/ btw

Regards







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


Re: recent c2_level very low on some bands

hf_linkz
 

I would like to thanks Rob and company for the analysis of my setup the other day (via the Zoom meeting)
It appeared that my Raspberry Pi 3B+ was too weak for a 12 chan monitoring, it used to work fine in the past so maybe the newer OS release was a bit too heavy that time .. who knows

But today I have modified the script to run on a more powerful computer, running an Archlinux distro
Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz (bogomips ~5700, it was 40 on the pi3 HI HI) - 4GB RAM - SSD drive

It's now 2310z on 22 may 2021 and wsprdaemon.sh is running on this computer
I will have a look on the logs to see if something is wrong and if it's OK then I'll fork the git code and commit the modified version for that specific OS, mods are mostly s/apt-get/pacman/ btw

Regards


Re: Audio input decoding

Rob Robinett
 

Have you executed './wsprdaemon.sh -i' ? 
t will help you find the audio port IDs and set the gain of your ports.


Audio input decoding

Paulo CT
 

Hello all,

I´ve been trying to run a single band wspr monitor with the audio input feature, but with no success. My present setup consists on a Funcube dongle, playong on the PC´s own soundcard. Since there´s no speakers plugged in, the default input the monitor for dummy audi output, that can be seen both by WSJTX and a QRSS grabbers.

I´m using a modified default config file, with only AUDIO_0 enabled, which suposedly should be listening on localhost:0,0. So far, I havn´t been able to see any spots from this setup. i also tried with my main shack PC, with an external soundcard, with no results as well.
OS is Ubuntu 20.04.

Here´s my current .conf file:

# To enable these options, remove the leading '#' and modify SIGNAL_LEVEL_UPLOAD_ID from "AI6VN" to your call sign:
#SIGNAL_LEVEL_UPLOAD="proxy"        ### If this variable is defined and not "no", AND SIGNAL_LEVEL_UPLOAD_ID is defined, then upload signal levels to the wsprdaemon cloud database
                                   ### SIGNAL_LEVEL_UPLOAD_MODE="no"    => (Default) Upload spots directly to wsprnet.org
                                   ### SIGNAL_LEVEL_UPLOAD_MODE="noise" => Upload extended spots and noise data.  Upload spots directly to wsprnet.org
                                   ### SIGNAL_LEVEL_UPLOAD_MODE="proxy" => In addition to "noise", don't upload to wsprnet.org from this server.  Regenerate and upload spots to wsprnet.org on the wsprdaemon.org server
#SIGNAL_LEVEL_UPLOAD="yes"          ### If this variable is defined as "yes" AND SIGNAL_LEVEL_UPLOAD_ID is defined, then upload extended spots and noise levels to the logs.wsprdaemon.org database and graphics file server.
#SIGNAL_LEVEL_UPLOAD_ID="AI6VN"     ### The name put in upload log records, the the title bar of the graph, and the name used to view spots and noise at that server.
#SIGNAL_LEVEL_UPLOAD_GRAPHS="yes"   ### If this variable is defined as "yes" AND SIGNAL_LEVEL_UPLOAD_ID is defined, then FTP graphs of the last 24 hours to http://wsprdaemon.org/graphs/SIGNAL_LEVEL_UPLOAD_ID
#SIGNAL_LEVEL_LOCAL_GRAPHS="yes"    ### If this variable is defined as "yes" AND SIGNAL_LEVEL_UPLOAD_ID is defined, then make graphs visible at http://localhost/

##############################################################
### The RECEIVER_LIST() array defines the physical (KIWI_xxx,AUDIO_xxx,SDR_xxx) and logical (MERG...) receive devices available on this server
### Each element of RECEIVER_LIST is a string with 5 space-seperated fields:
###   " ID(no spaces)             IP:PORT or RTL:n    MyCall       MyGrid  KiwPassword    Optional SIGNAL_LEVEL_ADJUSTMENTS
###                                                                                       [[DEFAULT:ADJUST,]BAND_0:ADJUST[,BAND_N:ADJUST_N]...]
###                                                                                       A comma-separated list of BAND:ADJUST pairs
###                                                                                       BAND is one of 2200..10, while ADJUST is in dBs TO BE ADDED to the raw data
###                                                                                       So If you have a +10 dB LNA, ADJUST '-10' will LOWER the reported level so that your reports reflect the level at the input of the LNA
###                                                                                       DEFAULT defaults to zero and is applied to all bands not specified with a BAND:ADJUST

declare RECEIVER_LIST=(
#        "KIWI_0                  10.11.12.100:8073     AI6VN         CM88mc    NULL"
#        "KIWI_1                  10.11.12.101:8073     AI6VN         CM88mc  foobar       DEFAULT:-10,80:-12,30:-8,20:2,15:6"
#        "KIWI_2                  10.11.12.102:8073     AI6VN         CM88mc  foobar"
         "AUDIO_0                     localhost:0,0     CT2IWW        IN51wf  foobar"               ### The id AUDIO_xxx is special and defines a local audio input device as the source of WSPR baseband 1400-1600 Hz signals
#        "AUDIO_1                     localhost:1,0     AI6VN         CM88mc  foobar"  
#        "SDR_0                           RTL-SDR:0     AI6VN         CM88mc  foobar"               ### The id SDR_xxx   is special and defines a local RTL-SDR or other Soapy-suported device
#        "SDR_1                           RTL-SDR:1     AI6VN         CM88mc  foobar"
#        "MERG_0    KIWI_1,KIWI2,AUDIO_1,SDR_1     AI6VN         CM88mc  foobar"
)

### This table defines a schedule of configurations which will be applied by '-j a,all' and thus by the watchdog daemon when it runs '-j a,all' ev ery odd two minutes
### The first field of each entry in the start time for the configuration defined in the following fields
### Start time is in the format HH:MM (e.g 13:15) and by default is in the time zone of the host server unless ',UDT' is appended, e.g '01:30,UDT'
### Following the time are one or more fields of the format 'RECEIVER,BAND'
### If the time of the first entry is not 00:00, then the latest (not necessarily the last) entry will be applied at time 00:00
### So the form of each line is  "START_HH:MM[,UDT]   RECEIVER,BAND... ".  Here are some examples:

declare WSPR_SCHEDULE_simple=(
    "00:00                       AUDIO_0,10 "
)

#declare WSPR_SCHEDULE_merged=(
#    "00:00                       MERG_0,630 MERG_0,160"
#)

#declare WSPR_SCHEDULE_complex=(
#    "sunrise-01:00               KIWI_0,630 KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12          "
#    "sunrise+01:00                          KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
#    "09:00                       KIWI_0,630 KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12          "
#    "10:00                                  KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
#    "11:00                                             KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
#    "18:00           KIWI_0,2200 KIWI_0,630 KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15                    "
#    "sunset-01:00                           KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
#   "sunset+01:00                KIWI_0,630 KIWI_0,160 KIWI_1,80 KIWI_2,80eu KIWI_2,60 KIWI_2,60eu KIWI_1,40 KIWI_1,30 KIWI_1,20 KIWI_1,17 KIWI_1,15 KIWI_1,12 KIWI_1,10"
#)

### This array WSPR_SCHEDULE defines the running configuration.  Here we make the simple configuration defined above the active one:
declare WSPR_SCHEDULE=( "${WSPR_SCHEDULE_simple[@]}" )

Any thoughts?

thanks

Paulo, CT2IWW


Re: Prefix/suffix call signs TX messages (Type 2) don't make it to WSPRnet.org, any solution for this?

Harry Zachrisson - SM7PNV
 

I think I am on its way to track down the weirdness with Type 2 messages.
It seems they only show up if I am also running a receiver with the same call sign and suffix.

I if  run a TX sending SM7PNV/7 and a RX with call sign SM7PNV the TX messages don't show up until I change my RX call sign to SM7PNV/7
The Type 2 message don't contain a locator so it is taken from the RX instead of leaving blank.
This a slight problem as well.

So if I send type    1 message as SM7PNV with locator AA00
followed by a type 2 message as SM7PNV/7

the first message will have locator AA00 but the second message will not.
It will have the locator of my receiving station inserted

OK at least know I know how it works, not super useful in my applications.
I was thinking to use it for trackers that could have used the Type 2 message to differentiate between several trackers running at the same time
E.g several balloons or sea buoys operating with the same Call sign but with different suffixes

73
//Harry 

 


Re: recent c2_level very low on some bands

hf_linkz
 

Ok thanks

I'll provide you a link to

Regards

241 - 260 of 501