Using an Arduino Due as a mini-QC controller

[garygid]

Jason,
I am pleased that you got the CTE32 (320x240) working.

I will try and define a CTE32HX that is really a CTE32HR
(480X320) that uses only 320x240 of the CTE32HR's screen.
If I manage to do that, then...
I should be able to see on my CTE32HR essentially
what you are seeing on your CTE32.
Maybe even add a x=80 offset, and y=40 offset
to center the "virtual" 320x240 screen on my display.

By using the IDE Help function, maybe you can discover
more about what fonts are available. Or, perhaps the
"user manual" for the UTFT Library has some info about
available fonts, and the spacing between chracters?

Of course, the part of my Sketch for the Karlsen Demo
displays a couple of different fonts, so maybe there is
info in the code that the demo uses.

Cheers, Gary

 

[garygid]

It seems like there are only two bit-fonts defined with the
UTFT Library and it cautions to add additional fonts using
a font.c file with the sketch.

The small font is tiny, only 8x12, and I use the "big" font
(16x16, which I not so very big) for all
of the non-demo sketch. A medium font for the displays
which have less than 480x320 resolution would be nice.

So far, I have not used the fonts in the CTE font chip,
except as they appear in the CTE demo.

I made a on-screen qwerty keyboard, to enter text
if needed in the user interface.

On the smaller of these screens, maybe even the larger,
using a nice round-tip stylus works a lot better than
trying to use a finger, with these resistive touch overlays.

I have started with writing some simple "simulation" code.
As soon as that works, I will add logging of some of the
most important values, using both a fast custom logging
message, and a couple of the fields in the two QC response
messages (only 10 pairs per second).

Then, I will have something to log and graph with CAN-Do.

 

[garygid]

In my Sketch v41, I got the first (overly simplified)
simulation working, updating the PWM 500 times
a second.

Currently, I crudely simulate either a resistive load,
or no load. I plan to add a simple Lead-Acid type
battery for constant current / constant voltage charging.
Then, I will crudely model the LEAF's Lithium battery.

I am logging a custom 10A message 500 times per
second, with the output voltage (in 10 mv steps). the
output amps (in 10 ma steps), and the PWM Control
used, from 0 to 5000 out of 6000.

Every 1/10 second, I log the 108 and 109 messages
(not yet with proper data) that would normally be
a response to the three QC "request" messages
that would come from the car's charging controller.

In Manual control mode, I can start and stop charging,
use voltage or current control mode, and ramp
the output voltage (or current) up or down, with
limits on both.

More refinements to the modeling tomorrow.

 

[garygid]

I am thinking of capturing four one-byte arrays of history data,
initially the Output voltage/2, the Output current*2, the
Requested voltage/2 or current*2, and the PWM/20.

I will use a 4-byte wide circular buffer to hold the
most recent data, and capture the data when I
write the 108 and 109 CAN messages.

Then, I could provide a graph of these "history" values on
the CTE display TFT screen.

I am thinking of sampling the data 10 times a second, to match
the update "request" rate of the QC CAN communication.
I will try to hold the last 80 seconds (800 points), and update
the graph "screen", if it is being shown, once a second.

This should be a good way to use this nice graphic display.

Comments or suggestions?

 

[garygid]

Does anybody know a way to capture nice screen-shots
in the Due, from the CTE display buffer, and then get the
bitmap data to the PC?

Yes, a camera would work, but a nice screen-capture
would sure be nice.

Cheers, Gary

 

[garygid]

My v42 Sketch is now capturing four bytes of history data, the Output Voltage/2,
the Output Current*2, the Goal (Requested Voltage/2 or Current*2), and the PWM/20.

I use a 4-byte wide circular buffer to hold the most recent data, and I capture
the data 10 times per second, when I generate the 108 and 109 CAN messages.

Then, I graph these "history" values on the CTE TFT display screen.

I byffer the last 78 (or 46) seconds (780 points on the 800x480 display, and
460 on the 480x320 display), and update the graph "screen", if it is being
shown, once a second.

This is a good way to use this nice graphic display.

 

[garygid]

In v43 I plan to try a wipe erase-draw instead of
the filled-rectangle erase that I am using now,
to eliminate the slight flicker in the graph redraw.

Then, I need to improve the simulator.

I will bring this to demo on Saturday at our SoCal
LEAF Gathering in Santa Ana, at the Hometown Buffet
on 17th Street, just 2 blocks East of I-5.

 

[garygid]

Trying my latest version v43 script on several displays,
I find that the CTE 5" display's touch input does
not seem to work as well as the smaller screens.
The Demo Paint program has troubles with it also.

Perhaps it is some problem with the voltages being
too low when it is fed with the USB port?

So, for now, along with JasonA's 5" screen failure,
I am slightly "not encouraging" their use, at least
until we know more.

We might be able to hide some of the erratic input
with software, but the upper right corner is noticably
worse than the other quadrants of the screen.

 

[garygid]

I have added I display type CTE32LR to the UTFT_Gg
library, which is really using the upper right
320x240 section of a CTE32HR (really 480X320)
to simulate the lower resolution CTE32 (320x240)
for testing the script for use with the real CTE32
that JasonA accidently bought.

However, please do not get the lower resolution
CTE32 display, get the same size (3.2") CTE32HR
which has the higher 480X320 resolution.

Most parts of the script seem to work ok,
except for the History Graph which was
intended for the higher-resolution screen.

I use the "small" font with the 320-width
(or less) screens.

I "calculated" a modification of the touch calibration
used for the CTE32HR to use with the CTE32LR,
and it seems to work well enough.

However, the two demos do not yet work
perfectly, but they do show some stuff.
I had to add the new CTE32LR display
to the UTFT_CTE_Gg library, and still need
my versions of the demo scripts themselves
to allow for the lower resolution screen.

 

[garygid]

Yesterday I got the two demos to work well.
I had to modify my versions of the demo scripts themselves
to allow for the lower resolution screen.

I also programmed a half-resolution History Graph
for the lower-resolution screens.

There is still a visual improvement to be made in the
progress bar, but everything in the Script seems to
work on the "CTE32LR". Hopefully JasonA will give
us some feedback on using the CTE32 display.

 

[garygid]

Today I added a screen that sends Val-Commands
out via the Serial3 port (pins 14 and 15) to the
Val-Charger (manually now), and receives responses
from the Charger.

I got it talking to itself, sending a message like
"abc123" and <cr> <lf>, and receiving the same,
ignoring the <cr> and stripping off the <lf> at
the end of the response.

Then I added a screen to simulate the command-
response action of the Val-Charger, recognizing
the command received, suggesting a response,
and manually sending the response.

I have a list of the commands, the responses,
and a short description of the command.
As soon as I can read and copy Valery's list
of commands, I can start adding them.

Perhaps Valery will email the command doc
to me so that I can do a first pass at adding
any missing commands, and commenting
on the command and response structure.

Tomorrow, I hope to automate the send,
receive, respond, receive sequence.

Cheers, Gary

 

[garygid]

I am adding code to my Due Script to test the charger by sending it many commands,
and logging the command and the response. When complete, one should be able to use
this to go through the operations required to start a QC session, and to "charge" into
an open circuit, a dummy load, or an available attached battery.

To test this out, I am coding a companion function to pretend to be a Val-Serial capable
charger, at last to give the expected responses in a timely fashion. I am using
the Serial3 pins, #14 and #15. Presently, I just have a wire jumper between
these two pins. Soon, it will be a pair of wires between two Due boards, and
a Ground wire.

So, let's get the commands defined, at least a sufficient set to exercise the charger.

Commands will expect a change in operation.
Power Up
Stop
Sleep
Request Volts out
Request Amps out

Queries just expect state or values back.
Get Max-Capable Amps and volts
Get present Amps and Volts being output
Get Max-Capable Temerature
Get charger Temperature
Get Charger State (what states?)
Get Charger Status (like HV leakage tests OK, etc.)

Settings expect to change the operating parameters of the charger.
Set Charger Max Voltage
Set charger Max Amps

 

[garygid]

From yesterday's experiment, apparently the LEAF can be
told that the charger can deliver only a maximum of 3 amps,
which would be about 1.2 kW, and it seemed to be happy
enough to continue with the QC process.

Cheers, Gary et all

 

[klapauzius]

To test this out, ...

What kind of cable/connector/hardware would be needed to play with these things...
Currently I only have the DUE and the LEAF...Somehow I envision that I something CHademo-connector like to actually get readings from the car?

 

[garygid]

So far, in using the Due, I use the CTE display and Shield,
and just one wire for a loop-back serial port, Serial3, using
pins 14 and 15, the Tx and Rx.

However, you are asking much more, I think.

 

[garygid]

To do serious QC investigation, one needs to be able
to gather (log) data, from the QC interface pins, the two
High Vltage (HV) pins, and the CAN bus.

Since there are 7 interface pins, and one is Ground,
and two are the CAN bus, one only needs to monitor
3 pins. What about the 7th pin, you ask? It is the
"proximity" pin, and always grounded (should be)
when the plug is inserted into the QC Socket.

So, monitor the two-way CAN conversation, the
states of the 3 "handshake" pins (and perhaps the 4th,
if it might not be properly grounded), and measure the
HV, at least the HV voltage, perhaps the offset from
Ground, and the HV current (with either a shunt or
a Hall-Effect sensor).

If trying to monitor and arbitrary QC vehicle and QC
charger, without access to modify either, one needs
a QC Logging Adapter to insert between the Charger's
Plug and the vehicle's QC Socket.

Perhaps rigid and 6" long, or flexible and somewhat
longer, made out of a plug and and in-line socket.

We can 3D Print a Plug, and have made male pins,
resulting in a Plug suitable for experimentation.
The in-line Socket is not difficult to design, or add
to the Plug design, but we still lack fully suitable
female pins, primarily for the two HV lines.

 

[garygid]

So, Logging without an adapter:

First, we investigated with meters and scopes to
see what we were dealing with. Aided by some
on-line public domain QC interface documents,
which seemed to verify our observations, we
slightly modified a vehicle, "tapping" the signal lines,
and the HV, but did not measure the current,
just for the lack of a good sensor, I suspect.

With that logging in place, we logged data from
a variety of commercial QC devices, as they
charged our single "logging-capable" LEAF.

Unfortunately, that 2011 SL is being offered
for sale, including the QC logging system, if the
new owner wants it.

 

[garygid]

After we gathered enough information, and graphed
the data, we began to think that we understood most
of the major things that were going on, at least during
a "normal" non-error QC charging session.

A log is available on line for those with enough
interest, and the log can be viewed with my
free CAN-Do program, see the link in my signature.

As we began to experiment with a "charger", we found
that we needed to rewrite the control to have tighter
control over the output stage, and include logging
(for testing with vehicles other than the log-capable
LEAF), and to create a command language for changing
control parameters which previously required recding,
compiling, downloading again, and restarting the test.

Unfortunately, that experimental version 1 mini-QC
unit is also finding a new home.

So, to be able to continue evaluation of, and experiments
with the new isolated charger, I need a new logging controller
that will tell the "charger" what to do, and conduct the
communication with the QC-capable car. Toward that end,
I an (somewhat slowly) programming the Arduino Due,
with a color touch display as the user interface.

It will first learn to converse with the charger using
the yet-to-be-invented Val-Serial Commands, Settings,
and Queries, and to interpret the Replies/Responses.

Once the hardware interface (control board) is worked out,
I will start to add the ability to converse with the "QC"
controller in the car, at least sufficient to perform
a simple mini-QC charge session.

It took us many months to get the first (AVR-CAN
based) version working well enough to try a second
car, only to find out that the car's firmware revision
changed the timing requirements for a "successful"
charging session.

Niw, with the latest (still beta) version of LEAF Spy Pro,
we can see if the car generates any DTCs, and even
clear them when needed, usually to re-run a new
variation of some test.

more later...

 

[garygid]

What kind of cable/connector/hardware would be needed
to play with these things... Currently I only have the DUE and
the LEAF...
Somehow I envision that I something CHademo-connector like
to actually get readings from the car?

There are 3 groups of things to access, monitor, or log.
1. The handshake pins (3 or 4)
2. The CAN pins (CH and CL)
3. The two HV Power pins (PP and PM), Mucho Quidado, CAUTION
4. The Ground pin.

Not recommended, but possible...
Access is possible by very carefully making "connections"
to the wires or pins on the back side of the QC connector, or a bit
further down the wiring harness. In any case, please consider
that you would be modifying an expensive "toy".

We MUCH prefer making a Logging Adapter for the
QC Plug-Socket interface, so that neither the vehicle
nor the Charger needs to be modified.

The biggest help would be to locate really compatible
female HV pins for such an adapter, which we could
then 3D print.

We could install and connect the pins, tap the wires
and design a good tap circuit. Then, one could attach
a logging box, which would log both the measurements
and the CAN traffic via a USB virtual Comm Port to a PC,
or even log to an SD card.

We have all these pieces working now, on the Mbed,
Due, and AVR-CAN. However, no one uP's code
includes them all, at the moment. One needs the
low and high voltage interface circuitry, the CAN
"listening" transceiver, the USB / Comm Port, a
suitably high-speed SD card interface, and just
a bit of a user interface.

I have the Very small Mbed with USB logging,
CAN transceivers, a 2x6 LCD display, a couple of
buttons for user interaction, and a SD card on
a host-USB port. It is the most compact, but lacks
the interface circuitry. It was intended to provide
stand-alone logging of two CAN buses, and even
black-box type operation.

We have two versions of AVR-CAN code, one used
in the GID-Meter, which includes a CAN interface
and a Serial logging port that uses a Serial-to-USB-Adapter
cable to get the logging data to the PC. No SD card.

The other version includes a hand-wired interface board
to make the measurements, and is now used as
the controller for our experimental non-isolated
mini-QC device, which we are in the process of
documenting. Of course, we STRONGLY advise
against experimenting with non-isolated charging
of the QC type vehices.

With the Due, which is much larger physically, the
User Interface (UI) has gotten a lot more attention,
using a color TFT touch screen display, which is now
being programmed to speak Val-Serial Commands
to a Val-capable charger, and handle the Responses.
Logging via the Due's Native USB Port seems to work well,
and adding logging to the SD card slot that is on the
display board (or to the one on the display shield board)
is not expected to be too difficult.

If you have a Due, and one of the CTE TFT touch screen
(with font chip) displays that I "support" with my Sketch,
you are welcome to try my current Sketch, which presently
has about 6000 lines of code in approximately 8 files,
and requires at least 3 modified libraries, and several
other libraries that are not included in the Arduino IDE
package. It was working with the IDE "beta" version
1.5.4r2, but I just recently changed to using the just-
released version 1.5.5, where I have not seen any differences.

With the Due, others have wired up CAN transceivers
and other external circuitry, I expect, but I have not
yet tried my just-started prototype sheld, which presently
just contains on Transceiver chip and some resistors.
I intend that it will become the control interface from the
mini-QC charger, and control, if not actually interface to,
the vehicle's QC Port, to actually facilitate the mini-QC
charging process.

Since the input pins of the Due are only capable of
handling 3.3 volts, something like a 5:1 divider is usually
sufficient for the 4 handshake pins, and the CAN pins
would go directly to a suitable 3.3v CAN transceiver chip.

The HV pins might need like a 100:1 ratio, since the PP
pin would typically go at least 205 volts above ground.
However, the HV might not be perfectly balanced,
and the experimental mini-QC candidate might
put out over 600 volts, so a 200:1 ratio is probably wiser.

Keep in mind that the HV-plus is normally above ground,
and the HV-minus is usually below ground, but that is not
always true. In some circumstances, they might both
be positive, or both negative.

Using some sort of opto-isolation between these signals
and the Due is likewise also wise. Quite high value resistors,
perhaps 20 megohms, might be suitable for tapping
into the HV lines without upsetting the vehicle's
HV leakage tests. Also, if you touch anything exposed,
you want the experience to be safe, not "shocking".

More details on the interface circuitry later.
Cherrs, Gary

 

[garygid]

What kind of cable/connector/hardware would be needed to play with these things...
Currently I only have the DUE and the LEAF...
Somehow I envision that I {need} something CHademo-connector like
to actually get readings from the car?

Yes, to actually begin interaction with the car itself, one needs
at least some signal wires, about 1/16 inch (1.5 mm) diameter pins
for the 7 "handshake" connections to the vehicle's QC Socket, and
some suitable interface circuitry to connect them to the Due.

Before you can decide what is "suitable", determining the nature
of each signal is important: signal levels, input or output, or both,
waveform shape, rise and fall time requirements, and eventually
some signal timing and function.

The best way to discover this is to read the open literature describing
the QC interface, and carefully observing an actual charging session.
After the initial observstions, logging the signals is very helpful.

We have had success with the following experimental results, but YMMV.
These are not official descriptions, use entirely at your own risk.

1. two signals apparently need to be grounded, Ground and Proximity.
2. two signals are a 500000 baud CAN bus, using 11-bit MsgIDs.
3. the QC Ready signal, where the QC device applies 12v "power".
4. an "enable-charging" signal, a QC pullup, pulled down by the car.
5. a "request-battery-connection" from the QC, a pull-to-ground.

So, other than the CAN bus and the important information there,
it appears that there are two signals from the QC device, and just
one from the vehicle.

We constructed some suitable interface, initially all analog for
logging these signals, to better characterize their voltage levels.

Once one is satisfied with the nature of the signals, one could
build actual control interface circuitry, and carefully test it.
Then, some testing with a QC-ready vehicle could begin,
without any connections to the HV lines.

Logging the signals and the CAN messages was critical
to develop an understanding, we are guessing, of what was
important in the two-way communications.

We programmed and logged the "mating ritual", up to the point
that the "dance" required HV to be supplied by the QC device.

We made some HV pins (19 mm diameter as I recall), hooked them
to some meaty wire, and prepared to connect them, very carefully,
to a "Charger" kit that we built, tested, logged, and modified to be
able to do the "show me your stuff, big boy" part for the mating
ritual. That appears to be a ramp up of the output voltage, hold briefly,
and more quickly ramp back down, apparently into little (essentially
no) load. Apparently the car watches this "display of capability", and
can choose to allow charging or not.

We arranged to get a first-generation Jolomo 3D-printed plug,
which held the 9 pins (2 big, and 7 small) more safely, and
eliminated manual hook-up errors. A suitable plug is strongly
recommended. Ours was not weather-proof, so for CAREFUL
use, indoors only.