reception of multiple frame sequence violated

[pe1rrr]

Hello
HF setup, speed ax300.

While testing the AGWPE connection to direwolf

I discovered that if a remote station is sending more than 1 frame (so if a remote station has a MAXFRAME of 3, for example) direwolf immediately transmits a frame over the top of the second incoming frame, apparently without checking DCD, causing it to miss the 2nd frame, it receives the third in the sequence but has to send a REJ to get the 2nd frame. This causing a bottleneck on HF during good conditions for mail forwarding etc.

If you need to know anything else, let me know.

[wb2osz]

Obviously, direwolf should not be transmitting when the channel is busy, i.e. when the DCD signal is active. More information is needed to figure out what is going on.
Using the "-do" command line option will display the changes in PTT and DCD signals. This will allow us to see if it is actually starting to transmit when DCD is still active.
What are the end applications being used? Is this using the AX.25 link layer processing inside direwolf or is direwolf being used as only a KISS TNC? What version?
Seeing everything that goes by, on the screen (along with the -do option), would be very helpful.

[pe1rrr]

Hello.

Since there is no gap between frames in the transmission, I presume the DCD should be picking up the tones just fine- but below is a capture demonstrating direwolf transmitting over the top of an incoming frame, this is greatly reproducible (which is a good thing for a bug).

I mentioned this is connected to an application via AGWPE port, in this instance direwolf is being used as a TNC. The application is is talking to is linbpq, and I have tested this setup with an alternative TNC which performs normally. AX25 v2.0 is forced.

This is with version 1.6 D

[0.1] PE1RRR-3>PE1RRR-2:(UA res, f=1)
Stream 0: Connected to PE1RRR-3. (v2.0)
CON 0 = 1

PE1RRR-3 audio level = 22(11/11) 000
[0.1] PE1RRR-3>PE1RRR-2:(I cmd, n(s)=0, n(r)=0, p=1, pid=0xf0)RIJEN:PE1RRR-7} Connected to BBS<0x0d>
DCD 0 = 0
PTT 0 = 1
[0L] PE1RRR-2>PE1RRR-3:(RR res, n(r)=1, f=1)
DCD 0 = 1
DCD 0 = 0

PE1RRR-2 audio level = 1(3/3) 000
[0.1] PE1RRR-2>PE1RRR-3:(RR res, n(r)=1, f=1)
PTT 0 = 0
DCD 0 = 1

PE1RRR-3 audio level = 21(11/11) 11
[0.1] PE1RRR-3>PE1RRR-2:(I cmd, n(s)=1, n(r)=0, p=0, pid=0xf0)[BPQ-6.0.20.9-B2FWIHJM$]<0x0d>.....................<0x0d>.|/|../...|..|__).|._/. <0x0d>.|..|./~~..|..|...
DCD 0 = 0
PTT 0 = 1
[0L] PE1RRR-2>PE1RRR-3:(RR res, n(r)=2, f=0)
DCD 0 = 1
PTT 0 = 0
DCD 0 = 0
DCD 0 = 1
DCD 0 = 0
DCD 0 = 1

PE1RRR-3 audio level = 22(11/11) 000
[0.1] PE1RRR-3>PE1RRR-2:(I cmd, n(s)=3, n(r)=0, p=1, pid=0xf0)test: #9815 <0x0d> active: 2418<0x0d> last read: #9573<0x0d>--0 new/3 old msgs--matrix--><0x0d>
DCD 0 = 0
PTT 0 = 1
[0L] PE1RRR-2>PE1RRR-3:(REJ res, n(r)=2, f=1)
DCD 0 = 1
PTT 0 = 0
DCD 0 = 0

PE1RRR-2 audio level = 5(7/7) |__
[0.0] PE1RRR-2>PE1RRR-3:(REJ res, n(r)=2, f=1)

I hope this helps, let me know if you need more.

Edit: I have just considered one extra variable which was FX25, I have had it enabled in all of these tests, I found that disabling it has linked the issue to tripping the DCD up (for lack of a better description). The DCD operates normally without FX25 enabled. Curious.

[pe1rrr]

In case the above edit was missed: I have just considered one extra variable which was FX25, I have had it enabled in all of these tests, I found that disabling it has linked the issue to tripping the DCD up (for lack of a better description). The DCD operates normally without FX25 enabled.

It seems the FX25 preamble isn't being detected by the DCD which means direwolf is keying over the following packet. Can you confirm?

[wb2osz]

Good catch!
I believe your explanation is correct but I have not yet tried to reproduce this behavior.
A couple of the correlation tags have eight "1" bits in a row, something that can never happen with normal AX.25. This could cause DCD to be dropped.
Using "-X 64" (rather than 16 or 32) might be a temporary workaround.
The tags used don't have that many "1" bits in a row.

[wb2osz]

A new Data Carrier Detect (DCD) technique has been developed.
Let me know if it solves your problem.

commit 0661e23

[pe1rrr]

You will be really pleased to know you have fixed the issue. Checked and tested!

[wb2osz]

Issue fixed and verified about a month ago. Closing.