$130 Bosch 4.9 sensor CAN-bus WB
01-08-2016, 04:07 PM
#21
Senior Member
Thread Starter
iTrader: (1)
Join Date: Sep 2011
Location: Lambertville, NJ
Posts: 1,215
Total Cats: 74
...
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 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.
So we'd end up with a multiplier of 49 and a divider of 13653. Weird, but it works. If you're running E85 do your own damn math
Reply
0
0
01-08-2016, 04:29 PM
#23
Boost Pope
iTrader: (8)
Join Date: Sep 2005
Location: Chicago. (The less-murder part.)
Posts: 33,038
Total Cats: 6,604
That's exactly what I want to know.
My wristwatch, a nice-looking analog device made in Denmark by Skagen and costing about a hundred dollars, is wrong. By that, I mean that at last check, it's about three seconds slow relative to GPS time, despite the fact that I calibrate it once every month or two.
Three seconds is a huge error if you're a TV station. It can cost you tens of thousands of dollars if it happens during prime time. This is why nearly every piece of equipment in my station (well, those related to on-air operation, anyway) are referenced to an industrial GPS receiver with two antennas on a UPS, which is backed up by a second industrial GPS receiver with two antennas on a different UPS, both of which are on an automatic failover switch with dual power supplies.
But that's an extreme example. It's the $5,000 wideband sensor of timekeeping.
For most practical purposes, such as catching a train, attending a meeting, showing up for a dinner reservation, etc., being three seconds late is no big deal. It's functionally indistinguishable from actually being on time.
I'm only aware of one article in which a variety of wideband systems were subjected to comparative testing under controlled conditions using reference gas. You can read it here: http://tunertools.com/articles/FordMuscle.pdf
In that test, the LC-1 was determined to be accurate to within a tolerance of +/- 0.1 AFR under the test conditions.
Was this a sufficient test? Well, it obviously didn't involve an actual running engine, or account for variables such as heat, vibration, moisture, aging, etc. So I'm sure that a more meaningful test could be performed. Until someone actually does that, however, and publishes the results, claims that "affordable wideband systems are horribly inaccurate" must be taken lightly. The only data I can find suggests that an LC-1 is, in fact, a $100 Danish wristwatch.
My wristwatch, a nice-looking analog device made in Denmark by Skagen and costing about a hundred dollars, is wrong. By that, I mean that at last check, it's about three seconds slow relative to GPS time, despite the fact that I calibrate it once every month or two.
Three seconds is a huge error if you're a TV station. It can cost you tens of thousands of dollars if it happens during prime time. This is why nearly every piece of equipment in my station (well, those related to on-air operation, anyway) are referenced to an industrial GPS receiver with two antennas on a UPS, which is backed up by a second industrial GPS receiver with two antennas on a different UPS, both of which are on an automatic failover switch with dual power supplies.
But that's an extreme example. It's the $5,000 wideband sensor of timekeeping.
For most practical purposes, such as catching a train, attending a meeting, showing up for a dinner reservation, etc., being three seconds late is no big deal. It's functionally indistinguishable from actually being on time.
I'm only aware of one article in which a variety of wideband systems were subjected to comparative testing under controlled conditions using reference gas. You can read it here: http://tunertools.com/articles/FordMuscle.pdf
In that test, the LC-1 was determined to be accurate to within a tolerance of +/- 0.1 AFR under the test conditions.
Was this a sufficient test? Well, it obviously didn't involve an actual running engine, or account for variables such as heat, vibration, moisture, aging, etc. So I'm sure that a more meaningful test could be performed. Until someone actually does that, however, and publishes the results, claims that "affordable wideband systems are horribly inaccurate" must be taken lightly. The only data I can find suggests that an LC-1 is, in fact, a $100 Danish wristwatch.
Reply
0
0
02-19-2016, 08:44 AM
#25
Senior Member
Thread Starter
iTrader: (1)
Join Date: Sep 2011
Location: Lambertville, NJ
Posts: 1,215
Total Cats: 74
Received the board and sensor yesterday. That thing is tiny! I did read the 1" x 2.5" for the board, but didn't really appreciate how small that is. The quality is so-so. It's definitely not something produced in mass quantity. The board is run-of-the-mill China quality. Assembly looks halfway decent. All solder connections seem to be solid. The whole board looks like it was sprayed with about 20 coats of hairspray after assembly. They really put the protective lacquer on thick and quick.
So far I have not been able to read anything from it using an Arduino with a CAN shield. Not exactly sure what I'm doing wrong. I hope I'll have some more time to play with it this weekend.
If anybody here has experience using the Seeedstudion CAN shield with extended frames please let me know. I may be screwing up with the extended frames somehow.
So far I have not been able to read anything from it using an Arduino with a CAN shield. Not exactly sure what I'm doing wrong. I hope I'll have some more time to play with it this weekend.
If anybody here has experience using the Seeedstudion CAN shield with extended frames please let me know. I may be screwing up with the extended frames somehow.
Reply
0
0
02-19-2016, 09:43 AM
#26
Junior Member
Join Date: Oct 2015
Location: Stockholm, Sweden
Posts: 89
Total Cats: 11
I didn't use the Seeedstudio shield but a cheapo ebay one with the same chips on it (MCP2515 + MCP2551), and was able to read both standard and extended frames with that. Can link you to some example code that worked well enough for me.
Other things to watch out for that I've seen is the "+" and "-" sides of the CAN bus being mislabelled (swapped), and general randomness in which CAN components have an internal 120ohm termination resistor or not.
Edit: Another thing that bit me was the CAN bus bitrate. When you initialize the MCP2515 controller you tell it what speed to run at, but that bitrate is based on the controller being clocked at 16MHz. The CAN interface adapters I got were clocked at 8MHz so it ended up running at half of whatever bitrate I told it. Using CAN_1000KBPS made it run at 500Kbps though. From the looks of the pictures the Seeedstudio one has a 16MHz crystal on it so that may be a non-issue in your case though.
Other things to watch out for that I've seen is the "+" and "-" sides of the CAN bus being mislabelled (swapped), and general randomness in which CAN components have an internal 120ohm termination resistor or not.
Edit: Another thing that bit me was the CAN bus bitrate. When you initialize the MCP2515 controller you tell it what speed to run at, but that bitrate is based on the controller being clocked at 16MHz. The CAN interface adapters I got were clocked at 8MHz so it ended up running at half of whatever bitrate I told it. Using CAN_1000KBPS made it run at 500Kbps though. From the looks of the pictures the Seeedstudio one has a 16MHz crystal on it so that may be a non-issue in your case though.
Last edited by jstck; 02-19-2016 at 09:47 AM. Reason: Addendum
Reply
0
0
02-19-2016, 09:56 AM
#27
Junior Member
Join Date: Oct 2015
Location: Stockholm, Sweden
Posts: 89
Total Cats: 11
Here's some simple debug code I used that just outputs whatever stuff comes in on the CAN bus. I think this is the version I had that would also read extended frames properly (but I'm not near hardware that I can test on atm).
http://pastebin.com/KNXLFW5M
It doesn't use interrupts but just simple polling, so if frames come in quickly it will drop some due to the 500ms delay (which you can just lower), did that for readability of output.
http://pastebin.com/KNXLFW5M
It doesn't use interrupts but just simple polling, so if frames come in quickly it will drop some due to the 500ms delay (which you can just lower), did that for readability of output.
Reply
0
0
02-19-2016, 10:36 AM
#28
Senior Member
Thread Starter
iTrader: (1)
Join Date: Sep 2011
Location: Lambertville, NJ
Posts: 1,215
Total Cats: 74
Thanks for the code. Having CanL and CanH confused is certainly a possibility. I would assume that this would cause some trouble. I may have confused them myself- even though I swear I did it right....
The WB does not have a terminating 120Ohm resistor, but at a wire length of maybe 20cm and 250kbps I don't think that would be the issue.
I'm pretty sure that my Seeedstudio shield uses the proper setup for bitrates, I used it to read gauge info from MS3, set at 500kbps. That worked.
I'll just run a RAW dump tonight, just reading the buffer every 100ms ir so and dumping it to serial. If the WB sends anything at all it should show up there.
The WB does not have a terminating 120Ohm resistor, but at a wire length of maybe 20cm and 250kbps I don't think that would be the issue.
I'm pretty sure that my Seeedstudio shield uses the proper setup for bitrates, I used it to read gauge info from MS3, set at 500kbps. That worked.
I'll just run a RAW dump tonight, just reading the buffer every 100ms ir so and dumping it to serial. If the WB sends anything at all it should show up there.
Reply
0
0
02-19-2016, 09:36 PM
#29
Senior Member
Thread Starter
iTrader: (1)
Join Date: Sep 2011
Location: Lambertville, NJ
Posts: 1,215
Total Cats: 74
No dice. Even just posting the raw CAN bus data to my serial gets nothing. The WB must be doing something, because as soon as I plug it in, the "RX" LED on my CAN shield lights up.
Actually with jstck's code the "TX" LED lights up too. But with either one there's 0 bytes transmitted.
I tried BAUD rates from 100kbps to 1000kbps. Nothing
Actually with jstck's code the "TX" LED lights up too. But with either one there's 0 bytes transmitted.
I tried BAUD rates from 100kbps to 1000kbps. Nothing
Reply
0
0
02-20-2016, 03:48 AM
#30
Junior Member
Join Date: Oct 2015
Location: Stockholm, Sweden
Posts: 89
Total Cats: 11
I think there is some kind of acknowledgement signals sent which might be what is causing TX to go on, but in that case it's really odd that it's not getting any data.
The only extended data I've meddled with was the MS3pro sending out "requests" when polling data (as set up in the CAN ADC, Vss and EGO dialogs), but I could see all those with that test code.
I honestly don't remember if I had to do anything with the mask/filter stuff, which I've never quite understood. There are a couple of lines about that (part of something I just copypasted from somewhere else), but since they are commented out I don't think so; I'm at least sure that for standard frames, setting no filters/masks whatsoever means it will receive everything.
Are you able to configure the O2/CAN controller to use standard frames to see if that makes a difference?
The only extended data I've meddled with was the MS3pro sending out "requests" when polling data (as set up in the CAN ADC, Vss and EGO dialogs), but I could see all those with that test code.
I honestly don't remember if I had to do anything with the mask/filter stuff, which I've never quite understood. There are a couple of lines about that (part of something I just copypasted from somewhere else), but since they are commented out I don't think so; I'm at least sure that for standard frames, setting no filters/masks whatsoever means it will receive everything.
Are you able to configure the O2/CAN controller to use standard frames to see if that makes a difference?
Reply
0
0
02-20-2016, 04:03 AM
#31
Senior Member
Join Date: May 2007
Location: Atlanta
Posts: 997
Total Cats: 156
I'll throw in with some of my code..
https://github.com/kckr/MSCan_Sniffe...Sniffer_V2.ino
that should display any CAN data coming across the wire, color coded to MSCan's packets if you use putty and each mcp2515 buffer displayed. I used it begin troubleshooting my own mscan development. You can reset the MCP2515's bitrate by playing with the CNF1-3 bits. Not sure if it'll parse correctly without some work for 11 bit ID's, but it should show anything broadcast.
https://github.com/kckr/MSCan_Sniffe...Sniffer_V2.ino
that should display any CAN data coming across the wire, color coded to MSCan's packets if you use putty and each mcp2515 buffer displayed. I used it begin troubleshooting my own mscan development. You can reset the MCP2515's bitrate by playing with the CNF1-3 bits. Not sure if it'll parse correctly without some work for 11 bit ID's, but it should show anything broadcast.
Reply
0
0
02-23-2016, 09:57 AM
#32
Senior Member
Thread Starter
iTrader: (1)
Join Date: Sep 2011
Location: Lambertville, NJ
Posts: 1,215
Total Cats: 74
I was too lazy to figure out how the CNF1-3 bits on the mcp2515 actually meant. That datasheet is just waaaaaay too long for my OCD brain.
So last night I connected a cheap ESM327 based USB/OSBD2 scan tool to the board and lo and behold we have readings!
Raw data looks something like this:
3 0FF00 01 CC FA FC FF 12 9E 20 58
3 0FF00 01 47 F5 FC FF 7E B3 10 46
3 0FF00 01 B4 F4 FC FF A0 B3 00 FE
That is the correct address. The data returned makes sense as well. There were a few things that bug me a little, but nothing insurmountable:
- I kept receiving the error "1100 -- Heater circuit short to GND"
- The AFR only goes up to 16. Some cars run close to that in cruise
- FYI: the ALM uses the "SAE J1939 CAN (29 bit ID, 250 kbaud)" definition and NOT the "ISO 15765-4 CAN (29 bit ID, 250 kbaud)" definition.
I was using two different power supplies- one for 5V and another one for 12V. They were not connected. Turns out they need a common ground outside the ALM board and the "short to GND" error goes away.
While the AFR reported only goes up to 16% (and if you look at the data above, the AFR on top of my desk is apparently constant at 15.99), the sensor also gives us a percentage O2 that goes all the way to 20+%. Which is an AFR of infinity. The O2 reading also goes down to negative percentage, indicating a lack of oxygen, so we should be able to just convert the percentage O2 into an AFR value in the MS.
To do: Figure out how to send the proper message to the ALM in order to change the protocol to the MS-compatible "ISO 15765-4 CAN (11 bit ID, 500 kbaud)" definition. The manual just states to "PC send" the following (hex): "81 81 29 01 00 00 03" where the "81 81" puts it in programming mode and the "29 01 00" is the new address. The "00 03" at the end sets standard protocol and 500kbs.
So this sounds like I just write this raw data onto the bus and the ALM changes its' setup. That sounds a bit dangerous to me- what if some device on the bus accidentally sends "81 81" as a header? Am I missing something here?
So last night I connected a cheap ESM327 based USB/OSBD2 scan tool to the board and lo and behold we have readings!
Raw data looks something like this:
3 0FF00 01 CC FA FC FF 12 9E 20 58
3 0FF00 01 47 F5 FC FF 7E B3 10 46
3 0FF00 01 B4 F4 FC FF A0 B3 00 FE
That is the correct address. The data returned makes sense as well. There were a few things that bug me a little, but nothing insurmountable:
- I kept receiving the error "1100 -- Heater circuit short to GND"
- The AFR only goes up to 16. Some cars run close to that in cruise
- FYI: the ALM uses the "SAE J1939 CAN (29 bit ID, 250 kbaud)" definition and NOT the "ISO 15765-4 CAN (29 bit ID, 250 kbaud)" definition.
I was using two different power supplies- one for 5V and another one for 12V. They were not connected. Turns out they need a common ground outside the ALM board and the "short to GND" error goes away.
While the AFR reported only goes up to 16% (and if you look at the data above, the AFR on top of my desk is apparently constant at 15.99), the sensor also gives us a percentage O2 that goes all the way to 20+%. Which is an AFR of infinity. The O2 reading also goes down to negative percentage, indicating a lack of oxygen, so we should be able to just convert the percentage O2 into an AFR value in the MS.
To do: Figure out how to send the proper message to the ALM in order to change the protocol to the MS-compatible "ISO 15765-4 CAN (11 bit ID, 500 kbaud)" definition. The manual just states to "PC send" the following (hex): "81 81 29 01 00 00 03" where the "81 81" puts it in programming mode and the "29 01 00" is the new address. The "00 03" at the end sets standard protocol and 500kbs.
So this sounds like I just write this raw data onto the bus and the ALM changes its' setup. That sounds a bit dangerous to me- what if some device on the bus accidentally sends "81 81" as a header? Am I missing something here?
Reply
0
0
02-23-2016, 10:19 AM
#33
To do: Figure out how to send the proper message to the ALM in order to change the protocol to the MS-compatible "ISO 15765-4 CAN (11 bit ID, 500 kbaud)" definition. The manual just states to "PC send" the following (hex): "81 81 29 01 00 00 03" where the "81 81" puts it in programming mode and the "29 01 00" is the new address. The "00 03" at the end sets standard protocol and 500kbs.
So this sounds like I just write this raw data onto the bus and the ALM changes its' setup. That sounds a bit dangerous to me- what if some device on the bus accidentally sends "81 81" as a header? Am I missing something here?
You're not on the OBD bus are you? I'd keep the OEM CAN bus separate from your aftermarket CANbus if possible. If you do you should just have the Megasquirt and your CAN controller on the bus right? It should be safe to send that command out. Or just disconnect it from any bus and put it on the bench and send the command with an arduino or other micro controller. You should only need to write that setting once and It should save it.
Reply
0
0
02-23-2016, 10:47 AM
#34
Senior Member
Join Date: May 2007
Location: Atlanta
Posts: 997
Total Cats: 156
borrowing from https://developer.mbed.org/users/Fal...f0ce/MCP2515.h
125 kbps
CNF1/BRGCON1 b'00000011' 0x03
250 kbps
CNF1/BRGCON1 b'00000001' 0x01
500 kbps
CNF1/BRGCON1 b'00000000' 0x00
Throw that into CNF1 register, see if it'll pick it up.
125 kbps
CNF1/BRGCON1 b'00000011' 0x03
250 kbps
CNF1/BRGCON1 b'00000001' 0x01
500 kbps
CNF1/BRGCON1 b'00000000' 0x00
Throw that into CNF1 register, see if it'll pick it up.
Reply
0
0
02-23-2016, 10:51 AM
#35
Senior Member
Thread Starter
iTrader: (1)
Join Date: Sep 2011
Location: Lambertville, NJ
Posts: 1,215
Total Cats: 74
You're not on the OBD bus are you? I'd keep the OEM CAN bus separate from your aftermarket CANbus if possible. If you do you should just have the Megasquirt and your CAN controller on the bus right? It should be safe to send that command out. Or just disconnect it from any bus and put it on the bench and send the command with an arduino or other micro controller. You should only need to write that setting once and It should save it.
I was researching if I could use the ELM327 to send data out to the bus, but can't find any AT commands that would actually allow me to do so.
So once I get my Arduino or Teensy to actually communicate with the ALM, I should be able to reprogram it to MS3 specs.
Reply
0
0
02-23-2016, 11:24 AM
#36
Junior Member
Join Date: Oct 2015
Location: Stockholm, Sweden
Posts: 89
Total Cats: 11
Are you sure it's giving you the AFR value and not the lambda value? The spec sheet just talks about lambda, and that would in a way make more sense as it is independent of the stoichiometric ratio of the fuel being used. A max lambda value of 16 is ridiculously high (corresponds to a gasoline AFR of about 235:1, practically infinity), but in free air you have zero fuel and all of the oxygen, so it still would make sense here.
I do wonder what the heck "negative oxygen" would even signify though.
As for programming the ALM, I'm pretty sure you would still have to send a CAN bus packet to the correct ID (the ID of the ALM thingy). 81 81 is just the first two bytes of the 8 byte payload, and if it's addressed to anywhere else it should be ignored.
Not quite sure what the ID it receives those programming commands on actually is in the 29-bit extended world though.
I do wonder what the heck "negative oxygen" would even signify though.
As for programming the ALM, I'm pretty sure you would still have to send a CAN bus packet to the correct ID (the ID of the ALM thingy). 81 81 is just the first two bytes of the 8 byte payload, and if it's addressed to anywhere else it should be ignored.
Not quite sure what the ID it receives those programming commands on actually is in the 29-bit extended world though.
Reply
0
0
02-23-2016, 11:29 AM
#37
The meter is currently on my desk and not hooked up to any vehicle. My Miata doesn't have an OEM CAN bus either. So that's not a worry for me at this time. I was just wondering how this ALM meter would work in a normal car with a CAN bus so full of data that I certainly wouldn't feel comfortable with that board setup being changed so easily over the bus. But maybe that "81 81" is a reserved codeword that is part of the CAN spec. Who knows.
I was researching if I could use the ELM327 to send data out to the bus, but can't find any AT commands that would actually allow me to do so.
So once I get my Arduino or Teensy to actually communicate with the ALM, I should be able to reprogram it to MS3 specs.
I was researching if I could use the ELM327 to send data out to the bus, but can't find any AT commands that would actually allow me to do so.
So once I get my Arduino or Teensy to actually communicate with the ALM, I should be able to reprogram it to MS3 specs.
If I were you I'd use an Arduino and CAN shield (or similar) as the middle translation bridge between your wideband and ECU. Have it read in the wideband CAN data then format it to the proper MegaSquirt CAN format and then transmit it out to the ECU via CAN.
Reply
0
0
02-23-2016, 11:39 AM
#38
Senior Member
Thread Starter
iTrader: (1)
Join Date: Sep 2011
Location: Lambertville, NJ
Posts: 1,215
Total Cats: 74
Are you sure it's giving you the AFR value and not the lambda value? The spec sheet just talks about lambda, and that would in a way make more sense as it is independent of the stoichiometric ratio of the fuel being used. A max lambda value of 16 is ridiculously high (corresponds to a gasoline AFR of about 235:1, practically infinity), but in free air you have zero fuel and all of the oxygen, so it still would make sense here.
I do wonder what the heck "negative oxygen" would even signify though.
As for programming the ALM, I'm pretty sure you would still have to send a CAN bus packet to the correct ID (the ID of the ALM thingy). 81 81 is just the first two bytes of the 8 byte payload, and if it's addressed to anywhere else it should be ignored.
Not quite sure what the ID it receives those programming commands on actually is in the 29-bit extended world though.
I do wonder what the heck "negative oxygen" would even signify though.
As for programming the ALM, I'm pretty sure you would still have to send a CAN bus packet to the correct ID (the ID of the ALM thingy). 81 81 is just the first two bytes of the 8 byte payload, and if it's addressed to anywhere else it should be ignored.
Not quite sure what the ID it receives those programming commands on actually is in the 29-bit extended world though.
AFR != Lambda
Need to keep reading up on the bus protocol. So far I'm not even sure how to set a recipient address- all I've ever seen is broadcast.
I also just found this handy calculator for the CNF bits on the MCP251x series.
https://www.kvaser.com/support/calcu...ng-calculator/
Of course the values calculated with that tool in no way shape or form reflect the values that are defined in the Seeedstudio CAN library.
Will keep digging :-)
Reply
0
0
02-23-2016, 11:46 AM
#39
Senior Member
Thread Starter
iTrader: (1)
Join Date: Sep 2011
Location: Lambertville, NJ
Posts: 1,215
Total Cats: 74
borrowing from https://developer.mbed.org/users/Fal...f0ce/MCP2515.h
125 kbps
CNF1/BRGCON1 b'00000011' 0x03
250 kbps
CNF1/BRGCON1 b'00000001' 0x01
500 kbps
CNF1/BRGCON1 b'00000000' 0x00
Throw that into CNF1 register, see if it'll pick it up.
125 kbps
CNF1/BRGCON1 b'00000011' 0x03
250 kbps
CNF1/BRGCON1 b'00000001' 0x01
500 kbps
CNF1/BRGCON1 b'00000000' 0x00
Throw that into CNF1 register, see if it'll pick it up.
Reply
0
0
02-23-2016, 10:43 PM
#40
Senior Member
Thread Starter
iTrader: (1)
Join Date: Sep 2011
Location: Lambertville, NJ
Posts: 1,215
Total Cats: 74
I'm baffled.
My Arduino shield works- but not with the ALM WB. I can read messages from MS3 at 500kbps no problem. I can even use different calculated settings for the CNF1-3 registers on the MCP2515 and it keeps working. Tried three different versions- they all worked. I can also send data from Arduino via CAN to the MS3 and have it displayed on gauges.
I'm just using the standard CAN receive routine from the examples. All it does is dump the CAN-buffer to serial. So if ANYTHING at all is received it gets printed. Loads of data comes from the MS3. But nothing at all from the ALM WB.
BTW: the ELM327 reader also reads the MS3 output, but it does throw a lot of "CAN ERROR" codes.
gooflophaze: Your code doesn't produce any output for me- not even reading from my MS3. I'm pretty sure I got the CS pin and the INT pin correct. The CNFs are the ones that I used with the Seeed library, so that's not it.
I must be doing something wrong, since all the parts work, I just can't get them to work together....
My Arduino shield works- but not with the ALM WB. I can read messages from MS3 at 500kbps no problem. I can even use different calculated settings for the CNF1-3 registers on the MCP2515 and it keeps working. Tried three different versions- they all worked. I can also send data from Arduino via CAN to the MS3 and have it displayed on gauges.
I'm just using the standard CAN receive routine from the examples. All it does is dump the CAN-buffer to serial. So if ANYTHING at all is received it gets printed. Loads of data comes from the MS3. But nothing at all from the ALM WB.
BTW: the ELM327 reader also reads the MS3 output, but it does throw a lot of "CAN ERROR" codes.
gooflophaze: Your code doesn't produce any output for me- not even reading from my MS3. I'm pretty sure I got the CS pin and the INT pin correct. The CNFs are the ones that I used with the Seeed library, so that's not it.
I must be doing something wrong, since all the parts work, I just can't get them to work together....
Reply
0
0
