The Advanced NBEMS Software Suite

Part 4 - FLAMP Advanced Message Broadcast

Philosophy and Methodologies

SATERN, as an organization, strives to view message transfers with the mission; “Get the message through”. Along with that montra, comes the need to be accurate and reliable. The SSB net trains extensively to have participants recognize and handle messages properly.

There comes a point at which either the volume of messages, the conditions under which a message is transfered, and the experience of the operators involved determine the result.

To that end SATERN International Digital Net has chosen the NBEMS suite of software precisely to overcome most of those obsticles.

Operators on the Digital Net practice weekly, sending and receiving digital messages using different formats and different digital modes in order to gain the skills needed to be of service and to build in a system–wide reliability to SATERN Digital capability.

Often it is desired to broadcast a single message or group of messages to more than one than one station. This may be for training, or for reduncency to enhance the possibility of complete reception of a complete message in difficult circumstances.

NBEMS provides FLAMP for just this purpose.


FLAMP - Workflow in Receive Mode

The FLAMP Receive Tab

From the official FLAMP documentation:

FLAMP is a program for AMP or Amateur Multicast Protocol. An FLAMP session will transmit one or more files with one or more iterations of the transmission. Each file is broken into blocks, each of which has a check sum. The receiving station saves the blocks that pass check sum. Successive transmissions will fill in the missing blocks provided that the new blocks pass the check sum. After the transmission sequence, the entire file is assembled and may be saved. “Fills” may be provided by retransmitting the entire file or by the sending station only sending the missing blocks.

There are several distinct advantages to using FLAMP for file transfer. FLAMP is able to send different file types in the same group. It also allows for repeats of not only the complete file to be resent, but also repeats of header and data blocks as well… futher enhancing the possibility of complete reception with maximum efficiency.

With the ability to send large amounts of data to multiple stations, FLAMP eliminates the need to send the same data multiple times to multiple stations.

Again, from the FLAMP official documentation:

FLAMP divides a message file into blocks, each of which will be checked for errors when received. You can select the block size with the Blk size selector. The range is from 16 to 2048 in increments of 16.

FLAMP will repeat the transmission from 1 to 10 times with an option of repeating the header data independently. Select the appropriate number based on transmission mode (i.e. mode performance) and propagation conditions.

File identification is derived from multiple sources of information. These include date and time of the last file modification, compression, base encoding, and block size. Therefore, additional transmission sequences may be performed if necessary as long as these settings are not changed. If these settings are modified, FLAMP will treat the file as a new transmit queue item.

On the “Send to” line you may add any specific recipients for the file. The default is “QST” (general call to all amateur radio operators) which may not be appropriate in some countries.

To send a file, it has to be added to the queue. Click Add and then browse for the file or you can drag and drop the file from your desktop to the DnD icon (one or more files). FLAMP will handle any file format.

You have the option to compress the file with the Comp check box and select the level of encoding: base–64, base–128, or base–256. A warning dialog will be displayed if the compression is not selected and a file is added to the transmit queue that requires compression (images, all files with high bit set bytes, etc). Compression, base encoding, and description fields are a per file configurable item.

Note: In some circumstances depending on the contents of a file. FLAMP will automatically enable compression. Disabling compression on these files(s) may have unintended effects between FLAMP and FLDIGI. It is strongly suggested that compression remain enabled in these cases. The blocks line and Fetch button will be discussed later.

FLAMP provides some additional information. When you select the compression/no compression option and the mode you will see the file size, number of blocks and estimated transmission time. This is useful for determining trade offs in terms of mode, repeats, compression and block size. Please note that the file size is the total transfer size (in bytes) and includes the AMP protocol overhead.

Note: When Tx/Rx Interval is enables transmit time does not include the time between transmit periods.

When the file has been added to the Transmit Queue, you may add a file description in the Description line. This could be just a basic description of the file or have handling instructions. If sending just one file, you must highlight the file in the queue and press the ‘Xmit’ button to transmit. This will place the file name and description in the corresponding lines. If you have more than one file in the queue, you may transmit all of the files by clicking ‘Xmt All’. Highlighting is not necessary.

It was mentioned that the files sent are broken into blocks for transmission. This is much like the ARQ mode except that there is no ACK/NCK exchange here. Sent blocks are displayed at the receiving station as either received, or not, on the receive tab. Received block are displayed in blue, and nothing is displayed for blocks not received or received incorrectly.

All is not lost though. Stations with missing blocks have the ability to request only those blocks missed by clicking on the REPORT button. FLAMP sends a specially formatted message to the sender that indicates which blocks should be fetched and re-transmitted for that station. When those needed blocks are sent, FLAMP fills in the missing pieces to complete the message. This method vastly reduces the time needed to complete data file and text file transfer.

          N0BDY DE S0MCAL
          <PROG 18 E9CE>{0EE2}FLAMP 4.0.3
          <FILE 28 13C7>{0EE2}20130323070339:ad5xj-diginet-20171011.p2s
          <ID 41 EEBC>{0EE2}Weekly Test Message
          <SIZE 14 2F49>{0EE2}221 5 48
          <DESC 15 856E>{0EE2}Net information
          <DATA 56 B927>{0EE2:1}[b64:start]AUxaTUEAAAggXQAAAAQAEAxB/TEWllgk3J5mK
          <DATA 56 BAFA>{0EE2:2}pYEOyC+U2nmNwaGCVvFVmqBX/av7rhbtp4H4xoY39GsVdk5W
          <DATA 56 24A2>{0EE2:3}ZmH3Jm/CULrcdlB39rhWJUUCcE0jXPg1l3yWPIV2q4fQDgaz
          <DATA 56 87D0>{0EE2:4}FXD/IqYKt7x07GamZsVFZORzk/TLgX4vBXqTc86KGO7kCFhJ
          <DATA 37 8435>{0EE2:5}Wpmo3mbURumL0Xj8cIE[b64:end]
          <CNTL 10 8E8D>{0EE2:EOF}
          <CNTL 10 2E81>{0EE2:EOT}
          N0BDY DE S0MCAL K

In a previous article we mentioned that FLMSG injects formatting text into text messages sent. In the same way FLAMP will inject error detection tags into sent data text.

The text shown is of a partial transmission of data from FLAMP. Notice that it is not in readable form. That is because of the binary text compression by FLAMP. It should also be noted that each line is a block of data that is sent by FLAMP. The first few lines are identifiers. The next few lines are the message header info. And, the message ends with the EOF/EOT blocks. All of this is text. There is no raw binary data in this message. This method is to avoid the many problems encountered sending raw binary data between different digital modes. Not the least of which is loss of bit data where noise or fading causes data errors.

We have already mentioned the problems PSK modes have with binary data. Other modes as well would have different but critical problems if we try to send raw binary data with some digital modes. To avoid such problems and allow traceable error–correction, only 8–bit UTF–8 text is used in the visible character set. Non–visible binary control codes (like a CR or LF) are used but not shown.

When the file is received, FLAMP will decompress the data and provide the receiving station with a file to save or import to FLMSG. All training messages on the SATERN International Digital Net are encoded, formatted, and compressed. The received (and saved) file must be opened in FLMSG, and viewed there, in order to be able to see the document as created.

For instance, if a ICS–213 document is sent, the data received would look something like shown. However, once complete and saved only the text of the ICS–213 and the formatting markup tags remain. When the saved file is opened in FLMSG, and viewed as HTML with the browser, it will appear as a familiar ICS–213 document with no formatting tags visible. It can then be saved to a PDF file, saved and sent as an email attachment to a WinLINK or Internet message, or printed from your browser.

This process is built on the premise that each end of the message transfer (sending station and receiving station) is equipted with the NBEMS suite of software. Without it, the message has little guarantee of being error–free or viewable in the format created.


FLAMP - Configuration

The FLAMP Configuration Panel

FLAMP and FLDIGI have the capability to synchronize modes, i.e. you only have to set the mode on one or the other and the second will follow. This feature may also be disabled so that the mode being used with FLDIGI at a given moment can be independent of the mode being used for FLAMP file transfers.

On the Configure screen, note the three top options as shown. The first option auto syncs FLDIGI to the mode selected on FLAMP. The second syncs FLAMP to the mode selected on FLDIGI. These two options are not mutually exclusive: if the first two options are selected, the mode selection is bilateral. To avoid confusion, it is recommended that only one is used.

The third option will override the current FLDIGI mode (e.g. a keyboard mode such as Olivia 8/500) with the mode selected with FLAMP for file transfers (e.g. one of the MT63 modes). The mode change will take place at the time of transmission.

If none of the boxes is checked, there will be no synchronization.

While operation in an emergency net may be different, the SATERN International Digital Net normally operates with FLDIGI controlling the mode. That means that the check box beside the “Autosync FLAMP to FLDIGI” caption should be checked. Individual operators have individual preferences and these considerations should be considered under different circumstances. It also means that net participants should have their RxID ON during the net to follow mode and offset frequency changes. Having TxID ON is not necessary, and is not recommended, because NCS controls the offset and mode which listeners should follow. Having it ON will not hamper NCS duties but is preferred OFF.


FLAMP - Digipeater Operation

The FLAMP Receive Tab. Notice the RELAY and FETCH buttons

Once again borrowing from the FLAMP documentation:

Under less than stellar propagation conditions their exists the possibility of multiple stations being unable to receive the data completely. The digipeater feature allows a receiving station to retransmit verbatim copies of the data to other receiving stations in the attempt to fill missing header/data sections. As with transmitting fills from the TX queue the Relay function acts on the missing reports from other receiving stations. Pressing the relay fetch button will transfer a list of missing blocks associated with the selected received queue item into the relay blocks field. This field is user editable and can be entered directly without the need to press the fetch button. If the Blocks field contains no missing block numbers (empty) the received content of the file will be retransmitted. It is not necessary for the received file to contain 100% of the data. Only checksum verified data is available for retransmission.

To enter missing block numbers manually, the following numerical values are used to indicate what part of the data is to be relayed. Missing preamble (header data) are represented by the number ‘0’. Block numbers 1 to n (the maximum number of blocks for the given file) represents the <DATA 34 2E43>{hash:block number n} AMP-2 tagged data.

Retransmission of the data format is limited to how it was received. The user has no control over the blocks size, compression, base conversion, etc. In effect it’s a manually initiated digipeater. Interval Timer can be enabled/disabled and time duration altered to the users requirements. Header Modem is not available for relay transmits. The modem used to transmit the data is the same as the one selected in the transmit panel.

Once FLAMP has exited or the files removed from the receive queue the digipeat option for the those file(s) are lost.

Each week the NCS station on the SATERN International Digital Net will ask a station to repeat the message as sent for those who did not get the completed data. This method is how that is accomplished. It is a convenience feature one could argue, but a simple and handy one.

Transfer Receive Queue Item to the Transmit Queue.

This feature is another in this long list of convenience items. To move a received message into the transmit queue list, select the receive queue item. Then, click on “To TxQ” button.

The content of the file, file name, description, and block size will be transfered to the TxQ after the user is requested to save the file. Software will only allow 100 percent completed files to be transfered. Mouse clicking on the Transmit tab reveals the transfered queue item. Retransmission of the file in it’s complete form must be conducted (no missing blocks fills). Use of this option does not allow for digipeater functionality. For digipeat operations see Digipeater Operations above.

Scheduling Timed Events

The FLAMP Events Tab.

FLAMP can transmit the queued files on a specified interval, on a timed schedule or continuously. This is particularly handy when NCS desires to broadcast weather reports or important messages to the net on a repeated basis. This is configured via the Events tab.

When executing the “One time at” event schedule, the time entries in the Xmt time (HHMM) field are remove as each event time is executed. When all times are exhausted the Start/Stop Events button is disabled (Stopped).

When using the “Continuous at” option, the event time format is represented as:

HHMM-HHMM<space>HHMM-HHMM<space>,... or HHMM-HHMM<comma>HHMM-HHMM<comma>,...

Particular attention should be paid to the specific Xmit time format. The time is entered in a HHMM format / from-to. In other words, a specific time would be 1000-1015 1415-1430 indicates transmit times of 10:00 to 10:15 and 13:15 to 13:30.

When “Repeated at” is selected then the event times are as delineated in the Xmt times (HHMM) control block. Other options include various repeat intervals (5, 15, 30 minutes; hourly, even hours, odd hours) and one time repeat at a specified time.

FLAMP Event Interval List.

As can be seen from the image shown, there are a number of options available to the NCS operator when scheduling events. Not the least of which is the mode interval selection from the dropdown box near the middle of the window.

This option list allows selction of how often the scheduled event is to occur. Selection from the dropdown list sets this schedule. The list of choices is shown here, but may change in future versions of FLAMP.



FLAMP Event Interval List.

The abilty to send at particular times or time intervals is absolutely convenient. But, what if you wanted to use different modes because of changing conditions or to fill the gap where some stations do not have all modes?

That gap is filled by using the HamCast mode tab. The feature allows the timed events to be sent in more than one of several selected modes.

The image shown portrays the option to rotate between a number modems in FLDIGI for given periods; the length of which is determined by the duration time entered on the right.

Hamcast activation facilitates the transmission of queued files using a rotating modems selected by the user. To illustrate this effect a ‘Continuos at’ is scheduled to occur between the hours of 0533 to 0539 hrs UTC. On the triggering of this event “Modem 1” (if enabled) will be selected and used to transmit the contents of the transmit queue. Once completed the second modem will then be selected to transmit the queue again. This cycling continues through all of the enabled modems until the event end is reached.

On multiple single events each enabled modem is assigned to each event in sequence.