NX clients should be able to relay location (GPS) and compass data.

[brigman]

NX clients should be able to relay location (GPS) and compass data to the server as part of the NX protocol. This way, an old tablet with poor processing capabilities can remote into a vastly superior device and still be useful for navigation.

Just to clarify: I use Samsung Galaxy Tab S devices (SM-T805) to remote into my home PC running Windows 10 over the 4G network. I currently use RDP for this. I can’t use navigation apps on my home PC because, well, it always shows its location as “my house”. If the data from the tablet’s onboard location and compass devices could be relayed to the ‘server’ over NX then I would ditch RDP for NX and this problem would be resolved. This data would use considerably less bandwidth than the existing option to relay microphone audio.

Of course, it would be doubly awesome to remote into a custom Android VM that is running on my PC, but that’s another issue. Anyway, I see this as significantly improving the usefulness of devices that are becoming computationally inadequate.

[Carin]

Hi brigman,

It is a very interesting idea, indeed. However, our product roadmap priorities are focused elsewhere and to relay location (GPS) and compass data to the server as part of the NX protocol is not foreseen for the moment.

Many thanks for sharing your suggestion.

[brigman]

Hi Carin,

Thanks for the response. It’s a pretty trivial implementation client-side, certainly no more complex than relaying mouse and keyboard input to the server as the compass and GPS devices typically just generate location and orientation data as ascii at 96oo bits per second. The majority of the coding effort would be generating virtual GPS and compass devices server side. That said, I don’t think the total coding effort would be that large — I’d be happy to help.

Sure, I’m biased because I find this feature personally desirable, but I think you are overlooking an opportunity to set yourselves ahead of MSRDP in yet another non-trivial way. The use cases are infinite, a central server that knows the location of all remote terminals — flight control, you name it. Please reconsider.

[Britgirl]

Hi brigman, indeed relaying the location and compass data from the client-side device to the server would require minimal effort. I agree that this could be a useful feature to have, so we’ll definitely evaluate doing this. Do you just need it because the navigation program you are using happens to be on the server?

[brigman]

That is the sole reason I personally need it, yes, but imagine an advantage to centralising vehicle tracking and co-ordinating logistics.

While you are considering that, consider relaying as much live data from client sensors as you can — accelerometers/gyros’, light sensors. If you create the conduit, developers will choose your platform — that’s where it starts to snowball. Let’s face it: you guys have had a technologically superior solution for 20 years and it is, developmentally, very mature. Give it everything it needs to get the success it deserves.

[Author]

Posts