Page 33 of 68

Weber and Coulomb's MX-5

Posted: Wed, 04 May 2011, 22:56
by Johny
OK - I'll bite too. Are they the same brand and age bulbs?

Weber and Coulomb's MX-5

Posted: Thu, 05 May 2011, 04:42
by Squiggles
My guess different inductance.

edit: I guess it's not a guess really.

Weber and Coulomb's MX-5

Posted: Thu, 05 May 2011, 04:58
by weber
Johny wrote: OK - I'll bite too. Are they the same brand and age bulbs?

They are not. But I'm not sure how important that is. You can see that they share fairly equally after the first second. I would expect that any slight difference in the initial rate of temperature rise will be amplified by the positive feedback caused by the effect that Woody mentioned (resistance increases with temperature).

Unfortunately I don't have two same age and brand to try because they all blew while I was using them in series as a dummy load. Which got me to thinking about why.

But it was a discussion Coulomb pointed out to me, over on EVDL, that caused me to actually do this test with my new Rigol DSO. ... ategory=36

On EVDL, Christmas tree lights were raised as a counterexample to this being any sort of problem. But this really has nothing to do with the MX-5 and I really shouldn't have posted it here. So if you want to discuss it further, better to do it in the EVDL thread.|a3487080

Dunno how I lived without a DSO for so long. Image It's also what let me capture those no-precharge half-voltage inrush current pulses for the DC-DCs (80 A) and the Wavesculptor (1080 A), mentioned in another AEVA thread.

Recent MX-5 progress includes finishing the brake upgrade, So we have 250 mm disks on all wheels now and the system is bled and ready for action. Or rather, ready to stop any action.

I'm afraid we have a severe case of creeping featuritis on the battery monitoring units (BMUs). We're completely redoing the artwork to:
(a) add failsafe bypass, whereby the bypass MOSFET will cease to get sufficient gate drive if the cell voltage falls below about 2.0 V, no matter what a crazy micro might be telling it to do,
(b) add the ability to reset all BMU microprocessors by sending a serial break,
(c) add a blue activity LED instead of confusingly blinking the red error LED to indicate serial comms activity,
(d) reduce the number of 5 W resistors from 3 to 2 and the bypass current from 1 A to 600 mA,
(e) allow for low-cost industrial fiber-optic connectors, to be populated only on the first and last cell in each battery box or ELV segment, to give us completely arc-safe isolated and noise-immune comms in and out of each battery box,
(f) add a piezo buzzer element to each BMU,
and maybe
(g) convert from Protel99SE to the free DesignSpark schematic and PCB software. (Thanks for the pointer Neville)

Apart from the $4 fibre connectors which are only on about one board in 10, these are all sub 30 cent additions involving few parts. (c) has zero cost due to a dual red/blue LED, (d) has negative cost (losing a 5 W resistor). Cost is also being reduced by using the cheapest optocoupler, with lower minimum CTR and just driving it with more current.

We'll also be using the latest MSP430G2452 microcontroller which has 4 times the flash memory of the one we're using now, while costing less.

Sometimes I think the major project here is really our BMS development, and the MX-5 is just a test bed for the BMS. Image

Weber and Coulomb's MX-5

Posted: Thu, 05 May 2011, 16:06
by Tritium_James
I can easily believe different bulbs (even of the same power rating) would have different startup characteristics. One could have more length of thicker wire (a better quality bulb with more vibration tolerance), giving the same resistance, but a completely different startup waveform.

Weber and Coulomb's MX-5

Posted: Thu, 05 May 2011, 23:47
by bga
weber wrote:I'm afraid we have a severe case of creeping featuritis on the battery monitoring units (BMUs)...

What! Never !! Image

Hmm... Opto-connectors that's a good idea. I was going to use sheathed cable on the hot 'send' lead from one cell processor to the next one and just be careful with the plugs/wires on the end.
Must resist... Must resist...Image

I decided to stop short of 64K flash and 16 Mips (that's meainingles instructions per second) in the celltop BMS, although the incremental cost from 8K to 64K is only about 50 cents now.

I have used a PIC18F14K22 which is good for this sort of application and C-compiler friendly, greatly simplifying coding. It's (not) surprising how much the PICs and TI processors have converged in recent times.

I have another PCB package for you: KICad, which also runs on Linux.

Back to the original thought...

Big halogen lamps in series were common in stage lighting. The standard 1000 watt PAR 64* lamp was 110 volts in the 1980s, although 240V versions are now available. These were usually wired with a tricky series Y-lead - don't forget to put that in!
Mostly they worked well with little obvious differences in the light output and didn't blow up very often.
When they did occasionally explode it was often with a loud BANG and glass sprayed over a wide area. (not all the cans had a screen to catch the bigger chunks)

* PAR 64 = 64/8 inches diameter, or 8 inches.

This 1/8 inch measure is also used in fluorescent tubes:
T8 = 1 inch (common big tube) and
T5 = 5/8 inch diameter, small, skinny tube.

++ Just learned this:
   With MR16 (halogen downlight) lamps,
   the 'MR' stands for Multi-faceted Reflector and
   the '16' for 16/8 inch (2 inch!)
   MR16 is also used for the rarer ones with smooth reflectors.
   (I can probably remember what the designation is now)

Weber and Coulomb's MX-5

Posted: Sun, 15 May 2011, 14:10
by coulomb
Back on the 8th of March:
coulomb wrote: The next job is to make a 28-cell box (because the metalwork is done and we have enough BMUs) and actually charge it. We'll have to put the 60-cell pack in series with it. We won't be able to charge it fully, since none of the 60-cell box cells will have BMUs on them.
We've found the 28 BMUs, organised the software in them, mounted them, changed the software again, and updated the software in those 28 BMUs.

The latest change was to run the internal clock at 8 MHz. [ Edit: TI provide official calibration values for 1, 8, 12, and 16 MHz. There is a rather large gap from 1 to 8 MHz! ] We had been running at 4 MHz, using what we thought was undocumented calibration data for 4 MHz, but the G series processors made it clear that the undocumented data was nothing of the sort. It may have even been a checksum of sorts. We didn't want to run the clock at 8 MHz, because the processor would draw more power, and also the chips aren't specified to run at low voltages at 8 MHz. However, we found that while the processor doesn't run reliably at low voltages, the clock does seem to, so we can just run the processor at half the clock speed.

We also noticed that while the voltage readings on the debugger were good and consistent, those from the monitor had much more variability. That is, if you read a cells voltage ten times in a row, the debugger will give values that are above or below by one millivolt, but the monitor would give results that varied buy typically 4 mV, usually in one direction, and occasionally much more. We spent a week trying to find and fix this bug.

The monitor uses interrupt driven communications, while the debugger uses bit-banging (busy wait loop) communications. So interrupts seemed to be the problem. But disabling interrupts during Analogue to Digital (ADC) conversions didn't improve the results at all.

It turns out it wasn't a bug at all, but something to do with our poor PCB layout and the clocks that we select. We found that we could make the debugger readings as bad (noisy) as the monitors by changing the frequency of the Sub Master Clock (SMCLK), which is often used to drive peripherals like the timer, serial port, and so on. Simply adding a single NOP to appropriate parts of the code could affect the result.

So we're going to try to improve the layout of power supply to the processor, possibly separating the analogue and digital power supplies with an inductor. We've changed the frequency of the SMCLK, and now the ADC system operates on a separate internal clock that isn't synchronised to the other clocks. Now the monitor is giving plus or minus one millivolt readings, the same as the debugger. The big question is, how well will all this work with PWM noise on the cell voltages? That's one of the reasons we need to get this 28-cell battery box charged and try running the motor, perhaps the whole car for very short distances, on it.

Rather than charge the 28-cell box in series with the 60-cell box as originally planned, we're just using bench power supplies to do the charging. They are both about 30 V chargers, but the pack is nominally 90 V, and needs about 102 V to provide 3.65 V per cell. One quarter of this is 25.6 V, which the power supplies can provide. One supply can provide 6 A; the other 3 A (but not continuously; it overheats). So we charge one bank of 7 cells (a quarter of this box) at 6 A and use the "alarm" command (sends a bell character on badness) on the last cell of that block. The other bank charges at 0.9 A; this is less than the bypass current of the BMUs we are using (newer ones will only have 0.5 A bypass capability). When not attended, the 6 A is turned back to 0.9 A as well. After one bank starts bypassing, the 6 A charger moves to the next set of 7 cells, and the weak charger finishes them off at 0.9 A. It's a lot of juggling, but it gets the job done. Hopefully we only need to do this occasionally, and will have enough BMUs to use the main charger soon. We can't finalise the printed circuit layout until we're sure that the analogue noise problem is solved, and generally tested the BMUs in as close to a real-life situation as we can get them.

As I type, the battery box is about half charged. So soon we'll install that box in the MX-5 and wire it up to the controller. Our goal of moving the MX-5 under its own power (originally set for 22nd June 2010) might be achievable just 12 short months late Image

Weber and Coulomb's MX-5

Posted: Sun, 15 May 2011, 20:12
by weber
When Coulomb refers to "the debugger" and "the monitor" above, you could be forgiven for thinking we are referring to general purpose tools for the MSP430 microcontroller. In fact Coulomb is referring to two items of application software that we have written (and rewritten and rerewritten), either one of which can be loaded (over the serial comms daisy-chain) into the 2 kB of flash in our BMUs. In these days of multi-hundred-megabyte bloatware, it's amazing to see how many bugs you can fit in 2 kB. Image

The two applications have slightly different but largely overlapping sets of single-character reverse-polish commands. Between them they use the entire lowercase alphabet and then some. The "monitor" is the normal software that is autonomously monitoring temperature, voltage (cell and link), and time since last received comms, and reporting "badness" on a scale of 0 to 7, and turning on the bypass resistors as needed. The "debugger" is what we use to calibrate the voltage and temperature readings in a new BMU, update the bootstrap loader (BSL), and for diagnostic purposes. If you want to know more about the available commands, just ask.

After leaving cells 15-28 on a 0.9 A charge overnight I went downstairs to the workshop in my dressing-gown and slippers this morning and checked on them. Cells 15-21, which had had some 6 A charging yesterday, were all blinking their yellow (bypassing) lights, about 90% on 10% off. The BMUs bypass 1 A at 3.600 V. All good.

I checked a few temperatures. Ambient temperature including non-charging cells was 17°C. The block of bypassing cells was 21°C at middle of side. The bypassing BMUs reported temperatures of 40 to 44°C (at their microcontrollers). The maximum temperature on the tops of the 5W resistors was 85°C (68 K above ambient). All good.

So I moved the 0.9 A charger back to cells 8-14 to get them more evenly (top) balanced. Cell 14 had only been bypassing for a short time yesterday. And I cranked the charger on cells 22-28 up to 6 A. I monitored them for a while and found the highest cell was cell 28 and it was about to go into bypassing. I should have backed them off to 0.9 A before leaving them but instead I only backed them off to 3 A, since from experience yesterday I knew it would be a while before cell 28 would go into bypass again at the reduced current, and a while after that before it was bypassing solidly and starting to rise above 3.600 V. It would raise the alarm at 3.650 V.

Then upstairs I went to fry not-bacon and eggs on toast for the family as I usually do on a Sunday morning, thinking I would be finished in plenty of time to go down to the workshop again and check on the cells. The best laid plans ...


The wife tells me we are out of bread, so no toast. She suggests scrambled-egg breakfast-burritos as we do have tortillas, beans and salsa. I say I don't do breakfast burritos (although I do like to eat them). She says she'll teach me.

At some stage I turn on the gas burner under the frypan. The electric lighter doesn't work. Dodgy switch on the burner knob. There's just gas coming out. I push another knob. Whump. Gas fireball sets the fine outer fibres of my cotton-toweling dressing-gown alight at waist level and the flame-front passes quickly up the front of my dressing-gown to my shoulders. Wife hears strange noise of me patting myself out, turns and says "Your back's on fire!" and pats the rest of me out. That was a bit exciting. A faint smell of charred cotton hangs over the rest of the breakfast preparations.

I eventually go downstairs to tell my 17 year old son that breakfast is ready and think "What's that ding-ding-ding noise? Oh s**t!"

I run into the workshop and turn off the charger. I find cell 28 with its red light on solid, reporting 4.067 V. Its bypass resistors are running at 104°C. After a minute or so the bypass resistors bring its voltage down below 3.650 V and the ding-ding-ding stops. Can't actually hear that from the upstairs kitchen.

I'm sorry I don't have any explosions to report, and the only plasma ball was on my dressing-gown, but still, there you have it. Any designer who passes up an option to design something that's foolproof at a reasonable cost, and instead just relies on people "being careful", is a fool. Humans will always, eventually, take risks to save time or inconvenience. And what can go wrong, will.

[Edit: spelling]

Weber and Coulomb's MX-5

Posted: Sat, 04 Jun 2011, 03:43
by coulomb
Pedal reading puzzle

Where does our time go when trying to finish the MX-5? Sometimes where you least expect it.

We've spent the last two weeks trying to read our pedal position. To cut a very long story short, we've found that the modifications we made to the Tritium Driver Controls Unit (DCU) (basically, so have have two RS485 ports, one for the charger and the other for the BMU string) have caused the processor to read junk from the ADC (Analogue to Digital) registers. The DCU actually makes 7 analogue readings every pass of the main loop (up to 3 pedal readings, three current readings, and a check of the 5 V power supply), and all of them read middle-ish values from about 600 to BFF, most often in the 800-9FF range. None of them has the slightest relationship to the pedal position. We've poked values into registers to make the chip read its internal references, even an input that should read zero. All of them read the same semi-random values. We've connected to pedal reading to a PWM (Pulse Width Modulation) output, and looked at the result on Weber's DSO (Digital Storage Oscilloscope), and you can see that the pulse width jitters randomly, but almost always has the middle-ish values.

We've put our latest software (which has mods for charging, most of them disabled) into a new DCU (we need two eventually, one for each half-pack which will have its own 400 V charger) and it works fine. We've put original, unmodified software into the old hardware, and it gives the bad readings. So it's something to do with the hardware mods we've made. We'll figure it out soon enough now, but it sure burns up the time.

Wild speculations as to what we could have done to upset the ADC system so comprehensively are welcome. Image

[ Edit: I forgot to add that the debugger seemed to be telling us that the conversion result was available the instruction after the start of conversion. However, unlike the timers, the ADC doesn't seem to slow down with the JTAG control of the clock. We wrote software to copy Timer A's time register to memory before and after conversion; it took some 940 ticks of the clock, just as we calculated. (Most of that time is 256 ADC clocks for sampling, which is probably more than needed.)

I also forgot to mention that the results, while basically random, do seem to respond a little when we change from the 2.5 V reference to the 1.5 V reference. So it seems to be doing most of the ADC conversion, just that it isn't reading the actual voltage at its pins. We've checked for correct voltage a the processor pins, shorts to ground, 3.3 V, 5 V, and to 12 V. ]

We have achieved one milestone, however: we've had the wheels turning under pedal control with the first complete battery box (90 V nominal, 93 V resting voltage, 28 cells). Unfortunately, the puzzle of the pesky pedal overshadowed this result, and we weren't even in the mood for putting the car on the ground. (It's still on stands; getting it to move under its own power would have required a longer CAN cable, which we forgot to get made, and a lot of tidying up of wiring.)

Weber and Coulomb's MX-5

Posted: Mon, 13 Jun 2011, 05:24
by weber
The pedal puzzle was solved when Tritium James told us he'd seen it before that an MSP430 microcontroller could have only its ADC damaged, apparently due to excessive voltage on an analog input.

James also reminded us that before we could do more than spin the wheels up on the stands, we needed to get the liquid cooling system for the Wavesculptor installed in the MX-5 and operating. Here's how we did it.

Image Image Image Image Image Image Image Image Image Image Image Image Image Image Image Image Image Image Image Image

Weber and Coulomb's MX-5

Posted: Mon, 13 Jun 2011, 05:59
by weber
BTW, we connected the two 120 mm IP55 fans in series so they would run slowly and quietly on half voltage. We may have to change that when we start using the full power of the WaveSculptor 200.

Our immediate goal was to be able to drive the MX-5 on a set of 28 cells (about 93 volts) in order to test our battery monitoring system before producing the full 228 BMUs (Battery Monitoring Units). So we needed a 12 V supply to power the pump and fans, and the various CAN bus devices including the WaveSculptor.

The MX-5's original 12 V lead-acid battery had died in the two years of inactivity, so I opted for an $89 SuperCheap replacement. What I'd forgotten was that the battery, being in the boot, was very wisely vented not to the boot space, but to the outside world, by having a sealed cover over the filler caps, with flashback-arrestors and plastic tubing connected to outside. Coulomb looked up the price of the "correct" battery -- $236!

We figured that for $147 we could afford to perform a transplant of the cover and the filler-cap-pressure-valves from the old battery to the new. It was harder than we thought because the cover was glued onto the old battery so well, and the new battery was already at the limit of height for the MX-5's hold-down clamp, but we got there eventually.

Image Image Image Image
[Edit: Mention that filler-cap-pressure-valves also transplanted]

Weber and Coulomb's MX-5

Posted: Tue, 21 Jun 2011, 08:04
by weber
Coulomb & Weber's electric MX-5 lives!

I'm sorry it's taken me so long to edit the video and upload it, but at 9 pm on Friday 10-Jun-2011 the MX-5 finally moved under her own (electric) power -- hoorah! -- albeit jury-rigged and with some strange behaviour, as you will see.

It was a long EV day that turned into a cold EV night, but Coulomb, Weber and Newton, fueled by mountains of cake and lashings of hot tea, were determined that this would be the day.

Finally we were ready to test-drive, so we lowered her off the stands.


It took us a while to realise that after clunking back and forth it was essentially deciding at random, whether to go forwards or backwards! We suspected our somewhat dodgy temporary mounting of the rotary encoder and so reinforced it with an anti-rotation arm made from a bamboo food skewer and some masking tape! Then we pored over it with the scope, but could find nothing wrong.

Image Image Image Image

So we called it a day, ... or a night.

Before I went to bed that night I sent off an email to James at Tritium. In the morning a reply was waiting. James said two important things:
1. "The going backwards thing is really odd and I've never seen it before."
2. "Does it do the same thing if you drive it from the software on the PC?"

So out I went and tried the latter. It worked totally smoothly and predictably. Then the penny dropped. We had modified the hardware of Tritium's Driver Controls unit to talk to our BMS, by re-purposing some inputs that were related to gear selection. When our matching software didn't work first go, we replaced it with Tritium's standard software.

Late nights out in the cold with wives threatening divorce* are not very conducive to clear thinking. It turned out that, from the point of view of the standard Tritium software, we had the reverse gear input connected to the CAN bus activity LED output which was naturally blinking on and off! [* Only joking. They were all very supportive.]

So now that's been fixed and it's all smooth and predictable, and we've even managed to implement our quadratic accellerator-pedal regen algorithm as described here:

[Edit: Substituted embedded YouTube for link to page with HTML5 <video> element. Give it a year and this might work reliably in all browsers.]

Weber and Coulomb's MX-5

Posted: Tue, 21 Jun 2011, 15:10
by Johny
A great moment - well done guys!

Weber and Coulomb's MX-5

Posted: Tue, 21 Jun 2011, 16:01
by coulomb
In lieu of a deleted post, an image from the first drive night (didn't make it into the final, edited movie):


Weber and Coulomb's MX-5

Posted: Tue, 21 Jun 2011, 18:37
by evric
Congratulations - Now for a real video of the first real drive...

Weber and Coulomb's MX-5

Posted: Tue, 21 Jun 2011, 18:53
by PlanB
Beanies? Is it really that cold in Brisbane? One degree overnight here in beautiful down town Freemans Reach on Sydney's outskirts.
So fist baby steps! Well done. You guys are gonna love that ride sooo much. I went for a run in a Blade build MX last year down W'gong way, the wind in your hair, the hum of the motor, hog heaven for silverbacks I call it.

Weber and Coulomb's MX-5

Posted: Tue, 21 Jun 2011, 21:59
by Jeff Owen
PlanB wrote: Beanies? Is it really that cold in Brisbane?

Yes, it really was that cold. The maximum temperature during the day was a chilly 20.4 degrees, and the overnight low got down to a very cold 9.5 degrees.

Weber and Coulomb's MX-5

Posted: Tue, 21 Jun 2011, 22:14
by Johny
Brrrr! (from Melbourne, sure....)
Thanks for the youtube video link coulomb, that was better.

Weber and Coulomb's MX-5

Posted: Thu, 23 Jun 2011, 19:55
by woody
Congrats Guys!

Weber and Coulomb's MX-5

Posted: Thu, 23 Jun 2011, 21:23
by VRLAme
Yes well done fellows. I look forward to seeing it driving around Brisbane.

Weber and Coulomb's MX-5

Posted: Sun, 26 Jun 2011, 02:49
by weber
Thanks for all the kind words, guys.

I must do justice to Newton (Jeff Owen) here. In the video, he can be heard to express some trepidation at the prospect of having to grab a certain cat. In case you were thinking he was a bit of a wimp, I must point out that this particular cat is, like the cat "Horse" of the Footrot Flats cartoons, about as cuddly as a sack full of fish-hooks. He is none other than Minxy the vicious Manx guard-cat you may remember being set to guard the battery boxes on the footpath in an earlier post.


Weber and Coulomb's MX-5

Posted: Mon, 27 Jun 2011, 16:04
by bga
With all that movement at the station, even the man from snowy river would be impressed.Image

Well done guys.

Weber and Coulomb's MX-5

Posted: Sun, 10 Jul 2011, 04:45
by coulomb
The recent push to get the MX-5 driving was firstly to achieve a milestone and have some fun. Secondly, it was for testing the battery management system in a real-life environment, so we can have the confidence to get some 250 boards manufactured and loaded with components.

This has been hampered by a communications failure. Every few seconds, a character would be dropped, and this would cause a pause for a timeout, then the communications would continue. It's hard to tell if the battery management system is working under these conditions.

This only seemed to happen with a long string of BMUs; it never seemed to happen on the bench with just 3 or 8 BMUs connected. We had all sorts of theories about what was going on; most of it had to do with slight differences in clock frequencies of the various BMU boards. We thought that eventually one would be sending slightly slower than average, and its receive buffer would eventually overflow. These processors only have 128 bytes of RAM, which has to include the stack, a command buffer, and various variables.

To cut a long story short, it wasn't that at all, and our elaborate system of sometimes sending bytes with 2 stop bits and at other times with one stop bit didn't fix the problem, although after every change, it was tempting to believe that we'd made it better. In the end, increasing the transmit and receive buffers to 8 bytes (7 bytes capacity, so it's easy to tell the difference between empty and full) from 4/3 bytes solved the dropped character problem.

So Weber dutifully headed up and down the test hill, at one stage noting 70 amps of regeneration in first gear. Eventually, he became aware of the red error light staying on continuously on the Driver Controls Unit (DCU). Back at the garage, he found that only the first eight BMUs were still running the monitor program; the other twenty (numbered 9 to 28) were running the bootstrap program. This is a sign that the watchdog timer has done its job of stopping a crashed processor and getting ready to load a new program. (With our reset-on-break feature, we'll be able to restart the monitor programs by sending a break signal, and not have to access the reset pins.)

Weber's theory, and it sounds plausible to me, is that the extra 8 bytes of RAM (6.25% of total RAM) has caused the command buffer to collide with the stack. I note that the later BMU boards have more work to do; they echo responses from all the boards up to that point, whereas the first three (as an example) boards only see responses for the first three BMUs. So that might explain why the boards at the beginning of the chain were not affected; they have less chance of a rare deep nesting situation coinciding with a command being written.

We have two BMU boards that have the new MSP430G2432 processor on them, which has 8K of flash and 256 bytes of RAM. We're not using the extra flash or RAM at present, but we could send a special version of the monitor program to those BMUs to use all 256 bytes of RAM, so the stack will be well separated from the command buffer. We could place those boards, currently at the start of the BMU chain, near the end, where the problem seems to be more likely to show up. If the problem "skips around" the processors with the larger stack, then that's pretty convincing that we've found the problem. We might also assemble up a temporary version of the monitor with some features disabled so as to use less RAM.

Just another thing to keep us from pressing the "manufacture" button for the BMUs, so we can get back to welding battery boxes and figuring out where to put our many pack break-up contactors.

Weber and Coulomb's MX-5

Posted: Tue, 02 Aug 2011, 17:29
by weber
We've put further BMS development on hold until we finish the mechanicals and get the MX-5 registered. But here's one last post on the BMS, about adapting our existing prototypes to use Industrial Fibre Optics (IFO) in and out of the battery box. The receive side was easy. The IFO phototransistor was simply connected in parallel with the phototransistor of the existing optocoupler.

The transmit side is a little more tricky since the existing opto-coupler uses an infrared LED at about 2 mA and so only needs about 0.9 V, while the IFO LED is visible red at about 20 mA and so needs about 1.8 V. And we want our BMUs to work down to a cell voltage of 1.53 V (since the microcontrollers work down to 1.53 V, although not specced to work below 1.8 V).

Because we already had differential outputs for transmit, we were able to obtain voltage doubling to drive the red IFO LED by adding only a diode and 100 uF cap. And the internal resistance of the micro outputs is about 30 R each, so we could omit the current limiting resistors.

           Vcc (1.53 to 2.5 V)
           _V_ 1/2 BAV99 (signal diode)
        +   |
TX+ ---||---+
      100uF |
           _V_~ IF-E96 (Red fibre optic LED)
TX- --------+

Here's a photo of the mod on the underside of the BMU.


[Edit: Added Vcc range and improved ASCII-graphics diode symbols as suggested by Coulomb]

Weber and Coulomb's MX-5

Posted: Tue, 02 Aug 2011, 18:33
by weber
This is a bit like the second "final farewell tour" of Spike Milligna the well known typing error, because here's a bit more on the BMS.

It's a very short video showing the pretty light-chaser pattern made by the BMUs as the master requests the voltage of each cell in turn and the following cells pass on the response.

In the final version these lights will be blue, so that red can be reserved for errors or warnings.

Weber and Coulomb's MX-5

Posted: Tue, 02 Aug 2011, 19:09
by weber
Last EV day (Friday) we got back into the mechanical side of things by asking our automotive engineer David Blythe to give us a visit, to look at battery box mountings and other registration requirements. This was one of the very few EV days in the past 2.5 years that the faithful Coulomb just couldn't make it. Both David Blythe and Jeff Owen (Newton) arrived as expected, just after 10 am, as I was finishing putting the MX-5 back on its stands.

Engine mounts
David approved our existing engine mounting cradle, made from 50 x 50 x 5 mm steel angle.

Some problems are that our motor alone can produce 360 Nm which is more than twice the original ICE, and the motor's flange-to-body bolts are only designed to take its own torque, not the gearbox reaction in first gear which will be about 3 times that. There is no gearbox mount in an MX-5 except for the beam that connects it to the diff.

After I explained the fear about putting gearbox torque through the motor flange and asked if we could do a torque brace from the top of the bell housing, Jeff figured, and David agreed, that we should tie two of the mid-height bell-housing bolts to our engine-mount cradle. I also suggested we should maybe modify the gearbox to prevent selection of first gear, although that would violate the "anyone can get in and drive it like normal" principle.

Battery boxes
David re-approved the mountings for the battery box under the boot and in the fuel tank space (middle level) which he had previously approved by drawings. He also approved the row behind the rollbar (assuming we attach it at 4 points to the harness bolts and rear mounting bolts of the rollbar as planned (min 4 x M8). And he approved the mountings of the two low boxes either side of the tailshaft. However, we have to modify the passenger side box to achieve 15 mm clearance from the rotating diff/tailshaft flange. It currently rubs on it! That box was designed with the old diff. We also need to move the brakeline bracket on the passenger side so the brakeline doesn't rub on the battery box. David approved cutting a section out of the bracket and welding it back together.

The boot floor needs to have a steel sheet welded back in between the chassis rails. We should forget about the clear-boot-floor-to-see-the-BMS-LEDs idea, unless it is a token window in the middle of this steel sheet, occupying maybe 1/4 of the area and with round corners. To maximise boot space, this steel sheet can be made to follow the slope of the lid of the battery box down, and then curve abruptly back up to the main floor level. What a shame we ever cut that out. We could have cut it only a small way at the rear and bent that part up and rewelded it.

He approved attaching the low front box of 13 cells (radiator space) to the 4 sway-bar mounting-bracket bolts above it (min 4 x M8), as planned. He gave us some options for the big battery box above the motor. It needs to be held in with at least 4 x M10 or 6 x M8 bolts. We can either
1. do crush-tube-and-plate arrangements through the chassis rails (4 x M10) or
2. reinforce (with welded plates) the gussets joining the shock absorber towers to the chassis rails and bolt to them (4 x M8 min), but if we do this we would need two more attachment points at either the front or rear of the box to prevent pitching.

Jeff favours 1. I favour 2 because it looks really hard to weld the crush tubes to the underside of the front chassis rails. There's so much stuff under there and the car would have to be tilted to avoid welding above my head.

David said that that the little 180 W plug-in fan-heater unit would not be sufficient for demisting, but that air conditioning alone (not even reverse cycle) is a sufficient demister for registration purposes.

After David left. Jeff and I had lunch, then worked on the battery box over the motor. We first altered the controller mountings by welding drilling and tapping, to move the controller 20 mm forward and 5 mm toward the passenger side to give it sufficient clearance from the battery box. I tack-welded the parts of the battery box together so we didn't have to rely on all those clamps any longer. Jeff got it positioned so there was 5 mm clearance from the several obstacles at the rear (brake master cylinder, clutch fluid reservoir, washer water reservoir) then we tried closing the bonnet. No go. The problem was solved by grinding away 5mm (not quite breaking through) the front lower corner of the battery box where it sits on the chassis rail. It will be reinforced elsewhere to make up for this.

After Jeff left (about 8 pm) I cut down the lid of the motor junction box so the battery box will clear it. I cut it sloped to be parallel to the underside of the battery box, and siliconed clear acrylic (PMMA or perspex) onto it. If the cables look too messy inside we can paint it. But we can certainly tidy them up from how they are now. The terminal bolts inside don't even need to be cut because they are close to the rear where the lid is high.

Image Image
Image Image
Image Image
Image Image

[Edit: Corrected some Spike Millignas]