[pskmail] Re: Trouble connecting
- From: John Douyere <vk2eta@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Fri, 20 Jan 2012 12:46:38 +1100
Hi David,
There is a solution in store and I have been testing it for a while
now to ensure no adverse effects.
I have seen the problem you mention a while back but never got round
to it until recently.
The way RSID is decoded currently only allows for a limited number of
errors (in fact one only) out of the heavily encoded frame that is
sent.
This is to avoid "false-positives", but in our application the lack of
decoding is a real issue for the slow modes that end-up having a much
higher sensitivity that RSID which, as you explained, defeats the
purpose.
In my tests RSID would decode with the same rate of errors with
signals between 3 to 5dBs above the ones needed for THOR8, THOR11 and
MFSK16.
So I have made changes for the RSID in my test version of Fldigi at
home and have been testing for a while now. I relaxed the decoding
requirements and I get down to the same level of sensitivity than
THOR8.
I get some rare false positives but most of them are with frequencies
far away from the listening frequency so we can easily eliminate those
based on the frequency difference anyway.
And if we do get one in a hundred or so false positives then we are
still much in front compared to the current situation.
So now what is left to do is to get the changes incorporated into
Fldigi if we agree this would be a plus. Of course that change would
apply only to Fldigi when used as a Pskmail modem.
Let me know if you want the code change to compile test.
Regards,
John
On Fri, Jan 20, 2012 at 12:30 PM, DAVID GRAY <kf4wbs@xxxxxxxxxxx> wrote:
> WHAT I SEE IS IF A SERVER DEFAULTS TO THOR 22 AND CONDITIONS ARE SUCH THAT
> THE TXID IS NOT
> HEARD FROM THE CLIENT THE SERVER WILL NOT RESPOND IT CANT
> IF HOWEVER THE SERVERS ARE SET TO THOR 8 AS DEFAULT THEN IF CONDITIONS ARE
> BETTER AND
> THE CLIENT SENDS A CONNECTION REQUEST AT A FAST MODE THE SERVER WILL
> RESPOND
> TO THE CONNECTION REQUEST
>
> FASTER IS NOT ALWAYS BETTER I WOULD THINK SERVERS SET TO DEFAULT AT THOR 8
> WOULD SERVE ALL IN THE BEST
> CAPACITY ESP WHEN YOU ARE OUT OF PORT WHEN YOUR SIGNAL MIGHT BE DEGRADED BUT
> STABLE OR IF FOR
> SOME REASON YOU WERE REQUIRED TO USE LOW POWER OUT
>
> DAVID KF4WBS / NNN0LES
>
> THIS GOES FOR BEACONS AS WELL IF YOU ARE SENDING A BEACON AND THE SERVER
> DOESN'T HEAR YOU
> AT THOR 22 AND CONDITIONS ARE NOT GOOD IT YOU SEND A BEACON AT THOR 8 IT
> STILL WONT HEAR YOU
> BECAUSE IT CANT HEAR THE TXID HOWEVER IF IT IS PRESET TO THOR 8 AND YOU
> SEND A BEACON WITH TXID
> AT PSK500 THE SERVER WILL STILL DECODE THE BEACON IF CONDITIONS ARE GOOD
>
> WHY EVEN INCLUDE THE SLOWER MODES IF YOU DO NOT INTEND TO USE THEM
>
>
> --------------------------------------------------
> From: "Christian Wagner" <wagnerschristian@xxxxxxxxx>
> Sent: Thursday, January 19, 2012 14:32
> To: <pskmail@xxxxxxxxxxxxx>
> Subject: [pskmail] Re: Trouble connecting
>
>>> Date: Thu, 19 Jan 2012 11:04:54 +1100
>>> Subject: [pskmail] Re: Trouble connecting
>>> From: John Douyere <vk2eta@xxxxxxxxx>
>>>
>>> Hi Christian,
>>>
>>> I will start with the end as it will put the other explanations in
>>> context:
>>>
>>> A. I would use a mode that does not care too much about frequency
>>> accuracy and does not use automatic frequency control like THOR22 or
>>> even THOR11. Since both these modes can be used by the European and
>>> North-American servers and they are very robust I think this is your
>>> best bet........<snip>
>>>
>> Thanks John, will try A, B and C tonight.
>>
>>
>>> Date: Thu, 19 Jan 2012 03:29:58 +0100 (CET)
>>> From: "Rein Couperus" <rein@xxxxxxxxxxxx>
>>> Subject: [pskmail] Re: Trouble connecting
>>>
>>> Christian,
>>> the network issue is probably caused by jPSkmail trying to connect to the
>>> Igate network.
>>> You can disable the network connection by going to the Igate screen and
>>> disselecting the
>>> Igate status ckeck button.
>>> If there is no network available (which is normal at sea), when jPSKmail
>>> will try to connect to the
>>> APRS server, the network socket will wait until the network socket is
>>> relinquished.
>>>
>>> This can take up to 3 minutes.... but jPSKmail will start after the
>>> network driver gves up...
>>> You will neee some patience!
>>>
>>> Buy try with the Igate disconnected first...
>>
>>
>> [pskmail] Re: Trouble connecting
>>
>> Ok, I think I wasn' very clear in my bugreport. Here it comes again:
>> The Problem is when I start fldigi- it can't create the arq server.
>> FLDIGI log:
>> Q: main: fldigi 3.21.30 log started on Thu Jan 19 14:19:26 2012
>>
>> Q: log_excluded_modes: RSID (tx) : CW BPSK31 RTTY
>> Q: log_excluded_modes: CWID : CW
>> Q: log_excluded_modes: VIDEOID : CW BPSK31 RTTY
>> I: testCommPorts: Found serial port /dev/ttyS0
>> I: testCommPorts: Found serial port /dev/ttyS1
>> I: testCommPorts: Found serial port /dev/ttyS2
>> I: testCommPorts: Found serial port /dev/ttyS3
>> E: open_tty: Could not open "/dev/ttyUSB0": Datei oder Verzeichnis
>> nicht gefunden
>> E: start: Could not start ARQ server (getaddrinfo: Die Adressfamilie
>> f?r Hostnamen wird nicht unterst?tzt)
>> E: start: Could not start XML-RPC server (getaddrinfo: Die
>> Adressfamilie f?r Hostnamen wird nicht unterst?tzt)
>> I: do_readfile: Reading 111 bytes from logbook.adif
>> I: do_readfile: NO RECORDS IN FILE
>>
>> So, jpskmail has nothing to do with it. It all happens before I start
>> jpskmail. Of course, If fldigi is in his state, jpskmail complains
>> about not beeing able to connect to the arq server (which just isn't
>> there).
>> The current workaround is tho create an ad-hoc network with the on
>> board wifi which somehow lets fldigi create a server. It seems to be
>> quite reliable.
>>
>>> Rein PJ4/PA0R @ PJ4C
>>>
>>
>> Thanks for all your help, will report my progress.
>> 73, DL3ZFC
>>
>>
>
Other related posts:
