TNC-to-Host feedback frames #2
Comments
|
Implementation first, on both the client and modem. This spec documents
existing implementations so others can create compatible implementations.
Once you have a working implementation, we can discuss what makes sense to
include in the spec.
…On Tue, Jan 14, 2025, 7:13 PM Thomas Karpiniec ***@***.***> wrote:
KISS has always been, well, simple, and this puts certain limits on how
the host can use the TNC. For example, it doesn't know when the channel is
occupied or when or whether a packet has been transmitted. For a simple
protocol like APRS this isn't an issue - a dropped or delayed packet is no
big deal.
With M17 offering arbitrary stream and packet modes, applications may be
developed that require estimates of channel utilisation, knowing whether
transmissions were achieved within a certain time, or some form of
backpressure to maximise throughput. For a transceiver application, PTT
state would be important information to include in the GUI. All of this
data surely exists inside the TNC and it's kind of a bummer if the host
can't access it just because it's on the other side of a KISS link.
Since KISS is already being used creatively here (spanning multiple ports
with different protocols, using a empty data frame to indicate underrun),
why not flex it a little more?
Some events I would find very useful:
- Data Carrier Detect on
- Data Carrier Detect off
- PTT on: started stream-type transmission
- PTT on: started packet-type transmission (potentially multiple
consecutive packets)
- PTT off
- One logical packet has been transmitted
- A packet sent via port 0 or 1 has been dropped as the internal queue
is full
These could be provided as data frames on, say, port 3. What do you think?
—
Reply to this email directly, view it on GitHub
<#2>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABD64DB4OKAU7GMWQPLJIKD2KXG63AVCNFSM6AAAAABVGIHHAWVHI2DSMVQWIX3LMV43ASLTON2WKOZSG44DQNZTHAZTSNI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Perfect, will do. Thanks! |
|
There are protocols such as XKISS
<https://www.cantab.net/users/john.wiseman/Documents/KISS.html> (also
called Ack Mode) and 6PACK which provide some of the packet features. I
recommend consulting those specs and determining whether it makes sense to
extend the specification to include ack mode (XKISS) in the M17 spec. I
don't ever recall seeing a 6PACK client. XKISS, I think, would be the
preferred method for the last two items on your list, since there are
existing clients for this mode. Winlink Express, for example, supports it.
It would be fairly easy to extend the existing Mobilinkd TNC firmware to
support this. I do not know whether Ack Mode supports NACK for dropped
frames.
When extending the M17 KISS protocol, *especially* *for packet frames,* try
to avoid violating "Postel's Law" which states that when communicating with
other systems, you should be conservative in what you send out (strict) and
liberal in what you receive (forgiving). With that said, the current spec
does say that we can emit LSF, stream and packet frames via KISS, which
would certainly confuse most existing KISS packet clients if someone
broadcasts a voice stream on a packet channel. That, I think, should be
addressed somehow in the spec.
I have extended the KISS protocol for streams in the Mobilinkd TNCs by
adding a "Viterbi cost" byte to the end of each stream frame as an
indication of signal quality. See the TNC4 M17 Frame Decoder
<https://github.com/mobilinkd/tnc4-firmware/blob/master/Core/TNC/M17FrameDecoder.h#L422>
as
an example of what is appended. This is used by the Mobilinkd M17 KISS HT
Android app <https://github.com/mobilinkd/m17-kiss-ht> to provide something
akin to an RSSI indicator. It is used to squelch really poor signals. This
uses one of two bytes that were previously used by a 16-bit CRC in an
earlier version of the M17 spec for stream frames. This is almost the DCD
indicator you are looking for. When implementing these features, try to
avoid stepping on this byte in the stream frame. There is another unused
byte there which can be used.
One other thought is that you can use the KISS hardware frame type (0x06)
to send back arbitrary data from any KISS modem. This could be used for
PTT. Rather than PTT, I think some NACK signal for BCL (busy channel
lockout) would be more useful. What other purpose do you see in having a
PTT on/off indicator?
…On Wed, Jan 15, 2025 at 11:14 AM Thomas Karpiniec ***@***.***> wrote:
Perfect, will do. Thanks!
—
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABD64DCBSJQN64DFGZYFU2T2K2XSFAVCNFSM6AAAAABVGIHHAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJTG42DIMRTHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Thanks for all this! I will be sure to take a close look before diverging from basic KISS. Completely agreed regarding Postel's law - I'm confident that the requirements mentioned here could be implemented in a way which doesn't require any configuration and will degrade gracefully if either side doesn't support it, which I believe would be an improvement on ACKMODE. I'm developing a project currently which implements and uses both the TNC and host sides of the KISS link. I have to finish a few other things first but I expect in a month or two it will be a convenient testbed for putting some of the ideas from this thread into code.
BCL is the obvious use case, right. I'm not sure if I'd call it a NACK since the TNC will still get your stream on air as soon as it's able to. As a voice operator who pressed the "transmit" button I would definitely like feedback firstly that I'm not actually on air yet, and secondly when I am on air. If there were updates for DCD and PTT you could observe this neatly: first the channel is in use, then it isn't and CSMA delays are underway, then if nobody else jumped in the PTT comes on. Apart from that I think it's just nice feedback as an operator to have accurate PTT and DCD status so you can intuit if your radio is transmitting in the pattern you expected or if the channel is really congested. This is particularly relevant to TCP KISS because you can easily put your radio and TNC in one room and operate from another device in another room over WiFi. |
|
Another thought: we should clearly define "DCD" in any proposed change to
the spec DCD state is going to be exposed. What constitutes data carrier
detection? There are three levels of signal detection that I can think of:
received signal strength (RSSI) available from the radio, baseband SNR
based on some signal metric, but which might not be due to an M17 frame,
and M17 frame detection (maybe just sync burst). My M17 modems use 2 levels
of DCD -- a crude estimate of the SNR of the baseband and M17 frame
detection. It uses the SNR to determine whether frame detection is
attempted. For purposes of CSMA, the modem uses the baseband SNR estimate.
I'm not yet convinced that it is the right thing to do.
…On Wed, Jan 15, 2025 at 2:58 PM Thomas Karpiniec ***@***.***> wrote:
Thanks for all this! I will be sure to take a close look before diverging
from basic KISS. Completely agreed regarding Postel's law - I'm confident
that the requirements mentioned here could be implemented in a way which
doesn't require any configuration and will degrade gracefully if either
side doesn't support it, which I believe would be an improvement on ACKMODE.
I'm developing a project currently
<https://code.octet-stream.net/m17rt/tree> which implements and uses both
the TNC and host sides of the KISS link. I have to finish a few other
things first but I expect in a month or two it will be a convenient testbed
for putting some of the ideas from this thread into code.
Rather than PTT, I think some NACK signal for BCL (busy channel
lockout) would be more useful. What other purpose do you see in having a
PTT on/off indicator?
BCL is the obvious use case, right. I'm not sure if I'd call it a *NACK*
since the TNC will still get your stream on air as soon as it's able to. As
a voice operator who pressed the "transmit" button I would definitely like
feedback firstly that I'm not actually on air yet, and secondly when I
*am* on air. If there were updates for DCD and PTT you could observe this
neatly: first the channel is in use, then it isn't and CSMA delays are
underway, then if nobody else jumped in the PTT comes on.
Apart from that I think it's just nice feedback as an operator to have
accurate PTT and DCD status so you can intuit if your radio is transmitting
in the pattern you expected or if the channel is really congested. This is
particularly relevant to TCP KISS because you can easily put your radio and
TNC in one room and operate from another device in another room over WiFi.
—
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABD64DC3RJYEBDWEDHZSK7D2K3RZVAVCNFSM6AAAAABVGIHHAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJUGEYDOMJTGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Interesting question. I suspect the most useful meaning is "does the TNC consider the channel to be occupied such that we cannot transmit?" without trying to specify how that is accomplished. If we liked this approach, the name DCD might be misleading. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
KISS has always been, well, simple, and this puts certain limits on how the host can use the TNC. For example, it doesn't know when the channel is occupied or when or whether a packet has been transmitted. For a simple protocol like APRS this isn't an issue - a dropped or delayed packet is no big deal.
With M17 offering arbitrary stream and packet modes, applications may be developed that require estimates of channel utilisation, knowing whether transmissions were achieved within a certain time, or some form of backpressure to maximise throughput. For a transceiver application, PTT state would be important information to include in the GUI. All of this data surely exists inside the TNC and it's kind of a bummer if the host can't access it just because it's on the other side of a KISS link.
Since KISS is already being used creatively here (spanning multiple ports with different protocols, using an empty data frame to indicate underrun), why not flex it a little more?
Some events I would find very useful:
These could be provided as data frames on, say, port 3. What do you think?
The text was updated successfully, but these errors were encountered: