I will look at the SysV interface code in fldigi. John, you can set the duration of visibility on that popup announcement. The default of 15 seconds is a little long. Look on the Notifications dialog.
Stelios: Perhaps the notification box could be suppressed if the "Notifications Only" (ID tab) is not checked. Dave Rein Couperus wrote: > 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/fldigi-alpha/attachments/20090908/a46d8a2d/attachment.html
