Topics

[winfldigi] FLMSG ARQ

Dave
 

See original report on flmsg arq behavior (below).

The 8PSK250F mode was designed for fast turn around VHF/UHF SSB transmissions.  My guess is that the HF transceivers were introducing additional delays.  Here is the algorithm used to compute the retry time:

// link layer spec for flmsg_arq
//
// generic Frame format:
// \x01bMYCALL~URCALL~[info])12EF\x04
//   | |  |      |       |    |   |
//   | |  |      |       |    |   +--ASCII <ARQ_EOF> (0x04) character
//   | |  |      |       |    +------checksum (4xAlphaNum)
//   | |  |      |       +-----------Payload
//   | |  |      +-------------------Your callsign
//   | |  +--------------------------My callsign
//   | +-----------------------------Block type
//   +-------------------------------ASCII <ARQ_SOF> (0x01) character
// callsigns max of 12 characters each
// payload size, 16, 32, 64, 128, or 256 characters
// frame overhead = 7

// connect string

    string nomFrame = "\x01AKA1CAL/2~KA1CAL/2~BBBBBBBBBBBBBBBB1234\x04";

// compute time to transmit in seconds
    float response_delay = transmit_time(nomFrame);


    if (response_delay < 5.0) response_delay = 5.0;

    response_delay *= 1000.0; // in milliseconds
    response_delay *= (1.0 + (0.5 * rand() / RAND_MAX));
    int idelay = floorf(response_delay/ ARQLOOPTIME);

The retry interval is always 5 seconds or more, depending on the modem in use (transmit_time).  The interval is then multiplied by a randome multiplier between 1.0 and 1.5.

The flmsg event log should contain event lines similar to "Wait 6.85 sec's before retry"

There is no user configurable item to add a fixed delay to the retry interval.  It would not be difficult to add.

73, David, W1HKJ

On 6/28/20 7:57 AM, Mark Erbaugh wrote:
Tonight I had a change to try FLMSG ARQ locally on 80m. We were using 8PSK250F. The path was very good - we were able to send a message via AutoSend with no errors. The problem with FLMSG ARQ was that when one station sent a CONREQ, the other station responded at the same time that the originating station was sending the next CONREQ, so it never heard the response. We couldn't find any parameter to increase the delay between repeats.