JP1 Remotes

Posted: **Thu Apr 09, 2020 9:30 am**

Hi There,

I switched from cable operator Telenet to Orange.

Apparently they use a ASKEY TCG300 or as the French say a Siligence TCG330 P/N SGA520MB.

The Cable Set-Tob Box itself is a Siligence SGS7233MB

From searching on the French Orange forum I found that for certain other learning remotes (Logitech Hub) one could use the Siligence SGS7233MB.
There seems to be a .bin slingbox file that I translated to a rmdu file, but I can't upload it to the remote.

This seems to work on the Logitech Remote for all keys except 2 (DVR and OPT).

It couldn't learn any of the keys, this was a first for Logitech. Then I remembered that I had a working Xsight AARX18G remote. The reason I switched from my beloved remote was that the Xsight had paint blistering and some keys needed a hulk to operate certain keys.
Something my wife didn't appreciate because of the broken furniture.

The Xsight had no problem learning any of the keys and I have a working rmdu file. Which I would like to share with this forum.

My questions are:

1) How can I share this rmdu file.
2) How can I convert between rmdu and rmir file.
3) Is there a firmware upgrade file for the Xsight. (mine is 1.3.32 bootloader 1.0.2 IRblaster 3201AX7 IR library 1.2.11)
4) How can I upload the Siligence7233MB.rmdu file to my Xsight

Thanks for reading,
Guy Forssman

Posted: **Thu Apr 09, 2020 10:40 am**

1) Click here then click the Upload button:
https://www.hifi-remote.com/forums/dload ... &cat_id=11

2) There is no conversion as they are 2 distinct things. But you can certainly add any RMDU to your Xsight in RMIR by going to the Devices tab, NEW, then OPEN the desired RMDU file. If you have a device in your RMIR file that you would like to save as an RMDU, go to the Devices tab, EDIT the desired device, then SAVE AS, and an RMDU file will be created.

3) No, you already have the latest and final version.

4) See 2

I see the old EZ-RC tray tool in your signature. That's only for the EZ-RC website that's long gone. RMIR doesn't need it. So you can uninstall it.

Posted: **Thu Apr 09, 2020 4:29 pm**

Thanks for your quick answer

I uploaded the rmir file and update the rmdu file.

Thanks for the clarification.

I can't seem to do a device upgrade need to read that part of the manual again.

So I changed a copy of a rmir file to a txt file and I was able to import it.

It seems though that when my XSight learned the key's it couldn't gues the protocol.
The convert to Device Upgrade button doesn't seem to do anything.
Even when I select qll rows

Thqnks for reading

Posted: **Thu Apr 09, 2020 6:09 pm**

What do you mean by "I can't seem to do a device upgrade" because I see you loaded your device upgrade to the file section:
https://www.hifi-remote.com/forums/dload ... e_id=25920

You also loaded your RMIR file isn't the Device Upgrade section, but it doesn't belong there. We generally don't need to see people's RMIR files unless there's a problem that you'd like us to fix, so I have moved it to the Diagnosis Area.

https://www.hifi-remote.com/forums/dload ... e_id=25921

If you're talking about building an upgrade for something else, maybe our wiki section will help, like this one

http://www.hifi-remote.com/wiki/index.p ... y_Is_It%3F

Posted: **Thu Apr 09, 2020 6:18 pm**

So you're trying to convert your Learned Signals to a device upgrade.

I can see from your RMIR file that it does not recognize the protocol which means it's unknown to us, a new protocol we haven't seen before.

In this case, just hang tight and we (meaning Rob

) can take a crack at making a new protocol by analyzing your learns.

However, like Rob, I'm wondering why you need to convert your learns since you somehow already made your new device upgrade by some other method. Are those learns some other device?

Posted: **Thu Apr 09, 2020 6:48 pm**

Dave, the learns look like NEC1 except that the frequency is 56kHz. I don't know where the upgrade came from but the device codes and OBCs match those in the learns, except for the frequency.

Posted: **Fri Apr 10, 2020 4:50 am**

Hi guys,

On the French Orange Forum I was adviced to use the Siligence 7233MB with my Logitech hub companion remote.

I found here a slingbox Siligence 7233MB

This worked except that 2 keys didn't. The (PVR and OPT key from the original remote ).
So this is the original remote https://bit.ly/2y9fsED.
There are 5 special keys Guide, PVR, Exit, Opt and Home(Menu).

I have a very strong feeling That the Slingbox Siligence 7233MB was translated to a logitech device and ended up with logitech that way.

Why you ask?
Because those 2 keys (OPT and PVR) these are mapped to function Custom10 and Custom11. There is even a Custom12.

I guess the guy who converted the file to logitech didn't now what to do with the Custom10 and Custom11 key.

I think IMHO that the Recording list of programs on this cablebox with HardDrive would best reside under the key LIST on my XSight remote.

I also used the colour keys to hold these special keys.
Red = LIST = PVR
Green = Guide
Yellow = INFO = OPT
Blue = Menu = Home.

I noticed that the latest version v2.10 build 3 doesn't do device upgrade Not even 1 line.
I used a older version v2.04 build 14 Where I noticed that not all lines had the same protocol or even frequency. Here I could do a device upgrade.
I guess a bug in the newest software?

This morning I relearned all keys from the original remote to my Xsight.
No discrepancies between the frequency or the protocol like the first time.

This is how 2 lines looks in rmir from 2.10 build 3
# Name........ DeviceButton........ Key......... Note Size Freq.... Protocol Device Sub Device OBC Hex Cmd Misc
1 __missing0 SILIGENCETCG300 ENTER............. 23... 56338 **None **
2 __missing1 SILIGENCETCG300 0.................... 23... 56338 **None **

This is how a line looks from rmir 2.04 build14
1 __missing0 SILIGENCETCG300 ENTER............. 23... 56338.. NEC1..... 134..... 227.........12....CF

Notice that all names start with __missing, none have a protocol, nothing is there after protocol.

I uploaded the new rmir file to the correct place .

Thanks for helping me guys I which I could use this remote on a daily basis without become the hulk every time.
I contacted Xnappo to buy one of his remotes.

Kind regards,
Guy Forssman

Posted: **Fri Apr 10, 2020 9:23 am**

mdavej wrote:I can see from your RMIR file that it does not recognize the protocol which means it's unknown to us, a new protocol we haven't seen before.

The Robman wrote:Dave, the learns look like NEC1 except that the frequency is 56kHz

In a PM, Dave asked me if this has anything to do with the current RM using IrpTransmogrifier (instead of DecodeIR), and if this can be addressed.

The way the protocol file IrpProtocols.xml is written, NEC1 is identified for frequencies 38400 +- frequencytolerance. frequencytolerance is a parameter, per default 2000 (Hz, not kHz). So the transmogrifier does as instructed when rejecting the signals as NEC1. However, it can be changed; and a negative value disables the frequency test. For example:

Code: Select all

$ irptransmogrifier decode Freq=56000Hz[+9024, -4512, +564, -564, +564, -564, +564, -1692, +564, -1692, +564, -564, +564, -564, +564, -564, +564, -564, +564, -1692, +564, -1692, +564, -564, +564, -564, +564, -1692, +564, -1692, +564, -1692, +564, -1692, +564, -564, +564, -1692, +564, -564, +564, -564, +564, -564, +564, -1692, +564, -564, +564, -564, +564, -1692, +564, -564, +564, -1692, +564, -1692, +564, -1692, +564, -564, +564, -1692, +564, -1692, +564, -39756][+9024, -2256, +564, -96156][]

$ irptransmogrifier --frequencytolerance -1 decode Freq=56000Hz[+9024, -4512, +564, -564, +564, -564, +564, -1692, +564, -1692, +564, -564, +564, -564, +564, -564, +564, -564, +564, -1692, +564, -1692, +564, -564, +564, -564, +564, -1692, +564, -1692, +564, -1692, +564, -1692, +564, -564, +564, -1692, +564, -564, +564, -564, +564, -564, +564, -1692, +564, -564, +564, -564, +564, -1692, +564, -564, +564, -1692, +564, -1692, +564, -1692, +564, -564, +564, -1692, +564, -1692, +564, -39756][+9024, -2256, +564, -96156][]
        NEC1: {D=12, F=34}

In English: first the signal is not recognized, setting frequencytolerance=-1, and it decodes!

So it is a matter of setting the parameters to get the desired result. (Actually this is not the full truth: there is also the possibility to set it for individual protocols, even non-symmetric intervals are possible.) It is not clear to me what the ideal solution would be. Possibly Graham would like to give the user access to frequencytolerance, but every such change makes the program harder to use.

(In DecodeIR all such decisions are hard coded into the sources, almost always not documented; you have to change the sources and recompile to change the behavior.)

Posted: **Fri Apr 10, 2020 11:03 am**

Forssux wrote:This is how a line looks from rmir 2.04 build14
1 __missing0 SILIGENCETCG300 ENTER............. 23... 56338.. NEC1..... 134..... 227.........12....CF

You don't have to go back to an ancient version of RMIR to see this. RMIR v2.10 gives you a choice of decoders. Go to Options > Set IR Decoder to switch between IrpTransmogrifier and DecodeIR. If you select DecodeIR then you get this decode. It is, however, wrong as NEC1 does not have a 56kHz frequency and if you construct a device upgrade on the basis that this is NEC1, it should not work. I can't tell from your posts whether you have actually constructed such a device upgrade, and if so, whether or not it works. If it does, it is because your equipment is not sensitive to frequency, not because RMIR with IrpTransmogrifier has got it wrong.

Barf wrote:Possibly Graham would like to give the user access to frequencytolerance

I don't see the benefit of this, as we do not have an executor that will generate NEC-style signals at 56kHz, and likewise for any other signals that are like known protocols with a vastly different frequency.

Posted: **Fri Apr 10, 2020 1:09 pm**

Ok, I've done a lot of "reading between the lines" on this one and I think I know now what the OP is saying (and Forssux, please correct me if I am wrong):

Here's my summary
1. He has a Siligence TCG330 cable box
2. He has been told that a code for a Siligence SGS7233MB should work.
3. He downloaded the Slingbox bin file for a Siligence SGS7233MB from here and reverse engineered an RMDU file from it.
4. He tested the RMDU file and it works but it's missing some buttons.
5. He tried learning from his Siligence TCG330 remote and got the learns found here.
6. He was unable to do anything with these learns because RMIR didn't decode them, which is because, while they look like NEC1 the frequency is wrong.

How did I do Forssux? If the TCG330 works using the SGS7233MB file, it implies that the device responds to both the regular 38kHz signal and the 56kHz signal. If it doesn't work, it means we will need to create an executor that generates NEC1 at 56kHz. Of course, given that the Slingbox file was created back in 2016, Alan would never have noticed that the NEC1 decodes were incorrect.

At any rate, Forssux, I have also reverse engineered an RMDU file from the Slingbox file, and I have re-named the custom buttons to match what the readme says they are. I have also added the DVR button from your learns. I have re-organized the buttons per where I think you want them to be, but please check that yourself. You should be able to add the RMDU file below to your RMIR file, replacing the upgrade that you currently have, to test it.

Of course, this doesn't help you program your Harmony but it should at least let you use your Xsight.

https://www.hifi-remote.com/forums/dload ... e_id=25922

To Barf and Mathdon, regarding what the decoder should do. I do not think the NEC1 decoder should be relaxed to display NEC1 for signals like this, because I do not expect a 38kHz signal to typically work where a 56kHz signal is required. But, would it be possible to create a generic NEC decoder where the frequency is just a parameter, like a device code? Because I *do* think it would be useful to know that a signal follows the NEC1 rules in all aspects except the frequency.

Also Barf, is there anyway you could change your program to add a space after the comma in the decodes that it shows? I ask because I always have to edit your posts where you post output to add the space, otherwise it messes up how the forum displays everybody's messages in the thread.

Posted: **Sat Apr 11, 2020 1:33 pm**

The Robman wrote:To Barf and Mathdon, regarding what the decoder should do. I do not think the NEC1 decoder should be relaxed to display NEC1 for signals like this, because I do not expect a 38kHz signal to typically work where a 56kHz signal is required. But, would it be possible to create a generic NEC decoder where the frequency is just a parameter, like a device code? Because I *do* think it would be useful to know that a signal follows the NEC1 rules in all aspects except the frequency.

IrpTransmogrifier has mechanisms available (without recompiling!); I already mentioned frequencytolerance, but you can also define relaxed protocols (with e.g. its own frequency tolerance). (Sorry for being brief; this was discussed some time ago.) But I do not think this is a really good idea. Most importantly, RM is a program for configuring remotes; for tasks like analyzing unknown signals other tools are available (which should not try to develop into remote configuration programs either). For this reason, I fully support Graham's decision not to support fumbling with frequencytolerance.

Also Barf, is there anyway you could change your program to add a space after the comma in the decodes that it shows? I ask because I always have to edit your posts where you post output to add the space, otherwise it messes up how the forum displays everybody's messages in the thread.

Short answer: no. You do not solve bugs by introducing new bugs, "anti-bugs". Also, there is a reason why the parameter assignments are given without a space: they can be easily be cut-n-pasted to new command line without using double quotes (at least with Linux/Unix/MacOS -- the "Dos-box" has its problems -- possibly Powershell is better?).

I wish you good luck on fixing the bug.

Posted: **Sat Apr 11, 2020 1:43 pm**

Barf wrote:
The Robman wrote:To Barf and Mathdon, regarding what the decoder should do. I do not think the NEC1 decoder should be relaxed to display NEC1 for signals like this, because I do not expect a 38kHz signal to typically work where a 56kHz signal is required. But, would it be possible to create a generic NEC decoder where the frequency is just a parameter, like a device code? Because I *do* think it would be useful to know that a signal follows the NEC1 rules in all aspects except the frequency.
IrpTransmogrifier has mechanisms available (without recompiling!); I already mentioned frequencytolerance, but you can also define relaxed protocols (with e.g. its own frequency tolerance). (Sorry for being brief; this was discussed some time ago.) But I do not think this is a really good idea.

So we're all in agreement, we should not loosen the tolerances for the official NEC protocols, but as you said, you already have the tools to support a "new" protocol, based on NEC, which does have much wider tolerances, and I support that.

Barf wrote:Most importantly, RM is a program for configuring remotes; for tasks like analyzing unknown signals other tools are available (which should not try to develop into remote configuration programs either). For this reason, I fully support Graham's decision not to support fumbling with frequencytolerance.

Not RM, but RMIR. We have always used RMIR (or IR.exe before it) to examine learned signals and I intend to keep on doing that. I'm not aware of any other tool, that I know how to use, which reads the memory from a remote and displays the learned signals.

Barf wrote:
The Robman wrote:Also Barf, is there anyway you could change your program to add a space after the comma in the decodes that it shows? I ask because I always have to edit your posts where you post output to add the space, otherwise it messes up how the forum displays everybody's messages in the thread.
Short answer: no. You do not solve bugs by introducing new bugs, "anti-bugs". Also, there is a reason why the parameter assignments are given without a space: they can be easily be cut-n-pasted to new command line without using double quotes (at least with Linux/Unix/MacOS -- the "Dos-box" has its problems -- possibly Powershell is better?).

I wish you good luck on fixing the bug.

Then don't be offended if I continue to edit any post of yours where you paste really long strings of text. If, on the other hand, you were offering to fix the "bug" in the forum software that doesn't break text without its own breaks, I will gladly give you the keys to the shop.

Posted: **Mon Apr 13, 2020 6:04 am**

Hi Guys,

Thanks for clarifying a lot.

Rob you where wright dough at step 6 I could use my Xsight remote to control this DVR.

I noticed hover that indeed when I change from IrpTransmogrifier to IR- Decoder the protocol device, sub device OBC and Hex Cmd are filled in.

However you can't convert to Device Upgrade. I then tried to jump to another loop and copied all values in the Ir-Decoder settings but couldn't paste it into the same fields but with TrpTransmogrifier setting.

So I hope that get's ironed out for the next release.

I hope you'll have a happy Easter,
Guy

Posted: **Mon Apr 13, 2020 7:33 am**

The older version of RMIR used a program called DecodeIR to translate the learned signals, the newer version uses a program called TransMoggyfier which is stricter in how it implements the rules. This is not a bad thing, because the rules for NEC1 shouldn't allow for frequencies as high as 56kHz.

However, in your case, it appears that your unit does respond to both the standard 38kHz signal and the unusual 56kHz signal, so it is useful to get the OBCs decoded.

And like Mathdon pointed out, you do have the ability to switch between DecodeIR and the newer program in RMIR.

Posted: **Mon Apr 13, 2020 2:26 pm**

Yes indeed, but how can anybody do a Convert to Device Upgrade in this case?

I tried it just didn't work.

JP1 Remotes

ASKEY / Siligence SGS7233MB cable box

ASKEY / Siligence SGS7233MB cable box

rmdu <----> rmir uploaded

Easter