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 >>>> >>>> >>> >> >> >