Out of interest (this is a question for Thom I guess), why is the N800 orbiter so responsive (in terms of volume control, skipping forward/back, any repetitive button presses) in comparison to the touch orbiters? Also the N800 ALWAYS displays the correct screen, in that it never needs to be refreshed - is there some fundamental reason for this?

I assure you this isn't a dig at your work darrenmason, I am just curious.

Cheers,Matt.

The Orbiter runs natively on N800. By that it connects directly to the server, responds to and creates its own DCE messages and then renders the user interface to the N800 using native libraries.

The android orbiter or any of the touch orbiters that have been developed and also the web orbiter rely on a proxy orbiter. What this is, is the same orbiter described above that runs natively on the N800 is running on another linuxMCE machine (typically the CORE). This orbiter is not rendering it's user interface to local libraries but is instead rendering to a bitmap - which is effectively a snapshot of the screen.The touch orbiters then connect (typically via wireless) to the proxy orbiter and retrieve the bitmap. It is then displayed on the remote device which listens for touch commands on the bitmap. Those touches are sent back to the proxy orbiter which then reacts by updating the UI and rendering a new bitmap. This is then sent back to the touch device.

So each touch will at a minimum involve the rendering of a new bitmap and transferring that to the remote device. This takes time and introduces the lag that you are seeing in interactions that involve a lot of repetitive key presses. There is also some code in the proxy orbiter that allows a flag to be set when the display updates independant of a user touch. The problem is that the remote device needs to poll for this flag as the communications with the proxy obriter as essentially client server. Depending upon this polling interval - there will be a lag associated with these updates. Additionally if that flag is not being set correctly then there may be inconsistencies with what is on the screen and what has been rendered.

Ways to improve;* Write a native orbiter for the device or more correctly port the orbiter code to a device. This is easier on devices that support the same runtime libraries as Orbiter has already been built with. The N800 platform is better suited to this than Android and/or iOS.* Reduce the work that the proxy orbiter is doing. This can be done by reducing your resolution and therefore decreasing the bandwidth required to transfer the bitmaps back and forth. This could also be done by not sending bitmaps but instead send markup that would be natively drawn.* Reduce your 'AnyNews' polling interval so that refreshes occurr quicker when the updates are from independent events

Keep telling people what is not working the way you want it to though as it will be input for any changes that do get done.

Yeah I had a quick look at this issue as well last night. It seems that the image returned has not been updated yet and it also does not flag anynews properly - suggesting that it is a proxy_orbiter device problem and not the touch orbiter (any variant). When I get a moment might look to see if there is anything obvious that can be done in the proxy orbiter.

Also done a couple of updates to the Android Orbiter. Just need to do a few more tests tonight and should have a new version....

Change log:Added configuration and related code to allow locking the screen orientation in either landscape or portrait. Still allows default behavior as wellAdded a couple of lines of code to give some feedback on touch. This is more playing around at the moment as I don't think it will meet the needs of the people that requested this. But see how it goes and feel free to give some more feedback. It should click and also give haptic feedback (if haptic feedback is on in config)

Anyway - please try and give me some feedback.

RegardsDarren

Hi Darren,

Just downloaded your latest apk above and have tested it on a Samsung Galaxy Mini GT-S5570 (600Mhz ArmV7) running Android 2.2 Froyo. The Mini has a native resolution of 320x240 so its far from being the ideal Android handset to use the Orbiter on! However the install went perfectly smoothly and the config/setup was straightforward too... apart from the screen resolution settings. I initially selected the 320x24 resolution in Web Admin... but this produced a 1/4 screen sized Orbiter in the top left hand quadrant of the screen (in landscape). My colleague had already setup his HTC Wildfire which has the same screen resolution and he determined that 640x480 was the resolution that delivered a full screen Orbiter. When I changed the Mini to that resolution it also displayed the Orbiter full screen.

Anyway the Orbiter works very nicely indeed and is very snappy on my Mini - nice work! The only thing I can say I miss is the refresh indicator which i'm used to seeing on the iOS Orbiters we normally use... not a big thing at all really and more to do with what I am 'used' too more than anything else!

Andrew - What is the refresh indicator? Not sure that I know what you mean. Do you mean like an on-screen animated icon whilst a refresh is occurring?

Hi Darren,

Yes that what I mean. Although it has to be said that the response in normal operation is reliably fast so there is very little time before the Orbiter responds. However there are situations where the indicator is useful... if for example the Core does not respond quite as quickly for some reason. Its minor thing though to be frank. Nice work by the way :-)

Have you any plans for additional features? I'd love to have you update your Orbiter when we have the spec for new Proxy_Orbiter pinned down. If you'd be interested in updating your code when we have a stable API etc let me know ok?

But definitely interested in updating with increased functionality and to utilise additional Proxy_Orbiter features. Send me whatever you have or post whatever is available as I might get some time this weekend to spend on this....

But definitely interested in updating with increased functionality and to utilise additional Proxy_Orbiter features. Send me whatever you have or post whatever is available as I might get some time this weekend to spend on this....

RegardsDarren

No Problem Darren. We're just doing the final debugging of the new QT Touch Orbiter reference App now...we hope to have that ready for distribution over the weekend. I'll keep you updated on how we do on that...but it looks like we will release it this weekend.

I'm experiencing firewall issues. your orbiter works only when I disable the fire wall on the core. the web orbiter works just fine with out any firewall changes. Am i missing something?I added an exception for the correct port on the firewall config tab. Shouldn't this port be open by default?

I'm experiencing firewall issues. your orbiter works only when I disable the fire wall on the core. the web orbiter works just fine with out any firewall changes. Am i missing something?I added an exception for the correct port on the firewall config tab. Shouldn't this port be open by default?

Hmmm... why would the firewall come into play at all? You are using the Touch Orbiter on the LAN side of your Core so it should not go near the firewall. Provide a schematic of how your system is physically interconnected so we can see how each device is inter-connected etc.

I'm experiencing firewall issues. your orbiter works only when I disable the fire wall on the core. the web orbiter works just fine with out any firewall changes. Am i missing something?I added an exception for the correct port on the firewall config tab. Shouldn't this port be open by default?

As Andrew said, shouldn't go near the firewall. Is your wireless access point on a different network to the LMCE internal one?

I'm experiencing firewall issues. your orbiter works only when I disable the fire wall on the core. the web orbiter works just fine with out any firewall changes. Am i missing something?I added an exception for the correct port on the firewall config tab. Shouldn't this port be open by default?

I can only assume that you are either trying to access the orbiter from an external network, either 3G or Wi-Fi somewhere other than your home.

If that is the case then it is behaving as expected. It is built to establish a socket based connection to the server. If you want an external network to access this server then you will need a path through your firewall. If this is what you are trying to do then I have tested it by tunnelling it over an SSH connection which I would recommend rather than just exposing or port forwarding the proxy orbiter port.

If you are not accessing from external network then as some others have suggested you have a setup issue. Check what IP address your device has received via DHCP should be 192.168.80.X address is everything setup as default. If it is then connection should have no problem to core running on 192.168.80.1 and whatever port is used.

...I have tested it by tunnelling it over an SSH connection which I would recommend rather than just exposing or port forwarding the proxy orbiter port.

I take it you are changing the "LMCE Server" setting to something clever in order to achieve this? Is that all you have to do for this approach to work, or do you have to SSH into the core separately from a terminal or something before you fire up the touch orbiter?