# CAN Bus communication



## mizlplix (May 1, 2011)

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


----------



## tomofreno (Mar 3, 2009)

mizlplix said:


> 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...
> Miz


 There's this: http://www.canbus.us/
Just started looking at it myself for similar reasons, so don't know much at this point.


----------



## DaveAK (Jun 28, 2009)

While CANBus can be used to connect various systems it's a protocol for message transfer and the messages themselves are system specific. While the major auto manufacturers may have collaborated on a standard messaging systesm such as OBD2 there's no guarantee that any particular system will take with another, unless they speak the same language. It might well be that in the HVAC industry they have developed their own messaging standard to be delivered by CANBus. I'm not aware of any such efforts in the controller industry, i.e. I don't know if a Curtis Spyglass will work with a Sevcon controller, although they both use CANBus for connectivity. (At least I think the Spyglass is CANBus, but the principal of what I'm trying to convey is the same.)

So an OBD2 scanner that's CAN compliant might read the data from your Curtis, but it wouldn't be able to interpret it because the Curtis doesn't spit out OBD2 messages. The scanner might not even respond at all if it doesn't get OBD2 messages.

There are CAN interfaces that will read the CAN output from the Curtis and present you with the raw data, but then you need to have something that will interpret the messages. I've been working on cracking the Sevcon Powerpak controllers. You can read about my efforts here: http://www.davescomputerstuff.com/sevcon/sevcon.html.


----------



## frodus (Apr 12, 2008)

note: spyglass is RS232, just a dumb terminal.

but I get what you're saying.

Curtis supports some J1939 messages via canbus and PID's. It's really not the adapter as much as the software that is running on your device (desktop, laptop, etc). The one's I've looked at seem to pass everything through to the canbus, it doesn't filter messages. That gets done in the software, which at this point, isn't written for the Curtis.

I'd love to work with people on this, I've got some ideas.


----------



## DaveAK (Jun 28, 2009)

frodus said:


> note: spyglass is RS232, just a dumb terminal.
> 
> but I get what you're saying.
> 
> ...


So does J1939 cover the actual messages themselves, or just the message format?

OK, found this on wikipedia "A PGN identifies a message's function and associated data. J1939 *attempts* to define standard PGNs to encompass a wide range of automotive, agricultural, marine and off-road vehicle purposes. A range of PGNs (00FF0016 through 00FFFF16, inclusive) is reserved for *proprietary* use."

Use of bold is mine to highlight what I said above. Also apparently J1939 did not original include CAN, but does now.

CANBus is like a telephone. You can use a phone to make a connection to someone in France, but unless you can speak French or they can speak English you're not going to be able to communicate.


----------



## DaveAK (Jun 28, 2009)

One other caveat. All devices on the system have to be set to the same baud rate to be able to communicate. My Sevcon has a fixed baud rate of 100kbps. If Curtis supports J1939 it will most likely be communicating at either 250kbps or 500kbps and might be switchable between these two speeds.

As you can see, getting multiple devices to work together on one CAN Bus depends on many factors. Having said that it's pretty straightfoward to actually hook a PC to a CAN Bus device and get the data. It's also pretty easy to sniff the data going between two devices. What you do with the data, or what data you can inject in to the bus is where the fun starts.


----------



## frodus (Apr 12, 2008)

100kbps? isn't it 125/250/500?

From everything I've read (I'm still trying to test), the serial/USB/Bluetooth dongles are just a bridge between the software and the Canbus. They don't do much filtering, they just act as a bridge between the 5(IIRC) different formats on the OBD port. The software is what does the "language" conversion....

I just don't have much experience with Canbus to even know what to send and what I'd recieve, it's been years since I've done much Com stuff.


That being said, I am aware it's just a "line" that gets talked on. But those dongles can pass J1939 messages/PID messages..... and the curtis supports those..... so it goes to reason that I could use a dongle to talk to the curtis, although it would likely be unsecured if it was via bluetooth.


----------



## bjfreeman (Dec 7, 2011)

For the physical layer you can get a Canbus to USB adapter for you laptop.
I have a Java applet that show the raw messages, and then tries to Identify the type of messages and display them.
even J1939 is proprietary and can not be entirely decoded.
If someone wants to provide formats I wil be glad to add them to the app and provide it free off my website.


----------



## bjfreeman (Dec 7, 2011)

you can use a app call PuTTY to setup raw data viewing
here is wealth of info.
https://www.vector.com/vi_downloadcenter_en.html
http://www.kvaser.com/en/about-can/higher-layer-protocols/36.html


----------



## bjfreeman (Dec 7, 2011)

frodus said:


> 100kbps? isn't it 125/250/500?
> 
> That being said, I am aware it's just a "line" that gets talked on. But those dongles can pass J1939 messages/PID messages..... and the curtis supports those..... so it goes to reason that I could use a dongle to talk to the curtis, although it would likely be unsecured if it was via bluetooth.


for my CanBus based on DSP that has a canBus the internal software send a message looking for a response at the highest speed then reduces the speed till it gets a response it is looking for.
bluetooth is a physcal layer interface, off the CanBus Driver. ylour bluetooth has to be able to interface with another Canbus Driver. then the Receiving BlueTooth would send it to an app and decodes the messages.


----------



## DJBecker (Nov 3, 2010)

frodus said:


> 100kbps? isn't it 125/250/500?


Those are standard choices, but CAN bus can use almost any signalling rate. Most hardware supports at least 1Mbps, with 2Mbps transceivers available.

For automotive use, the hardware should always use 500K baud and respond to 11 bit IDs. Always.

Most inexpensive "OBD2 readers" are copies of the ELM327, which is a PIC chip programmed to communicate over CAN and a few other interfaces. The host communication is over a serial port, so a USB adapter has a standard USB-to-serial chip, and a bluetooth one has a bluetooth-to-serial module, etc. This is important, because you might be talking over USB at 12Mbps, but inside it's limited to 19200 baud (and it's ASCII encoded) before going over the 500K CAN bus.

We implemented CAN bus with OBD2 reporting in our EV controller and BMS. By adhering to the standard we can simply use an under-$20 OBD2-bluetooth and Torque running on Android to get very nice looking digital gauges. Or plug in a Scangauge.


----------



## DaveAK (Jun 28, 2009)

frodus said:


> 100kbps? isn't it 125/250/500?


Nope, for the Sevcon it's 100kpbs. I don't think that's a typical baud rate for most CAN devices though, whereas the ones you list are. CAN 2.0b will work with rates up to 1Mbps.


----------



## DaveAK (Jun 28, 2009)

frodus said:


> From everything I've read (I'm still trying to test), the serial/USB/Bluetooth dongles are just a bridge between the software and the Canbus. They don't do much filtering, they just act as a bridge between the 5(IIRC) different formats on the OBD port. The software is what does the "language" conversion....
> 
> I just don't have much experience with Canbus to even know what to send and what I'd recieve, it's been years since I've done much Com stuff.
> 
> ...


Yup you're right on everything here. If the dongle is a straight CAN device it will talk to anything else that's CAN, you've just got to be able to interpret the messages. However if the device is an OBD2 scanner there's no guarantee that it would work with other CAN devices. For two reasons, firstly OBD2 is an automotive protocol only as far as I know and wouldn't do much good talking to a HVAC system as described in the OP, and secondly OBD2 is not necessarily CAN in the first place. It wasn't until 2005 or so that OBD2 had to use CAN as the transport protocol.


----------



## frodus (Apr 12, 2008)

DJBecker said:


> Those are standard choices, but CAN bus can use almost any signalling rate. Most hardware supports at least 1Mbps, with 2Mbps transceivers available.
> 
> For automotive use, the hardware should always use 500K baud and respond to 11 bit IDs. Always.
> 
> ...


What controller and BMS?

I have one of those cheap readers and torque, just don't know how to set it up  Only worked on it one night, probably look at it this weekend. I wired it up to my elithion BMS, just don't know what PID's to enter into torque.


----------



## frodus (Apr 12, 2008)

DaveAK said:


> Yup you're right on everything here. If the dongle is a straight CAN device it will talk to anything else that's CAN, you've just got to be able to interpret the messages. However if the device is an OBD2 scanner there's no guarantee that it would work with other CAN devices. For two reasons, firstly OBD2 is an automotive protocol only as far as I know and wouldn't do much good talking to a HVAC system as described in the OP, and secondly OBD2 is not necessarily CAN in the first place. It wasn't until 2005 or so that OBD2 had to use CAN as the transport protocol.


 
A manufacturer doesn't have to use CANBUS to be OBD2 Compliant (just one of the protocols is fine), but in order for those scanners to technically OBD2 compliant, they must read all of the protocols. All of the readers I've used have worked with my Audi A4 Quattro, which is 500kbaud Canbus 11bit, so at least I know canbus works. I just haven't got to the next step of actually testing anything


----------



## DaveAK (Jun 28, 2009)

frodus said:


> What controller and BMS?
> 
> I have one of those cheap readers and torque, just don't know how to set it up  Only worked on it one night, probably look at it this weekend. I wired it up to my elithion BMS, just don't know what PID's to enter into torque.


Elithion will have to give you the PID information they use I would suspect. Don't know how Torque works. Is it strictly OBD2?


----------



## DJBecker (Nov 3, 2010)

frodus said:


> What controller and BMS?
> 
> I have one of those cheap readers and torque, just don't know how to set it up  Only worked on it one night, probably look at it this weekend. I wired it up to my elithion BMS, just don't know what PID's to enter into torque.


We designed and built our own EV electronics. Most of the source code is up on Google code, including a port of OBD2 reporting code that should work with the Cougar controller.

The battery monitoring and charger control is still in progress, but the controller CAN communication has been working for a bit over a year.


----------



## DaveAK (Jun 28, 2009)

frodus said:


> A manufacturer doesn't have to use CANBUS to be OBD2 Compliant (just one of the protocols is fine), but in order for those scanners to technically OBD2 compliant, they must read all of the protocols. All of the readers I've used have worked with my Audi A4 Quattro, which is 500kbaud Canbus 11bit, so at least I know canbus works. I just haven't got to the next step of actually testing anything


Yeah, I guess that's true, so cheaper or older OBD2 scanners may not *technically* be compliant. If they are fully compliant then yes they should read anything on the CAN bus, but then it comes down to interpreting the information. Plugging an OBD2 scanner in to a HVAC system isn't going to give you useful information, at least in the supplied OBD2 software. If you can take the feed from it and pass it to appropriate software then you can decode your messages, otherwise it's not going to be much help.

Just for the sake of mentioing it my CAN dongles are strictly that. They don't come with any software and so are not limited in any way. I use either an Arduino with a CAN Shield or a Gridconnect CAN to USB device. Both work great for what I need, which is strictly limited to the Sevcon controller right now. They could just as easily work with a Curtis or an Elithion, if you knew what the messages that were being transmitted actually meant. And again, if they're in any way proprietary, (which I suspect they are), you'll need to get that information from somewhere. Otherwise you'll be trying to figure it out like I am with the Sevcon.


----------



## frodus (Apr 12, 2008)

Dave,

Elithion gives all the serial and canbus protocol information and PID lists on the website, so yes, they provide it.

Torque uses OBD2 dongles to communicate to whatever. Orion BMS uses a dongle to communicate to their BMS and Torque (android).

And yes, I'm aware that a normal OBD2 software meant to only do normal PID's isn't going to work, but torque does Extended PID's, you just tell them what they are and presto.


----------



## DJBecker (Nov 3, 2010)

DaveAK said:


> Elithion will have to give you the PID information they use I would suspect. Don't know how Torque works. Is it strictly OBD2?


Torque works with a few OBD2 adapters, but I suspect almost everyone uses it with a cheap ELM327 bluetooth dongle. WiFi dongles cost about 10x as much.

(BTW, an iPad has bluetooth hardware but intentionally does not support serial-over-bluetooth, so you pretty much would need need a WiFi dongle. Thus almost everyone doing OBD2 gauges uses Android.)

Once you know the PIDs for a device, you can enter them into Torque and have the data reported as a gauge. But Torque relies on the dongle to detect the OBD2 communication method. An ELM327 will attempt to connect to an OBD2 ECU using CAN at 250K and 500K baud, 11 and 29 bit IDs, as well as the other older communications links. It certainly won't detect a CAN device at 100K with no OBD2 reporting.

You can easily find the ELM327 datasheet. It's 40-50 pages long, and describes the 'AT' command set it uses. It tries to make all OBD2 communication links look the same, but it does have commands for directly handling raw CAN messages.


----------



## DaveAK (Jun 28, 2009)

frodus said:


> Dave,
> 
> Elithion gives all the serial and canbus protocol information and PID lists on the website, so yes, they provide it.
> 
> ...


Sounds like you've got exactly what you need then. I'll have to get myself an Android of some description and Torque and see if I can hook it up to the Sevcon.

Question though. Let's say you have a PID that returns controller temperature in one of the data bytes, but it's encoded. Can you tell Torque how to decode the value? In this case it's simple, just data value minus 30 gives you temperature in celcius. There could be more complicated encoding using multiple data bytes to represent a given value. OBD2 does just this I think. Can Torque handle encoding other than OBD2?


----------



## DaveAK (Jun 28, 2009)

DJBecker said:


> Torque works with a few OBD2 adapters, but I suspect almost everyone uses it with a cheap ELM327 bluetooth dongle. WiFi dongles cost about 10x as much.
> 
> (BTW, an iPad has bluetooth hardware but intentionally does not support serial-over-bluetooth, so you pretty much would need need a WiFi dongle. Thus almost everyone doing OBD2 gauges uses Android.)
> 
> ...


I think the ELM327 can handle CAN other than OBD2 if I recall. I looked at it a couple of years a go. So it should work with a 100k device, but there's no real point as the device won't be OBD2, and that's what the ELM327 is really being used for. This is why I was trying to make the distinction between OBD2 and CAN.


----------



## frodus (Apr 12, 2008)

DaveAK said:


> Sounds like you've got exactly what you need then. I'll have to get myself an Android of some description and Torque and see if I can hook it up to the Sevcon.





DaveAK said:


> Question though. Let's say you have a PID that returns controller temperature in one of the data bytes, but it's encoded. Can you tell Torque how to decode the value? In this case it's simple, just data value minus 30 gives you temperature in celcius. There could be more complicated encoding using multiple data bytes to represent a given value. OBD2 does just this I think. Can Torque handle encoding other than OBD2?




Yes, it’s encoded. There’s an “equation” associated with each PID. You can modify things there. 

You need:
OBD2 Mode and PID (in hex)
Long name (used in menus)
Short name (used in displays)
Minimum value
Maximum value
Scale factor
Equation (eg. A * B + 20, etc)
OBD header to use (leave blank for auto, or hex header)

Then you can test it. Once added you can now add a gauge on there and pic the value it’s reading from in the list of variables within torque.





DaveAK said:


> I think the ELM327 can handle CAN other than OBD2 if I recall. I looked at it a couple of years a go. So it should work with a 100k device, but there's no real point as the device won't be OBD2, and that's what the ELM327 is really being used for. This is why I was trying to make the distinction between OBD2 and CAN.


 
We get the distinction, but I already said, it’s just a pass through. The OBD2 specifies the connector, not the “languages”. The languages it speaks are completely within the software/microcontroller. The ELM device just takes those 5-6 protocols and converts to serial. There’s no filtering going on within the OBD2 dongle. *It could just as easily be called a “canbus + some other shit” dongle*. The important part here, is that it contains canbus + transceiver, it auto detects between 125, 250 and 500 (or you can set up another value within the AT command set (IIRC) for the chip it uses (Mine is a cheap Chinese alternative that is close to compatible with ELM327, but I’m purchasing one based on another faster chip). 

So rather than use a can tranciever and code through your Arduino, this chip would be paired with a tranciever, convert anything on CANBUS to serial and output to either bluetooth, USB-Serial, ttl converter, microcontroller or wifi-serial bridge....etc. It converts these: http://en.wikipedia.org/wiki/On-board_diagnostics#OBD-II_Diagnostic_connector to serial.

 
Read the ELM Command Set, or read the command set for the STN1110 chip.


----------



## DaveAK (Jun 28, 2009)

frodus said:


> Yes, it’s encoded. There’s an “equation” associated with each PID. You can modify things there.


Cool.




> We get the distinction, but I already said, it’s just a pass through.


I get that you get the distinction.


----------



## mizlplix (May 1, 2011)

Ok, just to sum up:

We have a circuit that will connect our controller to an information gathering device.

We need an appropriate sized LCD screen to display that information as well as some memory and a CPU to process the data. {at an affordable price} Like one of the new touch screen tablets. One that can be built in to the vehicle dash board. 

There are existing devices to go in-between to convert/interpret/and send wired or wireless.

We need to agree on an operating system that is not too difficult to deal with as they all have their quirks. Android has been already mentioned.

Lastly, the software to do the dirty work for us. {Possibly Torque with some mods perhaps? -to suit the controllers individually-}

What did I miss?

Miz


----------



## frodus (Apr 12, 2008)

android, hands down. Cheaper devices come out every day.

iOS is locked down unless you use wifi which increases the cost of the device. Windows or Linux based boards/LCD's are too bulky and costly. Android is pretty open and there's lots of devices out there for under $300. I own a Samsung Player 5.0. It's only wifi/bluetooth, so no cell service. They run about $240 right now at BestBuy. Works great with torque and the display is large and it's pretty fast. There are 7" tablets too, but for my motorcycle, I wanted a 5".


Lets brainstorm, because I was actually thinking about building something ..... What about a mediary device, something that goes in between our BMS, Controllers, chargers and the bluetooth/wifi? Something that can translate easily and create PID's specifically for Torque. What about security? I mean, if it's bluetooth, PIN's are easy to guess... so maybe a pushbutton "discoverable" option so it's only discoverable for a short period. Options for multiple canbus ports, multiple serial ports, RS485 options, SD Card slot.... I mean, it could be pretty flexible and offer more than just tapping into the canbus.... just a thought


----------



## bjfreeman (Dec 7, 2011)

frodus said:


> android, hands down. Cheaper devices come out every day.
> 
> iOS is locked down unless you use wifi which increases the cost of the device. Windows or Linux based boards/LCD's are too bulky and costly. Android is pretty open and there's lots of devices out there for under $300. I own a Samsung Player 5.0. It's only wifi/bluetooth, so no cell service. They run about $240 right now at BestBuy. Works great with torque and the display is large and it's pretty fast. There are 7" tablets too, but for my motorcycle, I wanted a 5".
> 
> ...


I am an old GNU, Linux person.I am also a hardware PCB person. so that is what I base my comments on.
get the device that works for you, even a visor mounted screen.
Then load Linux with a graphic interface, I use Centros distribution. the Device I use allows a boot from a internal SD so I can update the Linux drivers.
I use a 10.2 tablet that the supplier modified to my specs. I run Linux. I run Eclipse development on it, using a USB drive.
you can use a mini USB port for up to ten USB connection. Smart phones and most new laptops have this built in.
I would suggest a mini (netbook) laptop as the base unit and then use the Screen port to drive your display. you can put the netbook in a sadle bag and have a quick connect to helmet.
this gives flexibility without doing any customization.
also add voice control


----------



## frodus (Apr 12, 2008)

BJFreeman,

These devices we're talking about can't just "load linux"... they're embedded, you'd have to reverse engineer a device on a hardware level and custom compile a kernel, and that's a maybe. And most smartphones DO NOT have USB host ability, in fact, almost NONE have that ability. 

Go look at Torque for Android, the GUI software is already done. Why recreate the wheel? I mean, feel free to write some software, but Torque does pretty much everything we'd want, even GPS based logging of PID's so you can see your SOC mapped over the course of your drive.

I mean, for $240 with wifi, GPS, bluetooth fast processor, speakers and front/rear cameras... something I can use for GPS, or to log variables.... seems like you couldn't beat that with something running a Centros distribution running on a mini-pc with some sort of LCD output.


----------



## frodus (Apr 12, 2008)

RE: Bluetooth OBDII dongles

I ordered a Bluetooth OBD-II reader based on the New STN1110 chipset last night. Should be here next week and I can hopefully get it talking with my Curtis and Elithion. The only downsides I see, is that I don't really have any extra IO like I want, there's no onboard logging so I HAVE to have my Android device, and there's no security at all. It would be nice to talk to other devices on my bike or even have some IO so I can control/monitor some things.... Maybe I'll just build a Canbus IO card for that...

hopefully I can get some stuff tested in the coming weeks. Might need some support via you guys on the forum. I'll start with terra term to chat with the canbus devices, then I'll move towards Torque.

Just gotta say, the Samsung Player 5.0 running Torque looks Amazing. It's not OLED, but the display is very bright and easy to read. Dwarfs my old 4" Samsung Captivate screen.


----------



## DaveAK (Jun 28, 2009)

Travis, you know how much I like a good project. You're going to make me break my new year's resolution of not starting another one until I have at least two of the ones I have got finished. 

Still, I only got my netbook so I could load Android on to it. Maybe this weekend I'll see how the current distros look and see if I can get it dual booting into Android and install Torque. The CAN devices I've got should be a good start.


----------



## DJBecker (Nov 3, 2010)

The obvious way of doing what you plan is using a microcontroller with dual CAN bus, and a bunch of UARTs that support LIN. Then write software that emulates the ELM327 and standard OBD2 PIDs.

We build around a slightly different approach. We use STM32 processors that have dual CAN bus controllers, but put a transceiver on only one of the two. Our firmware responds to standard OBD2 CAN messages, sometimes substituting related values. (Motor temperature is reported as oil temperature, controller heatsink temperature is reported as coolant temperature, motor current is reported MAF, etc.)

OBD2 allows up to 8 responding ECUs, so you don't need to do anything special with multiple OBD2-capable controllers on one bus. An ECU can also act as a OBD2 translator: receive a message, gather the information from non-OBD2 CAN devices on the same bus, and respond. But you can't mix speeds on one bus, so dealing with something like a 100K baud controller would require a second CAN bus.

We wired our CAN to a OBD2 socket so that we could plug in any standard reader. This typically has a OBD2-to-bluetooth reader plugged in so that we can use Torque.

CAN isn't convenient for development debugging so we also have a direct serial bluetooth connection. We've been using the CSR bluetooth modules that are under $10 on FleaBay. They take 3V-5V logic inputs, so you don't need level shifting or a serial transceivers. The configuration is done with 'AT' commands that set the ID, passkey, baud rate, etc. so you can be somewhat secure.


----------



## frodus (Apr 12, 2008)

Haha, Dave you can help me a little with the canbus.... email me and send me your phone number.... might have to skype a bit 

Only thing I see is that torque is bluetooth serial, so you at least have to get your stuff talking to torque somehow. Do you have a bluetooth-serial dongle or breakout board?


----------



## bjfreeman (Dec 7, 2011)

frodus said:


> BJFreeman,
> 
> These devices we're talking about can't just "load linux"... they're embedded, you'd have to reverse engineer a device on a hardware level and custom compile a kernel, and that's a maybe. And most smartphones DO NOT have USB host ability, in fact, almost NONE have that ability.
> 
> ...


Android Runs on a Linux Kernel.
http://developer.android.com/guide/basics/what-is-android.html
It is the same as adding any Graphic interface to Linux.
Torgue therefore has to interact with the Linux drivers, though it does it through the Android API.
however it seems you are not wanting to brain storm beyond Android, so I will not go further.


----------



## DaveAK (Jun 28, 2009)

frodus said:


> Haha, Dave you can help me a little with the canbus.... email me and send me your phone number.... might have to skype a bit
> 
> Only thing I see is that torque is bluetooth serial, so you at least have to get your stuff talking to torque somehow. Do you have a bluetooth-serial dongle or breakout board?


Trying to figure out what Torque uses as its input right now. Digging through the wiki. I can't imagine all those adapters transmit the data the same way, although of course it's possible. Is there some setup in Torque to configure the input data stream?

It's going to be a bummer if it only accepts Bluetooth. I don't have any kind of adapter for that. It won't do it over wifi? I'd then have to get both bluetooth for the CAN and bluetooth for the netbook. Too spendy right now.

I'll email you my details, but it'll have to be later tonight as I'm supposed to be working right now.  Oh, and I'm not hip enough to skype, but maybe I'll figure that out tonight too.


----------



## bjfreeman (Dec 7, 2011)

DaveAK said:


> Still, I only got my netbook so I could load Android on to it..


you can put it on a USB Drive and set the netbook to boot first from USB.
That is how I run it on mine.


----------



## frodus (Apr 12, 2008)

BJ, It has nothing to do with not wanting to think outside the box. I've spent a lot of my spare time in the last 4 years looking at all the different Display options out there. I worked with a friend on Xenodisplay on the iPhone. I attempted to interface an S3C2440 Embedded processor running linux on a 7" touchscreen (and tried using Windows CE 6.0). The main problem was cost. I could get things running on the Iphone, but hardware to interface required wifi-serial interfaces that weren't really cheap. The S3C2440 board wasn't fast enough and at the time, USB-serial was unsupported in the kernel and the kernels were very unstable. 

It's not that I'm trying not to brainstorm beyond Android devices.... but the amount of work involved in porting a linux distribution to an existing embedded device is not something that happens easily if at all. Just not something I'd want to spend my time doing when there's already MUCH better software out there than I could ever write. 

I'm trying to stay on topic with the OP (Torque, bluetooth, android) as well as keep from recreating the wheel. I mean, Why do all that when android devices are cheap, and they run software that is already developed? 

Know of any other Linux or windows software that can do this for under $5?
(note, it's logging PID's, has a map overlay and is recording video off of a camera)









Orion did it for their BMS:
http://www.orionbms.com/screenshots/?album=1&gallery=3
runs on Torque, scangauge


----------



## bjfreeman (Dec 7, 2011)

As far as canbus
the DSP 56F803 I use came with a program that allows data as well as a scope function that communicates thru the Canbus.
so I have all the data about which each DSP is doing in my traction system.
I can track PWM, Analog signals as wave forms and voltage.
like one analog input is from the current bar inline with the batteries and the output of the three IGBTs.
so sticking to automobile standards are nice, but room should be left for other information that is not in the standards.


----------



## frodus (Apr 12, 2008)

DaveAK said:


> Trying to figure out what Torque uses as its input right now. Digging through the wiki. I can't imagine all those adapters transmit the data the same way, although of course it's possible. Is there some setup in Torque to configure the input data stream?
> 
> It's going to be a bummer if it only accepts Bluetooth. I don't have any kind of adapter for that. It won't do it over wifi? I'd then have to get both bluetooth for the CAN and bluetooth for the netbook. Too spendy right now.


The adapters it supports are ELM327 compatible, so they should all adhere to simple serial over bluetooth. 

It'll do wifi too. On android devices though, most don't support Ad-Hoc wifi unless they've been rooted and a custom rom is installed or the wifi tables are modified. But it might work if you're running android on a PC, although I don't how how well the hardare on a PC is supported within the android kernel.


----------



## bjfreeman (Dec 7, 2011)

frodus said:


> BJ,orm beyond Android devices.... but the amount of work involved in porting a linux distribution to an existing embedded device is not something that happens easily if at all. Just not something I'd want to spend my time doing when there's already MUCH better software out there than I could ever write.
> 
> I'm trying to stay on topic with the OP (Torque, bluetooth, android) as well as keep from recreating the wheel. I mean, Why do all that when android devices are cheap, and they run software that is already developed?
> 
> Know of any other Linux or windows software that can do this for under $5?


This Thread started out as CANBus info.
this goes beyond Torque, which is nice for what it does.
the 10.2 tablet I use was orginally a Android. To me Android would not let me do what I wanted.
so I purchase all you mention for less than $200 in hardware.
As I mentioned Android sits on top of the Linux kernel.
yes I have to recompile to the processor but that is what linux is built to do.
I developed on my netbook running linux.So was not any cost.


----------



## DaveAK (Jun 28, 2009)

frodus said:


> The adapters it supports are ELM327 compatible, so they should all adhere to simple serial over bluetooth.
> 
> It'll do wifi too. On android devices though, most don't support Ad-Hoc wifi unless they've been rooted and a custom rom is installed or the wifi tables are modified. But it might work if you're running android on a PC, although I don't how how well the hardare on a PC is supported within the android kernel.


OK, so I should be able to get my Arduino CAN to emulate ELM327 easily enough I would think. The Gridconnect device might already spit out the data in an ELM327 format for all I know. In which case the program I wrote for my Sevcon is ELM327 compatible as well. If not I'll make it so that it is.

As for Android on a PC. When I last looked it had support for USB, WiFi, Bluetooth and all that good stuff, it just wasn't very stable at the time. Hopefully things have improved. If they have then what are the chances of using USB do you think? Can you tell Torque which port you're using?


----------



## frodus (Apr 12, 2008)

BJ,
I'm asking this in a constructive way because I'm interested on how you did it, not to be argumentative:
What 10.1" Android tablet did you buy?
Where did you get a 10.1" tablet for under $200? (sounds very cheap).
How did you root it?
How did you install CentOS on the tablet? (from dumping the files from the device, to recompiling, to installing the new ROM)
Could it be done easily on any other android device?


----------



## bjfreeman (Dec 7, 2011)

frodus said:


> But it might work if you're running android on a PC, although I don't how how well the hardare on a PC is supported within the android kernel.


The android kernal does not handle drivers. Linux does. on the pc Netbooks usually have wifi as standard. some have blue tooth. mine does not have bluebooth so I used dongle and loaded the driver into the linux Kernel.
I had to get the linux driver code for my devices in the netbook.


----------



## frodus (Apr 12, 2008)

DaveAK said:


> As for Android on a PC. When I last looked it had support for USB, WiFi, Bluetooth and all that good stuff, it just wasn't very stable at the time. Hopefully things have improved. If they have then what are the chances of using USB do you think? Can you tell Torque which port you're using?


Torque now supports (what it says in the App):
Wifi Elm327 with an IP address in Ad-Hoc
Bluetooth Elm327
USB devices (but this is only supported with Honeycomb 3.0 or ICS 4.0 devices)

So you'd have to check and see if the Linux Kernel included with Android for the PC supports USB host.

Get android running first, then install torque. That will help you a lot.

There's also a dev forum.


----------



## frodus (Apr 12, 2008)

BJ, I meant, the linux kernel included with the PC version of Android for the PC. I don't know what they installed or didn't install or how hard it is to recompile. As you say, it didn't include bluetooth....thats exactly what I'm saying. 

stop being so argumentative.... It's not like you're being forthcoming in showing us any of what you've done. 

show us some pictures of your setup, model numbers for your tablet, details on what you did.... etc.


----------



## bjfreeman (Dec 7, 2011)

frodus said:


> BJ,
> I'm asking this in a constructive way because I'm interested on how you did it, not to be argumentative:
> What 10.1" Android tablet did you buy?
> Where did you get a 10.1" tablet for under $200? (sounds very cheap).
> ...


unless someone say I don't know what I know, I consider all as a discussion only, clearing up misunderstandings.
I got the 10.2 through www.dhgate.com and sell them on my ecommerce store and use them with ERP sofware I support.
the device is about $190.
not sure what you mean by root it.
I got the manufacture to add a boot from an internal SDX. I provided the code to them. the SDX .
so I put the whole centos including the boot on the SD
I doubt the main stream Droids will allow this change or a rom change, but yes compile on a device like a netbook with a targets to the device processor then burn a new rom.


----------



## frodus (Apr 12, 2008)

What's link to your ecommerce store?

So they provided you their linux kernel for their device?


----------



## bjfreeman (Dec 7, 2011)

frodus said:


> BJ,
> 
> stop being so argumentative.... It's not like you're being forthcoming in showing us any of what you've done.
> 
> show us some pictures of your setup, model numbers for your tablet, details on what you did.... etc.


I am working on documentation on my website.
I have posted an overall overview of my system in a few threads.
I have supplied the schematic and PCB documentation for the new boards as I get them done.
Getting the actual components are difficult and in the weather i don't feel like crawling under the bus to show you cases since that is all you will see.
you will have to wait till we put in the new boards this summer. Then I will show you.


----------



## bjfreeman (Dec 7, 2011)

frodus said:


> What's link to your ecommerce store?
> 
> So they provided you their linux kernel for their device?


http://www.specialtymarket.com/products/PROMOTIONS/p_10041
$190 is my and your cost if you order from them.
I bought the Device and dump the etc folder. it has all the config info from that I got the driver code.


----------



## frodus (Apr 12, 2008)

Man, you're all over the place.... I wasn't talking about these "boards" BJ .... I'm *STILL* talking about your "android" tablet! Try to stay focused please.....

I'm asking for some more supporting information, pictures of your so called "android tablet" running CentOS. 

Just not sure why you're so stuck on Running another linux distro on an android device, when the existing android OS already supports Torque and OBDII bluetooth, the android devices are cheap (some cheaper than $100), and the app costs $5..... 

If it was you and I wanting to run some software, fine, we do what we want, but I'm thinking a little further than just you and I, I'm thinking something that can run on phones, tablets and readers AS IS, without any compiling, coding, etc. Torque and Android do that, without modification. 

Why go through all the trouble of running another distro on hardware that already works just fine with what it's got.... I'm not really following your logic.


----------



## DaveAK (Jun 28, 2009)

frodus said:


> Torque now supports (what it says in the App):
> Wifi Elm327 with an IP address in Ad-Hoc
> Bluetooth Elm327
> USB devices (but this is only supported with Honeycomb 3.0 or ICS 4.0 devices)
> ...


Thanks Travis. This may be a job for tonight. I've glanced through the ELM327 data sheet and now I remember why I went straight CAN for my project.  The ELM chip looks to be a very comprehensive chip but was overkill for my needs at the time. It was much cheaper and easier at the time for me to go with CAN only.

Anyway, once I figure out the ELM327 output as it gets streamed from the OBD2 device I should be all set. I can't quite see it in there at a quick glance though. I'll go on the Torque forums later and see what I can find.


----------



## frodus (Apr 12, 2008)

bjfreeman said:


> http://www.specialtymarket.com/products/PROMOTIONS/p_10041
> $190 is my and your cost if you order from them.
> I bought the Device and dump the etc folder. it has all the config info from that I got the driver code.


not a bad price, thanks for the link.

The fact that you could even get to the etc folder, means it was already rooted to begin with.... most devices commercially available in the US are not rooted.


----------



## bjfreeman (Dec 7, 2011)

frodus said:


> Why go through all the trouble of running another distro on hardware that already works just fine with what it's got.... I'm not really following your logic.


this thread is about can bus. the app I use does not fit into torgue as I posted on this thread.


----------



## bjfreeman (Dec 7, 2011)

frodus said:


> not a bad price, thanks for the link.
> 
> The fact that you could even get to the etc folder, means it was already rooted to begin with.... most devices commercially available in the US are not rooted.


Ok you are talkng about permissions.
yes if your running linux you can not get to the etc folder.
however there is more than one way to hack a ROM


----------



## frodus (Apr 12, 2008)

BJ,

You do it your way, I'll do it mine.... without all the extra hassle of custom hardware, roms, and software.


----------



## bjfreeman (Dec 7, 2011)

lets leave at that.


----------



## DJBecker (Nov 3, 2010)

frodus said:


> not a bad price, thanks for the link.
> 
> The fact that you could even get to the etc folder, means it was already rooted to begin with.... most devices commercially available in the US are not rooted.


The description doesn't mention bluetooth. In my experience, if it doesn't explicitly list it as a feature, the device doesn't have it.


----------



## bjfreeman (Dec 7, 2011)

DJBecker said:


> The description doesn't mention bluetooth. In my experience, if it doesn't explicitly list it as a feature, the device doesn't have it.


you are correct, the reason I use the tablet against say a 5 and 7 inch is it uses the mPCIe bus, like this uses and you can change the cards. so you can put a wifi and blue tooth in instead of the 3G.
however it does have a USB so you can put a dongle onit


----------



## frodus (Apr 12, 2008)

Yeah, it got burried in the thread.....


bjfreeman said:


> on the pc Netbooks usually have wifi as standard. some have blue tooth. mine does not have bluebooth so I used dongle and loaded the driver into the linux Kernel.
> I had to get the linux driver code for my devices in the netbook.


----------



## mizlplix (May 1, 2011)

OK, good stuff, but I,m barely hanging on by my teeth. You guys rock.

Life would be simpler if I knew what language my Curtis spoke {CAN Bus wise}.

I guess only trial and error will tell.

Miz


----------



## frodus (Apr 12, 2008)

Oh, yeah, forgot to mention that little detail..... [evil grin]

I've got the full canbus spec and list of PID's for the Curtis 1238's in OS12 of the controller firmware. 

Would that make it easier?


----------



## bjfreeman (Dec 7, 2011)

mizlplix said:


> Life would be simpler if I knew what language my Curtis spoke {CAN Bus wise}.
> 
> I guess only trial and error will tell.
> 
> Miz


note sure if tyhis is the right one read the manual page 14
http://curtisinstruments.com/?fuseaction=cProducts.dspProductCategory&catID=63


----------



## DaveAK (Jun 28, 2009)

frodus said:


> Oh, yeah, forgot to mention that little detail..... [evil grin]
> 
> I've got the full canbus spec and list of PID's for the Curtis 1238's in OS12 of the controller firmware.
> 
> Would that make it easier?




(Wish I could get the same for my Powerpak. )


----------



## mizlplix (May 1, 2011)

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


----------



## frodus (Apr 12, 2008)

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.


----------



## DaveAK (Jun 28, 2009)

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.


----------



## tomofreno (Mar 3, 2009)

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?


----------



## DaveAK (Jun 28, 2009)

tomofreno said:


> 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.)


----------



## DaveAK (Jun 28, 2009)

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?


----------



## DJBecker (Nov 3, 2010)

DaveAK said:


> 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.


----------



## DaveAK (Jun 28, 2009)

DJBecker said:


> 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.


Well I only mentioned emulating the ELM327 as I thought that's what the Torque software needed, otherwise you're right. You wouldn't need to do the whole ELM327 command set, just what Torque needs. And that I don't know. Having said that you'd want to make your microcontroller work with any CAN messages not just Curtis so that you can connect other makes of controllers, chargers and BMS.

To be honest it might be more prudent to create a Torque like program that could do custom CAN messages as well as OBD2, and which would have more input options than just ELM327 to allow for other CAN devices.

If the developers of Torque are open to updating the software to work with other CAN messages besides OBD2 then that would be helpful. It might already have that capability but I can't tell from the little I've read.


----------



## DaveAK (Jun 28, 2009)

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.


----------



## frodus (Apr 12, 2008)

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.


----------



## DaveAK (Jun 28, 2009)

frodus said:


> 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?


----------



## frodus (Apr 12, 2008)

it's not the curtis, it's my elithion.... i'm still unsure what I'm even doing or if I need to do more in the AT commands on setting up the can stuff.... meeting with my canbus buddy this week.


----------



## DaveAK (Jun 28, 2009)

Sorry, my mistake. I need to pay better attention, you had it right in there.  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.


----------



## DJBecker (Nov 3, 2010)

DaveAK said:


> 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.


That's what I was suggesting. There is little point in emulating the ELM327. You can just buy one and skip writing that code. Save the effort for the unique part -- gathering controller output info and using that to respond to OBD2 requests.


----------



## frodus (Apr 12, 2008)

Thats kinda where I'm going, dave check your email. Something that basically just acts like an ECU and responds to PID requests from Torque (or Rev if you go wifi).

Something with more flexibility though, just canbus isn't enough for me.


----------



## DaveAK (Jun 28, 2009)

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.


----------



## DaveAK (Jun 28, 2009)

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.


----------



## frodus (Apr 12, 2008)

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?


----------



## DaveAK (Jun 28, 2009)

frodus said:


> 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?


Just what I need, another forum to waste all my time on.  But I'm definitely curious as to what help they'd be in opening it up a little, or advice they may give on making our stuff OBD2.


----------



## Gangsta (Mar 7, 2012)

Hi guys, have you done any more with this?? I have a fair bit of experience with CAN and OBD2 and may be able to help out a bit.


----------



## mizlplix (May 1, 2011)

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


----------



## Gangsta (Mar 7, 2012)

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.


----------



## bjfreeman (Dec 7, 2011)

mizlplix said:


> OK......
> 
> I just re-read this entire thread.
> 
> ...


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.


----------



## bjfreeman (Dec 7, 2011)

for clarification
OBD-II PIDs (On-board diagnostics Parameter IDs) this is the 11 bit format. it is known as J1979 
For canbus, _D_GN(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.


----------



## bjfreeman (Dec 7, 2011)

here are some can bus DGN that can be used. note some wont' be for vehicles.

```
#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##)
```


----------



## bjfreeman (Dec 7, 2011)

I tried to put all the DGN on one post but it would not work.
these are the vehicle DGN's

DGNGenericOBDIINetwork.h
DGNerrorCodes.h
DGNChassisCodes.h
DGNbodyCodes.h


----------



## DJBecker (Nov 3, 2010)

bjfreeman said:


> 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.


----------



## bjfreeman (Dec 7, 2011)

DJBecker said:


> 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.


true, however the thread is about Can Bus, not just OBD.
Give me time to get it all posted, unless you wish to contribute,


----------



## bjfreeman (Dec 7, 2011)

DJBecker said:


> 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.


btw the files are not copy paste. they are H include files.
but since you want pid
here they are
OBD-IIlMode.h
OBD-IIlPID.h


----------



## DJBecker (Nov 3, 2010)

bjfreeman said:


> btw the files are not copy paste. they are H include files.
> but since you want pid
> here they are
> OBD-IIlMode.h
> OBD-IIlPID.h


You should at least give credit to the Wikipedia pages you scraped that from.


----------



## bjfreeman (Dec 7, 2011)

DJBecker said:


> You should at least give credit to the Wikipedia pages you scraped that from.


If you notice I gave credit to information that was copyrighted, and/or licenses in previous posts.
Actually there is no copyright on Wikipedia. It is a free open punishing medium. There is no License required by the over 500 contributors to the subject.
You should read the MIT and Apache License.
Now if I was charging for these, can see a possible challenge, I am not. I am contributing so someone can advance there own development.
How about you contribute, instead of being a wet towel?


----------



## DJBecker (Nov 3, 2010)

bjfreeman said:


> Actually there is no copyright on Wikipedia.


There is definitely copyright on Wikipedia content:
http://en.wikipedia.org/wiki/Wikipedia:Copyrights



bjfreeman said:


> How about you contribute, instead of being a wet towel?


I've contributed to several the Wikipedia pages related to OBD-II, and also published working CAN bus and OBD-II code. Both my extensions to Paul's controller code to report using OBD-II using a MCP2515 CAN controller, and a more complete motor controller firmware system using STM32 microcontrollers are available on Google Code. 

You've mostly argued with people that have actually built things, telling them that they are wrong.


----------



## bjfreeman (Dec 7, 2011)

DJBecker said:


> There is definitely copyright on Wikipedia content:
> http://en.wikipedia.org/wiki/Wikipedia:Copyrights
> .


 *Important note:* The Wikimedia Foundation does not own copyright on Wikipedia article texts and illustrations. *It is therefore pointless to email our contact addresses asking for permission to reproduce articles or images*, even if rules at your company or school or organization mandate that you ask web site operators before copying their content.
The only Wikipedia content you should contact the Wikimedia Foundation about is the trademarked Wikipedia/Wikimedia logos, which are not freely usable without permission.
*Permission to reproduce and modify text on Wikipedia has already been granted to anyone anywhere by* *the authors of individual articles as long as such reproduction and modification complies with licensing terms *(see below and Wikipedia:Mirrors and forks for specific terms). Images may or may not permit reuse and modification; the conditions for reproduction of each image should be individually checked. The only exceptions are those cases in which editors have violated Wikipedia policy by uploading copyrighted material without authorization, or with copyright licensing terms which are incompatible with those Wikipedia authors have applied to the rest of Wikipedia content. While such material is present on Wikipedia (before it is detected and removed), it will be a copyright violation to copy it. For permission to use it, one must contact the owner of the copyright of the text or illustration in question; often, but not always, this will be the original author.
If you wish to reuse content from Wikipedia, first read the Reusers' rights and obligations section. You should then read the *Creative Commons Attribution-ShareAlike 3.0 Unported License and the GNU Free Documentation License.*

as I said, there is not copyright you sould read the content you link.
.


> I've contributed to several the Wikipedia pages related to OBD-II, and also published working CAN bus and OBD-II code. Both my extensions to Paul's controller code to report using OBD-II using a MCP2515 CAN controller, and a more complete motor controller firmware system using STM32 microcontrollers are available on Google Code.
> .


Now that is some links I would consider a contribution
though you use the 2515, it has a Can 2.0 spec .
STM32 code for the OLIMEXINO for 2515 is not usable since it only used 2551 driver.



> You've mostly argued with people that have actually built things, telling them that they are wrong.


an I have built fly-by from the 90's that include more than just a controller that uses ODBII.


----------



## DJBecker (Nov 3, 2010)

bjfreeman said:


> here is a 2515 implementatiion in hardware that will work with any micro that supports miso and interurpts
> 
> Schematic
> Board.
> ...



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.


----------



## bjfreeman (Dec 7, 2011)

DJBecker said:


> 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.
> 
> ...


 the 4n37 is replaced with 6n137 which is a 10mbit.
Using isolation as you suggested does not isolated the canbus when using the buss as supply voltage. it may cause ground loop problems.
the buck converter allows a 30 V max input which a analog will not allow and has a low idle current. This allow for 24 v operation that it is used in.
it handles the surges fine.


----------



## DJBecker (Nov 3, 2010)

bjfreeman said:


> the 4n37 is replaced with 6n137 which is a 10mbit.
> Using isolation as you suggested does not isolated the canbus when using the buss as supply voltage. it may cause ground problems.


The 6n137 has a different number of pins and a different pinout...



bjfreeman said:


> the buck converter allows a 30 V max input which a analog will not allow and has a low idle current. This allow for 24 operation that it is used in.
> it handles the surges fine.


Linear regulators are available with input voltages up to 40V.

The issue with switching converters is the output transient response, not input surges. When the transceiver is the primary load, the current might jump from 2mA to 70mA for a microsecond, or alternate between the two levels. That's a challenging load for a switching feedback loop.


----------



## bjfreeman (Dec 7, 2011)

DJBecker said:


> The 6n137 has a different number of pins and a different pinout...


yes and .......


> Linear regulators are available with input voltages up to 40V.
> 
> The issue with switching converters is the output transient response, not input surges. When the transceiver is the primary load, the current might jump from 2mA to 70mA for a microsecond, or alternate between the two levels. That's a challenging load for a switching feedback loop.


Not going to geT into design about buck converters. been building them for decades to power SCADA, from Solar power.


----------



## DJBecker (Nov 3, 2010)

bjfreeman said:


> yes and .......
> 
> Not going to geT into design about buck converters. been building them for decades to power SCADA, from Solar power.


Really? A few months ago you were in a extended discussion where you were deeply confused about how buck-configuration motor controllers worked.

That buck converter in your schematic was pretty much the datasheet's example circuit, but it probably won't work in this case. The transceiver's load is too light and variable. With a 10 uH inductor the converter will probably just hiccup instead of producing a stable output. You'll get poor regulation and low efficiency.


----------



## bjfreeman (Dec 7, 2011)

DJBecker said:


> Really? A few months ago you were in a extended discussion where you were deeply confused about how buck-configuration motor controllers worked.
> 
> That buck converter in your schematic was pretty much the datasheet's example circuit, but it probably won't work in this case. The transceiver's load is too light and variable. With a 10 uH inductor the converter will probably just hiccup instead of producing a stable output. You'll get poor regulation and low efficiency.


It was you misconception that confused me. I perfectly understand how you arrived at it. It is still not correct to call it a Buck controller, technically. marketing you can call it anything you want

If you say so. But I won't tell the boards that it works on, Don't want them to get a swollen ego.


----------



## bjfreeman (Dec 7, 2011)

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.


----------



## DJBecker (Nov 3, 2010)

bjfreeman said:


> If you say so. But I won't tell the boards that it works on, Don't want them to get a swollen ego.


Those DC converter component values might have worked on other boards, but not in the schematic you suggested. You can't just crib from here and there and expect things to work.


----------



## bjfreeman (Dec 7, 2011)

DJBecker said:


> Those DC converter component values might have worked on other boards, but not in the schematic you suggested. You can't just crib from here and there and expect things to work.


you want to start another thread on this be my guest, this is about CanBus, and the board was a concept, that I use and it works.
So your concerns are unfounded.


----------



## bjfreeman (Dec 7, 2011)

It seems, as far as I an research there is no one PGM model.
here is one:
PGMModel


----------



## bjfreeman (Dec 7, 2011)

here is an app that is used in RV circles.
it has a PC  and bluetooth version for androids.

it allows you to add gauges and alarms, and to define new pID

I use the PC version


----------



## DJBecker (Nov 3, 2010)

bjfreeman said:


> you want to start another thread on this be my guest, this is about CanBus, and the board was a concept, that I use and it works.
> So your concerns are unfounded.


The post was relevant. You posted a schematic and an incompletely routed board layout that *would not work*. There were several problems, some obvious and some subtle. Even here you switch between "a concept" and "it works".

Someone might have been mislead into thinking those were tested designs.

I've used the MCP2515 with multiple processors, writing the complete software systems. I know how difficult it is to debug CAN bus systems when there are problems at multiple layers.


----------



## bjfreeman (Dec 7, 2011)

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.


----------

