Bug when send Can Frame

Hi,
thanks for the update, but when I send a CAN frame I always receive the same Message ID
if i send
64: 08 01 01 01 EF
or
2EF: 01 01 01 01
I always receive :
18DB33F1: 08 01 01 01 EF
18DB33F1: 01 01 01 01
but I should have the same ID of what I send

What CAN adapter you are using?

Are you using 11 or 29 bit identifiers?

I use an OBD link mx + and I tried it on 11 and 29 bits and I got the same frame ID on the CAN bus. I tried it with the Android Version and the Windows version and same bug.

I will run some more tests, but on quick test when receiver is a MaxxECU, I cannot reproduce this problem.

I may have found this problem with OBD2 adapter sending a CAN frame. Fix will be in next release.

One not though, Using a ELM327 OBD2 device as CAN adapter while sending frames is very inefficient. In practise, these adapters are used in ‘Monitor All’ mode to receive CAN frames, and when you send a CAN frame, the following will happen:

  • Monitor All mode is stopped
  • wait for a reply to verify that Monitor All mode has been stopped
  • set a right header
  • wait for a reply
  • send the CAN frame data bytes
  • wait for a reply
  • restart Monitor All mode

This means that every time you send a CAN frame with these adapters, there will be a noticeably delay in received data. Depending on your use-case this may- or may not be a problem, but in typical vehicle setup this will show as ‘halt’ in incoming data stream.

Just to be clear, the above applies to ELM327 OBD2 adapters. Any other CAN adapter type is able to send CAN frames without extra delays.

That’s ok. We just need to be able to send CAN message with the right ID.
thanks a lot :wink:

Hi,
Do you know when will be the next release on Android ?

Should be out now.

I have tested it again with the version 2.1.9 and the error is always here. Every CAN frame we got on the Car is always on the same ID “18DB33F1” with the OBD link Mx +.
I have tried the same Frame of the last time 64: 08 01 01 00 and i the Car got 18DB33F1 : 08 01 01 00 but it should be 64: 08 01 01 00.

i have done some other test and if i send example 164: 01 01 i got 18000164: 02 01 01 where the first byte is the length and I should not be receiving this
if i send 064: 02 02 I got 18DB33F1: 02 02 02
but if before the send of 64: 02 02 i have send the 164: 02 02 02 the respond will be 18000164: 02 02 02 every time
if i send 264: 02 02 the ID will be send on 18000264 so after that if i send every ID less than 100 it will take the last ID so i got 18000264 for every ID less then 100 .
Every thing i got with 18000… is when i’m connected in extented but when i’m connected in standard the same thing arrive but without the 18000… So if i send 123: 02 02 02 i got 123: 02 02 02 and if after i send 45: 02 01 30 i got 123: 03 02 01 30. i need to send something over 100. And every thing is on the protocol ISO 15765. if i’m on the ISO 11898, I send same thing but now I got it without length and that is ok. but the ID have the same problem

And Can you tell me how i can send a variable value in Can Frame ?

There is something different on your test setup than mine. I will try to investigate further, but not sure if I can find anything more.

To send varying data, make a CAN XML description file that describes the values in CAN frames. Then you can use the triggers and actions system to change a value in RealDash. When value changes, the corresponding CAN frame is sent automatically.