How to decode S0002 status string #187
Comments
|
My understanding is that all detector logics are indexed from 1 and up, ignoring the component names. The first character refers to the first detector logic, etc. The S0002 docs states (my highlighting) : Each character represent the state of the detector logic in consecutive order. It implies that the list of components has an inherent ordering, which is not clearly described anywhere, as far as I'm aware. Perhaps this should be clarified in the docs? @otterdahl any inputs? |
|
Component names might include a number. 001DL002 But like in this example (2,6,9), they might not start from 1 and they might not be consecutive. The component names can be any strings and does not have to include an integer, eg: foot So instead S0002 uses the index into the compont list (1,2,3). But again, implies that the component list his has an inherent and stable ordering. |
|
We've specified According to the publication, the Perhaps we should update this definition to be more generic. We can remove the reference to the STA publication and instead make our own definition. |
|
I agree we should use a defintion that's universal rather than refer to STA (Swedish Transport Administration). Some devices internally assign ids to components, often with gaps in the numbering: 1 => KK+AG0506=000DL001 Should componet DL010 status be in the 3. or on the 10th digit? Ie. suppose all detectors are active, should it be "111" or "11-------1"? I'm also not sure the compoent will always match the internal ids. E.g. might the following exist today in devices? 0 => KK+AG0506=000DL001 The best would be to have a way to fetch the the index to component mapping. Without, we have to depend on manually configuring the mapping in the supervisor. But it's a bit fragile - if components are added/removed/edited on the device and we forget to update the config on the supervisor, we might misinterpret S0002 data. |
It should be "11-------1" since:
Do you think this can be clarified further?
No, this cannot happen in the controllers which we are used to. At least not to my knowledge. The controllers which we use always use a consecutive numbering 1,2,3,4... and so on. And the mapping is always 1 => KK+AG0506=000DL001, 2 => KK+AG0506=000DL002
This is of course possible, but I wonder if this is really necessary and if we are just making things more complicated than they need to be. |
|
So my understanding of the current implementation is: The list of components must be configured manually on the supervisor matching what's configured on the site. Eg: KK+AG0506=000DL001 Many (most?) road authorities use a component naming scheme that include the index as the last part of the name. For example, KK+AG0506=000DL002 would be assumed to have the index 2. In such cases the index can be inferred from the component names. Otherwise it must be manually configured: 1 => KK+AG0506=000DL001 When you receive an S0002 status string like "00--------1", the position of each character in the string is used as a lookup into the component map. In this case, the "1" is the 10th character, and looking up 10 in the component map gives the component name "KK+AG0506=000DL010". If component names are known to follow a scheme that includes the index, the component name can be constructed, in stead of using a preconfigured lookup table. In this example as "KK+AG0506=000DL#(index_wih_zero_padding)". Is it defined whether character positions start from 0 or from 1? |
|
If a site has large gaps in the numbering of detectors, this will result in a lot of "-' characters. Eg. if you have DL001 and DL100, you need to send: In this case would, it be a lot more efficient to have a component array: And then in the status string use character position to refer to index in the component array: I think we should consider this when we implement a way to get the list of components. |
I've never heard of a detector logic numbering that starts from 0. But we can clarify this. |
Sure, but I believe this is an unusual scenario. The controllers we're used to typically doesn't have any gaps at all. If the there is a need to remove a detector logic due to work in the intersection the controller still reports the status for the detector logic, even if it's no longer connected to anything. I think we should carefully consider if a mapping table is worth the extra trouble. I'd really like to know how common it is with gaps in the numbering to better unstand how big of a problem this really is. |
|
See also earlier issue #166 |
|
I guess the same mechanism applies to other status messages, e.g. S0001 with signal groups also counted from 1? E.g. KK+AG0506=000SG001 |
Yes |
|
I will propose a small change to the wording in 1.2.1 to make it less ambigiuous when there are gaps in the component ids. |
I received this question:
How to decode a S0002 detector logic status string? Is it correct that each character of the string can be assigned to a detector logic based on the component ID (and the index included in this ID)? Typically, the status of 001DL001 is represented by the first character in S0002 string, the status of 001DL002 is represented by the second character..
I have not found a clear description of this mechanism in the specs: is it described anywhere?
S0002 reference:
https://rsmp-nordic.github.io/rsmp_sxl_traffic_lights/1.2/sxl_traffic_light_controller.html#s0002
The text was updated successfully, but these errors were encountered: