Is there a UEI PID for the Grundig16 protocol? None of the Grundig TV setup codes on my URC-7781 seem to generate this protocol. It doesn't seem to be in either RM or KM, neither is there a Protocol Builder file for it, unless it is also known by some other name.
I am trying to sort out an inconsistency about this protocol in DecodeIR. The IRP notation for it in DecodeIR.html (which is also in the source code comments) is not consistent with the actual decode.
_____________
Graham
Grundig16 question
Moderator: Moderators
I'll give you some examples from my library of decoded CCF files, since I don't have time today to research a real answer. Hopefully these will resolve the inconsistency you see.
Edit: Is your thread a coincidence to the recently reopened thread at RC
http://www.remotecentral.com/cgi-bin/mb ... d.cgi?5575
The signals posted 4 years ago in that thread decode with IrTool as Grundig16 device 71. I guess I never followed up, because I have only device 127 in my library of sample signals.
First sample explained:
protocol: Grundig16
device: 127
Function: 21
EFC: 130
Toggle bit: 1
tot, U (I would need research to know what they mean)
Pairs decoded for this frame: 0_17
Various button identifying info from the CCF
Frequency: 30.479
Total capture: 51 pairs one-time, 0 pairs repeating
Raw data in microseconds.
From the file at: markus-emmert_ccf.zip
Grundig16 127 21 130 T=1 tot=32761 U=3443_3476 0_17 Taste1 VCR 1 VCR ShowView Men`u 30.479 51 0 820_2985 1312_1148 590_1148 590_2263 1181_1148 590_1148 590_1148 590_1148 590_459 590_1804 590_459 590_1804 590_459 590_1804 590_459 590_1804 590_67521 820_2952 1312_1148 590_1148 590_2263 1181_1148 590_1148 590_1148 590_1148 590_459 590_1804 590_459 590_1804 590_459 590_1804 590_459 590_1804 590_67554 820_2952 1312_1148 590_1148 590_2263 1181_1148 590_1148 590_1148 590_1148 590_459 590_1804 590_459 590_1804 590_459 590_1804 590_459 590_1804 590_2985
From the file at: luigi-palumbo_ccf.zip
Grundig16 127 0 026 T=1 tot=32732 U=3403_3500 0_15 Learned power IRcodes VCR 30.2565 15 15 826_2941 1322_1156 594_1156 594_2214 1189_2247 1189_2247 1189_1784 594_495 594_495 594_1784 594_495 594_1784 594_495 594_1784 594_53409 826-2941 1322-1156 594-1156 594-2247 1189-2247 1189-2247 1189-1784 594-462 594-495 594-1784 594-495 594-1784 594-495 594-1784 594-57739
From the file at: romain-heilig_ccf.zip
Grundig16 127 15 227 T=1 tot=32431 U=3410_3444 LEARNED + VCR Transport VCR 30.479 1 17 360_67915 820-2952 1312-1115 590-1148 590-2263 1181-1771 590-459 590-459 590-1771 590-459 590-1771 590-459 590-1771 590-459 590-1771 590-459 590-1771 590-67915
From the file at: ino-kussy_ccf.zip
Grundig16 127 0 026 T=0 tot=32405 U=3410_3412 0_14 LEARNED Off panel S-VHS1 30.479 28 0 820_2985 1312_2231 1181_2231 1181_2231 1181_2231 1181_1771 590_459 590_459 590_1771 590_459 590_1771 590_459 590_1771 590_67456 820_2985 1312_2231 1181_2231 1181_2231 1181_2231 1181_1771 590_459 590_459 590_1771 590_459 590_1771 590_459 590_1771 590_2985
You may want to use DecodeCCF yourself with DecodeIR.dll with those CCF files to test any tweaks you might consider to that decoder and/or to add any diagnostic output that may help you understand the protocol.
There are some samples reported by my test code as Grundig16 with other device numbers (not 127) in nick-solares_pro.zip and daniel-ramos.zip but those results seem to be flawed and I don't know whether the signals really are Grundig16. More likely, they are places where the Grundig16 decoder should be tightened to avoid false decodes.
Edit: Is your thread a coincidence to the recently reopened thread at RC
http://www.remotecentral.com/cgi-bin/mb ... d.cgi?5575
The signals posted 4 years ago in that thread decode with IrTool as Grundig16 device 71. I guess I never followed up, because I have only device 127 in my library of sample signals.
First sample explained:
protocol: Grundig16
device: 127
Function: 21
EFC: 130
Toggle bit: 1
tot, U (I would need research to know what they mean)
Pairs decoded for this frame: 0_17
Various button identifying info from the CCF
Frequency: 30.479
Total capture: 51 pairs one-time, 0 pairs repeating
Raw data in microseconds.
From the file at: markus-emmert_ccf.zip
Grundig16 127 21 130 T=1 tot=32761 U=3443_3476 0_17 Taste1 VCR 1 VCR ShowView Men`u 30.479 51 0 820_2985 1312_1148 590_1148 590_2263 1181_1148 590_1148 590_1148 590_1148 590_459 590_1804 590_459 590_1804 590_459 590_1804 590_459 590_1804 590_67521 820_2952 1312_1148 590_1148 590_2263 1181_1148 590_1148 590_1148 590_1148 590_459 590_1804 590_459 590_1804 590_459 590_1804 590_459 590_1804 590_67554 820_2952 1312_1148 590_1148 590_2263 1181_1148 590_1148 590_1148 590_1148 590_459 590_1804 590_459 590_1804 590_459 590_1804 590_459 590_1804 590_2985
From the file at: luigi-palumbo_ccf.zip
Grundig16 127 0 026 T=1 tot=32732 U=3403_3500 0_15 Learned power IRcodes VCR 30.2565 15 15 826_2941 1322_1156 594_1156 594_2214 1189_2247 1189_2247 1189_1784 594_495 594_495 594_1784 594_495 594_1784 594_495 594_1784 594_53409 826-2941 1322-1156 594-1156 594-2247 1189-2247 1189-2247 1189-1784 594-462 594-495 594-1784 594-495 594-1784 594-495 594-1784 594-57739
From the file at: romain-heilig_ccf.zip
Grundig16 127 15 227 T=1 tot=32431 U=3410_3444 LEARNED + VCR Transport VCR 30.479 1 17 360_67915 820-2952 1312-1115 590-1148 590-2263 1181-1771 590-459 590-459 590-1771 590-459 590-1771 590-459 590-1771 590-459 590-1771 590-459 590-1771 590-67915
From the file at: ino-kussy_ccf.zip
Grundig16 127 0 026 T=0 tot=32405 U=3410_3412 0_14 LEARNED Off panel S-VHS1 30.479 28 0 820_2985 1312_2231 1181_2231 1181_2231 1181_2231 1181_1771 590_459 590_459 590_1771 590_459 590_1771 590_459 590_1771 590_67456 820_2985 1312_2231 1181_2231 1181_2231 1181_2231 1181_1771 590_459 590_459 590_1771 590_459 590_1771 590_459 590_1771 590_2985
You may want to use DecodeCCF yourself with DecodeIR.dll with those CCF files to test any tweaks you might consider to that decoder and/or to add any diagnostic output that may help you understand the protocol.
There are some samples reported by my test code as Grundig16 with other device numbers (not 127) in nick-solares_pro.zip and daniel-ramos.zip but those results seem to be flawed and I don't know whether the signals really are Grundig16. More likely, they are places where the Grundig16 decoder should be tightened to avoid false decodes.
Thanks, John, but I don't really understand how this helps. It looks as if the descriptive data is from DecodeCCF with the aid of DecodeIR, so it does of course agree with the decode program, not with the IRP notation in the source comment with which that is in conflict. So it doesn't seem to take me any further forward. To be specific, the stated IRP is:
{35.7k,578,msb}<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>(806u,-2960u,1346u,D:1:6,T:1,F:8,D:6,-100)+
but your decoder corresponds to
{35.7k,578,msb}<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>(806u,-2960u,1346u,T:1,F:8,D:7,-100)+
I am trying to investigate which is correct and why there is a difference.
________
Graham
{35.7k,578,msb}<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>(806u,-2960u,1346u,D:1:6,T:1,F:8,D:6,-100)+
but your decoder corresponds to
{35.7k,578,msb}<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>(806u,-2960u,1346u,T:1,F:8,D:7,-100)+
I am trying to investigate which is correct and why there is a difference.
________
Graham
Sorry, I didn't guess from your first post the type of inconsistency you saw.
You are correct to ask about an existing pid, but I don't have any easy way to look for one. Maybe Rob remembers.
The data I linked to gives strong support for the position that the existing decode logic is correct about the toggle bit and correct about the bottom 7 out of 8 Function bits. The second bit overall and the last seven bits overall don't seem to change, which is at least consistent with (though not "strong support" of) the current decode that makes the second bit the msb of F and makes the last seven bits D.
The existing decode computes the EFC from a different 8 bits (shifted by one) from the bits used by the OBC. If I never saw a pid for this protocol, doing that would make no sense at all.
I don't recall whether the inconsistency came from some correction that was incompletely coded, or whether some of it comes from some kludge in a pid that I might have known about at some point.
Edit: I just noticed one more detail. The efc comes from hex that has the bits in each pair reversed. That tells me for sure that I saw some pid that reversed bit pairs (common for UEI in this type of protocol). That also forces them to treat the second bit overall as if it were first, so it isn't easy to make it part of F.
Someone (hopefully me) got the identities of the first two bits backwards somewhere in the confusion of the UEI executor reversing bit pairs. If it was me then the published IRP and comments are just wrong. If it was UEI then that executor is broken and the published IRP matches the broken executor.
My best guess is I based an initial version of this decoder on a mix of what I thought I understood from the pid and what I had seen in some CCF file. Then I found it didn't work for the CCF, so I corrected the code but forgot to correct the comments, then copied IRP documentation from those comments.
You are correct to ask about an existing pid, but I don't have any easy way to look for one. Maybe Rob remembers.
The data I linked to gives strong support for the position that the existing decode logic is correct about the toggle bit and correct about the bottom 7 out of 8 Function bits. The second bit overall and the last seven bits overall don't seem to change, which is at least consistent with (though not "strong support" of) the current decode that makes the second bit the msb of F and makes the last seven bits D.
The existing decode computes the EFC from a different 8 bits (shifted by one) from the bits used by the OBC. If I never saw a pid for this protocol, doing that would make no sense at all.
I don't recall whether the inconsistency came from some correction that was incompletely coded, or whether some of it comes from some kludge in a pid that I might have known about at some point.
Edit: I just noticed one more detail. The efc comes from hex that has the bits in each pair reversed. That tells me for sure that I saw some pid that reversed bit pairs (common for UEI in this type of protocol). That also forces them to treat the second bit overall as if it were first, so it isn't easy to make it part of F.
Someone (hopefully me) got the identities of the first two bits backwards somewhere in the confusion of the UEI executor reversing bit pairs. If it was me then the published IRP and comments are just wrong. If it was UEI then that executor is broken and the published IRP matches the broken executor.
My best guess is I based an initial version of this decoder on a mix of what I thought I understood from the pid and what I had seen in some CCF file. Then I found it didn't work for the CCF, so I corrected the code but forgot to correct the comments, then copied IRP documentation from those comments.
John, this is a reply to your edit:
If your recollection is right of how the discrepancy came about, it perhaps explains another oddity. The decoder uses data bits 1-8 for the OBC (the position of F in the second of the IRPs I gave) but it uses bits 2-9 to construct the hex code (the position of F in the first of the IRPs). I can't see how this can possibly be right, as it means that the OBC cannot be reconstructed from the EFC as they use different data bits. I can't see how to resolve that one without knowing the PID.
______________
Graham
It absolutely is a coincidence! I never look at Remote Central unless someone points me to it for something particular. CCF files are still a mystery to me - other IR matters have kept me pretty busy so far! My question arose because I have just started looking at the few protocols that have bitspecs with more than two IRstreams, to make sure I understand them, and I realised that the IRP didn't agree with the decoder.Edit: Is your thread a coincidence to the recently reopened thread at RC
http://www.remotecentral.com/cgi-bin/mb ... d.cgi?5575
The signals posted 4 years ago in that thread decode with IrTool as Grundig16 device 71. I guess I never followed up, because I have only device 127 in my library of sample signals
If your recollection is right of how the discrepancy came about, it perhaps explains another oddity. The decoder uses data bits 1-8 for the OBC (the position of F in the second of the IRPs I gave) but it uses bits 2-9 to construct the hex code (the position of F in the first of the IRPs). I can't see how this can possibly be right, as it means that the OBC cannot be reconstructed from the EFC as they use different data bits. I can't see how to resolve that one without knowing the PID.
______________
Graham
It wasn't a recollection. I have no memory at all of any work I ever did on Grundig16.mathdon wrote:If your recollection
It was a deduction based on the source code of decodeir.dll and knowledge of my work habits. The only way I could have written the code with that strange way of getting the EFC is if I was working from a pid that did something that strange.
It just means that pid supports OBCs 0..127 in one upgrade and might (depending on other details inside the pid) support 128..255 in a different upgrade.I can't see how this can possibly be right, as it means that the OBC cannot be reconstructed from the EFC as they use different data bits.
The CCF files and other resources at RC are an important source of learned signals. The ones I have from there tell us we probably don't need to worry about OBC numbers 128 to 255.
John, I have found the PID on which you based your original IRP. It is 0112, and my URC-7781 uses it in device DVD/0775. I've studied the protocol, and it appears to correspond to your original IRP but with the first two data bits the wrong way round, as you said "in the confusion of the UEI executor reversing bit pairs". I think the bit D:1:6 is best treated as a one-bit subdevice code, and that the best IRP is
{35.7k,578,msb}<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>(806u,-2960u,1346u,T:1,S:1,F:8,D:6,-100)+
This works with the UEI executor, the 8-bit function code comes from the same bits as the 8-bit hex value, and the device number remains constant in this interpretation whenever it did in your decoder (as it is the last 6 bits of that 7-bit value). If you tag what I have called S on as a top bit in D, then D would change between OBC values that showed up in your decoder as <128 and those that were >=128, as S is the top bit of that value.
If you were right that all OBC values in reality are <128 then this would not matter, but some time ago I was sent a Grundig16 .ir file by a user called Arrow, in connection with a problem he was having. See my exchanges with Arrow starting on the first page of this thread. That included a few OBC values which showed up as >=128. With my suggested IRP these now have S=1 but the device code still remains constant for all the signals in his file.
I hope you think this is a satisfactory resolution of the discrepancy. If so, I'll put it in the next version of DecodeIR that I issue.
_______________
Graham
{35.7k,578,msb}<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>(806u,-2960u,1346u,T:1,S:1,F:8,D:6,-100)+
This works with the UEI executor, the 8-bit function code comes from the same bits as the 8-bit hex value, and the device number remains constant in this interpretation whenever it did in your decoder (as it is the last 6 bits of that 7-bit value). If you tag what I have called S on as a top bit in D, then D would change between OBC values that showed up in your decoder as <128 and those that were >=128, as S is the top bit of that value.
If you were right that all OBC values in reality are <128 then this would not matter, but some time ago I was sent a Grundig16 .ir file by a user called Arrow, in connection with a problem he was having. See my exchanges with Arrow starting on the first page of this thread. That included a few OBC values which showed up as >=128. With my suggested IRP these now have S=1 but the device code still remains constant for all the signals in his file.
I hope you think this is a satisfactory resolution of the discrepancy. If so, I'll put it in the next version of DecodeIR that I issue.
_______________
Graham
I don't like doubling the F values that way.
In general, I don't like changing a reasonable interpretation of OBC based on the design flaws of a UEI PID.
I don't like making such changes at all (invalidating posted decodes in any RC threads etc.) without a stronger reason.
The digit key decodes for multiple devices (from CCF files) are currently OBC 20 through 29 for digits 0 through 9. That is very clean. You are proposing '0' = OBC 41, '1' = OBC 43, ..., '9' = OBC 59. That is not nearly as clean.
There are other protocols in which a choice in the fixed data restricts the range of OBC values, so proper support in RM is provided by a Yes/No field on the device sheet for "OBC>127". RM can also handle the other end and copy a bit of the device code into the hex code.
So I would really prefer to leave the decode as it stands and just fix the comments and the IRP documentation.
In general, I don't like changing a reasonable interpretation of OBC based on the design flaws of a UEI PID.
I don't like making such changes at all (invalidating posted decodes in any RC threads etc.) without a stronger reason.
The digit key decodes for multiple devices (from CCF files) are currently OBC 20 through 29 for digits 0 through 9. That is very clean. You are proposing '0' = OBC 41, '1' = OBC 43, ..., '9' = OBC 59. That is not nearly as clean.
There are other protocols in which a choice in the fixed data restricts the range of OBC values, so proper support in RM is provided by a Yes/No field on the device sheet for "OBC>127". RM can also handle the other end and copy a bit of the device code into the hex code.
So I would really prefer to leave the decode as it stands and just fix the comments and the IRP documentation.
I have now added the Grundig16 protocol to my copy of RemoteMaster, with a behaviour exactly as suggested by John. It required both a new entry in Protocols.ini and a new translator added to RemoteMaster.jar.
I will pass these on to Greg if he would like them, otherwise I shall include them in the package with the next issue of DecodeIR. I have discovered that WinZip is capable of adding new Java class files into a .jar file, so given the Grundig16 entry for the text file protocols.ini and the compiled GrundigXlator.class file, users of RemoteMaster can then add this protocol themselves if they wish.
_____________
Graham
I will pass these on to Greg if he would like them, otherwise I shall include them in the package with the next issue of DecodeIR. I have discovered that WinZip is capable of adding new Java class files into a .jar file, so given the Grundig16 entry for the text file protocols.ini and the compiled GrundigXlator.class file, users of RemoteMaster can then add this protocol themselves if they wish.
_____________
Graham
Since 3FG has started the ball rolling in another thread by posting an upgrade to RemoteMaster that adds a new translator, I've posted my Grundig16 add-in rather than waiting for the next issue of DecodeIR. The Java source code of the GrundigXlator class file is included.
_______________
Graham
_______________
Graham
I just found this topic - and it looks like the job is done already.
But I want to introduce my solution anyway because it works
perfectly - using the existing translator.
My Grundig VCR (GV450) uses the Grundig16 protocol.
The RC is "RP 35". It sends the code but at 30kHz.
I have found that this is done by PID=00AB.
PID=0112 in fact is the 36kHz Grundig16.
For my URC-7552 I have modified the PID=00AB protocols.ini as follows.
[Grundig16 (30kHz)]
PID=00 AB
DevParms=Device:7=0, OBCs>127:bool=0
DeviceTranslator=Translator(0,1,6,0) Translator(0,1,7,1) XorCheck(1,7,0,2,6,1) \
Translator(0,1,4,2) Translator(0,1,5,3) XorCheck(1,5,0,2,4,1) \
Translator(0,1,2,4) Translator(0,1,3,5) XorCheck(1,3,0,2,2,1) \
Translator(1,1,0,0)
FixedData=00
CmdParms=Decimal=0
CmdTranslator=Translator(0)
DefaultCmd=00
# code section from protocols.ini PID=00 AB...
I think this should work for 0112 too, but I can't test it...
[Grundig16 (36kHz)]
PID=01 12
# same as above ???
# code section from protocols.ini PID=01 12...
If someone wants to try that, I would like to hear of the results.
But I want to introduce my solution anyway because it works
perfectly - using the existing translator.
My Grundig VCR (GV450) uses the Grundig16 protocol.
The RC is "RP 35". It sends the code but at 30kHz.
I have found that this is done by PID=00AB.
PID=0112 in fact is the 36kHz Grundig16.
For my URC-7552 I have modified the PID=00AB protocols.ini as follows.
[Grundig16 (30kHz)]
PID=00 AB
DevParms=Device:7=0, OBCs>127:bool=0
DeviceTranslator=Translator(0,1,6,0) Translator(0,1,7,1) XorCheck(1,7,0,2,6,1) \
Translator(0,1,4,2) Translator(0,1,5,3) XorCheck(1,5,0,2,4,1) \
Translator(0,1,2,4) Translator(0,1,3,5) XorCheck(1,3,0,2,2,1) \
Translator(1,1,0,0)
FixedData=00
CmdParms=Decimal=0
CmdTranslator=Translator(0)
DefaultCmd=00
# code section from protocols.ini PID=00 AB...
I think this should work for 0112 too, but I can't test it...
[Grundig16 (36kHz)]
PID=01 12
# same as above ???
# code section from protocols.ini PID=01 12...
If someone wants to try that, I would like to hear of the results.
Hi, Spock. That is very interesting. I must say that I hadn't thought of using XorCheck to generate the fixed byte in that way. But it wouldn't work as it stands for the 0112 protocol with the OBC values generated by John Fine's code in DecodeIR. The problem is that you do no conversion in the Command Translator, but John uses the same conversion for it as for the Device Translator, so as to create OBC values where the OBCs for the digits just increase by one from one digit to the next. I see no reason why one shouldn't be able to do the same trick with the Command Translator as you have done with the Device one, though, and so avoid the need for a dedicated GrundigXlator. But creating and adding a new translator was an interesting exercise. 
_____________
Graham
_____________
Graham
I have some scripts, where I also started to do conversion for the Command translator.mathdon wrote:... The problem is that you do no conversion in the Command Translator, but John uses the same conversion for it as for the Device Translator...
But I created that entry nearly 2 years ago and I don't recall why I dropped that part.
I know, that the protocol (00 AB) worked for me as it was.
But may be that's why the OBCs don't match - and I suppressed them in the RM functions page.
Unfortunately I don't have much time for the JP1 stuff at the moment
but I hope to find some to work on it again (especially the Grundig16 and NRC17 protocols)
I wouldn't have known how to write a new translator.mathdon wrote: ... and so avoid the need for a dedicated GrundigXlator. But creating and adding a new translator was an interesting exercise.
_____________
Graham
That's why I had to find another solution - and obviously did.
I tried again to complete my Grundig16 00 AB protocol version (command translator part).
But now I see (again) that it is not possible to generate the correct OBC values using the XORCheck "trick".
So your GrundigXLator obviously is the way to go.
I think it will work with both protocols (00 AB and 01 12) and I suggest renaming them to
[Grundig16 (30kHz)]
PID=00 AB
...
and
[Grundig16 (36kHz)]
PID=01 12
...
But I can't test that right now.
It seems not to be compatible with the (rather old) java version 1.40 of RM, that I can only use on one of my
computers. (I only get a lot of java errors there.)
And I am not able to put it into the latest (standalone windows) version of RM.
So I will have to wait for the next release of RM, hoping that your translator is inserted there by default...
But now I see (again) that it is not possible to generate the correct OBC values using the XORCheck "trick".
So your GrundigXLator obviously is the way to go.
I think it will work with both protocols (00 AB and 01 12) and I suggest renaming them to
[Grundig16 (30kHz)]
PID=00 AB
...
and
[Grundig16 (36kHz)]
PID=01 12
...
But I can't test that right now.
It seems not to be compatible with the (rather old) java version 1.40 of RM, that I can only use on one of my
computers. (I only get a lot of java errors there.)
And I am not able to put it into the latest (standalone windows) version of RM.
So I will have to wait for the next release of RM, hoping that your translator is inserted there by default...