Klaus,
regarding the "no mail" error, can you check the number of the POP port?
Many mail providers have stopped using port 110, and I had to change
the port for web.de to 995 using SSL and TLS, as they stopped the
normal service.
Maybe we have to change the default POP service to SSL/TLS?
Pse look at the get_count routine on the server (arq.pm)...
Rein PA0R
--
*Gesendet:* Samstag, 17. Mai 2014 um 10:49 Uhr
*Von:* "Klaus Lohmann" <dl4oah@xxxxxxxxxx>
*An:* pskmail@xxxxxxxxxxxxx
*Betreff:* [pskmail] Re: Aw: Re: Server update to 2.2.1
Hello Rein,
change of offsetfrequency from 1000 Hz to 1500 Hz (Icom, Elecraft K3)
did not work in 1.5.29. Committed the fix to 1.5.30. SVN should take
care of it when you move to 1.6.0. So this info is only given to make
shure nothing gets lost.
Semething else:
Server always tells me "... no mail ..."
When I try the perl routine below, always get a count of -1.
Thunderbird email client on the same machine and same settings works fine.
Any idea?
Thank you and 73, Klaus DL4OAH
#!/usr/bin/perl
use Mail::POP3Client;
$pop = new Mail::POP3Client( USER => "pop3@xxxxxxxxxx",
PASSWORD => "mypassword",
HOST => "pop3.strato.de",
USESSL => true );
$a = $pop->Count(); # Number of messages
print "Count:".$a;
Am 17.05.2014 10:23, schrieb Rein Couperus:
I am still testing the matching client (1.6.0) ...
TXdelay is one of the items which has been fixed...
Rein PA0R
--
*Gesendet:* Freitag, 16. Mai 2014 um 21:10 Uhr
*Von:* "Franz Rohrauer" <franz.rohrauer@xxxxxx>
*An:* pskmail@xxxxxxxxxxxxx
*Betreff:* [pskmail] Re: Server update to 2.2.1
Rein,
thanks, server is updated
I tested timing using jpskmail 1.5.29 with fldigi 3.21.76. May be,
that following problem is solved in jpskmail 1.5.30, but I can't
test it (there is no installer available):
Parameter "TX delay" does not delay TX really! So client's
transmitter sends data, before server's RX is ready. Check-sum
becomes incorrect and a lot of time is spent for handshaking...
73 de
Franz, oe5rtl
Am 2014-05-16 10:22, schrieb Rein Couperus:
It is now 6 months since the last server maintenance release,
and time
to take another look...
We have seen some problems with timing on the server, and
there was also a quirk
in the ~QUIT routine, which made a clean disconnect difficult.
I have been testing the 2.1.n server extensively from my remote
winter location which has a very high noise level (mainly free
running
switching power supplies, well kown on large camp sites and in
harbours...).
My tests show that the PSK (and PSKxxxR) modes don't work
well in
harsh surroundings. MFSK modes, especially MFSK16 and THOR22 did
a lot better when the going got really rough. The main
drawbacks for these
modes are rather long latency and critical tuning.
This triggered a number of tests with DOMINOEX, which does not
have these
problems, and as a bonus it has 2x the speed of the FEC modes.
Tests show
it works very well. I plan to include DOMINOEX22 and
DOMINOEX11 in the next
client release for the version 1 client (the V2 client has no
DominoEx mode yet),
and introduce MEMORY ARQ to copy for the lack of FEC.
Meanwhile, I would propose to update all servers to version
2.2.1, which
already includes mode handling for DominoEx (it generates no
error messages
when DomEx modes are used on frequency). It also fixes some
problems
regarding protocol timing and ~QUIT sequence.
The archive is
http://www.pskmail.org/downloads/pskmail_server_update-150514.tar.gz,
it contains new versions of arq.pm and rflinkserver.pl. Just
drop those into
/usr/local/share/pskmail_server and you are in business....
A new version 1 client including DomEx modes is being tested
at the moment.
A mode table of PSK500,PSK500R, DOMINOEX22,DOMINOX11,MFSK16
(or THOR22)
seems to work very well, momentarily I am adding some
intelligence regarding
the decoding of status frames....
73,
Rein PA0R
--
