I have connected OBD2 and getting the can data (11bit 500kpbs CAN) using atmel can controller.
I get data.
Now, how do I get the mode and PIDs from this data?
For example, my data looks like this:
15164A8A-FF088B52 -- Data: 00,00,00,86,9C,FE,9C,FE,
I could see RPM changing, ignition on/off etc... on the data fields.
I don't want to use ELM chips. I need to handle the raw data directly.
HINT: All of my numbers are in HEX.
OBD2 protocol sends you responses in bytes (8 bits). responses are subdivided into header (or called ID as well) and data.
IDs are the address of the ECU and data is "response data" from ECU and it is always 8 bytes (in CAN Bus protocol?!).
8 Bytes of data will be divided into PCI (which can be one or two bytes) and values. PCI will show you what is your frame type (single, First, consecutive or flow control frame) and how many bytes are incoming.
to make it easier I make an example only for single frame:
you might send an OBD request to main ECU like this:
7DF 02 01 0C 00 00 00 00 00
7DF is ECU address for diagnose tester device.
02 is number of sending data bytes
01 is the mode (which you might be interesting in!) 01 is current data, 02 is freeze frame and etc.
0C is rpm PID.
The response from ECU would be something like (single frame):
7E8 04 41 0C 12 13 00 00 00
7E8 is the ECU that responding.
04 number of incoming data bytes.
41 the data are in response to 01 PID
0C response to this PID
12 13 are two byte in response to 0C. Please keep in mind that you have to decode these two bytes with OBD II ISO protocol. you can also find some of conversion rates on Wikipedia.
Other bytes are useless.
To make it short: you have to parse each response from ECU and try to convert the useful bytes to readable decimal value. It depends on which programming language you are using. in C/C++ the best practice in my opinion would be unsigned char which is guaranteed by compiler to be 8 bits and in JAVA it can be Byte. Moreover, try to use bitwise operators to make your life a bit easier.
By more questions do not hesitate to ask.
Related
I'm analyzing some captured packets and see that for some of the packets, Wireshark displays the image below, which appears to contain several Modbus PDUs in the one TCP segment. I have searched online for answers but can't see this behavior anywhere I looked. From what I'm reading, Wireshark re-assembly gathers the different TCP segments, and so it appears this can't be reassembly.
My question is: is this behavior (i.e. having several Modbus PDUs in one TCP segment) normal and expected? If not, what is causing this problem? Is this an issue with Wireshark?
link to fullsize image
Yes - Modbus TCP runs at the application layer and supports multiple simultaneous transactions over a single connection (see page 10 of the spec). So sending:
00 01 00 00 00 06 01 03 00 00 00 01 00 02 00 00 00 06 01 03 00 01 00 01
is fine (this is 2 x "Read Holding Register" commands - note the different transaction identifiers). If this is sent at the same time it's likely the two commands will be sent out in the same packet. While this is supported (by some devices!) its not something I see often (unless performance is key its easier to process the response before sending another request).
However I don't think this is what is happening in your case. The lines you are highlighting are flagged TCP Retransmission so I'm assuming there was a connectivity issue. You can also see this in the 1s gap between the retransmitted packed and the previous request (it looks like queries are being sent every 300ms).
862.493794
862.805685 - 0.3s gap
863.117588 - 0.3s gap
864.232576 1st retransmission - 1.1s gap
You will also note that after the retransmissions there are a couple of responses that come in very close together (less than 1ms apart).
When data is retransmitted I believe (not my area so relying on this answer and assumptions!) that multiple packets may be combined. So I suspect you are seeing is:
Network connectivity issue starts
Client sends request
No response received so Client tries again (may happen multiple times)
Connectivity issue resolved
The packets sent while there was an issue are combined and retransmitted (handled by the network stack).
In no case does TCP ensure that if you send a packet of x bytes, the other end will receive the x bytes in a single packet.
It can happen that one side sends 1000 bytes and the other side receives first 800 and then 200, or two packets of 1000 and 2000 are sent and the other side receives only one of 3000.
From the received PDU, first you have to read the bytes necessary to obtain the length and then read the rest and so on to extract the PDUs
I am new in Lora, I tray to connect my Lora GW & GPS tracer LW001-BG to The things Network, & it successfully connected to TTN, but how to convert or decode the data from the GPS to latlong format?
here is the documentation http://doc.mokotechnology.com/index.php?s=/2&page_id=143
I receive data format like this 02 01 56 F8 0B 45 F4 29 32 46 and I need to convert/decode it to readable format
thanks I hope someone can help me
The payload of the message is in bytes 3-6 (for the latitude) and 7-10 (for the longitude). The first two bytes indicate how many packages there are (two) and which the current one is (the first).
The four bytes represent a 32 bit floating point value; in your example this is 2239.5210 for the latitude. This means 22 degrees, 39 minutes, and 31.26 seconds (which is the fraction times sixty).
You can see this in an on-line converter: As the byte order is lowest byte first, you need to reverse it, convert it to binary, and then check the checkboxes in the binary representation:
54 F8 0B 45 becomes 45 0B F8 56 or binary
01000101000010111111100001010110
Here the first bit is the sign, followed by 8 bits of the exponent and 23 bits mantissa. The decimal representation is 2239.52099609 and you discard all digits after the fourth to get 2239.5210 (with rounding).
Depending on how you process this data, you might be able to simply cast this to a float variable, as they are generally following the 32 bit IEEE 754 standard.
First of all I am very new to deep learning and sorry if I am not asking the questions that are not up to the standard of the site.
I have a sequence of arm assembly opcodes that are respective to a number of functions (You can view the whole csv file from here). If I give a one particular sequence of a function it is as follows.
// This is the disassembly sequence of a function named bit()
// just assume four opcodes `b0 0a 46 01` belong to certain other library
83 b0 0a 46 01 90 02 a8 01 70 ff e7 01 98 01 68 01 22 52 05 91 43 01 60 02 a8 00 78 40 05 00 90 ff e7 01 98 01 68 00 9a 11 43 01 60 01 98 03 b0 70 47
I have already built a small deep learning model (by following a NLP tutorial) to classify among eight classes of function when a byte sequence as above is passed. However, what I need is in addition to identifying the function label, to identify the byte sequence that belong to particular library.For example, in the above function b0 0a 46 01 believe to a different library. So I want to identify such sub sequences when a whole function sequence is passed. I believe it is similar to object detection in images where instead of just identifying the image itself, identifying the objects in the model.
Frankly, I don't know whether such a requirement is possible in deep learning and if possible, I would like to know any resources/tutorials that I could look up and learn in order to reach my goal. Once again, sorry if I am asking something that doesn't make sense. Appreciate any help if possible.
Your idea to consider this something like a object detection problem seems to make sense. The Yolo model is supposed to be pretty decent in this use case: https://pjreddie.com/darknet/yolo/ . Perhaps you can substitute 1D convolutions in place of the 2D convolutions to adapt to your use case. Additionally, creating embeddings to encode your opcodes as a first step might be helpful, although you might have already implemented this part. I hope this helps.
I am integrating an iOS app with a Bluetooth chip.
I am trying to understand the differences between a constant BLE connection and an iBeacon notifications in terms of the protocol.
So I am able to connect to the chip and send/recieve data from/to iPhone.
To communicate , you need 3 things :
name
service UUID
characteristic UUID (to write and read from).
Then, when you want to register to a region of an iBeacon, you also need a UUID of the characteristic, but also major/minor values.
Thing is, all iBeacon apps will not detect this type of broadcast- the one I use for communication.
So, whats basically the difference in the protocol? what if I keep advertising the same service/char I use for regular communication? is it good also for beacon push notification ? apparently not- but whats the different?
Also, I have 2 hardware chips, both will not let you set a major/minor values, but only to update the characteristic to notify a new value to subscribers which is hex (not an integer like major/minor) - is that equivalent to an iOS push notification by iBeacon detection ??
Difference between constant BLE connection and Beacons
A "constant BLE connection" is a connection, two devices pair with each other.
A BLE iBeacon device does not know about other devices. It simply broadcasts a certain signal frequently. Other devices can than listen to this signal and evaluate the signals strength to estimate how nearby the sender might be.
"Is it equivalent to Push Notifications?"
No.
Major & Minor
The major number (2 bytes) is used to group a related set of beacons. For example, all beacons in my flat will have the same major number, while the neighbour uses his own. That way the application know in which specific flat the application is.
The minor number (2 bytes) is used to identify the actual beacon. Each beacon in my flat has a different minor number, so that you know where within my flat the application is.
" value to subscribers ... is hex ... not an integer"
An hexadecimal is an integer.
HowTo
You need to insert a specific set of bytes into the optional manufacturer specific Data field (your "new value" for subscribers).
According to this site, you need the following values:
ID (uint8_t)
Data Length (uint8_t) - The number of bytes in the rest of the payload = 0x15
128-bit UUID (uint8_t[16]) - The 128-bit ID identifying the Beacons manufacturer
Major (uint16_t) - The major value
Minor (uint16_t) - The minor value
TX Power (uint8_t) - This value is used to try to estimate distance based on the RSSI value
Example from this site:
0x02 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 00 00 00 00 C8 00
0x02
0x0008
1E 02 01 1A 1A FF 4C 00 02 15 Manufacturer
00 00 Major
00 00 Minor
C8 00 Power
While debugging on Windows XP 32-bit using the immunity debugger, I see the following on the stack:
_Address_ -Value_
00ff2254 ff090045
00ff2258 00000002
My understanding is that every address location contains 8 bits.
Is this correct?
If I'm understanding your question correctly, the answer is yes, every individual memory location contains 8 bits.
The debugger is showing you 4 bytes (32 bits) at a time, to make the display more compact (and because many data types take up 32 bits, so it's often useful to see 32-bit values). That's why the addresses in the left column are 4 locations apart.
If the debugger showed one byte (8 bits) at a time, the display would look like this:
_Address_ -Value_
00ff2254 45
00ff2255 00
00ff2256 09
00ff2257 ff
00ff2258 02
00ff2259 00
00ff225a 00
00ff225b 00
(assuming you're on a "little-endian" machine, which most modern desktop PCs are.)
I think the main problem with your question is that you ask for one thing, but I detect a different question lurking in the shadows.
First, and foremost, addressable entities in the memory of a computer is organized as bytes, which are 8 bits each, so yes, each address can be said to refer to 8 bits, or a byte.
However, you can easily group more bytes together to form bigger and more complex data structures.
If your question is really "Why am I seeing an 8-digit value as the contents at an address in my stack dump", then the reason for that is that it dumps 32-bit (4 bytes) values.
In other words, you can take the address, the address+1, the address+2, and the address+3, grab the bytes from each of those, and combine to a 32-bit value.
Is that really your question?
To complete the answer of RH, you may be surprised to have so many numbers for a given address.
You should consider
Address Byte (8 bits)
00ff2254 45
00ff2255 00
00ff2256 09
00ff2257 ff
00ff2258 02
...
(On a cpu architecture used by XP)
A memory location refers to a location of memory, and each consecutive memory location refers to the next byte in memory. So, you can only address memory on a one byte boundary, and everyone should know that a byte is 8 bits wide.