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 THATTHE TXID IS NOT HEARD FROM THE CLIENT THE SERVER WILL NOT RESPOND IT CANTIF HOWEVER THE SERVERS ARE SET TO THOR 8 AS DEFAULT THEN IF CONDITIONS AREBETTER AND THE CLIENT SENDS A CONNECTION REQUEST AT A FAST MODE THE SERVER WILL RESPOND TO THE CONNECTION REQUESTFASTER IS NOT ALWAYS BETTER I WOULD THINK SERVERS SET TO DEFAULT AT THOR 8WOULD SERVE ALL IN THE BESTCAPACITY ESP WHEN YOU ARE OUT OF PORT WHEN YOUR SIGNAL MIGHT BE DEGRADED BUTSTABLE OR IF FOR SOME REASON YOU WERE REQUIRED TO USE LOW POWER OUT DAVID KF4WBS / NNN0LESTHIS GOES FOR BEACONS AS WELL IF YOU ARE SENDING A BEACON AND THE SERVERDOESN'T HEAR YOUAT THOR 22 AND CONDITIONS ARE NOT GOOD IT YOU SEND A BEACON AT THOR 8 ITSTILL WONT HEAR YOUBECAUSE IT CANT HEAR THE TXID HOWEVER IF IT IS PRESET TO THOR 8 AND YOUSEND 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 connectingDate: 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 theIgate 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 jPSKmailwill 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 @ PJ4CThanks for all your help, will report my progress. 73, DL3ZFC