Treo 600 Bluetooth Bounty
The folks at TreoCentral have organized a grass-roots e-fundraising drive in search of Bluetooth support for the Treo 600. The drive aims to make a Bluetooth SD card driver available for the smartphone.
Many Treo enthusiasts have been disappointed with the lack of Bluetooth in the current Treo 600 and don't want to have to wait until the next generation treo to get Bluetooth functionality, which is a more than likely feature addition. There are a number of Bluetooth SD cards on the market today, including on from palmOne, yet no driver exists for the card to work with the Treo 600 or any other Palm OS 5 devices.
TreoCentral announced plans to offer a cash reward to the first developer that can bring limited bluetooth functionality to the Treo 600. The bounty, which started with a $100 pledge, is currently over $3100 USD and rising. The driver at minimum must allow for Bluetooth hotsyncing and file transfer. Unfortunately, wireless headset will not be possible as the current SDIO Bluetooth expansion card do not support this service.
The Bluetooth Bounty will expire on September 6, 2004. Any possible driver must be completed before that date to win the bounty.
Permalink
PrintArticle Comments
(8 comments)
The following comments are owned by whoever posted them. PalmInfocenter is not responsible for them in any way.
Please Login or register here to add your comments.
Comments Closed
This article is no longer accepting new comments.
Pathetic
RE: Pathetic
---
David
It should not have come to this
This should not have been necessary. Numerous companies have wireless products available. Practically all of them compatible with the dark side PDAs. Really, palmone must show some cooperation with companies desiring to work to make the necessary drivers.
---------------------
I really need to learn how to program. So much opportunity. I wonder if it is fun though.
Enough with the blame
There always seems to be some kind of conspiracy of Palm trying to milk for money or *wanting* to treat the customers poorly.
Has anybody considered that there are multiple technical problems involved? Not all problems are solvable. A responsible company won't release a buggy product. Even if the product works 80% or 90%--this isn't good enough for commercial release.
Companies other than Palm have had problems with Bluetooth products. Effective transmission with super low powered devices is not easy.
The the folks in Palm management have many plenty of dumb mistakes, but there is no reason for them to stymie a desired product intentionally. Quit imagining the conspiracies.
Let's grow up and stop whining folks.
RE: Enough with the blame
In high tech, there is plenty of incompentance when the MBAs start to steer and make the mistake that the high tech business fits the managemenet models they learned. Palm Computing / Palm / PalmSource / PalmOne management after the first million units shipped is a very good example of this.
Most that post here IMO are doing knee-jerk desktop equipment analogies that just don't fit. With desktop devices, you have plenty of power and space to cut corners to make something integrated and working. Now you have a form factor that is 1/10th the size of a desktop machine, no mechanical standard for accessory attachment and most of all, no open ended driver API for third party developers.
Palm OS devices are embedded systems so treat them like it and not desktop machines. With that here are some hard facts:
* The code base footprint is very tight. Thus you don't have extra CPU cycles for device background tasks.
* Connectors and busses are not as open as on the desktop so a poorly designed attachment doesn't kill the Palm device and Palm's reputation.
* Coding for the Palm OS is still a very specialized skill. You can throw a rock and hit an above the API desktop software developer that needs work. Not so for PDA developers since the best have hardware backgrounds.
* The industrial engineers have more influence over product design. PDAs follow more of the comsumer electronics model over desktop computers. Thus, there is a bit of "sillywood" influence where style has more influence over substance.
* The margins are low. The last five years have shown that "one trick pony attachements" have a very short product lifetime and eventually is designed into the next hardware revision -- no one buys the Pilot beaming attachment anymore since it is built in.
Frankly, I do not see this bounty for a Treo Bluetooth attachment being paid out at all. At best you will have an SDIO hack with an API and third party software developers will work with that. If Bluetooth drivers were technically possible, it would available by now.
My heart goes out to the gargage coders that will try to take this on and find out after a few hundred hours of pointless coding will be for nothing other than learning the hard way.
Write a nice Palm app on a support API and sell it on line. It will pay out better.
RE: Enough with the blame
Perhaps I'm not understanding you (once again), but what is the SDIO specification then?
no open ended driver API for third party developers
Looked like you were talking about the hardware, but this looks like the OS. Well, this limit you talk about dependes on the OS, doesn't it? Looks like other embedded OSes have an easier time coming up with drivers.
The code base footprint is very tight. Thus you don't have extra CPU cycles for device background tasks.
Again, I think I'm not getting your point.
My last 286 had a 16 MHz processor with 1 Mb RAM and 40 Mb hard disk - and did run plenty of non-embedded software. Even Windows 3.1+Word 6. (it was painful, but it DID run there :).
386 and 486 systems at 33 and 66 MHz have been used for every kind of use we can think of, from CAD to servers.
Now, my T3 has a 400 MHz processor and 64 Mb RAM (+ 256 Mb SD), and I can't help feeling that it's positively crippled.
And, as I've said a number of times, you can see that other embedded OSes are having an easier time with a variety of apps and drivers.
Connectors and busses are not as open as on the desktop so a poorly designed attachment doesn't kill the Palm device and Palm's reputation.
Please explain that. Are desktop's connectors and buses "open"? What do you mean?
Have ever "poorly designed attachments" been a problem for "desktops's reputation"?
What is more damaging for Palm* right now, the lack of SDIO or the fear of "poorly designed attachments"?
And anyway, if there were "poorly designed attachments", wouldn't the market be able to sort that out?
Coding for the Palm OS is still a very specialized skill.
Yes, and that's a problem, and looks like that should change on OS 6.
You can throw a rock and hit an above the API desktop software developer that needs work. Not so for PDA developers since the best have hardware backgrounds. Not so for PDA developers since the best have hardware backgrounds.
You can see that developers for other PDAs have an easier time porting existing software.
There's a huge existing codebase that could be being put to use (as others PDAs do). Palm OS is (the?) one that doesn't.
The margins are low. The last five years have shown that "one trick pony attachements" have a very short product lifetime and eventually is designed into the next hardware revision -- no one buys the Pilot beaming attachment anymore since it is built in.
That would explain lack of HARDWARE attachments. But it CAN'T EXPLAIN the lack of drivers for EXISTING hardware attachments; in fact new hardware keeps appearing! But where are the drivers? How can happen that drivers appear for other PDAs, but not for Palm OS? From Palm's very own BT SD card to SanDisk WiFi SD card.
So this really smells, IMHO, to problems on Palm (hardware/OS)'s side. (no, I don't buy on conspiracy theories, thanks. I agree on the "no need for malice when stupidity can explain it" adage :)
Treo Community Powerful
After reading the complete thread at Treo Central I don't personally believe that there is much hope that a developer will create a Treo 600 Bluetooth SD driver solution, especially when it seems that within a few months we will have Treo Ace (http://www.treoace.com) available at least for some networks.
I do think that the community of Treo lovers can do great things together. A good example is the Treo Video software that someone on treoCentral put together. I also got some good skins for the phone application on Treo Central or MyTreo.
On that note, I would like to request that if anyone has an easy (Garbage In - Garbage Out) way to make my MIDI ringtones louder I would like to see an online app like that!
That's my $.02
regards,
Sam Michelson
http://www.younevercall.com/treo600.htm
http://www.younevercall.com - the Treo 600 Source
Latest Comments
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST((SELECT/**/CASE/**/IS_SRVROLEMEM
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST((SELECT/**/CASE/**/IS_SRVROLEMEM
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST((SELECT/**/CASE/**/IS_SRVROLEMEM
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST(db_name()/**/AS/**/NVARCHAR(4000
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST(db_name()/**/AS/**/NVARCHAR(4000
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST(db_name()/**/AS/**/NVARCHAR(4000
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST(db_name()/**/AS/**/NVARCHAR(4000
- My comments --1' OR UNICODE(SUBSTRING((SELECT/**/ISNULL(CAST(db_name()/**/AS/**/NVARCHAR(4000
What is it with PalmOS and SDIO?