I'm answering my own questions! Problem solved for both versions. When I upgraded fldigi from 1.34 to 1.37p. I erased the .fldigi directory contents, per Rein's instruction. That also erased the RX ppm offset for my sound card. It is very inaccurate and I have to put in a -17000 ppm RX correction. With that back in, both 1.37p and 1.37S appear to work well. No more garbage data.
73, Fred wb5con Fred Reiselt wrote:
I went and got the fldigi alpha 1.37S source and compiled it. It seems to lock onto the incoming psk125 better, but the data decoded has errors a good bit of the time. I then went back and used the statically linked 1.37p that Rein provided. Now it is locking onto the psk125 better but also has errors decoding the data from the server, very similiar to 1.37S that I compiled. Don't know what I might have messed up. Perhaps building the libportaudio, libportaudiocpp, and libsndfile packages that are now required affected 1.37p?When I say it is locking onto the incoming psk125 better, I mean the phase on the polar chart is straight up and down now. Also the cursor on the waterfall is lining up over the signal, rather than off to one side. But the garbage in the data is puzzling.73, Fred Fred Reiselt wrote:Rein,I now have the 0.5.0alpha2 client running. I have checked mail,checked aprs messages, got the wwv forecast, and sent position. All that works. I like the status indicator at the bottom of the gui. So far, a lot fewer collisions between client and server.The AFC on the alpha fldigi is not working very well, as you have mentioned. I have narrowed the psk search window down to 10 Hz, which helped some. I turned the AFC off but it still was trying to track. The AFC seems to lock 90 degrees out of phase a lot, but still copies the server. The transmit and receive data both show up in the upper window in fldigi, nothing in the lower window. Not a problem, just a change.I have only tested it for about an hour but have no bugs to report, other than the AFC problem.Will test some more and hunt for gremlins. 73, Fred wb5con Rein Couperus wrote:On http://sharon.esrac.le.tue.nl/pub/linux/ham/pskmail/snapshot/client you find a new set of files which make up a test release of version 0.5.This release has alpha status. Main changes:* complete rewrite of the interface to fldigi, which now works with a SYSV message queue. That means you are not dealing with gmfsk_autofile and gMFSK.log anymore, which greatly simplifies installation. (You still have to install the perl modules though...).* software DCD. The client will not transmit when the squelch has been opened by another station running the pskmail protocol. At the moment this is only implemented in the client, I am waiting for a fully working version of fldigi to implement it on the server as well.* semi-synchronous polling. Polling is used to pick up a broken link. On an established link the protocol behaviour is asynchronous, which means the stations transmit in turn, answering as quickly as possible. If a link is broken through qrm or condx timing used to become fully random and there would be lots of collisions from stations polling at the same time. In version 0.5 the station starting the connection (master) is polling in seconds 0...4 and the slave is polling in seconds 5...9. This way the chance of picking up the link again is greatly enhanced. it will take max. 9 seconds extra before a poll is released, but if polling is necessary there is something wrong with the link anyway (a pactor station will need several minutes before it goes away).* RX/IDLE/TX indicator on the GUI.The signal capturing capabilty of fldigi is now so good that instead of using a long preamble (CALL) I am trying a 1-character preamble (<US>, ASCII 31) which will also trigger the software squelch.This stuff needs testing, let me know what you think... 73, Rein PA0R
