$130 Bosch 4.9 sensor CAN-bus WB
 

Wideband Controller | LSU 4.9 | CJ125 | Lambda meter | ALM-Board

A while ago I have managed to read the CAN bus info from the MS3 with an Arduino compatible microcontroller. It really wasn't all that difficult, especially since I had a code-base I could download.
Feeding data into the MS doesn't seem to be all that much more difficult. The attached CAN-enabled WB sensor seems to be fairly easily configurable. So in theory I would ASSUME that it should be possible to make this work.

Now here's my dilemma: I don't understand the CAN bus protocol at all. In order for me to put in the work to learn it, I would like to be reasonably certain that the time and effort aren't wasted. That means something useful, other than pure knowledge, would have to come out of it- for example a cool WB sensor directly hooked up via CAN bus.

A search on the MSEXTRA forums yields no useful information on this.

Does anybody here have enough knowledge of CAN bus protocol to make a quick judgement?

CAN is a pretty simple protocol. You might be able to pull out the information you need from the TinyIOX module firmware that has a serial input and CAN output for Innovate widebands.

I don't think their FW is public domain. Just checked their website and the FW I could find looks like it's already compiled. Or maybe I'm missing something? If so I would appreciate a pointer!

In for results.

You can check out this crazy project using a teensy board:

https://github.com/merkur2k/MSCan_Gauge/tree/teensy

It's doing a boat load of stuff over CAN BUS.

Just FYI Bowling and Grippo are working on a Wideband module that will work better then anything else on the market in the sub $5000 category. It should work over the MS can bus perfectly and be far more configurable and do more error checking then the other widebands on the market. It will use the Bosch 4.9 sensor, have a price point between $250-500, and should be out by the end of the year. I am hoping to get my hands on an alpha version on it in the March-May time frame. If what all Bruce has let on it will do, I will be getting rid of all my AEM and Innovative widebands in all my cars.

Sounds interesting, but....
$500 (because we know where their pricing is headed since MS-Pro) vs. $130. We're driving Miatas, so that means we're on a budget.
$370 for being more configurable and doing more error checking? That's almost a complete set of tires!

Well it seems Bruce has actually got a site up with info. Here is more information about widebands then you will probably ever want to know.

The real thing is all sub $5000 widebands at the moment are horribly inaccurate for many reasons and most vendors don't tell you that. They also do not do any corrections based on sensor temps and such. After listening to Bruce talk about it at the Megameet I now trust widebands even less.

I'm extremely curious as to the nature of the horrible inaccuracy.

I ask only because, several years ago, I got really bored and ran an OEM-type 4 wire narrowband sensor in parallel with my LC-1, which was about a year old at the time (having recently replaced an AEM UEGO which was, by any objective measure, not an especially good product.)

Presupposing that, by its nature, the narrowband sensor is always accurate at the stoichiometric point, I datalogged the two for comparison, to see if the LC-1 always reported crossing 14.7 at the same point as the narrowband. Aside from a relatively trivial amount of lag, I observed it to be pretty much dead-on-balls accurate, at least at the stoich point.

I honestly can't explain it because there is a ton of technical math involved that is a good bit above my level of understanding. I wish they would get the video of Bruce's wideband presentation from the MegaMeet up. The parts I sort of understand is that the Nernst cell and oxygen pump cell have a lot of variation based on a million things. Temperature of the wideband plays a huge part into it. Most of the variations and issues can be worked out an compensated for, but manufactures don't do any of it. I honestly suggest giving this site a read over if you have some time.

Looking at the documentation for that Wideband controller, it seems it should work with Megasquirt. You probably have to set its CAN bus bitrate to 500kbps and send "standard" 11-bit ID's (as opposed to the default 29-bit "extended" frames), but it looks like there are settings for that.
At least my MS3Pro runs at 500kbps and I haven't seen anywhere that can be changed, and it afaik only receiving "standard" (not extended) frames is supported.

If I read things right, you get the lambda value (or maybe the AFR, not sure) as a 16-bit unsigned little-endian int value (L2U) at 2 bytes offset, which you divide by 4098 (or more precisely, multiply by 65535 and divide by 16). It also gives a bunch of other data with varying degrees of usefulness for the ECU.

Thanks jstck!
Looks like I'll have to start reading stuff now...

Sorry, I thought their code was open source. Rev knows the answers to the questions your asking but I'm not sure if he's willing to share that info since it's similar to a product he sells.

Yeah, I would understand Rev not chipping in here.

So a quick overview.. it won't work unless the code is opened.

Just because it speaks CAN doesn't mean it will speak MSCan.

In MSCan you're writing directly to memory. When you set up Wideband over CAN in Tunerstudio, you're telling MS to "Broadcast a request packet". The req contains the address (block:offset) of where the AFR ratio is stored on the MS. To respond, you do a msg_write to block:offset with data of the AFR.

As far as functionality.. I wrote a library to read LC1's serial stream, display it on my gauge (4strings - yeap, that's my original code) with a difference between what MS3 was reading through analog vs the digital stream. My LC1 was well grounded, but the readings were surprisingly accurate. I don't recall seeing an offset difference of more than .1 AFR for longer than a few MS, which could have explained by buffer (and when I say a few MS, I mean the image was ghosted).

I have read most of the site linked to. It's heavy on theory, and talks a great deal about what makes it the perfect wideband sensor with regard to the potential shortcomings of lesser designs. (eg: the AEM, which lacks free-air calibration, and pretty much every other system which doesn't use an external thermocouple).

What I didn't see was any discussion at all, even in the abstract, as to the magnitude of the improvement of these design features, nor the conditions under which they are manifest. Are we talking about a 0.5% improvement in accuracy? 2%? 10%? And is this across the board, or only at cold idle, or only at WOT when EGT is > [some large number], or only when driving up a 6% grade at part-throttle on a balmy spring evening just after a rain as the swallows sing faintly but distinctly in the distance?


To a certain extent, it reads like a site meant to overwhelm the casual reader with the impression that "I know what I'm talking about," without actually providing much in the way of useful facts.



Edit: The B&G article spends a great deal of time waxing on about temperature and the need for an external thermocouple. At the very end, they acknowledge that this isn't the only way to do it. Sensor temperature can be estimated with a high degree of accuracy my measuring the resistance across the reference cell. This is how the OEMs do it, as well as the Innovate LC-2. This method actually reduces measurement uncertainty somewhat (as compared to an external thermocouple) by taking into account the operation of the sensor heater.

How do I alpha

I seriously doubt that they will open up their code. So we have the same problem as with all the others: No direct communication.
We could read it over serial (or in this case SCI) and then send it via CAN to the MS. Just like Rev or TinyIOX do.
So in order to save $60 as compared to an LC-2 you'd have to deal with an unknown piece of electronics. Meh.

Now if the sensor that Lars announced ends up on the $250 side of the range rather than the $500 side it would be worth it. We'll see, but I won't be holding my breath.

That is one of the two overall ways to get CAN data into Megasquirt (or any ECU), one device (MS) saying "hey, device with ID 100, give me data from table 111 offset 222" and the other device (WB controller) responding. This is what you set up in the "CAN EGO, GPS" menu item / dialog. MS can do this for a few specific things (EGO, GPS, VSS and Gear#) plus a bunch of "generic values" (under "CAN Parameters") that you can then use in various places.

The other method is just listening on data being broadcast, which is what you set up under "CAN receiving" where you specify an ID (the ID of the WB), an offset (the offset in the 8-byte data packet), and how the data is formatted. You can apply a "linear transformation" to map the data from some input range to whatever unit is needed.
This is what you would do for this WB controller, which just does broadcast stuff 100 times a second without anyone asking it for anything. Store this value as one of the CAN ADC items, and then use that as the EGO port under "AFR / EGO Control".

The thing that seems a bit odd to me is the data format, where "full output" (65535) corresponds to lambda 16.0. Making that into an AFR is just some math away (something like AFR = input * (16 * 14.7) / 65535) but that will have to be "simplified" a bit since Tunerstudio only accepts integer divisors/multipliers (+/-32767). Losing the 5th significant digit of the AFR value should not be much of a problem though.

The PWC has been "almost there" for about 5 years. I grew tired of waiting, and made my own. Direct CAN comms to the ECU, 4.9 sensor support, and thorough details about the sensor status, including heater, Nerst cell, pump cell, vground status.

The PWC may be a million times better than the current offerings on the market, however it says it requires a "Calibrated" sensor to work properly. I don't think this will fly well with a lot of people.