Dave, Rein and team, After a fair amount of testing with 3.13AE and a new version of the PSKMail server to be released are a few comments and requests:
1. RSID enables some pretty powerful modes to be used effectively. In the past using MFSK16 was notably difficult since tuning is so critical. The first part of the frame was often cut since the squelch would only rise as the AFC corrected the mis-tuning. Now with RSID it locks in strait away and decodes from the beginning with only a minimum lag. 2. When using RSID for a transmission, there seems to be little value in sending the post frame RSID since, if the pre-frame one didn't work, we missed the fame anyway. So I would propose either to remove the post-frame one when in "Server" mode or make it optional. 3. It seems that the initialisation from the PSKMail server disables RSID automatically (since it is always started after Fldigi), but the indicator on the main screen stays on. I have to disable and re-enable for RSID to work it seems. 4. We need to have RSID enabled automatically for auto restart of PSKMail. Two options in my opinion: Since RSID is now background there is no harm in leaving it in the last status it was and not disabling it automatically at Fldigi startup. Or we have a command in the arq_io section to enable RSID. We would then have an option within the PSKMail server to set RSID on or not at start up. 5. I noticed that while modes like PSK and MFSK get a full green squelch bar on reception, the Thor modes only produce a 1/2 bar at best (even at +20dB S/N ratio). This is an issue since when we switch modes, the low point of the squelch level need to be adjusted to avoid picking up QRM while still responding fast enough to avoid cutting the start of the frame. So if the THOR modes could produce a full bar as well that would be useful. 6. Back on the Fldigi lockup when overlapping TX: we corrected the overlapping transmissions from the server side, but I am still concerned that random issues would produce a locked modem. (I had one instance during last night testings where I could not trace the lockup to a known condition, but it behaved like a TX overlap lockup). So in my opinion, Fldigi should either, as discussed earlier, queue the request OR in fact simply ignore it since it is an abnormal situation. It is much better to miss a Tx frame (that's why we have the R in ARQ) than having a locked application that disables the whole system. Your comments are much appreciated. Thanks and regards, John -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/fldigi-alpha/attachments/20090909/b75936aa/attachment.html
