Palm. Are you Listening? I've got an Idea. It's good...no really :)

[Rkguy]

Goal: This post is a proposal for a hardware/software product line that is novel for the Palm Pre.

Topics discussed: Developer support to port software, Hardware product design, Marketing.

Product Type: Fuel efficiency products




Why a fuel efficiency product?

1. Automobiles are on people's minds.
   1. You tap into current news and pop culture. Automobiles have made news in relation to fuel prices and conservation, oil independence, global warming, and unfortunately, economic losses as well. Relevance to current culture allows for "viral" marketing.
2. It couples very Very well with your green initiatives and really pulls a lot of green-cred.
   1. Your website shows green practices you use….You can, and honestly should embrace opportunities to encourage and promote use of the WebOS product line for green practices, which parlays well your advertised notion of how WebOS helps you stay more productive, more connected, and more entertained. Why not more green as well?
   2. Other companies (big companies) think this is a big deal. For example, a Nissan study found and 18% improvement in gas mileage based upon realtime feedback about driver’s practices.
3. It allows for more advanced software to showcase your platform!
   1. The Palm Pre and WebOS are perfectly suited to perform a multitude of helpful tasks while on the road but they need to be capitalized upon.
4. It allows for manufacturing of related hardware either by Palm or a 3rd party, increasing revenue or the hardware ecosystem, respectively.

App development methods



There are many options:

1. You can code the entire product in-house.
2. You can outsource development but own IP.
3. You can help one of the existing software developers develop for the platform
   • This is what I think is the preferred method for a number of reasons:
     1. Shows you reaching out to the currently existing developer community
     2. Allows internal resources to remain free for other tasks
     3. Multiple examples of prior art: Three or more companies are currently making software that gives feedback to the user as to his or her driving practices. Some are more advanced than others, even as far as to give advanced engine diagnostics. Others are less expensive and require no additional hardware. The following companies make software for !the iPhone! and windows mobile
        • Ecogyzer
          
        • REV
          
        • Green Meter
          
     4. Showcases your platform advantage vs the iphone
        1. Multitasking! This has been touted so much. There really needs to be more applications that take full advantage of this. Here is a plausible scenario for how your software/hardware platform is better than the iphone.

           You are in the car, recording gas mileage statistics. There is a Greenness indicator on the screen (ala ecogyzer etc). A call comes in and you answer it, taking through the car stereo or speakerphone while still showing a greenness indicator in a notification bar at the bottom of the screen. This shows how your product can multitask
           

           People have said it and said it but this shows how a background process is really SUPER cool and functional. You get more than just a phone, more than a fuel efficiency tool. Not only can you get both (the iphone can do that right now) BUT you get both at the same time! Voila, an excellent example of the OS making software more functional.
           
        2. Synergy! … WebOS is designed so different software products can access or share the same information, Simultaneously.
           • For example, GPS information is available for multiple apps, so a navigation app can use GPS data irrespective of a fuel consumption app.
           • A user can have an option to automatically open related software when running telenav, essentially piggy backing on telenav.-This would also be true of related products like camera identifiers and speed trap alerts.
   • There are also drawbacks to using specialized software
     1. Of course, it goes without saying that if one visual interface were able to simultaneously show navigation, instantaneous gas mileage, speed traps, and even something like upcoming inclement weather in one map interface then the user experience would be more enjoyable than using multiple apps but development time would be considerable and it would limit growth opportunities for new developers.
        1. It should be noted that the visual interface is also aided significantly by the use of notifications, where a notification can exclaim (hopefully in big writing) thing like upcoming speed traps or inclement weather alerts along a specified route (this does of course require a navigation app to share its route with another app, which may or may not be possible).
     2. Another downside is that selection of one product to showcase shows exclusivity given to one company or product over another. It is possible that others will ask for assistance or be frustrated by lack of equal support.

Related Hardware Manufacturing Opportunities



Many uses currently exist for the Palm Pre in the automobile, not to mention possible future uses presented herein. There is an opportunity to create a top quality aftermarket manufacturing product. The following are some important implications of making a custom car mount

1. It possible to allow a third-party to develop and/or sell this BUT a car mount utilizing your existing induction charger technology would require licensing
2. A mount provides a more secure option than using the existing puck and puts unit is good visibility
   • Design should include stable base and sides and a snug fit. To be used in open or closed position
3. Takes advantage of automatic speakerphone as well as automatic music player pause when unplugging from external jack
4. Custom fab may prove useful to maintain cooler temperatures while driving, especially by proper selection of materials (aluminum) in strategic locations around puck.
5. Quick and easy (dis)mount
   • People enter and leave their vehicle frequently when running errands or going out.
   • Reduces concern for battery life issues by minimizing the action a person needs to take to charge their phone when getting in the car. The less thought people give to charging their phone, the less users are concerned about their battery life.
6. Allows you to make good on previous announcements that the puck is the beginning of Touchstone accessories)
7. Would be excellent if it automatically triggered that application or certain application(s) while mounted, not sure how it would distinguish between car and desk.
8. Can be optimized for use with other special HW/software needs.

Current state of software affairs



Having discussed the rationale for this product idea, I will try to describe in a brief but detailed manner how some of the products currently on the market work.

1. One program currently gathers data directly from the ODBII port.
   • ++: Not very difficult to operate. The software is already written and very robust. Very very accurate, capturing more information than competitors. For example, detects that fuel is not delivered to the cylinders when engine braking. Software has additional parameters that some customers may like. Should behave nicely within framework of the sdk. ODBII plug is automatically powered by port
   • --: You do have to purchase hardware from a third party unless it is bundled somehow. Does require communication with the ODBII transmitter over WIFI which uses power, creates some heat.
2. Another program uses a base of aerodynamics (drag), engine efficiency, and power losses (drivetrain) and layer acceleration on top of that.
   • ++: Allows logging of data. This also requires no additional hardware
   • --: Uses accelerometer and needs a higher frequency of accelerometer sampling (4 Hz is not fast enough). - Of course, some have figured out how to change the sampling frequency. - Does not use the GPS but probably should. Instead it currently tells you consumption for various speeds. It also thinks you are accelerating if you stop on a hill (ok in Florida, not gonna work in san francisco). Requires database of automobile characteristics such as drag and parasitic engine loss.
3. A third program I have encountered uses a proprietary box that collects various data and then transmits those data to the cell phone.
   • ++: Highly accurate and a well known company in fleet use.
   • --: Again a third party item would have to be purchased. This one would have to be plugged into the car outlet or powered by batteries).

Getting the word out
How this could really help the reputation of palm.




Embracing the opportunity to support one or more of these developers may have unforeseen benefits.

1. Free advertisement
2. If you accept my suggestion, it shows how you care about an everyday user, that you listen to and are a part of the community. It also shows that the community has some bright ideas
   • With Palm, one person with an idea has the capability to bring people together and make things happen (there's that concept of synergy again). Really embodies the product without having to be corny explicity (that's for the narrow-world of sports. Nice job by the way)
3. Since I am not hired by you, it really comes across as genuine interest in the product and how it can improve our lives. Opens opportunity for positive press. Opportunity to start a "how does your Pre help you everyday" campaign. In essence, you are attacking multiple markets with multiple marketing efforts, mantaining the general ethos of simplicity and life improvement through technology.

Thank you for your time. I figured the stars were aligned, I know I want this but don’t have the time to learn how to create the app. I know someone out there has the expertise to write the software and I know that Palm would love this App on the Pre and maybe even Pixi. I have nothing to lose. Call it Synergy because I think that this can happen.

[chatzvr4]

Basically this is a Datalogger program of some sort. This would be awesome.

[SiniStereO]

So... basically, I'm hearing that you want someone to port the iPhone OBD-II app to WebOS. Why should Palm care about this when Exchange sync is still broken?

Just askin'...

[Rkguy]

Originally Posted by SiniStereO

So... basically, I'm hearing that you want someone to port the iPhone OBD-II app to WebOS. Why should Palm care about this when Exchange sync is still broken?

Just askin'...

Good Question. I think exchange sync is Palm's Problem, encouraging an outside developer is Palm's Opportunity. I think it would take relatively few resources from Palm and yet is a very functional, high level (yet not too graphics intensive) program to showcase the Pre.

P.S. I thought their recent release fixed the exchange problems that were created with exchange sync...I remember them releasing something two days after the big update to correct that.

[Rkguy]

I also think that the green meter approach may be just as valuable, provided a database of drag coefficients for cars or classes of cars is used. Does one exist? I don't know yet

[HRT]

Hi folks,

I am the greenMeter developer. I would love to provide greenMeter on the Pre, and planned to do so earlier in the year. However, there are two main issues preventing it at this time.

The first problem, as you have noted, is the low frequency accelerometer sampling. We need about 50Hz to make it practical, but could skate by with 30Hz (minimum needed to drive smooth graphics).

Second, and more important, is that I need a way to protect my source code, which is extremely sensitive (to competition that is). Right now, there is no secure way to do this within the webOS. I have investigated obfuscation, but it is not good enough.

I was hoping Palm would have addressed these issues by now. I have a bunch of iPhone apps and games that I want to bring to the Pre. I may blog about these topics sometime soon, in hope of getting some action from Palm. Right now they are paying a lot of attention to open source, which is great, but it doesn't address the needs of developers like me.

By the way, regarding your last note Rkguy, greenMeter 2.0 now includes a help wizard that will walk you through determining the input specs for your vehicle based on a very simple interview. It's generally good enough to get within 85-95% of the real specs, which is more than enough for the purpose of the app.

So anyways, thanks for your interest, and I do hope to be on the Pre someday.

Craig

[sacherjj]

Originally Posted by HRT

The first problem, as you have noted, is the low frequency accelerometer sampling. We need about 50Hz to make it practical, but could skate by with 30Hz (minimum needed to drive smooth graphics).

Why does the update frequency control the smoothness of the graphics? Display update isn't linked to data capture. You can have a smooth update with 1 Hz, it all depends on how you are applying the acceleration input. The thing it would do is make a slight lag in the data, but animating between readings with 250ms durations would make the animation of a 4 Hz data set perfectly smooth.

Obviously, if you are integrating the reading or doing other calculus computations on the stream, it gets harder with display, but I've never used you iPhone app so I might be missing something.

(None of this is to say that I don't hope Palm increases this speed soon. )

[HRT]

Originally Posted by sacherjj

Why does the update frequency control the smoothness of the graphics? Display update isn't linked to data capture. You can have a smooth update with 1 Hz, it all depends on how you are applying the acceleration input. The thing it would do is make a slight lag in the data, but animating between readings with 250ms durations would make the animation of a 4 Hz data set perfectly smooth.

Obviously, if you are integrating the reading or doing other calculus computations on the stream, it gets harder with display, but I've never used you iPhone app so I might be missing something.

(None of this is to say that I don't hope Palm increases this speed soon. )

Unfortunately, I can't link to the greenMeter website to show screenshots or demo movies because I am new to the forum, but it comes down to the complexity of the computations and rendering.

Computationally, the app is integrating Newton's 2nd Law with a backward step scheme, using the most current accelerometer reading and the previous one. Accuracy of that scheme is directly proportional to the time step. For my other app gMeter, 50-100Hz is a requirement to get accurate vehicle performance. The greenMeter app is a little more forgiving, and can get by with 40-50Hz, or 30Hz if you don't mind a little error.

The rendering could be interpolated between the coarse 4Hz steps, but there are two problems, one being the necessary introduction of lag you noted. The second would be that using interpolation fundamentally means we're clamping the computed derivative unnaturally; even if this was only used for rendering, I believe the results would be un-physical enough to be noticed. Just as good physics make a game realistic, they also have a big effect on the realism when you're mimicking gauges and other types of automotive displays that are intimately linked to the vehicle's motion. Right now, the displays in greenMeter are very responsive and natural looking. I think adding lag and stepwise interpolation would be a step backward.

[VeeDubb65]

I know that this doesn't provide a long term development solution until Palm gives developers like you more access to the underpinnings of the system, but there are a few short term fixes that may help you on your way.

1. If you look around the homebrew community, you'll find a project for the accelerometer service, which allows you to adjust the sample rate of the accelerometer. I doubt that it would make it into the app store in it's current state, and it hasn't been updated recently, but the proof of concept is there.

2. There are also several programs that run an actual command line including a terminal application and an emulator for some ancient gaming system.

I fully realize that these are not app-store friendly, but they do provide the proof of concepts you need to do port your software. While it would obviously NOT be in your best interest to fully develop solutions based on these, they may allow you to lay some groundwork in anticipation of Palm releasing a more complete SDK.

[HRT]

Originally Posted by VeeDubb65

I know that this doesn't provide a long term development solution until Palm gives developers like you more access to the underpinnings of the system, but there are a few short term fixes that may help you on your way.

1. If you look around the homebrew community, you'll find a project for the accelerometer service, which allows you to adjust the sample rate of the accelerometer. I doubt that it would make it into the app store in it's current state, and it hasn't been updated recently, but the proof of concept is there.

2. There are also several programs that run an actual command line including a terminal application and an emulator for some ancient gaming system.

I fully realize that these are not app-store friendly, but they do provide the proof of concepts you need to do port your software. While it would obviously NOT be in your best interest to fully develop solutions based on these, they may allow you to lay some groundwork in anticipation of Palm releasing a more complete SDK.

We're aware of the AccelService from WebOS Internals, but you're right, we are waiting for official SDK support. But frankly, vulnerability of source code is by far the biggest concern right now; I can work around the other issues, but not that.

[VeeDubb65]

Originally Posted by HRT

But frankly, vulnerability of source code is by far the biggest concern right now; I can work around the other issues, but not that.

I'm really sorry to hear that. I completely understand your concerns about protecting your intellectual property, and sadly have nothing useful to contribute to help you on your way.

I certainly hope that Palm sees the importance of this before too long, and starts giving developers what they need to develop serious software.

[Rkguy]

Originally Posted by HRT

We're aware of the AccelService from WebOS Internals, but you're right, we are waiting for official SDK support. But frankly, vulnerability of source code is by far the biggest concern right now; I can work around the other issues, but not that.

I apologize for asking an elementary question butwhat does palm say they are doing now to help protect source code or rather maybe I should ask how the development process is supposed to work in the webos ecosystem. Honestly it surprises me that palm does not have a method of protecting source code. Gone are the days of submitting binaries?

a big thank you to showing up. You don't know how excited I was to see your reply

[VeeDubb65]

Originally Posted by Rkguy

Gone are the days of submitting binaries?

I'm not a developer, and I'm sure one will correct me if I'm wrong, but my understanding is taht WebOS apps are not binary at all. They are written purely in javascript, html and css, so once the app is installed there's absolutely nothing to stop someone from opening up the file system and reading the code.

[HRT]

Right, the javascript source code in webOS apps is plain text. You can use a technique called obfuscation to encode or encrypt it, and make it unreadable (or simply harder to read). Unfortunately, javascript is always accessible at run time through a debugger or profiler tool. Javascript is an interpreted language, which means it doesn't get compiled ahead of time, but instead gets "translated" at runtime.

You can keep most people honest with obfuscation, but a knowledgeable developer can get to the source code quite easily. It's an intellectual property quagmire. Since I'm a small developer, I'm most concerned with the idea of a competitor taking advantage of all the hard work I put into the app. iPhone apps get blatantly copied / duplicated all the time, and that's without access to the source code. In webOS apps, you can access everything inside the app bundle.

I raised this issue with Palm a couple months ago, but got a boilerplate reply. They recommended trying obfuscation and said they were looking into other solutions.

[HRT]

Originally Posted by Rkguy

I apologize for asking an elementary question butwhat does palm say they are doing now to help protect source code or rather maybe I should ask how the development process is supposed to work in the webos ecosystem. Honestly it surprises me that palm does not have a method of protecting source code. Gone are the days of submitting binaries?

a big thank you to showing up. You don't know how excited I was to see your reply

Glad to be here. Hopefully it will payoff someday!

I think Palm is playing up the open angle of the webOS and all the apps. In fact, you can look at the source of any of their apps too. This is good for people trying to learn, and it will help to advance the platform forward much like you see in the Linux world. But at the same time, it will probably limit appeal to many commercial developers (also like Linux in some ways). I sort of see that with the existing apps available for the Pre. They appear to be low-risk ways to dip a toe into the pool. The real barometer will be when a big-dollar developer puts a well-known big-dollar app on the Pre. I will be watching that very carefully.

[punzada]

While the SDK is based around javascript/html/css for the UI aspect there are ways to speak to the back end and have manipulation from binary services. I'm only a hobbyist developer at best but wouldn't creating this back-end binary with all your protected code and have it feed the UI (in a typical client-server model) solve this issue?

Also, I have to interject that the limited commercial appeal for developers in the x86/64 Linux world is much more to do with limited consumer user-base then anything else. There are many closed and proprietary binary solutions for the platform, it's kind of a poor comparison between this issue and the openness of webOS.

[HRT]

punzada, you need to sell the native SDK approach to Palm -- the ball is squarely in their court on that one. I'll be glad to use any tools they provide that can get the job done.

Sorry if I wasn't clear on the Linux comparison -- I was talking about two similarities to Linux (openness and limited commercial appeal), but not trying to imply they were related/connected on Linux.

[jrmnet]

I know this doesn't apply to webos, but in reply to the post that started this thread, it looks like palmos had and app that interfaced to the OBD connection:

www[dot]qcontinuum.org/obdgauge/

It would be cool if you could plug in an adapter to the OBD port that transmitted the necessary data to the pre via bluetooth. Something like this:

www[dot]dealextreme.com/details.dx/sku.16921

[Kasracer]

Originally Posted by HRT

Right, the javascript source code in webOS apps is plain text. You can use a technique called obfuscation to encode or encrypt it, and make it unreadable (or simply harder to read). Unfortunately, javascript is always accessible at run time through a debugger or profiler tool. Javascript is an interpreted language, which means it doesn't get compiled ahead of time, but instead gets "translated" at runtime.

You can keep most people honest with obfuscation, but a knowledgeable developer can get to the source code quite easily. It's an intellectual property quagmire. Since I'm a small developer, I'm most concerned with the idea of a competitor taking advantage of all the hard work I put into the app. iPhone apps get blatantly copied / duplicated all the time, and that's without access to the source code. In webOS apps, you can access everything inside the app bundle.

I raised this issue with Palm a couple months ago, but got a boilerplate reply. They recommended trying obfuscation and said they were looking into other solutions.

I would agree that obfuscation is a fundamentally flawed approach to protecting source code but I don't see this as being an issue.

How do you think early iPhone development began? Simple, developers decompiled different pieces of the iPhone, reversed engineered the APIs and got some applications working.

iPhone applications can be decompiled into ASM or even Objective-C. Sure, you won't get the exact, original, code but it might be pretty close. Obfuscation buys you basically the same-thing and, depending on the decompiler / obfuscater used, it may be harder to figure out what's going on than decompiling a native application. Why? Well, really good obfuscating applications will overload methods, wrap API calls, and do some really crazy things that decompiled code wouldn't exhibit.

I understand that you want to protect your code but I think that's silly. If your iPhone application is built with debugging symbols then anyone can just grab all of your variables / methods and watch the application execute with ease. If the symbols are gone, there are ways of intercepting the API calls to Cocoa then extrapolating the math behind the calls. A simple decompile into Objective-C is always an option as well which would allow the offender the ability to run the app in debug mode and figure out how it works.

Remember, .Net and Java work just like webOS applications in that everything is easily visible / decompilable and yet those areas are thriving. If someone wanted to steal your source, they would have done it by now.

I do agree that there should be a compilable option for webOS development so applications are faster and more efficient but maybe that'll happen (they have come out and said they know we want it).

[Rkguy]

Originally Posted by HRT

punzada, you need to sell the native SDK approach to Palm -- the ball is squarely in their court on that one. I'll be glad to use any tools they provide that can get the job done.

Sorry if I wasn't clear on the Linux comparison -- I was talking about two similarities to Linux (openness and limited commercial appeal), but not trying to imply they were related/connected on Linux.

FYI

http://forums.precentral.net/web-os-...lerometer.html