Remote: UUC-8820
IR v7.00(beta 3)
DecodeIR (Version 2.32)
After download from remote, on the "Learned Signals" tab, The learned code is not parsed into fields and placed under the proper columns. Instead the entire string appears under the "Protocol" column, which is pretty much useless to a novice like me.
For instance: Dreambox:138.015-1B1F442A16012600
Any help or pointers appreciated.
IR v7.0beta3 - Learned Signals not parsed into fields
Moderator: Moderators
That protocol is usually learned incorrectly as it was that time. It is a very difficult protocol for learning remotes.
What you see is NOT the original data. It has been recognized and processed as much as is possible given that it was learned wrong.
There is a more detailed description of the issues in the DecodeIR help text for this protocol at
http://john.fine.home.comcast.net/ir/De ... l#Dreambox
If you have a partially working setup code or JP1 upgrade, or even some correct learns from other buttons, that should make it much easier to get useful information from 16 hex digits in the partial decode of the bad learn (as described in that DecodeIr doc).
Another confusing factor in this protocol: The actual device will ignore many serious errors in the signal, so a bad learn may work even if it is much further from correct than some other learn that fails. The decoder does not duplicate that behavior. If the signal is learned too badly to deduce the correct values of all 16 digits, then the decoder will display (as you quoted) its best guess at the 16 digits rather than do the next step of processing. Depending on which digits are wrong the learned signal might or might not work.
It is also possible that your signal was learned correctly. I based the rules for these decodes on information Jon Armstrong gave me years ago. More recently, I discovered some valid signals violate constraints that Jon thought were protocol rules. I'm not sure whether the correction to that has gotten into a released copy of DecodeIr.dll yet. Without testing the .ir file containing your learned signal, I can't tell whether your signal is one of those. But as described in that DecodeIr.doc, the two timing numbers in your sample (138.015) tend to imply an unusually good learn, so it would be surprising if one of the 16 hex digits really is wrong.
What you see is NOT the original data. It has been recognized and processed as much as is possible given that it was learned wrong.
There is a more detailed description of the issues in the DecodeIR help text for this protocol at
http://john.fine.home.comcast.net/ir/De ... l#Dreambox
If you have a partially working setup code or JP1 upgrade, or even some correct learns from other buttons, that should make it much easier to get useful information from 16 hex digits in the partial decode of the bad learn (as described in that DecodeIr doc).
Another confusing factor in this protocol: The actual device will ignore many serious errors in the signal, so a bad learn may work even if it is much further from correct than some other learn that fails. The decoder does not duplicate that behavior. If the signal is learned too badly to deduce the correct values of all 16 digits, then the decoder will display (as you quoted) its best guess at the 16 digits rather than do the next step of processing. Depending on which digits are wrong the learned signal might or might not work.
It is also possible that your signal was learned correctly. I based the rules for these decodes on information Jon Armstrong gave me years ago. More recently, I discovered some valid signals violate constraints that Jon thought were protocol rules. I'm not sure whether the correction to that has gotten into a released copy of DecodeIr.dll yet. Without testing the .ir file containing your learned signal, I can't tell whether your signal is one of those. But as described in that DecodeIr.doc, the two timing numbers in your sample (138.015) tend to imply an unusually good learn, so it would be surprising if one of the 16 hex digits really is wrong.