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. |
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: Code:
SIDL = (lowByte((offset << 5)) | B0001000); //set IDE bit change to |
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.
Code:
7 1FC00 00 81 81 29 01 00 00 00 03 I sent an email to Ecotrans support for help- let's see what they get back with. |
Originally Posted by stefanst
(Post 1311184)
Code:
unsigned char stmp[8] = {0x81, 0x81, 0x29, 0x01, 0x00, 0x00, 0x00, 0x03}; 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. |
I'm putting my money on SAE J1939, something in EID* is malformed (currently 0x00) and the packet is being discarded.
|
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. |
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. |
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...
|
I checked the manual and it looks like it should be 1 8-byte frame
|
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. |
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. |
No response from their customer service either?
At least that test suggests it's unlikely to be "accidentally reprogrammed"... |
I'm wondering if the step "reprogram then reset" must be strictly adhered to.
|
Originally Posted by gooflophaze
(Post 1311939)
I'm wondering if the step "reprogram then reset" must be strictly adhered to.
Originally Posted by ALM Manual
4) If you modified the baud rate, you need to reopen USB-CAN device, and the close the ALM
power and reopen reset ALM. |
Originally Posted by stefanst
(Post 1312079)
So I could have it run through the whole address space again, just modifying the protocol to 11bit....
|
After some back-and-forth, I received an answer from tech support that may help shedding some light:
I have tried to modify the ID, and there may be some mistakes. The manual give a example:81 81 29 01 00 00 00 04, you should input 81 00 29 01 00 00 00 04. The data which is modified means the broadcast rate. Pls try it again. |
Well that's just silly. Any luck?
|
Didn't have time to try yet.
|
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! |
All times are GMT -4. The time now is 12:40 PM. |
© 2024 MH Sub I, LLC dba Internet Brands