Receive path

How a received signal travels through samoyed-direwolf: from an audio sample, through demodulation and frame decoding, to the application layer and the AX.25 data link state machine.

Concurrency

Everything from reading a sample to radioSink.RecFrame runs on the audio device’s own goroutine, one sample at a time. So the HDLC, FX.25 and IL2P receivers all see each bit from a slicer as it arrives.

Everything after the DataLinkQueue runs on the single recv_process goroutine. The data link state machine only ever runs there.

recv_process waits on the queue only until the next data link timer is due, so timer expiry is handled on the same goroutine as received frames.

Many decoders, one frame

A channel can run several demodulators (subchannels), each with several slicers (decision thresholds), and each subchannel and slicer pair has its own HDLC, FX.25 and IL2P receivers. More than one of them can decode the same frame. MultiModem.processRecPacket holds each decoded frame for a few bit times so that pickBestCandidate can pass on only the best copy.

One queue, two consumers

Frames received over the air, frames from external TNCs and network sources such as AXUDP and the IGate, and requests from AGW clients all go onto the DataLinkQueue. recv_process gives every received frame first to recPacketHandler.app_process_rec_packet and then to lm_data_indication, the entry point to the data link state machine.

“Clean or FEC” in the diagram means a frame decoded without any bits fixed, or one received with FX.25 or IL2P forward error correction. Only those are IGated or digipeated.

app_process_rec_packet stops with a frame from the IGate channel once the client applications and the web interface have it. A touch tone sequence, from the DTMF decoder or in a frame whose information starts with t, goes to the APRStt gateway instead of the IGate and the digipeaters.

EAS skips line decoding and HDLC framing altogether, and AIS skips the FX.25 and IL2P receivers.