Using Mbed for 2-Channel SOC-Meter

[klapauzius]

I just noticed that the FEZ Panda II board also has a CAN bus and it is a bit cheaper than the mbed.
Its a .net device, so can be programmed quite simply with free software (Visual C# 2010 express, which can be installed locally), e.g.
http://www.tinyclr.com/support" onclick="window.open(this.href);return false;.

It also has a SD card slot on board. There also is a touchscreen display for it.
http://www.ghielectronics.com/catalog/product/256/" onclick="window.open(this.href);return false;

 

[garygid]

I just tried the Mbed connected to the LEAF's USB port.
It appeared to work just fine.

I wrote a short .mp3 and a .wav file on its internal 2 MB Flash
Drive and the LEAF recognized the drive and the two music files.
It played the short .mp3 file fine, but could not play the .wav file.

The Mbed is usually available for under $59 and has two CAN ports.
Programming is easy in a C++ type language, largely due
to the many Library routines from Mbed and from its many users.

But, thanks for the suggestion.

 

[garygid]

While Logging test CAN Messages to a USB Flash Drive,
my Mbed firmware now writes the Log messages through
a USB port to a Virtual Comm Port in the PC (in Windows,
and also in Linux and MacOS, I believe).

I am testing sendind 2,000,000 messages, generated one
each 0.8 ms ... which takes about 45 minutes.

This simulates two CAN channels, each averaging 1.6 ms per mesage
(about 600 per second) to test the USB Flash Drive and CAN-Do.

I had to turn off the energy-saving Power-Off of the laptop's
screen, which was happening at about the 20-minute point.

 

[garygid]

Writing to a 4GB Micro SDHC card (in a USB Read/Write adapter), I was able to write about 5000 CAN Messages per second.

I will have to test other SD cards and Flash Drives, but it appears that some will be more suitable than others.

I am adding a startup option to set the Real-Time Clock's Date and Time.

An unsolved "problem" is how to detect the 12v power loss and have enough remaining power/time to close the currently open file.

At this point, it looks like the package will (at least initially) be:
1. the same SOC-Meter box
2. a 2x16 LCD display (maybe OLED)
3. A Power Switch: Auto-On, Off, Always-On
4. two Push-Buttons for User Input
5. a type A USB port for an SC Card or Flash Drive
6. a mini-USB port for:
a. Logging to PC,
b. easy-copy Firmware Updates
c. editing a Preferences file
d. possibly attaching a GPS to log X, Y, Z, etc.
7. an OBD cable, with 2 CAN buses, 2 power, Shield, and Ground connected
8. an Mbed micro-processor board
9. a custom Interconnect board to connect:
a. the OBD cable
b. the Display
c. the buttons and switch
d. the type-A USB port
e. the Mbed board
f. other components:
i) two CAN Transceiver chips
ii) a coin battery for the RTC
iii) the power-in voltage regulator
iv) a shut-down power circuit
v) 12v battery analog Voltage logging
vi) misc. other components

 

[garygid]

So, I hope to support:

1. Logging:
a. ALL CAN Messages from 2 buses (yet to test on car)
b. GPS NMEA Sentence data (for ver 2)
c. 12v Battery data

2. Log the data to:
a. a USB SDHC card (works)
b. a suitable Flash Drive (works)
c. to CAN-Do in a connected PC (works)

3. include Date/Time stamps to 1 milli-second (works)

4. Log both EV and CAR CAN buses simultaneously (needs in-car test)

5. In "Meter" mode (coming soon), display:
a. GIDs, raw and percent of 281
b. Traction Pack Voltage, Current, Power
c. "Real" SOC (of the reduced-capacity Pack)
d. "12v" Battery Voltage
e. Date and Time
f. optional GPS Altitude, Latitude, Longitude
g. additional data as we "discover" them

Notes:
1. For Safety, this LEAF "Black-Box" will normally be wired
to NOT write to the CAN buses.
This way, we have less chance of disrupting the LEAF's normal operation.
However, for those that accept the risk, there is likely to be
another option when we learn more and do sufficient testing.

2. With the Black-Box mode, I expect that it should record all
activity for days, even weeks on larger SDHC cards.

3. Every time the car starts, a new "next-name" file is opened for logging.

4. Although the firmware currently supports 999 files, when the RTC
backup battery is installed, I might name files as YMMDD-nn.alc,
so each day could have at least 99 files.

5. No, I have not yet delt with handling the Drive-Full condition.

 

[garygid]

Monitoring the "12v" battery:

Through one of the Mbed's Analog Inputs, I am thinking that I will try to scale approximately 0v to 20v into the values 0 to 200 in an 8-bit byte.

A resistor divider and two protective diodes might be sufficient. Actually, the protective diodes might already be in the Mbed, and it might also have an "accurate" input (pull down) resistance. If so, then simply ONE resistor might be sufficient!

I will do some investigation... Apparently not THAT simple.

 

[Nekota]

Monitoring the "12v" battery:

Through one of the Mbed's Analog Inputs, I am thinking that I will try to scale approximately 0v to 20v into the values 0 to 200 in an 8-bit byte.

A resistor divider and two protective diodes might be sufficient. Actually, the protective diodes might already be in the Mbed, and it might also have an "accurate" input (pull down) resistance. If so, then simply ONE resistor might be sufficient!

I will do some investigation... Apparently not THAT simple.

You will need some buffering and filtering for reliable measurements according to http://mbed.org/forum/bugs-suggestions/topic/1514/ (Thomas Olson). The mbed analog inputs are 3.3 volts max I believe so a divider will be needed. I would set dividers for 15V full scale reading and 'calibrate it' with a stack of silver oxide '392' batteries.

Also Mischa Megens http://mbed.org/forum/bugs-suggestions/topic/1514/?page=2#comment-7783 suggests a low pass filter and test code to show the ADC follows the DAC and some quantization plots.

What factors lead you to use the mbed over the arduino mega?

 

[garygid]

One might get 16 volts plus noise, so I thought 20v would be better.
It is actually a 12-bit A to D, so there is plenty of resolution.
Apparently a conversion takes about 5 us.

Mbed has 2 CAN controllers built in, and a USB client and a USB Host port.
Ethernet, Serial, I2C, etc.

It is a 32 bit up, running at 96 MHz, instead of an 8-bit up at 16 MHz.

It seemed like it had a lot in a small package, and many users with
at least some good libraries.

 

[kc1950]

I ordered a few months ago a Raspberry Pi en just recieved it.
I want SOC meter on my Leaf and now I am doubting:

• using the Mbed board; advantage: I can cooperate with Gary in the development phase
  using the Pi: advantage it is very fast, operates under Linux, has an GPIO (32 pins), there arre people who have build an CAN interface
  disadvantage: no software available.

Who has experience with this?
Who can give me advice?

 

[garygTx]

Who can give me advice?

I decided to buy the mbed, just so I could work with garygid on it. And it also has a CAN library, though I don't know if he is using it (I assume he is). It was $50.00 at Mouser for single units. And it is VERY easy to program.

 

[Nekota]

...
Who has experience with this?
Who can give me advice?

I have a Raspberry Pi on order as well as the APC but both of those are unlikely to make it into repackaged systems since the processor cannot be easily purchased from broadcom. Even the source and specifications on the Raspberry Py are not 100% open so there are serious deployment issues for a repackaged or modified Raspberry Py. The Mbed is a much more capable Arduino - probably 10x to 20x more capable but likely 10x to 20x less capable than the Raspberry Py so the Arduino is underpowered for the LEAF when logging GPS, 3 or 4 CAN buss, processing the messages and logging everything. Likewise the Raspberry Py has way too much cpu capability for the task at hand but the Mbed seems to be in between the two and has a good resource match. Also, the Mbed has more interface capability than the stock Raspberry Py (RPy) so adding analog data capture and CAN buss interface is needed for the RPy while the Mbed has it already built in. Now maybe the RPy will be helpful to analyze the logged data and build graphical displays of same? The Mbed is the data collector with some processing, the RPy is the data analyzer and graphical engine particularly when you consider what MatPlotLib packages on the RPy will be capable of doing.

For me it looks like the first steps should be getting the Mbed data collection and logging enabled.

 

[kg4bec]

So, I hope to support:
<snip>

Hi Gary,

This sounds perfect. I especially like being able to log to an SD card instead of a laptop. As soon as you have a kit or a parts list together, I would like to buy one. My display needs are not great, really SOC is what I'm primarily interested in, and logging data so I can help analyze it. I can build a kit, so no worries there.

Cheers/73, Bert/KG4BEC

 

[garygid]

The typical 2x16 LCD display will just fit inside the box that I am using
for the SOC-Meter.

Remaining Projects:
1. Locate a suitable bezel for the LCD.

2. We need to make an interconnect board with a 1x16 header for the LCD,
two rows of 20 for the Mbed, spaces for two 8-pin transceiver chips,
perhaps a 2x8 header for the OBD cable, another 2x4 for connecting
a Power switch and two push-buttons, a 1x4 for the USB port, space for
the coin battery for THE Mbed's RTC, and a good 5v regulator.

3. Reliably measure the 12v input with the ADC.

4. Provide for a second or two of 5v power after the 12v dies.

5. Try to use a USB hub to read a USB GPS while writing to the Flash Drive.
Mbed has a library for doing this kind of thing.

6. Identity a good 5v regulator, perhaps the one ChrisH used on one of his boards.

If you want to play Mbed, I can give you several programs to start with.

I will soon start a new Web page for this project, with a contact email.
It will be http://www.wwwsite.com/puzzles/blackbox/" onclick="window.open(this.href);return false;

 

[Nekota]

I am investigating using the Mbed board (100 MHz, 32-bit) as
a controller for the SOC-Meter because it apparently has two
CAN controllers built in, and includes a USB port that can
look like a virtual Comm Port (or a FlashDrive) to the PC.

Adding the LED display or a serial-bit interface LCD should be
easy, but one does need to add two CAN transceiver chips.

The Mbed programming environment is web-based, with the
source code is C-like syntax. There are extensive libraries
available, and loading the program is just a file copy to the
Mbed's USB "FlashDrive".

Those interested in the Mbed, with experience or not, might
wish to participate. The first step is to read some of the
"HandBook at http://www.mbed.org/" onclick="window.open(this.href);return false; about getting started.

Apparently this Mbed is used extensively, especially by
student groups. One Mbed can even be "shared".

The second step is to buy an Mbed board (about $60) to get access
to the on-line programming environment, and try to compile and run
a few of the many samples. The first just flashes one of the LEDs.

Avnet has a special for the 48MHz low power version of this processor (LPC11U24) and a NGX mX baseboard which includes LCD, onboard regulators, DC power supply, extension headers, 2x RS232, VGA, SD/MMC, RJ45, Audio amp with jack, 256k eprom and a bzzzt buzzer.

http://mbed.org/blog/entry/Buy-an-mbed-LPC11U24-and-an-NGX-mX-baseb/" onclick="window.open(this.href);return false;

 

[garygid]

I believe the LPC11U24 does not have the two CAN ports built in.

But, thanks for the information.

 

[Nekota]

I believe the LPC11U24 does not have the two CAN ports built in.

But, thanks for the information.

Yes the low power LPC11U24 is missing the CAN ports and some other stuff so the processor is much more limited than the LPC1768 version. I was keen on the expansion board but after getting it it's more difficult to use than it should be. The board makes use of pins for connections so your breadboard wires have to be sockets or berg wires.