Paul & Sabrina's cheap DIY 144v motor controller

[MPaulHolmes]

well, I got the software fixed! ya! I think I had been using different resistor values for the voltage divider on the old control board.
Now the PWM behaves just as it should. This is (as far as I know) a perfectly functional control board! ya!

-Paul

[MPaulHolmes]

I don't seem to be able to explain properly. Maybe someone else should try?

My answer would be:

(for a new local working copy):

- "Checkout" the project to the local disk
- If you don't have local modifications continue to work on the trunk/HighVoltageController.c file as it came from the svn.
- If you allready have modifications since your last commit replace the entire content of trunk/HighVoltageController.c with your code. Then "SVN Update" (will merge the modifications from the svn with your own). Then "SVN Commit" will publish your modifications to the svn.
- continue to work on this file from now on. Always do "update" before changing thinks and commit when your are satisfied with your changes.

(for an already existing local copy):
- Just do "SVN Update"
- Continue to work on it

OK, checkout isn't an option now anywhere that I look, so I can't get past step 1 above.

tps report... pc load letter?

The directory that I downloaded a while back used to have a little green thing on it, and now it's red. I bet that's significant.

I think I just sent HighVoltageControllerImproved.c (which is the very much unimproved test version of the software, with the 2 numbers changed so that the pwm signal works.)

HEY! I JUST DOWNLOADED A 30 DAY FREE TRIAL OF SOME TERMINAL PROGRAM, AND I HAVE THE CURRENT DISPLAYING ON SCREEN! ya!
That's cool. Hmm.. There are a lot ofpossibilities with that!

[wjdennis]

Originally Posted by dcb

Putting electricity into and out of a SLA battery is about %75-%85 efficient (more current is less efficient), and that does not include any charging equipment. Using a battery to charge a battery doubles those losses.

'Cept, see, these babies are them there lithium-ion cells. Coulombically efficient. Hardly any losses when not shunting (which I wouldn't be during driving).

So I asks ya agin, where are all them losses I keep hearing so much about.

Bill

[MPaulHolmes]

Fran the man, that's not from a garbage can is sending me his boot loader code that is heavily commented so that people won't need an STK500 to help with programming! They'll only need to hook up the control board to the serial port of a laptop or something. ya!

[nubie]

@wjdennis

I think that is a solution to something that isn't a problem, just pick a battery pack that will accept the draw you are placing on it.

Wouldn't it be simpler and cheaper to use batteries rated for the draw placed on them, instead of a second set of more expensive batteries?

I notice that White Zombie uses Lead acid, and does pretty well (I don't think you are planning on using twin WARP motors to drag race.)

You get a loss of energy as the electrons travel (through a semi-conductor, not a super conductor), and as the (1st) battery discharges, and as it recharges the 2nd battery. Just using the energy in the motor would make it so much simpler, and you would need an even larger battery pack to make up for the losses in a dual-pack system. If you could make friends with somebody living at the beginning of your uphill and have a battery pack waiting to swap it would be good, or even a trailer battery pack (although now you are moving more mass uphill, it would be a charged battery, perhaps with a higher draw rating.)

All of this talk is way off-topic though.


Way to go Paul! Still watching with interest, the power section looks terrific, I like the bend on the legs, looks like plenty of contact on the solder pads.

I wonder about the Cat5 connection, since you already have an opto-isolator couldn't you exchange that for a Fiber-optic transmitter jack (and matching reciever), I can get them out of hi-fi equipment for nothing, and they sell fiber optic cable at wal-mart!

That way you could mount the controller inside while keeping the high voltages safely away.

That is all cosmetic though, as long as it works the packaging is up to the end-user.

[charlie_fd]

Originally Posted by MPaulHolmes

I don't seem to be able to explain properly. Maybe someone else should try?

My answer would be:

(for a new local working copy):

- "Checkout" the project to the local disk
- If you don't have local modifications continue to work on the trunk/HighVoltageController.c file as it came from the svn.
- If you allready have modifications since your last commit replace the entire content of trunk/HighVoltageController.c with your code. Then "SVN Update" (will merge the modifications from the svn with your own). Then "SVN Commit" will publish your modifications to the svn.
- continue to work on this file from now on. Always do "update" before changing thinks and commit when your are satisfied with your changes.

(for an already existing local copy):
- Just do "SVN Update"
- Continue to work on it

OK, checkout isn't an option now anywhere that I look, so I can't get past step 1 above.

tps report... pc load letter?

The directory that I downloaded a while back used to have a little green thing on it, and now it's red. I bet that's significant.

I think I just sent HighVoltageControllerImproved.c (which is the very much unimproved test version of the software, with the 2 numbers changed so that the pwm signal works.)

HEY! I JUST DOWNLOADED A 30 DAY FREE TRIAL OF SOME TERMINAL PROGRAM, AND I HAVE THE CURRENT DISPLAYING ON SCREEN! ya!
That's cool. Hmm.. There are a lot ofpossibilities with that!

Paul,

It's great that you have fixed the software! The code you are using for serial link (chris stuff) is converting from hex to ASCII inside the uC witch in my opinion is a waste of uC cycles (the conversion can be done in the client on the computer). Also, you are using the classic "wait for transmission ready" algorithm so every second you will stop the program to do the ASCII conversion (3 characters) and the transmission of 5 characters. Have you taken a look at the interrupt based transmission algorithm I'm using? Basically every second you could just fill a buffer with the values you want transmitted and enable the relevant interrupt. The interrupt will be fired each time the data register is ready to receive the next character letting the program do it's job during the actual transmission.

I gave up on the idea of working together on the same code via svn. in the version I was using I'll adjust the code manually to match your latest upload , and let only the (improved) serial transmission code from my version. It looks like we also have a java client for it now (thank you roverT).

[dcb]

Originally Posted by wjdennis

'Cept, see,...

ya, another thread maybe, and try to disclose your assumptions.

[dcb]

Originally Posted by charlie_fd

...is converting from hex to ASCII inside the uC witch in my opinion is a waste of uC cycles (the conversion can be done in the client on the computer)...

If it is human readable then it isn't a waste of time, because more people will read it. Just because you know how to install a custom client does not mean everyone does. But most PCs/many PDAs etc have some sort of terminal program at their disposal (i.e. hyperterminal, whatever). So the target audience for this uart code that was coerced into existance becomes much larger.


P.S. Paul, I got rid of the bootloader on the guino for reliability purposes (and space too), just fyi. Had a few cases where the chip messed itself and it seemed like having code that is sitting around waiting to rewrite the chip was the likely culprit in flakey voltage conditions. I also disable spm commands in the fuses.

[dcb]

Other common programming options include the dirt cheap parallel isp programmer
http://ecomodder.com/forum/showthrea...mmer-7311.html and program with avrdude or somesuch

(couple resistors and an old parallel printer cable)

or the usbtinyisp, though its avrstudio integration is a bit hokey, it works fine with avrdude as well.

[wjdennis]

Originally Posted by dcb

ya, another thread maybe, and try to disclose your assumptions.

Guys, I'm not trying to be persnickety or contrary here. I asked a question that was on-topic, about the controller and its possible use as a charger. My follow-up questions were going to be able how to size the inductor so that when I built the controller I could test it as a charger, too. But I got responses about choosing the right battery pack and energy losses and pack swapping. I've already got my battery pack. My EV goes over 100 miles on a charge. I drive it 88 miles round-trip to work. It just has trouble with sagging on steep hills, and Lee Hart recommended the solution I mentioned, getting a small second pack that could handle the high-demand draws for hills, and have my existing pack supply a constant 70A. Paul's controller seems like a good solution since I'm planning on building one anyway.

Bill