[pskmail] Re: Exchange between server and client for dynamic mode table and mode changes
- From: John Douyere <vk2eta@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Sun, 2 Oct 2011 10:17:32 +1000
Hi Rein,
There is no mode issue with jPskmail, just that I was copying the logic in
AndPskmail.
The table as sent to the server seems to be read from right to left (index
of 1 = the rightmost mode sent in the connect string). I was doing
the opposite.
I'll have a look at arq.pm here for my tests.
It should work ok now.
Thanks,
73, John
On Sun, Oct 2, 2011 at 12:46 AM, Rein Couperus <rein@xxxxxxxxxxxx> wrote:
> There ia a typing error in arq.pm.. (PSk63).
>
> Will test further (we never need to use PSK63 here (:-)
> I will see if I can add PSK31...
>
> The '3' returned by the server is a pointer into the new mode table,
> seems to work here on jPSKmail.
>
> Rein PA0R
>
>
> --
> http://pa0r.blogspirit.com
>
> ------------------------------
> *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
>
>
Other related posts:
