Hi all, actually fldigi sends a 0x06 at the end of each transmission, which is recognized by the modem driver.
When msgsnd writes the message to fldigi (BTW, the server still uses the POSIX SYS V queue) a flag is set in the .pskmail directory. On receipt of the 0x06 this flag (.tx.lck) is removed. So in principle the exchange with fldigi is mutex based. I think 2 things should happen: * check what is the reason why fldigi stops the queue, this should not happen * check if the mutex handling works as required, pskmail should wait before sending the next frame. I will take a look at the second one. As I am only using PSK250 it has not happened on PI4TUE. 73, Rein PA0R (follow 'pskmail' on twitter...) > -----Urspr?ngliche Nachricht----- > Von: "John Douyere" <vk2eta at gmail.com> > Gesendet: 08.09.09 02:22:28 > An: fldigi-alpha at lists.berlios.de > Betreff: Pskmail TX lock-up with 3.13AE (in fact since 3.10) 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) > > _______________________________________________ fldigi-alpha mailing > list fldigi-alpha at lists.berlios.de https://lists.berlios.de/mailman/ > > listinfo/fldigi-alpha -- http://pa0r.blogspirit.com
