Hi,
this new URC 8603 Xsight Touch, does it have JP1 connectivity?
As said in this review the remote has many disadvantages such as the programming website...
For a special device I have hex codes in the pronto format, but don't know how to get these into that remote. Now first reading about JP1 I remember that I have a remote from a Dreambox 7020 which should have this kind of connector. So the long way would be to programm these codes into the Dreambox remote via JP1 and teach the 8603 with that.
Or I get rid of that "high developed" 8603 and find a simple JP1 with full access even by a Linux-computer.
One for All URC 8603 Xsight Touch
Moderator: Moderators
For now I keep it. I was long time looking for one that has RF and cheap RF-extenders.
But I'm not sure if I like it.
That review is quite good and tells exactly what I don't like about the programming. The website is slow and always requires the remote to be connected.
Then I think the 8603 has a quite noisy buttons sound. It is not possible to do some configurations on the surround processor whithout disturbing the others while watching the movie.
While being new to JP1, I really like that easy connection. Let's see if I can get that JP1-USB adaptor from Germany..
But I'm not sure if I like it.
That review is quite good and tells exactly what I don't like about the programming. The website is slow and always requires the remote to be connected.
Then I think the 8603 has a quite noisy buttons sound. It is not possible to do some configurations on the surround processor whithout disturbing the others while watching the movie.
While being new to JP1, I really like that easy connection. Let's see if I can get that JP1-USB adaptor from Germany..
I'm just studying all these 9xx codes and wonder about Advanced codes or EFC. Can't find something here in the forums.
If I have discrete codes as hex (should be Pronto hex), is it possible to programm a JP1 without cable with that? It is just about 5 buttons I'd like to programm my old Dreambox JP1 with and then teach the URC 8603.
If I have discrete codes as hex (should be Pronto hex), is it possible to programm a JP1 without cable with that? It is just about 5 buttons I'd like to programm my old Dreambox JP1 with and then teach the URC 8603.
Re: One for All URC 8603 Xsight Touch
Spurred on by this and other interest that has been shown in the XSight Touch, I have just bought one with a view to providing support for it in RMIR. At the moment, however, we haven't worked out how to communicate with it. I hope to release prototype support in RMIR for the XSight Lite soon, but the XSight Touch seems to have a different communication protocol.paoleela wrote:this new URC 8603 Xsight Touch, does it have JP1 connectivity?
Graham
Wow, does that mean, you are talking about the USB port of the Touch, if you talk about communication protocol?
This would be marvellous, a huge step. The hardware is ok, it is very flexible, but I guess all people are unhappy about their proprietary website and being dependent. Being able to program it with an open tool would free this, according to the idea of JP1 in general.
So far it is still the only hardware I know of this series that has RF. Using the RF I think it is the only way to really implement macros since its signal reception saver if there is nothing in the way of the RF extender. I guess also these universal remote extenders should work with it (at least the RF->IR part), frequencies are the same, but I did not test.
This would be marvellous, a huge step. The hardware is ok, it is very flexible, but I guess all people are unhappy about their proprietary website and being dependent. Being able to program it with an open tool would free this, according to the idea of JP1 in general.
So far it is still the only hardware I know of this series that has RF. Using the RF I think it is the only way to really implement macros since its signal reception saver if there is nothing in the way of the RF extender. I guess also these universal remote extenders should work with it (at least the RF->IR part), frequencies are the same, but I did not test.
The RemoteMaster program was originally an application for creating and editing device upgrades that could then be loaded into IR.exe, which was the application that could download from and upload to the remote. In recent times, RemoteMaster has been enhanced to include most of the facilities of IR.exe so that it can now be opened in either of two modes, as RM (the original device upgrade editor) and RMIR (the IR.exe-like mode).paoleela wrote:Sorry, but what is the difference between RMIR and RemoteMaster? I have the RemoteMaster sources, and if I start rmir.sh or rmaster.sh both look similar.
IR.exe is no longer being developed, so RMIR is the only program that will support the newer remotes that have JP1.4 or JP2 interfaces or the direct USB interface of the XSight series. IR.exe was a Windows-only program, RemoteMaster works in Windows, Linux and Mac OS X, however the XSight capability is at present being developed only for Windows.
Graham
So rmir.sh only adds -ir to the command I see. So RMIR can do all what RemoteMaster can do and additionally the USB communication? So I would also use RMIR instead of RemoteMaster only?
Good to know that there is some work for the Xsight series. I would like to see that working for Linux too, or at least potentially. I could provide to test it on Linux. This is my only OS and I like to avoid the huge Windows virtual machine which I already need for Internet Explorer for traditional Xsight programming.
Good to know that there is some work for the Xsight series. I would like to see that working for Linux too, or at least potentially. I could provide to test it on Linux. This is my only OS and I like to avoid the huge Windows virtual machine which I already need for Internet Explorer for traditional Xsight programming.
Why is the USB communication different actually for Windows and Linux? Doesn't Java have some abstraction layer there?
Which features would be possible to support for the URC 8603? I don't need that whole icon stuff instead of usual button titles, or the favourite channels.
Macros and devices are the most important, and adding codes from Pronto Hex codes which is not possible at all currently.
At least after having configured all required buttons for all devices by that website, it is very hard to re-arrange the soft-buttons on the touchscreen, since it is only possible to add and remove buttons from the end of the list like a FIFO. So I started to have dummy buttons on every page which I only need to replace. But it is still hard if you delete some button from between (curiously this is possible) but you cannot insert inside the list.
Which features would be possible to support for the URC 8603? I don't need that whole icon stuff instead of usual button titles, or the favourite channels.
Macros and devices are the most important, and adding codes from Pronto Hex codes which is not possible at all currently.
At least after having configured all required buttons for all devices by that website, it is very hard to re-arrange the soft-buttons on the touchscreen, since it is only possible to add and remove buttons from the end of the list like a FIFO. So I started to have dummy buttons on every page which I only need to replace. But it is still hard if you delete some button from between (curiously this is possible) but you cannot insert inside the list.
Windows has very good support for USB generally, and particularly HID devices. A programmer can simply treat a HID device as a file and use standard file system calls to read or write. The prototype system we're testing now with the XSight Lite/Plus or AR ARRX12G uses an enhanced version of JP12Serial.dll which employs these Windows system calls.
I don't use Linux, but Googling suggests that it isn't so easy in Linux.
In any event, Java does not have an hardware abstraction layer for USB or even just HID devices, in the same sense that it has one for disks. There have been some attempts, but again Google tells me that none actually work. Maybe somebody who is familiar with Linux can suggest a path forward.
However, so far, we have only implemented a prototype version for the Xsight Lite/Plus/ARRX12G remotes. The internal structure of these remotes is very similar to JP1.4/2/3 remotes. It is less clear that the XSight Touch/Color have that internal structure, so at this point it is hard to know what may eventually be supported.
I don't use Linux, but Googling suggests that it isn't so easy in Linux.
In any event, Java does not have an hardware abstraction layer for USB or even just HID devices, in the same sense that it has one for disks. There have been some attempts, but again Google tells me that none actually work. Maybe somebody who is familiar with Linux can suggest a path forward.
However, so far, we have only implemented a prototype version for the Xsight Lite/Plus/ARRX12G remotes. The internal structure of these remotes is very similar to JP1.4/2/3 remotes. It is less clear that the XSight Touch/Color have that internal structure, so at this point it is hard to know what may eventually be supported.
Thank you very much for your efforts.
As for Windows having good support for HID: At least my Windows XP in the VMware has much problems to connect to the Xsight. It took me long to find out how to connect. There were always problems in the hardware manager. Before connecting there are 2 HID, one should be my Microsoft mouse. the other I don't know. The third one, which is the Xsight, had always a problem. I always need first to deactivate the 2nd which is not my mouse since this is still working, then disabling and enabling Xsight again, then the Xsight tray icon goes green and is able to connect. So there is some conflict, which is in the way of MS Windows hard to detect.
As for Linux, at least lsusb always shows the Xsight, but has no knowledge in terms of kernel modules. Currently I only need the Windows VM for IE and the Xsight.
What do you mean with "disks"? Raw block device access? Ok, that should not be portable, but using files on filesystems is portable, as well as network access. I don't know which usecase that would be that a Java application should have direct access to the block device, maybe for formatting or partitioning. I read about software emulating Linux block devices on Windows, but sure, this is operating system dependent.
About HID and USB I don't know, but if you say so. Then the work would be doubled, you would need a different JP12Serial for Windows (dll) and Linux (so) for having our own abstraction for JP1.
The other way would be trying to use wine emulation on Linux, but I'd like to avoid using a Java application in wine, which is meant to be as portable as Java is.
I'm using many Java applications on Linux which also work on Windows, sometimes the devs even only develop on Windows. Those all are using files, network, but I can't remember one that's doing USB communication in general, so I can't say.
Interesting, that the underlying structure after leaving JP1 has not changed that much. So cancelling JP1 was more a political decision, be it for avoiding 3rd party software or forcing to use their own programming websites.
As for Windows having good support for HID: At least my Windows XP in the VMware has much problems to connect to the Xsight. It took me long to find out how to connect. There were always problems in the hardware manager. Before connecting there are 2 HID, one should be my Microsoft mouse. the other I don't know. The third one, which is the Xsight, had always a problem. I always need first to deactivate the 2nd which is not my mouse since this is still working, then disabling and enabling Xsight again, then the Xsight tray icon goes green and is able to connect. So there is some conflict, which is in the way of MS Windows hard to detect.
As for Linux, at least lsusb always shows the Xsight, but has no knowledge in terms of kernel modules. Currently I only need the Windows VM for IE and the Xsight.
What do you mean with "disks"? Raw block device access? Ok, that should not be portable, but using files on filesystems is portable, as well as network access. I don't know which usecase that would be that a Java application should have direct access to the block device, maybe for formatting or partitioning. I read about software emulating Linux block devices on Windows, but sure, this is operating system dependent.
About HID and USB I don't know, but if you say so. Then the work would be doubled, you would need a different JP12Serial for Windows (dll) and Linux (so) for having our own abstraction for JP1.
The other way would be trying to use wine emulation on Linux, but I'd like to avoid using a Java application in wine, which is meant to be as portable as Java is.
I'm using many Java applications on Linux which also work on Windows, sometimes the devs even only develop on Windows. Those all are using files, network, but I can't remember one that's doing USB communication in general, so I can't say.
Interesting, that the underlying structure after leaving JP1 has not changed that much. So cancelling JP1 was more a political decision, be it for avoiding 3rd party software or forcing to use their own programming websites.
One for All URC 8603 Xsight Touch: Robustness very fragile
One thing about the robustness of the Xsight Touch: My first unit had a broken VolUp key, this was after half a year. I got a replacement which completely stopped working now after another half year. This happened after a quite soft hit which alway may occur to a main remote in daily use.
Since the warranty of 2 years does not get reset, I'm unsure if I should get another replacement with only 1 year warranty left.
After all the Touch seems to be very fragile compared to the old JP1 remotes. But since I have now a quite functional setup after hours on the annoying web programmer, and I could just copy that setup to a new device I think I go for another one, but fearing the next break.
Seeing the robustness of the old JP1 remotes and the flexibility of the RemoteMaster software, could you tell which of all the OneforAll JP1-capable remotes is the most advanced and flexible? I have around 12 devices to control. I loved the RF-feature of the Touch, being able to control the extender-to-IR and also remote universal PowerSwitches. But since I did not get this installed yet, I could cope with the missing RF as programming by JP1 is going much easier.
Since the warranty of 2 years does not get reset, I'm unsure if I should get another replacement with only 1 year warranty left.
After all the Touch seems to be very fragile compared to the old JP1 remotes. But since I have now a quite functional setup after hours on the annoying web programmer, and I could just copy that setup to a new device I think I go for another one, but fearing the next break.
Seeing the robustness of the old JP1 remotes and the flexibility of the RemoteMaster software, could you tell which of all the OneforAll JP1-capable remotes is the most advanced and flexible? I have around 12 devices to control. I loved the RF-feature of the Touch, being able to control the extender-to-IR and also remote universal PowerSwitches. But since I did not get this installed yet, I could cope with the missing RF as programming by JP1 is going much easier.