I have to enter programming session to test some functionalities, but i face 3 different scenarios each time..
*sending the request"10 02"
1- getting positive response "50 02 xx xx xx xx"
2- getting negative response "7F 10 22"
3-first getting negative response "7F 10 22" and then getting "50"
the QU: what does "50" mean?
and another QU: what may make the programming session not entered? what is the preconditions that should be happened?
This seems to be UDS based diagnostics.
The first byte of the request - 0x10 in your case - is the service ID. In UDS 0x10 is for session handling.
The first byte of a positive response is always 0x40 + <service id>. Thus 0x50 in your example.
When a request to enter a programming session is denied is mostly application specific.
E.g. you may need to authorize first. Or you may be going full speed on the highway and thus reprogramming the engine control is not a good idea.
Related
I have an IoT device, which communicates with a cloud server via UDP. The device receives a command to turn on/off every couple of seconds based on a cloud schedule.
I believe the chip inside the device is similar to an arduino pro mini. It has an external serial to wifi bridge which "opens" the UDP connection to the server.
Commands from server:
CMD22246A00M10C239S004!9S1$
CMD22246A00M10C239S280!WM0$
CMD22246A00M10C075S960!X2I$
CMD22246A00M10C239S520!ME5$
CMD22246A00M10C075S811!EPJ$
I will explain the data a bit in case that helps.
Time in these packets is 22:46
The first 2 stands for Wednesday (0 being Monday)
A00 basically means turn off (supply 0 amps) - This changes to A10 when it is allowed to turn on
M10 is the maximum configured amps the devices should be allowed to pass through
CXXX I have no idea about
SXXX I have no idea about
And the 3 alphanumerics between the ! and $ seem to be a checksum. The letters are always uppercase.
The device reports data back to the cloud similarly with a 3 alphanumeric checksum at the end
I have tried "injecting" command data into the device via a separate UDP server but they are all have no effect unless I replay valid ones from the server.
I have tried various online tools and checksum/crc calculators but cannot seem to find any matches.
Thanks in advance.
Update
I have just started to notice that similar packets have a very similar "checksum" at the end. Here is a link to all my data from every Wednesday at 23:46, sorted alphabetically which gives the best string matches when starting left. I have started to notice that data that is "+1" to its neighbour, might have the checksum be +1 in the first character of the checksum.
Full data set here: https://pastebin.com/n6LgrDfh
Same data but split with symbols removed: https://pastebin.com/Q8q4ANEE
I have split these examples and removed the symbols for easier reading:
CMD22346A10M10 C075 S274 FZD
CMD22346A10M10 C075 S275 EZD
CMD22346A10M10 C075 S276 DZD
CMD22346A10M10 C075 S277 CZD
CMD22346A10M10 C073 S515 P60
CMD22346A10M10 C073 S516 Q60
CMD22346A10M10 C073 S517 J60
Update 2
There are never any letter O in the check characters.
I'm currently developing a modbus server to control a device.
The device manual says about holding registers:
Adress 6000: ValueA, 2 Byte
Adress 6001: ValueB, 1 Byte; ValueC, 4 Byte; ValueD, 4 Byte
Adress 6005: ValueE, 2 Byte
The only supported read function is FC 03 / Read Multiple Holding Registers
To my knowledge, one can see the register as a memory block of numbered 16Bit values, and could read it in one go by reading 6 registers / 12 Byte beginning at 6000.
I think the 1Byte-value isn't an issue, the register simply contains a value not exceeding 255.
But expanding the table above gives:
Adress 6000: ValueA, 2 Byte
Adress 6001: ValueB, 1 Byte
Adress 6002-6003: ValueC, 4 Byte
Adress 6004-6005: ValueD, 4 Byte
Adress 6005: ValueE, 2 Byte
so, there is an overlap last line at 6005.
My device manual is full of such occurences, and meanwhile, I'm thinking that modbus registers ain't such a simple, linear memory as I thought.
Does anybody know if modbus registers are linear, or not?
I stumbled across a similar situation and asked about it in a more specialized forum. The "to long, didn`t read" was, that the address space is linear most of the time, but not always.
Check out the following example:
Excuse the German parts, but what you can see here, is that register address 0x2021 holds data made up of eight words or eight 16-bit blocks. Following your above logic you would expect the second word to be stored in the register 0x2022, but I checked on my local device and they are not the same. So, in summary, there are some devices out there which decide, that they give one register more memory than it's ought to have. So, register 0x2021 really holds 8 words on his own and does not use register 0x2022 to hold memory.
you might have a similar case.
I'm pretty new to using GNURadio and I'm having trouble recovering the data from a signal that I've saved into a file. The signal is a carrier frequency of 56KHz with a frequency shift key of +/- 200hz at 600 baud.
So far, I've been able to demodulate the signal that looks similar to the signal I get from the source:
I'm trying to get this into a repeating string of 1s and 0s (the whole telegram is 38 bytes long and it continuously repeats). I've tried to use a clock recovery block in order to have only one byte per sample, but I'm not having much luck. Using the M&M clock recovery block, the whole telegram sometimes comes out correct, but it is not consistent. I've tried to adjust the omega and Mu values, but it doesn't seem to help that much. I've also tried using the Polyphase Clock sync, but I keep getting a runtime error of 'please specify a filter'. Is this asking me to add a tap? what tap would i use?
So I guess my overall question would be: What's the best way to get the telegram out of the demodulated fsk signal?
Again, pretty new at this so please let me know if I've missed something crucial. GNU flow graph below:
You're recovering the bit timing, but you're not recovering the byte boundaries – that needs to happen "one level higher", eg. by a well-known packet format with a defined preamble that you can look for.
I'm working with a ELM327 and I'd like to be able to set the header and data portions of CAN messages to be sent. I see that there is a code for setting the header for messages
SH xxyyzz
But I'm having trouble finding out how to set the data portion and control when the message gets sent.
Do these both occur when I send a ASCII request for a PID with extra characters for the data field?
And would that use the header that was set by the SH command?
Is there a better way to do this?
Datasheet: http://elmelectronics.com/DSheets/ELM327DS.pdf
If you're using the ELM327, and you're on a protocol such as J1850 vpw, or J1850 pwm (older than 2003 CAN vehicles).. Then you will use this to set the header.
The header will consist of xx yy zz
xx = priority of message (i.e. 68)
yy = Target address of module you want to talk to (i.e. 5A)
zz = Sender address, which can usually be F1
So your command would look like this ATSH 68 5A F1
This sets the header.. Now you want to send data. Any data you send from now on will use that header, and send the data to that module.
So if you wanted to get the RPM's, you can just send 01 0C
You will get something like 41 0C 23. The last data byte is the value of RPM's. You will have to figure out the formula to convert this into a human readable format though.. A lot of information can be found here..
https://en.wikipedia.org/wiki/OBD-II_PIDs
By the way, if you're communicating on a CAN network, you would just use the module ID as the header.. ATSH 7E0, then send your data. all vehicles 2008+ are CAN.. some 2003-2007 are also.
This might be an old question, but I just found an online link which describes in detail how to send arbitrary CAN messages using the ELM327. So anyone (like me) coming past that question can still find a valid answer.
Look here for details on send arbitrary CAN messages with the ELM327:
https://www.elmelectronics.com/wp-content/uploads/2017/11/AppNote07.pdf
Best
If you're using an ELM327 chipset, you need to call ATSH or AT SH, to set the header first. Then send the message separately (The data bytes).
https://www.sparkfun.com/datasheets/Widgets/ELM327_AT_Commands.pdf
I am new to CAN protocol, going through the Robert Bosch's CAN Specification ver2.0 Part B. I can't understand the following lines on page 63
" Note:
Start up / Wake up:
if during startup only one node is online, and if this node transmits some message, it will get no acknowledgement, detect an error and repeats the message. It can become 'error passive' but not 'bus off' due to this reason."
As far as I understand when a transmitter detects an error(like Acknowledgement error) it retransmits the message and also increments the transmit error count (TEC) by 8. So if there is only one node then its TEC should increase by 8 everytime it transmits a message and should go into 'bus off' condition once TEC goes above 255.
Can someone please explain why the specification says it can only go 'Error Passive' but not 'Bus off'?
I think you missed this part of the specification:
"Exception 1:
If the TRANSMITTER is 'error passive' and detects an ACKNOWLEDGEMENT ERROR because of not detecting a 'dominant' ACK and does not detect a 'dominant' bit while sending its PASSIVE ERROR FLAG.
"
In this case, the TEC is not changed!
So, in your case, when the only node in the network re-transmits every time and the TEC becomes >= 128, it becomes 'error passive'. Then the above exception case becomes valid! And the TEC is no more changed! Hence no 'bus off'.
Yes, that is correct as if the Tx ECU is not receiving any ACK from any ECU in the CAN network then it will stay in Error passive state.
Because the Networking protocol needs when more than one systems are available in CAN network and if no ECU available in the network, then it is not meaning as the ECU is having an issue, so instead of going to CAN bus off state it should stay in Error passive state.
To know more about CAN error, you can follow the below link: