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@xxxxxxxxx>
Gesendet: 08.09.09 02:22:28
An: fldigi-alpha@xxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxx https://lists.berlios.de/mailman/
listinfo/fldigi-alpha
