Using a PDA as a bike computer?

Is there any way to hook up a pda as a cycle computer, to register speed, distance, time, etc? If so, it would also be nice to connect it to the motor to keep track of the temp of the motor, to measure discharge rate of the battery, estimated miles of electricity left, etc. Is this stuff out there? If not a pda how about a small notebook computer - the size of a Toshiba Libretto? something that has full scale usb functionality? Please feel free to touch on any peripheral issues as well. I want to think tank, and sometimes bunny trails help.

I think Amberwolf uses a Palm for his telemetry.
otherDoc

first thing, most pda's don't have USB host ability.

second, you need a way to convert digital and analog inputs to either serial or USB, or even bluetooth.

I'm surprised there isn't more interest in this. USB host capability is built into the hardware of a lot of newer smartphones (USB On-The-Go). Software support is a hot feature request for the Android platform. Maybe some day soon...

http://code.google.com/p/android/issues/detail?id=738&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars

A wireless link sounds cool, but Bluetooth hardware seems almost prohibitively expensive for low volume stuff. Anyone know if newer PDAs or smartphones support wireless protocols that are intended to be lower cost/power? I'm not an RF expert, but Zigbee comes to mind...

but just having USB OTG support doesn't mean that its easy to add hardware. You need a driver written for that specific device. Most of the support thus far is for keyboards and flash memory.

bluetooth rs232 devices can be gotten for under $20, but again, you need your OS to support the serial bluetooth protocol.

here's one for under $10
http://cgi.ebay.com/Mini-Bluetooth-Wireless-TTL-Transceiver-Module-rs232_W0QQitemZ300449416850QQcategoryZ16145QQcmdZViewItem#vi-content

Hi - I am using my iPhone with the app called every trail and it seems good accurately.


more info: http://ruedatropical.wordpress.com/2009/02/11/iphone-cycling-applications/

frodus said:

but just having USB OTG support doesn't mean that its easy to add hardware. You need a driver written for that specific device. Most of the support thus far is for keyboards and flash memory.

Click to expand...

Yup. Clearly, there would be some work to do... analog sensors (I, V, temp?), driver, and UI. But I suspect reasonably low cost microcontroller development boards which include USB and ADC interfaces are available off the shelf.

frodus said:

bluetooth rs232 devices can be gotten for under $20, but again, you need your OS to support the serial bluetooth protocol.

here's one for under $10
http://cgi.ebay.com/Mini-Bluetooth-Wireless-TTL-Transceiver-Module-rs232_W0QQitemZ300449416850QQcategoryZ16145QQcmdZViewItem#vi-content

Click to expand...

Neat. That's about half the price of anything I was able to dig up in a quick search. Based on a quick google search, it looks like Android supports serial bluetooth. Still need a way to interface it to the sensor array (small microcontroller development board?).

It wouldn't be hard to get a uC to support analog/digital inputs and have it spit out serial. The problem is how do you get the serial data to a smartphone OS so that it can recognize it. Bluetooth is an option.... but I have seen very little bluetooth serial support on the phones out there. It may have android support, but kernels running on the smartphones do not include that support neccessarily. Just because the OS CAN support it, doesn't mean it is compiled to do so. You need to check your phone to see what support it gives.

I use older PalmOS 3.x devices like the m100 with VeloAce, which does what a good bike computer would do. But it doesn't have any ebike-specific capabilities. It just monitors a simple serial input (either from the dock serial port using any reed switch and magnet, or from IR, if you build a little module) to get wheel RPM, then calculate a bunch of stuff from that.

I really only need the speedo from it, and the odometer. The other stuff is nice enough if it's there, like average and peak speeds, trip time, etc. Interesting is the g-force chart it estimates acceleration with, which looks a lot different with the motor than it does with me pedalling.

Both of my Android phones support bluetooth comunication with my car's sound system, nintendo wii controllers, bluetooth keyboards, etc.

Google released a pretty slick DIY app creation open-source tools set about a month ago, something that is suposed to be simple enough that anybody can create a simple app, and slick programmers can create amazing things with minimal android specific skills.


http://www.techradar.com/news/internet/google-android-app-creator-for-n00bs-launched-702341

Android is also currently the dominate smart-phone OS, and the only smart-phone OS currently in a growth state. The growth charts for android vs iphone vs windblows mobile/7 vs RIM vs palm is fairly shocking. lol Android gaining market share at an amazing rate, apple roughly flat, everything else in delcline. In about ~2 years, I predict most developers will stop bothering to create apps/content for non-android platforms.

This is a little overkill but it would do the trick..and really not much more expensive than a good pda.

Hrmmm... check out this Apple patent. How novel.

http://www.freepatentsonline.com/y2010/0198453.html

What is claimed is:

1. A system for communicating riding characteristics among a plurality of bicycles, comprising: a first electronic device coupled to a first bicycle, the first electronic device operative to: determine at least one riding characteristic of the first bicycle; receive in real-time from a second electronic device coupled to a second bicycle at least one riding characteristic other than location of the second bicycle; and provide the determined and received at least one riding characteristics to a display associated with the first electronic device.

2. The system of claim 1, wherein the first electronic device is further operative to: determine the current position of the first bicycle; receive from the second electronic device the current position of the second bicycle; identify a path to reach the second bicycle from the determined current position of the first bicycle; and provide the identified path to the user of the first bicycle.

3. The system of claim 1, wherein the first electronic device is operative to receive data from at least one sensor connected to a component of the first bicycle.

4. The system of claim 3, wherein the sensor comprises at least one of a cadence sensor, a power sensor, an accelerometer, an incline sensor, a derailleur setting, and a speedometer.

5. The system of claim 3, wherein the first electronic device is operative to provide the received data to the second electronic device.

6. The system of claim 1, wherein the first electronic device is further operative to provide at least one of a text communication, a voice communication and a video communication to the second electronic device.

7. An electronic device for providing cycling information to the users of a plurality of bicycles riding in a group, the electronic device associated with a first bicycle, comprising control circuitry operative to: detect a plurality of electronic devices, each associated with one of the plurality of bicycles; determine at least one riding characteristic of the first bicycle, wherein the riding characteristic comprises at least one of speed, distance, time, altitude, elevation, incline, decline, heart rate, power, derailleur setting, cadence, wind speed, path completed, expected future path, heart rate, power, and pace; and receive, in real-time from each of the detected plurality of electronic devices, at least one riding characteristic of each of the plurality of bicycles.

8. The electronic device of claim 7, wherein the control circuitry is further operative to: determine the current position of the first bicycle; identify at least one cycling path located in the vicinity of the determined current position; and provide the identified at least one path to a display for display.

9. The electronic device of claim 8, wherein the control circuitry is further operative to: receive an indication of an interest from a user; identify at least one attraction located in the vicinity of the determined current position; and provide the at least one identified attraction to the display for display.

10. The electronic device of claim 9, wherein the control circuitry is further operative to: generate a map of the vicinity of the determined current location for display to the user; and include representations of the identified at least one path and identified at least one attraction in the generated map.

11. The electronic device of claim 7, wherein the control circuitry is further operative to: identify the location of at least one of the plurality of bicycles; and direct a display to display the identified location and received riding characteristic for the at least one of the plurality of bicycles.

12. The electronic device of claim 11, wherein the control circuitry is further operative to direct the display to display the identified location and received riding characteristic on a map.

13. The electronic device of claim 7, wherein the control circuitry is further operative to: receive a comparison profile comprising at least one riding characteristic; and direct a display to simultaneously display the at least one riding characteristic of the comparison profile and the corresponding at least one riding characteristic of the first bicycle.

14. The electronic device of claim 13, wherein the control circuitry is further operative to: provide a listing of available comparison profiles, wherein at least one of the comparison profiles corresponds to past riding performances of the user of the first bicycle; and receive a user selection of one of the available comparison profiles.

15. The electronic device of claim 13, wherein the comparison profile comprises at least one riding characteristic that changes based on at least one of the environment of the first bicycle, the location of the first bicycle along a course, the duration of the ride, and the amount of time that the bicycle has been ridden.

16. The electronic device of claim 7, wherein the control circuitry is further operative to receive a user selection of the plurality of bicycles from which to receive at least one riding characteristic.

17. A sensor for use with an electronic device, the sensor coupled to a bicycle and comprising: communications circuitry operative to pair with at least one authorized electronic device; and control circuitry operative to: monitor the movement of at least one bicycle component; determine, from the monitored movement, that the bicycle is in use; detect that the communications circuitry has not received a communication from the at least one authorized electronic device; generate an alert indicating that the bicycle is being used without authorization; and direct the communications circuitry to broadcast the alert.

18. The sensor of claim 17, wherein the control circuitry is further operative to: determine the current location of the sensor; determine the current time; and generate an alert that includes at least one of the determined current location and the determined current time.

19. The sensor of claim 17, wherein the communications circuitry is further operative to broadcast the alert to a remote server.

20. The sensor of claim 17, wherein the communications circuitry is further operative to: detect an unauthorized electronic device; and transmit the alert to the unauthorized electronic device, wherein the alert comprises an instruction to relay the alert to a remote server.

21. The sensor of claim 17, wherein the control circuitry is further operative to: define a region where the bicycle can be used without an electronic device; determine that the bicycle has left the defined region; and generate the alert in response to determining that the bicycle has left the defined region.

22. The sensor of claim 17, wherein: the communications circuitry is operative to detect an authorized electronic device; and the control circuitry is operative to: generate a message canceling the alert; and direct the communications circuitry to transmit the generated message.

http://www.mini-itx.com/store/?c=49#dg41mj

Sorry, I forgot to post the link in my last post.

amberwolf said:

I use older PalmOS 3.x devices like the m100 with VeloAce, which does what a good bike computer would do. But it doesn't have any ebike-specific capabilities. It just monitors a simple serial input (either from the dock serial port using any reed switch and magnet, or from IR, if you build a little module) to get wheel RPM, then calculate a bunch of stuff from that.

Click to expand...

Hrmmm... if you were to hijack the serial RPM sensor input and replace it with a pulse train proportional to battery current, it would count amp-hours instead of miles.

pengyou said:

This is a little overkill but it would do the trick..and really not much more expensive than a good pda.

Click to expand...

The display, IMO, is one of the main reasons why building a little dongle board that interfaces with a cell phone or PDA makes so much sense. That and - in theory - if you have a PDA or smartphone, it's on your person most of the time anyway.

Yes, life would be a lot more useful and less wasteful if all of the cell phone and pda mfg would use the same interface for a/c adapters and for interfacing with other devices...and devices talking to other devices would be a lot more useful/cost effective/practice. USB would do it all for all of them, but no, they have to make their own charger, sometimes a separate one for each individual model of phone, etc. Where do these adapters end up 2 or 3 years later? In some landfill waiting to have the casing cracked so that the toxic elements can spill out into the environment, etc...

Sorry for getting off track here...but where is Ralph Nader when you need him?

busted_bike said:

Hrmmm... if you were to hijack the serial RPM sensor input and replace it with a pulse train proportional to battery current, it would count amp-hours instead of miles.

Click to expand...

True, but then it could not track RPM or distance, as it only has the one port on some of them. Others have two (IR and dock), so if someone were to rewrite VeloAce (I think it is open source) then it could be used to track both. The electronics to convert a shunt's voltage to FM pulses is fairly trivial, but the CA already does these two functions plus others derived from them pretty well, and is probably the best-supported ebike computer (or power meter of any kind) on the planet.

I'd like to see a slightly different UI on the CA, with a larger screen, and certain user-selectable graphics in addition to the text versions, for better instantaneous readability by a potentially distracted (by trying to read the CA) rider. Other than that, the CA does most of the data display functions I'd like to see.

A design that can read battery current, phase currents, etc., as well as read the hall signals (if any), control the lighting, motor, etc., is what I'd ideally like. I have a number of "specifications" worked out for such a device, but am not an engineer and so can't really write the programs nor safely design the electronics. I can hack stuff together really well, but that doesn't mean it's done right for long-term success.