[pskmail] Re: Using MFSK modes
- From: John Douyere <vk2eta@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Wed, 17 Aug 2011 18:04:50 +1000
Hi Rein,
This is looking very good and we can add more modes in any order in that
list.
I was thinking about helping users choose modes: maybe we can colour code or
give a number rating to the modes in terms of robustness (not speed), so
that they can choose a logical series of modes.
We also need to have for each mode either a sensitivity factor or equivalent
to guide the server in upgrading modes. Maybe a value in dBs so that the
threshold can be adjusted based on the gap in dBs between the current mode
and the next one up.
That way if the choice is for example PSK500, PSK500R, PSK250R, THOR8 for
example, we do not re-upgrade from THOR8 to PSK250R too easily.
I hope that makes sense.
Have you considered removing the :1024 port number since we do not use it,
in order to minimise the size of the block?
Regards,
John
On Wed, Aug 17, 2011 at 4:50 PM, Rein Couperus <rein@xxxxxxxxxxxx> wrote:
> Hi John,
>
> I have the server working already. I have found a solution which is
> backword compatible.
> The list of modes to be used is sent in the connect request frame as a
> string of mode
> designators AFTER the proto byte, like:
> <SOH>10cPA0R:1024 PI4TUE:24 665b3d4AA0<EOT>
> Here the mode table is 65b3d.
>
> The mode list:
> my %modelist = ("0" => "default",
> "1" => "THOR8",
> "2" => "MFSK16",
> "3" => "THOR22",
> "4" => "MFSK32",
> "5" => "PSK250R",
> "6" => "PSK500R",
> "7" => "PSK500",
> "8" => "PSK250",
> "9" => "PSK125",
> "a" => "PSk63",
> "b" => "PSK125R",
> "c" => "MFSK64",
> "d" => "THOR11" );
>
> When there is no list, the default is used.
> Now working on the client code....
> There is a new 'Modes' tab in the prefs dialogue (see attachement).
>
> Rein PA0R
>
> --
> http://pa0r.blogspirit.com
>
> ------------------------------
> *Von:* "John Douyere" <vk2eta@xxxxxxxxx>
> *Gesendet:* Aug 15, 2011 11:38:03 PM
>
> *An:* pskmail@xxxxxxxxxxxxx
> *Betreff:* [pskmail] Re: Using MFSK modes
>
> Hi Rein,
>
> Thanks. That is good news. I look forward to the specs so that I can
> incorporate in the Android version.
>
> I have taken a big bite in the Android development by incorporating most of
> the client/server functions in the jPskmail client but I think it is worth
> it at the end despite a longer initial debug time.
>
> Interesting stuff.
>
> Best regards,
>
> John
>
> On Mon, Aug 15, 2011 at 5:49 PM, Rein Couperus <rein@xxxxxxxxxxxx> wrote:
>
>> Solid stuff John,
>>
>> I have already implemented an experimental mode choice table in the
>> client,
>> and I will set up a procedure for the server.
>>
>> Now to make sure all this will be backward compatible...
>>
>>
>> Rein PA0R
>>
>> --
>> http://pa0r.blogspirit.com
>>
>>
>> ------------------------------
>> *Von:* "John Douyere" <vk2eta@xxxxxxxxx>
>> *Gesendet:* Aug 15, 2011 2:29:30 AM
>> *An:* pskmail@xxxxxxxxxxxxx
>> *Betreff:* [pskmail] Re: Using MFSK modes
>>
>>
>>
>> Hi Rein,
>>
>> I just came back from a four days trip, so I apologize for a late
>> response.
>>
>> I haven't seen that problem but considering that MFSK is sensitive to
>> frequency mis-alignment it is quite logical that if there is mis-alignment
>> it would be the first mode to suffer.
>>
>> Since the mode table is arranged in a simultaneous speed and robustness
>> order AND each step up is done such that a threshold has to be reached to
>> upgrade we have to be mindful to have steps that are manageable.
>>
>> If the step is too large then we will have a lot of hunting whereby the
>> lower speed mode will be very robust but the communication will fail on the
>> next up because the robustness is not there for an upgrade.
>>
>> In my initial research on the modes which fitted that bill I found that
>> the correlation between signal quality in a given mode and the potential
>> success of the next mode up is not linear at all, and if you look at the
>> Fldigi code there are a few "adjustments" I did in the reported signal
>> quality to try to find a section of the curve where there was enough
>> correlation.
>>
>> So if you want address the MFSK frequency sensitivity I would suggest one
>> of the following solutions:
>>
>> 1. Replace MFSK32 with PSK125 so that we have a manageable step (-3dB in
>> sensitivity for 1/2 speed). I would advise against going strait to THOR22 as
>> the gap is significant (about -8dB and 1/3 of the speed). And replace MFSK16
>> with THOR11. THOR16 is a better mach in speed for MFSK16 but not in
>> sensitivity.
>>
>> OR
>>
>> 2. When using MFSK modes always send TXid in both directions when in a
>> connected session. RSID aligns the receiving Fldigi to the exact audio
>> frequency required.
>>
>>
>> But really all in all it depends on the situation and I really I think we
>> should have a user selectable set of modes to cater for the different
>> situations.
>>
>> This would address the situations where only a restricted list of modes
>> can be used but mode shifting adds value, e.g. Portable devices (like the
>> Android development), slower computers, wider modes.
>>
>> It would also address the situation where wider modes could be of value
>> like MFSK64 or new modes like THOR44 (easy to create at double the speed of
>> THOR22 but wider). The RSID codes could be borrowed from unusable modes for
>> ARQ like RTTY and CONTESTIA. It would be easy to have an alternate use of
>> these RSID codes when Fldigi is used under Pskmail. That would be a real
>> value to us in Region 3 for use on the low bands where MFSK64 is of more
>> value than PSK250R for example.
>>
>> In regards to passing this list to the server I have detailed possible
>> solutions in a previous email last week which I believe are fully backward
>> compatible and is not restrictive for the future, whatever new modes are
>> available or desired then.
>>
>> I believe the most flexible solution is to pass the list at connect time
>> so that the server can start using that list strait away even during the 3
>> phase connect state. Each mode is mapped to a character and that mode table
>> string is sent where we sent the current start-up TX mode for the server.
>>
>> With one character per mode instead of one letter for a given start-up
>> mode, we would have an increase of length of the connect sequence of 6
>> characters.
>>
>> If we believe that is an issue we can easily reduce the length by at least
>> 5 characters by for example removing the :1024 as at this point the port
>> number is not used. The net result would be an increase of 1 character for
>> the whole 7 modes table we use now. Not significant in my opinion.
>>
>> Also I would not expect that list to be much longer than the seven we have
>> now otherwise it becomes a bit silly (like having a 10 gears car would be).
>>
>> What will also be needed for that to work smoothly with various mode
>> combinations is a relative robustness index for each of the mapped modes so
>> that the threshold for the mode upgrade can be variable. That is pretty easy
>> to implement too.
>>
>> Regards,
>>
>> John (VK2ETA)
>>
>> On Fri, Aug 12, 2011 at 6:12 PM, Rein Couperus <rein@xxxxxxxxxxxx> wrote:
>>
>>> The mode table in pskmail contains PSK, MFSK and THOR modes.
>>>
>>> I have been able to monitor quite a number of qso's during the last few
>>> days,
>>> and it becomes clear there is a problem with MFSK.
>>>
>>> The effect is that when the mode is degraded from PSK250R to MFSK32,
>>> one of the stations (server or client) clearly does not decode the MSK32
>>> signal,
>>> and after a few retries the mode falls through to THOR22.
>>>
>>> After the link gets better (pactor qso on top of the connect finished),
>>> the server tries to
>>> upgrade to MFSK32 again, but that does not succeed, so the server stays
>>> in THOR22.
>>>
>>> After seeing this also on my own connects, I did some tests, and it
>>> turns
>>> out that most of the time the slight frequency difference between server
>>> and client
>>> is probably the cause. The same happens with MFSK16 and THOR8...
>>>
>>> I am thinking about removing the MFSK modes from the table. That
>>> is a pity, because the MFSK modes are the most sensitive... but that
>>> does not bring any advantage if the smallest frequency difference defeats
>>> it.
>>>
>>> Question:
>>> * Did you also see this effect?
>>> * Would you be in favour of dropping the MFSK modes?
>>>
>>> 73,
>>>
>>> Rein PA0R
>>>
>>> --
>>> http://pa0r.blogspirit.com
>>>
>>
>>
>
Other related posts:
