Von: "John Douyere" <vk2eta@xxxxxxxxx>
Gesendet: Oct 1, 2011 2:36:00 PM
An: pskmail@xxxxxxxxxxxxx
Betreff: [pskmail] Exchange between server and client for dynamic mode table and mode changes
Rein, Per
I read the jPskmail code for the dynamic mode tables and there is something I don't understand.
In this case, with the Android client, I use PSK500, 250, 125 and 63 as the modes and PSK250 as the initial TX modes for the server, resulting in a connect string sent to the server of "<SOH>...... 8789aXXXX<EOT>" with the first '8' being the startup TX mode of the server and the rest "789a" the mode table.
When the server replies it sends a proto byte of "3". As I thought this was the index in the mode table starting at position 1 this make my Android client reply in PSK125 when the server of course listens in PSK250 the mode used at connect time.
Something is wrong but I am not sure where.
Also can we have PSK31 as part of the list of modes in the server? (not in the jPskmail client as there are better modes to use).
While on this subject, I have seen good signals in PSK63 and especially psk31 not being decoded properly because of the frequency offset between transceivers and sound cards, and the reset-to-carrier feature making the audio frequency jump around and miss characters.
I have thought of how to use these modes effectively, including the MFSK modes if we include them.
I think the following method should work:
1. A parameter sets the maximum deviation from the audio carrier frequency like we have now, say +/- 50Hz.
2. The server modem AND the client modem remember the audio frequency decoded of the last RSID received (+/-2.7Hz accuracy).
3. There is no reset to carrier frequency as now. So even when there is a mode change, the audio frequency used to create the new modem is the same as in 2. There is no ALC either. The only limit of deviation is the parameter in 1.
4. So if the client does not decode the server due to an initial or progressive frequency offset, the transmission of RSID by the server will reset it's audio frequency where it should be.
5. A slight modification in behaviour is needed for the client: if the server requests a status WITH and RSID for the second time, the client will set TX RSID on for the next status reply ONLY. This allows for the server to re-align it's audio frequency which remains as decoded until the next occurrence.
Any comments of the above? This could be implemented in Fldigi for the server as well.
Regards,
John
