Hi everybody, don't you think it is nearly time that a DIY-ECU should provide some OBD-scan compatibility.
I think MicroSquirt is fully eligible for this.
That would be a milestone, isn't ?
Here is my state of mind.
It is so frustrating to see low budget cars (new cars) connected on low-budget OBD-scanners providing features that were previously available in high-end DIY-ECU a few years ago like real-time parameter measurement, deluxe gauges, deluxe charts and error logs.
What I am looking now for my next car is MicroSquirt "as is" but running a supplementary OBD software layer running in the background. In other words, having MicroSquirt properly responding to a native OBD scan originating from any decent OBD scanner.
And, following this, what I will be looking for the future is MicroSquirt fitted with an "extended" OBD software layer enabling MicroSquirt to read "extension" sensors (8 channel O2 wideband, 8 channel PT200 temperature, 8 channel knock sensor) using CANbus then automatically adjusting some engine management parameters like fuel and ignition in closed loop.
I am now starting designing a dedicated CANbus module, miniaturized, providing 4 channels of O2 wideband and 4 channels of PT200 EGT, fully featured with NS SimpleSwitcher DC current for heating (bye bye RFI), RCAL resistance measurement and Nerst Cell resistance measurement. I don't know if this "blackbox" should direclty respond to an OBD scan, or if it always should rely on the presence of a ECU like MicroSquirt. Personally, I prefear having the "blackbox" responding to a OBD scan even without the presence of the main ECU, but wait a moment - this looks like distributed OBD, and I know nothing about distributed OBD. Can somebody give me some guidelines before I open the Pandora box ?
One obvious advantage of having that multi sensor "blackbox" directly adressed by any decent native OBD scanner is that we can concentrate on the hardware, leaving to other people the difficult task to graph the data using redimensionable gauges, textures, virtualized custom dashboards, and other clever gadgets that are pure marvels to the eye.
This means also that this particular hardware, initially conceived as a MicroSquirt extension may become a de-facto standard multichannel O2 wideband sensor for many people. Bye bye proprietary solutions, and welcome true multichannel O2/EGT sensing, true OBD scanning. A nice market, after all.
Not forgetting the important fact that within a couple of years, ALL dashboards will get virtualized.
By the way, can anybody advise me a fine microcontroller, low footprint, low pincount, CAN-enabled, that can be programmed in C for doing the job ? I got attracted by ATMEL AT90 series then some people told me there was a nasty silicon bug involving the stack, then I went to Microchip but didn't like them because they quickly make their own chips obsolescent, then finally ended up (like B&G) with the Freescale MC9S12 cpu, but found it overkill for my multisensor blackbox.
On the other side, the fact that MicroSquirt is based on the same Freescale MC9S12 cpu has significant advantages like sharing and streamlining the compiler and other development tools. As a consequence, all OBD-related routines, especially in the context of a distributed OBD implementation running in the background of existing MicroSquirt software , will be far easier to develop and maintain.
So, any clue or recommendation welcome.
Regards,
Steph
from Brussels
OBD-scan compatibility / distributed OBD in background
Forum rules
Read the manual to see if your question is answered there before posting. If you have questions about MS1/Extra or MS2/Extra or other non-B&G code configuration or tuning, please post them at http://www.msextra.com The full forum rules are here: Forum Rules, be sure to read them all regularly.
Read the manual to see if your question is answered there before posting. If you have questions about MS1/Extra or MS2/Extra or other non-B&G code configuration or tuning, please post them at http://www.msextra.com The full forum rules are here: Forum Rules, be sure to read them all regularly.
-
MegaScott
- MegaSquirt Guru
- Posts: 149
- Joined: Mon Jun 14, 2004 8:35 am
- Location: Seattle, Washington USA
- Contact:
I'm a proponant of distributed computing. For many reasons I think it much better to have several small "connected" multifunction devices than one huge do-all box.
The board you are proposing could simply be a version of the GPIO board that has WBO2 and EGT on it. I think there's plenty of room for a device such as this.
If you go with the 9S12 CPU you can load firmware directly through the CAN interface, just as you will be able to do with Megasquirt GPIO.
CAN would be a good application for transferring slow changing signals like WB and EGT, and since there is no D/A - A/D conversion the result should be much more accurate and with less delay.
Put me on the list for one!!
The board you are proposing could simply be a version of the GPIO board that has WBO2 and EGT on it. I think there's plenty of room for a device such as this.
If you go with the 9S12 CPU you can load firmware directly through the CAN interface, just as you will be able to do with Megasquirt GPIO.
CAN would be a good application for transferring slow changing signals like WB and EGT, and since there is no D/A - A/D conversion the result should be much more accurate and with less delay.
Put me on the list for one!!
Hello MegaScott,
Receiving you loud and clear.
So you (like me) have a preference for a distributed scheme, using a few nodes fitted with the 9S12 cpu like in MicroSquirt. Fine.
What about OBD-scan compliance ?
Remember that for hi-end systems we are going to have 8 wideband O2 and 8 EGT, plus some knock sensors, plus maybe later on some ionization sensors, meaning the system will have far more PIDs than usual. Is that a problem ? Can we maintain compatibility with any generic third party OBD scanner ? Don't we need to define something like a eOBD with "e" for "extension" ?
More : once you realize that having the 8 x WBO2 and the 8 x EGT, you need them OBD-scanned in a diagnostic approach, and you also need them measured for driving the fuel/ignition timings in a closed-loop management. So in other words, it is needed to surimpose on a potential OBD-scan (diagnostic scan), another CAN-based communication, on the same CAN wires, from the sensor board to the MicroSquirt board. How to avoid confusion ?
Shall we define two distinct classes of communication : first one for the external diagnostic-oriented OBD scan and another one, continuously used for internal closed-loop regulation ?
Or, shall we only rely on the OBD-scan concept, but this time with two distinct scanners running in parallel : the one that could be hooked for diagnostic purpose, and the other one, MicroSquirt, constinuously scanning for the closed-loop regulation.
There are interesting questions raised here. That is the Pandora box I was referrning above. Any hints, any comments welcome.
I need to take some orientations before I start coding the stuff.
What are the car manufacturers doing ? Do they already have distributed systems in place, and if yes, how do they manage to have this running both for diagnostic purposes, and closed-loop control ?
And for safety reasons, how to ensure that a car, running on the road, but having a third-party OBD-scanner hooked for datalogging, will be immune to the OBD-scanner starting to malfunction like stalling the CAN communication (MicrosQuirt trying to scan for the closed-loop regulation but never receiving the answers) -> don't you think it is mandatory to have a separated CAN node, able to detect scanner malfunction and isolating it ? Or, more radical, a Dual-Can capability for the node that connects on the external OBD-scanner ... Is MicroSquirt able to manage two physically distinct CAN busses : first one that attaches to the external OBD-scanner, and second one that is the distributed CAN we are talking about.
Or, maybe the external OBD scanner doesn't need to be CAN, it may be RS-232 or something like that ... but then, are we still OBD-scan compatible ?
How would you organize MicroSquirt communications ports (SPI, RS232, CAN) for getting something simple : a distributed CAN scheme both for the closed-loop management and the external OBD-scan, but still immune to any external OBD-scan malfunction ? Knowing that you want to be compliant with any decent external OBD-scanner.
Any hints, any recommendations welcome.
Regards,
Steph
Receiving you loud and clear.
So you (like me) have a preference for a distributed scheme, using a few nodes fitted with the 9S12 cpu like in MicroSquirt. Fine.
What about OBD-scan compliance ?
Remember that for hi-end systems we are going to have 8 wideband O2 and 8 EGT, plus some knock sensors, plus maybe later on some ionization sensors, meaning the system will have far more PIDs than usual. Is that a problem ? Can we maintain compatibility with any generic third party OBD scanner ? Don't we need to define something like a eOBD with "e" for "extension" ?
More : once you realize that having the 8 x WBO2 and the 8 x EGT, you need them OBD-scanned in a diagnostic approach, and you also need them measured for driving the fuel/ignition timings in a closed-loop management. So in other words, it is needed to surimpose on a potential OBD-scan (diagnostic scan), another CAN-based communication, on the same CAN wires, from the sensor board to the MicroSquirt board. How to avoid confusion ?
Shall we define two distinct classes of communication : first one for the external diagnostic-oriented OBD scan and another one, continuously used for internal closed-loop regulation ?
Or, shall we only rely on the OBD-scan concept, but this time with two distinct scanners running in parallel : the one that could be hooked for diagnostic purpose, and the other one, MicroSquirt, constinuously scanning for the closed-loop regulation.
There are interesting questions raised here. That is the Pandora box I was referrning above. Any hints, any comments welcome.
I need to take some orientations before I start coding the stuff.
What are the car manufacturers doing ? Do they already have distributed systems in place, and if yes, how do they manage to have this running both for diagnostic purposes, and closed-loop control ?
And for safety reasons, how to ensure that a car, running on the road, but having a third-party OBD-scanner hooked for datalogging, will be immune to the OBD-scanner starting to malfunction like stalling the CAN communication (MicrosQuirt trying to scan for the closed-loop regulation but never receiving the answers) -> don't you think it is mandatory to have a separated CAN node, able to detect scanner malfunction and isolating it ? Or, more radical, a Dual-Can capability for the node that connects on the external OBD-scanner ... Is MicroSquirt able to manage two physically distinct CAN busses : first one that attaches to the external OBD-scanner, and second one that is the distributed CAN we are talking about.
Or, maybe the external OBD scanner doesn't need to be CAN, it may be RS-232 or something like that ... but then, are we still OBD-scan compatible ?
How would you organize MicroSquirt communications ports (SPI, RS232, CAN) for getting something simple : a distributed CAN scheme both for the closed-loop management and the external OBD-scan, but still immune to any external OBD-scan malfunction ? Knowing that you want to be compliant with any decent external OBD-scanner.
Any hints, any recommendations welcome.
Regards,
Steph
-
MegaScott
- MegaSquirt Guru
- Posts: 149
- Joined: Mon Jun 14, 2004 8:35 am
- Location: Seattle, Washington USA
- Contact:
I think you need to leave the CAN scheme alone on the Megasquirt, to insure compatability. Sure, eventually the Megasquirt will need to be configured to pick the WBEGO signals off the bus, and your messages need to be formatted properly as per the Megasquirt "standard".
You will need to connect a second SPI up to a CAN transciever or other OBD translator, depending on what kind of OBD2 you want to emulate. There are several ways to do OBD, only one of which is CAN, If doing CAN like you say, your "scanner" would need to know the PID's of the non-standard data you are sending, just a plain old handheld scanner won't work for the special added PID's, but you could format the standard Manufacturers PID's to work with the scanner. Add-on software would have have to be configured to work with a common PC interface like the ELM chip. I'm sure all you would need to do is publish what the PID's are for the non standard signals then they could be accessed by any programming interface on the other end.
Your biggest task is going to be to translate all of the Megasquirt signals like RPM, timing advance, injector pulsewidth, etc... to the standard OBD CAN format for the scan tool to recognise. Also you may have to have a Keyline interface, depending on which Auto manufacturer you choose as your target for CAN.
Since you are talking a huge amount of I/O needed to control 8 WEGO's. I think you need to start small, say two channels, and once you get that down, migrate to an 8 channel solution. The EGT is easy, simple analog data read through the A/D ports, but you have only 8 so if you need more you will have to add another A/D which adds complexity, one of the reasons I am recommending to start small and make an UBER WEGO/EGT board later.
The Auto manufacturers ECU's will have more than one processor, one for the slower speed EFI stuff, often running a seperate process to service the OBD and health monitoring. The timing critical events are often taken care of by secondary processors or TPU's that are specially programmed to perfom those task's.
You will need to connect a second SPI up to a CAN transciever or other OBD translator, depending on what kind of OBD2 you want to emulate. There are several ways to do OBD, only one of which is CAN, If doing CAN like you say, your "scanner" would need to know the PID's of the non-standard data you are sending, just a plain old handheld scanner won't work for the special added PID's, but you could format the standard Manufacturers PID's to work with the scanner. Add-on software would have have to be configured to work with a common PC interface like the ELM chip. I'm sure all you would need to do is publish what the PID's are for the non standard signals then they could be accessed by any programming interface on the other end.
Your biggest task is going to be to translate all of the Megasquirt signals like RPM, timing advance, injector pulsewidth, etc... to the standard OBD CAN format for the scan tool to recognise. Also you may have to have a Keyline interface, depending on which Auto manufacturer you choose as your target for CAN.
Since you are talking a huge amount of I/O needed to control 8 WEGO's. I think you need to start small, say two channels, and once you get that down, migrate to an 8 channel solution. The EGT is easy, simple analog data read through the A/D ports, but you have only 8 so if you need more you will have to add another A/D which adds complexity, one of the reasons I am recommending to start small and make an UBER WEGO/EGT board later.
The Auto manufacturers ECU's will have more than one processor, one for the slower speed EFI stuff, often running a seperate process to service the OBD and health monitoring. The timing critical events are often taken care of by secondary processors or TPU's that are specially programmed to perfom those task's.
Hi MegaScott,
What do you think about rethinking all four SPI signals from the MC9S12 CPU of MegaSquirt, using them as MOSI, MISO, SCLK, SS and using them to connect a Microchip MCP2515 stand alone CAN controller ?
This way we get two CAN ports on MicroSquirt.
Built-in MC9S12 CAN port to be used for the sensor extensions.
Microchip MCP2515 CAN port to be hooked on any third-party OBD-II scanner.
Thus, say we drop all OBD-II protocols that are not CAN-based.
Because we are future oriented.
Doing this, MicroSquirt is losing four GPIO pins (Idle, Inj, Accel, Warm) then for some applications it may be needed to regain them. This can be done using a MicroChip MCP25020 CAN I/O expander. This is a small IC that hooks on CAN and provides a few I/O lines. We hook this IC on the sensor extension CAN. Not on the OBD-II CAN. Make sure you understand the datasheet. This IC seems very effective when needing a few extra lines.
MicroSquirt software must contain two new background processes : the sensor extension CAN (say the nodes management) and the OBD-II CAN (say the scanner management).
Due to the fact that there are going to be lots of new PIDs, more than what's actually available using a standard OBD-II scanner, yes I agree some tricks will be needed in the OBD-II scanner. We cannot say "any" decent scanner will be able to read and graph all these new PIDs. What is required is an extendable OBD-II scanner, but most are now developed on Windows, so this is not going to be a massive problem.
That's what you wrote, isn't ?
Regarding the nodes, if one want to reduce the complexity, yes, a fine idea indeed would be to have a 4-channel WBO2 + EGT. If one want to measure WBO2, RCAL, RNernst, VHeater, and EGT, this makes 5 x 4 channels = 20 channels. We hook three A/D converters like the ADC108S022 from NS, on SPI. They are 10 bit precision, have 8 inputs each, in a 16-pin package . So we get a total of 24 A/D inputs still with a low pin count and copper tracks easy to manage as we put the A/D converters on the analogic board. We don't rely on the built-in MC9S12 A/D converters. Instead, we use a few pins from the MC9S12 like PAD00, PAD01, PAD02 to select the A/D converters.
Doing so, the hardware remains very lightweight, low pin count.
And MicroSquirt gets unlimited power.
There are three difficulties regarding software.
1. One must invent a robust communication format between MicroSquirt and the multisensor nodes.
2. One must get MicroSquirt reponding to OBD-II queries, say the generic queries as a first goal. Nothing to invent there. Only becoming OBD-II compliant.
3. Soon after this, one must "persuade" some programmers to extend the capabilities (more PIDs) of their WinXP OBD-II scanners, and refine accordingly MicroSquirt OBD-II software. Say we become "OBD-Flex".
I think that the safety and reliability of this is OK.
Because we maintain a chineese wall between the two CAN busses.
The only real risk is that the MicroSquirt OBD-II process, due to programming errors or due to the OBD-II scanner doing weird, starts cannibalizing all the ressources (ram, mips) so no memory or no CPU time left for the Engine Management.
But I think that with decent care in writing the OBD-II software in MicroSquirt, the multisensor CANbus and the Engine Management functions of MicroSquirt will remain working correctly.
I'm thinking about a watchdog in MicroSquirt, disabling, unloading then restarting the whole OBD-II process if some OBD-II tasks are not processed as scheduled. A kind of intelligent watchdog with auto-retry.
Would you buy such system ?
How to setup an interactive "temptative" specification ?
I am still worried about how to extend the basic OBD-II PIDs in such a way that the people that have programmed OBD-II scanners under WinXP, will be "persuaded" to quickly upgrade their software.
One should ask them their opinion before, on a technical basis, about what would be "OBD-Flex".
I really dislike the OBD-II, so inflexible. Seems they focused on emissions, that's all. I would prefear akind of "OBD-Flex" with MicroSquirt sending a big ASCII table, easy to read, about the PIDs, their names, their coding, and then, only after the table being understood by the OBD-Flex scanner, maybe also after the end-user having designed the PIDs he wants to be datalogged, having MicroSquirt reponding "just that" in binary to the subsequent requests. This will avoid MicroSquirt sending data the end-user won't even look at.
Pls send me some feedback, I need "a second opinion".
I know nobody having programmed a OBD-II scanner under WinXP.
If you know such people, or if you are such people, don't hesitate participating in a "temptative" specification.
Don't know if B&G are going to setup something in MicroSquirt website.
Would be nice once the main lines get defined.
Regards,
Steph
What do you think about rethinking all four SPI signals from the MC9S12 CPU of MegaSquirt, using them as MOSI, MISO, SCLK, SS and using them to connect a Microchip MCP2515 stand alone CAN controller ?
This way we get two CAN ports on MicroSquirt.
Built-in MC9S12 CAN port to be used for the sensor extensions.
Microchip MCP2515 CAN port to be hooked on any third-party OBD-II scanner.
Thus, say we drop all OBD-II protocols that are not CAN-based.
Because we are future oriented.
Doing this, MicroSquirt is losing four GPIO pins (Idle, Inj, Accel, Warm) then for some applications it may be needed to regain them. This can be done using a MicroChip MCP25020 CAN I/O expander. This is a small IC that hooks on CAN and provides a few I/O lines. We hook this IC on the sensor extension CAN. Not on the OBD-II CAN. Make sure you understand the datasheet. This IC seems very effective when needing a few extra lines.
MicroSquirt software must contain two new background processes : the sensor extension CAN (say the nodes management) and the OBD-II CAN (say the scanner management).
Due to the fact that there are going to be lots of new PIDs, more than what's actually available using a standard OBD-II scanner, yes I agree some tricks will be needed in the OBD-II scanner. We cannot say "any" decent scanner will be able to read and graph all these new PIDs. What is required is an extendable OBD-II scanner, but most are now developed on Windows, so this is not going to be a massive problem.
That's what you wrote, isn't ?
Regarding the nodes, if one want to reduce the complexity, yes, a fine idea indeed would be to have a 4-channel WBO2 + EGT. If one want to measure WBO2, RCAL, RNernst, VHeater, and EGT, this makes 5 x 4 channels = 20 channels. We hook three A/D converters like the ADC108S022 from NS, on SPI. They are 10 bit precision, have 8 inputs each, in a 16-pin package . So we get a total of 24 A/D inputs still with a low pin count and copper tracks easy to manage as we put the A/D converters on the analogic board. We don't rely on the built-in MC9S12 A/D converters. Instead, we use a few pins from the MC9S12 like PAD00, PAD01, PAD02 to select the A/D converters.
Doing so, the hardware remains very lightweight, low pin count.
And MicroSquirt gets unlimited power.
There are three difficulties regarding software.
1. One must invent a robust communication format between MicroSquirt and the multisensor nodes.
2. One must get MicroSquirt reponding to OBD-II queries, say the generic queries as a first goal. Nothing to invent there. Only becoming OBD-II compliant.
3. Soon after this, one must "persuade" some programmers to extend the capabilities (more PIDs) of their WinXP OBD-II scanners, and refine accordingly MicroSquirt OBD-II software. Say we become "OBD-Flex".
I think that the safety and reliability of this is OK.
Because we maintain a chineese wall between the two CAN busses.
The only real risk is that the MicroSquirt OBD-II process, due to programming errors or due to the OBD-II scanner doing weird, starts cannibalizing all the ressources (ram, mips) so no memory or no CPU time left for the Engine Management.
But I think that with decent care in writing the OBD-II software in MicroSquirt, the multisensor CANbus and the Engine Management functions of MicroSquirt will remain working correctly.
I'm thinking about a watchdog in MicroSquirt, disabling, unloading then restarting the whole OBD-II process if some OBD-II tasks are not processed as scheduled. A kind of intelligent watchdog with auto-retry.
Would you buy such system ?
How to setup an interactive "temptative" specification ?
I am still worried about how to extend the basic OBD-II PIDs in such a way that the people that have programmed OBD-II scanners under WinXP, will be "persuaded" to quickly upgrade their software.
One should ask them their opinion before, on a technical basis, about what would be "OBD-Flex".
I really dislike the OBD-II, so inflexible. Seems they focused on emissions, that's all. I would prefear akind of "OBD-Flex" with MicroSquirt sending a big ASCII table, easy to read, about the PIDs, their names, their coding, and then, only after the table being understood by the OBD-Flex scanner, maybe also after the end-user having designed the PIDs he wants to be datalogged, having MicroSquirt reponding "just that" in binary to the subsequent requests. This will avoid MicroSquirt sending data the end-user won't even look at.
Pls send me some feedback, I need "a second opinion".
I know nobody having programmed a OBD-II scanner under WinXP.
If you know such people, or if you are such people, don't hesitate participating in a "temptative" specification.
Don't know if B&G are going to setup something in MicroSquirt website.
Would be nice once the main lines get defined.
Regards,
Steph
-
MegaScott
- MegaSquirt Guru
- Posts: 149
- Joined: Mon Jun 14, 2004 8:35 am
- Location: Seattle, Washington USA
- Contact:
I think that taking away potential ignition drivers away from MS2/Microsquirt is limiting your audience.
There is a CAN tranciever in MS2/Microsquirt that will be used to communicate to a second processor, why not use that as intended, then extend your OBD through the additional processor?
I think the idea of distributed computing limits the load to MS2/Microsquirt. Any additional task's that are not timing critical can be processed off board in another module where the sensor data from that module will be available to all on the Megasquirt bus. The OBD process is not required for proper engine operation, and certainly not timing sensitive, therefore a perfect candidate for off board implementation.
Yeah I think it just a matter of defining the new PID's in the Scanner Database to give logging or monitoring capability to most all PC based OBD2 diagnostic scanner packages.
I would buy a board based on this topology, but I'm pretty sure I don't need more than 2 WBEGO sensors, and I'm only interested in 1 EGT at each turbo. Since I only have two injector channels I don't have individual cylinder trim so any more than 2 is a waste, except for datalogging. Later down the road with MS3 I may be interested in more EGO or more EGT channels, but it would be an expensive proposition. You figure $60 each for sensors and about $10 for connectors and wire cost per sensor. For a V8 that's $560 and I haven't even started buying thermocouples and assocated connectors yet. We have low buck DIY EFI here, this is why I think 2 or 4 channels is good. If you want more, just buy another board and connect it to the Megasquirt CAN bus.
There will be more CAN stuff on the Web site, I know Bruce and Al are excited about the possibility of people doing exactly what you are describing, any case I think CAN is here to stay, even in a New MS3 system there will be CAN for implementation of additional modules, so work on this system now won't be wasted.
There is a CAN tranciever in MS2/Microsquirt that will be used to communicate to a second processor, why not use that as intended, then extend your OBD through the additional processor?
I think the idea of distributed computing limits the load to MS2/Microsquirt. Any additional task's that are not timing critical can be processed off board in another module where the sensor data from that module will be available to all on the Megasquirt bus. The OBD process is not required for proper engine operation, and certainly not timing sensitive, therefore a perfect candidate for off board implementation.
Yeah I think it just a matter of defining the new PID's in the Scanner Database to give logging or monitoring capability to most all PC based OBD2 diagnostic scanner packages.
I would buy a board based on this topology, but I'm pretty sure I don't need more than 2 WBEGO sensors, and I'm only interested in 1 EGT at each turbo. Since I only have two injector channels I don't have individual cylinder trim so any more than 2 is a waste, except for datalogging. Later down the road with MS3 I may be interested in more EGO or more EGT channels, but it would be an expensive proposition. You figure $60 each for sensors and about $10 for connectors and wire cost per sensor. For a V8 that's $560 and I haven't even started buying thermocouples and assocated connectors yet. We have low buck DIY EFI here, this is why I think 2 or 4 channels is good. If you want more, just buy another board and connect it to the Megasquirt CAN bus.
There will be more CAN stuff on the Web site, I know Bruce and Al are excited about the possibility of people doing exactly what you are describing, any case I think CAN is here to stay, even in a New MS3 system there will be CAN for implementation of additional modules, so work on this system now won't be wasted.