search

ve3wmb / OrionWspr

Arduino WSPR Beacon for Amateur Radio pico-Balloons using SI5351a
GNU General Public License v3.0
16 stars 5 forks source link

Truncation of first Symbol in WSPR message transmission likely #1

Closed ve3wmb closed 5 years ago

ve3wmb commented 5 years ago

In the function encode_and_tx_wspr_msg1( ) the transmission of the first Symbol in the encoded message begins while the Timer1 is already running. What this is means is TCNT1 will not be equal to 0 (it will be indeterminate at this point as the Timer interrupt has been running for some time). This will have the effect of shortening the duration of the transmission of the first symbol by an unknown amount of time. This may cause problems with decoding of the symbol, however redundancy through the FEC may recover it so it may not be that big of an issue. Still this needs to be investigated and fixed if deemed necessary.

A possible related issue in the same function concerns the clearing of the volatile bool g_proceed which is set by the ISR code for Timer1. Ideally a set action should be performed within a critical section as this needs to be an Atomic Action. Given the duration of the Timer1 interrupt interval (every 1.46 seconds) this might not ever be an issue (i.e. not likely that it will get cleared by the ISR as it is being set). Also considering that the volatile keyword forces this variable into a register, a boolean clear should likely take a single clock cycle. So even though this is not a great practice it may not be a real problem but it should be investigated to determine if a different approach is needed.

Michael VE3WMB

ve3wmb commented 5 years ago

I had an additional thought on this issue. If it is a real problem then it should be impacting decodes. If it is not then we can safely ignore it. A possible way of testing this is to run a prototype beacon into a dummy load with a receiver close by connected to a computer running WSJT-X in WSPR mode. By adjusting the spacing and/or using a switched attenuator on either the TX or RX we should be able to adjust things so the the RX signal report is something below -20 dBm which would be a typical incoming WSPR signal. Now in theory on every transmission cycle the RX station should decode the TX packet as we have removed the variable of propagation. If we leave this run for say 24 hours and there are no missing decodes then there is no real problem. If we are missing some decodes then it seems that we have a problem.

ve3wmb commented 5 years ago

This issue is resolved by synchronizing the 1.46 second Timer1 interrupt used for WSPR TX to the start of WSPR transmission by zeroing TCNT1 and doing a Preselector Reset with the following code

// We need to synchronize the 1.46 second Timer/Counter-1 interrupt to the start of WSPR transmission as it is free-running. // We reset the counts to zero so we ensure that the first symbol is not truncated (i.e we get a full 1.46 seconds before the interrupt handler sets // the g_proceed flag).
noInterrupts(); TCNT1 = 0; // Clear the count for Timer/Counter-1 GTCCR |= (1 << PSRSYNC); // Do a reset on the pre-scaler. Note that we are not using Timer 0, it shares a prescaler so it would also be impacted. interrupts();

The was submitted in the v0.15a update.