John,
when I said "there ae still some issues with version 0.5" I meant the effect you have found,
and I have been working on it yesterday.
When on the road last week I found that when using short packets (16 characters payload)
there were repeat cycles which could not be explained. The effect was not present when
using payloads of 32 or 64 characters, so there was obviously a timing problem. The repeats
also made the protocol engine shrink the payload to 8 characters, making the problem worse.
After some analysis during the last few days it turned out that the application did not have
enough time to accomodate the packets coming from the interface, and I made some
changes to arq.pm so the interface waits until the application in ready with the previous packet.
I can now send a testfile with 8-character payloads without repeats. Which also means
the payload length increases quickly to 64 characters because there are no faulty packets
anymore, making the problem less. :)
The new arq.pm files are in:
http://sharon.esrac.ele.tue.nl/pub/linux/ham/pskmail/snapshot/client and
http://sharon.esrac.ele.tue.nl/pub/linux/ham/pskmail/snapshot/server
(they are different for server and client at the moment).
Please let me know if the problem goes away.
73,
Rein PA0R
-----Ursprüngliche Nachricht-----
Von: pskmail@xxxxxxxxxxxxx
Gesendet: 19.10.07 03:29:29
An: pskmail@xxxxxxxxxxxxx
Betreff: [pskmail] PSK250 mode
Hello, I did some short distance tests yesterday using two rigs and low power
to ensure I had the setup correct for the server.
I am interested in your experience in the setup with PSK 250 as it seems to be
more sensitive than the slower modes which is logical. I implemented a new
command to change the speed (~SPEED250!) so that I could see the impact while
in the same session.
The average effective data rate of PSK250 for a binary file download I found to be around 14 cps, which is consistent whith the theoretical speed and the data transfered: jpeg file so very little compression and high proportion of non-lowercase characters.
But I noticed also that a number of times the client would repeat the same request several times before it was either finally recognized or dropped by the server. Funny enough, when I did the file download there didn't seem to be many repeats.
I unfortunately didn't record a detailed log of the data exchange. And by the
way, how do I do this? Is it with the degug flag in pskmailrc.pl and the log
option of fldigi?
But what was clear is that falling back to PSK125 or PSK63 the repeat
disappeared. So I need to do more test to see what is happening. But any
feedback or pointers in the mean time would be appreciated.
73s, John
