[pskmail] Re: Various subjects
- From: John Douyere <vk2eta@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Thu, 7 Jan 2010 13:10:22 +1100
Hi Rein,
Great regarding the link request.
Regarding the client's frame size I propose we leave that as is:
controlled by the block size data we put in the preferences, but have
a separate variable for the mode combination.
Regarding the other modes combination, nothing prevents us to have
mode than 10 options since this character we send at connect time can
be alphanumeric and we can have A,B,C etc... for other modes
combination.
With auto frame size and auto speed on the server there is no need to
send a frame size from the server anymore.
Here are the extra combinations I put for my server in replacement of
some of yours at the moment: PSK125/PSK125R, THOR22/THOR11,
THOR11/THOR8 then finally, but not tested: PSK125R/PSK63F.
On the asymmetric linkup, yes I agree that more RSID is not a good
thing, especially with the current level of sensitivity compared to
the more robust modes like THOR.
So your idea of fixed combination (TX/RX modes) is the right one at
this point in time in my opinion, rather than letting the client
decide on the mode based on link quality like the server does.
Here is one option:
1. Have an option on the client for asymmetric linkup. This triggers
an offset in the mode combination sent (say +20). So if we choose
combination 9 on the client, we send 29 to the server at connect time.
2. The combinations therefore have three modes: hi speed TX, Low speed
TX and RX (from the server's perspective).
3. The server and client then switch modes depending on RX and TX
4. The client need to know which mode it received last (before TXing)
since it needs to switch back to that mode after TX. This may need
some development. We could use the "notification" function of Fldigi
which is already there and is triggered by an RSID decode.
Regarding the difference in modes let's look at the "cost" of ONE
missed status frame: Timeout + TX of RSID + TX of status request from
server. The time for "TX delay of client + RX of client's status"
would be there regardless of the missed frame or not so it is excluded
from the additional time lost.
With timeout being larger than: (blocklength + 9 characters) * 2.5 + 6
seconds and the status frame being 12 characters minimum, there is a
large penalty for missing a status frame from the client. So I think
downgrading by even two the CPS speed of the client TX would still
provide a time gain, and especially if the server's data keeps coming
at the higher speed.
So we could have for example (High/Low/RX): PSK500,/PSK500R/PSK250R,
PSK500R/PSK250R/PSK125R, THOR22/THOR11/THOR8.
Since I suspect the majority of times we receive more data than we
transmit, this scheme would offer a real gain in the time utilization
of a "Pskmail channel" on top of delivering a more robust linkup (less
dropouts).
What do you think?
On the PSK500 squelch issue, yes I have seen that and I strongly
suspect this is because we update the squelch value much more often
than for the slower mode. Let me have a look at this and the
notification option as discussed above.
Regards,
John
On Wed, Jan 6, 2010 at 7:32 PM, Rein Couperus <rein@xxxxxxxxxxxx> wrote:
> Hi John, comments see below...
>
>> Happy New Year to all.
>>
>> I was away for a while and discovered a lot of activity on the list.
>> Great to see the Windows end of line issue resolved.
>>
>> I also tried the new auto speed features with 9.29 server and 0.4.0.2
>> client while away camping.
>>
>> First: Per, regarding the initial link request I personnaly don't find
>> it useful, especially since the autolink option (which is great) will
>> request a link at a later stage.
>
> I have already removed the initial link request... maybe we should
> store the 'autolink flag' which is default on at the moment, so
> off remains off at new start.
>>
>> When I get the Pskmail client going, it is generally with a specific
>> task in mind and the initial link request is an annoyance in this
>> case. But it depends on the patterns of use of course.
>>
>> Regarding the auto speed system of the server a few comments from my tests:
>>
>> 1. When I choose the mode combination in the preferences (block size
>> variable) it seems to also affect the client's block size which is an
>> issue. Maybe now is the time to separate the two. Otherwise I got
>> emails sent with 256 bytes block sizes: there were quite a few repeats
>> to get these blocks through..hihi
>
> I will fix the client block size to 32 chars.
>
>>
>> 2. The PSKR modes, as per Rein's observations, are effective for NVIS
>> conditions too (300Km, 80M, morning and day time, static crashed in
>> abundance) and seem to handle the resulting phase distortions and
>> selective fading quite well. Not as good a Thor from my observations,
>> but still very effective.
>>
>> 3. I had to modify the server to get access to slower Thor modes for
>> the evening. Rein, can we have a table in the pskmailrc.pl file so
>> that we can configure the mode combination? Different situations mean
>> different needs.
>
> yes, I will do that, the client can then switch it with mode profile 0
> (server default).
>
> I am also thinking about allowing the client to send a custom profile to
> the server after linkup. Moreover, if you have a mode pair you need
> often, the mode table can still be changed...
>
>>
>> 4. I wished I had an asymmetric mode link-up: I could hear the server
>> better that it could hear me, resulting in speed downgrading which was
>> only necessary for the client status frames to be received properly.
>> The data from the server could have stayed at maximum speed. The
>> penalty was at least a factor a 4 in speed (PSK500R could have been
>> used instead of PSK125R). In my case where I regularly download web
>> pages for bush fire alerts and weather forecasts this would be great.
>>
>
> I will think about it... I am a bit worried about the amount of RSID'ing it
> would take, maybe I should think about fixed, but different speeds?
> Is a combination of PSK500R-PSK125R ok as a starting point?
> Needs some experimenting...
>
>> 5. Agree that RSID needs improvement in reliability.
>>
>
> I now have an issue with PSK500 decoding. PSK500 needs a preamble of
> 'XXXXXX' to decode the start of a packet. I see the squelch bar dive down to
> zero and then build up when the packet starts.... After going through fldigi
> code for 8 hours
> I have found no difference so I wonder if somebody else sees this.
>
>
>
> 73,
>
> Rein PA0R
>
>
>
Other related posts:
