We often see two gibberish frames come out after the postamble.
This might be mostly due to untuned frame sync word detection thresholds in Locutus. Work on that is happening in the pluto_msk repository.
The whole purpose of the postamble is to eliminate the uncertainty about when to stop receiving a transmission. We could ask Locutus to detect the postamble and use that to force the frame sync word detection into its initial searching state. That would be correct, in that the postamble is defined to signal that the receiver should not expect future frames to be synchronized with the preceding frames. However, it may be burdensome to the Locutus implementation, and it may not be desirable to modularize this function into Locutus anyway.
It would be within the potential scope of Dialogus to detect the postamble. However, Dialogus should still relay the postamble to Interlocutor, which should eventually be using it to inform some kind of “incoming transmission in progress” indicator in the UI. Maybe it would make sense for Dialogus to send a special “postamble detected” control message instead of just sending it as an encapsulated frame. We probably need to talk about a whole vocabulary of control messages between Dialogus and Interlocutor. For instance, users would probably like to see RSSI on screen, and Dialogus has access to the information but currently Interlocutor does not. I’ll file a separate issue for that. Anyway, given that Dialogus shouldn’t complete the processing of the postamble, maybe it shouldn’t be processing it at all.
Dialogus could apply some heuristics to discard probable gibberish frames, with or without taking the postamble into account. But it couldn’t do much without running a risk of discarding good frames.
We often see two gibberish frames come out after the postamble.
This might be mostly due to untuned frame sync word detection thresholds in Locutus. Work on that is happening in the pluto_msk repository.
The whole purpose of the postamble is to eliminate the uncertainty about when to stop receiving a transmission. We could ask Locutus to detect the postamble and use that to force the frame sync word detection into its initial searching state. That would be correct, in that the postamble is defined to signal that the receiver should not expect future frames to be synchronized with the preceding frames. However, it may be burdensome to the Locutus implementation, and it may not be desirable to modularize this function into Locutus anyway.
It would be within the potential scope of Dialogus to detect the postamble. However, Dialogus should still relay the postamble to Interlocutor, which should eventually be using it to inform some kind of “incoming transmission in progress” indicator in the UI. Maybe it would make sense for Dialogus to send a special “postamble detected” control message instead of just sending it as an encapsulated frame. We probably need to talk about a whole vocabulary of control messages between Dialogus and Interlocutor. For instance, users would probably like to see RSSI on screen, and Dialogus has access to the information but currently Interlocutor does not. I’ll file a separate issue for that. Anyway, given that Dialogus shouldn’t complete the processing of the postamble, maybe it shouldn’t be processing it at all.
Dialogus could apply some heuristics to discard probable gibberish frames, with or without taking the postamble into account. But it couldn’t do much without running a risk of discarding good frames.