[pskmail] Re: Using MFSK modes
- From: John Douyere <vk2eta@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Tue, 16 Aug 2011 07:38:03 +1000
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:
