Difference between revisions of "Talk:Control Chain Protocol"
m (Crudo moved page Talk:Control Chain to Talk:Control Chain Protocol) |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 10: | Line 10: | ||
| − | 3) is the SLIP encapsulation really necessary? Or a sync byte and no chars escaping, sounds | + | 3) is the SLIP encapsulation really necessary? Or a sync byte and no chars escaping sounds enough? |
| + | |||
| + | |||
| + | 4) In the initial proposal of Control Chain we had, on the host data request message, a sequence number field that would be used to detect if device response (of the data request) was delivered to host. This was proposed as a workaround to one problem in a specific case, the "trigger". It's a sort of problem the trigger message doesn't be delivered to the host. So, the idea was, if the device receive the same sequence number as the previous, it should re-send the last value. This approach sounds too much for a situation that happens eventually. Suggestions? | ||
Latest revision as of 12:52, 24 March 2017
1) Is the current operation definition (polling devices for data) using the best approach? Others options:
- time slicing, where each device will be allowed to send data only in its slice, defined previously by the host
- on demand, any device can send data to host since it has new data. In this case a collision detection strategy have to be designed
TODO: Pros and Cons to each case
2) instead of channel selection need to have an human interaction (selector switches, buttons and display, ...) , could be better try an automatic way, using random number, e.g.?
3) is the SLIP encapsulation really necessary? Or a sync byte and no chars escaping sounds enough?
4) In the initial proposal of Control Chain we had, on the host data request message, a sequence number field that would be used to detect if device response (of the data request) was delivered to host. This was proposed as a workaround to one problem in a specific case, the "trigger". It's a sort of problem the trigger message doesn't be delivered to the host. So, the idea was, if the device receive the same sequence number as the previous, it should re-send the last value. This approach sounds too much for a situation that happens eventually. Suggestions?
