S-9.2 Add Clarifying Note to the Standard about back-to-back Packets

[bakerstu]

The standard allows command stations to send back-to-back packets to the same decoder address. However, a decoder is not required to receive back-to-back packets, within the 5msec of the previously decoded packet addressed to it.

We should add a clarifying comment that this is useful for the command station only when two identical packets are sent back-to-back, and that sending two non-identical back-to-back packets from the command station should be avoided. This is because the decoder is not guaranteed to receive both non-identical packets.

[RR-CirKits]

How about: Non-identical packets to the same address must have at least a 5mS delay between them.

Dick :)

[bakerstu]

@RR-CirKits this is actually still more strict than necessary, and violates the principals of the original text. To follow your statement, I would not be able to send two packet types A and B in the following sequence: A A B B. ...However, this is completely legitimate because the decoder will still have an opportunity to correctly receive one of packet type A and one of packet type B without having to decode back-to-back packets.

[RR-CirKits]

Would: "Individual non-identical packets to the same address must have at least a 5mS delay between them." solve the issue? I'm trying to come up with concise wording that doesn't require a paragraph in a TN to explain. This is because, as written, the standard is absolutely accurate. We are asking for an explanation text. That is typically what a TN provides.

[bakerstu]

@RR-CirKits Actually, I think a paragraph in a TN is the best way to solve this.

[KQRR4449]

I am not sure putting this in a TN would work. I think the basic requirement for back to back packets needs to be in the Standard so manufacturers must follow it. Manufacturers are not required to follow a TN.

Explaining the back to back requirement in a TN would work well.

On Wed, Oct 19, 2022, 6:37 AM Stuart W Baker @.***> wrote:

@RR-CirKits https://github.com/RR-CirKits Actually, I think a paragraph in a TN is the best way to solve this.

— Reply to this email directly, view it on GitHub https://github.com/nmradcc/documents/issues/63#issuecomment-1284030889, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3GEFTSOXMWJ3ZQDVSKLD3WD72P5ANCNFSM6AAAAAARFKZUY4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[bakerstu]

@KQRR4449 There are currently zero defects in the standard S-9.2 as written. It correctly allows for command stations to send back-to-back packets to the same address without restriction, except to addresses 112-127 as noted. It correctly allows for decoders to ignore packets addressed to it within 5 milliseconds after the packet end bit of any previous packet addressed to it. These two items are not in conflict, but there are implications for system designers to consider.

The purpose of additional commentary (requested by Railcommunity) is to explain some of the potential implications of the standard (as written), including how the two requirements are not in conflict. It is not to correct the standard. The standard is already correct as currently written.

If we can summarize this in one or two sentences, then I'm fine with adding it inline to the standard. If we need additional text in order to be thorough, and I suspect we do, then we should put it in a TN-9.2 that accompanies the standard. I think to be thorough, we should provide some specific examples of various scenarios indicating the implications of those scenarios.

[bakerstu]

S-9.2 should also be updated to note the fact that decoders must properly decode to back-to-back packets for the recently defined S-9.2.1.1 standard, as noted in that standard. This does not affect any decoders that do not use these newer packet definitions.