Wideband O2 to CAN communicator

[humjaba]

Here is what my serial monitor looks like...

Code: Select all

ID: 33920
ID: 19662136
ID: 19662136
ID: 33920
ID: 33920
ID: 24642232
ID: 19662136
ID: 20219192
ID: 33920
ID: 33920
ID: 19662136
ID: 19662136
ID: 33920
ID: 33920
ID: 33920
ID: 19662136
ID: 20219192
ID: 33920
ID: 33920
ID: 19662136
ID: 19662136
ID: 33920
ID: 33920
ID: 33920
ID: 19662136
ID: 20219192
ID: 33920
ID: 33920

Unfortunately I won't have time to work on it more until tomorrow evening

[grom_e30]

do you have anything else attached to the bus? and are you using 'real time broadcasting' with the 'base message identifier' set to 1520 in tuner studio?

those do not sound like any i have come across

[Manu]

Hi,

It's look like you have noise. Did you twist the 2 CAN wires together ?

Regards,
Manu

[humjaba]

Hi all

I had some more time to fiddle with it today. I had my can running through about 20ft of wire, so i cut that down to 3 and it didn't make any difference, so I'm back to figuring out what these messages are. No other devices on the bus.

Turning CAN off in TunerStudio stops the messages. I was able to determine the other messages were mostly requests for data - notice the messages repeat. I was able to stop certain messages by, for example, disabling PWM polling, input port, output port, and pwm outputs in CAN parameters. Still working out the ID's - for these kinds of requests, are the ID's inconsequential? I was able to break out the extended message to_id and they correspond correctly when I change them in tunerstudio.

By shutting off all those options I was able to isolate the CAN Broadcast function... Turning it on does nothing - I guess you have to enable individual messages? Why are there only options for RPM, coolant, and "Alfa/Fiat/Lancia" ?? Is this something I'll have to discuss with mslabs? I was able to get RPM and coolant messages going, and they looked like this. 640 was RPM and 649 was coolant?

Code: Select all

ID: 640 Ext: 0
 To: 5
0070500016
ID: 640 Ext: 0
 To: 5
0061500016
ID: 640 Ext: 0
 To: 5
0060500016
ID: 640 Ext: 0
 To: 5
0061500016
ID: 640 Ext: 0
 To: 5
0066500016
ID: 640 Ext: 0
 To: 5
0051500016
ID: 649 Ext: 0
 To: 5
00100000016
ID: 640 Ext: 0
 To: 5
0059500016
ID: 649 Ext: 0
 To: 5
00102000016
ID: 640 Ext: 0
 To: 5
0056500016
ID: 649 Ext: 0
 To: 5
00102000016
ID: 640 Ext: 0
 To: 5
0067500016
ID: 649 Ext: 0
 To: 5
00102000016
ID: 640 Ext: 0
 To: 5
0064500016
ID: 649 Ext: 0
 To: 5
00102000016
ID: 640 Ext: 0
 To: 5
0064500016
ID: 649 Ext: 0
 To: 5
00102000016
ID: 640 Ext: 0
 To: 5
0064500016
ID: 640 Ext: 0
 To: 5
0047500016
ID: 649 Ext: 0
 To: 5
00102000016
ID: 640 Ext: 0
 To: 5
0052500016
ID: 640 Ext: 0
 To: 5
0060500016
ID: 640 Ext: 0
 To: 5
0063500016
ID: 640 Ext: 0
 To: 5
0069500016
ID: 649 Ext: 0
 To: 5
00102000016
ID: 640 Ext: 0
 To: 5
0060500016
ID: 640 Ext: 0
 To: 5
0053500016
ID: 640 Ext: 0
 To: 5
0067500016
ID: 649 Ext: 0
 To: 5
00102000016

Thanks

[jsmcortina]

Read up on "Megasquirt CAN". It is documented in the Manuals.

James

[humjaba]

Read up on "Megasquirt CAN". It is documented in the Manuals.

James

Thought I had read through all that... but I missed "1.4.x firmware". Gonna have to see if I can get that update.

[jsmcortina]

There is a manual specifically covering 29bit Megasquirt CAN.

James

[humjaba]

Yep, spent a lot of time in that today. Making some progress.

Some questions. For AFR, why does the megasquirt send two request packets if it's a 1-byte variable? If I enable "Fetch Innovate EGO Data via CAN", it sends two request packets - one to table 7, offset 252 (where I specified) and one to table 7, offset 260 (not expected).

Also, unless I'm not parsing this response correctly, the megasquirt is asking to store the response at table 7 (myvarblk), offsets 597 and 605 (myvaroffset)? Is this right? It doesn't seem to use this data if I make a response to that location.

If I broadcast a message to table 7, offset 252 I can see the result in tunerstudio... so what do I do with myvarblk and myvaroffset?

See attached raw messages from my megasquirt, requesting EGO data on table 7 offset 252.

Code: Select all

Type: 1 To: 10 Table: 7 Offset: 252
 Data0: 111
 Data1: 1001010
 Data2: 10101000
 Data3: 0
 Data4: 0
 Data5: 0
 Data6: 0

 Raw ID: 100000100001000010100111000
Type: 1 To: 10 Table: 7 Offset: 260
 Data0: 111
 Data1: 1001011
 Data2: 10101000
 Data3: 0
 Data4: 0
 Data5: 0
 Data6: 0

Thanks!


Edit: I forced my response to table 7 offset 252 and I got some nice smooth digital AFR goodness in my megasquirt. So I still need to figure out what the deal is with the myvarblk and myvaroffset, because this isn't an elegant solution. I took a quick cell phone video comparing analog vs digital in case anyone was wondering what the difference looks like. https://www.youtube.com/watch?v=hXu9RfWrqsU

In the meantime, I'm going to work on requesting some data from the MS, since my firmware doesn't have the 11 bit broadcasting...
Edit 2: Well that was easy. Got it pretty much first try. Looks like I won't need that 11 bit broadcast after all, though it would be nice.

[grom_e30]

what did you have to change to make the innovate stuff work? i had a quick try with the code you posted and it stated my lc1 was warming up but never spat out any afr data.

[humjaba]

what did you have to change to make the innovate stuff work? i had a quick try with the code you posted and it stated my lc1 was warming up but never spat out any afr data.

I haven't changed it from what's posted. If you're able, have it print out the two bytes raw and you should be able to interpret them manually according to the LC1 protocol floating around. Post them up here if you want - the status code should be bits 3, 4, and 5 in the first data byte.

[grom_e30]

B2 82 43 13 6 4D

thats raw data from my lc1 grabbed from mini term in tuner studio.

[racingmini_mtl]

...
Edit 2: Well that was easy. Got it pretty much first try. Looks like I won't need that 11 bit broadcast after all, though it would be nice.

It might have been easy but you're not using these things correctly:

• the CAN protocol
• the "Fetch Innovate EGO Data via CAN" function
• the EGO control to get the correct AFR from the preceding

You can keep it like that if you want and it will work until a new firmware version breaks your unintentional kludge. I would recommend others not to follow this.

I don't have time to go through each point in detail but you need to read more and might even need to look at the MS3 source code.

Jean

[humjaba]

I've been in Japan for the last week, so no progress on my front

It might have been easy but you're not using these things correctly:

the CAN protocol
the "Fetch Innovate EGO Data via CAN" function
the EGO control to get the correct AFR from the preceding

So that's pretty generic.. what part of the CAN protocol isn't being used correctly? I request values in the table, ECU returns values from table... I suppose if a firmware update changes the location of the values it would break but I don't see a way around that? And the values I pass for myvarblk and myvaroffset are the same as in the ECU because that's an easy/lazy way to parse it later, rather than keeping track of two addresses.

Fetch innovate EGO data via CAN function -- I mentioned this earlier.

For AFR, why does the megasquirt send two request packets if it's a 1-byte variable? If I enable "Fetch Innovate EGO Data via CAN", it sends two request packets - one to table 7, offset 252 (where I specified) and one to table 7, offset 260 (not expected).

Also, unless I'm not parsing this response correctly, the megasquirt is asking to store the response at table 7 (myvarblk), offsets 597 and 605 (myvaroffset)? Is this right? It doesn't seem to use this data if I make a response to that location.

If I broadcast a message to table 7, offset 252 I can see the result in tunerstudio... so what do I do with myvarblk and myvaroffset?

[jsmcortina]

Seems that you are ignoring or misunderstanding those offsets, that's a problem.

James

[humjaba]

Seems that you are ignoring or misunderstanding those offsets, that's a problem.

James

Maybe you can help point out where my misunderstanding is

I enable "Fetch innovate EGO data via CAN" function. I specify this data is located in Table 1, offset 1 of my device (for example).
In my device, I wait for a request addressed to Table 1, offset 1.
The MS3 sends a request for data addressed to Table 1 offset 1, and table 1 offset 8. ** I see bittertech had this same issue. Second byte is unused?
MS3 packets have myvarblk =7 and myvaroffset = 597 or 605
My device sends 1 byte response to table 8, offset 597.

Is something missing in my understanding of this process? My kludge ignores this whole thing and deposits AFR straight into running memory (table 7 offset 252), but as I mentioned, I know this is the wrong way. But putting it into offset 597 didn't seem to work.

[jsmcortina]

16 bytes are required for 8 widebands, hence the two requests.

Did you tell the ECU to process the AFR data by setting the input to CANEGO?

Attach your MSQ.

James