Hello,
On Fri, Jun 7, 2013 at 12:31 AM, Tony Cheneau <tony.chen...@amnesiak.org> wrote:
>
> Thanks for your comments. They are especially appreciated since you designed
> the version 1 of the protocol. Please see my comments inline.
>
> [...]
>
>
>> Sometimes we had problems with synchronisation/recovery/etc. If a
>> character is lost,
>> it takes some (1-2) packets to resync kernel and a device.
>
> I don't doubt your word, but I don't think I have witnessed such issues. It
> could be because the Econotag's UART code has been improved lately.
> Regardless, it's good to design robust protocol and we can't account for
> upcoming devices, so your point makes sense.
We had these problems with mc13192+HCS08 devices. Sometimes they
would get out of sync with pl2303 and then ~half of the packed will be
received as garbage. This often (~90%) happened after long pauses
in communication between host and dongle.
>
>> I have two suggestions (we can agree on either of them or on both).
>>
>> 1) I suggest for 's' to be used only as a packet start character.
>> Let's pick up something like
>> SLIP/PPP have:
>>
>> For transmitter:
>> 's' = start of the packet. If it happens in the packet, transmitter
>> should replace it. 's' => 'ec'
>> 'e' = escape char. If it happens in the packet, replace it with 'e' =>
>> 'ee'
>>
>> For the receiver:
>> 's' => start of the packet. If it is found, finish the current packet
>> (possibly truncated/damaged)
>> and start parsing new packet
>> 'e' => escape char. Replace:
>> 'ee' => 'e'
>> 'ec' => 's'
>>
>> After 's' comes protocol version ('s' '2').
>
> Byte stuffing makes perfect sense here. I would tend to favor Mariano's
> suggestion and use Consistent Overhead Byte Stuffing (COBS). I haven't read
> the paper in details yet, but the implementation seems lightweight and it
> does not add much overhead.
I did not know the idea of COBS at the time of my original email. Nice idea.
Let's see if we can make use of it.
>> Also what is the point of reversing the high bit in the 'received
>> block' event/response?
>
> It makes it extra easy to match a request to its response and to compute the
> response message in the case you don't even support the command (provided
> that all your command have the same "header", such as "s2" and <status>, you
> can indicate a failure). Perhaps that not needed if you report errors in a
> different manner.
I know why both V1 and V2 have that | 0x80 ;)
I was asking especially about received-block event. V2 has that 0x80 inverted
in received-block (if compared to V1).
--
With best wishes
Dmitry
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
