Joined
·
4,525 Posts
See today's anncoucement.
Pronto Killer - Finally, a PDA Remote!
- Status
1 - 11 of 11 Posts
I'm more excited about the stuff forum members are brewing...
http://www.avsforum.com/ubb/Forum12/HTML/013090.html
The sony thing is still IR. one-way, directional, unreliable IR.
the custom ipaq could have two-way, reliable communication with HTPC using RF Ethernet. Then just automate everything from HTPC.
Just think if the members attacked this problem like they did with dScaler...
http://www.avsforum.com/ubb/Forum12/HTML/013090.html
The sony thing is still IR. one-way, directional, unreliable IR.
the custom ipaq could have two-way, reliable communication with HTPC using RF Ethernet. Then just automate everything from HTPC.
Just think if the members attacked this problem like they did with dScaler...
Joined
·
455 Posts
I've just got my new ProntoPro and I'm thrilled with its capabilities and interface. The design features are unlimited with the ProntPro Edit software! I guess I'll never stop changing it...
Like Suutar, I have no intentions of leaving my PocketPC at home just for controlling the HT. The ability of having the PocketPC running as a universal controller is indeed a great feature, but I prefer to have my own dedicated controller. I just imagine different people (or even myself) putting their dirty fingers at the screen of my PocketPC (I can't imagine someone controlling a HT using the pointing device!). There are other limitations, from my point of view, as consuming the batteries of the PocketPC (remember, it will be used mainly for other things), leave your personnal data vulnerable to other people (even if you have nothing to hide, there is always a change someone screw up and loose your data - yes you can always syncronize again, but...)
Maybe if you're gonna be the only one controlling the HT this is a better idea. But I still prefer the dedicated remote. The Pronto is great and now I'm getting the Ocelot and entering the X-10 world...
So let's say this maybe a good idea (even great for some people) but it is no Pronto Killer!
Like Suutar, I have no intentions of leaving my PocketPC at home just for controlling the HT. The ability of having the PocketPC running as a universal controller is indeed a great feature, but I prefer to have my own dedicated controller. I just imagine different people (or even myself) putting their dirty fingers at the screen of my PocketPC (I can't imagine someone controlling a HT using the pointing device!). There are other limitations, from my point of view, as consuming the batteries of the PocketPC (remember, it will be used mainly for other things), leave your personnal data vulnerable to other people (even if you have nothing to hide, there is always a change someone screw up and loose your data - yes you can always syncronize again, but...)
Maybe if you're gonna be the only one controlling the HT this is a better idea. But I still prefer the dedicated remote. The Pronto is great and now I'm getting the Ocelot and entering the X-10 world...
So let's say this maybe a good idea (even great for some people) but it is no Pronto Killer!
The work I had started towards the ePod - Girder app that is mentioned in the thread above hasn't progressed very far. My approach was for a full embedded Visual C++ MFC app with configurable button layout, multiple screens, Girder application extensions, etc. My test app used static buttons with static control strings and the plain vanilla Girder TCP/IP plugin. I can send my source code to anyone who would like to play with it, although you need to download the embedded Visual C++ compiler from Microsoft. It was available free for private use a couple months ago, and I believe that it still is. It's a TWO CD download, so it helps to have a broadband connection.
In terms of coding for the ePods. I found it easier to develop the code using Visual C++ 6.0 on my Win2000 machine to test and debug. If it worked under 6.0 it should work with a few mods under embedded C++. So the easiest thing for me was to copy the project (.dsp, .rc, .etc files) and source code over to embedded Visual C++. This required some updates to the includes, some mucking with the MFC class names and control interfaces, and finally updating the project settings to use MIPS code generation, Windows CE 2.12 target platform, ActiveSync mechanism, etc. I'm making it sound harder than it is, but it does take a while to figure it all out. It also helps to be familiar with MFC before trying to port Visual C++ 6.0 MFC code over to embedded C++ MFC.
Others were working with Visual Basic and seemed to have progressed farther along.
As a concept I think Girder control using a wireless (wireless Ethernet, IR, bluetooth, etc) TCP/IP connection has lots of potential. Two way communication is a feature that cost $$$$ in high end systems, but with the right software it could be implemented for a few bucks on a HTPC. There are some interesting problems that need to be solved with regards to application status reporting. Namely, a standard way of getting application status information. Intercepting windows messages could work, but the individual messages need to be decoded and that requires understanding the proprietary data in each message. Girder already can do something like this.
however, there is no hard requirement that an application send a windows message to change the state of control or reports the state of a control. It's how MFC works, but if you program your application using other software tools and techniques there are ways to avoid the windows message queue. This would make the message capture technique useless.
IMHO, In the media player world it would be very cool to have a COM/ActiveX like interface that Girder could query for application control and status interfaces. Interface statndards would need to be specified. (Microsoft is really good at this type of stadardization, but they tend to leave application programmers alone and let them do whatever comes to mind) Perhaps, manufactures would release Girder configuration files that specifies how Girder can access these interfaces. One can dream...
In terms of coding for the ePods. I found it easier to develop the code using Visual C++ 6.0 on my Win2000 machine to test and debug. If it worked under 6.0 it should work with a few mods under embedded C++. So the easiest thing for me was to copy the project (.dsp, .rc, .etc files) and source code over to embedded Visual C++. This required some updates to the includes, some mucking with the MFC class names and control interfaces, and finally updating the project settings to use MIPS code generation, Windows CE 2.12 target platform, ActiveSync mechanism, etc. I'm making it sound harder than it is, but it does take a while to figure it all out. It also helps to be familiar with MFC before trying to port Visual C++ 6.0 MFC code over to embedded C++ MFC.
Others were working with Visual Basic and seemed to have progressed farther along.
As a concept I think Girder control using a wireless (wireless Ethernet, IR, bluetooth, etc) TCP/IP connection has lots of potential. Two way communication is a feature that cost $$$$ in high end systems, but with the right software it could be implemented for a few bucks on a HTPC. There are some interesting problems that need to be solved with regards to application status reporting. Namely, a standard way of getting application status information. Intercepting windows messages could work, but the individual messages need to be decoded and that requires understanding the proprietary data in each message. Girder already can do something like this.
however, there is no hard requirement that an application send a windows message to change the state of control or reports the state of a control. It's how MFC works, but if you program your application using other software tools and techniques there are ways to avoid the windows message queue. This would make the message capture technique useless.
IMHO, In the media player world it would be very cool to have a COM/ActiveX like interface that Girder could query for application control and status interfaces. Interface statndards would need to be specified. (Microsoft is really good at this type of stadardization, but they tend to leave application programmers alone and let them do whatever comes to mind) Perhaps, manufactures would release Girder configuration files that specifies how Girder can access these interfaces. One can dream...
Joined
·
1,007 Posts
you've got to remember that some of us hold our Prontos close to our hearts. Be more sensitive next time
I use my pronto with the receiver from the philips kb power buy. Works great!! Yesterday I started using it for web browsing. With the pronto in mousemode, I just use a stylus to move the mouse cursor around the screen. The bottom hard buttons are used as mouse buttons, and I programmed vol +- to be scroll up and down. mute is back button. There are still channel +- which I haven't figured out what to use for them yet.
You could get this function using a cordless trackball of course, but I don't have to drop anything when I decide to turn on the lights, or control any IR equipment, including the pc. This makes it very easy to just sit back on the couch and hold the pronto and control anything.
I use my pronto with the receiver from the philips kb power buy. Works great!! Yesterday I started using it for web browsing. With the pronto in mousemode, I just use a stylus to move the mouse cursor around the screen. The bottom hard buttons are used as mouse buttons, and I programmed vol +- to be scroll up and down. mute is back button. There are still channel +- which I haven't figured out what to use for them yet.
You could get this function using a cordless trackball of course, but I don't have to drop anything when I decide to turn on the lights, or control any IR equipment, including the pc. This makes it very easy to just sit back on the couch and hold the pronto and control anything.
These remote control software programs for PDA's have been around for a while. I tried one out once a couple of years ago on a WinCE device. It was OK. One advantage that the Pronto has which is a HUGE advantage is the operating angle. (For lack of a better term) With the PDA I had to point it directly at the device that I wanted to control. With my Pronto I can be way off and it the device will still receive the code. Looking at the new PDA's I have a Palm V, VII and an IPAQ (my wife is a wireless developer so she gets all the wireless toys from work) and a few others they don't look like they can be used too much off angle.
Dino
Dino
Quote:
That sounds pretty cool. Are those Phillips KB receivers still available? I recall something about the powerbuy being a one time thing. Also, can you use it in conjunction with an Airboard? Or, is the Phillips KB just as good (or better).
Regarding the button mapping - how about mapping chan up, down as enter and backspace? And how about mapping a button as "Escape"?
- Dave
| Originally posted by hmcgrath I use my pronto with the receiver from the philips kb power buy. |
Regarding the button mapping - how about mapping chan up, down as enter and backspace? And how about mapping a button as "Escape"?
- Dave
Joined
·
1,007 Posts
the limited availability is why we had to use the power buy to get these. I'm not sure if you can find any.
The receiver which came with the powerbuy is the only one that will work with the pronto's mousemode feature. That I know of.
I have mute as backbutton. The others could easily be mapped to any keyboard shortcuts.
Although the mousemode is cool, using Girder software and an IRman receiver you could really bring the pronto to its full potential.
The receiver which came with the powerbuy is the only one that will work with the pronto's mousemode feature. That I know of.
I have mute as backbutton. The others could easily be mapped to any keyboard shortcuts.
Although the mousemode is cool, using Girder software and an IRman receiver you could really bring the pronto to its full potential.
Joined
·
888 Posts
What a PDA remote like the sony palm device needs is a Pronto CCF parser to take advantage of all the free CCF files out there. Other than a remote-codes database, it shouldn't be too hard to come up with such a beast - perhaps someone already has?
There are some Pronto ccf parsers here:
http://remotecentral.com/files/util.htm
If we were developing our own PDA based RF remote, we could use the ccf format and use pronto edit as the gui development tool. That would be a good start, but we would later want mechanisms to exploit the two-way RF link. And Phillips might have an issue with us using their format and their software...
http://remotecentral.com/files/util.htm
If we were developing our own PDA based RF remote, we could use the ccf format and use pronto edit as the gui development tool. That would be a good start, but we would later want mechanisms to exploit the two-way RF link. And Phillips might have an issue with us using their format and their software...
1 - 11 of 11 Posts
- Status
Join the discussion
