High Voltage: The Fast Track to Plug In the Auto Industry A behind-the-scenes look at the robustly competitive race to dominate the market for electric cars.

So is the PAKTRAKR and CYCLE ANALYST necessary?

19 replies [Last post]
racermike39's picture
Offline
Joined: 11/15/2007
Posts:
Points: 127

According to what I have read here and on the product websites, it seems each provide features that are necessary for EV's, but using both can be pricey and will provide some redundancy.

Pro's of the Cycle analyst:
Volt/Amp & Speed readouts
control capability over the controller output.
accumulative data storage.

Cons:
no individual battery monitoring
no data logging or PC interface

Cycle analyst price (high current model)
$200

Paktrakr Pros:
Individual battery condition readout
volt monitor
data logging
computer interface
battery bay temp readout

Cons:
no speed readout
Amp readout costs $50 for sensor (not required if used with Cycle analyst, but if you want to data log Amps, you will need this)

Paktrakr cost:
EV600=$150
data logging and PC connection=$80
Total w/o Amp reading=$230
Total with Amp readout=$280

So for both systems, you are looking at $430-$480 bucks.

None of these are mandatory, but.... none? One? both?

Thanks in advance.

Mike.

__________________

Racermike
5 years ago I met Jesus and he total ruined my life. I have never been happier.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Offline
Joined: 12/22/2007
Posts:
Points: 211
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

I had both systems on my 1st Gen Zapino. Then I got the new 2nd Generation Zapino and
installed both systems there. After testing the new Zapino, I determined the speedometer is not as far off as the 1st gen. I also decided I did not need the
throttle amp control. I eventually took off the Cycle Analyst and use only the
Paktrakr to monitor pack voltage, individual voltage, amps and battery box temp.
I initially purchased the paktrakr with the amp module and the serial download port.
Now I do not plan to use the serial port. I did not even install it. During a range
test the paktrakr showed the decreasing black squares as I used up the charge until
it finally displayed the msg to charge the batteries. So for me the Paktrakr is
essential. The Cycle analyst is a great device, but in my case, not needed.

__________________

Robert Dudley
E-Scoot Tech

frodus's picture
Offline
Joined: 03/17/2008
Posts:
Points: 189
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

It doesn't take much... a little microcontroller and support electronics, shunt resistor, tach input and an LCD. I mean, each product is worth it because of the time and design and packaging that went into it.... But i see your point, each one falls a tad short of being a full featured product.

I'll see if the guys I'm working with want to maybe work on something that you guys can use.

In my opinion, it'd be cool to have an open source version with analog inputs, analog outputs (for throttle/etc), some switch inputs, and even some outputs for driving PWM outputs for lights and stuff. Maybe we can colaborate ideas. Programming it isn't hard, but getting enough people interested to make a run of boards can be difficult.

__________________

____________

Travis Gintz
1986 Honda VFR Conversion
www.evfr.net

reikiman's picture
Offline
Joined: 11/19/2006
Posts:
Points: 8448
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

I own an instance of both.

I would love for the featureset of both to be in one unit.

I would love to participate in an open source project related to this. My day job is in open source software.

__________________

- David Herron, Green Transportation Examiner, Green Transportation Info, The Long Tail Pipe, Torque News, electric race news, davidherron.com, 7gen.com, What is Reiki
- EVT 4000, Charger bike (rebuilt), Vego 600sx (rebuilt), Electrified Electra Townie
- Lectra motorcycle, 1971 Karmann Ghia

frodus's picture
Offline
Joined: 03/17/2008
Posts:
Points: 189
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

well, lets start it... I mean, a little PIC or AVR, an onboard DC-DC for various input voltages 36-72V? shunt inputs, tach input, 12 battery inputs? bus connector for daisychain, onboard character 4 line 20 character LCD... or we could go graphical.

I've got all the Pic Development stuff for a 40 pin pic... we just need to nail specs.

If people could, let us know of their desire for something like this, and any features they want to see. Logging? USB? Serial?

Would you want to remotely monitor batteries with each having their own module and communicate over CAN or 485 and add them on as you buy batteries? or would it be best to have a central unit with fixed amount of inputs? What about controller interface to things like Kelly or Alltrax through the serial port for monitoring?

What about temperature inputs from controller and motor? GPS serial input?

lets brainstorm, get ideas and come up with something. I mean, if someone wants to help, We can develop a board that fits the needs, and sell the boards only...

__________________

____________

Travis Gintz
1986 Honda VFR Conversion
www.evfr.net

e-commuter's picture
Offline
Joined: 01/20/2008
Posts:
Points: 52
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

I've been appreciating the serial logging device on the Pak Trakr. It may have even saved my batteries by making it clear that the chargers I was using were inappropriate.

At any rate, two things come to mind.
1. I'm not sure why the interface has to be serial. If you've got a laptop (as many of us do) you'll have to go out and buy a USB adaptor. Why not make the interface USB from the start?
2. It turns out that I have to take my laptop to the paktrakr in order to download data. I had assumed that I would be able to unplug the serial cord and carry it inside to download the data. For someone who only has a desktop, that could be a problem.

racermike39's picture
Offline
Joined: 11/15/2007
Posts:
Points: 127
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

Thanks for the feed back everyone.
I almost ordered the cycle analyst yesterday, but I changed my mind.
I think I am going to purchase the PacTrakr because I like the individual battery monitoring, and I agree that when charging, this information may be more useful than when riding. The data logging should reveal losses or gains in experiments with battery mfg's, aerodynamics, tire pressures etc.

The controller I am using is programable, so I can live without that feature from the CA.

The one feature I really wanted is the speed readout. I am going to start researching quality bicycle speed/odometers. For $20-$50 I should be able to come up with a good one that will be back lit, have trip functions etc.

This route will get me from $480 down to $320 or so.

Thanks again all.

Mike K.

__________________

Racermike
5 years ago I met Jesus and he total ruined my life. I have never been happier.

Offline
Joined: 11/21/2006
Posts:
Points: 181
Open Source

frodus wrote:

voltages 36-72V?

You might find some li-ion bikes approaching 80V. Are you planning on handling li-ion? New mass manufacturing lines are coming on line expecting to bring prices down. If yes then there are more batteries to monitor.

Mik
Mik's picture
Offline
Joined: 12/11/2007
Posts:
Points: 3709
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

frodus wrote:

well, lets start it... I mean, a little PIC or AVR, an onboard DC-DC for various input voltages 36-72V? shunt inputs, tach input, 12 battery inputs? bus connector for daisychain, onboard character 4 line 20 character LCD... or we could go graphical.

Could it be designed to use a PDA phone with a trans-reflective touchscreen as instrument panel?

By the time you are finished making it there should be plenty of old PDA's lying around waiting for an open-source OS reboot!

And consider making it flexible towards the top end of voltage requirements - they seem to be going up and up...

Mr. Mik

__________________

This information may be used entirely at your own risk.

There is always a way if there is no other way!

andrew's picture
Offline
Joined: 11/28/2006
Posts:
Points: 1361
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

Would any sort of battery balancing integrated be possible?

frodus's picture
Offline
Joined: 03/17/2008
Posts:
Points: 189
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

The specifications I had above were merely brainstorming, by no means a limitation.

When I said 36-72, I was referring to having an onboard DC-DC converter... so the guys that have bikes and go-karts who don't need to power accessories, can run a monitor without buying a DC-DC converter. As far as sensing the battery pack voltage ..there will likely need to be voltage tiers, due to the voltage sensing input to the uC. If its up to 48, you might have one design, 36-72 another, 60-120 another... You may be able to chose a design that goes up to 200V, but the resolution goes away. If you have something between smaller numbers, it provides more resolution... which is needed in our case. It may be as simple as changing resistor values, but we need to keep resolution in mind.

Also why would "monitoring" LiFePo be any different than the lead acid? You chose a warning voltage level for each bat, and a "turn off the controller now before they fry" level for each bat. So far, we're talking about monitoring, not charging and balancing (i'll touch on that in a min).

As far as the PDA phone, I'm not sure about what their comm capabilities are... but I know I searched a while to find an affordable PDA (under 150) that had some sort of communications I could easily implement. Almost no PDA's (there's 2 I know of) have USB Host support. All are USB Client. This is an issue, because one must implement a USB Host on the monitor board, and have software on it to support PDA's. This may not be an issue, I stopped researching at that point because I knew RS232 was a viable option. I chose a Dell Axim. its cheap, easily available for 50-75 bucks, and its got Compact flash and a serial port. I can add ethernet via compact flash if I want, or I can add another serial port via CF. There are other protocols, but they get expensive to convert. Serial and ethernet were the easiest options to implement on either side, unless you want to design a custom LCD uC monitor with custom pages. I wanted the ability to use VB. Also, reprogramming the firmware on a PDA, unless its linux on SOME devices, its a long process to get the full functionality out of it. Use something canned and easy to implement. We could make the device have a small LCD for daily use, but for diagnostics, logging, etc... plug into a laptop or PDA. We could make it so a USB version is available, but also, a serial option for those with PDA's. Its just a USB chip onboard to convert to serial anyway.

Transflective may be good. Older Ipaq's are side lit and transflective and show up fairly well. I've got a Dell Axim X5, and its got plenty of visibility. I guess it would be up to trial and error.

Now, for the discussion on Battery Balancing. I can't talk a lot about that, because I'm working with Synkromotive on that same idea. I've got ideas, but can't mention much. But the answer is yes, its possible.

Keep the ideas coming. I might start a new thread ... we hijacked this one :)

Lets list bare minimum requirements first.... then wishlist... then pipedreams :)

Bare min:
-Speed sensor input able to deal with a 24V input (Some sensors are 24V).
-Two current sensors minimum, one for motor side, one for battery side.
-12 standard battery voltage inputs for monitoring. Maybe an add on card for additional. Maybe distributed add one at a time?
-Small LCD delivering fault status, level of each battery and a menu system for basic setup
-several menu buttons
-speaker/buzzer for warning sound when bats hit the warning level
-user setable warning level and cutoff level, with curves set for all bat types. Additional types could be firmware updated as they are tested.
-throttle input/output to adjust curves
-SOME data logging. Maybe a couple hours worth? 10 times a second to eeprom that can be read? Most EV's don't drive that long. Maybe write to a USB thumb drive? Compact flash? SD?
-Motor/controller/battery temp inputs? Maybe like 4 total? add on cards later?

__________________

____________

Travis Gintz
1986 Honda VFR Conversion
www.evfr.net

andrew's picture
Offline
Joined: 11/28/2006
Posts:
Points: 1361
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

Here's some ideas. Some of these may be too much for bar minimum, while others are probably easy to integrate:

Hardware:
-Flashing fault LED for any of the preset fault conditions warning (temperature, low voltage of any battery). With accompanying 3 short beeps two times when condition is first met.
-Flashing cutoff LED for when cutoff condition is met and cutoff has occurred.
-Cutoff override option for when you know a battery is bad, and just want to get home.
-Buzzer for 20% SOC with 2 long beeps. Then, 2 long beeps every 5% SOC drop from there.
-Ability to interface with controller keyswitch input for cutoff.
-Write to a USB storage device to log hundreds or even thousands of hours, and easily transfer this to a desktop.
-Charger cutoff via control of charger 120v input relay for when any battery voltage, or temperature goes too high. 20 short beeps, and display fault code. Resume charging after delay of 15 min for temperature, and one min for voltage.
-Preset charger max on time, and preset turning on charger for topping the batteries (like once weekly).
-Log all temperature inputs as well
-Can it data log faster than 10 times/sec for accuracy?
-Motor voltage in addition to battery voltage input and logging

Software:
-Vary cutoff voltage based on current as an option. This would allow for very high performance, but still with good cell damage prevention.
-Bar graph "fuel" gauge display with accompanying % level printed. This will be a function of whrs remaining.
-Display option of just battery with the lowest voltage
-When displaying individual battery voltages, identify them with B#
-Motor and battery current displayed side by side
-Group data logging by date/time for easy access
-Bar graph display of individual battery voltages so they all can be compared quickly. Auto arrange, or set arrangement. Adjustable parameter of either set voltage range, or auto range with best battery as maximum, and worst as minimum.

frodus's picture
Offline
Joined: 03/17/2008
Posts:
Points: 189
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

I'll put my comments in line:

-Flashing fault LED for any of the preset fault conditions warning (temperature, low voltage of any battery). With accompanying 3 short beeps two times when condition is first met.

Easy to do, but there's an LCD, put a fault code in the top corner. Beeps can be done with buzzer.

-Flashing cutoff LED for when cutoff condition is met and cutoff has occurred.

Use LCD for cutoff warning

-Cutoff override option for when you know a battery is bad, and just want to get home.

Good idea, also integrate into throttle so that the throttle cuts back too.

-Buzzer for 20% SOC with 2 long beeps. Then, 2 long beeps every 5% SOC drop from there.

easy to do

-Ability to interface with controller keyswitch input for cutoff.

This might be dangerous, but if overide is enabled then it wouldn't cutoff? Maybe something where it cuts back throttle and beeps until you turn it off. How could you overide while driving?

-Write to a USB storage device to log hundreds or even thousands of hours, and easily transfer this to a desktop.

Might not be hard, I need to look into USB host of memory devices via a uC

-Charger cutoff via control of charger 120v input relay for when any battery voltage, or temperature goes too high. 20 short beeps, and display fault code. Resume charging after delay of 15 min for temperature, and one min for voltage.

Well, thats another design altogether, because the BMS should be integrated into the charger. Ideally the BMS would have monitoring of the batteries and know what level they're at and shutoff. It would ideally have a uC onboard that would have an internal temp sensor for local sensing of the bat. As far as this discussion goes, lets keep it to monitoring. Charger/BMS design is another thing altogether. I know you COULD have something that cuts off though, but you'd also be sucking power to monitor while charging. Not a bad idea, but still something BMS and the charger should do.

-Preset charger max on time, and preset turning on charger for topping the batteries (like once weekly).

see above.

-Log all temperature inputs as well

if there's a monitor on each bat, then the uC would have an internal temp sensor that can be used with no extra hardware. If the monitor is mounted on top of the bat, this would give a good idea at temp. If its distributed, thats 1 input for each bat voltage, 1 for temp. 24 inputs right there. Plus currents, tach input... you're getting up there. Maybe 1 sensor for groups of 4 bats. But definately logging.

-Can it data log faster than 10 times/sec for accuracy?

Yes, but why? Is this thing supposed to be an oscilloscope? we've used 10 or 20 on a monitor that Synkromotive is desinging and its pretty good. Even for seeing spikes in overvoltage cutoff of the controller. I think you could increas the logging, but 12 bats voltage 100 times a second might load the uC a little, esp if its doing tach calcs, current calcs, logging, etc.

-Motor voltage in addition to battery voltage input and logging

Why would you ever use that? Its PWM'd, its going to jump all over the place. I just don't see where you'd use it. Its just not an importand piece of data.

Software:
-Vary cutoff voltage based on current as an option. This would allow for very high performance, but still with good cell damage prevention.

Not sure what you mean. If you mean, shutting off the contactor at certain voltages based on current... I don't know what that'd get you. If you mean, if the current draw is low, decrease the cutoff because the rate of discharge is lower?

-Bar graph "fuel" gauge display with accompanying % level printed. This will be a function of whrs remaining.

That could be integrated into a small LCD OR Display. When I say LCD, It could be either a Character, graphic. When I say Display I mean a PDA/Laptop/Custom interface via serial or USB.

-Display option of just battery with the lowest voltage.

Easy to do through menu's

-When displaying individual battery voltages, identify them with B#

Yeah, definately... If it was on a PDA, you could even have it overlay the location in the car of the battery.

-Motor and battery current displayed side by side
-Group data logging by date/time for easy access
-Bar graph display of individual battery voltages so they all can be compared quickly. Auto arrange, or set arrangement. Adjustable parameter of either set voltage range, or auto range with best battery as maximum, and worst as minimum.

All good ideas as well.

I'd want the LCD at a min (by line on a 4 line LCD):
* show Pack V, Pack % Pack A, Motor A, Speed (MPH or KMH), motor temp, avg pack temp and "Distance til empty" (based on current amp draw and pack rate of discharge)
*show fault code if present, low voltage warning, over temp warning, etc
*show B#, B% and a fill of a character as a bargraph, skip a space, and go to the next bat.
*show continuation of battery voltages.

__________________

____________

Travis Gintz
1986 Honda VFR Conversion
www.evfr.net

jdh2550_1's picture
Offline
Joined: 07/17/2007
Posts:
Points: 2338
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

I'll read this all in detail later tonight but wanted to add my enthusiasm for an open source product like this. Like reikiman I can also offer to help.

I haven't read closely but here's a few thoughts (sorry if they're already covered):
- I think separating the control logic from the number of batteries being monitored is a must to allow folks to gracefully add more batteries or switch chemistries with minimal cost (i.e. adding 1 or 2 12V batteries to boost power or switching from PbA 12V packs to LiFePO4 3.2V packs (or is it 3.4 I can never remember!)
- I think the control aspects of the Cycle Analyst are very interesting - especially to give a "reserve tank" capacity.
- On board logging of data to an SD card would be cool - and I think pretty "easy" to do from what I've seen of folks creating small data loggers (check out sparkfun.com for the basic idea)
- Bluetooth or USB would be "cool" (and useful) but should be secondary to plain old RS232 - for widest support
- Having a separate "head unit" that was really just that (i.e. just control not processing) would facilitate allowing folks to choose a simple head unit like the CA and PT come with or to use a PDA, cell phone or similar.
- Also integrating a charge management system like Bob and Gary's design on endless-sphere would be very cool. It might be too much to aim for - but a lot of the monitoring required is already needed for this so one part says why not take advantage of that? A modular design to allow a CMS to be added to this system would be the best of all worlds.

Open source would be great. Having someone willing to build these for none electronics folks (and making a reasonable profit) would also be great.

Just my 2cents worth. I hope to read in more detail later tonight.

__________________

John H. Founder of Current Motor Company - opinions on this site belong to me; not to my employer
Remember: " 'lectric for local. diesel for distance" - JTH, Amp Bros || "No Gas. No Worries." - JDH, CuMoCo || "Make Volts Not War" - anon.

racermike39's picture
Offline
Joined: 11/15/2007
Posts:
Points: 127
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

OK now that you have admittedly HIJACKED my post, I get the first production piece for free right?
I have enjoyed your input and I am glad this post has sparked such great thoughts and input.
This could definitely be a winner in the EV market place. However, You must keep in mind that you can easily cross a line from a useful tool to a cumbersome specialized devise that will bring more frustration than positive results.
The keep it simple approach should be high on the priority list, Such that someone just trying to read battery condition, power consumption, speed and miles would also be attracted to this product. And then there is the cost.
You have all read and posted comments on how tough the EV consumer market is, because at this time, an EV user must be very familliar with many aspects of owning and operating an EV to realize good long term results. This product has great potential, but the more complicated features, the more product support will be necessary. Hours and hours will be spent on forums like this to help people who get lost in the menus and buttons.

NOW BACK TO MY ORIGINAL TOPIC!

I ordered the Paktrakr EV 600 today. $293 including shipping, shunt, shunt bar and the interface cable with the USB storage.
I researched the Cyclocomputer and the market is loaded with models in the $50 range.
Some things I found that clearly stood out:
*Most are waterproof
*The latest trend is a wireless sensor. This should be avoided in an EV, because the noise from the controller etc will effect it greatly. Many of the prduct ratings complained of innaccuracy due to interference with the signal. so go with a wired sensor. This is good news, because the wired sensor models dropped in price due to the release of the wireless models.
*Many are back lit.
*Many have large screens
*Most diplay speed, trip and time on the same display real time.
*Some high end models include a second sensor(wired) for cadence. This could be used for motor RPM? there is a calabration figure that you have to input, but I am not sure a cadence signal would have enough range for 4500 RPM. These are typicaly the highest priced.
*Warnings were given about models that auto shut off when you stop, but don't auto turn on when the sensor outputs a signal. If you were doing some sort of test, this could result in a do-over, or you may loose track of how many miles before you should turn around.
*It looks like the perfered meathod of mounting is velcro tape.

So there is some more market research for you. Does that qualify me for a 2% cut now?

That's it for now.

Mike K.

__________________

Racermike
5 years ago I met Jesus and he total ruined my life. I have never been happier.

jdh2550_1's picture
Offline
Joined: 07/17/2007
Posts:
Points: 2338
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

Sorry Mike! To add my answer to your question

If I had limited budget I'd go PakTrakr (PT) before Cycle Analyst (CA). Even with "unlimited budget" (yeah, right!) for a DIY project I wouldn't bother with a CA. For "upgrading" a commercial product (XM, Z/R, EFun etc.) the CA can prove useful for enforcing limits rather than relying on the rider's self discipline.

I think only the anally retentive amongst us (and the avid DIYer) really appreciate the data logging capabilities - so the average retail customer can save some PT bucks there as well if they wish. However, I know you're in the DIY camp (and far be it from me to determine whether you're a data crunching junkie!). However, if you want to "tune" your entire system (batteries, motor, amp draw, LVC, gearing etc. etc.) there's simply no substitute for a clear data log of before and after real world results as you tweak and change the bike. So, in other words, get the PT data logging it will be well worth it. I went for the version that didn't store it's own data just streamed it out in real time - with the intent of using a PDA all the time to actually capture the data. I'm now questioning that approach. I'd ask mikejuv for his handy dandy MS Access application to ease the crunching of data from PT format into Excel friendly format (see another thread on this board).

The main reason I see as a CA being most worthwhile for a commercial upgrade is for it's "meta controller" functions - i.e. being able to control the amp load and the low voltage cut off on the controller. Those are nice features and can extend battery life - and enforcing those limits on a sub-optimal OEM controller setup can be important for extending the life of batteries and improving the customer experience without having to tell the user "don't go more than X miles or accelerate harder than Y or run at max throttle up hills for longer than Z". However, all these things can be monitored and managed by the rider - at least to some extent:
-- as far as low voltage cut off goes this can be achieved by the rider themselves by simply knowing "don't go over X miles no matter if the bike tells you it can".
-- there's no real practical way of the rider controlling amp draw to the level of degree provided by the CA - however, if your batteries can't handle the amp draw demanded by the OEM controller then I think you need to change your batteries not control your amperage (again this is for the average consumer system - not the self designed and calibrated system of a DIYer).
-- as far as improved speedo accuracy - I'd say "quit worrying about it, or just paint a dot on the speedo for the true speeds that matter to you".

The main reason I wouldn't bother with a CA for a DIY project is that you'd be better off spendning your money on a controller that you can program to give the performance characteristics that you want. Or, instead supporting a project like what that thread hijacking Frodus has suggested... ;-)

CA is a great product and IMO it can add a lot to improving the ownership experience - but I don't think it's essential.

Does any of that help?

__________________

John H. Founder of Current Motor Company - opinions on this site belong to me; not to my employer
Remember: " 'lectric for local. diesel for distance" - JTH, Amp Bros || "No Gas. No Worries." - JDH, CuMoCo || "Make Volts Not War" - anon.

Offline
Joined: 03/10/2008
Posts:
Points: 340
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

If yous guys are going to do some Inventing how about all this battery monitoring AND a charger that charges each CELL of the new LIFEPO4 battery on xm3500 , that charges , monitors , and balances the batterys ,AND records preformance of the motor ,batterys ,AND calculates speed by the motors hall effect senser with editable circumfrence for diffrent tyre sizes . An LCD readout and bells and whistles as worning before I run into trouble ???? for about $6-700.00 fan cooled would be good (sort of like what cars have now for all that ongoing engine proformance stuff ) ;)

__________________

thank GOD I wake up above ground !!!!

frodus's picture
Offline
Joined: 03/17/2008
Posts:
Points: 189
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

well, the reason no one does it, is because its expensive to do all at once... and no one wants to pay for it.

Monitoring is more digital, while charging and balancing is more analog design, power, high current stuff. Alot more goes into a design for power than for something small and digital.

But, just to let you know, I know of one company that has a controller, monitor and balancer that is mostly integrated... they're working out the final integration and packaging. Its not here yet, but its being developed.

__________________

____________

Travis Gintz
1986 Honda VFR Conversion
www.evfr.net

andrew's picture
Offline
Joined: 11/28/2006
Posts:
Points: 1361
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

In response to frodus:

-Ability to interface with controller keyswitch input for cutoff.

This might be dangerous, but if overide is enabled then it wouldn't cutoff? Maybe something where it cuts back throttle and beeps until you turn it off. How could you overide while driving?

hmm. I was just trying to think of how the device can do cutoff. This seems like an easy way, where it just disables the keyswitch input. I don't use this input to the controller for an emergency cutoff since it's not a sure thing, but it'll be good for cutting the power in normal situations, and if it is overided, no big deal because one should still have direct control of their main contactor. And even if they use the KSI as an emergency cutoff, they can just wire a switch in series with the unit's control, so they could have external control of the KSI anyway.

Well, thats another design altogether, because the BMS should be integrated into the charger...

True. I guess this is a bit too far. I just figured because your already monitoring all of the batteries, but then, a BMS will most likely be implemented anyway, and directly interfaced with the charger as you say. It's probably bad planning for this device to take over some of the BMS functions---you'll make people think they don't need a BMS, when what we really need is a more advanced BMS (something better than the BattEQ or powercheq).

-Log all temperature inputs as well

if there's a monitor on each bat, then the uC would have an internal temp sensor that can be used with no extra hardware. If the monitor is mounted on top of the bat, this would give a good idea at temp. If its distributed, thats 1 input for each bat voltage, 1 for temp. 24 inputs right there. Plus currents, tach input... you're getting up there. Maybe 1 sensor for groups of 4 bats. But definately logging.

It would be to relate how all of the other parameters change in relation to battery temperature. Just one battery temp sensor would do. Unless they are charging, or a battery is bad, their temperature should remain about the same.

Motor voltage in addition to battery voltage input and logging

Why would you ever use that? Its PWM'd, its going to jump all over the place. I just don't see where you'd use it. Its just not an importand piece of data.

The capacitors on the controller smooth it out. When the controller pulses off, I think a freewheeling diode allows the current to continue flowing through the motor windings. Try measuring it. It allows you to calculate the controller efficiency, and get an idea of the motor efficiency. This data along with motor current can be compared to motor torque curves. It might also help select the proper gearing. For example, on my scooter, the controller is often limiting the current to 20 amps at full throttle, and the motor voltage would allow me to see exactly at what conditions this is occurring.

Software:
-Vary cutoff voltage based on current as an option. This would allow for very high performance, but still with good cell damage prevention.

Not sure what you mean. If you mean, shutting off the contactor at certain voltages based on current... I don't know what that'd get you. If you mean, if the current draw is low, decrease the cutoff because the rate of discharge is lower?

What I mean is the keyswitch cutoff voltage changing with current draw. You wouldn't want to shutoff the contactor under current draw because this may damage the contactor. Here's a good example:

On my motorcycle I can draw a ridiculous amount of current, and the batteries will probably sag to 50v or 8.33v/battery. Maybe 800 amps, indicating a battery pack resistance of <.0275 ohms. If my cutoff was set at 10.2v/battery, than this would limit my performance because I couldn't draw as much current without having it cutoff.

But, if I'm cruising drawing 70 amps, than 61.2v might indicate that the batteries are pretty much discharged, and in danger of over-discharge. This would indicate a battery DC resistance of about .216 ohms.

To further complicate matters, temperature changes how much the battery voltage will sag with SOC. So temperature may need to be factored into the cutoff set point.

In summary, the voltage cutoff point may need to have current draw, and temperature factored in. Essentially, it would be a measure of battery DC resistance to determine cutoff, and adjusted for battery temperature.

-Display option of just battery with the lowest voltage.

Easy to do through menu's

I'm thinking this would be set to automatically shift the display to the battery with the lowest voltage at any given time. This is so that if you wanted the minimal amount of data displayed, you could see the voltage of the lowest battery at any time without having to read any other batteries, and this would be the most important piece of information.

Anyway, I understand the need for simplicity. Meaning, it may not be very useful if it is difficult and cumbersome to set up. If the menus are simple and clear cut, then that would be awesome. The e-meter is a good example of what not to do. It is very difficult to set up just about anything, but it doesn't have an LCD display so it can't display a menu.

Mauibuck's picture
Offline
Joined: 02/19/2008
Posts:
Points: 10
Re: So is the PAKTRAKR and CYCLE ANALYST necessary?

WOW, what a discussion. WAY over my head but I'll throw in comments from the non-intelligencia end user viewpoint. I don't have any of the units under discussion and stumbled into this post while searching for info on the Watts Up watt meter. I hope the proposed open source design incorporates whatever it does although I suspect you passed that step in the first or second sentence of the proposal.

I think it would be nice if this device could easily be transfered between EV. I have an eGO scooter and EVG eBike now and plan to add one or two 4 wheel EV within the next year. I'm not wise enough yet to know if it would be best to have one monitoring device on each EV or if one would be sufficient and swappable. My present 2 wheelers are 24V but headed for 36V. The 4 wheelers will be 72V to perhaps as high as 144V.

I like the idea of PDA and/or laptop interface and preferably not state of the art connections required. XP over Vista. Dell Axium X5 is excellent choice. Quite inexpensive now and readily available.

And after this, perhaps you guys could design an open source Powercheq? Or maybe somebody already did that?

Learning
Mauibuck

__________________

115% home PV, eGO scooter w/ PV charge, EVG eBike
Considering 4 wheel EV purchase or conversion of Spitfire

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Short URL

Customize This