Hello,
I'd like to request a number for Z-Wave serial interface link type.
The link-level protocol is described in section 5 of
https://www.silabs.com/documents/login/user-guides/INS12350-Serial-API-Host-Appl.-Prg.-Guide.pdf
Best,
Mikhail.
___
tcpdump
On Jul 21, 2019, at 9:23 AM, Mikhail Gusarov wrote:
> I'd like to request a number for Z-Wave serial interface link type.
>
> The link-level protocol is described in section 5 of
> https://www.silabs.com/documents/login/user-guides/INS12350-Serial-API-Host-Appl.-Prg.-Guide.pdf
So the packets wo
Hello,
I would like to request a Link-Layer Header Type for USB 2.0 packets.
This is intended to be used as a export format from sigrok.
While sigrok contains code to convert D+/D- signals into
LINKTYPE_USB_LINUX_MMAPPED, it is a bit limited. One issue is that
without dissecting USB Configuration
Hello Guy,
On 21 Jul 2019, at 20:28, Guy Harris wrote:
The link-level protocol is described in section 5 of
https://www.silabs.com/documents/login/user-guides/INS12350-Serial-API-Host-Appl.-Prg.-Guide.pdf
So the packets would either be:
an ACK frame, with the packet data being 1 byte
On Jul 21, 2019, at 1:14 PM, Mikhail Gusarov wrote:
> That's right. Also there might be some garbage frames at the beginning of
> capture
> (basically, the contents of the current packet up to ACK/NAK/CAN/data).
So a "garbage frame" would be any frame that begins with a value other than
0x06,
On Jul 21, 2019, at 12:40 PM, Tomasz Moń wrote:
> I would like to request a Link-Layer Header Type for USB 2.0 packets.
It looks as if USB 3.1's packets are different from USB 2.0's packets, so this
would be 2.0-specific.
> The new Link-Layer Header Type is supposed to contain the USB 2.0
> pa
On Jul 21, 2019, at 1:27 PM, Guy Harris wrote:
>
> On Jul 21, 2019, at 1:14 PM, Mikhail Gusarov wrote:
>
>> Now that I think about it, in a very rare case it is possible to not be able
>> to synchronize at all:
>> if a SOF byte is encountered inside the data frame, then the next byte will
>>
Hi Guy,
On 21 Jul 2019, at 23:07, Guy Harris wrote:
So a "garbage frame" would be any frame that begins with a value other
than 0x06, 0x15, 0x18, or 0x01?
Is there any reason for whatever capture mechanism produces these
packets not to discard garbage frames
rather than handing them to the l
On Sun, Jul 21, 2019 at 10:47 PM Guy Harris wrote:
> It looks as if USB 3.1's packets are different from USB 2.0's packets, so
> this would be 2.0-specific.
USB 3 operates on different hardware signals. USB 3 hubs do contain
USB 3 and USB 2.0 hubs inside them.
The USB 2.0 data is sent on the D+/
