I am trying to make a software, which runs under Windows and communicates with an ELM327 device. I created the first version and I went in my SMART ForTwo (SMART 451) vehicle and I managed to connect with the Instrument Cluster (Transmit CAN ID is 782, Receive CAN ID is 783). However I have a huge problem with Flow Control. Here is the log:
TX: ATI
RX: ELM327 v1.5a
TX: ATE0
RX: ATE0 OK
TX: ATSP6
RX: OK
TX: ATH1
RX: OK
TX: ATL1
RX: OK
TX: ATCFC1
RX: OK
TX: ATFCSM0
RX: OK
TX: ATAL
RX: OK
TX: ATSH782
RX: OK
TX: ATCRA783
RX: ?
TX: ATST64
RX: OK
TX: 1092
RX: 783 02 1A 87
TX: 1A87
RX: 783 10 16 5A 87 05 6E 00 08
I used another tool and I saw that the ELM327 device sends the Flow Control Frame, immediately. It is like this:
891.438 782 02 1A 87
891.444 783 10 16 5A 87 05 6E 00 08
891.444 782 30 00 00 00 00 00 00 00
As you can see - Flow Control frame is sent at exactly the same time as the First Frame, that is sent from the other device. I am sure that the other device has a problem to receive the "Flow Control" frame.
I studied the ELM327 documentation, but did not find any info about how to delay the Flow Control frame.
How should I correctly send the request "1A 87" and receive the response?
It's an old post but might help others!
This is my Experience with First Frame (FF) and Flow Control (FC) on MCP2515 connected with SPI.
First of all you should always send the FC message after the FF message and not in the same time.
Secondly the diagnostic reader can use the ID in the ECU response frame to continue communication with a specific ECU. In particular, multi-frame communication requires a response to the specific ECU ID rather than to ID 7DF. In the easy language you should not send your FF message with ID 7DF and you should address the exact ECU that you want to receive the consecutive frames. For instance requesting car VIN (based on real information from Golf VII):
7DF 02 09 00 00 00 00 00 00 //sending request
7E8 10 14 49 02 01 57 56 57 //receving from main ECU
7E0 30 00 00 00 00 00 00 00 //adressing the main ECU and not 7DF anymore !!
7E8 21 5A 5A 5A 41 55 5A 45 //consecutive messages are sending by 7E0!!
7E8 22 50 35 33 30 36 38 35
Hopefully it helps!
It's very easy, I guess..
Use the ATCFC0 command, and then you can process all the response frames from the control unit, and you need to manually send the flow control frame.
Related
I am trying to remote authentication for tachograph. I have a problem between tachograph and can bus communication. i am successful open session 10 7E and send company card ATR. But when i passed to authentication of company card.
i send : 0x31,0x01,0x01,0x80,0x03.
tacho respond: 10 0C 71 01 01 80 04 00
i send fc : 30 00 14 00 00 00 00 00
but tacho not respond me. Can anyone give me any idea?
I'm struggling with an old radiation sensor and his communication protocol.
The sensor is event driven, the master starts the communication with a data transmission or a data request.
Each data telegram uses a CRC16 to check only the variable data block and a CRC8 to check all the telegram.
My main problem is the crc16, According to the datasheet the poly used to check the data block is: CRC16 = X^14 + X^12 + X^5 + 1 --> 0x5021 ??
I captured some data with a valid CRC16 and tried to replicate the expected value in order to send my own data transmission, but I can't get the same value.
I'm using the sunshine CRC calculator trying any possible combination with that poly.
I also try CRC Reveng but no results.
Here are a few data with the correct CRC16:.
Data | CRC16 (MSB LSB)
14 00 00 0A | 1B 84
15 00 00 0C | 15 88
16 00 00 18 | 08 1D
00 00 00 00 | 00 00
00 00 00 01 | 19 D8
00 00 00 02 | 33 B0
01 00 00 00 | 5A DC
08 00 00 00 | c6 c2
10 00 00 00 | 85 95
80 00 00 00 | 0C EC
ff ff ff ff | f3 99
If I send an invalid CRC16 in the telegram, the sensor send a negative acknowledge with the expected value, so I can try any data in order to test or get more examples if needed.
if useful, the sensor uses a 8bit 8051 microprocessor, and this is an example of a valid CRC8 checked with sunshine CRC:
CRC8 = X^8 + X^6 + X^3 + 1 --> 0x49
Input reflected Result reflected
control byte | Data |CRC16 | CRC8
01 0E 01 00 24 2A 06 ff ff ff ff f3 99 |-> 0F
Any help is appreciated !
Looks like a typo on the polynomial. An n-bit CRC polynomial always starts with xn. Like your correct 8-bit polynomial. The 16-bit polynomial should read X16 + X12 + X5 + 1, which in fact is a very common 16-bit CRC polynomial.
To preserve the note in the comment, the four data bytes in the examples are swapped in each pair of bytes, which needs to be undone to get the correct CRC. (The control bytes in the CRC8 example are not swapped.)
So 14 00 00 0a becomes 00 14 0a 00, for which the above-described CRC gives the expected 0x1b84.
I would guess that the CRC is stored in the stream also swapped, so the message as bytes would be 00 14 0a 00 84 1b. That results in a sequence whose total CRC is 0.
I'm trying to use my smartphone to move my cars windows up and down. I recorded the CAN traffic two times by using AT MA. First time I just turned the ignition on. The second time I pushed the buttons for the electric windows.
I guess the PIDs for the window are the ones which didn’t occur in my first log file…
Now I want to try this by sending the bytes back but how can this be done with the ELM 327?
This is a message I received:
400 23 00 00 00 00 00 00 00
I already tried to set the header by doing:
AT SH 400
And then I wrote the remaining bytes to the stream:
23 00 00 00 00 00 00 00
But this seems not to be the cheat…
Cheers,
Stefan
I'm programming a low level communication with an Epson tm-t88iv thermal printer on a Linux device, which receives only hexadecimal packages. I have read the manual trying to understand how the checksum is built but i can't manage to recreate it.
the manual says that the checksum are 4 bytes representing the 2 bytes sum of all the data in the package sent.
I have currently four working examples I found by listening to a port on a windows computer with a different program. the last 4 hexadecimals are the checksum (03 marks the end of the data and is included in the checksum calculation, according to the manual).
02 AC 00 01 1C 00 00 03 30 30 43 45
02 AC 00 00 1C 80 80 1C 00 00 1C 00 00 1C 03 30 32 32 31
02 AD 07 01 1C 00 00 1C 31 30 03 30 31 35 33
02 AD 00 00 1C 80 80 1C 00 00 1C 00 00 1C 03 30 32 32 32
I have read somewhere that there is a sum32 algorithm but i can't find any example of it or how to program it.
Wow, this is a bad algorithm! If someone else finds himself trying to understand Epson's terrible low-level communication manual, this is how the check-sum is done:
The checksum base is 30 30 30 30
Sum in hexadecimals all of the data package (for example, 02+89+00+00+1C+80+80+1C+00+01+1C+09+0C+1C+03 = 214)
Then separate the result digit by digit, if its a letter add 1 to the value (for example B2 would be 2|1|4).
sum it to the checksum base number by number starting from right to left (this would be a checksum of 30 32 31 34).
Note: It works perfectly, but for some reason the examples I posted above don't seem to match so much. They are all the printers response, but slightly after it got a hardware problem and had to be reformatted by technical support, so maybe it got fixed.
I hope it helps somebody somewhere.
How do you turn off the feature or stop the creation of all the .ddp files for your Delphi 7 forms? I read something about removing the designdgm60.bpl, but is that the only way? It seems that there was another way I can't remember any longer.
Update: I tried renaming the designdgm70.bpl and that just creates a ton of program errors.
Also, I'm using Delphi 7.2 on one computer and there is no design tab I can see unless its covered by something in CnWizards. 7.2 definitely creates the ddp files though.
DDP files are for Delphi diagrams (DDP stands for Delphi Diagram Portfolio) in Delphi 6-7. Delphi 5 used the DTI extension for this.
DDP files can have meaningful information. They don't get compiled into .DCU/.EXE./... as they are for documentation purposes only.
Did you create diagrams of components on your form/datamodule? I used to do that (to explain structure to co-workers) so I was actually really happy with the DDP files.
Before deleting them, inspect them to see if they contain documentation you want to keep.
You can safely delete them if they are 51 bytes long and the TDUMP of it looks like this:
000000: 07 18 44 45 4C 50 48 49 2E 44 49 41 47 52 41 4D ..DELPHI.DIAGRAM
000010: 2E 50 4F 52 54 46 4F 4C 49 4F 0F 00 00 E0 40 02 .PORTFOLIO....#.
000020: 01 09 06 09 55 6E 74 69 74 6C 65 64 31 06 00 02 ....Untitled1...
000030: 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
I suppose that it's impossible to turn off .ddp creation in IDE by built-in methods, but DDevExtensions tool includes this option (File Cleaner)
You can install DDevExtensions which is free.
There is an option which you can check that automatically deletes .ddp files.