Weber and Coulomb's MX-5

[coulomb]

Or you could use this freeware serial port monitor software.

Thanks for that, Don! It's pretty close to what I was looking for. I'm pretty impressed that its tentacles can reach out of the computer to the serial hardware that is out past the USB port. But of course it just looks at the serial API, and it all "just works". Impressive.

It still has some Windows limitations showing through. For example, I wrote a program to just send commands to the BMUs; I can see the commands going out. But I can't see the reply, apparently because "no-one is listening". I can't run HyperTerminal to read the result, because my program already has the serial port opened. Sigh. I need "half a comms program" or a program that "opens half the serial port".

There may be other options in the serial port monitor to explore. I guess I'll have the same problem with the charger; nothing will be "listening to what the charger is saying".

The other issue that I had is that it wanted me to "close the application" that has holding the serial port. Well, I did; it has an infinite loop, and I used ^C to cancel out of it. Of course, that means that I bypassed the code that closed the serial port. So the monitor program was hanging (at 100% CPU no less) waiting for the comms port to get closed, and it wasn't going to happen. I had to wind the Windows down and up again to fix that one; process monitor would not kill the monitor (presumably because it has to do some tricky driver-level things that Windows doesn't like to kill).

[Electrocycle]

what I've often done in the past is connect another serial port's Rx line to whatever I want to monitor, then view / log it in another terminal program.

[mcudogs]

Mike, this software lets you send commands as well as listen to responses. The free version is limited but may let you do what you want.
serial sw

[coulomb]

Or you could use this freeware serial port monitor software.

Thanks for that, Don! It's pretty close to what I was looking for.

With the "no-one listening" problem, I decided I needed some crude software to look for results coming from the last BMU, and echoing that to the screen. The ClearCommsError() function seems like it should tell me when there is data waiting (the third argument is a pointer to a structure with among many things the number of bytes unread). So then I can call ReadFile() for that number of bytes. Seems simple enough.

The only problem is it never sees any unread bytes. Aha! I can use the serial port monitor to see if anything really is coming back! Unfortunately, the combination of my software and this monitor program led to the entire computer freezing twice: no mouse cursor movement, no alt-tab, no ctrl-alt-delete for the task manager, nothing. That gets faintly irritating.

Guys, thanks for all the suggestions; I'll get there in the end. It seems such a simple problem - send a bunch of commands every few seconds, and echo the response.

[coulomb]

Mike, this software lets you send commands as well as listen to responses.

This looks really close to what I want too; thanks again for the pointer. Alas, it only sees "modems", and the USB serial port adapter doesn't show up in the comm port drop down box. And in this one, you can't type your own comms port name into the box.

So close.

I think I know what's wrong; the sample software I copied seems to be using an overlapped structure, which I need to pass to ClearCommError(). I didn't think I was using overlapped mode, so I thought I could get away with passing NULL for the overlapped structure pointer.

[coulomb]

Oh, oh! Burning resistor smell!



Note the burn marks around R5. Luckily this was on a strip of only 3 BMUs, so only 6 bolts to undo.

Huh? That's a 150 ohm resistor. 3.3 V across that is only 1/13 of a watt. Somehow it must have gotten 24 V; that would be 3.8 W; that would cause this kind of damage.

The last thing that I did was to swap from the bench power supply to the 6 A charger.

Oh, no... surely not... Coulomb gets a multimeter, puts it on the continuity range, one lead on the earth pin of mains plug, other lead on negative output... beeeep!   

Non isolated charger. There are opto isolators everywhere on the BMUs, so it's easy to forget that the output isn't isolated. Well, except for the end-of-row circuit, which we only populated on a few boards. Ok, this happens to be one of those boards, so if I had used it, this damage would not have happened*. I didn't bother using it because the 12 V connection is another connector to balance delicately and make sure it gets a good connection. Sigh.

The worst part is that the 150 ohm resistor goes directly to the microprocessor. So it would have seen some 24/150 = 0.16 A through its output. So that's another difficult soldering operation to remove the processor and replace it with a spare.

* Edit: turns out that this end of row circuit was not tested, so it wasn't working anyway. So the 6 bolts came off again

[coulomb]

Incredibly, the processor survived that ordeal! It's measuring voltage, passing comms, etc, now that I've repaired the resistor.

Edit: I guess those resistors (R4 and R5, splitting the current limiting job between them) really did their secondary job (of giving some protection to the micro).

Weber was concerned that the outputs may have lost their protective diode, but my multimeter says they're still there. Amazing.

[coulomb]

We've just ordered a pair [of HLG-240H-15A LED power supplies] from Mouser. At AU$195, they're a bit pricey...

I found another supplier (via insightcentral.net, thanks guys):
http://www.trcelectronics.com/Meanwell/ ... -15a.shtml
They have them at US$119.25 (around AU$140 @ 0.85 exchange rate); I don't know what the shipping is like (the Mouser price includes shipping).

They also have the CLG-150 series, which is also designed for 277 VAC, but with a maximum of 280 VAC or 396 VDC, just a little too low for us, at US$88 each. Oh, and I see also the CLG-100 series, which seem to accept up to 295 VAC / 417 VDC, for US$78. We might get these if our current pair of supplies isn't enough. These are IP67, and I don't see how they can be adjusted for voltage or current.



[ Edit: it looks like new stock from Mouser will be slightly cheaper at AU$183. Many available models, but not the 15 V version, are at this price already. Also, Mouser will have the B and C versions (IP67 and connector block versions) for a little more money, MOQ is 1, but lead time is 20 weeks. ]

[coulomb]

I just need to post this somewhere so some poor sap like me doesn't get caught by Microsoft's ... well, unique software style.

After finding some example code for reading and writing to serial posts that seemed to need Visual Studio, I weakened and installed Visual Studio 2010 Express (it's free for evaluation, unlimited time). After installing it, it complained about mscorlib.tlb not existing in a certain place, but in fact it was definitely there. After much searching and rebooting and reinstalling, I got it down to an immediate error message, and finally found this post:

http://social.msdn.microsoft.com/Forums ... c9cd07c2a0

I implemented it by putting these two lines into a file vc.bat in the start menu:

set windir=c:\windows
"c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\VCExpress.exe"

Low and behold, it works if you start using vc.bat. (Windir is already set to c:\Windows in System Properties/Advanced tab/Environment Variables\System variables). It looks like Microsoft never tested on a machine (like Windows XP) where one environment variable chains to another. Or something. Anyway, it now at least starts up.

[coulomb]

I finally have some serial port software that can communicate in two directions. It was some old MFC (Microsoft Foundation Classes) code, so I tried to install Microsoft Visual Studio 2010, only to find that MFC is not included, and doesn't seem to be available free anywhere. (This after all the dramas with things not installing).

Finally I found an old disk with Visual Studio 2005, and it's installed and working.

Here is the current version I'm running while charging a string of 8 cells:



It seems to work well enough for now, but I feel certain that the final BMS master won't be running under Windows. The voltage commands make a pretty pattern with the error lights (which flash at 50% when a communications byte is being sent).

The "tick" command at present just turns the bypass resistor on or off based on a single voltage measurement. The master will know if a BMU isn't talking, because it won't get the "k" command echoed at the end of the string. I'm not checking for that in this early version.

Of course, I'm running a multimeter up the string of cells every few minutes just in case.

[weber]

Dr Van Emmerik! (coulomb) I have been dreaming of seeing a display like that from our cells, for almost a year now. Thank you so much for making it a reality.

And I had a surprise visit from another true craftsman this evening. Warrick Beattie (pascal) delivered the finished adapter plate. Isn't it beautiful! But what's more, it fits the gearbox and motor perfectly, with alignment more precise than we can measure.





That's the hand of the maker in the photo. Michelangelo eat your heart out.

I must tell a story about this guy's attention to detail. When measuring the position of the center of the motor shaft relative to the two locating dowels, we got different answers depending on whether we measured it off the gearbox or the ICE. We measured each in several ways including an ingenious one Pascal came up with involving inserting two Nikko pens (which happened to be exactly the right diameter) into the two dowels.

You'd expect the shaft center to be at the center of the line between those two dowels, but in fact it was a few millimetres below it. When measuring off the gearbox we were getting 2.0+-0.1 mm and off the ICE we were getting 2.2+-0.1.

Now I would have been happy to say "lets just make it 2.1 mm and be done with it". But all other measurements had been a whole number of millimetres and so this wasn't good enough for Pascal. Nor was it good enough for him to say, "let's make it 2.0 mm and assume we're somehow measuring it wrong on the ICE". He had to find an explanation for the discrepancy and figure out which one was right.

Eventually he hit on the hypothesis that the crankshaft bearings on the ICE were worn down by 0.2 mm. Rather than turn the ICE upside-down we screwed a bolt into the end of the crankshaft and I hauled upward on it as hard as I could while Pascal remeasured. Sure enough, 2.0 mm.

[Edit: See http://forums.aeva.asn.au/viewtopic.php?t=980&p=27297#p27297 for more dimensions.]

[coulomb]

Now that I have 34 BMU modules completed and tested, I have a little time to turn to the charger and its CAN interface.

It took me a while to turn the first image into the second image:

     

It was then possible to trace the RS232 interface circuit as follows:



The surprise is that the received data (WRT the charger) has no pullup, and there is the fairly large resistor R2 in series with the opto. I guess I was wrong about this interface being even close to RS232 compatible. It certainly explains why I receive no data; my interface circuit expects high signals to supply enough current to turn on the base of a transistor, and an RS232 receiver would expect much the same. I'll need a transistor between the CAN box and the RS232 connector; either an NPN emitter follower or PNP common emitter circuit (depending on the polarity, i.e. mark = opto conducting or mark = opto open) running from about +5 V (e.g. using the DTR output).

[ Edit: It's no longer a surprise now that we know what's in the charger, now marked in red on the schematic. ]

Then again, the data rate (2400 bits per second) is low enough that perhaps I can get away with about a 50k resistor from TXD to DTR; that will pull it up, and when the opto conducts, TXD will go to 1/11th of the DTR voltage, which might be low enough to be interpreted as a mark. That's assuming that they have stuck to the convention that mark = conducting/current (as per the good old days of current loops and mechanical serial decoding). Did I say the good old days? I meant the bad old days, of course   

[Edit: I've just realised that they don't stick to the current loop "convention" for transmit data from the charger, so I'll likely need the PNP transistor to invert the signal.]

( Edit edit: I believe I must have gotten that wrong. Both directions seem to conform to the opposite of the "current loop convention", which I'll call the "opto convention", which is that optos like to be normally dark. They draw less power that way. June 2015.)


[Edit 2: corrected schematic; had pins 4&5 to the CAN daughter board swapped.]

[Edit 3: added R3 to the schematic.]

[ Edit 4: Added guessed/confirmed charger circuitry (in red) to the circuit diagram. ]

[ Edit 5: Updated charger part of the schematic Oct 2013 ]

[coulomb]

Um, I've made a few mistakes in that last post. I seem to have been thinking that the above circuit is in the charger, or something.

What is surprising about the receive (WRT the charger) circuit is that there isn't a simple pull-up at the charger. What I read is 0.083 V or so, and on the CRO, a few blips up and down. Yet when they connect, there seems to be real data there. I'm not sure why I didn't read any data from when these two (the charger and the CAN box) were connected. I guess I must have goofed somehow.

So there are still some mysteries to unravel. Sorry for the wooly thinking above.

[ Edit: the reason for the lack of pullup was damage to the charger. The charger in fact has the diode of an opto coupler connected to pin 6, with the anode of that diode connected to +12 V. After repair, I see some +10 V there. ]

[mcudogs]

Are you measuring the voltage between pin 2 and the receive data pin?

[coulomb]

Are you measuring the voltage between pin 2 and the receive data pin?

Errrm, no, sorry. My impression that the CAN box was talking to the charger was based on seeing a strong logic signal on pin 5 of the CAN daughter board. But I had an error on my circuit (now corrected); it is actually pin 4 that I should have been monitoring; pin 5 was data from the charger TO the CAN box. I think I was also confused about what was input and output on pins 6 and 7 at one point. (Grrr.) Looking at pin 4 of the daughter board (cathode of the opto transmitting to the charger), I see about 3.2 V steady as a rock, no pulses on the multimeter or CRO. Id say the CAN bus opto must be running at 3.3 V, hence the need for the R5/R6 divider. That's causing the CAN box output on pin 6 to be open circuit.

Because pin 6 is open circuit, I'm seeing about 1 V p-p of spikes on it, presumably capacitive coupling from the other line, which is pulsing about 6V p-p. The CRO input resistance is 1 MR. The occasional spikes I saw on pin 6 with nothing connected to the charger were presumably also capacitively induced spikes. I was imagining some weird arrangement where a pull-up was switched in only when data was expected, say in a milliseconds after the charger has sent its packet. But as I type this, I realise how unlikely that would be.

So I'm back to not knowing what the charger is expecting on pin 6 because there is nothing being transmitted on the CAN bus. I should have a CAN bus driver by the end of the week.

At least I have a reason for the CAN box not sending data: there is an opto isolator there ready to send data, but none is forthcoming. As for why the charger is not pulling pin 6 high, I'm at a total loss, and it's bothering me. If and when the CAN box starts making the opto conduct, how will it know if there is no current through that opto?

[7circle]

When you measured the RX (Pin 6-2) of 0.083V was the Can box connected?
If it was could the opto 1 be turned on(edit-add comma), pulling pin 6 low?
This suggested the RX line is normally low when ready to communicate.
So from the chargers view when it is pulled low it knows the CAN-box is connected.
So what do you meaure ether side of R2.
Or measure on Pin 6 - 2 (edit - on the charger side) with the 7pin disconnected?


for gouging out the gue.
(edit - add comma)

[coulomb]

When you measured the RX (Pin 6-2) of 0.083V was the Can box connected?

Yes.

If it was could the opto 1 be turned on pulling pin 6 low?

Err, no. Pin 6 is connected to the transistor side of the opto; it's the side that gets turned on (or not) by the LED. Forgive me if I've misunderstood you.

So what do you measure ether side of R2.

I haven't specifically checked, but I'd expect nothing on either side, apart from noise induced into an essentially open circuit wire.

Or measure on Pin 6 - 2 (edit - on the charger side) with the 7pin disconnected?

That's a good idea; see if the lack of current in the pin 7 wire makes the slight pulses I saw on pin 6 go away.

for gouging out the gue.

Heh, thanks. I found that a small flat-blade screwdriver was best where I knew that there was nothing underneath was the quickest, and the combination of a fingernail and a wooden toothpick was best near the components.

[7circle]

If it was could the opto 1 be turned on pulling pin 6 low?

Err, no. Pin 6 is connected to the transistor side of the opto; it's the side that gets turned on (or not) by the LED. Forgive me if I've misunderstood you.

Sorry my puncutation was terrible and missleading.
"If it was, could the opto 1 be turned on, pulling pin 6 low?"
That's better.

So have you checked that the LED side of OPTO1 is ON or OFF.
- I think 1.8V across infrared LED in optocopler when ON.

Some people think that as there are opto's the circuit is isolated, well done for showing the GND link around the opto. And that you found the CAN signals isolated from GND.

[coulomb]

So have you checked that the LED side of OPTO1 is ON or OFF.

Definitely off. It has maybe 0.1 V forward bias, nowhere near enough to turn it on. It seems to be waiting for activity on the CAN bus before it sends anything towards the charger.

Fair enough I suppose; what could it send?

[Squiggles]

A possibly useful link URL
http://www.interfacebus.com/Design_Connector_CAN.html

[7circle]

Hi Coulomb, as you have noted, it does seem odd that the pin 6 signal has so much noise on it (0.083V avg 1V p-p).
Does shorting the OP1 pins 4 to 3 (If you think thats okay) remove the noise on the other side of R2 (5K1)?

Old Post on Elcon 7 pin Connecter

You can see that it connects to 4 pins: 2, 3, (ground and power), 6, 7 (TX and RX data).

But the post shows only the 2 pin connector.

I was wondering about the possibility the the Charger Rx signal is not getting through to the charger Pin 6. eg wire broke/soldered to wrong pin/fault in the charger.

Must be very frustrating, with little info from manufacture/supplier.

I hope your CAN Hardware/driver sorts things out.

It looks like your DIY BMS master will connect to the charger without the CAN-Box once you know both the Rx and Tx Protocols. Even if its at 12 byte packets at 1200bps (slow for transient data logging).

Do have any concerns about command errors.

You wouldn't want the Charger to be congured with the wrong Voltage, Current, Battery Capacity Etc.
It would be more comforting if there was an echo of Commands from the charger. Which could be verified before enabling the charger on pin 1.

Again, thanks for sharing your build.

[coulomb]

Now that the main under-the-bonnet battery box has been tack welded, we were able to test the fit it (to a degree; really we need the motor in there to be sure).

It was a pleasant surprise to find that it fitted with a finger gap on one side, and even more on the other.

We've attached the bonnet to the car for now, but since we can't find the bonnet prop (oops... must look in my garage), it's held open with a hook and rope to the ceiling. It actually opens up a lot further that way, which will be nice when manoeuvring heavy items like the motor and filled battery boxes.

[Jeff Owen]

Why are you surprised that it fitted?
Photos?

[weber]

Why are you surprised that it fitted?
Photos?

Of course we should not have been surprised, since you designed it Newton. And cut all the pieces so precisely.

[coulomb]

Today Pascal and Weber prepared the rotor. We were fortunate to gain access to a small lathe. Here is the rotor mounted:



A 4 mm hole was bored into the non-drive end for the shaft of the encoder.



The next part was cutting the drive end shaft to be 50 mm long. Alas, with the small lathe that we had, the parting tool had bad vibrations, so the best we could do was to cut a groove about 2 mm deep with it. After that, we used an ordinary hacksaw, with the lathe merely spinning the rotor for us:



[Edit: the flash really stopped the action; the lathe and hacksaw were both moving quite fast.]

The middle of the drive end came bored with an M12 thread, so we had to do the last part by hand.



It turns out that if we file the end flat, we end up with the 50 mm length that we wanted. Pascal did a heroic effort of hand filing the end.

Unfortunately, the double cutting left is with a slight lip on the end:



Still to be done: we need to bore out the drive end to 18 mm diameter.

Edit: added 2 top photos