Topics

ARQ transition from FEC


Mitch Winkle
 

If I have the modem in PROTOCOLMODE FEC and an ARQ call for me comes in and I have LISTEN = TRUE set, is it supposed to switch automatically to ARQ mode and answer the request?  I thought this was how the old version worked.  Now, in v2 I have to switch to ARQ mode in order to answer a connect request.

If this is normal, I am not really finding a unique set of states that point to an ARQ request coming in.  All that's shown is PENDING, but that is shared with PING which does not need ARQ to function.

What am I missing here?

CMD RESPONSE: "NEWSTATE DISC\r"

CMD RESPONSE: "INITIALIZE\rPROTOCOLMODE NOW FEC\r"

CMD RESPONSE: "ENABLEPINGACK NOW TRUE\rLISTEN NOW TRUE\r"

CMD RESPONSE: "FECMODE NOW 4PSK.200.100\r"

CMD RESPONSE: "BUSY TRUE\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

 

CMD RESPONSE: "BUSY FALSE\r"


John G8BPQ
 

ARDOP will only answer a connect request while in ARQ Mode.

If you hear a connect request (to any station) you should see a message of the form [ConReq2500 >  G8XXX] on the data socket with a tag of "ARQ". You could check if it is addressed to you and switch to ARQ mode. This is sent in FEC mode, or in ARQ mode if the connect request is not to you or is rejected.

73, John G8BPQ




On 12/05/2018 19:26, Mitch Winkle wrote:

If I have the modem in PROTOCOLMODE FEC and an ARQ call for me comes in and I have LISTEN = TRUE set, is it supposed to switch automatically to ARQ mode and answer the request?  I thought this was how the old version worked.  Now, in v2 I have to switch to ARQ mode in order to answer a connect request.

If this is normal, I am not really finding a unique set of states that point to an ARQ request coming in.  All that's shown is PENDING, but that is shared with PING which does not need ARQ to function.

What am I missing here?

CMD RESPONSE: "NEWSTATE DISC\r"

CMD RESPONSE: "INITIALIZE\rPROTOCOLMODE NOW FEC\r"

CMD RESPONSE: "ENABLEPINGACK NOW TRUE\rLISTEN NOW TRUE\r"

CMD RESPONSE: "FECMODE NOW 4PSK.200.100\r"

CMD RESPONSE: "BUSY TRUE\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

 

CMD RESPONSE: "BUSY FALSE\r"



Mitch Winkle
 

I just use the native TNC commands on the command socket.  I am switching to arq on any PENDING, then if I hear PING... I switch back.  Hokey but it works.


On Sat, 12 May 2018, 16:43 John Wiseman, <john.wiseman@...> wrote:

ARDOP will only answer a connect request while in ARQ Mode.

If you hear a connect request (to any station) you should see a message of the form [ConReq2500 >  G8XXX] on the data socket with a tag of "ARQ". You could check if it is addressed to you and switch to ARQ mode. This is sent in FEC mode, or in ARQ mode if the connect request is not to you or is rejected.

73, John G8BPQ




On 12/05/2018 19:26, Mitch Winkle wrote:

If I have the modem in PROTOCOLMODE FEC and an ARQ call for me comes in and I have LISTEN = TRUE set, is it supposed to switch automatically to ARQ mode and answer the request?  I thought this was how the old version worked.  Now, in v2 I have to switch to ARQ mode in order to answer a connect request.

If this is normal, I am not really finding a unique set of states that point to an ARQ request coming in.  All that's shown is PENDING, but that is shared with PING which does not need ARQ to function.

What am I missing here?

CMD RESPONSE: "NEWSTATE DISC\r"

CMD RESPONSE: "INITIALIZE\rPROTOCOLMODE NOW FEC\r"

CMD RESPONSE: "ENABLEPINGACK NOW TRUE\rLISTEN NOW TRUE\r"

CMD RESPONSE: "FECMODE NOW 4PSK.200.100\r"

CMD RESPONSE: "BUSY TRUE\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

 

CMD RESPONSE: "BUSY FALSE\r"



Mitch Winkle
 

Ah I see what is going on here.  I was already doing as you suggested John.  Apparently the text has just changed.  Oy!


On Sat, 12 May 2018, 16:43 John Wiseman, <john.wiseman@...> wrote:

ARDOP will only answer a connect request while in ARQ Mode.

If you hear a connect request (to any station) you should see a message of the form [ConReq2500 >  G8XXX] on the data socket with a tag of "ARQ". You could check if it is addressed to you and switch to ARQ mode. This is sent in FEC mode, or in ARQ mode if the connect request is not to you or is rejected.

73, John G8BPQ




On 12/05/2018 19:26, Mitch Winkle wrote:

If I have the modem in PROTOCOLMODE FEC and an ARQ call for me comes in and I have LISTEN = TRUE set, is it supposed to switch automatically to ARQ mode and answer the request?  I thought this was how the old version worked.  Now, in v2 I have to switch to ARQ mode in order to answer a connect request.

If this is normal, I am not really finding a unique set of states that point to an ARQ request coming in.  All that's shown is PENDING, but that is shared with PING which does not need ARQ to function.

What am I missing here?

CMD RESPONSE: "NEWSTATE DISC\r"

CMD RESPONSE: "INITIALIZE\rPROTOCOLMODE NOW FEC\r"

CMD RESPONSE: "ENABLEPINGACK NOW TRUE\rLISTEN NOW TRUE\r"

CMD RESPONSE: "FECMODE NOW 4PSK.200.100\r"

CMD RESPONSE: "BUSY TRUE\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

 

CMD RESPONSE: "BUSY FALSE\r"



John G8BPQ
 

Unfortunately the text had to change as the V2 ConReq only has the called callsign, not the calling call. This is supplied on the ID frame which is sent following the receipt of a ConAck.

73, John


On 12/05/2018 22:10, Mitch Winkle wrote:
Ah I see what is going on here.  I was already doing as you suggested John.  Apparently the text has just changed.  Oy!

On Sat, 12 May 2018, 16:43 John Wiseman, <john.wiseman@...> wrote:

ARDOP will only answer a connect request while in ARQ Mode.

If you hear a connect request (to any station) you should see a message of the form [ConReq2500 >  G8XXX] on the data socket with a tag of "ARQ". You could check if it is addressed to you and switch to ARQ mode. This is sent in FEC mode, or in ARQ mode if the connect request is not to you or is rejected.

73, John G8BPQ




On 12/05/2018 19:26, Mitch Winkle wrote:

If I have the modem in PROTOCOLMODE FEC and an ARQ call for me comes in and I have LISTEN = TRUE set, is it supposed to switch automatically to ARQ mode and answer the request?  I thought this was how the old version worked.  Now, in v2 I have to switch to ARQ mode in order to answer a connect request.

If this is normal, I am not really finding a unique set of states that point to an ARQ request coming in.  All that's shown is PENDING, but that is shared with PING which does not need ARQ to function.

What am I missing here?

CMD RESPONSE: "NEWSTATE DISC\r"

CMD RESPONSE: "INITIALIZE\rPROTOCOLMODE NOW FEC\r"

CMD RESPONSE: "ENABLEPINGACK NOW TRUE\rLISTEN NOW TRUE\r"

CMD RESPONSE: "FECMODE NOW 4PSK.200.100\r"

CMD RESPONSE: "BUSY TRUE\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

CMD RESPONSE: "PENDING\r"

 

CMD RESPONSE: "BUSY FALSE\r"




Mitch Winkle
 

I was previously keying on "#ARQ" which no longer exists.  This has forced me to go through all of this handling code and get it right, so no worries!  I will have to go dig this out of the new docs.  This was the only thing in my v1 code that did not work reliably.  When you put a piece of code down for 5 months at a time, you forget things.

What is probably throwing me is to find indications on the data port.  In the hardware modems that I work with all indications are on the control port and only raw data is on the data port.  The exception are modems (RapidM) which allow data on the remote control port wrapped in their control protocol.  In any case, indications are always on the control port.

Thanks for the leg up once again John, as always!

Mitch, AB4MW


John G8BPQ
 

Yes, this is a bit of an anomaly, but that message is intended as monitoring info for the user (like ID frames) not for processing by software, so it sent on the data channel. But not using things as intended by the designer is part of the ham tradition!

73, John



On 13/05/2018 12:23, Mitch Winkle wrote:
I was previously keying on "#ARQ" which no longer exists.  This has forced me to go through all of this handling code and get it right, so no worries!  I will have to go dig this out of the new docs.  This was the only thing in my v1 code that did not work reliably.  When you put a piece of code down for 5 months at a time, you forget things.

What is probably throwing me is to find indications on the data port.  In the hardware modems that I work with all indications are on the control port and only raw data is on the data port.  The exception are modems (RapidM) which allow data on the remote control port wrapped in their control protocol.  In any case, indications are always on the control port.

Thanks for the leg up once again John, as always!

Mitch, AB4MW