[pskmail] Re: Trouble connecting

  • From: John Douyere <vk2eta@xxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Fri, 20 Jan 2012 12:53:34 +1100

Both sides.

Regards,

John

On Fri, Jan 20, 2012 at 12:49 PM, DAVID GRAY <kf4wbs@xxxxxxxxxxx> wrote:
> THIS IS ON THE SERVER SIDE ?
>
> DAVID
>
> --------------------------------------------------
> From: "John Douyere" <vk2eta@xxxxxxxxx>
> Sent: Thursday, January 19, 2012 20:46
>
> To: <pskmail@xxxxxxxxxxxxx>
> Subject: [pskmail] Re: Trouble connecting
>
>> 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: