alexranaldi / cwsl_digi Goto Github PK

Hi Alex and all,
Great software - 0.88 working well looks better.
When run - Missing libmmd and libifcore type error when I copied 0.88 files over 0.86 (using 0.86 config.ini still)

• easily solved by installing fortran math runtime - not sure where it went :)
  here -
  https://registrationcenter-download.intel.com/akdlm/IRC_NAS/b4e4ffda-25e9-4549-8ca1-46087ff704d7/w_ifort_runtime_p_2023.2.0.49500.exe
  from web page
  https://www.intel.com/content/www/us/en/developer/articles/tool/compilers-redistributable-libraries-by-version.html
  regards 73
  Matthew G0TTV

Heads up - wsprnet.org has changed IP address. I'm unsure why addresses for wsprnet & pskr are hard coded but would suggest using their hostname so such changes don't affect the software in future.

Hi Alex,

On first start the box loads its firmware and by this time program has errored. Second time it works ok and all other subsequent times... any way of waiting for the firmware load to finish and then continue with your fine software. Running twice is a bit of a pain for my batch script ;) Keep up the great work and many thanks.

Matthew.

The config file suggests using wave files is faster than shared memory. It seems somewhat counter-intuitive but I tried it anyway, using a RAM disk as D:\ and setting transfermethod=wavefile. CWSL_DIGI still reports the shared memories when starting up and I see no noticeable change in CPU load. Is there something I have missed? I decode thirtysomething FT4 and FT8 segments.

Björn SM7IUN

Hi there, I stumbled upon this interesting project.

I have been using various receivers for WSPR and FT8, like Red Pitaya's, Hermes Lite and RSP1a with JTDX and WSJT-x.

But I do not understand what needs to be done to get cwsl_digi to work with these.

I followed the install and config instructions and have wsjt-x installed.

But I do not find any instructions to get access to my receivers. Should I just start wsjt-x and let that run or is there other magic to it. Or can I find these instructions somewhere (google did not help, it only brought me to the RBN Groups io.

Thanks
PE3ES / F4VTQ de Erwin

Hi Alex,
Thanks again for your nice software. 0.84 working well.

1. Any chance of an intelligent buffer so signals captured are not missed if the internet connection goes down while your excellent software is running e.g. WIFI goes off, signals don't get uploaded to pskinfo for the time it was off, even if WIFI comes back on?
2. For some reason on mine when the WIFI reconnects it doesn't seem to start uploading again, even the new ones from then on?
   regards,
   Matthew.

The text in the config file says

# Maximum age of data to report, in multiples of the mode's time frame
#   e.g., for FT8, 15s * 10 = 150s. Data older than 150 sec is dropped 
#   Data is dropped at 260 sec always, regardless of this value.
#   The default value is 10.
#maxdataage=10

When I try to set maxdataage=5, CWSL_DIGI says

### ERROR :: wsjtx.maxdataage must be >= 30

Telling me that maxdataage is actually seconds rather than frames.
But how can then the default be 10? What is the actual default?
And from when is the time counted? At the first sample, at last sample or after decode?

Björn SM7IUN

I have noticed that the base decoding frequency is always reported for FT8. This is of course correct when decoding the waterhole frequencies like 3573, 7074, etc. but can be misleading when decoding F/H segments. For instance, I have 14090 as one of the F/H segments and sometimes DX transmit at, say, 14091 or 14092. They are then still spotted as 14090. It would be great if there was an option for the decoder= lines to chose either base frequency or actual frequency truncated to whole kHz . Or some other method of achieving this.

Björn SM7IUN

Over the last 24 hours I've seen the following error from CWSL_Digi for my K1RA skimmer spit out numerous times:

ERROR :: Socket connect failed with error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

2024-06-17 17:10:40.608 ### ERROR :: Error connecting to WSPRNet

Is anyone else who's spotting WSPR from CWSL_Digi not seeing their spots posted at

https://www.wsprnet.org/drupal/wsprnet/spotquery

I'm also running K1RA-PI (DigiSkimmer / RPi + RaspSDR) and K1RA-4 (QRA-Skimmer / RX-888) also from the same QTH/network skimming all modes and those are posting WSPR to WSPRnet just fine.

What is the timeout on the CWSL_Digi socket connection to the WSPRnet server? I see manually polling the WSPRnet database that response times today are up to 60 seconds and its acting very sluggish.

Thanks & 73

andyz - K1RA

It looks as though CWSL_DIGI submits the timestamp of the start of the transmission rather than the decode time. This confuses the analyzer that looks for incorrect QRG on the reports -- it assumes that a particular callsign only transmits on a single band in a single timeslot.

Thanks

Philip, N1DQ (PskReporter.info)

I am the author of the SOTA/POTA spotting service SOTAmat (https://SOTAmat.com). The system works by having SOTA/POTA operators, in the field without cell service, send special FT8 messages addressed to themselves where their callsign has up to a 4 character suffix (the suffixes are carefully curated NOT to interfere with valid callsign suffix Country Locators, but instead are callsign suffix Indicators). The Indicator suffixes are commands to be executed by an automated service (self spotting for example, similar to RBNhole, but for SSB and not just CW).

Until the recent CWSL_DIGI 0.87-alpha/beta, there has only been one SDR skimming software (SparkSDR) that:

• Looks for callsigns inside FT8 "Free Text" messages (the 13-character FT8 mode that allows any message schema-free). Most other software on the market (besides SparkSDR) only looks for callsigns in the normal FT8 Schemas where the data structure informs the software that it is an actual callsign rather than just free text. SparkSDR (and now CWSL_DIGI) look for callsigns in the free text schema-free.
• Also grabs callsign suffixes out of the FT8 "Free Text"
• Reports such callsigns+suffixes to PSKreporter. Note that the WSJT-X software only reports callsigns found in FT8 CQ messages. Only SparkSDR reports the Free-text ones.
• My SOTAmat software has a direct feed from PSKreporter. It finds and decodes the special callsign/suffix messages and executes the instructions. You can see examples here: https://SOTAmat.com/activity

If you want to get into the weeds on how all this works, and the legal framework around it, you can watch a (far too long) video here: https://youtu.be/FG6hO5LgByI

CWSL_DIGI 0.87-alpha/beta has started doing what SparkSDR is doing. This is AWESOME since the SOTA community wants more SOTAmat compatible skimming stations to hear these messages.

PROBLEM: While it is great to have CWSL_DIGI add this functionality, it has a bug. Most of the time it works just like SparkSDR. However, some of the time CWSL_DIGI is truncating the callsign suffix and removing a character or two. This completely changes the meaning of the command the user wants to execute! I have had to black-list any PSKreporter reception reports from CWSL_DIGI until we get this fixed. What is really strange is that sometimes multiple CWSL_DIGI stations will hear the same FT8 Free-Text message and they will each decode the message differently (one will not truncate the suffix, while the other one does truncate). Since FT8 has error detection and correction, both stations must be getting the same identical message, but even the same version of the code at two skimmers are reporting different suffixes. Non-deterministic errors!

You can reach me at S O T A m a t -AT- S O T A m a t -DOT- c o m and I can share screenshots of the database dump of past reception reports where SparkSDR and most of the CWSL_DIGI reception reports are identical, but some differ and are truncated.

Here is a Google Spreadsheet that is an excerpt of my database showing in Red Color the errors:
https://docs.google.com/spreadsheets/d/1o5OB-0nNljfd-8szrk1ChgU0ai8c4flRNrE9D4iqHE0/edit?usp=sharing

Thanks! 73 de AB6D - Brian