Results 1 to 12 of 12
  1.    #1  
    I just recently saw the Nokia Bluetooth Mouse project which I found through Shadowmite's site. It's one of those of ingenious ideas that seems so simple and so useful, but no one really thinks about. I'm going to try and recreate that code for the Treo 650. If there's enough interest, I'll post future updates and files here, just let me know.

    Basically, the Treo will create a serial connection over bluetooth to a host system on, say, COM1 (/dev/rfcomm0 under Linux). The host system will then translate the bluetooth frames into mouse signals (possibly already accomplished by attaching a serial mouse driver to COM port). On the Treo, software will capture images at regular intervals and segment the image into X number of sub images and calculate and store average RGB values. To determine vectoral displacement the average RGB values for the current image and the last image can be passed into a comparative algorithm and send the new coordinates to the host system. Hopefully there will be no need for server sided translation and the Treo will be able to emulate a serial mouse, even though this wasn't the case in the Nokia project. The guy from the Nokia project suggested that instead of tracking all of the changes in color, that the Treo track the change in position of a certain subimage to be determined by the difference in its average RGB values to all average RGB values minus itself (difficult to explain... sorry).

    Following the footsteps of the Nokia project, I'll be using Java. I know that no sane individual would write (quasi) real time code in Java or for low-level componts which I wil have to code for, but the simplicity and relative efficiency of automated garbage collection offsets for the resource overhead and latency on the Treo. Besides, if I write it in Java, I can work on it during my AP Computer Science class . Using Java will also make it easier to incorporate my (currently very primitive) compression algorithm, since it's also written in Java. But that's outside of the Bluetooth spec and would require a lot of extra coding, so that won't come around for a while.

    The first thing I need to do is find out how to talk to the camera module and get meaningful data out of it (and display that data for the extra "geek factor"). Once I can get the Treo to generate the right data with high success rates, then I'll start figuring out how to get that data to the right destination with the right information. It might be a while until the first release, and even then it'll likely be buggy and more of a proof of concept than something entirely useful. Setting up a development environment might be the most time consuming part. I've never written code for a Treo before or Java on anything other than an x86 platform with seemingly infinite resources (yet I still miss embedded platforms... go figure ).

    If you have any comments or suggestions, please let me know! They'd be very helpful!

    UPDATES AND NEWS
    11/1/2006:
    I've finished setting up the IDE and researching the technical aspects of bluetooth. I am now looking into purchasing camera modules and a spare or partially functioning Treo to start writing code for. Until then I'll be doing "safe" experiments on my Treo using Java and Bluetooth and setting up a formal project page on my site.
    Last edited by kboal; 11/01/2006 at 09:27 AM.
    Prev Name: FrozenCode
  2. #2  
    I'm really interested in this project. I have actually considered myself the idea of making the Treo into a bluetooth keyboard, which should really be a very simple project compared to yours. Problem is, I've not been incredibly fond of my few comp sci classes and that is where my knowledge lacks.

    One annoying thing I've noticed is that the Java implementation on our Treo's does not include the Java Bluetooth class (JSR-82). If it did, the thousands of bluetooth java apps on the net would work on the Treo. How are you going to work around this? What programming environment are you using? I would really like to get acquainted with a free and fairly simple environment for PalmOS programming including bluetooth commands but the task of learning it all is still daunting - haven't found time.

    One suggestion I have is that you might try and finish the serial mouse emulation portion very first, with simple up down left right d-pad input, and compile your first working beta with this functionality. This would be a good starting point and releasing this as a just-for-fun app first will get people interested in your project.

    Do you intend on releasing the code with the app?
    Keep us updated.
  3. #3  
    I've been using the Treo as a keyboard and trackpad for quite some time now. When the Treo was launched, I could use Salling Clicker, but then only the trackpad functionality was there, and, at the time, only on the Mac. Today, Clicker works on Windows as well, but I've switched to using BlueRemote, which implements the full Bluetooth HID profile for both mouse and keyboard. However, no one has implemented the equivalent of the Nokia Mouse project yet - might be neat to see!
  4.    #4  
    Yes, the application will be completely open source.... once it's finalized. I'm also doing this project for a class, so if I were to release the code prematurely the authenticity of the code would be impossible to verify. Kind of a pain, I know, but in the end I'll release the code.
    Prev Name: FrozenCode
  5. #5  
    Quote Originally Posted by Conrad View Post
    I've switched to using BlueRemote, which implements the full Bluetooth HID profile for both mouse and keyboard. However, no one has implemented the equivalent of the Nokia Mouse project yet - might be neat to see!
    That's just what I wanted...... thanks!
  6.    #6  
    Quote Originally Posted by RawsonDR View Post
    That's just what I wanted...... thanks!
    Sorry, in my rush I didn't read your entire post. Working around the absence of the bluetooth API can (hopefully) be accomplished by native function calls. More overhead, but a viable solution (or not... we'll find out ). I'm going to be using the IDE and tools available on the ACCESS developer page. It seems to have everything I'll need and is apparently a derivative of the Eclipse IDE.

    Your suggestion seems very reasonable, and likely a better choice. Nevertheless, it's not as complicated and definitely not as fun, besides it'd be one step away from writing everything in pseudo-code As I said earlier, this project is primarily for a high school course, not necessarily the enjoyment of the world, that comes second. I promise I'll try to follow a quick development cycle though...
    Prev Name: FrozenCode
  7. #7  
    Quote Originally Posted by Conrad View Post
    I've been using the Treo as a keyboard and trackpad for quite some time now. When the Treo was launched, I could use Salling Clicker, but then only the trackpad functionality was there, and, at the time, only on the Mac. Today, Clicker works on Windows as well, but I've switched to using BlueRemote, which implements the full Bluetooth HID profile for both mouse and keyboard. However, no one has implemented the equivalent of the Nokia Mouse project yet - might be neat to see!
    I came to this thread intruiged about using my Treo as a BT mouse. That'd be much handier to have than the BT mouse I'm currently using in my truck for the carputer. Then I read your post and went, "WHOA!" My Treo as a trackpad? Sweet.

    I heard about Salling Clicker years ago when I had a Kyocera 7135. Your post reminded me of it so I downloaded the trial and within 5 minuts I was paying the registration! That is one sweet app! I'm using my Treo as a trackpad for my Mac mini carputer now, and the built-in controls for iTunes and DVD Player are wicked!

    I'm going to try out the keyboard in BlueRemote too, although I already have a ThinkOutside Stowaway BT keyboard, it'd be cool to have all my input devices integrated into my Treo!
  8. #8  
    Quote Originally Posted by Cool Cat View Post
    I came to this thread intruiged about using my Treo as a BT mouse. That'd be much handier to have than the BT mouse I'm currently using in my truck for the carputer.
    That's my application as well. BlueRemote looks promising.
  9. #9  
    I stumbled across this thread and figured I would play with BlueRemote. What a great application! A quick install and I was off and running. I will use it when carpooling because the laptop bounces around which makes typing and doing quickbooks challenging. I will just use BlueRemote on my Treo and just leave the laptop sitting on the seat. Thanks a ton.

    The only problem I find with BR is getting a decimal point when in number mode. Makes entering into Quickbooks challengin. I've written the developer but haven't heard back.
  10.    #10  
    Just a quick update...

    I'm still waiting on Sourceforge to either accept or deny the project, they're treating it as an abandoned project takeover which apparently can take up to a few weeks. I also stumbled across a VM alternative for the 650 (SuperWaba) which claims to contain support for bluetooth. This seems like a much more efficient solution than instantiating the C++ API, and might prove to be a reasonable alternative...
    Prev Name: FrozenCode
  11. #11  
    I think its fake. Here are my reasons:

    1) Look at the video of his hand holding the phone. The shadow of his hand is casted over phone. Couple that with how he's holding the phone pretty much over the pad, theres NO light for the camera CCD to even get a clear image. (with all that talk about calculating RGB values, it would imply he's getting a VERY colored & detailed pic, which I doubt is the case). Furthermore, at the distance he claims (<1cm), theres no way you can capture a clear image. The camera phone certainly isn't equipped with a proper lens -- try taking a simple macro shot and see what you'll get.
    2) a standard optical mouse samples at atleast 125hz (i.e., 125 frames per second). A typical camera phone likely grabs at most 30 frames/sec? From the videoclip that window is being moved fairly smoothly -- WAY too smoothly IMO.
    3) a software solution for tracking vectoral displacement? a software solution, let alone using java, would require a fair amount of CPU power to process the xxxx # of images PER SECOND. Doing this in Java? On a phone? I highly doubt it...
    Last edited by Comatose; 11/08/2006 at 11:37 PM.
  12.    #12  
    Sourceforge accepted the project. For now I'm using http://sourceforge.net/project/tbluemouse as the homepage, but by Monday I'll have a page setup at http://tbluemouse.sourceforge.net which will redirect to http://EsotericNet.com/TreoMouse/

    As for the video being fake, I think you're mistaken.

    1)
    The framerate (FPS) on the Treo 650 is ~30 (NTSC Std: 29.97).

    The image capture rate on optical mice are >100 images per second.

    The framerate is not the same thing as the image capture rate (in either direction)

    Framerate describes the speed at which images are displayed on the screen. The image capture rate on mice is dependent on the camera hardware. The framerate is independent (to an extent) and likely uses buffers to store captured images until they are ready to be displayed. Your 30 FPS then translates some larger number which is likely capable of operating similarly to your 125MHz mice.

    2)
    The clarity of the image is irrelevant so long as it is consistent. I neglected to define "significant deviation", but it does not mean bright pink pixels on a black surface. RGB values of (6,7,8) and (10,11,12) are both nearly identical shades of a very dark grey on a macroscopic level, but still differentiable in the code. These subtle differences are signficant enough for the sake of the code.

    3)
    You are confusing your terms in stating that the clock rate is a bottleneck in the system. The clock rate is a measure of the number of instructions per second (or cycle, I don't remember). Unless you're running conditionals for every subimage, you won't notice too much of a performance hit, even with a relatively complex algorithm. I think what you're thinking about (correct me if I'm wrong), related to the apparently smooth operation, is the speed at which the images can be accessed. That is dependent on the hardware interface, but should be fast enough to load up the buffers. It's the buffers which caused such smooth operation.

    As far as the language, I can't imagine a better reason for using Java. Java is meant for things like handling images.. it's the low level hardware addressing which is an issue, which can be compensated for using the JNI (implemented in the MIDP2.0 spec), or if the code seems reasonable using Java API functions. The latency is caused by the high level nature of the VM itself. Again, the consistency here makes it okay. What is a problem is the unpredictable latency which is caused by periodic garbage collection. That's a horrible thing to have when dealing with real time task management. That's what will make the code fun to write; finding a way to make it work...

    From what I've gathered so far, this application is very much viable. I had also E-Mailed the author of the Nokia version and he sounded like he knew enough to have actually written it himself.
    Last edited by kboal; 11/09/2006 at 10:26 AM.
    Prev Name: FrozenCode

Posting Permissions