DIY Electric Car Forums banner

CAN Bus communication

58K views 107 replies 7 participants last post by  bjfreeman 
#1 ·
Greetings to all:

I started this thread to gather information/experiences with CAN Bus communication. It seems to be a future technology that extends from vehicles to even large buildings.

I see at my workplace, the use of CAN Bus in our fire systems as well as our HVAC central controls. It is very flexible as well as precise in coordinating multiple units to allow them to operate as a whole. Even among units from different manufacturers.

I also gather that it has been building and growing for several years and finally emerging as THE common choice for inter-unit-communications.

My AC50/Curtis controller came with a nice wiring diagram. It lists a CAN Bus interface point. Has anyone used it to communicate with it?

The newer OBD2 vehicle scanners utilize CAN Bus in their software. Would one of these read a Curtis controller?

The interface plugs with attached wires exist for sale to facilitate this.

I was just wondering what the controller could do over this link?

Miz
 
See less See more
#63 ·
If I read my wiring diagram correctly, My 1238 has a couple of switch outputs. Are they user defined? Are they serial or CAN Bus accessed?

They would be really great for maybe a warning light or even RPM signaled to shift the transmission.

Miz
 
#64 ·
Not as far as I can tell. From what I understand after talking to Curtis, They're only available within the actual OS, through custom programming called VCL. That itself is a whole new can of worms. User defined, no. HPEVS defined? yes, since they're the OEM, they did the VCL programming.

And unfortunately we don't have that.....

Maybe there's some way to access the outputs via canbus, we'll find out I guess.
 
#65 ·
Playing around a little with Torque and trying to get my head around the ELM datasheet. According to the data sheet OBDII uses 7 data bytes while CAN allows for eight. I think OBDII uses the first byte for some particular purpose and then the data is in the remaining 7 bytes. This has the potential for causing problems with Torque I think. See page 36 of the ELM datasheet. The first CAN byte is something called PCI, the remaining 7 bytes contain the data. If this means that Torque takes the second byte as the first data byte, (i.e. A in any calculation), then anything in the first byte potentially becomes lost to Torque. I know that my Sevcon controller uses the first byte for data and I presume the Curtis does as well. I haven't studied the Torque wiki to know if there's a way around this yet.
 
#66 ·
Ok, I found Torque Pro and Widgets here:
https://market.android.com/search?q=torque&c=apps
Seems this and an android tablet gets you a long way, but its not clear to me how I get data out from the Curtis 1238 controller in a format required for Torque. The only communications I am aware of is the serial output to the "spyglass". I can display many parameters from this output using the Curtis PC software, but how would I interface this to an Android device in a format Torque can use? Looks like widget might make it easy to display data in gauge format, but can the data be data logged and saved?
 
#67 ·
Ok, I found Torque Pro and Widgets here:
https://market.android.com/search?q=torque&c=apps
Seems this and an android tablet gets you a long way, but its not clear to me how I get data out from the Curtis 1238 controller in a format required for Torque. The only communications I am aware of is the serial output to the "spyglass". I can display many parameters from this output using the Curtis PC software, but how would I interface this to an Android device in a format Torque can use? Looks like widget might make it easy to display data in gauge format, but can the data be data logged and saved?
From the manual:
CAN bus (Pins 21, 23, 34, 35)
It is recommended that the CAN wires be run as a twisted pair. However, many successful applications at 125 kBaud are run without twisting, simply using two lines bundled in with the rest of the low current wiring. CAN wiring should be kept away from the high current cables and cross it at right angles when necessary.

So you feed these pins to a suitable connector and plug in your CAN/OBD2 to Wireless/Bluetooth ELM327 compatible adapter as listed on the Torque web site. However, I'm still not convinced that Torque can handle non-OBD2 CAN messages from the Curtis or other controllers. (See my post above.)
 
#68 ·
Hey Travis, can you send me those Curtis Can bus specs? You've got me curious about whether this will work with Torque or not. Right now I'm not seeing it if there's data in that first byte.

Now, there are ways around that I guess, but it involves work. And work sucks. I think you'd have to program a microcontroller to emulate the ELM327 and then shift all the data bytes to make the output OBD2 compliant for Torque to be able to handle it. Relatively straightforward, but not plug and play like using one of the OBD2 scanners.

Unless Torque can access that first byte as a data byte. Anyone? Anyone? Bueller? Anyone?
 
#69 ·
Now, there are ways around that I guess, but it involves work. And work sucks. I think you'd have to program a microcontroller to emulate the ELM327 and then shift all the data bytes to make the output OBD2 compliant for Torque to be able to handle it.
Actually, it would be simpler and more general to have a microcontroller that reads the Curtis data and presents it as an OBD2 ECU. That way you don't have to emulate the quirks of the ELM327 command set.
 
#71 ·
I think I misunderstood you. Do you mean Curtis -> microcontroller that converts to OBD2 -> existing Torque compatible OBD2 Scanner -> Torque?

That would be a good way to go. You'd have to have the microcontroller to OBD2 interface cope with other devices such as chargers, but it might not need to have any modifications to do that.
 
#72 · (Edited)
I think a microcontroller would be a good idea.... that way you can do stuff like serial and rs485 easily and interface with stuff like Manzanita Micro, Alltrax, Kelly, etc, not just Canbus stuff. Add some logging so it's always running even without the connected display device. You can also add more security than just the PIN on the bluetooth. Add some IO you can access... and it would be a great little device. Make some custom PID's in the format of something any OBD software can handle, and you can make gauges, whether on Torque (android) or PC (many software options). Use a wifi-serial chip instead and you can use Devtoaster's REV for the iPhone.

I looked at it last night but can't figure out what I need to do to set up the canbus comm. I pair with the ELM and can do AT commands via putty, but can't get much past that. Just trying to interface to the elithion right now. It's connected and the bus is stable and it autodetects 500kbaud 11-bit and I can measure the OBD Adapter voltage.
 
#73 ·
I looked at it last night but can't figure out what I need to do to set up the canbus comm. I pair with the ELM and can do AT commands via putty, but can't get much past that. Just trying to interface to the elithion right now. It's connected and the bus is stable and it autodetects 500kbaud 11-bit and I can measure the OBD Adapter voltage.
Sounds like you're almost there if it's autodetecting the baud rate. My Sevcon streams data constantly as soon as it's switched on. Do you know if the Curtis does the same, or do you need to send it a CAN message to tell it to start spitting out data?
 
#75 ·
Sorry, my mistake. I need to pay better attention, you had it right in there. :D I think the key is probably the ELM commands, but I don't have one to play around with.

I think I'm going to add the ELM command set to my project, or at least a subset of it. It'll save me having to write my own proprietry one and will allow me to tinker with OBD2 stuff/Torque.
 
#78 ·
OK, well I've got that half sorted already then with my Sevcon project. A couple extra lines of code and I can convert it to output OBD2 and have it go out over wifi. Any microcontroller worth its salt nowadays has multiple IO interfaces, including a CAN controller. If you want to include other non-CAN devices that's easy enough too just as long as you have the specs of what you're reading from.

I'd still go with emulating the ELM output though, (if that's what Torque and Rev need). I just don't see the point of using an OBD2 scanner to do what you can just as easily do yourself. It would be a redundant system at that point.
 
#79 ·
Hmmm, it seems as though as soon as I post something I figure out some other salient point. Basically I see two methods. One would be discrete modules that convert manufacturer's A output into OBD2, which then can all be connected on a bus and used with any OBD2 scanner to get the data to something like Torque. The other option, which is what I thought we were talking about but I could be wrong, is a system that enables multiple equipment from multiple manufaturers into one device. This could then do away with the OBD2 scanner, but might need more tailoring to the system, i.e. it would be less generic.

I kinda think we've hijacked the OP, for which I apologize. :)
 
#80 ·
either way, it's pretty straightforward.

The STN1110 and ELM327 chips are reasonably priced if you want to go that route, or you can just write your own code to just respond the same way torque/etc need.

Maybe we should post some of this in the torque forum?
 
#83 ·
OK......

I just re-read this entire thread.

I have come to realize my original question was quite naive.

CanBus is just a name for an idea to monitor/control machine-to-machine communication and or control.

Every manufacturer uses their own version of the idea. CanBus for an HVAC system may/may not communicate with CanBus from a vehicle system. Even if it did communicate, it may/may not be at the same speed, therefore be of use.

Even if it did communicate and was of the same speed parameter, it may/may not "understand each other.

Even if it did communicate. Even if it was of the same speed parameter. Even if it did "understand" each other. It still might/might not be able to issue two-way commands and just be a read only system.

This brings back memories of 4 track/8 track/casette issue. Then VHS/BetaMax. Then monochrome/VGA/whatever they use now. HD/Blue ray.
Everyone invested in their own Tech. and didnt use that energy to cooperate in developing an industry standard. They just tried to kill off everyone else.

While I understand most of the things said previously, My knowledge ends there.

I agree on a few points:

We need to develop our own "standard" system. It needs to be cheap as possible while still being able to expand to cover most new situations.

I get that Android covers 90% of our needs. It will not do for those wanting a full 100%. {Android might work for mobile systems only though.}

I get that most CanBus has no standard Baud rate and we must be tolerant of that.

I get that most CanBus has its own language. We need to have a way to add modules to suit future additional situations.

{Please forgive my clumsy wording, but it is the best I can do with this subject.}

It sounds like a "Swiss Army Knife" approach.

Miz
 
#85 ·
So I don't have to repeat about the hardware level
http://roadwarrior.free-man.com/can/
the messages can be define as an industries Vocabulary.
So just like the RV industry has a CAN vocabulary,
taking all the EV products that use CAN and have a vocabulary that is defined in one place.
Like this thread.

Addressing the User interface this should be a library of code, C, Java, that developers use to build displays. If developers use Java then it will be easily portable, without change on the PC, Linux, web pages and Android(linux based java) there is a place call GitHub that this repository can be put for all to use.
 
#84 · (Edited)
My 2 cents,

I would opt for one of the existing sae standards, thus allowing your can bus diagnostics to be read by any standard obd2 scan tool. Obviously these are mostly emission related an irrelevant in this context, but many others apply to any vehicle. The standard obd messages can be extended with manufacturer specific messages (thats you in this case) such as charge rate, motor temp, etc. The protocol used is normally UDS over CAN (high speed 500k) responding to diagnostic PIDS. If its something that your still interested in doing then let me know and i can help you draw up the details and perhaps put together an example controller to look at.

Also, when CAN is used in an automotive enviroment there are standard baud rates defines by the sae standards, and as the 'manufacturer' in this context, we can decide which speeds to impliment. It would be the Scan tool that needs to be tolerant. Again, as for the spoken language on the bus, there are standards that define this too, and includes diagnostics, module to module comms, module reprogramming etc.
 
#86 ·
for clarification
OBD-II PIDs (On-board diagnostics Parameter IDs) this is the 11 bit format. it is known as J1979
For canbus, DGN(Data group number ), SPIN(Service Point Number) extends the 11bit to 29 bits and is known as J1939
Both of these are
define by a chip that takes care of all the signals between nodes then provide the data in a format that a CPU can process. A cpu can also be programmed to what the chip does, but take away from the CPU to do other things.
The simplistic communication between nodes is “Are you there”, and a reply “Yes I am”. So a CAN can modify how many nodes it has and keep updated.
The next level is :what can you do, and the reply is a list of things the node can do.
So a CAN can learn what a new/upgraded node can do.


Now a node may be attached to many identical things, like a bunch of temperature sensors. So the node will also send how many of each thing it has.
take some development from the RV industry and the Can spec
The olimexino is a good development board. it is about $30.
Though you can use an elm327 and 329 still think using an environment that the is in software is better.
there is plenty of free code that I have used.


 
#87 ·
here are some can bus DGN that can be used. note some wont' be for vehicles.
Code:
#define DATE_TIME_STATUS ((uint32) 0x1FFFF)
#define SET_DATE_TIME_COMMAND ((uint32) 0x1FFFE)
#define DC_SOURCE_STATUS_1 ((uint32) 0x1FFFD)
#define DC_SOURCE_STATUS_2 ((uint32) 0x1FFFC)
#define DC_SOURCE_STATUS_3 ((uint32) 0x1FFFB)
#define COMMUNICATION_STATUS_1 ((uint32) 0x1FFFA)
#define COMMUNICATION_STATUS_2 ((uint32) 0x1FFF9)
#define COMMUNICATION_STATUS_3 ((uint32) 0x1FFF8)
#define WATERHEATER_STATUS ((uint32) 0x1FFF7)
#define WATERHEATER_COMMAND ((uint32) 0x1FFF6)
#define GAS_SENSOR_STATUS ((uint32) 0x1FFF5)
#define CHASSIS_MOBILITY_STATUS ((uint32) 0x1FFF4)
#define CHASSIS_MOBILITY_COMMAND ((uint32) 0x1FFF3)
#define AAS_CONFIG_STATUS ((uint32) 0x1FFF2)
#define AAS_CONFIG_COMMAND ((uint32) 0x1FFF1)
#define AAS_STATUS ((uint32) 0x1FFF0)
#define AAS_SENSOR_STATUS ((uint32) 0x1FFEF)
#define LEVELING_CONTROL_COMMAND ((uint32) 0x1FFEE)
#define LEVELING_CONTROL_STATUS ((uint32) 0x1FFED)
#define LEVELING_JACK_STATUS ((uint32) 0x1FFEC)
#define LEVELING_SENSOR_STATUS ((uint32) 0x1FFEB)
#define HYDRAULIC_PUMP_STATUS ((uint32) 0x1FFEA)
#define LEVELING_AIR_STATUS ((uint32) 0x1FFE9)
#define SLIDE_STATUS ((uint32) 0x1FFE8)
#define SLIDE_COMMAND ((uint32) 0x1FFE7)
#define SLIDE_SENSOR_STATUS ((uint32) 0x1FFE6)
#define SLIDE_MOTOR_STATUS ((uint32) 0x1FFE5)
#define FURNACE_STATUS ((uint32) 0x1FFE4)
#define FURNACE_COMMAND ((uint32) 0x1FFE3)
#define THERMOSTAT_STATUS_1 ((uint32) 0x1FFE2)
#define AIR_CONDITIONER_STATUS ((uint32) 0x1FFE1)
#define AIR_CONDITIONER_COMMAND ((uint32) 0x1FFE0)
#define GENERATOR_AC_STATUS_1 ((uint32) 0x1FFDF)
#define GENERATOR_AC_STATUS_2 ((uint32) 0x1FFDE)
#define GENERATOR_AC_STATUS_3 ((uint32) 0x1FFDD)
#define GENERATOR_STATUS_1 ((uint32) 0x1FFDC)
#define GENERATOR_STATUS_2 ((uint32) 0x1FFDB)
#define GENERATOR_COMMAND ((uint32) 0x1FFDA)
#define GENERATOR_START_CONFIG_STATUS ((uint32) 0x1FFD9)
#define GENERATOR_START_CONFIG_COMMAND ((uint32) 0x1FFD8)
#define INVERTER_AC_STATUS_1 ((uint32) 0x1FFD7)
#define INVERTER_AC_STATUS_2 ((uint32) 0x1FFD6)
#define INVERTER_AC_STATUS_3 ((uint32) 0x1FFD5)
#define INVERTER_STATUS ((uint32) 0x1FFD4)
#define INVERTER_COMMAND ((uint32) 0x1FFD3)
#define INVERTER_CONFIGURATION_STATUS_1 ((uint32) 0x1FFD2)
#define INVERTER_CONFIGURATION_STATUS_2 ((uint32) 0x1FFD1)
#define INVERTER_CONFIGURATION_COMMAND_1 ((uint32) 0x1FFD0)
#define INVERTER_CONFIGURATION_COMMAND_2 ((uint32) 0x1FFCF)
#define INVERTER_STATISTICS_STATUS ((uint32) 0x1FFCE)
#define INVERTER_APS_STATUS ((uint32) 0x1FFCD)
#define INVERTER_DCBUS_STATUS ((uint32) 0x1FFCC)
#define INVERTER_OPS_STATUS ((uint32) 0x1FFCB)
#define CHARGER_AC_STATUS_1 ((uint32) 0x1FFCA)
#define CHARGER_AC_STATUS_2 ((uint32) 0x1FFC9)
#define CHARGER_AC_STATUS_3 ((uint32) 0x1FFC8)
#define CHARGER_STATUS ((uint32) 0x1FFC7)
#define CHARGER_CONFIGURATION_STATUS ((uint32) 0x1FFC6)
#define CHARGER_COMMAND ((uint32) 0x1FFC5)
#define CHARGER_CONFIGURATION_COMMAND ((uint32) 0x1FFC4)
#define CHARGER_STATISTICS_STATUS ((uint32) 0x1FFC3)
#define CHARGER_APS_STATUS ((uint32) 0x1FFC2)
#define CHARGER_DCBUS_STATUS ((uint32) 0x1FFC1)
#define CHARGER_OPS_STATUS ((uint32) 0x1FFC0)
#define AC_LOAD_STATUS ((uint32) 0x1FFBF)
#define AC_LOAD_COMMAND ((uint32) 0x1FFBE)
#define DC_LOAD_STATUS ((uint32) 0x1FFBD)
#define DC_LOAD_COMMAND ((uint32) 0x1FFBC)
#define DC_DIMMER_STATUS_1 ((uint32) 0x1FFBB)
#define DC_DIMMER_STATUS_2 ((uint32) 0x1FFBA)
#define DC_DIMMER_COMMAND ((uint32) 0x1FFB9)
#define DIGITAL_INPUT_STATUS ((uint32) 0x1FFB8)
#define TANK_STATUS ((uint32) 0x1FFB7)
#define TANK_CALIBRATION_COMMAND ((uint32) 0x1FFB6)
#define TANK_GEOMETRY_STATUS ((uint32) 0x1FFB5)
#define TANK_GEOMETRY_COMMAND ((uint32) 0x1FFB4)
#define WATER_PUMP_STATUS ((uint32) 0x1FFB3)
#define WATER_PUMP_COMMAND ((uint32) 0x1FFB2)
#define AUTOFILL_STATUS ((uint32) 0x1FFB1)
#define AUTOFILL_COMMAND ((uint32) 0x1FFB0)
#define WASTEDUMP_STATUS ((uint32) 0x1FFAF)
#define WASTEDUMP_COMMAND ((uint32) 0x1FFAE)
#define ATS_AC_STATUS_1 ((uint32) 0x1FFAD)
#define ATS_AC_STATUS_2 ((uint32) 0x1FFAC)
#define ATS_AC_STATUS_3 ((uint32) 0x1FFAB)
#define ATS_STATUS ((uint32) 0x1FFAA)
#define ATS_COMMAND ((uint32) 0x1FFA9)
#define WEATHER_STATUS_1 ((uint32) 0x1FFA5)
#define WEATHER_STATUS_2 ((uint32) 0x1FFA4)
#define ALTIMETER_STATUS ((uint32) 0x1FFA3)
#define ALTIMETER_COMMAND ((uint32) 0x1FFA2)
#define WEATHER_CALIBRATE_COMMAND ((uint32) 0x1FFA1)
#define COMPASS_BEARING_STATUS ((uint32) 0x1FFA0)
#define COMPASS_CALIBRATE_COMMAND ((uint32) 0x1FF9F)
#define BRIDGE_COMMAND ((uint32) 0x1FF9E)
#define BRIDGE_PGN_LIST ((uint32) 0x1FF9D)
#define THERMOSTAT_AMBIENT_STATUS ((uint32) 0x1FF9C)
#define HEAT_PUMP_STATUS ((uint32) 0x1FF9B)
#define HEAT_PUMP_COMMAND ((uint32) 0x1FF9A)
#define CHARGER_EQUALIZATION_STATUS ((uint32) 0x1FF99)
#define CHARGER_EQUALIZATION_CONFIGURATION_STATUS ((uint32) 0x1FF98)
#define CHARGER_EQUALIZATION_CONFIGURATION_COMMAND ((uint32) 0x1FF97)
#define CHARGER_CONFIGURATION_STATUS_2 ((uint32) 0x1FF96)
#define CHARGER_CONFIGURATION_COMMAND_2 ((uint32) 0x1FF95)
#define GENERATOR_AC_STATUS_4 ((uint32) 0x1FF94)
#define GENERATOR_ACFAULT_CONFIGURATION_STATUS_1 ((uint32) 0x1FF93)
#define GENERATOR_ACFAULT_CONFIGURATION_STATUS_2 ((uint32) 0x1FF92)
#define GENERATOR_ACFAULT_CONFIGURATION_COMMAND_1 ((uint32) 0x1FF91)
#define GENERATOR_ACFAULT_CONFIGURATION_COMMAND_2 ((uint32) 0x1FF90)
#define INVERTER_AC_STATUS_4 ((uint32) 0x1FF8F)
#define INVERTER_ACFAULT_CONFIGURATION_STATUS_1 ((uint32) 0x1FF8E)
#define INVERTER_ACFAULT_CONFIGURATION_STATUS_2 ((uint32) 0x1FF8D)
#define INVERTER_ACFAULT_CONFIGURATION_COMMAND_1 ((uint32) 0x1FF8C)
#define INVERTER_ACFAULT_CONFIGURATION_COMMAND_2 ((uint32) 0x1FF8B)
#define CHARGER_AC_STATUS_4 ((uint32) 0x1FF8A)
#define CHARGER_ACFAULT_CONFIGURATION_STATUS_1 ((uint32) 0x1FF89)
#define CHARGER_ACFAULT_CONFIGURATION_STATUS_2 ((uint32) 0x1FF88)
#define CHARGER_ACFAULT_CONFIGURATION_COMMAND_1 ((uint32) 0x1FF87)
#define CHARGER_ACFAULT_CONFIGURATION_COMMAND_2 ((uint32) 0x1FF86)
#define ATS_AC_STATUS_4 ((uint32) 0x1FF85)
#define ATS_ACFAULT_CONFIGURATION_STATUS_1 ((uint32) 0x1FF84)
#define ATS_ACFAULT_CONFIGURATION_STATUS_2 ((uint32) 0x1FF83)
#define ATS_ACFAULT_CONFIGURATION_COMMAND_1 ((uint32) 0x1FF82)
#define ATS_ACFAULT_CONFIGURATION_COMMAND_2 ((uint32) 0x1FF81)
#define GENERATOR_DEMAND_STATUS ((uint32) 0x1FF80)
#define GENERATOR_DEMAND_COMMAND ((uint32) 0x1FEFF)
#define AGS_CRITERION_STATUS ((uint32) 0x1FEFE)
#define AGS_CRITERION_COMMAND ((uint32) 0x1FEFD)
#define FLOOR_HEAT_STATUS ((uint32) 0x1FEFC)
#define FLOOR_HEAT_COMMAND ((uint32) 0x1FEFB)
#define THERMOSTAT_STATUS_2 ((uint32) 0x1FEFA)
#define THERMOSTAT_COMMAND_1 ((uint32) 0x1FEF9)
#define THERMOSTAT_COMMAND_2 ((uint32) 0x1FEF8)
#define THERMOSTAT_SCHEDULE_STATUS_1 ((uint32) 0x1FEF7)
#define THERMOSTAT_SCHEDULE_STATUS_2 ((uint32) 0x1FEF6)
#define THERMOSTAT_SCHEDULE_COMMAND_1 ((uint32) 0x1FEF5)
#define THERMOSTAT_SCHEDULE_COMMAND_2 ((uint32) 0x1FEF4)
#define AWNING_STATUS ((uint32) 0x1FEF3)
#define AWNING_COMMAND ((uint32) 0x1FEF2)
#define TIRE_RAW_STATUS ((uint32) 0x1FEF1)
#define TIRE_STATUS ((uint32) 0x1FEF0)
#define TIRE_SLOW_LEAK_ALARM ((uint32) 0x1FEEF)
#define TIRE_TEMPERATURE_CONFIGURATION_STATUS ((uint32) 0x1FEEE)
#define TIRE_PRESSURE_CONFIGURATION_STATUS ((uint32) 0x1FEED)
#define TIRE_PRESSURE_CONFIGURATION_COMMAND ((uint32) 0x1FEEC)
#define TIRE_TEMPERATURE_CONFIGURATION_COMMAND ((uint32) 0x1FEEB)
#define TIRE_ID_STATUS ((uint32) 0x1FEEA)
#define TIRE_ID_COMMAND ((uint32) 0x1FEE9)
#define INVERTER_DC_STATUS ((uint32) 0x1FEE8)
#define GENERATOR_DEMAND_CONFIGURATION_STATUS ((uint32) 0x1FEE7)
#define GENERATOR_DEMAND_CONFIGURATION_COMMAND ((uint32) 0x1FEE6)
#define LOCK_STATUS  ((uint32) 0x1FEE5)
#define LOCK_COMMAND  ((uint32) 0x1FEE4)
#define WINDOW_STATUS  ((uint32) 0x1FEE3)
#define WINDOW_COMMAND  ((uint32) 0x1FEE2)
#define DC_MOTOR_CONTROL_COMMAND ((uint32) 0x1FEE1)
#define DC_MOTOR_CONTROL_STATUS ((uint32) 0x1FEE0)
#define WINDOW_SHADE_CONTROL_COMMAND ((uint32) 0x1FEDF)
#define WINDOW_SHADE_CONTROL_STATUS ((uint32) 0x1FEDE)
#define AC_LOAD_STATUS_2 ((uint32) 0x1FEDD)
#define DC_LOAD_STATUS_2 ((uint32) 0x1FEDC)
#define DC_DIMMER_COMMAND_3 ((uint32) 0x1FEDB)
#define DC_DIMMER_STATUS_3 ((uint32) 0x1FEDA)
#define GENERIC_INDICATOR_COMMAND ((uint32) 0x1FED9)
#define GENERIC_CONFIGURATION_STATUS ((uint32) 0x1FED8)
#define GENERIC_INDICATOR_STATUS ((uint32) 0x1FED7)
#define GENERAL_RESET ((uint32) 0x17F##)
#define DOWNLOAD  ((uint32) 0x17E##)
#define TERMINAL ((uint32) 0x17D##)
#define INSTANCE_ASSIGNMENT ((uint32) 0x17C##)
#define INSTANCE_STATUS ((uint32) 0x17B##)
 
#89 ·
here are some can bus DGN that can be used. note some wont' be for vehicles.
Copying and pasting a list is pretty useless...

The OBD-II Parameters (PIDs) and diagnostic trouble codes (DTCs) are vital to using OBD, but the short description are pretty much useless for implementations. You really need a more complete description. An example is "gas pedal" position reporting. You need to know the meaning of absolute, relative and commanded positions, and what point is considered pedal vs. throttle.
 
This post has been deleted
#96 ·
Have you actually built that circuit? You would have found that a 4n37 optocoupler is far too slow for this use. You would have to operate the SPI bus at well under 400KHz, likely under 100KHz.

We use a Si8421 isolator on the CAN Tx and Rx lines. It's faster, more reliable, doesn't have aging problems, meets margins over a wider temperature range and uses less power. A hobbyist design might consider one of the newly available isolating CAN transceivers -- the extra cost and availability risk isn't a problem when you need only a few.

Your transceiver slew rate resistor is probably pointless.

Most designs would use a simple linear regulator for the widely-varying power requirements of a CAN transceiver. The transceiver uses minimal power while idle and during reception, but uses significant power briefly during transmission. This can lead to stability problems unless carefully tested.
 
#102 ·
The original question that started this thread was "How do I use Can bus to get my information."
The answer, though not simple, it to use the PowerTrainControl model.
the problem is that no controller conforms to this model.
Correct me if I am wrong.
Also the ThrottlePositionModule is not supported.
These are run under the Body control Module (BCM)
Then there are the controllers that do not support CanBus.
ODB was not meant for RunTime reporting but like its name says Diagnostics.
So the next level up is to supply a module for each that is external, that provided the info the controller and throttle does not, using the models specified.
 
#108 ·
though these project don't directly address how to have a homogeneous Can Bus for all controllers, these are building blocks.
if you a tinker, you can build these if they interest you, otherwise you can wait for the put together nodes I will sell.
I am working on using a more powerful Embedded that is a gateway so dissimilar DLC can be married together.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top