Using an Arduino Due as a mini-QC controller

[garygid]

In my v23 sketch yesterday, I switched to unsigned long to hold
the micros() result and to calculate the seconds. I also compared
(byte) sec to OldSec and now it keeps running for hours.

Still, I do not know what happens at the roll-over, which is
about once an hour (plus about 5 minutes).

I plan to have a timer-counter that counts milliseconds, and
reset that count to zero when I get a start-a-second-interrupt from the RTC,
then I would have at least coordinated h:m:s:ms to use for time-stamps,
and for the once a minute Date-Time pseudo messages.

However, real interrupts are still a mystery to me.

The control process will operate at least 10 times a second, but
probably more like 100 or even 1000 per second to try to achieve
better output regulation. This process will read inputs, see if the
CAN-control data has been changed, and take action depending
upon the state of the power supply and charging process.

The CAN input (QC messages from the car) could be handled
by a fast interrupt, or by dedicating 3 CAN "mailboxes" to
holding the latest expected input. However, for logging all
messages, some perhaps unexpected, that might come in,
and time-stamping them for logging, the interrupt method
is probably better.

So, my next step is to get the CAN I/O working well, using
CANRX0 and CANTX0 (Due pins D68 and D69).

I have one proto board with a TI 235 transceiver chip, and jumpers
to configure it almost any way, from no termination (for sniffing)
to providing double termination and bias for the CAN bus.

I will build a second proto board, also with a CAN transceiver, wired
to emulate the car's QC port (as we observe it), where it appears
that the CAN bus lines have only a simple terminator, which is
normally just 120 ohms.

Then, one Due will simulate the QC device, and the other will simulate
some of the QC aspects of the car. To do it right, there should also be
some additional connections for handshaking, but I will add those later.

 

[garygid]

If you have some sketches with these things working
(on the Due), please share them so that I do not have to
re-invent these wheels:

1. A working in-Due "hardware" counter-timer interrupt...
2. CAN input by interrupt...
3. CAN output...
4. figure out why the output to the display halts the timer...
5. synchronize a ms timer-counter with the RTC...
6. more later...

 

[garygid]

My Names for the Jolomo pins (not official):
(looking at the end of the plug)

         GP
      QR    x    
   x     EC    x   
 PP    x     x     PM
   x     GD    x
      CH    CL
         BR

(my guesses/interpretations, assuming that I got it correct, YMMV)
Use at your own risk.

GP = Ground, Protective
QR = QC Ready, QC applies 12v
EC = Enable Charger (permission to charge), car pulls to ground.
PP = Power, DC Plus, isolated
PM = Power, DC Minus, isolated
GD = Ground, Disable car motion, Plug Proximity
CH = CAN-High
CL = CAN-Low
BR = Enable Battery Relay closure, to begin charging, Ground from QC

This is patterned after the info in these documents:
The interface: http://chademo.com/05_interface.html" onclick="window.open(this.href);return false;
The protocol: http://chademo.com/05_protocol.html" onclick="window.open(this.href);return false;

Apparently this is the sequence of opperation (guesses) :

GP and GD are grounded when the plug is inserted.
CH and CL are biased but not yet being used.
PP and PM are unpowered, but will carry the charging voltage & current.

That leaves just 3 control lines (again my assumptions):

QR: the QC applies 12v if/when it is ready/available to do charging.
... (The car responds by starting CAN communication, sending car requirements.)
... (QC responds with charger capabilities.)

EC: the car pulls this line to ground to enable charging prestart testing.
... After successful pre-charging tests...

BR, the QC connects this line to ground to participate in closing the Battery Relay.
... The car closes the Battery Relay to "expose" the car's battery pack HV leads.
... (The car requests current, in amps.)
... (The QC "follows" the requests, and reports its status.)

If there are errors here, please let me know.

 

[garygid]

My unofficial first pass at States-of-Charging for our mini-QC.
These are guesses and assumptions based mostly on the open
literature above, and possibly (some log observations).

0. QC sleeping, usually no QC connection.
1. QC waking up, and pre-charging internal DC pool.
2. QC awake, ready for user interaction, requesting plug-in
3. QC plugged in, apparently, waiting for Start from User
4. QC starting a charging session, applies 12v, waits for CAN from car.
5. QC gets CAN messages from car, analyzes, and responds on CAN
6. QC waits for car to ground EC to do Voltage Display
7. QC ramping output voltage up, no load yet
8. QC holding high voltage, and doing HV leakage tests
9. QC ramping output voltage down (to essentially zero)
10. QC waits for car's test results
11. QC grounds BR to participate in closing the Battery Relay
12. QC waits for??
13. QC prepared for current requests
14. QC gets requests for charging current and ramps up
15. QC stabilizes current after ramp-up
16. QC follows current requests, waiting for zero request or Stop
17. QC processing Stop from the User
18. QC achieving zero-current condition
19. QC opening Battery Relay
20. QC achieving essentially zero-voltage condition
21. QC unlocks plug
22. QC waiting for plug removal
23. QC indicates still-Ready
24. QC entering Sleep after period of no use

30. Error N occured, quickly power down
31. Unground BR to Open the Battery Relay, and remove 12v
32. Power down the QC supply
33. Wait for user to Reset

Of course, behind all of these states, there should be numerous
error states, based upon incorrect sequencing, measured
values, time constraints, internal error conditions, and
possibly error flags sent from the Car.

For now, for essentially any error condition, most likely
we should quickly act as if the user had pushed Stop
or perhaps as if the plug connection was broken.

Note: Use entirely at your own risk.
These might be incomplete, or wrong.

If you have any corrections or suggestions, please
let us know so that I can update this list.

Cheers, Gary

 

[garygid]

My first pass at States-of-Charging for my QC port simulation.
These are guesses and assumptions based mostly on the open
literature above, and possibly (some log observations).

0. Car sleeping, no QC Plug connection.
3. Car senses QC Plug, waiting for 12v from QC
4. Car got 12v, sends CAN messages to QC.
5. Car gets CAN response from QC, analyzes, and grounds EC
6. Car waits for QC to do Voltage Display
7. Car watches ramping up voltage
8. Car watches high voltage, doing HV leakage tests
9. Car watches ramping voltage down (to essentially zero)
10. Car sends HV test results to QC via CAN
11. Car waits for QC to ground BR
12. Car does...?, then closes the Battery Relay
13. Car prepares to send current requests
14. Car requests charging current and monitors current
15. Car requests current ramp-up
16. Car modifies current requests as charging continues
17. Car processing Stop from the QC
18. Car waits for zero-current condition
19. Car opens Battery Relay
20. Car monitors achieving essentially zero-voltage condition
22. Car waits for plug removal, or restart charging
23. Car remains still-Ready
24. Car entering Sleep after period of no use

30. Error N occured, request zero current, sending error flags
31. Open the Battery Relay
32. Unground EC
33. Wait for user to Reset

Of course, behind all of these states, there should be numerous
error states, based upon incorrect sequencing, measured
values, time constraints, internal error conditions, and
possibly error flags sent from the QC.

For now, for essentially any error condition, most likely
we should quickly act as if the plug connection was broken.

Note: Use entirely at your own risk.
These might be incomplete, or wrong.

If you have any corrections or suggestions, please
let us know so that I can update this list.

Cheers, Gary

 

[garygid]

The CAN-Do program can log more than one stream of messges.

I intend that our mini-QC will normally log using the QC-CAN channel.
However, I will include the option to use the Multi-CAN channel,
so that both the mini-QC (or simulator) and the QC-Port simulator
have a logging port to use.

One type of pseudo-message is an "event" (text) message,
and I intend to log all of the state changes as Events,
to better debug operation before plugging into the car.

 

[valerun]

this is awesome thread guys. bummer I haven't seen this before (my miss, most likely). Anyway, the display is on order now. Would you like to have it incorporated into the standard PCB we are building? Is the supply of these displays sufficiently stable?

how can I get the current firmware for tests?

Thanks,
valery

 

[garygid]

Which display did you order?

Did you order the CTE display shield for Due also, or are
you thinking of adding that function to your adapter board?

I figure that using their shield and a Due / Mega proto board
is an efficient way to get started and experiment.

Note what pins the shield uses, including the interior 2x3
connector for the SPI pins.

The CTE32HR, CTE35, CTE40, CTE50, and CTE70 all use only the
same 2x20 connector on the shield, but the displayed image
is rotated 180 degrees on some of the displays, which might
affect mounting. I have all of these.

I will email my latest sketch, which will work with any of
these displays, and the required modified libraries.
Note: it does not yet do any actual CAN communication,
but I am adding the State-logic, which might be more
important.

Several are using the CTE35, although I had intended to use
the CTE32HR (same 480x320 resolution). But others ordered
the 3.5" version, so I modified the UTFT, UTFT_CTE, and UTouch
libraries, and some demo sketches, to work on the CTE35 and
CTE40.

Do you have any sketches for the Due that would be
educational for us to see?

 

[garygid]

In order to get the Charging logic better debugged,
and make the controller capable of simulating CCCV
as well as QC, I am thinking that I will add rudimentary
simulation for the various components:

Simulated Load Models:

1. No Load
2. Resistive Load
3. Lead-Acid battery
4. LEAF-type battery
5. Connection Cable
6. Heating and Cooling aspects
7. BMS function
8. One highest cell

Simulated Charger Operation:

1. Manual Volts with AmpMax Control
2. Manual Amps with VoltMax Control
3. Auto CCCV (Constant Current, then Constant Voltage) Profile
4. QC-type charging session
5. Time Limit

Simulated Charger Components:

1. AC Power Source
2. AC to DC first stage
3. Regulation Stage
4. Temperature aspects
5. Cooling components

Simulated Charger Control:

1. Output Stage PWM Control
2. AC Power On/Off
3. In-rush control
4. etc.

Ideas?

 

[garygid]

Did somebody have a Due script for writing and reading a text and/or
binary file to the SD card on the under-side of the CTE display card?
(Not the one on the CTE display shield for Due board.)

I want to test writing an ".ini" file and reading it, as a substitute
for saving parameters in EEPROM.

Also, is it fast enough to write a binary ".alc" log file to it?

There, the problem is usually not burst speed, but that
there are "pauses" in the writing process that require
a rather large buffer in the uP to avoid losing the log data
during these "pause" periods, which can be almost a second
long, but only occur occasionally.

I want to add the option for local logging to the mini-QC
controller, and save the user-entered parameters in the
INI file.

Thanks.

 

[garygid]

I got a fairly decent Set-RTC graphic screen working today.

 

[klapauzius]

Ordered the W5100 LAN module for the due ( http://www.epictinker.com/IT-W5100ETH-W5100-Ethernet-Network-Module-p/it-w5100eth.htm" onclick="window.open(this.href);return false; )

This should work with the ethernet library, so will be easy to program. Once I have it, I will see if this allow for updates of the RTC using e.g. NIST at startup.

 

[garygid]

There are also some more accurate RTC "buttons"
that were used with the OpenEVSE project.

They might have had some small amount of
EEPROM on them as well.

I will see in the morning how the Due's RTC
does, checking against a GPS clock.

 

[garygid]

My Due's RTC is within about a part of a second of GPS time this morning.

I will try to leave two or three Dues going this evening.

If you have an Android device with GPS (like the Kyocera Event),
the "GPS Test" app seems to be very good.

 

[valerun]

Which display did you order?

Did you order the CTE display shield for Due also, or are
you thinking of adding that function to your adapter board?

I figure that using their shield and a Due / Mega proto board
is an efficient way to get started and experiment.

Note what pins the shield uses, including the interior 2x3
connector for the SPI pins.

The CTE32HR, CTE35, CTE40, CTE50, and CTE70 all use only the
same 2x20 connector on the shield, but the displayed image
is rotated 180 degrees on some of the displays, which might
affect mounting. I have all of these.

I will email my latest sketch, which will work with any of
these displays, and the required modified libraries.
Note: it does not yet do any actual CAN communication,
but I am adding the State-logic, which might be more
important.

Several are using the CTE35, although I had intended to use
the CTE32HR (same 480x320 resolution). But others ordered
the 3.5" version, so I modified the UTFT, UTFT_CTE, and UTouch
libraries, and some demo sketches, to work on the CTE35 and
CTE40.

Do you have any sketches for the Due that would be
educational for us to see?

Thanks Gary! This is very helpful!

I've ordered a few sets of your recommended 3.2" display and a matching Due shield. So this should be fully matching your setup.

I think we will try to not reinvent the wheel and will make sure our board works with the shield.

Will share the charger sketches soon - porting now to the Due.

Valery

 

[garygid]

Glad that I could be helpful to you.

The 3.2 HR and 3.5" CTE35 displays are both 480x320
and both have their 2x20 connector on the Left in
normal landscape usage.

I did not order the CTE32, but got the CTE32HR instead
because of its higher resolution.

The three larger displays (4, 5, and 7") are 800x480
and all three have their 2x20 connector on the Right.

Yesterday I ran (changing only one line of the source)
all 5 display sizes with my current Sketch that includes
a screen for manually setting the RTC Date and Time.
I still need to integrate the RTC into creating once-a-
minute Date-Time log messages.

Cheers, Gary

 

[garygid]

A screen for Manual Mode control of the "charger",
used at this point to control a simulated power supply
with a simulated load. (is now in my v29 sketch)

Simulated Load:
1. None (output not connected)
2. Resistive Load, set load R and cable resistance.
3. Lead-Acid type battery (not yet implemented)
4. LEAF-type battery (NYI)

The Manual Mode screen:
1. Start and Stop buttons, when stopped, the Stop button
might be a Return button.

2. Show and set Max Amps out, and Max Volts out.

3. Radio buttons to select Control-Amps mode, or
a Control-Volts mode.

4. Display the actual output, Volts, Amps, kW, and kWh.

5. Show and set the Requested-Goal (Volts or Amps),
and a ramp rate (V or A/sec) to use to try to get there.

That will be a rather full screen, I suspect.
What else is needed?

 

[garygid]

Power Supply Simulation

Given the current state of the Supply:
1. AC input Voltage and Max Amps (simulsted)

2. First stage crude model properties, initially
just a pool of DC = 1.4 * V-AC, with no current limits.
Also, a %Boost parameter, to achieve about 450 volts.
So, calculate a Vout1 value.

3. Regulator stage, very crude model, just to get
something working: PWM switch (Rp) feeding
an RC filter, operating at 14 kHz, with Duty Cycle
in N=6000 steps, and allowed range from 0 to DcMax,
initially about 5000 for DcMax.
So, initially Rp, Rf and Cf, PWp, PWm, and PWon.
Or, R and C, and DutyCycle fraction, and Vin and Vout.

4. Switched Bleeder Resistor Rbleed, initially auto-controlled
to help ramp down the output voltage.

5. For simplicity, an ideal diode on the output.

Again, this is just to get something "working", to be
better able to get the data Logging integrated properly,
and then demonstrate "real" logs (of simulated
operation).

Suggestions?

 

[garygid]

V29: Added the Manual Mode control Menu,
but did not yet get to simulating the power flow.

 

[klapauzius]

Got my W5100 based ethernet controller (from here http://www.epictinker.com/category-s/1862.htm" onclick="window.open(this.href);return false.

It works out of the box with the ethernet library that is part of the Arduino IDE. Make sure you have the 1.5.4 version, the 1.5.3 was not working for obscure reasons.

Even better, there is under examples in ethernet a UdpNtpClient, which gets the time from an ntp server at NIST.
Only thing i had to change was the server address

from
IPAddress timeServer(192, 43, 244, 18); // time.nist.gov NTP server
to
IPAddress timeServer(216, 228, 192, 69); // nist-time-server.eoni.com NTP server

because the former was not responding.

With that, we can just get the time at start up from NIST, set the RTC. No soldering or extra stuff required.

I wonder if there is meaningful off-the-shelf solution for sharing the SPI bus between the display/SD and the ethernet module ?
If we stack a protoshield e.g. between the display shield and the DUE, that would ideally route the ICSP connectors out to some pins on which the ethernet module could connect.