[pskmail] Re: Java client on Linux and Windows
- From: Rein Couperus <rein@xxxxxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Fri, 13 Mar 2009 17:07:34 +0100
> 3. findu
> I don't know if I missed that when I made it or if its removed by
> accident or if Rein has a better plan there (he worked with the server
> update just now). I'll check that.
>
I removed it on purpose, it was a relict from the days when pskmail had only
conected mode :)
> Regarding the thor mode and that bug I have not experienced that, quite
> possibly because I only do psk250. I'll leave that one for Rein :-)
>
I had no time to test it yet... the code is in arq.pm on the server. I am
fighting a
bug which prevents uploading large mails at the moment...
> > 1. Since the client is always manned I really like the connect
> > principle at the moment where the connects requests are generated
> > manually instead of automatically at set intervals. The human ear
> > and/or fldigi waterfall are much better instruments to decide if a
> > connect request needs to be sent again or not. I am not sure how to
> > reconcile that with the Mail/scanning option, maybe by sending only
> > the first connect and letting the operator do the repeats if
> > necessary.
My idea is to let the operator start the connect with the button, and the
client waits
until the right minute has come.... that way you can do something else for up
to 4 minutes :)
> > One question though: on this new client what is the usage and impact
> > of the DCD number? Is that seconds delay after last character received
> > before transmitting?
The java client uses an improved DCD. The figure is seconds after the last
character received.
(also characters produced by noise or other modes). A pskmail <EOT> character
resets DCD
immediately. You now have a new DCD indicator... grey = listening, yellow means
DCD on,
blue = receiving pskmail block, red = transmitting.
> >
> > Server side: One issue that I noticed with my home server in the past
> > and have reproduced on Steve's server today (with both the old client
> > and the new one): when we use the THOR mode, the server will sometimes
> > just ignore any block received by Fldigi although the block is formed
> > properly. When this occurs, the server will then ignore any new block
> > received in any mode and needs a restart. We never see that with the
> > PSK modes. This could be due to the encapsulation of the pskmail block
> > with the <stx> and <eot>: is the <stx> creating an issue with the
> > beginning of the block or are the two side by side <eot> at teh end
> > basically interpreted as an empty block?
This is possibly a timing issue caused by CPU load. Two EOT or SOH blocks
should be interpreted as empty, and are certainly not valid so they get thrown
away.
> >
> > Although I am happy to do some debugging I am not sure where to look
> > for in the server code: rflinkserver.pl or arq.pm?
all low level protocol stuff is in qrq.pm. I am deeply buried in there now :)
73,
Rein PA0R
--
http://pa0r.blogspirit.com
Other related posts:
