gooflophaze

Ah hell. Sorry - I'm tired and thinking of what I'm currently working on (standard frames). Put

SIDL = (lowByte((offset << 5)) | B0001000);

back into enable extended frames. And change..
EID8 = 0x00;
EID0 = 0x00;

I think that'll work.

stefanst

iTrader: (1)

You know I have NO idea what you're doing on my computer. For all I know you're taking over my network from Atlanta :-)

My setup now looks like this:
And there's no traffic again....

stefanst

iTrader: (1)

Alright - with your latest code changes we are indeed sending extended frames and they look just like what we would need to reprogram the ALM.
Alas, the ALM is not being reprogrammed. My guess is that the manual is not telling us the whole truth- something else is needed.

I sent an email to Ecotrans support for help- let's see what they get back with.

jstck

That should do the job, just as the "byte-banging" variant, as long as the ID is the right one. I didn't see any reference to that ID in the docs, but I'm guessing neither 0x1FFFFFFF nor 0x1FC00 are correct. I think it would be something in the neighbourhood of what it's sending "from".

A dirty way would be to just have it loop ID's over some range and see if anything bites. I'd start with 0xF000 to 0x10000, which is just 4000-ish id's to try.

gooflophaze

I'm putting my money on SAE J1939, something in EID* is malformed (currently 0x00) and the packet is being discarded.

stefanst

iTrader: (1)

My guess is that you both may be right.

I did try a simple address counter, but aborted at around 0x6000- that had taken an hour with sending each packet 5 times to make sure it gets heard.
I'll try the suggested address spaces and run another counter.

My curent thinking is that we must comply with SAEj1939 100%. It appears that this specification allows for sending a request to a specific address. My best guess is that I need to send the request to the address of the ALM unit.

A brief description of the SAEJ1939 header format can be found here:
https://www.kvaser.com/about-can/hig...-introduction/

I also found a library modified for sending SAEJ1939 messages from my CAN shield:
Sending J1939 CAN-BUS messages with Sparkfun CAN-BUS Shield | Wunderkammer

So I'll do some more reading on the SAEj1939 spec.

stefanst

iTrader: (1)

I'm still struggling with the safety aspect of reprogramming the board via CAN bus.
Working with the assumption that we can indeed reprogram it using the j1939 protocol by using a specific source and target address combo, that seems reasonably safe. It's already proven to be difficult to reprogram on purpose, so reprogramming by accident may be just as hard, or even impossible if certain address spaces are being avoided.

But what happens after the protocol gets changed to standard? Then we don't have the protection of the 29 bit addresses anymore. So if any other sensor on the engine CAN bus should happen to send out a data package that fits the "0x81 0x81" pattern our ALM controller changes settings to something random. Not a good thing....

BTW: So far no response from Ecotrons support, even though they had answered previous inquiries within 12h. I assume their support is in China.

gooflophaze

I'm also wondering if the reprogram sequence shouldn't be delivered in 8 1 byte frames instead of 1 8 byte frame. I've only glanced at the documentation...

stefanst

iTrader: (1)

I checked the manual and it looks like it should be 1 8-byte frame

gooflophaze

void J1939write (byte priority, byte edp, byte dp, byte pduf, byte pdus, byte srcaddr) {
byte SIDH, SIDL, EID8, EID0, DLC;

SIDH = ((priority & B00000111) << 5); // 8:5 first 3 bits priority
SIDH = SIDH + ((edp & B00000001) << 4); // bit 4
SIDH = SIDH + ((dp & B00000001) << 3); // bit 3
SIDH = SIDH + ((pduf & B1100000) >> 6) // bit 2-1

SIDL = (pduf & B0011100) << 2; // 8:6
// bit 5 is not used in sidl
SIDL = SIDL | B0001000; // set EID bit on 4
// bit 3 is not used in sidl
SIDL = SIDL + (pduf & B0000011) // 2:1, which means no shifting

EID8 = pdus; // hooray for direct byte copies
EID0 = srcaddr; // w000

DLC = 0x08; // how many bytes are we sending? 8 bytes

digitalWrite(CS_PIN, LOW);
SPI.transfer(0x40); // Push bits starting at 0x31 (TXB0SIDH)
SPI.transfer(SIDH); //0x31
SPI.transfer(SIDL); //0x32
SPI.transfer(EID8); //0x33
SPI.transfer(EID0); //0x34
SPI.transfer(DLC); //0x35
SPI.transfer(0x81); // data byte 1
SPI.transfer(0x81); // data byte 2
SPI.transfer(0x29); // data byte 3
SPI.transfer(0x01); // data byte 4
SPI.transfer(0x00); // data byte 5
SPI.transfer(0x00); // data byte 6
SPI.transfer(0x00); // data byte 7
SPI.transfer(0x03); // data byte 8
digitalWrite(CS_PIN, HIGH); // end write

digitalWrite(CS_PIN, LOW);
SPI.transfer(B10000001);
digitalWrite(CS_PIN, HIGH);

CANWrite(CANINTF, 0x00); // clear transmit interrupt
}

finally looked at the manual. that should give you a J1939 packet, assuming i'm not off by 1 somewhere.

stefanst

iTrader: (1)

So by now my Arduino went through the entire address space from 0x00 to 0x1FFFFFFF. Took more than 12 hours. No success. I was using the modified CAN library.
Next try is Gooflo's bit-banging code.

jstck

No response from their customer service either?

At least that test suggests it's unlikely to be "accidentally reprogrammed"...

gooflophaze

I'm wondering if the step "reprogram then reset" must be strictly adhered to.

stefanst

iTrader: (1)

Unlikely but possible. However this would only apply to a change in the baud rate. Which is somewhat understandable.

So I could have it run through the whole address space again, just modifying the protocol to 11bit....

jstck

Well, at least that address space is a lot smaller (just 2048 possible addresses).

stefanst

iTrader: (1)

After some back-and-forth, I received an answer from tech support that may help shedding some light:
It can't work if you use the wrong escape sequence - will try again tonight.

gooflophaze

Well that's just silly. Any luck?

stefanst

iTrader: (1)

Didn't have time to try yet.

noname4me

I have been meaning to start playing around with a similar project for months now. Bought a microcontroller, but haven't had time to actually start on the effort. Hats off to you for jumping into the deep end to figure this out!

That being said, did you look at the Spartan 2 WB controller from 14point7.com? $40 for a WB controller compatible with the LSU 4.9 O2 sensors (4.9 sensors sold separately) and looks to be a solid design, including providing data on operation of the heater, sensor temp, etc. Spartan 2 OEM

Multiple output options with their controller, but the best accuracy would be I2C from the Spartan 2 WB to an Arduino (or some similar microcontroller), then CAN bus to the MS3. 12 Spartan WB controllers can share a single I2C bus, so the solution can scale to per cylinder monitoring, if you want/need it.

For a more "out of the box" solution, read through the jbperf.com forums... you can actually use a TinyIOx or IO Extender board with the Spartan 2 WB controller in place of a generic microcontroller like an Ardunio + CANbus shield. This wouldn't be as fun as hacking/coding your own solution, but it already works and can even be configured using Tunerstudio.

Note, I did pick up on the jbperf forum that one should ideally combine the WB controller(s), I2C wiring bus wiring, and TinyIOx or IO Extender in one enclosure, then use external wiring for the CAN bus signals to the MS3. The CAN bus is much more resistant to interference/electrical issues on the bus vs I2C, so it makes sense to keep the I2C bus/wires as short as possible to avoid potential issues.

Good luck with your project!