I need some help understanding the last part of this usb hid report descriptor. It is rather straight forward for the most part, except for the last 3 fields of 16 bits (line 60 - 67). I am going to use this for what should be a rather simple arduino esp32 project. For this project I need to write a small device driver using This library.
Usage Page (Desktop), ; Generic desktop controls (01h)
Logical Minimum (0),
Usage (Gamepad), ; Gamepad (05h, application collection)
Collection (Application),
Report ID (1),
Usage Page (Button), ; Button (09h)
Logical Minimum (0),
Logical Maximum (1),
Report Size (1),
Report Count (10),
Usage (01h),
Usage (02h),
Usage (04h),
Usage (05h),
Usage (07h),
Usage (08h),
Usage (0Eh),
Usage (0Fh),
Usage (09h),
Usage (0Ch),
Input (Variable),
Usage Page (Consumer), ; Consumer (0Ch)
Report Count (6),
Usage (Mute), ; Mute (E2h, on/off control)
Usage (Volume Inc), ; Volume increment (E9h, re-trigger control)
Usage (Volume Dec), ; Volume decrement (EAh, re-trigger control)
Usage (Power), ; Power (30h, on/off control)
Usage (AC Back), ; AC back (0224h, selector)
Usage (AC Home), ; AC home (0223h, selector)
Input (Variable),
Usage Page (Desktop), ; Generic desktop controls (01h)
Usage (Hat Switch), ; Hat switch (39h, dynamic value)
Logical Maximum (7),
Physical Minimum (0),
Physical Maximum (270),
Unit (Degrees),
Report Size (4),
Report Count (1),
Input (Variable),
Input (Constant, Variable),
Usage (Pointer), ; Pointer (01h, physical collection)
Collection (Physical),
Report Size (16),
Report Count (4),
Logical Minimum (0),
Logical Maximum (65535),
Physical Minimum (0),
Physical Maximum (65535),
Usage (X), ; X (30h, dynamic value)
Usage (Y), ; Y (31h, dynamic value)
Usage (Z), ; Z (32h, dynamic value)
Usage (Rz), ; Rz (35h, dynamic value)
Input (Variable),
Usage Page (Simulation), ; Simulation controls (02h)
Report Count (2),
Usage (C5h),
Usage (C4h),
Input (Variable),
End Collection,
Collection (Application),
Usage Minimum (01h),
Usage Maximum (03h),
Logical Maximum (65535),
Report Count (3),
Report Size (16),
Output (Variable),
End Collection,
End Collection,
It is a generic gamepad, but with rumble motors, so my first guess was that those are controls for the rumble feature on the device. They are declared as outputs which would support that guess. However, the usage types don't make sense for that use case at all and I don't see why you would need 3 reports of 16 bits to control that.
It also doesn't seem to be padding, since the total amount of bits comes up to 164, which is rather random, and you don't need to declare usage types for that. It is also declared as an output, which is strange for padding.
Can anybody help me understand this? I have read the hid documentation, but could not find any clear answers.
There was a request for the raw hex code:
003:011:000:DESCRIPTOR 1650199607.153697
05 01 15 00 09 05 A1 01 85 01 05 09 15 00 25 01
75 01 95 0A 09 01 09 02 09 04 09 05 09 07 09 08
09 0E 09 0F 09 09 09 0C 81 02 05 0C 95 06 09 E2
09 E9 09 EA 09 30 0A 24 02 0A 23 02 81 02 05 01
09 39 25 07 35 00 46 0E 01 65 14 75 04 95 01 81
02 81 03 09 01 A1 00 75 10 95 04 15 00 26 FF FF
35 00 46 FF FF 09 30 09 31 09 32 09 35 81 02 05
02 95 02 09 C5 09 C4 81 02 C0 A1 01 19 01 29 03
26 FF FF 95 03 75 10 91 02 C0 C0 05 01 09 02 A1
01 85 02 09 01 A1 00 05 09 19 01 29 03 25 01 75
01 95 03 81 02 05 09 09 05 95 01 81 02 75 04 81
01 05 01 09 30 09 31 15 81 25 7F 75 10 95 02 81
06 C0 C0 06 DE FF 09 01 A1 01 05 FF 19 01 29 40
85 FD 15 00 25 FF 95 40 75 08 81 02 C0 06 DE FF
09 03 A1 01 19 01 29 40 85 FC 95 40 75 08 B1 02
C0
Hello Every one
I'm currently working on a project that takes data from patients monitors and send them to another system that we built (Not the central station -which display all monitors- which is already working but it is closed source.).
The monitor is supplied with an Ethernet card and it sends data over the UDP protocol. But when we need to read real data which is in the application layer we understand nothing.
Here is a small frame we get from the traffic when the monitor talks to the central station.
0000 ff ff ff ff ff ff 66 76 84 00 18 73 08 00 45 00
0010 00 2e 00 00 40 00 40 11 7a 03 c0 a8 00 14 ff ff
0020 ff ff a4 10 1f 42 00 1a 04 45 ff d0 00 02 00 fe
0030 00 0a 32 01 02 03 04 05 0b 32 33 50
When I but it on wireshark it analyze until the UDP protocol and stop, it doesn't understand the application layer data.
Here is a sample application layer data.
ff d0 00 02 00 fe 00 0a 32 01 02 03 04 05 0b 32 33 50
Another one:
ff da 7f f1 00 04 00 0c 02 18 0d 0f 60 0c 04 0b 0b 10 00 00
Are there any standard protocols that used in medical field to transport data like ECG, respiration, etc.? And is there a protocol that is compatible with the form above?
Please stop there!
Get the specification or documentation from the vendor and do not reverse engineer the protocol. If you are unable to do so, leave this thing alone.
If you get it wrong you are endangering patients. Doctor may rely on your information which you are guessing as it seems.
Even if it something well documented like HL7 oder DICOM read the documentation and talk with the vendor.
Depending on jurisdiction there may be a myriad of legal problems ahead.
It may be transmitting in HL7
http://www.hl7.org/index.cfm
So I purchased this device from a company in china thinking, I'm savvy, I'll be able to figure it out.
http://www.ebay.com/itm/RS232-DC-12V-8Ch-Serial-control-computer-control-switch-Relay-Board-Module-/261695306230?hash=item3cee4179f6:g:UVwAAOSwWnFWBPYq
Well now that I have it, I can not figure out RS232 commands to issue and I can not find a manual anywhere. I've tried looking at similar devices and issuing commands like "FF 01 01" which equates to "addressofboard, relay, state" in other similar devices. Can anyone help me find a manual or has anyone ever used this thing?
I finally got a reply from the manufacturer. It's so complicated that I would have never guess the correct order. Here are the commands:
Close 1 channel：56 01 13 00 00 01 01 6C
Open 1 channel ：56 01 13 00 00 01 00 6B
Close 2 channel：56 01 13 00 00 02 02 6E
Open 2 channel：56 01 13 00 00 02 00 6C
Close 3 channel：56 01 13 00 00 04 04 72
Open 3 channel：56 01 13 00 00 04 00 6E
Close 4 channel：56 01 13 00 00 08 08 7A
Open 4 channel：56 01 13 00 00 08 00 72
Close 5 channel：56 01 13 00 00 10 10 8A
Open 5 channel：56 01 13 00 00 10 00 7A
Close 6 channel：56 01 13 00 00 20 20 AA
Open 6 channel：56 01 13 00 00 20 00 8A
Close 7 channel：56 01 13 00 00 40 40 EA
Open 7 channel：56 01 13 00 00 40 00 AA
Close 7 channel：56 01 13 00 00 80 80 6A
Open 7 channel：56 01 13 00 00 80 00 EA
The structure is weird to me but I'm sure it makes sense somewhere:
(data, device address, function, empty, empty, relay, state, checksum)
The checksum is an addition of all the values and taking the 8th value of that addition.
I need to sort out something about the IPv4 header. For example the following frame with an Ethernet-II frame with an IPv4 packet starting at the fifteenth byte.
0000: 08 00 20 7c 94 1c 00 00 - 39 51 90 37 08 00 45 00
0010: 00 3e 36 00 00 00 80 11 - da 4f 82 eb 12 7f 82 eb
0020: 12 0a 04 01 00 35 00 2a - ee 6a 00 01 01 00 00 01
0030: 00 00 00 00 00 00 06 67 - 65 6d 69 6e 69 03 6c 64
0040: 63 02 6c 75 02 73 65 00 - 00 01 00 01
I need to sort somethings out:
What does the 0000 & 0010 & 0020 & 0030 on the left stands for?
I just cant sort it out is 1 pair for example the first one 08 two bits or?
And if the IPv4 starts at fifteenth byte(1 byte = 8 bits) where does it start then, have problems to understand this because i dont get number 2.
Thank you for your time.
”45” in your first line of hexdump is the 1st byte of the ip header (15th byte of the ethernet frame). Each line is 16 bytes.
Also, in the beginning of each line has an offset like e.g. ”0010: ” (in hex) means the starting offset from the start of the whole dump.
Your first line would be, (total 16 bytes),
dmac(6)+smac(6)+etype(2)+ first2byte_of_ip(2)
and your first byte of ip is hex ”45”, you can lookup the detail ip header field in wikipedia.
It would be nice if you can read wireshark user's guide on your own. Anyway, to answer your question,
1) What does the 0000 & 0010 & 0020 & 0030 on the left stands for?
It stands for hexdump offset. You can refer to this page.
2) I just cant sort it out is 1 pair for example the first one 08 two bits or?
It is (part of ) destination MAC address. Entire MAC address should be 08 00 20 7c 94 1c.
3) since Q2 is now answered, this should not be problem for you.
I did some work to transplant TCP/IP stack to MCU. Through GPRS, MCU can connect internet.
However, I met with some trouble during LCP negotiation.The following is my solution referring networking material
In order to make MCU PPP simpler.The LCP option request will be respond with rejection.
Server:7e ff 03 c0 21 01 01 00 14 02 06 00 00 00 00 05 06 b0 70 9c c3 07 02 08 02 54 06 7e
MCU:7e ff 03 c0 21 04 01 00 04 02 06 00 00 00 00 05 06 b0 70 9c c3 07 02 08 02 69 78 7e
A authentication request is expected in the second step. But i get a none LCP option request.
Server:7e ff 03 c0 21 01 02 00 04 b5 5a 7e
This means server forces MCU to start LCP negotiation.I am missing.
I send a authentication option request to server so that forcing server to start authentication option negotiation.Server respond me two packets.One is a ACK packet for authentication request.The another still is the none LCP option.
MCU:7e ff 03 c0 21 01 05 00 08 03 04 C0 23 ac 56 7e
Server:7e ff 03 c0 21 02 05 00 08 03 04 C0 23 bd 34 7e
Server:7e ff 03 c0 21 01 02 00 04 b5 5a 7e
After several "none option" request, The negotiation over. What should I do? I am l
(My english is not good .I hope you can understand my means.)
When you respond with Configure-Reject when modem sends Configure-Request. Then modem will send a new modified Configure-Request. See RFC1661 chapter 6.4.
So you should respond with Configure-Ack when Configure-Request contains suitable values for you. So you should send Configure-Ack after the second Configure-Request.