Hi All, First let me say that the new feature of background RSID is a great addition for the ARQ scene as it allows to connect in (more or less) any mode depending on the conditions. More on the tests below.
But for the lockup issue: I have done more tests to identify the issue I highlighted some months ago where Fldigi would lockup and stop transmitting at connect or seemingly at random while used with the Server of PSKmail. The problem (very repeatable now that I know what to look for) occurs when Fldigi is currently sending a frame and another frame is being submitted by the server before the end of the transmission. This also explains why lockups would be far more common on slow(er) modes like THOR22, uncommon with PSK125 and rare with PSK250 since the chances of frames overlaps is greater as the transmission time extends. It also explains why the server would stop responding at seemingly random times. In fact this occurs when there is a timeout condition in the server and a poll frame is sent to Fldigi while a normal status frame is being currently transmitted. I believe has been experienced by other PSKMail server operators too (in particular VK2ZSZ with whom I did a number of tests). Restarting Fldigi clears the issue until another frame overlap occurs. Restarting the server only does not resolve the problem. This issue appeared at the transition between Fldigi 3.03 to 3.10. In other words, version 3.03 does not exhibit this issue. Please note that this occurs with pre-compiled binaries as well as when recompiling from source. Current operating environment: Ubuntu 8.04 (up to date), PSKMail server 0.9.1 (but issue present on older versions too), Fldigi 13AE (compiled from source). Correcting this problem in the server by adding delays partially solve the problem but it is still unreliable since the server has no knowledge of the transmission status of Fldigi. Therefore the effective behaviour is for Fldigi to queue the frames for transmission. Just for information, slower more robust modes are essential as our tests have demonstrated here in VK: large distances, land mobile operations (and therefore compromise antennas and constantly changing earth and orientation of the car means significant and rapid QSB). We have had great success with the THOR and MFSK modes on 40 and 80M while mobile, but this issue issue is really a show stopper. Please let me know how I can help more. My knowledge would probably extend to setting up a debugging environment and tracing the code in Fldigi. So far I have traced the Perl code on the server side and I can confirm that the frames are being sent to fldigi via the msgsnd function but Fldigi does not respond to what is being received. If required I could setup a small Perl script to emulate the issue. Now back on the background RSID: I have successfully tried that new option with the PSKMail server. This allows us to scan different frequencies independently of the mode used for the exchange. Brilliant. The only small issue is that even if the option "only provide notification" in the RSID tab is unticked, I still get a notification pop-up window which is redundant since the change of mode and frequency adjustment has already occurred. Please keep up the great work. Thanks and regards, John (VK2ETA) -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/fldigi-alpha/attachments/20090908/34350e70/attachment-0001.html
