TESTING...TESTING...1...2...3....Why We Overestimate Our Knowledge

Part of the disjuncture in almost everything has to do with a paradox described formally in a paper that examined test subjects taking an examination on technical material and then estimating their performance. Amazingly, those with the LOWEST scores on the material always rated their performance on the test HIGHEST of the group. The "experts" on the material that virtually aced the examination rated their probably scores MUCH lower.

I call this "don't know and don't know they don't know." Generally, we over estimate our knowledge on any particular topic, and grossly so on topics we know little about. I fancy myself a medical expert, which is very odd in that I see a doctor about once every five years.

Actually, I know a lot about a lot of different things. Which is little comfort, as it makes me generally uncertain about my knowledge of anything. This is a world where everyone is SURE they have the answer. Confidence tends to trump uncertainty.

Worse than uncertain, in any problem I can usually find a pretty handsome solution. Alas, I am further plagued with a ready realization of all the other problems solutions tend to generate. So if you want to solve the national debt, I can probably work that out for you. But there are 75 corollaries that result, and I'm not sure you're going to be real happy about some of them.

My refuge is to test. The nice thing about electrical work is you can usually put a meter on it. You can set up some sort of test with usually a pretty definitive result one way or another. Apparently this is not universally admired.

Viewers of EVTV will no doubt be familiar with our achilles heel. No, it isnt' batteries, though occasionally. It is audio. The irony of video is that it is mostly about audio, and audio is where we fall down most often. Mics whose battery goes out during one of our longish boring recordings. Audio connections that are a little tenuous. Wind noise. Rattles. Lapses and gaps. About the only audio we actually get right is our opening song, and many of our viewers really want us to do something a little more hip and catchy there.

But we do a lot of audio checks and "testing, testing... 123."

The past three weeks, I've been suffering a huge confidence deficit. I have just NOT been able to get the Autoblock AMP device to drive our tachometer and gas gage, and similarly the HPEVS Curtis controller to present RPM to the tachometer. And so with a car essentially done, we've been struggling with pretty basic instrumentation issues.

The nature of these issues is actually not precisely rocket science. A tachometer basically integrates a series of pulses into an average current deflecting a needle. A gas gage basically heats a bimetallic to position a needle according to a variable resistance from the tank sender. So I feel kind of up to the task of dealing with these things. But I was failing miserably.

Ever in the background of course, is the death of my father, two uncles and an aunt all from a particularly clear cut and unequivocal gruesome death from ALzheimers disease. They still debate whether or not this stuff is genetic. Everyone but in the Rickard family. Half of us believe it IS genetic and the other half can't actually remember but would be pleased to describe what happened 42 years ago on a Tuesday if you want to talk about that.

So it might be that I'm just slipping a little bit. A little bit at a time. Something I would not have precisely invented.

How else can we explain my inability to perform very rudimentary electrical connections and instrumentation tasks.

Well actually there IS another possibility. How about product developers who don't precisely TEST anything before shipping.

In fairness, there were some assumptions going on here - largely driven by pretty web pages and of course I'm accustomed to unobtainium beautifully described. But in the case of REchargeCar, I think I may have overreached. I wanted them to be done with the development of both Autoblock AMP and Macchina. And they wanted to be done as well. And I wanted it. ANd they of course wanted me to have it. And we were all in violent agreement.....

In truth, I WAS the test pigeon. And probably not a very good one.

So it worked about well enough to make me WANT it to work REALLY BADLY. And so it did work, REALLY BADLY. I've apparently blown up three of them. I'm not sure how. And the fourth, on Speedster Nippon, would calibrate badly when hooked up to a laptop or on a bench, but in the car, the gas gage would never go down. As it turns out, the pullup resistor in the reset line was a might too high, and so any noise on the line would reset it. So it WAS going down, it just got reset to full every few minutes - with the car sitting still.

No idea what the HPEVS problem was, but the Recharge guys brought a nifty little oscilloscope and we checked the output of the controller - 1v square wave at 9.6kHz. It doesn't vary with RPM at all. So it's not the opto-isolator, the wiring, or anything to do with the tachometer. Whatever they did at HPEVS doesn't precisely make a tach output on pin 2 as advertised. Software, hardware, who knows? They kind of lost interest in my problem so I have too. We use an Automation Direct inductive pickup on the flywheel - tested and proven and available in our online store. We have rpm now.

And so it goes. We had a very enjoyable visit with ALL the REchargeCar guys along with Nathan KNappenburg of Team Illuminati, the Progressive Insurance X-Prize entry SEVEN. Seven, as it turns out, is having its handmade foam board/fiberglass outline replaced with carbon fiber for a spring tour they plan in conjunction with the release of a book on the X-Prize competition largely featuring them. They would like to fast charge in Cape Girardeau if we can get the PulsaR in operation by then.

So it broke into a little mini-EVCCON in the shop this week with pizza, beer, and lots of tinkering and measuring and testing and theorizing. I actually haven't had that much fun in months. We've been dealing mostly with misplaced or mispacked orders for EV components and badly in calendar arrears projects for Speedster Nippon and Aptima Motors eCobras instead. My Escalade is unfinished. My wife's Ford Edge sits forlorn. It's actually operational but has a half of a battery pack not even connected and a couple of other minor "features" that need a little attention. The Mini Cooper has eaten a DC-DC converter (recurring theme here at EVTV). And the entire concept that electric vehicles do not require maintenance appears to be a fantasy of Chelsea Sexton and Plug-In America gone sickly comical. Point me toward ONE that works.

In reality we just have a few too many projects on the table. All of them are kind of known and easily doable, but we are living day to day on what fire burns hottest. I have a LOT of people now with very shiny new Siemens motors and billet aluminum DMOC645 inverters and even deluxe eGearDrives from Borg Warner. Of course, none of them actually WORK yet. And so some focus on CAN bus.

The good news is that CAN is just not that hard. Like most onions you peel, what you find under all the layers is just mostly more onion. CAN is a message based protocol. You make messages and throw them up in the air. You receive messages, and usually find out about three things expressed in eight bytes. Compared even to RS-232 serial communications of the 1980's, it's really quite simple. The "ID" has little to do with addressing. It just identifies what the message purports to be. And the data is it being it. All the rest is handled by the transceiver chip. And you don't really do anything about that.

Macchina is RechargeCar's attempt at making an Arduino do CAN for a car. They've rather ambitiously included ALL five of the OBDII protocols on the device in hardware, but we only have a C++ library for CAN. They have protected the inputs to the chip, which is a big deal for Arduinos actually. The Arduino boards are very inexpensive, which is good because you will blow one up by breathing on it. The inputs to the ATMEL are entirely bare and any spike kills the microprocessor, which is most of what is on the board. The REchargeCar guys have put a zener diode on each of them anyway. And while they were here I talked with Aaron Shephard, their EE designer about BAT schottkey diodes and some other techniques I think are a bit better yet. He not only agrees, but has some special tristate device he thinks would improve on THAT and so Macchina 2.0 is at least conceptual.

They also added a very nicely beefed up power supply system that can take a much wider range of DC input - essentially the automotive 12v range, and convert it to up to 3 AMPS of 5v power. Arduino is more like 500 mA. I actually struggled with a LEM HASS hall effect current sensor only to find I was loading the Arduino Mega power supply down to about 4.85v which was throwing off my ADC readings considerably. So 3 amps of 5V is non-trivial actually.

Enter Nathan and Jack. We're kind of collaborating on a C++ program using Macchina to control a TCCH charger. This week, we got it off the ground and in flight.

The TCCH charger is kind of an enigma. Bang for buck, this has emerged as THE charger selection for the EV community - almost entirely on price. For $1300 or thereabouts you can get a 4 kW charger that will do the typical 156volt charge at about 29 amperes. I know the math doesn't work out correctly. This is the typical Chinese modesty. The 4 kW charger routinely puts out 4.5 kW. But they CALL it a 4kW charger. This will charge a 180Ah battery pack in about six hours if you run it down to nothing. That's pretty cool. Other solutions in this power range are both hard to find and then tend to be north of $3000.

The other thing we like about the charger is it is VERY good at hitting a voltage, and then holding it in CV mode, and then terminating. These chargers, unless assisted by a high quality BMS< just pretty much refuse to burn a car or a house to the ground.

It does have a couple of downsides. First, it is semi-enormous. It weighs about 30 lbs and is roughly the size of a flattish toaster oven. But the big draw back is you have to pick a charge curve when you buy it, and then you have to live with it. It is NOT configurable by the end user. In the lead acid version, it advertises 10 "profiles" you can select. But they have gotten to be very reluctant to do that for Lithium cells. You usually get one. Some are able to wheedles a few to select from at fixed voltages. But basically you cannot configure it and to have it changed you either have to return it to China, or to a guy out in Sacramento that rather rudely insists you need to buy a BMS from him and that whatever curve you DO want is the wrong one anyway. Then he generally holds your charger for about two months until he gets around to it.

The TCCH charger does have an option. You can get them with CAN bus control for another $75. This is their attempt at BMS compatibility. Here is the CAN bus specification for the TCCH CHARGER.

Basically, the TCCH charger puts out a single CAN bus message. Bytes 1 and 2 show the current battery pack voltage. 156.5 volts would have 15 in the first byte and 65 in the second. How's that for encoding? Bytes 3 and 4 have the charge current in two bytes the same way. 21.5 amps would then be 0 in the first byte and 215 in the second. The 5th byte is a status byte with each bit representing a different fault, battery dead, battery polarity wrong, AC input out of range, communications failure, etc.

It starts sending this message automatically on startup. If it does not RECEIVE a control message within five seconds, it shuts down, terminates any charge activity, and refuses to do anything further until the input power is cycled. This is my favorite feature. In fact AT ANY TIME during charge, if it does not receive a valid control message from the controller for five seconds - it terminates. So if your Macchina or BMS or whatever gets lost in space from a lightning strike, the charger doesn't. It terminates charge.

It expects several messages from the controller. BUt only one of them is actually of any importance. It contains the voltage and charge current. The voltage is your target voltage you want to charge to. The charger will charge to that voltage, and then hold it by decreasing the current, to whatever level it has to, to maintain that voltage. During the constant current phase when the voltage is lower, it will use the current level in the message. If it can. If you enter a current HIGHER than it can produce, it just produces all it can until the target voltage is reached.

So the same four bytes with voltage and current in the same format. Byte 5 is a control byte and if you set this to 1, it terminates the charge. We do the comparison to the terminate current actually in the Macchina code.

But quite usefully, you CAN set a current less than maximum and it will charge at that. So for example, if you are on a 15 amp AC circuit that keeps blowing the circuit breaker, you could set the current to a lesser DC output level and reduce the AC draw in this way.

The charger operates from 85 to 248 VAC. So it does not seem to care whether you have 120v or 240v AC input. Lower output on 120vac obviously.

And this week we got our program and Macchina working with the charger.

The trick on the Maccina is a C++ class called MCP2515. In Arduino speak, this class is a "library". And it provides access to all the functions of the onboard MicroChip MCP2515 controller/MCP2550 transceiver that actually does the hard work of CAN communications. This link provides access to a lot of data on this chipset and even general CAN information you might find useful.

One of the neat features of the MCP2515 is that it has several buffers for received messages. You can configure this to set a hardware interrupt from the MCP2515 chip to the ATMEL chip on the Macchina board. This is kind of interesting in that it appears the REchargecar guys used a pin for this that shows up as INTERRUPT 6 on the Atmel and in the Arduiono IDE. Interrupt 6 is kind of interesting in that it doesn't precisely EXIST. Actually it DOES exist and IS supported in the Arduino IDE code, but it isn't documented as one of the Arduino MEGA interrupts. So you can be pretty certain this interrupt is not going to be used by other shields and so forth.

The interrupt will go low whenever a message has been received and placed in the buffer.

And os in this way, you use a statement like "attachInterrupt(6, interrupt service(), FALLING);" to connect this external hardware interrupt to a routine in your program to process incoming messages. How cool is that? Well, pretty cool actually. So your program doesn't have to waste time checking for incoming messages, it can do whatever you want it to full time until the interrupt is received. The microprocessor will THEN stop your program, and go run the routine you provided a pointer to in the statement to process any incoming messages. When it is finished, your program continues right where it left off. So a bit of real time programming without much effort.

BETTER. The MCP2515 has a series of masks and filters you can apply to messages before they ever show up in the buffer. And so if you are on a CANbus with tons of traffic, you never get an interrupt at all until a specific message ID shows up that gets past your masksa and filters.

This reduces the overhead on our little ATMEL by about three orders of magnitude. And so it doesn't need to do ANYTHING with respect to CAN other than send a message once every five seconds. And it can be the same message every time.

There are actually a couple of shields out there with MCP2515 chips on them for Arduino. Also several REALLY BAD classes for MCP2515 and all of them named, conveniently enough, MCP2515. The RechargeCar guys did a pretty good one. And then Collin Kidder, who happens to be working on a DMOC645 as it so happens and did the only Mercedes Benze 190SL conversion we're aware of (gorgeous car) improved it a bit in January to include the filters and masks function. RechargeCar has a pointer to the GITHUB on their website.

So I'm a little giddy about all that. We're ordering in a bunch of these CAN bus version chargers and going to offer the charger and controller for about $1700 which I think will be a fantastic value proposition for a charger, in a world with a great gaping hole under the title of CHARGER for electric vehicles. We await PulsaR (still) and we have filled in with a few bargain priced Brusa's which are going very quickly. So we need a good charger in our line of EV parts.

So we're ready to mail em out! Great! Excellent!

Well not quite. You see, getting it to work once in a row on camera is not precisely making a development project road ready. I'm sorry. Only really GIFTED engineers and scientists can do that. For dumbies like me, we have to slog it out by hooking it up and watching it work about 60 dozen times and trying to figure out little glitches and gotchas that, and I'm just guessing here it is true, but MIGHT spring up along the way.

So another cool project. We're building the MOTHER LODE. The battery bank in steel box on wheels I've always wanted. We have 73 Thundersky 100's in it now, all strapped up. We're adding cabling to it. And probably fusing, contactors, JLD404 meters, etc.

This will serve as part of our new test bench - the electric car conversion with no car - and should position us to test PulsaR when it is ready - charging cars from the MOTHER LODE and the MOTHER LODE from cars quite indiscriminately. WITH a PulsaR it will eventually be a fast charge station. ANd meanwhile it can power our test bench to get the DMOC645 and Siemens motors turning.

As such, it should also qualify as officially the

longest range electric vehicle ever built

In any event, lots of testing of the Macchina. And lots of testing of the TCCH charger. And that's the only way I know how to build something and get it to run more than one time in a row.

Jack Rickard