DIY Electric Car Forums banner
1 - 18 of 18 Posts

·
Registered
Joined
·
18 Posts
Discussion Starter · #1 ·
I have a Curtis 1238-7501 controller with their small model 840 one-line display (for my 9" AC-50 motor). I'm getting the parts now to wire-up an RS232 cable (as seen on other threads). Before I sink hours into this, has anyone documented the protocol over this link to be able to get and set parameters (like their PC software and handheld programmer does)?

Thanks, Tom.




Particulars:

Donor: 1981 Jeep CJ5, manual SR-4 transmission, stock (light duty) transfer case, manual brakes, manual steering
GM small-block adapter plate from Candian EV to stock bell housing
Presently removed front drive-shaft

34 200Ah Thundersky batteries
EV Display fuel gauge
MiniBMS (distributed) BMS
Curtis 1238-7501 controller
AC50 9" Ac motor
2/00 wiring
 

·
Registered
Joined
·
4,064 Posts

·
Registered
Joined
·
18 Posts
Discussion Starter · #3 ·
I plan to use their software for intial tests and tuning.

Ultimately, I'd like to make a more elaborate dashboard as I can't read that little display (not to mention mine has a 6 o'clock viewing angle which doesn't work for a Jeep dashboard). I've used some larger color displays in some other things that would work great.

Tom.
 

·
Registered
Joined
·
4,064 Posts
If you want a display, use the canbus. It has readily available all of the parameters inside the controller. The RS232 has to be programmed to output what you want, which is done by HPGC or Curtis. Its running a program inside called VCL and from what I've seen, it outputs one variable at a time and toggles every time you hit the key on the front. It just spits out serial ascii values. Unless you have the Operating system and a VCL program, you're going to have a big problem trying to change much of anything as far as output goes.

Me and a friend are going to use an Android device. We had iphone working with serial, but it was too limited. We decided to open it all up and go canbus with an OBDII reader that passes all canbus messages. We're going to support curtis and elithion first.
 

·
Registered
Joined
·
18 Posts
Discussion Starter · #5 ·
I assumed that because the Curtis software connects to the same connector as the model 840 display, that they supported some type of protocol there (over RS232). You are right, if the VCL is just spitting-out characters to the display, then this is pretty useless. I have no intention of programming in VCL.

I have not done any CAN bus interfacing. I see that you can buy CAN to USB interfaces and that there are USB ODBII readers (that look to be about the same hardware) available on EBAY for low $$$. I would need some type of driver/API to be able to read and write characters to the CAN bus which may not be available from the ODBII readers (...although, I saw that one used the FTDI serial to USB chips for which I may be able to download FTDI's driver and api--I've used these in the past).

How are you guys getting your commands to and from the ODBII interface? Which ODBII interface are you using?

Thanks for your knowledge and experience. Tom.
 

·
Registered
Joined
·
4,064 Posts
that "some type of protocol" is proprietary and you'd have to reverse engineer it. For configuration and setup, the handheld programmer or the curtis software/serial dongle is the best way to do it. Even if you had the intention of programming VCL, you can't. Its for developers only and you'd need access to the OS which curtis only gives to certain OEM's.

The OBDII reader I have was found on dealextreme and sets up as a bluetooth serial port. On one end it speaks along a canbus connection, on the other, it spits out serial data. Android 2.0 and later has support for serial bluetooth already, so its pretty simple.

They use the ELM327 chipset:
http://www.elmelectronics.com/obdic.html

converts canbus (and OBDII) to rs232. You might have to set it up to send all canbus, instead of just OBDII messages.

We got this one:
http://www.dealextreme.com/details.dx/sku.16921
 

·
Registered
Joined
·
18 Posts
Discussion Starter · #7 ·
Very interesting...thanks. Have you ran into any issues with bluetooth and interference from the controller/motor/etc. ??? I was looking at a little PIC controller w/ touch display so a hard-wired connection would be fine.

But thanks very much for pointing me in the direction. I was planning on doing that protocol "reverse engineering" on the COM port using their SW and an RS232 sniffer.

Again, I don't have experience with CAN bus, but I assume it's just the physical layer on an otherwise serial port. Do you have a list of commands over the CAN bus that you send/receive to access the parameters inside the controller or are you figuring these out as you go?

Tom.
 

·
Registered
Joined
·
4,064 Posts
I just got it last week, its only been hooked up to my car (gas).

I'd still go canbus, but it'd be easy to use an ELM327 chip to interface.

Look at the link i sent about the 327 chip. I have no other info, I'm not the programmer, I'm the hardware engineer. Look up the canbus protocol and read up, its got lots of info in there.

RS232 isn't going to net you much unless you can get it reverse engineered properly. Canbus is wide open already and with the 327 chip, you don't have to muck with much, just know what variables on the RS232 port you need to look for, and parse them.
 

·
Registered
Joined
·
1,773 Posts
Its not just a serial cable though, apparently its inverted:
That would be a Nul Modem meaning transmit and recieved are rolled pins 2 and 3.

Hard to believe manufactures are using such an antiquated ground referenced unbalanced signal.
 

·
Registered
Joined
·
4,064 Posts
That would be a Nul Modem meaning transmit and recieved are rolled pins 2 and 3.

Hard to believe manufactures are using such an antiquated ground referenced unbalanced signal.
Actually if you looked at the actual schematic on the link Sent, No.....

Inverted means the signal is inverted. Its not just swapping the RX and TX. They actually get inverted. That means a 1 is a 0 and a 0 is a 1...... Go to the link on buggiesgonewild and look at the circuit.
 

·
Registered
Joined
·
230 Posts
Using CAN bus isn't difficult.

Most of the adapters are based on an ELM (or clone) chip. These are microcontrollers that talk over a serial port and send message packets over the car network.

The ELM chips don't know specifically about OBD. You don't ask them what the engine RPM is, or to clear a trouble code. Instead you (or the application) type in a command line that says "send this numeric message". The chip sends it, waits a bit to gather all of the response messages, and prints those responses out one per line.

The command line protocol looks a lot like the old modem "AT" command set. It's human-readable, and you can type in commands directly.

The bluetooth and USB version of the ELM OBD readers are exactly the same as the serial version. They just use a bluetooth module or USB-serial chip inside to talk to the ELM chip. Yes, they go from a fast link, down to really slow serial, back to a fast bus.

Between this double conversion, the inefficiency of ASCII command line communication and the inherent send-wait nature of the ELM chip, you probably will only get 5-10 values per second from the CAN bus, even though it is capable of about 4000 packets per second. This is almost always good enough, but it is something to keep in mind.

If you do need higher sample rates, it's likely best to start from scratch working with hardware that has a CAN bus controller.
 

·
Registered
Joined
·
230 Posts
BTW, I think Curtis uses CANOpen. This is a simple protocol that sits on top CAN bus. It is usually used with process control and factory automation, and is a bit... clunky.(**)

It is a different protocol than automotive CAN, and partially incompatible -- something to consider if you want to use standard automotive instruments. IMHO, it's a poor choice for an automotive controller. Of course this is really a side market for them.

** Not that anything on CAN is especially elegant. Using an "ID" as a mix of priority, addressing and function was a bad idea that triggered many mediocre work-arounds.
 

·
Registered
Joined
·
230 Posts
but its still "canbus" so the elm327 compatible chip will work, correct?
Oh yes, albeit with a little more work. My point above wasn't clear. The ELM327 mostly just interprets the line typed in, bundles it up into a message, and listens for the results.

It does do a few things specific to OBD. It defaults to the OBD diagnostic address/ID, and uses ISO-TP encapsulation (Note: I had a bit to do with the http://en.wikipedia.org/wiki/ISO_15765-2 page.) But it's only a few commands to set to other CAN IDs and have it exchange generic CAN message without encapsulation, although you might learn more than you had planned in order to get everything exactly right.
 

·
Registered
Joined
·
18 Posts
Discussion Starter · #15 ·
I succeeded in making the cable (just null-modem wiring, no logical inversion) and connecting at 9600 baud. My cable was precarious, so I wasn't able to do much debug yet (I'll crimp everything today).

The RS232 protocol is more complex than just simple ascii commands. At least the protocol that is established to Curtis' PC software. I loaded a COM port sniffer and see that there is quite a bit of binary activity going on. I haven't given up yet. I think the commands might be simpler if only the model 840 display is being used. I'll look at that over the weekend.

I'm wondering if the protocol is actually a CAN bus protocol implemented on the RS232? Just a thought.

It sure would be good to have documentation on this. I could make such a nice display panel with this information. If anyone has cracked any of this already, I'd love to hear about it...Tom.
 

·
Registered
Joined
·
230 Posts
Do you capture timing with the data? That usually helps identify the message boundaries.

If you post the data exchanged someone might recognize the message format.
 

·
Registered
Joined
·
95 Posts
Why? A differential signal won't make it a better controller.
From a signal integrity perspective at low data rates, which is all the controller needs, ground reference has worked for a while :).

Now on a functional perspective serial access is becoming a problem since most computer folks are dropping their south bridge interfaces.

That would be a Nul Modem meaning transmit and recieved are rolled pins 2 and 3.

Hard to believe manufactures are using such an antiquated ground referenced unbalanced signal.
 
1 - 18 of 18 Posts
Top