Per, Franco, Also, I would look at the connect log information as it seems that the server did not go into asymmetric adaptative mode since Franco did not see any mode changes despite the poor s/n reports from his client. This happens when the RSID is not decoded by the server at connect time and therefore it assumes that it should stay on the currently unknown mode for the whole session. If that is the case, the number of reties would create a disconnect condition, which is a logical behaviour in my opinion, since it is better to reconnect and get mode changes to complete the tasks. I noticed that the protocol number is "0" and therefore does not use the DTN option as in the latest clients. Not that it would have helped for the header list, but it would for the email downloads. Regards, John On 1/7/11, John Douyere <vk2eta@xxxxxxxxx> wrote: > Hi, > > Looking at the log it seems that the link was not very strong > (propagation or QRM) since the signal repost from the client was an > "E" which is a bit less than 50% if I remember well. > > There is also evidence of a few repeats with the blocks 5 and 6 being > re-sent and the client also requesting block ":" for repeat. > > So I wonder what mode the server would have downgraded to. If it went > all the way to THOR8 there is a reduced numer of repeats since the > timeouts become very long. > > But I have also noticed at times of poor conditions some "earlier than > expected" disconnects too. Not major but annoying at times. > > Regards, > > John > > On 1/7/11, Pär Crusefalk <per@xxxxxxxxxxxx> wrote: >> Hi, >> >> Looking at the end of that log: >> >> RX (2011-01-06 12:24Z): iyfivdfrukd} t <SOH>i%s$4956FF80<EOT> >> RX (2011-01-06 12:24Z): darapTajaRaapoTaTTaT >> TX (2011-01-06 12:24Z): <US><SOH>0%5 Re: QSL for QSO on 20 m. >> 9570<SOH>0%6 1919 >> TX (2011-01-06 12:24Z): 15 FRANCISCO___JAVIER@telefonica. Re: QSL for >> QS7B8C<SOH>0%s:$$A569<EOT> >> TX (2011-01-06 12:24Z): - >> RX (2011-01-06 12:24Z): ivdio ff<BEL>i fhZh<SOH>E%s$99:845E<EOT> >> RX (2011-01-06 12:24Z): <DC3>aTaldaCT au >> TX (2011-01-06 12:24Z): <US><SOH>0%s:$$A569<EOT> >> TX (2011-01-06 12:24Z): -<US><SOH>0%d741B<EOT> >> TX (2011-01-06 12:24Z): -<US><SOH>0%d741B<EOT> >> TX (2011-01-06 12:24Z): - >> >> It does look somewhat cut off at the end there. Hard to say if it was >> correct to cut it there. >> What we can do is to try a live session. I can be by the server this >> weekend with a skype connection and we can see how it handles. Would >> that work for you? >> >> 73 de Per, sm0rwo >> >> >> >> tor 2011-01-06 klockan 19:44 +0100 skrev Franco Spinelli: >> >>> Il 06/01/2011 19:28, Rein Couperus ha scritto: >>> > Just updated mail headers from 185 to 215 on PI4TUE, this is >>> > using jPSKmail-0.8.6 and UBUNTU 10.04. So I cannot reproduce the >>> > problem. >>> >>> How can I do for debug my problem? In my installation this wrong >>> behavior is normal! I am upgrading .jar file from approx 7 months >>> without a new install. >>> Can be this the problem? >>> >>> > >>> > The retries are not cumulative, a good status resets Max-retries to 0. >>> > >>> >>> So in log of SM0RWO there is the answer to my disconnect? I was >>> downloading my mail headers! >>> >>> Regards >>> Franco Spinelli >>> IW2DHW >>> >> >> >> >> >