WsprDaemon

a robust  decoding and reporting system for  WSPR

The following are our working definitions of the data fields in our Timescale spots and wsprdaemon_spots tables. (Updated 15 May 2020). There's a separate page for wsprdaemon_noise data fields.

Variables uploaded to, or derived by, wsprnet.org and also uploaded to wsprdaemon_spots

WSPR field name definitions

date and time          

drift

frequency     


     

km          

          

SNR          

          

rx_id                    

rx_grid

tx_call     

          

tx_dBm               

tx_grid               

tx_az          

UTC

Drift of the transmitted signal in Hz/minute seen by the receiver (which may also drift).

Frequency in MHz as seen at the receiver by adding the measured audio frequency to the 'dial' frequency for the selected band. Frequency is reported to seven significant digits, i.e. 0.1Hz, to wsprdaemon_spots.

Distance in km calculated from the receiver and transmitter grid squares. Accuracy will be best with two 6-character locators.

Signal to Noise ratio calculated in wsprd from the 30th percentile of the sorted FFT coefficients scaled to a 2.5kHz bandwidth.

Callsign (or other designator if SWL) of the reporting station.

4 or 6 character Maidenhead grid square. Map available here.

Callsign of the transmit station. If the sender is using a WSPR Type 3 message then the entry will look like <AJ8S/1>.

Power reported by the transmitting station. 30dBm = 1 Watt.

4 or 6 character Maidenhead grid square. Map available here.

Azimuth in degrees of the receiver as seen at the transmitter assuming a great circle short path. Clockwise from north. This is the azimuth reported by wsprnet.

band


c2_noise     



rms_noise     

rx_az     



rx_lat


     

rx_lon     

tx_lat

tx_lon     

v_lat




v_lon

Band in metres for 2200 - 2 metres. When wsprdaemon can report spots from receivers at 70cm and 23cm those will be reported as 70 and 23.

Noise estimate from the wsprdaemon FFT algorithm using the c2 decimated samples file produced by wsprd. Units are dBm in 1Hz, however the absolute value will depend on the offset calibration provided at the receiver (same goes for rms_noise).

Noise estimate from the wsprdaemon RMS algorithm, essentially the RMS value of the quietest 50ms within the gap between WSPR transmissions.

Azimuth in degrees of the incoming signal at the receiver assuming a great circle short path from the transmitter. Clockwise from north. This is calculated by wsprdaemon; only tx_az is reported by wsprnet.

Latitude in degrees of the receiver calculated from the rx_grid. Negative is south. These numeric latitude and longitude fields allow for numeric SELECT statements in postgreSQL queries.

Longitude in degrees of the receiver calculated from the rx_grid. Negative is west.

Latitude in degrees of the transmitter calculated from the tx_grid. Negative is south.

Longitude in degrees of the transmitter calculated from the tx_grid. Negative is west.

Latitude in degrees of the vertex of the great circle path between receiver and transmitter. The vertex is the most northerly, or southerly, point on the path. There are, of course, instances where the vertex is at the receiver or transmitter. This is calculated by wsprdaemon and can be useful when studying paths that are near to or within the polar Auroral Ovals.

Longitude in degrees of the vertex of the great circle path between receiver and transmitter.

Derived  and other  variables calculated by wsprdaemon and uploaded to wsprdaemon_spots

Variables available from wsprd, not uploaded to wsprnet but uploaded to wsprdaemon

The following variables are calculated within wsprd but are not reported to wsprnet. They have been added to the wsprdaemon data set for completeness and in case they may be of use in some studies, especially given our full relational database facility. The interpretation below is that of G Griffiths, G3ZIL, derived from reading the wsprd.c source code and related material. There may well be errors of interpretation or understanding. We would welcome posts on our Forum with corrections or further/clearer explanations. Curret as of wsjtx 2.2rc1.

blocksize






dt










     

decode_cycles




     

jitter






     

metric

     



     






















          


A parameter controlling the detection of individual symbols in the wsprd demodulator. Allowable values are 1, 2, 3, 6, 9. A value of 1 signifies that the first try using non-coherent detection of individual symbols was successful (sufficient), this is equivalent to the original wspr demodulator. Blocksizes of 2 and above means that that many symbols are decoded at once, from the code, "Longer block lengths require longer channel coherence time". Most of the time blocksize will be 1, as an example, of 90271 spots at KD2OM 88214 were blocksize 1, 1575 at 2 and 482 at 3, none were at 6 or 9.

This is the time difference between the actual start of the audio signal presented to wsprd and 2 seconds past an even minute as perceived by the clock at the receiver. wsprdaemon records the full 10ms resolution value. There are (possibly at least) four main causes for a non-zero reading:

1. A time offset from UTC in the clock at the transmitter.

2. A time offset from UTC in the clock at the receiver.

3. A delay (latency) at the transmitter between the clock-commanded start of transmission and the actual transmission.

4. A delay (latency) at the receiver between the clock-commanded start of reception and the actual audio file start.

This is the number of cycles taken for the Fano (default) or Jelinek (if selected) decoder to produce an output. The default maximum number of cycles is 10,000, but can be set with the -C option on calling wsprd. In practice the most common value for decode_cycles (mode) is 1; for example, decode_cycles was 1 for 10212 out of 13285 spots for KD2OM on 40m, which is about 77%.

Applied as a fine adjustment to the well-known dt time shift value. Centred on zero, values are in steps of 8 between -64 and +64. For 91092 spots at KD2OM 85645 i.e. 94% jitter was 0, 1.5% were at -8 and 1% at +8, and all allowed values to +/-64 were present. While no unit is given, it is certainly time, and quite likely to be the sampling interval, that is 1/375Hz or 0.26667 seconds, making each step of 8 equivalent to 0.021333 seconds.

This is an output from the Fano (default) or Jelinek (if selected in the call to wsprd.c) decoder. In Information Theory, metric is a measure of the "closeness of a path to the received sequence". The distribution of metric for 92513 spots at KD2OM is shown below. There is a broad asymmetric distribution at about 570. The singular peak at 810 is because that value is when the Fano (or Jelinek) algorithm has failed. In that case, the Ordered Statistic Decoder (OSD) is executed. It will come up with its decode, and if accepted, the osd_decode flag (see below) will be set to 1. This happened (osd_decode flag set to 1) in 98.8% of instances when metric was 810 in this test case with KD2OM spots.

where the summations are over k=0 to 161, as WSPR uses a 162-bit sync vector pr3 comprising a pseudorandom sequence of 0s and 1s.

p0[k] to p3[k] are assumed to be the amplitudes of the four tones - amplitude because they are the square root of values with the same variable name. An example distribution of sync_quality for 13453 spots received by KD2OM on 40m is shown below.

Flag, either 0 or 1. If 0 then either the Fano (default) or the stack (Jelinek, only if wsprd is called with option -J ) decoding algorithms have been used to decode. These algorithms can end without a decode being produced. If 1 then the Ordered Statistics Decoder (OSD) has been used. This decoder will always produce a decode - but of course it can be wrong. Therefore, wsprd only accepts an OSD decode if the tx_call it produces is already in the hash table having been decoded previously by the Fano or Jelinek algorithms.

Our conjecture: A measure of how well the incoming sync symbol sequence is synchronised to the sync vector sequence timed by the receiver's clock. The raw variable looks like to be on a scale of 0 to 1 but is recorded as the integer of 10 times the raw value, hence recorded values are between 0 and 10. The overall equation is:

decodetype

(previously osd_decode)

     



     

sync_quality

A flag determined by user set options and the number of passes required to effect a decode. If wsprd is called with option -s (which it is not in wsprdaemon) this is the single pass (now very old) mode, so ipass can never be greater than 1, but (I think) can still be 1 if only a single pass was needed. If option -B was set (which it is not in wsprdaemon) then block demodulation is disables, only single-symbol noncoherent demodulation is used, and npass can take the values 1 or 2. Otherwise, npass may take a value of up to 3.


A count of the hard errors from the Fano (default) or the stack (Jelinek, only if wsprd is called with option -J ) decoding algorithm. Not yet clear what it means if the Ordered Statistics Decoder (OSD) has been used.

ipass







nhardmin