# A combo meter wish list for developers



## Qer (May 7, 2008)

Jimdear2 said:


> Developers please feel free to contribute descriptions of what you may have in the pipeline


Heh. This is actually one of our planned products that we will start to look at as soon as we manage to finish the controller. 



Jimdear2 said:


> *An Acceptable Price*
> $150.00 to $175.00 for the basic unit


I can tell you already that that won't happen. Sorry.



Jimdear2 said:


> *Basic Unit*
> A weather proof backlit color LED touch screen display unit of say 4 x 6 or 5 x7 inches with suitable edge and back attachment point.


And here's the reason why. A reasonably sized color display with touch screen means that it won't be very cheap. On the other hand, if we pick a cheap display to make the price more competitive it'll suck instead. We prefer quality over el-cheapo crap, so the price will definitely be higher than you suggest.



Jimdear2 said:


> It would be great if the basic unit could be based on a standard display archetecture (sp??). That way company Z module and company T module could be plugged into the company W basic unit to give exactly the sensor and information mix you want. Each module would automatically put itself into the basic units display index and wait to be called up.


Ouch. Committee product. That is SO not gonna happen. Ever heard the expression "a camel is a horse designed by a committee"?

It's not that I don't see your point and the benefits from an end user perspective (if the product would ever make it out the door that is), it's just that as an experienced, disgruntled and cynical so called senior software engineer (as if there's much engineering in software to begin with, look at Windows for example...) I've seen this goal ruin perfectly good ideas too often to even give it the surviving chance of a player of Russian roulette with a semi-automatic.

My comments in red below.



Jimdear2 said:


> Basic default continous displays should be
> 
> 
> Volts, Battery and Motor - Actually, motor Voltage is pretty pointless (and very hard to measure). Power would be more fun (my opinion), but pack voltage definitely should be there.
> ...


So, as I said, we've already been thinking about this. We just have to get the controller working first. If you buy many controllers I can quit my day job and if so you'll see this one faster. Hint, hint.


----------



## Madmac (Mar 14, 2008)

If you want to also have a car PC then the displays can be added at a small extra cost. A few details of the system I am designing and will post full construction details at some point (may not be on this forum).

A low power ( target of 30 watts) PC system with freeware Road Runner software can provide graphical interface for battery monitoring as well as MP3 and video playback, GPS, ability to remotely monitor / control charging, heating / aircon control, etc. With addition of cell phone modem can send SMS messages of car status, for example if car is disconnected midway thru charging. I use a slightly modified DigitalFx skin, see http://www.mp3car.com/vbulletin/rr-s...7-25-08-a.html many thanks to Gino (RoadRunner) and JohnWPB (DigitalFx) for all their hard work and support of open-source software for PERSONAL use.

This is the rough price of the parts for an AC controller, charger and BMS system

$880 ......8 off 12 battery BMS PCB’s, Including connectors etc. $110 each
$700* ....IGBT / Contactor / Precharge/ High volt PSU / Coulomb counter PCB
$58 .......current shunt
$150* ....Control PCB with PC PSU / Housekeeping CPU / DSP / USB to PC / etc
$134 .... Added components for mains input charger, filter connector interlock etc
$120 .....DC to DC 13.8 Volt at 70 Amps, part of commercial product bought as spare
$43 ......12V mains switch mode, powers system electronics during mains charging
$86 ......LED stop light / message display
$93 ......Intel Atom MiniATX 1.6Ghz PC motherboard
$180 ....7” Touch LCD monitor 
$53 .....160Gb 2.5 inch hard drive
$19 .....Memory SIM
$2516 Total

* These items may change slightly as the design is finalised.


Note this is small quantity component pricing, includes cost of PCB’s but does not include cost of assembly, if you do it yourself then there is no cost. All PCB’s designed to be hand assembled, they use no parts smaller than 0805 passives. Soldering some IC’s used in this project does require a bit of skill and practice.

Log in to see following photo's.....


----------



## ftaffy (Mar 13, 2009)

Madmac, that looks awesome. How much information about your system will you releasing? ie: Is this a forsale product or open source?

I am wondering as for those who want mod your design to reduce features/add them. 

In reply to the orgional:
Data logging - record with respect to time everything (well choice of what you want to logg anyway) in an easy to extract formate. You wont need it all the time but when something breaks you want to have access to it.

Be able add extra inputs for data logging. I would like to add air flow meters for aero tests, G-force sensor, etc.


----------



## Jimdear2 (Oct 12, 2008)

Qer said:


> Heh. This is actually one of our planned products that we will start to look at as soon as we manage to finish the controller.


Thanks for answering. When somone of your background shows interest., it gives the whole thread a level of potential reality. (don't let that praise go to your head)


*On Cost*


Qer said:


> I can tell you already that that won't happen. Sorry.
> 
> And here's the reason why. A reasonably sized color display with touch screen means that it won't be very cheap. On the other hand, if we pick a cheap display to make the price more competitive it'll suck instead. We prefer quality over el-cheapo crap, so the price will definitely be higher than you suggest.


This is a wish list after all and prices do keep coming down 

*On Open design of basic unit*


Qer said:


> Ouch. Committee product. That is SO not gonna happen. Ever heard the expression "a camel is a horse designed by a committee"?
> 
> It's not that I don't see your point and the benefits from an end user perspective (if the product would ever make it out the door that is), it's just that as an experienced, disgruntled and cynical so called senior software engineer (as if there's much engineering in software to begin with, look at Windows for example...) I've seen this goal ruin perfectly good ideas too often to even give it the surviving chance of a player of Russian roulette with a semi-automatic.


And an elephant is a governement designed mouse.

As usuall I wasen't clear. It's not so much the firmware (Is that the correct term) that should be commom, its the interface between the basic unit and the modules. Your unit could be a 13 inch heads up display and use virtual dials, theirs might be a 4x4 and use bar graphs. 

I thought that there were already standard in place on information exchange and protocols for data transfer. The module connection hard point would be common i.e. your module would plug into their basic unit (sounds kinky) the data transfered from the collection module would be the same

If you design the basic unit and your own set of modules and tell everyone just do this to make your device display on our Basic Unit, every module he sells might mean a basic unit sale for you if yours is better or they don't make one. Something like computers and sound cards.
[/quote]



Qer said:


> My comments.


I like your comments, I don't agree with all of them,  . . . but that is what a discussion group is all about. 

If I get a big enough sample it might give you developers a head start on saleable product. (and as an aside, get me the instrument designed that I want)



Qer said:


> So, as I said, we've already been thinking about this. *<My edit> great minds do think alike <end edit>* We just have to get the controller working first. If you buy many controllers I can quit my day job and if so you'll see this one faster. Hint, hint.


You don't have to hint,  I'm already saving my money to upgrade to a bigger set up for the ultralight puller next year. More voltage, more current, more battery capacity, more...more...more... and I haven't even run it yet.


----------



## JRP3 (Mar 7, 2008)

> time, date, ambient temperaturer


 I wouldn't even bother since many vehicles already have time and temperature and it's easy enough to add it if not.


----------



## Jimdear2 (Oct 12, 2008)

JRP3 said:


> I wouldn't even bother since many vehicles already have time and temperature and it's easy enough to add it if not.


Thanks for contributing.

I was thinking about a time, date, temperature information chips and sensors to be used within the basic unit for calculations. Maybe one that uses the atomic clock time check/set signals. Not primarliy for display for the operator and or passengers.

Keep the suggestions coming, Positive, negitive or neutral. In the end they will all help people like QED and madmac make better product for us.


----------



## Anaerin (Feb 4, 2009)

If you've got GPS integrated, you already have (multiple) atomic clock sources to hand.

As for temperature, most I/O systems come with temperature measurement lines on-board, so all you need to do is run the sensors ($0.10 each). Essentially you're getting ambient/external temperature measurement "For free". It may not be accurate to 12 decimal places kelvin, but it's more than enough to be an appreciable "value add" for comparatively little expenditure.

Also with GPS, you get a (reasonably accurate, questionably better than radar speed guns) Speedometer and Odometer. Then all you need are a few shunts to convert the high-current measurement into more manageable values, a whole stack of low-voltage and low-current measurement cards (for the battery pack, 1 per cell, perhaps integrated into the BMS for charging), and you've got a complete system.


----------



## Jimdear2 (Oct 12, 2008)

Anaerin said:


> If you've got GPS integrated, you already have (multiple) atomic clock sources to hand.
> 
> As for temperature, most I/O systems come with temperature measurement lines on-board, so all you need to do is run the sensors ($0.10 each). Essentially you're getting ambient/external temperature measurement "For free". It may not be accurate to 12 decimal places kelvin, but it's more than enough to be an appreciable "value add" for comparatively little expenditure.
> 
> Also with GPS, you get a (reasonably accurate, questionably better than radar speed guns) Speedometer and Odometer. Then all you need are a few shunts to convert the high-current measurement into more manageable values, a whole stack of low-voltage and low-current measurement cards (for the battery pack, 1 per cell, perhaps integrated into the BMS for charging), and you've got a complete system.


Anaerin

GPS, wow how did I miss that , Thanks.

Are you suggesting the GPS be part of the Basic Unit or a add on module so I know where to place it on the spread sheet.

I assume the low voltage cards would be for an add on BMS module


----------



## Anaerin (Feb 4, 2009)

Jimdear2 said:


> GPS, wow how did I miss that , Thanks.


I didn't even notice it was missing, TBH.


Jimdear2 said:


> Are you suggesting the GPS be part of the Basic Unit or a add on module so I know where to place it on the spread sheet.


I thought it was an integrated part, but it could (quite easily) be made optional. If the hardware isn't included, that part of the functionality/display would be disabled.


Jimdear2 said:


> I assume the low voltage cards would be for an add on BMS module


Yes. I was thinking primarily of Li-Ion cells, where you need a BMS for each cell. My thoughts were that as there is a over/under voltage protection shunt, among other things, a simple pre-programmed uC (Something like a PIC) on each cell, that also happens to talk to other cells and/or the charger/controller/interface (Using something like I2C) would make this self-configuring, also. When the system is powered up, it interrogates it's attached modules to build a map of what functions are available. Potentially, things like the GPS module (Which could also be a separate unit talking on the same bus) could also have their interface software/drivers included internally (Like AutoConfig enabled on the Amiga, for example).


----------



## Madmac (Mar 14, 2008)

Using a PC as the basis for displays ( the cost will be 2 to 3 times your budget buying new) means that it is very easy to add modules via USB. A good example is the Fusion Brain http://www.mp3car.com/vbulletin/fusion-brain/ with digital I/O, A to Ds, relay drivers. The software driver allows this to be easily used with RoadRunner without needing to learn to program. USB in cars has shown itself to be reliable if cables are short and good quality. If budget was very tight then a secondhand portable could be creatively re-engineered at very low cost, it could easily be achieved under your budget of $150.



> How much information about your system will you releasing? ie: Is this a forsale product or open source?


 It is an open source project. It uses RoadRunner open source software for creating custom display screens. The screens can easily be skinned to create custom looks and to group together information as required on each screen. If you look at http://www.mp3car.com/vbulletin/road-runner/ you will see that there are dozens of application add on’s from phone control to displaying real time Google Earth, displaying road side traffic camera’s to check traffic, tyre pressure monitor and warning system etc.




> Yes. I was thinking primarily of Li-Ion cells, where you need a BMS for each cell. My thoughts were that as there is a over/under voltage protection shunt, among other things, a simple pre-programmed uC (Something like a PIC) on each cell, that also happens to talk to other cells and/or the charger/controller/interface.


 The PCB in the above photo’s is a 12 cell BMS based on the Linear Technology LTC6802 device. Each group of 12 cells has its own control PCB with charge bypass equalisation, full voltage and temperature monitoring (PCB plus 5 in pack), 20 Watt (easily upgradeable to 40 watt) boost charger for balancing one cell at a time in each pack of 12 (can be used during charging, standby or discharge). In and out connectors for looping BMS bus to next pack. Data bus is based around RS485.

Designed to get maximum life out of battery pack, also works with coulomb counter on High_power_PCB to track charge in and out of batteries for accurate state of charge indication. Also monitors for shorts to chassis of battery cables for safety.

Intended for Li-ion but can be used with any chemistry where the cell voltage is less than 5 volts, using the PC to format the data a complex model of the battery can be run to get accurate capacity display.

Typical ACIM system would use 8 (8 x 12 x 3.6 = 345 Volts) or 9 (9 x 12 x 3.2 = 345 Volts) PCB's depending on battery technology. Max of 14 BMS boards in a system.

Running a GPS mapping program on the PC, for example Sygic, allows setting up charging points (some point in the future!!!) as Points Of Interest for easy location and directions to find them.


----------



## Qer (May 7, 2008)

ftaffy said:


> Data logging - record with respect to time everything (well choice of what you want to logg anyway) in an easy to extract formate. You wont need it all the time but when something breaks you want to have access to it.


With the risk of getting shouted at for plugging for our product...

Right now we're using this protocol when you extract data from the controller:



> 58716 28.609375 198 195.836500 14.018692 32.710280 153 43
> 58724 28.609375 199 196.582100 14.018692 30.841121 153 43
> 58732 28.609375 199 195.953000 14.018692 32.710280 153 43
> 58740 28.609375 198 196.186000 14.018692 30.607477 153 43
> ...


The data is, from left to right, running time in ms, CPU load in percent, throttle in Ampere (thinking of changing that to percent), Motor Amps, PWM frequency (kHz), Pulse width (percent), Pack voltage and Controller temperature. I don't see any reason why it'd have to be more complicated than that, binary formats are just annoying since it means that you have to use a special software which usually don't run under anything else than a too old version of Windows...



ftaffy said:


> Be able add extra inputs for data logging. I would like to add air flow meters for aero tests, G-force sensor, etc.


That's a rather fun idea, actually. Haven't thought about that. Mind if I steal it? 



Jimdear2 said:


> (don't let that praise go to your head)


Too late... 



Jimdear2 said:


> I thought that there were already standard in place on information exchange and protocols for data transfer.


Not really afaik. But if there is one I'm definitely interested...



Jimdear2 said:


> I like your comments, I don't agree with all of them,  . . . but that is what a discussion group is all about.


Well, don't hold your breath. We still have to get the controller running before we can start looking into this project.



Anaerin said:


> As for temperature, most I/O systems come with temperature measurement lines on-board, so all you need to do is run the sensors ($0.10 each). Essentially you're getting ambient/external temperature measurement "For free".


Although, in a product that's sold to actual customers you have the warrant aspect too. You really don't want to just connect an ADC-pin (which is what I think you're talking about, right?) to the outside world without some kind of protective buffering because then just a slight mistake (for example connecting 12 Volt to screw 3 instead of 4 or whatever) will blow the microcontroller and you have a dead box and a warrant issue. If you're a happy DIY'er that cook your own boards etc you'll just smack your forehead, call yourself names and cook a new board, if you're selling the stuff it's going to be helldesk misery to release anything that's that sensitive.

Not that I'm saying temperature sensor is a bad thing (personally I wouldn't mind one or two as well), only that it will not be "free". I'd say that in the end it might be maybe a buck or so, all included. Granted, a buck isn't that much, but after a while it starts to add up.



Anaerin said:


> My thoughts were that as there is a over/under voltage protection shunt, among other things, a simple pre-programmed uC (Something like a PIC) on each cell, that also happens to talk to other cells and/or the charger/controller/interface (Using something like I2C) would make this self-configuring, also.


When I started to get interested in EV's, watched GAV's and Forkenswifts videos etc I had those thoughts too, however we're not planning such a project (there's a limit to what a handful of guys have the time to pull off). Here's some feedback to your ideas though:

You can probably measure more than one cell per microcontroller by adding fitting voltage dividers, then you can get cell voltage 1 by input 1, cell voltage 2 by input 2 minus input 1, cell voltage 3 by input 3 minus 2 etc.

The biggest problem here is isolation. Either you have to isolate all the inputs or you have to isolate the communication. Personally I was going to isolate the communication since it's much easier (think MIDI if you're familiair with that) and power each microcontroller from the packs it's measuring but then you can't use I2C since it's bidirectional. I was thinking of daisy chaining UARTs (output to input, the microcontroller relays the info plus adds it's own to the output that goes to next input etc) but you could use SPI too if you like (although that means you have to use more wires and more opto couplers). Theoretically you could use I2C too, of course, but it'd be a pain to handle the data direction changes...


----------



## Madmac (Mar 14, 2008)

Quer


> and power each microcontroller from the packs it's measuring


If you have a background in power electronics then you know that crashes due to noise can easily lock up the internal logic of a microcontroller meaning that it will no longer respond to the reset line. Powering the microcontroller so that you can remove power to force reset is the only way to guarantee running reliably.


----------



## Qer (May 7, 2008)

Madmac said:


> If you have a background in power electronics


Nope. That's one of the technical areas I've actively avoided until now. The most powerful I've toyed with before this was 230 Volt AC, 10 Amps. Even now I'm mainly involved by proxy in the power electronics since it's Tesseract that handles those parts and he's on a different continent...



Madmac said:


> then you know that crashes due to noise can easily lock up the internal logic of a microcontroller meaning that it will no longer respond to the reset line.


No, that I've never seen. I've seen microcontrollers lock up by various reasons, static discharges is a popular reason, but I've never seen one that's been so badly locked up that a hard reset hasn't worked. We've experienced lock-ups in the controller due to arcing too, but still that hasn't disabled reset. That sounds like some kind of hardware flaw in the microcontroller itself.

Out of curiousity, what kind of microcontroller was that?



Madmac said:


> Powering the microcontroller so that you can remove power to force reset is the only way to guarantee running reliably.


Or you could try to use the watchdog...

Admittedly, I've experienced watchdogs that hasn't worked, but that has usually been on more complicated CPU's and systems. On a microcontroller they are usually rather reliable. But then, you don't know until you've tried...


----------



## Madmac (Mar 14, 2008)

I first came across the problem while contracting for a mutlinational in the late 90's. We had an Arm7 based device locking up about 1 in a 100 crashes during EMC susceptibility testing. A project was launched to see what was going on and a range of 12 popular micro controllers were tested. They all suffered the same problem to varying degrees. The best was around 1 in a thousand. This was in a high electrical noise enviroment.

Since then I have chatted to other designers in high power electronics and high reliability systems and this seems to be a standard practice. The watchdog is also used to cycle power. 3V3 devices are more susceptible. A quick Google came up with Lee Hart recommending the same technique.

With your idea of connecting directly to the battery in a pack.. a lock up, even if it is 1 in a 1000 crashes, would mean having to physically get in there to reset.

It may seem a very infrequent event but if the time that it does occur causes the product to fail then it is a warrenty burden that a company does not want. In the case of your product it would no longer respond to the throttle and possibly just hold the current PWM value. As always the devil is in the detail for good design.

In the BMS board above I use a normal internal hardware watchdog, force reset holding the RS485 line in break for a couple of seconds and finally power removal.


----------



## Qer (May 7, 2008)

Madmac said:


> A quick Google came up with Lee Hart recommending the same technique.


You didn't give me a link so I googled around a bit myself. Is this the same Lee Hart:

http://www.mail-archive.com/[email protected]/msg06154.html

It's a bit long but scroll down or search for the phrase "Lee Hart wrote". There are two places that matches that string. One is a post from Lee Hart, the other a reply to that post.


----------



## Madmac (Mar 14, 2008)

It looks like it is the same guy... well known for his pb battery management. Was not the same as the text I read.....that was on the effects of high dv/dt transients both induced and conducted.

the comment



> A uC generally can't overheat from its own power. MilSpec would allow for any unreasonable external temp.


He did not come across one of the first mask runs of the (IIRC) MC6802 and its halt and burn instruction. An unused op code caused a bunch of drivers turn on at the same time effectively shorting the PSU. If your program crashed and a table had that value picked up as an opcode the device killed itself, took about 15 seconds.


----------



## ftaffy (Mar 13, 2009)

Qer said:


> That's a rather fun idea, actually. Haven't thought about that. Mind if I steal it?


Fine with me, i am throwing all my time and money into my custom built EV with only thoughts on adding these things coming along for the ride. I would make it if there was a base line set of designs that were known to work and then mess around but i dont have time to learn and then design anything this complicated. I have enough fun designing suspension pick up points and nose cones (... not going well here lol).

I took at look at lee's balancer, might look into installing that. Not sure how i will fund an extra stream in the project yet lol. Can you sell pieces of scrap metal with skin and blood attached for much? 

edit: Just took a look at http://www.mp3car.com/vbulletin/fusion-brain/, now im interested. ahhh crap, why does coming on here cost me $$. Now off to see what kind of tiny computer i can build to fit in my car.


----------



## Jimdear2 (Oct 12, 2008)

Well we have heard mostly from developers so far:

I would still like to hear from end users.

THIS IS A WISH LIST

Please wish away, your idea may be the key one needed to get these things developed.

Jim


----------



## SimonRafferty (Apr 13, 2009)

Strangely enough, I've been thinking about this - and have a few more ideas!

Most vehicles have a tachometer - yes? I'm not sure I see the point of knowing the motor RPM, at least not all the time. The readout is, however, very easy to control and use for other stuff.

A low cost display option would be the tacho and an LED to indicate what it is showing at the moment.

One level up on this would be a small (16 x 2 line) LCD module showing the status and display function. It could use as little as a single push button to change display.

Computer wise, I think a PC is over the top. Use something like a Parallax Propeller microcontroller which contains 8 x processors clocked at nearly 100MHz and can do some truly remarkable things like synthesize a VGA RGB output directly using only 6 pins on the processor. You can plug it in to a low cost VGA or Composite monitor - or the LCD / Tacho.

Another display option I like is using RC servos moving the needle of a gauge - simple and cheap.

Monitoring wise, the Propeller does not have proper analogue inputs. Instead I propose using Maxim Max1139 which is a 12 channel serial I2C A to D converter. There are several others in the range which may have better characteristics. The 12 inputs, I propose be used for 10 voltage measurements, one current and one temperature for clusters/strings of up to 10 batteries. The individual voltage measurements gives good info on failures and residual capacities. Current should be measured with a Hall effect loop rather than a shunt. Also, they are quite resilient to line noise so powering from each individual string is possible.

The I2C interface only uses 2 pins on a processor and you can daisy-chain more I2C devices together than you will ever need in an EV (127 IIRC - or 1270 individual batteries)

The propeller is available on a low cost ($50) ready built board and hardly uses any power compared to a PC.

My wish list for functions is as follows. I have included stuff for ICE's as well as it increases the potential market:

*
*
·[FONT=&quot] [/FONT]NMEA Serial input from GPS

·[FONT=&quot] [/FONT]Programmable speedometer - input from GPS / driveline sensor

·[FONT=&quot] [/FONT]Tacho
·[FONT=&quot] [/FONT]Clock (use GPS Time reference)
·[FONT=&quot] [/FONT]Fly-by-wire Throttle re-map with 0-5v and Servo PWM out
·[FONT=&quot] [/FONT]Cruise Control using Speedo and Throttle
·[FONT=&quot] [/FONT]Economy / sport acceleration
·[FONT=&quot] [/FONT]String voltage monitor 0 to 400v 
·[FONT=&quot] [/FONT]Pack Voltage monitor 0 to 400v 
·[FONT=&quot] [/FONT]String Current monitor 0 to 2000A 
·[FONT=&quot] [/FONT]Fuel gauge (0 to 12v analogue feed to vehicle fuel gauge)
·[FONT=&quot] [/FONT]Fuel used ICE (flow meter)
·[FONT=&quot] [/FONT]Degree of discharge based on voltage and current Integration
·[FONT=&quot] [/FONT]Range in current gear
·[FONT=&quot] [/FONT]Economy mile per kwh or per gallon
·[FONT=&quot] [/FONT]Engine / Pack Temperature
·[FONT=&quot] [/FONT]USB logging and programming via PC


Si


----------



## rocketjosh (Jun 8, 2008)

It seems this company: RechargeCar Inc. is working on a USB Tachometer sensor for an EV. Their site says it will work with existing sensors, or a magnetic pickup sensor mounted to a motor shaft. 

Looks like it plugs into a laptop or "carputer" which is used for a display.

Has anyone else heard of this company?


----------



## Amberwolf (May 29, 2009)

I am only building and riding bicycle-class EVs, but I have wished on occasion for a "dashboard" of meters for various things. 

Currently, I use VeloAce on an old m100 PDA to keep track of bike speeds/info, but have nothing that keeps track of motor/battery info (can't yet afford the cycleanalyst, but it would be good for this). 


Since this is a "wish list", I'll put up my dream goal. 


I'd like to see something that includes what one would expect out of a typical dashboard, only in a "glass cockpit" display format, preferably where one display can be used to page thru multiple types of information.

Some information is not needed except during servicing, typically not when driving the vehicle. That can all be on non-primary pages.

Other things need to be instantly visible at a glance, so that needs to be on the first page. During driving, I think this page should have a high enough priority that it will be automatically switched back to after some very short period after the user switched to any of the other pages. 

Some things may not be needed *all* the time, but would be very handy to have on a second page that can be reached with a simple tap on the screen or button to the side (or on the steering mechanism next to one's thumb, etc). 


Since not everyone will have the exact same needs, the ability to customize all these pages for which items will display on each would be essential (to me). 

For instance, cabin temperature would be largely irrelevant to me, on an open bike, but to others in an enclosed vehicle, it might be important enough to want on the first or second pages. 

Motor RPM on the other hand is likely to be something almost everyone will want on the first page, unless they have a specific hardware setup that physically prevents over-revving it. 


I'd also like to see the controller use a VGA type output, so that *any* monitor someone prefers could be used to display the data. I don't know how hard DDC is to implement, but assuming it is not possible, then by default the unit would output some low-resolution version, so that regardless of display size/res, it would still display, and then the menu could be accessed to change it to the desired resolution for the display the user actually has. 

Since it would be possible to accidentally set it too high, then there should be some method to reset to the default display setting without erasing all other customizations, such as holding a specific multiple-button set during power on (or at any other time, perhaps), to reset only the display resolution.

A higher resolution display would be able to have more information on a single page, and/or have larger, more easily-visible ways of displaying it. 


Customization of the pages would include the order they should appear on screen. Personally I would use a drag-n-drop method, if touchscreens are used, to allow this. It would let a user just nudge the meters around on screen until they're where they like them, in relation to each other. 

A similar method can be used for changing their size, so that information that is more important to that user can be made larger. Simply hold a specified button down, then drag any corner of the meter, and it would expand proportionally in that direction. Holding the button and dragging any edge expands linearly but non-proportionally in that direction.


Having multiple types of meters to display information would be useful as well. Different people like different types of displays, and different information is suited more for certain types of meter than others--but it doesn't mean that a person wants to actually *use* the best meter for that info, for whatever reason. 

Many things like speed are often best given in the dial format, as that's what most people are already used to. Battery levels perhaps in a level-meter format. Odometers in text format. But not everyone would always want the same thing. 

For instance, I would prefer a text format for speed, so I can see the exact speed all the time, rather than watching a dial. It's faster for me to interpret and react to. I don't want a text format inside a dial, because then I have a distraction of a moving needle, too. 

(I have a brain problem that causes me to be distracted by certain kinds of things, and it's one small reason I prefer bikes to cars, as it's easier for me to deal with the problem at slower speeds than I could drive at in a car, when I am in traffic). 

Sometimes it's only about the looks of the display, where someone might want all the readouts to be identical in appearance, though I would not. 


At the extreme end of the wishlist, I also would want to be able to customize the colors of things, as there are some color combinations I will notice better than others, depending on the surrounding colors of the environment (car interior, etc). For other people, some are colorblind to certain combinations, like red/green, and wouldn't be able to tell when a motor was redlining via a simple red/green level meter, but if they had, say, yellow/blue they could tell easily.


As for a way to interface everything electrically, so that different controllers and sensors and modules could be read and controlled by the same user interface, there are a number of existing electrical specifications, such as CAN, One-Wire, etc, that could be used depending on the type of data to be passed along. Some of these already specify electrical isolation methods, as well (such as optocouplers, which MIDI uses). There are even older methods such as the original RS232 which is fairly noise-immune even over long runs due to it's high-voltage swing, but it isn't all that practical to use for today's stuff at those high voltages. GPIB is another old standard that could be used, but I don't think it is as appropriate as things like CAN.

If induced electrical noise is a great concern, perhaps fiber-optics could be used in critical comm lines. (this would also be another way to ensure electrical isolation)


The protocol to be used over that electrical interface is a bigger can of worms, as there are many more ways to do this. Perhaps a text-interface so that data formats such as given a few posts above would be useful. MIDI is an example of one that uses 7-bit ASCII codes already. 


Practically, I imagine that intercommunication between different manufacturers' modules isn't going to happen for the foreseeable future, just because of competition, warranty issues, tech support, etc. If there's more than one brand of stuff in there, it's a lot harder for tech support over the phone to be sure which one to start with, and a lot easier for them to tell an end-user that it "must be the one from company X" rather than their own, without even troubleshooting anything. That's a common thing in PC support, for instance. 

Personally, I think that if there were intercommunication available, it would increase sales of those systems using it because people could pick and choose what modules they want out of each system, or which ones are more appropriate for their vehicle. I'd certainly be more likely to purchase such systems, if for no other reason than this: if a manufacturer goes out of business, or changes product lines, then at least I could continue to purchase replacement modules from other companies that would still work with it, instead of having to scrap an entire interface/control/etc system just because one small part of it failed irrepairably. 



I'm sure I can think of a lot of other stuff, but that's enough assault on this thread for now. 
________
Leather Webcams


----------

