Weber and Coulomb's MX-5

Post up a thread for your EV. Progress pics, description and assorted alliteration
User avatar
weber
Site Admin
Posts: 2572
Joined: Fri, 23 Jan 2009, 17:27
Real Name: Dave Keenan
Location: Brisbane
Contact:

Weber and Coulomb's MX-5

Post by weber » Thu, 28 Jan 2010, 17:36

Nevilleh wrote: It looks really interesting and I'm sure that there's a lot of us eagerly awaiting some results!

Always remember,

"By doing just a little every day you can gradually let the task completely overwhelm you."
-- Wil Baden.
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

User avatar
Johny
Senior Member
Posts: 3729
Joined: Mon, 23 Jun 2008, 16:26
Real Name: John Wright
Location: Melbourne
Contact:

Weber and Coulomb's MX-5

Post by Johny » Fri, 29 Jan 2010, 20:28

Geez that's a big motor for a 132 frame classification. It's almost square looking at it from the front. I notice also the terminal box (non-removable?) is on the business end (a topic close to my heart at the moment).

User avatar
coulomb
Site Admin
Posts: 3645
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Weber and Coulomb's MX-5

Post by coulomb » Fri, 29 Jan 2010, 22:59

Johny wrote: Geez that's a big motor for a 132 frame classification.
Thanks. We like it   Image
I notice also the terminal box (non-removable?) is on the business end (a topic close to my heart at the moment).
Yes, but the mounting feet are near the drive end as well. How is yours for balance on its foot mount? That might be a clue as to whether it's been installed backwards.
Nissan Leaf 2012 with new battery May 2019.
5650 W solar, PIP-4048MS inverter, 16 kWh battery.
1.4 kW solar with 1.2 kW Latronics inverter and FIT.
160 W solar, 2.5 kWh 24 V battery for lights.
Patching PIP-4048/5048 inverter-chargers.

User avatar
coulomb
Site Admin
Posts: 3645
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Weber and Coulomb's MX-5

Post by coulomb » Wed, 03 Mar 2010, 05:48

The motor is finally complete!

Image

We didn't want to take out the rotor initially, but when trying to get the flange off temporarily so we could start the screws into the bearing plate, the rear bearing slipped out anyway. So here is the rotor and a look inside.

Image     Image

While the motor was open, we added a thermistor, under a smear of silicone:

Image

Those wires (I hope they can take 160+ degrees) will be protected with some varnished cambric tubing; we can poke that down from the junction box. The thermistor, with some fifty ohms at room temperature, reduces resistance with temperature until about the 160 degree knee point, at which time its resistance rises to over 10 k Ohms.

Edit: since ABB couldn't provide recommended torque settings for the bolts, we looked up standard figures for 8.8 grade bolts. These are now on the top photo.
Last edited by coulomb on Tue, 09 Mar 2010, 15:04, edited 1 time in total.
Nissan Leaf 2012 with new battery May 2019.
5650 W solar, PIP-4048MS inverter, 16 kWh battery.
1.4 kW solar with 1.2 kW Latronics inverter and FIT.
160 W solar, 2.5 kWh 24 V battery for lights.
Patching PIP-4048/5048 inverter-chargers.

User avatar
Johny
Senior Member
Posts: 3729
Joined: Mon, 23 Jun 2008, 16:26
Real Name: John Wright
Location: Melbourne
Contact:

Weber and Coulomb's MX-5

Post by Johny » Wed, 03 Mar 2010, 14:25

Hooray! Well done guys.

User avatar
coulomb
Site Admin
Posts: 3645
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Weber and Coulomb's MX-5

Post by coulomb » Mon, 08 Mar 2010, 06:36

The digital version of the MX-5's Battery Management Units (BMUs, the part of the BMS that exists on the cell tops) is finally ready for prototyping. Perhaps there are some eagle eyes out there that can find a problem before we do send it off.

The circuit is at the bottom of the post, since you may need the scrollbar to see it all:

Edit: schematic was here.

How's that for minimalist, eh?

Well, if it looks way more complicated than it needs to be, consider that the upper right hand part is only for BMUs at the end of a cell cage, where wires head off to another cage. We don't want thin comms cables to be lethal, so these are buffered using the auxiliary 12 V system. So now all the lethal comms wires are within the same cage.

The second MOSFET is in case we want to control a fan in the future. I'm glad we put it in there now; it would have been hell trying to add that later if needed.

Similarly with the two resistors on VREF- and VREF+: they are an experiment that may not be needed. The idea is to use half the positive reference as the negative input to the internal op-amp that measures voltage in the muicrocontroller. That way, we can only measure say 2.048 to 4.096 volts, but that's the range we are interested in anyway. These cheap microcontrollers only have a 10-bit A/D converter, which means a resolution of 4 mV. By halving the range, we get 2 mV resolution, which may be more useful.

The bypass MOSFET and its LED are the same as for the analogue circuit. We can even PWM drive it if we want.

The opto is used between every cell. We considered and rejected the idea of using the fact that one cells positive is connected to the next cell's negative, because sometimes we want to isolate a group of cells, and there could briefly be 750 V where there was less than a tenth of a volt before. We could also have measured the link voltage drop that way, but it's just too dangerous, and noise spikes due to drive and regen current would likely cause problems.

Speaking of noise, we used TJ's idea of two outputs for complementary drive. Basically, in the LED off state, the LED gets reverse biased, to make sure it is off. It will take at least twice the noise to turn it on from being reverse biased. We found a clever way of doing the differential drive in software, and it fits into the MSP430's "info flash" area with exactly zero bytes to spare. More on the software later.

The voltage regulator is sadly needed; all these processors have a strict upper limit to how many volts they'll take. The regulator on the 12 V repeater is needed because the optos can't take 12 V of reverse bias, and we want the drive voltage to be about the same as for non-repeated data.

The comms data is strictly single directional. Every byte received by a BMU is echoed (not bit for bit, so that timing errors don't accumulate) to the next in line. We have a clever scheme for addressing individual cell BMUs despite this behaviour.

The layout of the comms cables bothered us for a while. No matter where we put the comms cables, they always ended up potentially covering some LEDs, because of course in a linear array of cells, the orientation of the BMU boards alternates.

We somehow came up with the crazy idea of having two "isomers" of the board: one with the positive terminal on one side, and the other with the positive terminal on the other side. That way, the LEDs don't alternate, and all the comms cables are very short. But we didn't want to maintain two copies of the board. We came up between us with this arrangement:

Image

[Edit: image updated to revision 28]

Note how the processor (the green blob with all the red wires coming from it) is on the left with the negative terminal on one board, and on the right still with the negative terminal on the other. To generate the other "isomer", we literally make a selection of the middle of the board, deselect a few pieces of text and two pads, do a rotate of 180 degrees about the origin (which is the middle of the board), and move one via. That's it. The board is designed with careful symmetries and careful symmetrical placement of vias and tracks so that it works the same either way around. The only downside of this is a ground and VDD heavy track, one of which is unused in one orientation.

We've actually codified the rotation procedure as a set of steps, and it is tagged at the bottom of the schematic as a multi-line text box (not shown above).

Note the vast tracts of land between some parts of the circuit and the rest. This is not because we ran out of things to put there (!!); it's for isolation between parts of the circuit that could have over 750 VDC between them. We have four slots in the boards (two straight, and two "horse shoes") that help with isolation.

These digital boards are slightly (10/1000") taller than the analogue boards. We just couldn't sneak some of the tracks past the many connectors at the edges without violating clearance from the board edges.

The 3-terminal JP5 is for initial JTAG programming of the BMUs' processors (and possibly post disaster reprogramming). Once programmed with our bootstrap loader (BSL), we should be able to reprogram all cells with new software without touching the BMUs. All that software is written and tested (but only on a development board with one processor so far).

Last but by no means least, please let me thank the various contributors to this design. I've already mentioned Tritium James, who posted a simple digital board months ago and challenged us to make an analogue circuit that had as few components. Well, we now have a lot of components, but a lot of features as well.

Thanks also to Neville for various ideas, and Neville we have nothing against AVRs, we just went with what we are most familiar with. Also Acmotor, of course, for the inspiration for the original analogue BMS board. And I guess to National Semiconductor, for the application note that his board was based on. And of course all the others that contributed ideas here and there.

So... who wants to be first to shoot down this design with some obvious flaw that we've missed?   Image

Image

Edit: moved schematic to the end of the post
Edit: updated to revision 21
Edit: updated to revision 22
Edit: updated to revision 23
Edit: updated to revision 28
Last edited by coulomb on Mon, 26 Apr 2010, 05:43, edited 1 time in total.
Nissan Leaf 2012 with new battery May 2019.
5650 W solar, PIP-4048MS inverter, 16 kWh battery.
1.4 kW solar with 1.2 kW Latronics inverter and FIT.
160 W solar, 2.5 kWh 24 V battery for lights.
Patching PIP-4048/5048 inverter-chargers.

Nevilleh
Senior Member
Posts: 773
Joined: Thu, 15 Jan 2009, 18:09
Real Name: Neville Harlick
Location: Tauranga NZ

Weber and Coulomb's MX-5

Post by Nevilleh » Mon, 08 Mar 2010, 12:36

For some reason, I can only see the LH half of the circuit diagram.

And I don't own shares in Atmel! The reason I use their chips is that they are powerful, cheap (as chips?) and I have all the development tools for them. If you have the tools for others, then they are the logical choice.

I'm still writing software for mine, been fighting with byte stuffing, CRC generation and the like. I have some good, efficient routines for those functions now (in C) if you need anything like that.
And waiting for a response on my blown up LogiSystems controller.....

I read an interesting article on ZEVA's site about a Curtis 123 that blew up in a like manner. (Logisystems is supposed to be a copy). Ian surmised the cause of the blow-up is the disparity in track lengths for the gate drive. About 50 mm for the fets nearest the driver and 300 mm for thos e furthest away. Hence the near ones turn on a bit sooner and so carry the full current for a few microseconds. Which is all it takes to melt 'em!

User avatar
coulomb
Site Admin
Posts: 3645
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Weber and Coulomb's MX-5

Post by coulomb » Mon, 08 Mar 2010, 14:43

Nevilleh wrote: For some reason, I can only see the LH half of the circuit diagram.

You may need to use the scrollbar at the bottom of the post. It's a long post, so unfortunately the scrollbar is a long way down the page (so you need the vertical scrollbar to get to the horizontal scrollbar).

Here is a smaller version; I hope it's readable.

Image

Edit: despite bad preview, this seems to work.
Edit: there is a scrollbar, but it's a long way down.

Edit: the above is out of date now; see above for revision 23, which should be easier to read now.
Last edited by coulomb on Sun, 14 Mar 2010, 06:54, edited 1 time in total.
Nissan Leaf 2012 with new battery May 2019.
5650 W solar, PIP-4048MS inverter, 16 kWh battery.
1.4 kW solar with 1.2 kW Latronics inverter and FIT.
160 W solar, 2.5 kWh 24 V battery for lights.
Patching PIP-4048/5048 inverter-chargers.

User avatar
coulomb
Site Admin
Posts: 3645
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Weber and Coulomb's MX-5

Post by coulomb » Mon, 08 Mar 2010, 14:51

Neville: I moved the schematic to the bottom of the post. Is that easier to read?
Nissan Leaf 2012 with new battery May 2019.
5650 W solar, PIP-4048MS inverter, 16 kWh battery.
1.4 kW solar with 1.2 kW Latronics inverter and FIT.
160 W solar, 2.5 kWh 24 V battery for lights.
Patching PIP-4048/5048 inverter-chargers.

Nevilleh
Senior Member
Posts: 773
Joined: Thu, 15 Jan 2009, 18:09
Real Name: Neville Harlick
Location: Tauranga NZ

Weber and Coulomb's MX-5

Post by Nevilleh » Mon, 08 Mar 2010, 15:00

Yes, that's much better, I can see the whole thing now.
I'll have a good look at it.

Nevilleh
Senior Member
Posts: 773
Joined: Thu, 15 Jan 2009, 18:09
Real Name: Neville Harlick
Location: Tauranga NZ

Weber and Coulomb's MX-5

Post by Nevilleh » Mon, 08 Mar 2010, 15:26

Yes, that looks quite neat.
What voltage do you set the regulator for the micro to? I wonder if you actually need that with the micro spec'd to run from - what, about 1.5V to 3.6V?
I like those low threshold fets too - are they expensive? Have you costed out the board yet?
I think having to run a separate 12v supply is a bit of a pain, just for the comms. I wonder if a small boost converter running off the cell voltage might be a better way to do it? I like your "poor man's rs485" too!
Looks like considerable thought has gone into it so far, well done.

Edit: The scroll bar has now magically appeared in the original post! It wasn't there before, I swear!
Last edited by Nevilleh on Mon, 08 Mar 2010, 04:28, edited 1 time in total.

Tritium_James
Senior Member
Posts: 683
Joined: Wed, 04 Mar 2009, 17:15
Real Name: James Kennedy
Contact:

Weber and Coulomb's MX-5

Post by Tritium_James » Mon, 08 Mar 2010, 15:36

I'd be exceedingly tempted to get rid of the extra 12V output section on the comms. Yes, if you don't have it the comms wires between sections are 'dangerous', but so are the high power connections. Treat the comms the same as you treat the power (1000V insulated wire, run in the same conduit, etc) and there shouldn't be any problems.

You should have a 100n cap close to the micro power pins. I can't remember if you need one on the VeREF+ pin for that part either but you should check.

A bit late now that you've done it, but why not use 0603 caps and resistors, it would make your PCB layout much easier.

If you're only using one A/D channel there's a variant of that part that has a 16-bit ADC on it. Maybe consider that option if you're worried about resolution?

User avatar
coulomb
Site Admin
Posts: 3645
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Weber and Coulomb's MX-5

Post by coulomb » Mon, 08 Mar 2010, 15:52

Nevilleh wrote: I'm still writing software for mine, ... I have some good, efficient routines for those functions now (in C) if you need anything like that.
Thanks, but our software is in assembler (for the boostrap loader, BSL) and Forth (main flash code, not complete yet).

In 256 bytes, less a few calibration bytes, we've fitted serial read and write functions, and a main loop that looks for a 3-byte "password" to start the erase and flash writing process, and code for the erase/flash write. We couldn't fit a proper CRC in there, so we have a simple 8-bit XOR checksum (apparently slightly better than an 8-bit addition sum). There is also logic for whether to call the main flash with a copy of the received byte. We found we didn't have space for interrupt handling; it's all timing loops. Interrupt code seems to take more space with all the accesses to special registers, which take an extra 2 bytes for the address.
And waiting for a response on my blown up LogiSystems controller.....

I read an interesting article on ZEVA's site about a Curtis 123 that blew up in a like manner. (Logisystems is supposed to be a copy).

Yes, I've read that some time ago. You'd think that a big company like Curtis, selling lots of product, would figure out that failure mode by now. I wonder if Logisystems copied this design error as well...
Nissan Leaf 2012 with new battery May 2019.
5650 W solar, PIP-4048MS inverter, 16 kWh battery.
1.4 kW solar with 1.2 kW Latronics inverter and FIT.
160 W solar, 2.5 kWh 24 V battery for lights.
Patching PIP-4048/5048 inverter-chargers.

User avatar
woody
Senior Member
Posts: 1712
Joined: Sat, 21 Jun 2008, 02:03
Real Name: Anthony Wood
Location: Mt Colah

Weber and Coulomb's MX-5

Post by woody » Mon, 08 Mar 2010, 15:53

Are you breaking the pack with contactors? - you could break the comms with aux. relays.
What's your charging plan? One string?
Planned EV: '63 Cortina using AC and LiFePO4 Battery Pack

User avatar
coulomb
Site Admin
Posts: 3645
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Weber and Coulomb's MX-5

Post by coulomb » Mon, 08 Mar 2010, 16:09

Tritium_James wrote: Treat the comms the same as you treat the power (1000V insulated wire, run in the same conduit, etc) and there shouldn't be any problems.
Thanks for the comments, James. Wouldn't you want to keep the comms wires separate from the power cables? Since they will be radiating serious electromagnetic interference?
You should have a 100n cap close to the micro power pins.
We have a 1000n about 40 mm away, I was hoping that would be good enough. But I take your point; nothing is too much in the way of bypassing, and with all the noise that there will be... we'd better try and squeeze it in.
I can't remember if you need one on the VeREF+ pin for that part either but you should check.
Oh, that sounds familiar now. I should definitely check.
A bit late now that you've done it, but why not use 0603 caps and resistors, it would make your PCB layout much easier.
Yes, we found the larger components a lot easier to hand solder. But we might consider that option now...
If you're only using one A/D channel there's a variant of that part that has a 16-bit ADC on it. Maybe consider that option if you're worried about resolution?

Yes, it's the MSP430F2013, the same as we have on the development boards. But the conversion is quite slow. It's still an option; we can populate one prototype board with a 2012 and another with a 2013 and see what is better. Continuous conversion would be OK for speed, except we want to watch temperature as well as voltage. That's why the processor is so close to the negative terminal. So we'd be switching from one analogue input to the other all the time, and waiting hundreds possibly close to a thousand milliseconds for it to settle and convert.
Last edited by coulomb on Mon, 08 Mar 2010, 09:46, edited 1 time in total.
Nissan Leaf 2012 with new battery May 2019.
5650 W solar, PIP-4048MS inverter, 16 kWh battery.
1.4 kW solar with 1.2 kW Latronics inverter and FIT.
160 W solar, 2.5 kWh 24 V battery for lights.
Patching PIP-4048/5048 inverter-chargers.

Tritium_James
Senior Member
Posts: 683
Joined: Wed, 04 Mar 2009, 17:15
Real Name: James Kennedy
Contact:

Weber and Coulomb's MX-5

Post by Tritium_James » Mon, 08 Mar 2010, 16:16

I don't think there will be too much noise in your system, you're not using a crappy DC brushed controller. I'd be quite surprised if your industrial drive radiated or conducted anything too serious at all, actually. They appear to have an appropriately rated amount of DC bus caps and input filtering. Even with noise, your comms scheme will be very robust, and highly unlikely to be susceptible to it.

Nevilleh
Senior Member
Posts: 773
Joined: Thu, 15 Jan 2009, 18:09
Real Name: Neville Harlick
Location: Tauranga NZ

Weber and Coulomb's MX-5

Post by Nevilleh » Mon, 08 Mar 2010, 16:56

Yes, everyone thinks that a proper CRC check involves many bytes! But it doesn't have to - and yet still be fast. Here's a way of doing it in nibbles that only requires a 32 byte lookup table. I took it from a fellow called David Schwaderer ("C Programmers Guide to NetBIOS, IPX and SPX", p 231). Its as concise as I have ever seen and pretty fast too. Maybe you can fit this in - should be easy enough to rewrite in assembler or even that other rude word you mentioned.
I wrote a version in 8052 assembler some years ago.
This is the CCITT one, but if you want to use a different algorithm you need only change the pre- and post- conditioning - and the table.

const int CRCTable[16]=
{0x0000, 0x1081, 0x2102, 0x3183, 0x4204, 0x5285, 0x6306, 0x7387,
0x8408, 0x9489, 0xA50A, 0xB58B, 0xC60C, 0xD68D, 0xE70E, 0xF78F}
;


uint16_t GenerateCRC(Length, TxtPtr)
     uint8_t Length;
     char     *TxtPtr;
     {
          char TempChar;
          uint8_t i, index;
          uint16_t CRCTemp=0xFFFF;//preconditioning byte
          
          for(i=0;i<Length;i++)
               {
               TempChar = *TxtPtr;
               index = ((CRCTemp^TempChar)& 0x000F);     //isolate low order nibble
               CRCTemp = ((CRCTemp>>4)& 0x0FFF)^CRCTable[index];//apply it
               TempChar>>=4; //stage the next 4 bits
               index=((CRCTemp^TempChar)&0x000F); //isolate low order nibble
               CRCTemp=((CRCTemp>>4)&0x0FFF)^CRCTable[index];
               }
               return ~CRCTemp;//CCITT bit inversion (post conditioning)
     }     

Last edited by Nevilleh on Sat, 13 Mar 2010, 07:26, edited 1 time in total.

User avatar
weber
Site Admin
Posts: 2572
Joined: Fri, 23 Jan 2009, 17:27
Real Name: Dave Keenan
Location: Brisbane
Contact:

Weber and Coulomb's MX-5

Post by weber » Mon, 08 Mar 2010, 19:17

Tritium_James wrote: I'd be exceedingly tempted to get rid of the extra 12V output section on the comms. Yes, if you don't have it the comms wires between sections are 'dangerous', but so are the high power connections. Treat the comms the same as you treat the power (1000V insulated wire, run in the same conduit, etc) and there shouldn't be any problems.
OK. But what about the very last cell board, that transmits back to the master (a laptop with a USB to RS232/422 adapter)? Won't it be best to have an isolated output from it?

Yes Woody, we will have breakup contactors, but we hope to charge in a single string using the industrial VF drive to regen off 3 phase mains via 3 inductors, or off the motor being idled as a rotary phase converter off single phase mains.

Could have little relays to cut off unisolated comms too, but it would be nice to still be able to talk to all the cells when the pack is isolated power-wise.
You should have a 100n cap close to the micro power pins.
Oops! The reg (and hence its output stability cap C2) gradually crept further and further from the micro. Thanks.
I can't remember if you need one on the VeREF+ pin for that part either but you should check.
Good point. Coulomb checked. We don't need one. Only on the 2013, the one with the 16 bit sigma-delta (sloooooow) ADC.
A bit late now that you've done it, but why not use 0603 caps and resistors, it would make your PCB layout much easier.
You should know by now that we like to do everything the hard way. Image

Actually we only have to do the layout once, but we have to assemble the components onto the board 228 times, so we want to make life easy for ourselves and avoid components that can be mistaken for specks of dirt. Image
[Edit: spelling]
Last edited by weber on Mon, 08 Mar 2010, 08:19, edited 1 time in total.
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

Tritium_James
Senior Member
Posts: 683
Joined: Wed, 04 Mar 2009, 17:15
Real Name: James Kennedy
Contact:

Weber and Coulomb's MX-5

Post by Tritium_James » Mon, 08 Mar 2010, 19:29

Since you'll need some little adapter board to convert your differential comms output to something the PC can handle, it might as well have an opto on it and look like the input stage for the next battery node. Then you don't need anything special in the transmit circuit for any of your nodes.

I don't see the need to isolate this signal in particular. Just make sure the connector you use on it can handle the voltage, and that your adapter board has the appropriate clearances etc. Maybe design the board to fit in some standard off-the-shelf enclosure, so you can't touch things accidentally?

Squiggles
Senior Member
Posts: 742
Joined: Wed, 22 Apr 2009, 03:19
Real Name: Neil
Location: Newcastle NSW

Weber and Coulomb's MX-5

Post by Squiggles » Mon, 08 Mar 2010, 22:41

Do the port pins have internal pull ups?

User avatar
weber
Site Admin
Posts: 2572
Joined: Fri, 23 Jan 2009, 17:27
Real Name: Dave Keenan
Location: Brisbane
Contact:

Weber and Coulomb's MX-5

Post by weber » Mon, 08 Mar 2010, 23:44

Nevilleh wrote: Yes, that looks quite neat.
What voltage do you set the regulator for the micro to? I wonder if you actually need that with the micro spec'd to run from - what, about 1.5V to 3.6V?
I like those low threshold fets too - are they expensive? Have you costed out the board yet?
I think having to run a separate 12v supply is a bit of a pain, just for the comms. I wonder if a small boost converter running off the cell voltage might be a better way to do it? I like your "poor man's rs485" too!
Looks like considerable thought has gone into it so far, well done.

Thanks for the kind words Neville. The reg is 2.5 V. We definitely need it since the micro has abs max 3.6 V. It will operate down to 1.8 V, so reg is LDO, but can only program flash down to 2.2 V. I think those FETs are pretty cheap. Search on "PMV31XN" at Mouser.com (or was it Digikey or Farnell?). We are using them for 1 amp. Haven't costed it properly yet, but expect it to be cheaper than our analog design and well under our $10 budget for parts inc PCB. The boost converter is not a bad idea. You can get those tiny isolated converter modules. I'll look into it. It will be a "poor man's RS422" in our case since it is only point-to-point. It was TJ's idea. It will be chinese whispers from the master through 228 BMUs and back to the master (the BMM?). That way the master gets to see if the packet was corrupted and can resend it.
Squiggles wrote: Do the port pins have internal pull ups?

Yes. About 36k. Programmable as pullups or pulldowns, or not. Well spotted (the lack of an external one on the RX opto transistor).
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

User avatar
weber
Site Admin
Posts: 2572
Joined: Fri, 23 Jan 2009, 17:27
Real Name: Dave Keenan
Location: Brisbane
Contact:

Weber and Coulomb's MX-5

Post by weber » Tue, 09 Mar 2010, 00:54

Nevilleh wrote: Yes, everyone thinks that a proper CRC check involves many bytes! But it doesn't have to - and yet still be fast. Here's a way of doing it in nibbles that only requires a 32 byte lookup table. I took it from a fellow called David Schwaderer ("C Programmers Guide to NetBIOS, IPX and SPX", p 231). Its as concise as I have ever seen and pretty fast too. Maybe you can fit this in - should be easy enough to rewrite in assembler or even that other rude word you mentioned.

That CRC code is cool. But sadly we even looked at some types of checksum intermediate in error detection and code complexity between a proper CRC and a simple XOR. These were the "internet checksum" and "Fletcher's checksum". But we had to reject these too as they would have required a whole 18 bytes of code! In the end we could only afford 6 bytes. 2 for the xor instruction, 2 for the test for zero, and 2 for the jump.

We have done some serious assembly-language optimisation to fit our serial bootstrap loader into a special 256 byte block of flash (including general initialisation code, a 3-times oversampling software UART, password detection, watchdog checking and various bits of calibration data. This is so it can survive when called upon to erase and rewrite the main 2k of flash with data received from the serial input, while passing it on to the next BMU to do the same. The main 2k of flash will contain the packet interpreter and code for doing voltage and temperature measurements and operating the bypass resistor and optional fan. That part's not finished yet.

Coulomb has even written and tested code that should let us update the bootstrap loader serially on all BMUs at once, if we ever need to. It works by having the existing bootstrap loader load what it thinks is a new version of the packet interpreter into the main 2k of flash. Little does it suspect it has just uploaded the instrument of its own demise -- a bootstrap loader loader. Or is it a bootstrap bootstrapper? Anyway it contains within it a copy of a new bootstrap loader.

The first time the existing bootstrap loader passes it a byte to interpret, it says "gotcha", and erases and replaces the bootstrap loader in its special 256 bytes of flash. Then the new bootstrap loader is used to reload a proper packet interpreter into the main 2k again.

So Forth is a rude word eh? We can't fit a full Forth outer interpreter and compiler into 2k so we use a bunch of macros in the assembler on the host PC to compile Forth to "tokens" or "bytecode". i.e. a call to a Forth routine is coded as a single byte. This should allow us to write compact code, although it will be slow to interpret. There's a lookup table on the target that gives the actual address of the routine, with the high bit set to indicate whether it is written in machine code or bytecode. In the latter case the interpreter is called recursively until it eventually bottoms out in a machine code routine.

The packets we will send from the master will also consist of this Forth bytecode to be interpreted by the BMUs.

The bytecodes are assigned in such a way that they are memorable to humans. e.g. the bytecode for the Forth "AND" routine is ASCII "&". In fact you can memorise enough of these bytecodes-as-ASCII-characters, and the end-of-packet character is a carriage return, so if you turn off checksumming you can just type commands at the packet interpreter in bytecode using a terminal emulator. This is like a Forth in which every routine has a one-character name. So I call it "Wunth". How's that for a rude word?
[Edit: Added "ASCII"]
Last edited by weber on Mon, 08 Mar 2010, 15:11, edited 1 time in total.
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

Squiggles
Senior Member
Posts: 742
Joined: Wed, 22 Apr 2009, 03:19
Real Name: Neil
Location: Newcastle NSW

Weber and Coulomb's MX-5

Post by Squiggles » Tue, 09 Mar 2010, 01:19

Strike me pink, I have not heard any mention of Forth for 20+ years, thought it was extinct. Unlike Cobol that we just wish was extinct.

Nevilleh
Senior Member
Posts: 773
Joined: Thu, 15 Jan 2009, 18:09
Real Name: Neville Harlick
Location: Tauranga NZ

Weber and Coulomb's MX-5

Post by Nevilleh » Tue, 09 Mar 2010, 12:10

weber wrote:
Squiggles wrote: Do the port pins have internal pull ups?

Yes. About 36k. Programmable as pullups or pulldowns, or not. Well spotted (the lack of an external one on the RX opto transistor).


I don't know what data rate you are using, but the micro internal pull-up is likely much too high in value for the opto. I found I had to use about 1k5 to get it to work at 9600 Baud. That was with a 4N37. (The turn-off time is way too long.)

256 bytes isn't much memory to put a bootstrap loader in!
You should chuck that F**@! away and do it all in assembler if you are that strapped. Even C would be better! I wonder if GCC supports that micro?

Another good reason for using an AVR - 8k of flash (or more) lots of RAM and also EEPROM.
Last edited by Nevilleh on Tue, 09 Mar 2010, 01:18, edited 1 time in total.

User avatar
weber
Site Admin
Posts: 2572
Joined: Fri, 23 Jan 2009, 17:27
Real Name: Dave Keenan
Location: Brisbane
Contact:

Weber and Coulomb's MX-5

Post by weber » Tue, 09 Mar 2010, 15:24

Nevilleh wrote:I don't know what data rate you are using, but the micro internal pull-up is likely much too high in value for the opto. I found I had to use about 1k5 to get it to work at 9600 Baud. That was with a 4N37. (The turn-off time is way too long.)
Good point! Yes we're using 9600 baud. I'll add an external resistor to the PCB. Thanks.
256 bytes isn't much memory to put a bootstrap loader in!
You should chuck that F**@! away and do it all in assembler if you are that strapped. Even C would be better! I wonder if GCC supports that micro?
The BSL was done entirely in assembler. No Forth. We have a free C compiler for the MSP from Texas Instruments, in the same integrated development environment as the assembler. We just choose not to use it because (a) we can write more compact code in assembler, and (b) MSP430 assembler is fun to write, as it's a 16-bit CPU and all addressing modes work with all instructions and all registers. It's "orthogonal", as they say. The architecture is basically that of the classic PDP-11 except they sacrificed a destination address-mode bit in the instruction word so they could access twice as many registers. Similar to a Motorola 68000, but without the distinction between data regs and address regs.
Another good reason for using an AVR - 8k of flash (or more) lots of RAM and also EEPROM.
We could of course have used an MSP430 with more memory too. But choose to keep it cheap and small with wide-spaced pins (but in a quad-flat-pack so we can use the thermal pad to do cell temp measurements). The only AVR contender was the AT-tiny25V that you recommended. That also has 2k of flash. It would have done just as well. We have both used AVRs in the (distant) past. But in the end we went for the MSP because of two very minor points: (a) one of us had recent experience with the MSP, and (b) the quad-flat-pack AVR had more and closer pins than the quad-flat-pack MSP. It seems odd that something in an 8 pin DIP or SOIC has to have 20 pins when put in a QFN package.

It seems that people either fall in love with Forth, or they loathe and detest it. I'm not sure why that is. And it's debatable whether we should call this thing Forth, since it doesn't have the usual dictionary and interactive compiler. But it certainly is a virtual dual-stack-machine that lets us write compact code in reverse-Polish form.

We needed a command interpreter anyway, to interpret the command packets from the master. We get that for free, since we can just send the same stack-machine bytecode as commands from the master.
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

Post Reply