pflarue / ardop

Source for various version of ARDOP
Other
29 stars 5 forks source link

TX PSK envelope control? #64

Open pflarue opened 3 months ago

pflarue commented 3 months ago

I recently rebuilt CalcTemplates.c, which is intended to create ardopSampleArrays.c. This contains the digitized sample data for constructing transmitted signals. CalcTemplates.c was not functional in the form inherited from ardopc, but now it works.

For generating the PSK templates, there were (and still are) two lines of code, one of which is commented out. One is labeled "with no envelope control", and the other "with envelope control using Sin". The latter must be used to duplicate the current content of ardopSampleArrays.c (which is what ardopcf is currently using), but the other is what was active in CalcTemplates.c before I started editing it.

I'm unsure which version ardopcf should be using. I see no reference to this in the Ardop spec, but the spec does give crest factor values for the various modes. It should be possible to calculate or measure crest factors with and without this envelope control to determine which was intended by the specification.

I believe that envelope control should (theoretically) reduce maximum bandwidth for an individual carrier, and thus might reduce interference between adjacent carriers, thereby reducing the error rate. If the transmit filtering is working correctly, this shouldn't significantly change the bandwidth of the combined multi-carrier signal or the transmitted bandwidth of a single carrier signal. The disadvantage of this envelope control is that it would increase the crest factor meaning that for a given peak envelope power (PEP), the average power would be lower. For a given noise level, this would result in a lower average signal to noise ratio with envelope control, resulting in a higher error rate.

If the previous paragraph is correct, then no envelope control seems likely to give the best performance for the 200 Hz bandwidth single carrier PSK/QAM modes where interference between multiple carriers isn't an issue. For the multi-carrier modes, it is less obvious which of the competing effects would dominate. This seems likely to be dependent on the adequacy of the spacing between the adjacent carriers. Thus, the carrier spacing may have been chosen based on whether or not envelope control was intended to be used.

This requires further investigation, since it is possible that the current usage is incorrect and is resulting in decreased performance.

pflarue commented 3 months ago

I recorded (using web sdr) a brief connection between my station running ardopcf v1.0.4.1.2+develop and a Winlink gateway running RMS Trimode 1.3.54.0 (presumably running Ardop_Win). I used bw 200MAX assuming that the envelope control would be visible in the single carrier 4PSK.200.100 frames used by default for this BW, and ensuring that a basic Winlink check in with no messages to send or receive would still require each station to send multiple data frames.

I viewed the recording with Audacity, using timestamps from my debug log to identify frame types and distinguish which heard frames were mine and which were sent by the Winlink gateway.

With a moderate amount of noise, I could see what appears to be clear evidence of the envelope control in my own 4PSK.200.100 frames as expected. I did not see such evidence in the 4PSK.200.100 send by the Winlink gateway.

If anyone wants to repeat this test, envelope control in a PSK frame viewed as a time domain waveform looks similar to the two-tone leader at the start of every Ardop frame, with its sinusoidally varying amplitude. However, the pulse duration is half as long for the PSK data compared to the leader.

This provides initial evidence that Ardop_Win is not doing envelope control like what ardopcf does.