Weber and Coulomb's MX-5

Post by **weber** » Sun, 11 Jul 2010, 17:38

The motor shaft was 80 mm long (38 mm dia). We cut 30 mm off it so is now 50 mm long. This leaves 1 mm clearance between the motor flange and the 2517 taperlock hub of the flywheel we're having made.

We need an 18 mm dia hole, 21 mm long, in the drive end of the shaft, to take a 1.5 mm wall brass bush, as a plain bearing for the 15 mm dia end of the gearbox input shaft. It used to run in a ball bearing set into the flywheel, but we can't afford the extra length. We just have the 20 mm adapter plate between the bell-housing and the motor flange. No packing ring. This is necessary to keep our long 132 frame motor from projecting too far forward and having the aircon/power-steering pulley hitting the sway bar.

We still have lathe work to do on the non-drive end as well. We have to turn that down from its current 27 mm dia to either 25.4 or 25 mm to take an xx10 taperlock (where xx is yet to be decided). Useful taperlock specs here (although we've been ordering them from Blackwoods):
http://www.austechindustrial.com.au/pro ... oductid=37

We thank Ross Pink of Electronic Innovations for the use of his lathe, and Pascal for operating it and teaching us how.

You'll notice the use of a hand drill with the lathe, as the lathe bed wasn't long enough for our rotor and the tail-stock. With care, and an existing center, the spinning of the workpiece keeps the hole axial. Yes, the drill was straightened up after that photo was taken.

So we didn't actually do anything to the shaft yet, that couldn't have been done with the shaft in the motor, with the motor being driven at low speed.

Next stage is to help Pascal set up the larger lathe he bought years ago but hasn't got around to aligning.

Post by **coulomb** » Mon, 12 Jul 2010, 17:56

I came across a badly behaving BMU yesterday. It would oscillate between overvolts with bypass on and no overvolts and no bypass. I'd seen this before, when one of the links had bad tubing creep. This is the worst one I have here, but there are many with much worse creepage:

In that case, the BMU was literally seated on the tubing, not the top of the link, so the only conduction from cell to BMU was through the stainless steel bolt. These conduct poorly, and I noted a 115 mV voltage drop with just the ~1 A bypass current. When I cut the tubing back with a sharp knife, all was well with that cell. The second image (an older photo) shows a worse example.

However, this newest BMU didn't suffer from that problem. It also had about a 115 mV drop due to bypass current. I tightened the bolt a bit and got the voltage drop down a bit. When I tightened it to as much as I dared, it still had a 40 mV drop. That was enough to prevent the bad behaviour (at present, we have a 50 mV threshold from bypass voltage to overvoltage). However, there was clearly something wrong with that BMU or cell, and I wanted to know what it was.

So all 16 bolts came off (this happened to be the one and only string of 8 BMUs that we have made up; all the rest are cut up into smaller strings of 3-5 BMUs). The opto isolator was at a bit of an angle, but inspection revealed that it has at least 6 mm of clearance. Nothing else seemed strange about it, except that it appeared to be one of just two BMUs that had no anti-corrosion paste between the link and the board. But that can't have been it.

Finally, I noticed that the cell in question was slightly misaligned:

The gap actually looked worse in real life than in the photo. That millimetre or two of twist in the cell meant that one BMU was getting less contact pressure. When I released the compression plates and tapped the cell back into place and reassembled the BMUs to the cells, I found just a 2 mV drop. Another slight tightening of the bolt brought it back to 1 mV.

[ Edit: See my next post; Weber considers this to be unlikely to be the cause. ]

I think we may find it easier to assemble the BMUs to the cells before fully tightening the compression plates. And of course, we need to pay more attention to misalignment of cells, since it's been demonstrated how problems can arise. Also, as a final test of BMUs on cells, I should put all the cells in bypass and check the link voltages one by one. The link voltage facility was to find cell to cell links that are high resistance, which will cause problems under high load and high regen. However, with the bypass resistors on, it is also effective at finding high cell-to-BMU resistance.

Edit: conductive paste -> anti-corrosion paste.

Post by **Johny** » Mon, 12 Jul 2010, 18:08

Good work guys. As I work through modifying my headway packs (removing BMS, modifying for opto monitoring, bypassing power FETs) I often pontificate (worry about) the 200+ series connections all of which have to take full battery current.
Your system is good in that you can "see" an indication into the quality of connections via the monitoring system.

Post by **weber** » Mon, 12 Jul 2010, 19:10

Johny, don't forget you can (and should) still do these measurements by hand immediately after assembly. i.e. you can put in some charge current or pull it out with a dummy load, and measure millivolts with a multimeter. You can actually measure things our BMUs can't, to narrow down where the problem is. Turning on bypass to measure cell-to-BMU volt-drop may be a little harder, but there's probably somewhere you can temporarily short to make it happen.

But of course where the remote monitoring will be great is after the cells are buried in and under the vehicle, a particular problem with the MX-5.

What is really awesome about this digital BMS is having a reverse-polish command interpreter that makes adding new commands a piece of cake and being able to change the software in all BMUs at once in a few seconds.

I suggested to Coulomb that we could make our BMS behave like a simple analog BMS and not require a master to send it serial commands or interpret the serial results.

The BMUs all have consecutive ID numbers in the comms chain (thanks to a clever command Coulomb worked out) and so, although all BMUs run the same software and receive the same commands, the first one can figure out it is the first one and do the job of the master in sending commands to all the other BMUs as well as monitoring its own cell. And the last one can figure out it is the last one and do the job of the master in raising the alarm if there is any badness in the chain, as well as monitoring its own cell. It uses its isolated serial output as the alarm output.

It seemed that no sooner had I suggested this than Coulomb had it working. But then that's also because he's an insanely good programmer.

Post by **Johny** » Mon, 12 Jul 2010, 19:24

weber wrote: Johny, don't forget you can (and should) still do these measurements by hand immediately after assembly. i.e. you can put in some charge current or pull it out with a dummy load, and measure millivolts with a multimeter.

Yes, your system just adds that extra bit of confidence. I am measuring all the cell pairs and connection bars to cell tops/bottoms when I disassemble each pack to modify the BMS. So far so good. Lots of cases where the pack end connections to external terminal lugs (M6) have heatshrink over too much of the lug though. Having said that, I haven't seen this cause a problem but it's frightening looking and I'm quite surprised that they get away with it (technically).

Post by **weber** » Mon, 12 Jul 2010, 19:37

The encoder finally arrived.
http://australia.rs-online.com/web/sear ... 78&x=0&y=0

This is how we propose to mount it. Except there will be a taperlock hub on the motor shaft, inside the pulley. You can see that the encoder is smaller in diameter than the shaft (with its blue painted end).

I plan to glue the encoder shaft into the hole in the end of the motor shaft using a rubbery glue or contact cement such as Selley's Kwik Grip, and prevent the body of the encoder from rotating, also in a resilient manner, using its own cable.

Post by **coulomb** » Mon, 12 Jul 2010, 20:29

coulomb wrote: That millimetre or two of twist in the cell meant that one BMU was getting less contact pressure.

Weber pointed out to me in email that this doesn't sound likely. I think that there must have been some gunk on the thread of that bolt, which is now elsewhere (I've checked the other voltage drops; they are fine). Perhaps the act of removing and re-inserting the bolt has moved enough of the gunk to allow the bolt to tighten the BMU to the link.

I forgot to mention that when it was high resistance, pushing on the BMU [edit: against the link] with a screwdriver lessened the resistance dramatically. So provided that the BMUs can twist sufficiently (surely they can), the bolt should have done the same thing.

Post by **weber** » Mon, 12 Jul 2010, 20:52

BTW, anyone who is buying Li cells before they are ready to use them would be well advised to buy some grey goo (zinc-filled anti-corrosion paste) at the same time and immediately smear this on all the terminals and on the exposed surfaces of all the copper links. Alternatively (or in addition) keep the copper links in airtight bags or containers. And keep the cells covered. The mud wasps love the terminal holes.

All things we now wish we had done.

Post by **mcudogs** » Tue, 13 Jul 2010, 00:41

When I first connected up my SE cells I had a lot of problems with bolt and terminal threads, so I re-threaded all the bolts and cells. It then went together well with no HR joints. With the number of cells you guys have that should keep you busy for a while

Post by **coulomb** » Tue, 13 Jul 2010, 05:09

mcudogs wrote: When I first connected up my SE cells I had a lot of problems with bolt and terminal threads, so I re-threaded all the bolts and cells.

Do you mean you used an M6 tap to clean out the cell threads, and a die to clean up the bolt threads?

I assume you don't mean that you re-tapped all the cells to say M8, and used all new M8 bolts.

The former sounds like a good idea, if somewhat laborious.

Post by **mcudogs** » Tue, 13 Jul 2010, 13:47

All of my cells and bolts were M8. Yes I did use a bottom tap and die to clean up the threads. It took about 3 hours and was very tiring.

Post by **Squiggles** » Tue, 13 Jul 2010, 14:20

Tiring for the battery drill you used for the tap I suppose

Post by **mcudogs** » Tue, 13 Jul 2010, 19:08

No, I did it old school. I didn't think about using a battery drill. Every time I go to use mine it's flat.

Post by **Johny** » Tue, 13 Jul 2010, 19:11

Probably just as well. It would be pretty easy to stuff up an aluminium thread using a power drill - less feel than doing it by hand.

Post by **Squiggles** » Tue, 13 Jul 2010, 19:58

Your just a scaredy cat Johny

A battery drill on lowest clutch setting should be fine if you take your time.
I had the same feeling about using a tap in a drill press when I was an apprentice, the tradesmen finally convinced me it is ok. Never broke a tap or thread....might have just been luck though!!

Post by **Johny** » Tue, 13 Jul 2010, 20:13

Meow!

Post by **coulomb** » Wed, 14 Jul 2010, 02:55

We decided to try charging 48 V nominal (16 cells) at a higher charge rate (up to 15 A) and hopefully with a little PWM noise. Probably nothing like a motor controller chopping 200 A, but more than a regulated power supply or high frequency battery charger.

You can see 5 multimeters, two headlights (to correct a horrific unbalance between the two 24 V halves), and a house fan to try to keep the bulbs under 120°C. There is also a printout of a spreadsheet telling us the average cell voltage for a given total string voltage. The roomy box used to hold 100 (or was it 200?) Ah of lead acid.

The power source was one of Weber's three solar arrays. Alas, Weber has a nasty shading problem on that particular array, so from about 1pm onwards the current was down to about 2 A. The battery didn't fully charge, so unfortunately we'll have to continue the experiment another time. We didn't see any problems with the BMUs so far.

Edit: didn't charge -> didn't fully charge

Post by **coulomb** » Thu, 15 Jul 2010, 16:55

The Tritium Drivers Controls device which we will probably use as our BMS master arrived this week. I've finally managed to get the jtag programming working. The free Olimex programmer seemed to work if I lied and told it I had a MSP430F147 device (it's really an MSP430F247 device with 4x the memory and 2x the processor speed). However, I found a text file which the GUI and command line programmer software read from, and added an entry for the '247 chip. It turns out all it wants is the start and end of program memory, and start and end of "data" (info-flash), which is the same for both devices anyway.

So now I can read, erase, write, and verify an Intel hex file to/from the device. Here I have changed the control program slightly to flash the red "fault" LED instead of the green "CAN activity" LED:

The 14-pin to 8-pin adapter in the middle is provided with Driver Controls; the Olimex unit at the right is one that Weber had lying about the house (as you do

. It's quite old, but fortunately the company updates the firmware for free online, so it can program the latest devices. (However, their free stand alone programming software is a little behind the firmware, as noted above, but it seems to deal with the 16 MHz devices no problem).

I'll still have to sort out the msp430-jtag and msp430-gdbproxy problems, so I can use msp430-gdb to debug it with symbols. In the meantime, I can use the free IAR development environment to debug it without symbols. If I could convert the .elf to the TI .d43 format I could use that debugging environment instead.

Compiling the source with msp430-gcc was effortless.

Edit: .hex files don't have symbols, and so can't usefully be converted to .d43 format.

Post by **EV2Go** » Thu, 15 Jul 2010, 19:59

What is the purpose of 4x the memory and still have the same start and end addresses?

"It turns out all it wants is the start and end of program memory, and start and end of "data" (info-flash), which is the same for both devices anyway."

If the program and BIOS have pre defined memory boundries how is it going to use the extra memory unless it is dynamically addressed?

Post by **coulomb** » Thu, 15 Jul 2010, 20:36

EV2Go wrote: What is the purpose of 4x the memory and still have the same start and end addresses?

Sorry, I keep using the word "memory" where I mean "RAM". The '247 has 4x the ram, but the same amount of flash (32 kB + 256 bytes in two separate blocks; the latter is intended for calibration data and/or a bootstrap loader). This programmer software won't write to RAM, only flash; hence the two processors are the same as far as it is concerned.

Post by **EV2Go** » Thu, 15 Jul 2010, 23:26

No I think you used it in the right context, as memory and RAM are pretty much interchangable (from a general description perspective anyway), it only when the memory isn't availble for Random Access (read only) that it stops being RAM. When the code is Read Only and changable by flashing then it's ROM or commonly known as flash memory.

Wouldn't you need some form of memory manager or OS to access the general memory area?
The flash memory in the BIOS already has some hard coded basic code to know what the programmer software is talking about.

Post by **coulomb** » Fri, 16 Jul 2010, 03:07

EV2Go wrote: Wouldn't you need some form of memory manager or OS to access the general memory area?

No, these microcontrollers are very simple. The RAM is at a fixed address, 0x0200 for the small ones like we use, 0x1100 for the larger ones as used in Driver Controls. So what we'd think of as virtual addresses in a PC are the same as physical addresses in these devices.

There are some larger models that address more than 64 kB of memory, but they solve that problem by making the processor registers larger; 32 bits I believe, with about 20 bits brought through for memory address lines. I'm not sure of the details.

The two flash areas are also at fixed addresses. The main flash always "grows downwards" so that it ends at 0xFFFF, since the interrupt vectors are hard coded at there. The info-flash is 1000-10ff, for historical reasons I guess. The first 4 kB (0-0xFFF) is reserved for various registers. They are generous with that space, since there are many models with many different capabilities, and they try to always have the same peripheral appear at the same address, so you have to make minimal changes to code to take advantage of a new model.

Post by **coulomb** » Fri, 16 Jul 2010, 23:43

Here is the current battery layout diagram. Warning: wide (1505 pixel) images. You may need the scrollbar at the bottom of the post (scrolls the whole post, including text).

Hopefully we'll update the model with motor/gearbox/diff/controller some day. We'll no doubt need to tweak things here and there (in the car and in the model to reflect the car better).

Post by **coulomb** » Sun, 18 Jul 2010, 05:39

I have now updated the Driver Controls software to send and receive packets to the charger's CAN box, as well as a few minor changes to how the LEDs work. I can see the charger's packets in the Driver Controls RAM; it looks exactly the same as the RS232 version, as expected, complete with the comms error flag set.

I'm pretty sure I'm sending the right CAN packets to the charger, but it makes no sign that it has received them. I can finally see pulses on pin 6 of the charger connector, but only if I use a pullup resistor to 5V or 12 V. It is the opposite polarity to what you'd expect of RS232: normally high. This lack of signal without a pullup resistor has to indicate a problem, and it's looking like the problem is in the charger.

I'll check soon, but I believe that the reason I never saw anything on pin 6 before is because I wasn't sending packets with the right CAN ids. I assume that the charger CAN box has a CAN controller chip similar to the one used by Driver Controls, which means it will only communicate with its host (here the charger over the serial link) if there is a packet that meets its receiver filter requirements; in other words, it won't talk unless it sees a packet that it is interested in. It seems to be programmed to look for packets like the ones the Elithium BMS sends, which have an ID of 1806E5F4, and indeed this number is written prominently on the CAN box. So I think I've found at least the right ID.

The next job is to try and read the serial data now on pin 6, and see if I can get some clues from that.

Post by **AMPrentice** » Tue, 20 Jul 2010, 16:45

Looking awesome