OBDSim now supports multiple ECUs and trouble codes

**Curiosity** · 04-04-2010, 12:06 AM

Padding out the remaining 1 or 2 codes with zeros is correct. The DTC count will determine how many are valid.

**chunkyks** · 09-12-2010, 12:35 AM

I'm fairly certain that I've now sorted out multiprotocol support in my sim. The hardest bit was this code, and I'd appreciate any comments anyone has on it. Saliently, stuff that I worry might be wrong is mostly the ecu addresses.

In my struct, ecu->ecu_num starts at zero and goes up incrementally [first ecu appears at ecu_num 0, second is at ecu_num 1, etc]. Currently the maximum number of ecus is six, but that's just a #define.

11 bit can ecu addresses are good [via lots of discussion in this thread]
I'm not so sure about 29 bit can [I just add the ecu num to 0x18DAF110]
I'm also not sure about J1850PWM/VPW or ISO14230, where I just add the ecu num to 0x10. In the samples I've seen, ecus end up with addresses $10, $18, $28, so obviously just adding ecu num to 0x10 doesn't entirely correlate with the example I've seen, but am I actually wrong?

Code:

int render_obdheader(char *buf, size_t buflen, struct obdiiprotocol *proto,
        struct obdgen_ecu *ecu, unsigned int messagelen, int spaces) {

        unsigned int ecuaddress; //< The calculated address of this ecu
        unsigned int segments[4]; //< If the address needs to be split up

        switch(proto->headertype) {
                case OBDHEADER_J1850PWM:
                        ecuaddress = ecu->ecu_num + 0x10;
                        return snprintf(buf, buflen, "41%s6B%s%02X%s",
                                spaces?" ":"",
                                spaces?" ":"",
                                ecuaddress, spaces?" ":"");
                        break;
                case OBDHEADER_J1850VPW: // also ISO 9141-2
                        ecuaddress = ecu->ecu_num + 0x10;
                        return snprintf(buf, buflen, "48%s6B%s%02X%s",
                                spaces?" ":"",
                                spaces?" ":"",
                                ecuaddress, spaces?" ":"");
                        break;
                case OBDHEADER_14230:
                        ecuaddress = ecu->ecu_num + 0x10;
                        return snprintf(buf, buflen, "%02X%sF1%s%02X%s",
                                (unsigned)0b10000000 | messagelen, spaces?" ":"",
                                spaces?" ":"",
                                ecuaddress, spaces?" ":"");
                        break;
                case OBDHEADER_CAN29:
                        ecuaddress = ecu->ecu_num + 0x18DAF110;
                        segments[0] = (ecuaddress >> 24) & 0xFF;
                        segments[1] = (ecuaddress >> 16) & 0xFF;
                        segments[2] = (ecuaddress >> 8) & 0xFF;
                        segments[3] = (ecuaddress >> 0) & 0xFF;
                        return snprintf(buf, buflen, "%02X%s%02X%s%02X%s%02X%s%02X%s",
                                segments[0], spaces?" ":"",
                                segments[1], spaces?" ":"",
                                segments[2], spaces?" ":"",
                                segments[3], spaces?" ":"",
                                messagelen, spaces?" ":"");
                        break;
                case OBDHEADER_CAN11:
                        ecuaddress = ecu->ecu_num + 0x7E8;
                        return snprintf(buf, buflen, "%03X%s%02X%s",
                                ecuaddress, spaces?" ":"",
                                messagelen, spaces?" ":"");
                        break;
                case OBDHEADER_NULL:
                default:
                        return 0;
                        break;
        }
        return snprintf(buf, buflen, "UNKNOWN%s", spaces?" ":"");
}

Any thoughts would be welcome,
Gary (-;

**chunkyks** · 09-12-2010, 01:14 AM

Also I finally got around to figuring out how to cross compile, targetting windows. This binary works in wine, so I'd expect it to work in windows correctly. Should demonstrate multiple protocols:
http://icculus.org/obdgpslogger/down...2010-09-11.zip

To use, enjoy the "ATSP{n}" or "ATSPA{n}" commands.
Changes are reflected in "ATDP" and "ATDPN".
The "auto" stuff is just cosmetic; if you specify you want ATSPA7, then the protocol is reported as being "auto", but will communicate as the protocol you specified - it's never going to dynamically change to another protocol.

Obviously other than ATDP and ATDPN, you'll want to send ATH1 to get something out that changes according to protocol. For example, here's a discussion I just had with my sim:

Code:

>ATSP1
OK
>ATDP
SAE J1850 PWM
>ATDPN
1
>0100
41 6B 10 41 00 FF FF FF FF
>ATH0
OK
>0100
41 00 FF FF FF FF
>ATSP2
OK
>ATH1
OK
>0100
48 6B 10 41 00 FF FF FF FF
>ATDP
SAE J1850 VPW
>ATDPN
2
>ATSPA3
OK
>0100
48 6B 10 41 00 FF FF FF FF
>ATSP8
OK
>ATDP
ISO 15765-4 (CAN 11/250)
>ATDPN
8
>0100
7E8 06 41 00 FF FF FF FF
>ATSPA7
OK
>ATDP
Auto, ISO 15765-4 (CAN 29/500)
>ATDPN
A7
>0100
18 DA F1 10 06 41 00 FF FF FF FF
>

Have fun,
Gary (-;

**chunkyks** · 09-12-2010, 01:32 AM

One other thing; as usual, all the details of what obdsim supports [such as how to work multiple generators, or what AT commands it understands] are available online here:
http://icculus.org/obdgpslogger/manp...der/obdsim.txt

Gary (-;

**remus08** · 09-12-2010, 03:05 PM

Really nice work Gary!
I will test that with my software soon.
I let you know if somethings works bad but everythings seems good

**chunkyks** · 09-12-2010, 03:46 PM

remus08; do I remember right seeing that you have a sim you've written, too? Do you still use it?

What features would I have to implement to get you using mine instead? :-D

Gary (-;

**remus08** · 09-13-2010, 12:04 PM

My main topic is to create an OBD software, not a simulator lol.
Yours seems more powerful, and now you provide a version compatible with Windows, it should fine. Reading your post I've also found a problem with "ATSPx" response in my software..
ELM chipset are really tricky, following the protocol used, the frame can be really different, lot of test case are needed to have a good test covering...

**chunkyks** · 09-13-2010, 03:33 PM

Well, it is possible that my behaviour on ATSPx is wrong; I also always return success, and it's possible it might fail in some cases

Gary (-;

**remus08** · 09-13-2010, 04:06 PM

No, I don't think so, ATSPx command will always respond "OK", it's just a configuration, the ELM chipset take care of your preferences, the negative response will append on the connection which occurs when you send 0100 frame

Code:

8.624820 > ATSP5
8.646734 < OK
8.646773 < 
8.674097 < >
8.689836 > ATH1
8.706358 < OK
8.706399 < 
8.706422 < >
8.739787 > 0100
9.638272 < BUSINIT:ERROR

Here an example I've done on a CAN vehicle which I tried to force in KWP, the connection failed! Now I have to try with your software.
About ECU address to be more reallistic, a KWP car will often include 2 ECU at 0x10(ECM), 0x18(TCM), a CAN 11 bit 0x7E8 (ECM) and 0x7E9 (TCM). For 29 bit can, I have to check, I let you know...

PS: I never see a vehicle with 2 ECM but maybe a bugatti vairon has... ;-)