You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But what if can't make the assumption whether the payload is relative to an uplink or a downlink ?
I feel a bit uncomfortable with having to handle externally to the PHYPayload itself the way it is going to be marshalled or unmarshalled regarding to an unexported attribute. Do you agree ?
Shall we find a way to make unmarshalBinary works in both cases in order to obtain the correct under-relying structure ?
Otherwise, each time one transmits a raw sequence of bytes representing a physical payload, one's also has to transmit whether or not its an uplink or downlink payload (this is obvious when you consider a context where the receiver / sender knows what they are doing, but considering libraries which manipulate payloads out of any context, this is not that straightforward).
As far as I see in the implementation, the uplink attribute is only used by MAC commands to check if the payload refers to a valid command depending on its nature (commands are split into two groups, uplink-related commands, and downlink-related commands). Nevertheless, isn't the nature of the payload defined by the command (and not the opposite way) ?
Let me know,
Thanks.
The text was updated successfully, but these errors were encountered:
There are a couple of things that are depending on the direction of the payload: calculation of MIC, MAC commands (uplink and downlink share the same bits in the CID field), encryption and frame counters. So without knowing if it's uplink or downlink, there is no way to decode and validate a payload correctly.
It is possible to guess the direction by looking at the MType field. This will work in most cases, except for MType=Proprietary, so this is not a solid solution.
So I think there is no way to know for sure if the payload is uplink or downlink by looking at the byte slice, unfortunately.
Hey !
I just stumble across a small issue. How to unmarshal a payload if you don't know by advance if its uplink or downlink ?
PHYPayload.uplink
isfalse
by default, so, the above line is equivalent to:But what if can't make the assumption whether the payload is relative to an uplink or a downlink ?
I feel a bit uncomfortable with having to handle externally to the
PHYPayload
itself the way it is going to be marshalled or unmarshalled regarding to an unexported attribute. Do you agree ?Shall we find a way to make
unmarshalBinary
works in both cases in order to obtain the correct under-relying structure ?Otherwise, each time one transmits a raw sequence of bytes representing a physical payload, one's also has to transmit whether or not its an uplink or downlink payload (this is obvious when you consider a context where the receiver / sender knows what they are doing, but considering libraries which manipulate payloads out of any context, this is not that straightforward).
As far as I see in the implementation, the
uplink
attribute is only used by MAC commands to check if the payload refers to a valid command depending on its nature (commands are split into two groups, uplink-related commands, and downlink-related commands). Nevertheless, isn't the nature of the payload defined by the command (and not the opposite way) ?Let me know,
Thanks.
The text was updated successfully, but these errors were encountered: