Discussion Forums

RIP Palm Support?

Want the ECU+ to make you breakfast in the morning? Did the software light your basement on fire? Chime in here.

RIP Palm Support?

Postby tlcoll1 » Wed Dec 27, 2006 9:03 pm

Gang -

I'm giving some thought to dropping support for the Palm's in the next version of the ECU+ software. After supporting this for a while, here's what I see:

1. The Palms seem to be a real hassle to get working HotSync-wise. I get no end of technical questions about 'em, and some of the questions I just can't answer without having the Palm and the customer's laptop in my hand.

2. Doesn't seem like too many people are using the Palm software.

3. The Palm software does way less than the Windows software. I can only see this getting worse.

4. And finally, the Palm software is a HUGE PITA for me. Every hunk of code I write for the Windows software is something I have to rewrite for the Palm. The Palm is just a miserable platform to develop for, and stuff never works right off the bat. In the end, it takes me loads of time to get stuff ported to the Palm, and that's time I'm not spending developing new features.

Thoughts?

Tom
tlcoll1
Site Admin
 
Posts: 1511
Joined: Sun Jun 13, 2004 1:01 am
Location: Odenton, MD

Postby mad_viii » Thu Dec 28, 2006 10:24 am

Well,

I understand where you are comming from Tom. The only reason I don't use my palm more than i do is the boost logging..... since we cannot import the files and keep the boost log intact I end up not using it.

Perhapse palm is not real solution, and the more I think about it the more I think we need an addon hardware module that say fits in the factory stereo opening (hint hint) that has a digital readout for several parameters and either a usb or sd port for logging to removeable media in the native ecd format. And maybee a serial port so we can plug the laptop in to the display unit rather than having to swap cables on the head unit. I would be willing to pay a couple hundred bucks for all that finctionality, considering you could replace several gauges with it.

ECU+ Is a great product, but I often find myslef wishing I had a way to display the logging data in realtime to use a set of gauges for boost, afr, egt, etc. I was very excitted to hear MJ's display / logger idea, as I think that would take the ECU+ to the next level.


From my perspective, what would make the palm software worth having is logging, plain and simple. Move the palm db conversion function into the ecu+ gui so that we can just copy the raw logfiles (palm db format) to an sd card, pop it out of the palm and into the laptop or windows box and import the logs via the windows gui rather than having to hotsync.
HKS 272's -4i/-1e | 10.5 | 3" catless | Walbro 255 | PTE 750's | K&N Panel | HPF LICP | ECU+ | ECU Flash
mad_viii
 
Posts: 35
Joined: Wed Jul 19, 2006 1:25 pm

Postby tlcoll1 » Sat Dec 30, 2006 10:50 pm

That's an interesting point of view. Really, the challenge with the Palm software is trying to somewhat-match the features of the Windows software. For example, getting all of the OBD-II and MUT-II diagnostic info in there was a mess. Also, keeping it in sync with the head unit settings is just a mess. Maybe a slimmed-down Palm app is the answer, which just displays data real-time and allows logging - you won't be able to setup the unit with the Palm software. I'll have to think about whether that's feasible.

The display unit is something I started thinking about the other day as I was looking at the opening in my EVO dash. I may do that eventually just 'cause it sounds like fun, though I have no time right now. From what I know now, it seems like the problem with a development like that is finding hardware that fits into a DIN opening which is also programmable. Not sure I want to start from scratch on that project, as I think the physical part of it will be what makes it cost-prohibitive. If you've seen anything that could get me started, that would help.

Tom
tlcoll1
Site Admin
 
Posts: 1511
Joined: Sun Jun 13, 2004 1:01 am
Location: Odenton, MD

Postby mad_viii » Sun Dec 31, 2006 11:13 am

Jack posted up a project he was working on here and on evom:
http://forums.evolutionm.net/showthread ... ost3573705

Don't get me wrong Tom, I would much rather you spend your time working on new features for the firmware and windows gui than palm support.

It's just a shame to have all the data required for a full digital dash and no way to implement one.... especially now with the mut-ii support.

A din sized multi gauge that displayed afr, boost, egt (since those are the ones you can't easily split the signal on) knock sum, coolant temp etc.

Even without the logging I would pay a couple hundered for that.

But if that is too much work..... how many 5v outputs do you have and would it be possible to duplicate a 5v input votage to a 5v output voltage so we can run regulat gauges but off the ecu+ rather than direct from the source.
HKS 272's -4i/-1e | 10.5 | 3" catless | Walbro 255 | PTE 750's | K&N Panel | HPF LICP | ECU+ | ECU Flash
mad_viii
 
Posts: 35
Joined: Wed Jul 19, 2006 1:25 pm

Postby steel_3d » Mon Jan 29, 2007 5:50 pm

Is it possible to keep the existing functionality working on the palm? Personally I really like the ability to log and do some quick tuning any time I want, even if it doesn't do everything. The laptop can't always be in the car, the palm can. Also I find the palm more comfortable to work with.

At the very least we'd need a knock warning of some sort to replace the everyday monitoring ability.

Have you thought of using the stock boost gauge as a display? Could really be set to display anything. I guess it would eat up one output...

Personally I'm not a fan of the DIN display idea, since it's impossible to look at during a pull.
Steve Marton
steel_3d
 
Posts: 20
Joined: Thu Feb 09, 2006 4:37 am
Location: LA

Postby tlcoll1 » Mon Jan 29, 2007 11:08 pm

Unfortunately, even keeping the current functionality is a hassle. I have plans to change a whole bunch of under-the-hood structure, and that means that the Palm software requires extensive modification. I just plain dread doing it, and that's bad news for people who want me to release new features.

Tom
tlcoll1
Site Admin
 
Posts: 1511
Joined: Sun Jun 13, 2004 1:01 am
Location: Odenton, MD

Postby mad_viii » Sun Feb 04, 2007 10:26 pm

steel_3d wrote:Is it possible to keep the existing functionality working on the palm? Personally I really like the ability to log and do some quick tuning any time I want, even if it doesn't do everything. The laptop can't always be in the car, the palm can. Also I find the palm more comfortable to work with.

At the very least we'd need a knock warning of some sort to replace the everyday monitoring ability.

Have you thought of using the stock boost gauge as a display? Could really be set to display anything. I guess it would eat up one output...

Personally I'm not a fan of the DIN display idea, since it's impossible to look at during a pull.


I don't think many folks have a stock boost gauge. are you refering to the sport meter kit?

No reason the din display could not have outputs to drive other gauges.
HKS 272's -4i/-1e | 10.5 | 3" catless | Walbro 255 | PTE 750's | K&N Panel | HPF LICP | ECU+ | ECU Flash
mad_viii
 
Posts: 35
Joined: Wed Jul 19, 2006 1:25 pm

Postby tlcoll1 » Mon Feb 05, 2007 11:36 pm

mad_viii wrote:
steel_3d wrote:Is it possible to keep the existing functionality working on the palm? Personally I really like the ability to log and do some quick tuning any time I want, even if it doesn't do everything. The laptop can't always be in the car, the palm can. Also I find the palm more comfortable to work with.

At the very least we'd need a knock warning of some sort to replace the everyday monitoring ability.

Have you thought of using the stock boost gauge as a display? Could really be set to display anything. I guess it would eat up one output...

Personally I'm not a fan of the DIN display idea, since it's impossible to look at during a pull.


I don't think many folks have a stock boost gauge. are you refering to the sport meter kit?

No reason the din display could not have outputs to drive other gauges.

The DSMs (at least the 2Gs) have a "boost gauge" built into the gauge cluster. The stock ECU estimates boost and displays it.

Tom
tlcoll1
Site Admin
 
Posts: 1511
Joined: Sun Jun 13, 2004 1:01 am
Location: Odenton, MD

Postby tlcoll1 » Mon Feb 05, 2007 11:38 pm

steel_3d wrote:At the very least we'd need a knock warning of some sort to replace the everyday monitoring ability.

Have you thought of using the stock boost gauge as a display? Could really be set to display anything. I guess it would eat up one output...

I hadn't given the boost gauge any thought, though the CEL is a good candidate to drive. I'd need to do some research to see what it takes to drive the DSM boost gauge.

Tom
tlcoll1
Site Admin
 
Posts: 1511
Joined: Sun Jun 13, 2004 1:01 am
Location: Odenton, MD

Postby Matz » Tue Feb 06, 2007 9:51 am

I love having the Palm support for autox days. However, since MalibuJack on evom has an external display under the works, I'd opt for that anyway. If it makes supporting the software easier, and allows you to write more maintainable code, I say get rid of the Palm support! :)

EDIT -- I know I've brought the serial protocol subject with you before, Tom, but with all of the talk about getting rid of the Palm support (ok), it would be nice to add some sort of open "interface" to the ECU+. It would be totally awesome to come up with a serial data packet structure that is guaranteed not to change, and will not have any effect on the ECU+ operation. That way, people like myself and MalibuJack can hook up a device to the ECU+ serial port, initiate communications, and then read the data stream and render the data as we please. That would be awesome! A logical way to represent the data would be XML. However, because of the overhead and sheer number of parameters that could be logged, maybe upon negotiation the client device can receive descriptors for each 8 byte value in a packet. Each byte would correspond to a parameter that ECU+ reads. I only picked a byte because I believe that's the size of the variables used in the stock ROM.
2003 Apex Silver Evolution VIII
User avatar
Matz
 
Posts: 57
Joined: Tue Dec 06, 2005 10:34 am
Location: somewhere off of the track

Postby tlcoll1 » Tue Feb 06, 2007 11:23 pm

Dave -

Here's what I'll say about the protocol. I'm hesitant to open that up because using it incorrectly can potentially poke weird values into the head unit memory, and I really don't want to have to field the support e-mail for other people's software. But I will make it available to folks who demonstrate a prototype of something they want to make work with the ECU+. So, for example, with MJ, when/if he gets something in working condition that works with his own homemade data stream, I'll give him the real information to make it work with the ECU+. Same for you - if you build some hardware or software to look at the ECU+ serial stream in a special way (something that say, wouldn't make sense to go in the ECU+'s normal software), then I'll give you the real info.

Tom
tlcoll1
Site Admin
 
Posts: 1511
Joined: Sun Jun 13, 2004 1:01 am
Location: Odenton, MD

Postby Matz » Wed Feb 07, 2007 8:37 am

tlcoll1 wrote:Dave -
Here's what I'll say about the protocol. I'm hesitant to open that up because using it incorrectly can potentially poke weird values into the head unit memory, and I really don't want to have to field the support e-mail for other people's software. But I will make it available to folks who demonstrate a prototype of something they want to make work with the ECU+. So, for example, with MJ, when/if he gets something in working condition that works with his own homemade data stream, I'll give him the real information to make it work with the ECU+. Same for you - if you build some hardware or software to look at the ECU+ serial stream in a special way (something that say, wouldn't make sense to go in the ECU+'s normal software), then I'll give you the real info.


Hi Tom,

That seems very fair to me! But can you please comment on the idea of switching the serial output of the ECU+ based on the connected client? The idea I was proposing was a push-only mode where the client reads in a stream, but the ECU+ would ignore all incoming data when in this special mode. That would be way better IMHO... you wouldn't have to worry about anyone messing with the ECU+ operation, since it would ignore the incoming data, and then no one would have to spend the time to figure out your serial protocol, which could change at any time.
2003 Apex Silver Evolution VIII
User avatar
Matz
 
Posts: 57
Joined: Tue Dec 06, 2005 10:34 am
Location: somewhere off of the track

Postby tlcoll1 » Wed Feb 07, 2007 10:57 pm

Dave -

Any device that worked with the ECU+ would need to do two-way communications. The simplest example is the MUT-II logging, in that the device would need to ask the ECU+ box what MUT-II values were being logged currently. There's probably other cases, but that one springs immediately to mind.

Part of the reason that I'm willing to make the protocol info available to you after doing a prototype is that I don't think you're really going to take me up on the offer! :o I contemplated doing something like MJ is proposing (an in-dash display unit) myself, and came to the following conclusions:

1. It has to support both the older black box as well as silver box ECU+'s. That's three, and soon to be four, over-the-wire protocols.

2. It has to do many of the same things that the Windows software does. That means, for example, it has to know the calibrations for all umpteen wideband sensors that the ECU+ supports. Gonna need lots of program memory for that, and maybe a floating point CPU. To support OBD-II and MUT-II, pretty much all of that portion of the Windows software would need to be ported.

3. It's gonna take a year, or so, to design and build.

4. Hardware costs will be about $150 per unit. Probably couldn't sell it for less than $400 each. No one is going to spend $400 for an in-dash display unit.

5. If it was, say, $200, the total sales would be 5-10 units. At 10 units, that's $500 profit for a year's work.

And just FYI, even selling the ECU+ is really a joke from the perspective of it being a real "business." I did a back-of-the-envelope calculation today, and found that looking at the ECU+ business from a "is it worth it" POV, I'm pulling in about $2.50 an hour. It's clear that I would have been much better off working at McDonalds 5 hours a night, 365 days a year for the past 7 years than working on the ECU+.

Tom
tlcoll1
Site Admin
 
Posts: 1511
Joined: Sun Jun 13, 2004 1:01 am
Location: Odenton, MD

Postby Matz » Thu Feb 08, 2007 12:30 am

And just FYI, even selling the ECU+ is really a joke from the perspective of it being a real "business." I did a back-of-the-envelope calculation today, and found that looking at the ECU+ business from a "is it worth it" POV, I'm pulling in about $2.50 an hour. It's clear that I would have been much better off working at McDonalds 5 hours a night, 365 days a year for the past 7 years than working on the ECU+.


Bah, that calculation is flawed because it doesn't count how much people praise you for such a great instrument! Out of those 365 days, do you think anyone will thank you for making a great batch of fries? :D

Back to my original point -- I guess I don't understand what's under the hood, because I've done one way-only serial communications before, where my device just spits out data that gets rendered in a VT100 terminal. There's never a requirement that the client responds in any way, unless you're talking about XON/XOFF.

So perhaps you're just saying that it is required by the ECU+? And if so, I was simply proposing that you enable it to switch to a "push mode" of sorts and just stream data without listening for a response. The device shouldn't have to ask the ECU+ what data is being logged, because the ECU+ will have this info in the data sent over the serial connection.

You could use XML, which would be really easy for logging parameters, or just create a defined structure for the data and leave it to the client to figure out which byte matches which parameter.

Anyhow, I apologize if I keep blabbing about this. I just don't understand why it would require two-way communications... hmm.. do you have an extra serial port available? :) I don't know which AVR you use.
2003 Apex Silver Evolution VIII
User avatar
Matz
 
Posts: 57
Joined: Tue Dec 06, 2005 10:34 am
Location: somewhere off of the track

Postby tlcoll1 » Thu Feb 08, 2007 11:19 pm

Matz wrote:
And just FYI, even selling the ECU+ is really a joke from the perspective of it being a real "business." I did a back-of-the-envelope calculation today, and found that looking at the ECU+ business from a "is it worth it" POV, I'm pulling in about $2.50 an hour. It's clear that I would have been much better off working at McDonalds 5 hours a night, 365 days a year for the past 7 years than working on the ECU+.


Bah, that calculation is flawed because it doesn't count how much people praise you for such a great instrument! Out of those 365 days, do you think anyone will thank you for making a great batch of fries? :D

Don't get me started on that!

Back to my original point -- I guess I don't understand what's under the hood, because I've done one way-only serial communications before, where my device just spits out data that gets rendered in a VT100 terminal. There's never a requirement that the client responds in any way, unless you're talking about XON/XOFF.

So perhaps you're just saying that it is required by the ECU+? And if so, I was simply proposing that you enable it to switch to a "push mode" of sorts and just stream data without listening for a response. The device shouldn't have to ask the ECU+ what data is being logged, because the ECU+ will have this info in the data sent over the serial connection.

You could use XML, which would be really easy for logging parameters, or just create a defined structure for the data and leave it to the client to figure out which byte matches which parameter.

Anyhow, I apologize if I keep blabbing about this. I just don't understand why it would require two-way communications... hmm.. do you have an extra serial port available? :) I don't know which AVR you use.

There definitely is no push mode in there now. I log at 19200 baud, and at 25 of everything per second, there's really no spare time to send extra information. That's why the Windows software requests a bunch of won't-change things at the start of a logging session and uses them as it captures the data. XML is a nice disk-based format, but over a wire, it'd be about 800% overhead for me. Bottom line is that a device that wants to talk to the ECU+ box is gonna have to do two-way comms and work roughly like the Windows software, and that's a relative PITA for some other embedded device. And you'd have to have a heck of a good idea to convince me to implement yet another over-the-wire format, especially since the ECU+ box is very tightly limited as to memory and code space.

Tom
tlcoll1
Site Admin
 
Posts: 1511
Joined: Sun Jun 13, 2004 1:01 am
Location: Odenton, MD

Next

Return to Feature Requests and Bug Reports

Who is online

Users browsing this forum: No registered users and 1 guest

cron