Weber and Coulomb's MX-5

[7circle]

Couple of thoughts:
1 - Nancy the ElCON distributer may not be seeing all your hard work trying to get their charger working without any manufacturer data on what is the flow of messages should be. ie Flow chart would be nice or you.
As Nancy has posted info on the CAN pus spec elsewhere
ie Earlier post in this topic
Endless Sphere :ElCon 1500W charger , New postby nancylooloo@yahoo.cn » Mon Mar 01, 2010 10:56 pm
They may be inclined to release a document on what to do.

Basically I don't understand why they won't release info on the serial communication.

The BMS from - guantuo
http://www.guantuo.com/Products.aspx?i= ... ChildMenu2
is also suposed to be compatable with ELCON chargers

2: I looked back at the circuit and see you edited to show R3 in the power supply section.


Can indicate where you are linking your inverter circuit onto the Pin 6 signal before or after R2?
I was wondering what the source impedance would be on the "IN" signal to detiremine the hysterisis.

The message you are sending to the charger
18 06 e5 f4 10 08 00 0a 00 00 00 00
h1 h2 h3 h4 d1 d2 d3 d4 d5 d6 d7 d8
Voltage d1d2 = 1008h = 4104 x 100mV
Current d3d4 = 000ah = 10 x 100mA
Control d5 = 00h = 0,0,0,0,0,0,0,0=ON

Maybe you need to tell the charger to be "OFF" first.
And get a comms okay reply.
You may also need to send or poll this a number of times before the charger says comms are okay. eg once a second for 10 seconds.

You could check the reverse polarity detection flag and the voltage reading.

Like I said earlier you deserve and award if you get it going without a spec.

[weber]

Thanks all, for the info re the pot box and cable. It makes good sense. One problem we have with using the "barrel" on the end of the cable is that this is about twice as far from the end of the cable-outer as the pot lever is now. It is difficult-to-impossible to get enough separation to be able to use it. On the original engine it wrapped around a rather large diameter quadrant on the throttle.

[EV2Go]

All is not lost there is another way to do it while leaving the pot box in it's current position.

Remember the old choke cable arangement from the 70's cars where a wire cable passed through something that looked like a roll pin?

There was a tiny bolt in the end that clamped onto the cable and the other end was usually secured with a split pin.

[coulomb]

1 - Nancy the ElCON distributer may not be seeing all your hard work trying to get their charger working ...

Nancy has been quite helpful, but I don't think she has the technical expertise that I need. I was just talking to Mcudogs about this last night; he seems to have had contact with the designer himself. So if I really run out of ideas (I have a few left), I might pursue that option.

The BMS from - guantuo

http://www.guantuo.com/Products.aspx?i= ... ChildMenu2

is also suposed to be compatable with ELCON chargers

Ah. I've seen that BMS before, and I've been reading a fairly good document with the various packet formats, and didn't connect the two. But I see that the document has "GT" at the top, which likely stands for GuanTuo; most of their BMS product names start with GTBMS (presumably GuanTuo Battery Management System).



Rescanning that document, it's finally dawned on me how the CAN IDs are constructed. Or at least the last 16 bit of them. It seems to come from the IEEE J1939 [ Edit: maybe that should be SAE J1939) standard (which I haven't looked at; perhaps I should). It seems to be a way to specify the source and intended destination of messages, since the CAN bus standard only really specifies a sort of "data content". So while CAN says something like "Mass air flow is 3.7, for anyone that cares about such things", with the extended (29 bit) IDs and the J1939 standard you seem to be able to say "this is mass air flow sensor number 5, intended destination is ECU number 2, here is the air flow value you will need".



The last two bytes are source (last byte) and intended desination (byte before that), with the codes 0xF4 = BMS, 0xE5 = charger1, 0xE6 = charger2, and 0x50 = broadcast. The latter address turns the packet into a more standard CAN packet. The charger sends out such a packet; its CAN id is 18FF50E5h, so the source is E5 (charger 1) and the destination is 50 (to whom it may concern). On the other hand, the Elithion BMS uses ID 1806E5F4h, so the source is F4 (BMS) and the intended target is E5 (charger 1).



All the "extra" packets defined in the GT document use IDs ending in E6F4, meaning BMS to charger 2. All the extra packet formats also mention "only available for charging station", which I think means "these will only be generated by our BMS, and only our charger will be expecting them". However the main two packet formats use charger 1 (E5), which possibly means that any charger conforming to IEEE J1939 will understand and generate these packets. A real standard!

Can indicate where you are linking your inverter circuit onto the Pin 6 signal before or after R2?

After R2. Before pin 2 is internal to the CAN box, normally buried under 5 mm of potting material. I suppose I could solder a wire onto R2 or the opto, but I wanted to try to use it as is.

I was wondering what the source impedance would be on the "IN" signal to determine the hysteresis.

I was aiming for 10% with the 15k/150k ratio. I guess it would be a lot less when the opto is conducting.



Edit: "all of" -> "most of"; GTBM -> GTBMS.

[Squiggles]

You've been doing all this without referencing the CAN standard

[coulomb]

I've done as threatened and modified the inverter circuit to get crisp rail to rail signals to the charger, in case it is needing them:

EDIT: WARNING! The below is based on incorrect assumptions, and WILL BLOW UP your charger's opto-isolator! WARNING!







The transistor is needed to amplify the ~ -3 V .. +7 V RS232 signals to be at least 2/3 of the 12 V rail. I also modified the software I've been using to talk to the BMUs to monitor the RS232 from the charger, and regularly send a packet requesting 410.4 V and 1.0 A. It also displays the charger status (e.g. "can_comms", "ac_volts" etc). The ac_volts status comes on when I turn the charger off (it keeps running the comms for about 24 seconds after power goes off; it must have some big capacitors in there).



I even checked that the signals are crisp RS232 by tapping off between the two inverters and feeding that back in as RS232 input. It displays 410.4 V, 1.0 A, and "hardware_fail" in place of "charger off". So I know that the signals are good, although it is still possible that the data on the Elithium page isn't exactly what the charger is expecting, or I have made some other invalid assumption. I also tried inverting the signal (taking the output from the first inverter instead of the second), still no difference. Always I get the seven flashing lights (indicating no valid CAN communications for 10 seconds), and the status flag that says the same thing is also on. The voltage from the charger comes back as 0.5 to 1.0 V, and the current is always 0. There is a small voltage at the output of the charger, roughly half what the charger says it is. Obviously the charger isn't going to be very accurate at extreme low values of output voltage, so that's fine.



I've also tried asking for the charger to be turned off first, then on.



So I'm thinking that I can't have the right CAN packet contents yet. I suppose it's possible that the lack of an actual battery at the output may be causing the charger to emit an error, and lacking a separate status bit for this purpose, they use the CAN communications status bit for this error. I'm loathed to put a 12 V battery on the output of a 400 V charger, in case it suddenly comes on full bore. Maybe I'll find a battery that I don't care much about for such experiments. And/or find some ~ 2 A fuses that can definitely clear 400 VDC.

[mcudogs]

You may be right about the missing battery. My charger won't turn on unless the battery is attached and within acceptable limits.

[PlanB]

Saw mention of Ultramotive in your posts guys. Their 'carbon' motor with a tritium controller seems like a nice combo. I feel like I'm stuck in the boonies here in Sydney. A few years ago I first stumbled across Ev conversions with Ross Blade and the Azure dynamics solution in Melbourne & now it looks like all the action is in Brisbane.
James reckons their 900v controller is still two years away but it's great to see you guys getting stuck in with what's available now. I got to go for a run in a Blade MX5 a while back, it's hard to forget that faint electromagnetic whine from under the bonnet, just the sweetest sound.

[coulomb]

Spot the diff:



For one thing, the new diff is a fair bit longer, and a bit meatier at the back. Yet only 3 kg heavier: 27 kg vs 24 kg. It's supposed to be much stronger; the nut holding the wheel (not the gloved Weber) is 32 mm, verses 29 mm for the existing diff.

We want this taller diff (~3.6 vs ~ 4.3) to give us more high end power; our motor has more torque and less speed than the original IC engine.

Edit: The new diff comes with stronger half shafts, and a shorter tailshaft.

Edit: less tall -> taller (duh)

[weber]

Spot the diff:... the nut holding the wheel (not the gloved Weber) ...

Ah Coulomb, you're such a card, and should be dealt with.

We want this less tall diff (~3.6 vs ~ 4.3) to give us more high end power; our motor has more torque and less speed than the original IC engine.

Sorry Coulomb but a 3.6 diff is _taller_ than a 4.3 diff. That's because it doesn't divide the propshaft revs down as much, so the wheels do a larger fraction of a revolution per propshaft revolution, and so the car travels further per propshaft revolution in the same way that a tall person takes longer strides.

The 4.3 diff has 10 teeth on the input gear and 43 on the output.
The 3.6 is actually 3.6363.. and has 11 teeth on the input and 40 on the output.

Unfortunately the term "driveshaft" is ambiguous due to different British and US usages. So I prefer the term propshaft for the longitudinal one (as in the propellor shaft of a boat) and half-shafts or half-axles for the lateral ones.

[EV2Go]

what's wrong with the good old aussie term "tailshaft"?

[weber]

what's wrong with the good old aussie term "tailshaft"?

Absolutely nothing. I forgot it existed. Sorry. It certainly is exclusively Australian (but we can work on that ). Makes more sense than the British "propshaft" since there isn't any propellor. At least not on my car. But certainly the term "driveshaft" is hopelessly confused. Would makes more sense if it referred to both kinds.

[EV2Go]

Agree. Propshaft sounds like it belongs under an E-Type Jaguar and driveshaft could be either a tailshaft or a half-shaft. They should have just called anything that the diff drives either an internal / external axle, at least that way we would know that a propshaft, driveshaft, tailshaft and any other name it is called were all the same thing.

[coulomb]

But certainly the term "driveshaft" is hopelessly confused.

Indeed. You will recall that I could not make sense of the (British) instructions till you pointed that out. They still didn't talk about disconnecting the tailshaft, so I wondered if they meant by "each drive shaft" each of the three shafts (two half-shafts and the tailshaft). They all happen to be attached by four 14 mm bolts. But later it became clear that they only meant the half shafts.

[7circle]

RE - Pack Seperation

... We will also have 12 vacuum contactors for pack breakup. These Andersons are mainly so we don't have to deal with unfused bolted connections when lying underneath the vehicle installing or removing battery boxes.

If your using 12 will that be 2 in each of the 6 battery boxes?
Do you isolate both pos and neg in the battery pack box?



What type of "vacuum contactors" will you use?
Sounds costly. Would they need to be 100A with 1200Vdc Isolation?
The Coils to pullin the contactors are you tinking of 12VDC?
What coil current would they need?

So if they are normally open then you need the Aux ACC battery to be charged/ready to turn them all (12) ON.

Also if the Aux 12VDC lost connection to battery packs the isollators would drop out most likely while current passing causing arcing in contactors as they release.
Would it be worth having a fast Solid-state relay in the circuit too to kill current first?
This would prevent arcing in contactors and help them last such an event.

It could have the blead resistor across it for charging the DC bus capacitor bank in the Motor drive and 12V Bat Charger.
... can't remember if you where to have a 12V battery or just DC/DC. re dual Meanwell DC/DC's to be used for floating a 12V battery.
If you haven't got a battery you might need a hand crank generator to get power to bring in all the isolators.

in other topic...
It would be a nice feature, so if you can see a way to make it work ...

RE BMS circuit with the "LINK IN" or "LINK OUT" signals
For the LINKIN signal on Neg Battery BMU pcb in each pack add:
, add a 1uF Cap to GND (to allow diodes time to turn on)
and diode to GND and diode to Vcc as MSP430 can only take 2mA in its pin diodes.
Then a 10kohm 1/2W (1000V) resistor then followed by100mA trip PTC resistor 1000Vdc/650VAC so when normally operating at 50ohm it wont effect the 10K + 75Kohm (x2)circuit path.
As the PTC will take 1/4 second to turn off the diodes need to be over 0.1A and if there Vrrm is 1000V they're still low cost and do the job.

LINKOUT on POS end BMU with similar addon but diode to Vdd not Vcc.

You could fit them to the edge of the PCB's with axial diodes not surface mount. Making it tidy and tough is always a challange though.

Then I would also totally isolate LINKIN and LINKOUT from the connectors with relay contacts 1000Vdc isolation. So another couple of relays.

Considering all the connectors, wiring, relays and vacuum contactors, it might be worth having a Battery-Pack PCB to help with signals distribution.
I guess your plan of the end BMU having the extra opto may become redundent and could be moved to this PCB with the LINK protection.

So your battery boxes would have in and out connectors with
IN(0V, 12V, COM+, COM-)
OUT(0V, 12V, COM+, COM-)
LINK-POS, LINK-NEG
BAT-PACK-POS, BAT-PACK-NEG

After considering all those extras (plus the LINK wiring) maybe it's not worth the cost to verify where the fault is when it could be either the contactor or anderson plug (or the circuit its self).

The more built in diagnostics, the more commercially viable the design would be considering the automotive OEM market. (If the cost doesn't blow out)

I hope some of that is helpful. Helps me consider the options of + 300Vdc EV approach.

(edit 10K + 75Kohm (x2))

[coulomb]

If you're using 12 will that be 2 in each of the 6 battery boxes?

No. There are in fact at least 7 boxes; the 13- and 16-cell boxes are at opposite ends (driver's side and passenger side) of the car. So they will have cables between them, and they need another contactor.

Do you isolate both pos and neg in the battery pack box?

No. The extra contactors are so that we can enforce ELV onto each isolated section. The ELV limit we're using is 120 VDC, so assuming a maximum of 3.65 V on each cell, that's a maximum of 32 cells in series before a separation contactor. We may not need exactly 12, but it will be close, so we're using the 12 figure to work with.

[ Edit: a figure of 28 cells comes to mind. I think that's if we consider the maximum cell voltage to be 4.2 VPC.]

What type of "vacuum contactors" will you use?

EV200s Kilovacs (Tyco Electronics).

Sounds costly.

They are. We got them off Ebay and a few via Johny's bulk buy, at something like AU$50-60 each all up. That's still a lot of money, and one of the things that makes high voltage AC more expensive than low voltage DC.

[Edit: the price has been low for a while because of the liquidation of some EV company in the US about 2 years ago. I believe that they normally sell for around AU$200 each, which would change the economics considerably.]

Would they need to be 100A with 1200Vdc Isolation?

No. They are all in series, so as long as they don't switch under load, the voltage ratings more or less add. These are rated at about 600 VDC, I believe. They will pass up to 240 A at peak traction power, assuming the pack can supply it.

[Edit: the "continuous carry current" is 500 A, so that's fine. They mention "rated operating voltage" as 12-900 VDC, so I assume that we'll be fine if one contactor opens on its own. ]

The Coils to pulling the contactors are you thinking of 12VDC?
What coil current would they need?

Yes, they are all 12 VDC coils with optimisers. The hold current is a moderate 130 mA, so that's under 1.6 A continuous load. However, the maximum inrush current is 3.8 A, for a total of over 45 A briefly, and that figure has me concerned. If necessary, we could stagger the closings by say 20 ms each, with a simple piece of circuitry. But then that's another piece of complexity in a vital part of the vehicle. As you point out, dropping the main contactors (or even one of them) is going to cripple the car.

So if they are normally open then you need the Aux ACC battery to be charged/ready to turn them all (12) ON.

Yes. There is no way that the DC/DC can be running when the isolation contactors are off.

Also if the Aux 12VDC lost connection to battery packs the isolators would drop out most likely while current passing causing arcing in contactors as they release.
Would it be worth having a fast Solid-state relay in the circuit too to kill current first?
This would prevent arcing in contactors and help them last such an event.

That's an interesting point that I at least haven't considered yet.

If you haven't got a battery you might need a hand crank generator to get power to bring in all the isolators.

It might be a way to start the car after having parked it away from power. It's somewhat ironic that an EV ends up having similar 12 V battery issues that an ICE engine has, with respect to "starting" it.

Edit: added better description and link for EV200 contactors.

[weber]

Just to add to Coulomb's excellent reply (which he has edited to add even more useful info including a link to the EV200 vacuum contactor datasheet):

None of the contactors are actually _in_ the battery boxes. Which is one reason we need the fingerproof Andersons. There's no room in there for anything but cells, BMUs and cell clamps, and barely enough for those. We figure that double-insulated and mechanically protected cables (16 mm^2) can be run from the Anderson's to some other space where the contactors and fuses are in PVC junction boxes. These junction boxes will be put in places where we can't actually fit any cells.

As you would have seen, space for cells is at a premium in this performance design. So if we have to then spend more money to make it safe, so be it. I'll just have to teach some more classes in PV system design and installation to pay for it.

Our ELV segments end up varying in size from 13 cells to 28 cells. The 13 is because we want every battery box to be a whole number of segments (between 1 and 3 as it turns out). Or putting it another way, we want every box to be isolated by at least a contactor on each side of it. And the smallest boxes hold 13 cells. These are the one down low on the drivers side of the tailshaft and possibly the one down low at the front, although we hope to squeeze 14 into that one.

The 28 is because we don't want to have to bring heavy cables out of the middle of any row of cells (again there's no room inside the boxes to do that) and the largest set of adjacent rows within a box, that totals less than 33 cells, happens to be two rows of 14, totalling 28. So with max 28 cells per ELV segment we would also be OK with Thundersky cells at 4.25 V max charge.

There will actually be 14 breakup contactors in total because the pack is configured as two independent strings of 114 cells. This allows charging with two independent chargers that can run off two independent domestic power circuits with separate circuit breakers and so pull 10 amps each at 240 Vac. And each string consists of 6 variable-sized ELV segments, so each string needs 7 contactors (5 between the segments and one at each end). So we switch both positive and negative of each string, as you must with any floating supply.

There will be other contactors that connect these strings in parallel for feeding the controller (and possibly in series in future, for a higher-voltage controler), and yet other contactors to control the precharge resistors.

I note that with a floating traction pack, you can in theory "jump start" a flat 12 V battery with jumper leads off any 4 cell section of the traction pack. In practice this would be difficult and dangerous. Better to do it off another vehicle's 12 V battery as usual.

[weber]

I had a private request for dimensions of the adapter plate for the gearbox bellhousing of the Mazda MX-5, also known as the Mazda Miata (USA) and the Eunos Roadster (Japan). I thought I might as well post it here too, in case someone else can benefit. Apparently it may suit some other Mazdas as well, such as the Mazda 121.

See
viewtopic.php?t=980&p=26473#p26473
for photos and other info.

The obvious origin or reference point is midway between the two locating dowels (the two holes that are almost on a horizontal line through the shaft centre). The dowel centres are 161.0 mm either side of the origin and the centre of the shaft is 2.0 mm below the origin. The dowels are 19.0 mm OD. These are the only critical measurements.

The six lower holes are all on a circle of radius 161.0 mm.

The two lowest are at angles of 22.6 degrees either side of vertical (61.9 mm either side of the origin and 148.6 mm below it) apparently forming 5:12:13 Pythagorean triangles.

The other two without dowels are not symmetrical and are 56.1 and 47.9 degrees off the vertical (one is 133.7 mm to the side and 89.7 mm below the origin and the other is 119.5 mm to the side and 107.9 mm below the origin).

The two top bolts are on a radius of 204.1 mm and at angles of 23.0 degrees either side of the vertical (79.8 mm to the side and 187.9 mm above the origin).

If anyone ever get this into some kind of CAD file, I'd appreciate a copy. You'd also need to describe the outline as a series of lines and arcs as well. We haven't done that. Pascal just traced around the bellhousing for that.

[Edit: Made URL into a live link]

Edit2: Note that the two bellhousing bolt circles I give radii for above, are centered on the aforementioned origin, _not_ centered on the shaft. However the bolt circle for the electric motor flange _is_ centered on the shaft, 2.0 mm below the bellhousing origin.

Edit3: KlaasDC has made a drawing, and an Autodesk Inventor file, from the above measurements, and added an outline. See viewtopic.php?title=weber-and-coulombs- ... 131#p40131

[weber]

We mentioned getting a stronger taller diff, and because it's physically larger than the old diff we also have to put in the matching shorter tailshaft and half-shafts. Richard Larsen of MX5Plus who sold us the used parts also loaned us a special tool he made for pushing the half-shafts out of the wheel hubs.

As we learned with the tie-rod ends, belting a thing like that with a hammer, axially, does nothing but cause a shock wave that expands the thing laterally (and therefore makes it stick harder) as it passes. What is needed is steady pressure.

Let's call it Special Tool No. 378. Here it is bolted in place by the wheel nuts.



We needed to get Special Tool No. 378 back to Richard within a week, i.e. by today. But before we could get to use Special Tool No. 378 we had to get the wheel hub nuts off. The enthusiasts workshop manual gave dire warnings about the fantastic amount of torque needed to get these off.

First problem, they are 29 mm nuts. I kid you not. Super Cheap Auto didn't have 29 mm. They had 28 mm and 30 mm and they had 1&1/8". So I'm standing there in the store doing inferial to metric conversions in my head (it's 28.575 mm) and I decide to give the 1&1/8" a go. Fortunately it fitted -- very snugly -- so it is actually a better option than the 29 mm.

Then I'm home with 1/2" socket handle and long piece of pipe and son and wife taking turns standing on the brake pedal as hard as they can or me standing on the pedal and them pulling up on the bar, but no good. The brake disc always slipped before the nut would let go.

So I had to quickly invent Special Tool No. 379 so I could use Special Tool No. 378 and get it back to Richard today. Here it is. Note the wheel nuts on backwards and tightened with wheel brace to resist bending of wheel studs by crowbar. And extra wheel nuts from the other side to protect wheel stud threads from damage.



Worked a treat. Now I'd better go and take Special Tool No 378 back to its owner, with thanks. See you later.

[EV2Go]

Special Tool No. 379 looks familiar, are you infringing on my copyright? (got a feeling I wasn't the first by let's say a considerable margin )

[weber]

Special Tool No. 379 looks familiar, are you infringing on my copyright? (got a feeling I wasn't the first by let's say a considerable margin

Yes, I expect the more general claims in your patent would fail on the basis of prior art, if I could afford to contest it. But I'll bet you have a claim, right near the end, that specifically claims the use of a rusty crowbar and an old pair of Dunlop KT26 joggers (Driving Grade) as the "levering means", on the off chance it might prove to be new, useful and unobvious.

[Edit: fixed smiley in quote and minor grammar at end]

[coulomb]

We've had a bit of trouble getting a serial port working on Weber's relatively new Dell laptop. It comes with 64-bit Windows 7, which despite the name, isn't very Windows compatible. Well, 32-bit software works OK, with the exception of some older software, but getting 64-bit drivers that work has been a problem. The laptop I'm typing this message on was inherited from a work project that needed 64-bit Windows XP, and I was frustrated enough by the lack of drivers 2 years ago that I shelled out money to buy a license for 32-bit Windows (again; I've bought it often enough before, and had it come pre-installed on machines before, but I always forget to save the product key before I put the axe into obsolete machines).

Finally, Weber found this gizmo which promised to work on 64-bit Windows 7 (though so did the Jaycar USB to serial adapter, but we just could not get that to work):



[Edit: It actually did work on 64-bit Windows 7.]
The old interface and the Jaycar USB to RS232 adapter is on the left. The Novus USB-i485 is on the right. It comes with a truncated 80mm mini CD-ROM, which Weber couldn't even insert into his latest laptop (it's one of those trayless ones where you push the CD-ROM into the drive). So he had to download the drivers (I find it's usually a good idea anyway; the ones on CD-ROM are often out of date) from this Brazilian page:
http://www.novus.com.br/site/default.as ... bsecaoID=0
(Search for i485 on that page; it currently leads to
Operating Manual and Drivers for USB-i485 (7.12.2010)).

We use it in RS422 (= RS485 full duplex?) mode, hence the link from MOD to GND. It provides differential drive, just like our BMUs, and accepts differential data from our BMUs. The only modification we had to make was to add a pair of 1k resistors in series with the TX+ and TX- wires; you can see them in the photo. This converts the +- three point something volts (under load) to about 2 mA maximum drive with a worst case 1.0 V drop across our opto-isolator diodes.

[ Edit: we use 560R now, not 1K. ]

The receivers only need about 0.3 V of signal, so our 2.5 V signals work with no modification. We don't use terminating resistors (RT1 and RT2 terminals).

The Tx and Rx lights on the unit are handy. Although the transmit and receive parts of the unit are not isolated from each other, they have good (1500 VDC) isolation from the comms ports to the USB port. This is something that my simple circuit did not have (though it could easily be modified to provide the isolation). This will be useful when we have a lethal battery pack put together. We just have to remember that the Rx (to the BMUs) wire could be hot, if the Tx wire is connected to an unisolated Tx port on a BMU (most of them are not isolated).

Overall, we're pleased with these units. They are not exactly cheap at $129 + GST + freight (total $155.40) from Ocean Controls in Victoria. Shipping was quick, about 2 days. They are also MacOS and Linux compatible.

[EV2Go]

Not all USB to serial adaptors are created equal. The first one I bought to interface with my ECU gave me quite erratic results and kept on loosing the signal.

Bad enough that I had interopolation issues between the wideband O2 sensor and the ECU (Haltech), I really didn't need the adaptor being inconsistant.

I bought another one and it really helped with refining my auto tuning software, unfortunately with no syncronisation, and limited protocol co-operation with the ECU vendor, there was only so much I could do.

[rhills]

We've had a bit of trouble getting a serial port working on Weber's relatively new Dell laptop. It comes with 64-bit Windows 7, which despite the name, isn't very Windows compatible.

Guess you're up and running now, but don't forget the Linux option. I too bought a 64-bit laptop recently that came with W7 but I am now running Ubuntu Linux on it instead. I can run Windoze 7 in a window on it if I need to but haven't needed to so far.

Although I've contemplated doing this in the past, I've always had to have Windoze as my primary OS because not enough stuff worked in Linux. This time it seems the other way around. In particular, Ubuntu's support for "old" stuff (printers, mice, webcams etc. > 12 months old) seems much much better than W7's. I think it's fair to say that Linux has moved out of the domain of Geeks and is now something you'd install on your parents' computer.

And when you start talking about real geeky stuff like serial ports, usb, rs-232 etc, you're into the domain that linux rules!

The nice thing is that you can try before you "buy". Before I took the plunge, I downloaded and installed Ubuntu onto a $10 usb memory stick and booted my new laptop from that to check that everything worked OK before taking the plunge and actually installing it on my hard disk.

[coulomb]

We use a TI eZ430-F2013 Development Tool slightly modified to program our MSP 2012-based Battery Management Units (BMUs). We have two units. For mine, I soldered four wires on to the main printed circuit board, and brought it out to a 0.1" spacing header plug, for connecting to the actual BMUs.

For Weber's, we decided to sacrifice a target board (we still have one whole), and cut off the target board just below the area where there are 14 holes (also at 0.1" spacing), one for each processor pin. We just soldered to four of these.

It seemed to work for a while, but we noticed a few glitches. These development boards are cranky at the best of times, but I became suspicious of Weber's when it would not light the LED on a BMU reliably. I found that there was about 2.8 V on the processor, with about 3.6 V at the reset (SPWTDIO) wire (that's something like Spy By Wire Test Data Input/Output, but it's also the reset pin as well, pulled up to Vcc with a 47k resistor). [Edit: it's pulled up on the BMUs as well as on the target board.] Sure enough, the Vcc pin was not connecting to the 3.6 V power supply on the development tool board.

It turns out that the Vcc wire connects via a zero ohm resistor, so you can remove this resistor if you supply Vcc externally:

     

[Edit: This resistor happens to be on the part of the board that was cut off.] So if you do this, make sure you cut the board below the track that conducts Vcc, or add your own jumper. Better yet, we found that cutting the board makes it more prone to pulling out from the tiny plug on the main board, so just cut the processor pins off and leave the target board whole.

Restoring the Vcc lead reduced the glitches somewhat, but plenty remain. For example, we find that sometimes the driver refuses to start until we plug the JTAG into a completely isolated BMU, or replace the original MSP430-F2013 target board that the development kit came with. That seems to change some state somewhere, such that debugging on a BMU that is on a battery becomes possible again (for a while).

So far, we've never been completely unable to debug. I've put some of the workarounds I've found here.