Difference between revisions of "Talk:Control Chain Protocol"

From MOD Wiki
Jump to navigation Jump to search
 
(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 enough?
+
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?