SOC-LCD-Meter "LeafCAN" with 2x16 Display by lincomatic

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

garygid

Well-known member
Joined
Apr 21, 2010
Messages
12,469
Location
Laguna Hills, Orange Co, CA
I finally got time to assemble the "LeafCAN" LCD SOC-Meter
(circuit designed and firmware programmed by "lincomatic").

Link: http://blog.lincomatic.com/?tag=can-bus" onclick="window.open(this.href);return false;

Chris H. did a board layout for the circuit and had a prototype
board made, and populated it before sending one to me.

So, thanks entirely to the work of these others, this new
2-line LCD version went together and workes flawlessly:

1. A 1st version prototype board from Chris (2nd is coming "soon"?),
2. Which came populated and already loaded with lincomatic's
"soc" firmware for using a 2 row by 16 character LCD display,
3. A white-on-black, 2x16 LCD display from SparkFun,
4. The box used for the SOC-Meter, with a larger slot for the LCD,
5. An "SOC-Meter" OBD cable.

I "assembled" this prototype SOC-LCD-Meter primarily to work better
with lincomatic and Chris, but also for testing an LCD as the display,
experimentation, and demonstrations.

I need to learn to compile and load new firmware for it,
but it seems to work quite well as it is.

I am looking forward to the next generation of this "LeafCAN" board,
and to testing the LCD in different lighting conditions.

When we find more CAN data to display, I hope that we can add
auto-switching between two (or more) CAN busses, some user-input to select display screens, logging via a USB port, etc.

Also, I would like to find a bezel or frame to fit the LCD,
since a simple rectangular hole lets the backlight shine through.

Any Ideas, suggestions, etc.?

No, it is not "in production" yet, but it could be if there is the demand.

Thanks, Sam (lincomatic) :) :)
 
Thanks.
Digikey: Only one 2.5" Bezel without lens in stock, and $2.34 each.
With lens about $2 more. A bit expensive perhaps.
However, a good suggestion, thanks.

------
The White-on-Black LCD works fine, but the character size is a
bit small for my old eyes. Also, the contrast is sometimes not
really enough for easy reading, and the viewing angle is critical.
So, the 4-digit LED characters (0.5" high) are substantially
easier to read at a glance. So, how often, while driving, does
one need to see several variables (and which ones)?

-----
Chris H. should have a "ver 2" SOC-LCD-Meter board by now,
so I am anticipating more features crammed onto the board,
maybe even two CAN transceivers and a USB port.

-----
In what way would you like to participate (or "play")?

What skills do you already have?
(PM me to get my email address.)

Or, would you like to learn?
(plenty of opportunity there)

Have you tried using CAN-Do?
(Get it at http://www.wwwsite.com/puzzles/cando/" onclick="window.open(this.href);return false; )
 
What I would like to see at the same time is % SOC, Gids, power/regen in Kw, and pack voltage.


garygid said:
The White-on-Black LCD works fine, but the character size is a
bit small for my old eyes. Also, the contrast is sometimes not
really enough for easy reading, and the viewing angle is critical.
So, the 4-digit LED characters (0.5" high) are substantially
easier to read at a glance. So, how often, while driving, does
one need to see several variables (and which ones)?
 
TomT,
Well, this 2x16 LCD version of the SOC-Meter might be good for you.

The firmware that mine has shows %GIDs, GIDs, Pack Voltage (Volts),
and Pack Current (Amps). It should be easy to show
Pack Power (kW) instead of Current.

Maybe we can get more info from Chris about his next board,
I will ask.
 
I'm wondering if the 'mega' version of this chip ATmega2560 would be able to handle all 3 of the data streams from the can buss? There are new experimental serial drivers with adjustable buffer sizes which use C++ streams and provide data logging to a microSDHC. I can setup some serial simulations to test the I/O if some details about the data stream rates and data packet size can be provided. I consider a data packet to be the message + data followed by the terminator. The data writing to the microSDHC takes up to 250 milliseconds so buffering the inputs is needed.

Details on new library --> http://arduino.cc/forum/index.php/topic,85207.75.html" onclick="window.open(this.href);return false;
 
The data stream from each CAN bus can be as much as about
one Message per milli-second.

I send a sync byte, two MsgID bytes, and 8 data bytes for
each message, for 11 bytes total, to CAN-Do, which adds
two bytes of time stamp (seconds and milli-seconds) to
each message, and a byte for the channel designation.

This gives 11 minus the sync byte, plus 3 = 13 bytes total to store.
When logging 3 buses at once, there could be 3 messages that
arrive at about the same time. For speed and compactness, I use
binary format, rather some form of text format.

Then, each minute, CAN-Do inserts a Date Time pseudo-message.

I set the Block Size to 64 bytes and Latency Timer to 4 ms when
using the high-speed drivers for the 4-port RS232 to USB adaptor.

So, if one has sufficient buffer, writing to the SD card might require
an average of 500 or so messages per second or about 7k bytes
per second. Not really very fast, but writing only 4 blocks per second
will require a block size of at least 2K and maybe 4K bytes.

Does any of this help?
 
Update from Chris H:

I do not have any more Version 1, boards or components boards.

The Version 2 board is pretty much ready to go for prototype PCB. I added the FTDI USB components to one of the Serial ports. The second would still require a FTDI cable or external board I used the FT232RL chip that is standard in all the sparkfun/adafruit product. I have been thinking about changing it to the new FT230X chip which is a lot smaller and half the price. Maybe that should wait for 2.5 so I can get this thing out the door...
So, there is progress, but it appears that we will have to wait for a while.
 
Hi Gary,
Here is another possible option for the display.
http://www.adafruit.com/products/823
It is an blue OLED 16x2 display with ultra-high contrast and any-angle readability.
They are pin/shape/code compatible with 'standard' HD44780 LCDs.
823_MED.jpg


Greg C.
 
Thanks Gary for the information of 7 Kbytes/sec. I understand that's the processed data stream but these messages that arrive at 1 millisecond rates, how many bytes in those? And the baud rate on the CAN buss -- is it a standard speed like 57,600 using a UART or does the CAN buss require a specific buffer/interface? Your answers have been very helpful and now for something new. Anyone looking at the Rasberry Pi? It is an ARM11 with 256Meg of memory, ethernet and HDMI interface and a couple of USB ports with enough processor power / decoding to play blu ray movies. It's about $35 and runs linux and uses python - check it out. http://www.raspberrypi.org/" onclick="window.open(this.href);return false;
 
I agree, I will have to order and try that OLED display.
(Not LCD, but the pixels are individual LEDs.)

I had not tried it before because of its higher cost.
THANKS.

---------
The LEAF's CAN buses all run at 500,000 bits per second, much
faster than those in an average car.

Each message contains about 10 bytes of real data, and
at least several bytes of overhead and checksum.

Burst message rate seems to be about 1 ms, but an average
of 3 or 4 ms is typical.

Cheers, Gary
 
Gary,
This board was based off my schematic and code, which is hosted at: https://github.com/lincomatic/LeafCAN" onclick="window.open(this.href);return false;
You can get information on how to get Arduino set up to compile my firmware from my blog: http://blog.lincomatic.com/?tag=can-bus

Note that the board has 2 serial ports. The idea is to use the first port to communicate with the board via an FTDI cable for logging and control.
The second port is for hooking up a bluetooth adapter.
There is a row of I/O pins broken out, too for other enhancements.
Since the board supports only 1 CAN transceiver, you can select the active BUS via the jumper block.

I am going to add some code soon to support a pushbutton to toggle the display.

Right now, it stays powered up even when the car is turned off. I am thinking of adding some code to shut off the backlight
after a few minutes of inactivity on the CAN bus.

If anyone makes any useful changes to the firmware, please send them to me, so that I can update the repository on github.

I will get the latest Eagle files from Chris and update that on github, as well.

Let me know if you need any help to get it up and running w/ the firmware compilation.

-Sam
 
Chris and I have been discussing a Ver2 board. Are you in that loop?

I want (I might need to lay out my own board to get this.):

1. two CAN transceivers, with their Rx TTL side switched by the uP, so the 6x2 jumpers are not needed. Then, the uP should be able to monitor both EV and CAR CAN buses, by switching back and forth between the two Rx lines.

2. a well-placed (optional) USB port (via an FTDI chip) so that the requirement for a GOOD RS232-ro-USB adapter goes away. The port needs to stick out so that the port is usable when the board, with the display, is mounted in my box.

3. I still intend to use an On-Off-On Power Switch, for Always-On, Off, and Auto-On operation. However, if the current drain is very low ... maybe not needed.

4. I would prefer the JTAG re-programming interface, for compatibility with the current SOC-Meter.

5. Provision to support the present 4-digit LED display (since it is bright and the characters are much larger).

6. I have ordered an oled 16x2 display, to see how well it works. So, maybe support that display.

7. more? ... I forget.

Also, I am working on a Logging-to-Flash (USB Flash Drive) version, based on the Mbed board (96 MHz 32-bit). I am writing CAN messages to a Log file now, from BOTH its CAN ports (yes, two). I have a tiny USB Reader for a Micro SD/SDHC card, and maybe that will also work. I hope to try it today.

Cheers, Gary
 
Gary,

Chris & I have discussed some minor changes to the board, nothing drastic.

1. I am not versed enough on the deeper workings of the CAN library to know how to switch back and forth between transceivers. I'm not even sure if it's possible to do on the fly, but maybe it's doable? The hardware would be relatively easy to wire up on a perf board for prototyping .. the transceiver comes in DIP packaging, as well.

2. a well-placed (optional) USB port (via an FTDI chip) so that the requirement for a GOOD RS232-ro-USB adapter goes away. The port needs to stick out so that the port is usable when the board, with the display, is mounted in my box.

Definitely doable. Another option would be to use one of Atmel's USB chips, such as what's being used in Arduino UNO. They run native USB CDC, so no FTDI drivers needed.

4. For JTAG, we just need to add the header. ISP has less pins, though, and the programmers are cheap & readily available.

5. I'm not sure how you are interfacing to the LED, but if there are enough I/O breakouts on the board, it should only be a firmware change.

6. If there's an Arduino library for your oled display, it shouldn't be hard to modify the firmware. As for the hardware side.. we need to know how it interfaces to the MCU.

Mbed dual CAN: cool! Where did you find example CAN bus code for it?
 
The http://www.Mbed.org" onclick="window.open(this.href);return false; site has many Libraries, and examples of
how to use many of the functions. I used their CAN library,
created two (each attached to different two pins), set the
frequency of each to 500.000 baud and used their CAN-receive
interrupt mechanism to "attach" two receiver routines, that
time stamp the message and dump it ito a circular buffer of
about 1000 messages.

Their language is basically a C++ and is fairly easy to learn
with siple examples for beginers. The Mbed is apparently
used my many students in many classrooms.
 
I have been using Lincomatic's SOC reader for the past week. As it is it gives me the battery information on 2 lines. For me it does not need any enhancements.

I did not use a circuit board. I used the Olimax development board with the 2551 on a small proto board.

For me, I used a white on blue display that I am not fond of. I just ordered a black on yellowish display that is supposed to lave larger characters. When it arrives from China it should be an improvement.

I am using pin 8 for power instead of pin 16. This allows the unit to come on with the car power button. The 2551 spec says its OK to have it on the buss unpowered.
 
Sounds good.
I also leave the CAN transceiver on the CAN bus unpowered.

I have a power switch to turn the Meter On while charging,
when the switched 12v is not ON.

I also have some other displays, but I have not had time to
try them all yet. The oled display might be brighter.
Character size for old eyes is also a consideration.

Cheers, Gary
 
I made a couple of minor changes today:

1) Display remaining pack KWh, per Phil's GIDs * 80 / 1000 formula
2) slow down the LCD updating to 250ms, so that the numbers are much easier to read when fluctuating rapidly.

Here is the new display:

LeafCAN-1.1.jpg


The top line, from left to right contains Battery Pack Remaining KWh, SOC ("GIDs"), SOC % (GIDs/281*100), and Remaining Fuel Bars.
The bottom line is unchanged, and contains Battery Pack Voltage, Battery Pack Current Draw (Amps).

Download it here: https://github.com/lincomatic/LeafCAN/downloads
I added LeafCAN.hex, so you don't have to compile it yourself anymore.
 
Maybe display V*A=kW on the second line:
"392.2*-10.2=-3.9" when charging, or
"394.1*120.3=48.4" when driving?

80 Watt-Hours per GID might be the energy fed
into the battery, but it is not the usable energy out.
So, I worry that your kWh might be misleading,
especially at the low end.

However, keep up the Great work. :D
 
Back
Top