rusefi.com

mck1117 wrote: ↑

Thu Dec 31, 2020 11:15 pm

The MCU is currently limited on the sample rate of the ADC. It can't really sample more at the same time without reducing accuracy or going to a faster MCU with multiple ADCs. The plug-in module is only ~$12, so it would be super easy to just plop two of them down on a single carrier board. Shared power supply and protection, but independent CAN transceivers both on the same bus.

The catch is that the MCU is actually an active participant in controlling the sensor - it's being controlled digitally, not in analog like the Bosch ASIC does.

I like that idea better. I tried looking at the repository for the schematics and board files but found nothing there. Maybe I can create a carrier board for twins.

SHOf429 wrote: ↑

Thu Dec 31, 2020 11:53 pm

I like that idea better. I tried looking at the repository for the schematics and board files but found nothing there. Maybe I can create a carrier board for twins.

https://github.com/mck1117/wideband/tree/master/board_carrier

I will ask a bit of a layman question, but is this WBo2 Controller board already supported in Tuner Studio in conjunction with the latest Proteus firmware? Because I don't see it on the drop-down list in the EGO Menu, but I don't know if I'm looking at it correctly because I don't know all the names that are there. Thank you very much for your understanding, I don't have a physical ECU yet, but I'm training on a simulator in Tuner Studio, trying to explore your hard work.

Matt, do you have any of these plug-in modules ready to go? I'd like 2 for my application, and development of the twin carrier board

blackbirdsr71 wrote: ↑

Fri Jan 08, 2021 5:51 pm

I will ask a bit of a layman question, but is this WBo2 Controller board already supported in Tuner Studio in conjunction with the latest Proteus firmware? Because I don't see it on the drop-down list in the EGO Menu, but I don't know if I'm looking at it correctly because I don't know all the names that are there. Thank you very much for your understanding, I don't have a physical ECU yet, but I'm training on a simulator in Tuner Studio, trying to explore your hard work.

No - that's a great question. The answer is a little boring because I actually reused the protocol for the AEM X-Series - so anything that supports the AEM X-Series wideband contollers (including rusEfi) already support this one too! The text in TunerStudio needs to get updated to make that clear, but if you flip the "enable AEM x series wideband" switch on the EGO page, the ECU will be able to read the sensor over CAN.

Hi,

Very nice project!
Would be nice to add an analog output 0-5V, related to AFR.

Hello! Great work on this controller! Are anymore available for sale or testing? I'll take one if so.

To people interested in getting their hands on one of these controllers: I'm waiting on a bit of testing to be completed before announcing wider availability. As soon as they're available, this thread will be the first to know!

Speaking of testing:

My Volvo race car has two O2 sensor bungs right next to each other, just after the turbo - I added the second some time ago especially for testing multiple wideband controllers/sensors at the same time. For this test I raised the idle to ~1800rpm, then varied the target air fuel ratio, while running completely open loop (no fueling correction by the ECU), comparing the lambda as measured by my AEM 30-4110 gauge, and the controller I'm developing. I then swapped the sensor connectors (but left the controllers as-is), to correct for any difference between the sensors, isolating the difference between the controllers.

Here is the result:
The X axis is the average (between two sensors) measured lambda, and the Y axis is the delta between the rusEFI controller and AEM (positive means rusEFI reads leaner than AEM). If there were an error in the sensor, you would see the two traces diverge in the swapped case (one would have positive error, the other negative). If a problem with the controller, the error would go in the same direction even when the sensors were swapped, as is seen here.

The math running in the controller matches the Bosch datasheet, and the controller checks out okay on the bench, so I'm not sure exactly where the error is coming from. More investigation required, to be continued! I also plan to compare against my AEM X-Series controller to see if the error is actually in the AEM gauge, not in this controller.

I am developing a carrier board to support dual controller modules. They will share the +5v power supply and the CAN output. Electrically, it will appear on the bus as two nodes. I added termination bits to the board as I imagine this will be one of few, if not the only, CAN device being used with rusEFI. My inspection of the Frankenso schematics did not show bus termination on the board.

Matt, how difficult would it be to modify the firmware on the module to give the second controller a unique ID? Then, how hard would it be to get the rusEFI firmware updated to read two sensors off the CAN bus?

Files will be uploaded as soon as I have them ready.

SHOf429 wrote: ↑

Tue Jan 19, 2021 2:34 am

I am developing a carrier board to support dual controller modules. They will share the +5v power supply and the CAN output. Electrically, it will appear on the bus as two nodes. I added termination bits to the board as I imagine this will be one of few, if not the only, CAN device being used with rusEFI. My inspection of the Frankenso schematics did not show bus termination on the board.

I think Frankenso does indeed have a terminator on board, but I'm not 100% sure. Proteus and MRE certainly have a terminator. For short busses you can get away with a single terminator no problem.

SHOf429 wrote: ↑

Tue Jan 19, 2021 2:34 am

Matt, how difficult would it be to modify the firmware on the module to give the second controller a unique ID? Then, how hard would it be to get the rusEFI firmware updated to read two sensors off the CAN bus?

That's already in the cards so that you can run multiple modules independently, which is functionally identical to two modules inside the same case each with their own CAN transceiver and a shared PSU. The only question is first time firmware update, since each module would need a different flag set in the config page of flash memory to indicate its index. There's a solderable jumper on the back of the board that's currently unused, but that could be used to offset the address by 1, so that two fresh-out-of-the-box MCUs will end up with different addresses.

SHOf429 wrote: ↑

Tue Jan 19, 2021 2:34 am

Files will be uploaded as soon as I have them ready.

There have been a few improvements changes to both the carrier board and module since they were fabbed, so I'm happy to do a review of your design before it goes off to the fab.

mck1117 wrote: ↑

Tue Jan 19, 2021 3:26 am

SHOf429 wrote: ↑

Tue Jan 19, 2021 2:34 am

Matt, how difficult would it be to modify the firmware on the module to give the second controller a unique ID? Then, how hard would it be to get the rusEFI firmware updated to read two sensors off the CAN bus?

That's already in the cards so that you can run multiple modules independently, which is functionally identical to two modules inside the same case each with their own CAN transceiver and a shared PSU. The only question is first time firmware update, since each module would need a different flag set in the config page of flash memory to indicate its index. There's a solderable jumper on the back of the board that's currently unused, but that could be used to offset the address by 1, so that two fresh-out-of-the-box MCUs will end up with different addresses.

You probably need the ability to set 8 or 12 CAN IDs to make eveyone happy....but it would be like a Parrado chart, 60% need 1 ID, 30% 2, 7.88% 4,0.1% 8, 0.01% 12. 0.0001% 18 something like that so more than 2 doesn't cost much market share but on the surface, but probably a few will pass as its not expandable to a dream setup they will probably never build. The basic motec M1 ECUs allow up to 18 O2 sensors for a setup like mine even though there is probably only about 1 race team on the planet that uses all 18.

Edit: forgot....after prototype phase a sealed robust enclosure is needed if you want to steal market share from the current leaders like AEM and 14point7 I think....and that is where costs come in. Some place like protolabs can mold housing pretty cheap in a pretty cheap aluminum tool that might be good for 10k parts before it needs repair or replacement.....but it you go over molder its more, then you have to raise the price to recoup capitol and profit to make it worth the risk and you're quickly at the 14point7 price point

Dual controller info...still working on the board layout.
Connector has been changed to a 20 pin device to support the 2nd sensor.
https://www.molex.com/molex/products/part-detail/pcb_headers/0348302001;jsessionid=mGUZriLKudcw3BvXRfAmKTp-ldN-4mSAH7vEA1_B.molex1

Digi-Key ordering info: More to come!

Offtopic, thinking out loud: .xlsx attachments are such a red flag, shall I prohibit .xlsx attachments altogether?

We have github, we have github wiki...

Also I would assume that separate development deserves a separate thread. Let's not mix original work thread with derived work content.

AndreyB wrote: ↑

Thu Jan 21, 2021 6:46 pm

Offtopic, thinking out loud: .xlsx attachments are such a red flag, shall I prohibit .xlsx attachments altogether?

have a little chill, man, xlsx isn't hurting anybody

mck1117 wrote: ↑

Thu Jan 21, 2021 6:51 pm

have a little chill, man, xlsx isn't hurting anybody

xlsx is hurting me for sure, I do not have any applications installed to open. In my opinion in 2021 https://www.google.com/sheets/about/ would be a better tool for sharing a spreadsheet on the internet.

As requested, further discussion of the dual carrier board will be here: https://rusefi.com/forum/viewtopic.php?f=4&t=1927

AndreyB wrote: ↑

Thu Jan 21, 2021 6:53 pm

xlsx is hurting me for sure, I do not have any applications installed to open.

This works well.
https://www.libreoffice.org/

The connector order info from Digi-Key, PDF format
[attachment=0]MX150 Connector Order.pdf[/attachment]

The Quest To Find The Error continues:

I set up the controller on the bench with a simple 330 ohm shunt resistor between Ip and Vm, to simulate a sensor's pump cell. Custom firmware then swept the pump driver current, recording both the current measured by the module (via the voltage drop between Ip and Rtrim), and the voltage drop across the 330 ohm resistor, which indicates the actual current flowing in/out of the module.
Here's the same data in a graph, X=[module mA], Y=[err]:
While not perfect, it's pretty darn good. Under 1.5% error across the full range, which is just about bumping up against the rated accuracy of the multimeter I used to measure the resistor and corresponding voltage drop, so we can probably count the current sense error as just about exactly zero.

The hunt continues!

Could it be tolerance errors accumulating in one or more resistors? Noise in the op-amp? Non-linearity in the STM ADC?

so you're off 0.02 lambda?

Looking at the AEM site I could find where they claim an accuracy? You might be looking at noise here, its certainly an error that is below where I would care.

Another point is unless you are switching back and forth between setups an offset is almost irrelevant. If the output is repeatable is a much more important question. you look at the reading, make changes, measure the result, move on.....you'd never know the number you were looking at was offset.

Just saying, it might not be broken and is almost certainly not broken enough to worry about or confirm without more samples and calibrated equipment.

mk e wrote: ↑

Wed Feb 10, 2021 7:03 pm

so you're off 0.02 lambda?

Looking at the AEM site I could find where they claim an accuracy? You might be looking at noise here, its certainly an error that is below where I would care.

Another point is unless you are switching back and forth between setups an offset is almost irrelevant. If the output is repeatable is a much more important question. you look at the reading, make changes, measure the result, move on.....you'd never know the number you were looking at was offset.

Just saying, it might not be broken and is almost certainly not broken enough to worry about or confirm without more samples and calibrated equipment.

No - that's the error in pump current sensing, not the actual observed difference in lambda. The 3 microampere offset at lambda=1 is an offset of only 0.0001 lambda. I went hunting for the much larger errors I'd seen, and this was confirmation that the hardware probably isn't the problem.

I didn't see an offset a lambda=1, I saw a gain error. As I got richer, this controller read progressively richer than my AEM X-Series. At 0.8 lambda, it indicated 0.04 lambda richer than AEM. That's a lot!

Hi there, trying to follow the progress. Does this mean we can fix the error using firmware or is there a resistor or some other hardware we need to add to correct the variance?

Lambo97 wrote: ↑

Wed Feb 10, 2021 7:17 pm

Hi there, trying to follow the progress. Does this mean we can fix the error using firmware or is there a resistor or some other hardware we need to add to correct the variance?

99% chance it's a firmware fix. The crux of the problem is that Bosch defines a mapping from pump current (driven and sensed by the controller) to lambda. You drive some amount of pump current to get the nernst cell to indicate stoichiometric, then look up in a table the resulting lambda as a function of current. The problem is there are TWO DIFFERENT MAPPINGS and we're not sure which one is the right one. In the rich region, they vary by 15%, which is very close to the difference I've seen between my AEM and this controller.

Dave and I are trying to get an answer out of Bosch about which curve is correct. We'll keep y'all posted!

mck1117 wrote: ↑

Wed Feb 10, 2021 7:11 pm

I didn't see an offset a lambda=1, I saw a gain error. As I got richer, this controller read progressively richer than my AEM X-Series. At 0.8 lambda, it indicated 0.04 lambda richer than AEM. That's a lot!

For me personally, as long as it repeats it would honestly make no difference. Best if its calibrated, but not sure how I'd ever know or care if it wasn't?

I am pretty sure AEM uses calibrated gas to test with but no idea how repeatable unit to unit they are. I used to be involved with calibrating other gas sensors and we used a chamber, pulled vacuum and filled 3 times then measured, we had a cal table we used in the software and made no effort to calculated what should be, just measured what was and moved on as each gauge had to be spot on.

Update 2/13: Spent many hours this week trying to get in touch with someone at Bosch on the phone. Sent many emails. No response so far. If anyone happens to know someone at Bosch who may be willing to help and is in the automotive sensor division, please get in touch with Matthew or I.

Update 2/23: still trying to get information out of Bosch, so far unsuccessfully. Starting to try and figure out a somewhat accurate way to make calibration gases for testing

blundar wrote: ↑

Tue Feb 23, 2021 3:23 pm

Starting to try and figure out a somewhat accurate way to make calibration gases for testing

I spent several years for my work life on this problem and can tell you that even with calibrated gas cylinders its pretty hard to create a calibrated environment for the gauge to read. Basically you need a sealed container you can pull and hold a pretty hard vacuum in, then refill with calibrated gas and repeat at least 3 times. To actually make a calibration gas you kind of need a calibrated sensor to start with and run the setup just purging the mixture and adjusting until the calibrated sensor says its correct.

It might be easier and cheaper to find a lab that can create a calibration curve on a few sensors or sell you a calibrated setup, then you use the calibrated setup to measure what your sensor should be reading.

If you are not familiar with calibration curves, basically its the gauge sensor error at various points. Most of the time actually getting the sensor to read correctly is impossible so they just measure its output across the range a few time and give you the input/output info. With electronic gauges that would go into a table so the displaced output is the calibrated reading.

Then, you buy a dozen sensors form a dozen different places to give yourself your best shot at getting representative production error and see what each reads and use that to create your formula or lookup table for the final controller.

This honestly seems like step 2 though and what you do to take a good working usable product from great for rusEFI to great for the world. I say that meaning that as long as the setup is repeatable it will work fine. you install it, you tune until the engine runs good and you really never care what the lambda number is beyond its works good at that setting. In the bigger world it's more important that someone switching from a different sensor to the rusEFI setup can use their existing tuning info to make the switch less painful.....set 2.

Step 1 is a rugged, repeatable setup and hopefully setup 2 is a firmware update once you have a good calibration setup of lots of data like Mack collected for a bunch of users between your setup and others to approximate a good calibration.

Update: a friend of mine has a contact at Bosch Motorsport which confirmed that the "17025" ( 0 280 017 025 ) sensor which is commonly available matches the Bosch Motorsport PDF data. Waiting to see if he will deny or confirm some of the other part numbers (17212, 17263, 17323) we have on hand.