JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Upgrade or learns analysis needed: Uniden TL42TZ1-AW LCD TV
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> Code Search (Closed)
View previous topic :: View next topic  
Author Message
digital_silence



Joined: 22 May 2004
Posts: 237

PostPosted: Sat Aug 01, 2015 11:27 pm    Post subject: Reply with quote

Fair enough...

Thanks, I'll upgrade to v2.03. My question above stands: Is there a single file executable installer, just like was for my current v.2.01 which would also create an executable launch file?

If not, could you please refer me to the installation instructions for JAVA version of v.2.03 (build4)

And one more thing, while I am doing that...

Yesterday, I've noticed that TV/Video button works in such a way that it does not select HDMI inputs (TV -> Video1 -> Video2 -> Video3 -> Video4 -> TV -> Video1 -> ...)
To select HDMIs, the separate button called HDMI must be used.
I have updated my upgrade accordingly, but while I was doing this, I noticed that all OBC codes are scrambled, compared to what they were yesterday, when I was figuring out all OBC's. In my findings, all OBCs were in the range 0 to 110, and they are all over the shop now, after I saved RMDU file edited by RMIR v2.01 ...

I assume that would be a result of RMIR 2.01 stuffing up...

Can someone pls have a look at the RMDU upgrade HERE and possibly convert all OBC's back to where they should be (0 to 110 range)

Thanks,
:-DS
Back to top
View user's profile Send private message
digital_silence



Joined: 22 May 2004
Posts: 237

PostPosted: Sun Aug 02, 2015 6:32 am    Post subject: Reply with quote

Update:

That doesn't seem to be a RMIR version problem... or I should say that problem must be not the only one...

I've installed RMIR v.2.03build4 and used it to load the Vicky's updated upgrade (UNIDEN_TV.txt) into my 8910B00. Still doesn't work.

I have saved the remote image (same way I've done yesterday, the only difference is that it's now made with RMIRv.2.03)
I uploaded it here for your study and comparison.

Please let me know what else I should try.

I am kind of OK for now, as Comcast 1067Bx3 seems to work, but it'd be nice to get to the bottom of why 8910 doesn't.

Best,
:-DS
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 6968
Location: Florida

PostPosted: Mon Aug 03, 2015 7:13 am    Post subject: Reply with quote

Hi DS.

I found 4 AAA batteries testing.

I tried uploading your RMIR file, and got a Mem Fault and then the TV setup was TV/0047, not TV/2003.

Following the master reset instruction in the wiki I did a 8910 Manufacturer's Reset and tried again. Same result.

So saved the RMIR file as an IR file and repeated the reset followed by an upload from IR, and still got the Mem Fault.

Looking at this in IR, I see two 0160 protocols, so I deleted the second one, and it uploaded fine. TV/2003 on the TV button shot nearly identical signals to the Comcast signals. the timing difference was miniscule.

Of course the POWER and MENU buttons won't work because you have not deleted the learns, so the learns override the upgrade.

So I went back to RMIR and looked at the protocols tab where the second 0160 protocol was. I deleted it, and uploaded the image to the 8910 and that worked great, signals still look fine.

Bottom line, the 8910 remote despised the duplicate unused protocol.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Back to top
View user's profile Send private message Visit poster's website
digital_silence



Joined: 22 May 2004
Posts: 237

PostPosted: Mon Aug 03, 2015 8:26 am    Post subject: Reply with quote

Hi Vicky,

I repeated your exercise, and here are my comments:

1) I opened my latest RMIR (the one made with v2.03) with the same version (2.03) of RMIR that I installed yesterday, then uploaded it into 8910 - all uploaded OK, no memory fault messages, but it didn't work.

2) I removed the two TV learns (POWER and MENU), uploaded it into 8910 again, and it worked!

3) I didn't remove any protocols. Note that there's only one protocol (01 60 (2)) that appears in the Protocols tab of RMIR in my case. And I didn't touch it. All works OK.

So, all in all, it appears that all it was is just a stuff-up on my side with forgetting to remove POWER and MENU learns from TV device in 8910.
Looks like the version of RMIR and custom protocol has little or nothing to do with that.
And yes, I admit that you pointed the POWER/TV learns to me, and I just didn't pay attention. I am really sorry, Vicky.

So it's almost all sorted, except I still would like someone to explain to me why all OBC codes got changed in RMDU upgrade that I linked to in the first post on this page. "Got changed" - I mean, compared to what I set them to before saving the upgrade to the RMDU file.
As I explained, all OBCs were below 110 when I created the upgrade.
Now, in saved RMDU file, they are all over the place.
Can someone pls help me and get them back to 0-110 range

Thanks,
:-DS
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 6968
Location: Florida

PostPosted: Mon Aug 03, 2015 2:09 pm    Post subject: Reply with quote

Okay I don't have a clue as to what is going on with this file. All I know is that mem fault was a problem with my 8910 working with this file. So something was corrupt in this setup I'm not sure why.

As to why RM is changing the OBC's from LSB to MSB again I don't have a clue. It didn't do it for me when I did it on a trial version.....

It is really kind of a mystry.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18539
Location: Chicago, IL

PostPosted: Mon Aug 03, 2015 6:25 pm    Post subject: Reply with quote

I can't look at the RMDU file in RM as I don't have the tool anymore, but looking at the file in Notepad, am I right in guessing that the OBCs for the numeric buttons were a match (ie, the OBC for number 1 was 1, etc)?

Now you say the OBCs are random and scrambled, what is the new OBC for the #2 button? Is it 64, 254 or 192?

If it's...
64 - you are viewing the hex as MSB
254 - you are viewing the hex as LSB-COMP
192 - you are viewing the hex as MSB-COMP

You should be using LSB.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
digital_silence



Joined: 22 May 2004
Posts: 237

PostPosted: Mon Aug 03, 2015 7:45 pm    Post subject: Reply with quote

The Robman wrote:
I can't look at the RMDU file in RM as I don't have the tool anymore, but looking at the file in Notepad, am I right in guessing that the OBCs for the numeric buttons were a match (ie, the OBC for number 1 was 1, etc)?

Now you say the OBCs are random and scrambled, what is the new OBC for the #2 button? Is it 64, 254 or 192?

If it's...
64 - you are viewing the hex as MSB
254 - you are viewing the hex as LSB-COMP
192 - you are viewing the hex as MSB-COMP

You should be using LSB.
Hi Vicky and Rob,

I am away from my home setup now, so I will answer your Q tonight.
From the memory, the OBCs for numeric buttons were in sequence, but I don't think they were a match... but I don't want to confuse anyone, I'll tell you in a few (7+) hours.

In the meantime, just for my benefit: what are the formulas for converting between OBC, HEX and EFC ?

I understand the Little/Big Endian confusion (aka Motorola Hex vs Intel Hex in the old good days) - I'd be able to have a more educated look at those codes if I knew the conversion rules.

Thanks,
:-DS
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18539
Location: Chicago, IL

PostPosted: Mon Aug 03, 2015 9:17 pm    Post subject: Reply with quote

I wouldn't bother trying to convert to or from EFC as those codes are deliberately scrambled by UEI.

As for converting from hex to OBC you need to work with binary instead of hex and you need to know if you are dealing with LSB or MSB and if it's comp'd.

hex 0x01 = 00000001 in binary, which is OBC 1 in MSB or OBC 128 in LSB. To get the comp'd version subtract the OBC from 255.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!


Last edited by The Robman on Thu Aug 06, 2015 10:17 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
digital_silence



Joined: 22 May 2004
Posts: 237

PostPosted: Tue Aug 04, 2015 9:36 am    Post subject: Reply with quote

The Robman wrote:
I wouldn't bother trying to convert to or from EFC as those codes are deliberately scrambled by UEI.

As for converting from hex to OBC you need to work with binary instead of hex and you need to know if you are dealing with LSB or MSB and if it's comp'd.

hex 0x01 = 00000001 in binary, which is OBC 1 in MSB or OBC 128 in LSB. To get the comp'd version subtract the OBC from 255.

- What's "Comp'd" ?
- How do I change the view in RMIR between MSB/LSB-COMP/MSB-COMP ?

OK, that's what I found:

When I first load Vicky's TXT upgrade into Remote Master or into RMIR, the Functions tab shows the following numbers:

Button-OBC-HEX:
-------------------
"0"-0-00
"1"-1-80
"2"-2-40
"3"-3-C0
"4"-4-20
"5"-5-A0
...

...that is the HEX codes are "flipped horizontally" binary numbers of the OBC codes.

When I then save the upgrade as RMDU and re-open it (and that's what I uploaded above), they look like that:

Button-OBC-HEX:
-------------------
"0"-0-00
"1"-128-80
"2"-64-40
"3"-192-C0
"4"-32-20
"5"-160-A0
...

i.e. the OBC codes now are just decimal representations of the HEX codes...

I don't know what to make of it... but it's good that I get the logic.
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 3785

PostPosted: Tue Aug 04, 2015 10:18 am    Post subject: Reply with quote

You need to go back and learn the basics of boolean math to understand the different kinds of complements (comp), most significant bit (MSB), etc. Hex deals at the byte level, but you're flipping bits, so you need to work in binary unless you can convert the hex to binary in your head. You need to do these format conversions by hand. RM won't do them for you.

I learned all this stuff in engineering school, but there are some great wiki's out there that at least cover the basics. Like anything, you need practice to understand and get good at it.
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 6968
Location: Florida

PostPosted: Tue Aug 04, 2015 10:44 am    Post subject: Reply with quote

Or you can use the HEX Tool in Bart's IrScrutinizer that does the hex for you, and lets you switch back and forth effortlessly.

In a very, very simple protocol like this, there is a direct relationship between the hex and the OBC. That is not usually the case.

If you want to switch it back,

In RMIR under Hex settings, make sure preserve data is not checked.
Copy the Hex column from the functions,
Edit the protocol to interpret the protocol as LSB , its MSB by default.
Then edit the device again and paste the hex into the hex column.
Note you will also need to fix the Device.

Again, I didn't have this problem. You found some sort of bug that I didn't. Your procedure is different then mine. RMIR doesn't like custom protocols very much, but if the procedure is uncomplicated, it sometimes works. I know that you deleted a device and added it back in one motion, I could see that because it forced you to change the protocol from 01ff. I never do that. I always save and close after the delete, and
exit RMIR and then reopen. Then it seems to work. You also had two custom protocols in the same RMIR, I haven't thoroughly tested it/
Back to top
View user's profile Send private message Visit poster's website
digital_silence



Joined: 22 May 2004
Posts: 237

PostPosted: Tue Aug 04, 2015 6:58 pm    Post subject: Reply with quote

:-)

mdavej, I work (amongst the other tasks) as an embedded systems designer (both H/W and S/W) and write C and Asm code, so all those BIN-HEX-DEC conversions, flips and shifts are hardwired in my brain... :-)

My questions were caused by a couple of confusing (to me) things:
When I asked Rob what "Comp'd" was, I was just confused by that 'd suffix, as usually "(two-)complement" term is used rather than "complemented".
Also, I don't understand the reason for using the complements in RM. Those are normally used for representing the negative numbers, but all HEX and OBC codes are positive (or non-negative, I should say). Codes above 127 (the ones having 1 in MSbit) could I guess be interpreted as negative numbers, but from what Rob's written above, they all get "complemented" by subtracting them from 256 (we have to discard bit8 for comp OBC=0 though). Beats me.
I am pretty sure there is a logic behind doing this and that's just my poor familiarity with the JP1 tools.

I fully appreciate the MSbit/LSbit dualism though, as the sequence of bits can be serially transmitted Head-first or Tail-first. That's okay.

And my main question was: Why in the scenario when I don't change any settings in RM options, and I manually enter the following info:
Button-OBC-HEX:
-------------------
"0"-0-00
"1"-1-80
"2"-2-40
"3"-3-C0
"4"-4-20
"5"-5-A0


and then just Save->Quit->Start->Load, it changes the data into:
Button-OBC-HEX:
-------------------
"0"-0-00
"1"-128-80
"2"-64-40
"3"-192-C0
"4"-32-20
"5"-160-A0


When I said "I don't know what to make of it", I meant: "...what to make of the fact that they don't load back the same as they were saved".
The conversion functions are as clear as: New OBCs are just HEX2DEC of the hex codes.

Vicky's answer above kinda suggests that it is a bug, but it's strange that it doesn't show up in Vicky's setup.

Maybe that's because all the bits are flipped "upside down" here Down Under?... :-)))
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 3785

PostPosted: Tue Aug 04, 2015 8:11 pm    Post subject: Reply with quote

Sorry, that "comp'd" question gave the impression that you had no idea what we were talking about. I see this is far from the truth. My apologies.

Unfortunately I have no clue why the bits are flipping by themselves.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18539
Location: Chicago, IL

PostPosted: Tue Aug 04, 2015 10:39 pm    Post subject: Reply with quote

I can't speak for what RM is (or isn't) doing as I haven't used it in years and I've been through several PCs since I last used the tools, so I don't have Java installed.

Anyway, the only reason we need to ever consider complements is because you create an executor you have two options as to which pair you consider to be the logical 1 or 0, so one option would be the natural binary and the other would be the complement, and UEI typically chooses the complement. My use of the term "comp'd" was just an abbreviation for the longer term complemented, so yes I was using it as a verb.

But back to the question at hand, RM stores codes using the hex codes, so when you re-load an upgrade using a custom executor, there are 4 possibilities for how it interprets the hex in order to come up with OBC codes. I don't recall what options you have to switch between the 4, so a current user would have to advise on that.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3241

PostPosted: Wed Aug 05, 2015 12:01 pm    Post subject: Reply with quote

digital_silence wrote:
When I asked Rob what "Comp'd" was, I was just confused by that 'd suffix, as usually "(two-)complement" term is used rather than "complemented".
Also, I don't understand the reason for using the complements in RM. Those are normally used for representing the negative numbers, but all HEX and OBC codes are positive (or non-negative, I should say). Codes above 127 (the ones having 1 in MSbit) could I guess be interpreted as negative numbers, but from what Rob's written above, they all get "complemented" by subtracting them from 255 (we have to discard bit8 for comp OBC=0 though).
I suspect, based on this quote, that there's a bit of misunderstanding here. If I'm wrong about that, my apologies in advance....
Anyway, regarding the complement that Rob refers to, mathematicians typically call this operation as the "one's complement". Computer programmers typically call it simply the "complement" or the "bit-wise complement". It can be performed by subtracting the operand from 255 if the operand is 8 bits. More generally the operation is performed on x by calculating (2^N-1)-x, where N is the number of bits of x. In binary notation, it can also be performed by replacing each 1 with a 0 and each 0 with a 1. The C programming language employs the ~ (tilda) character to indicate this operation. The Samsung ASM language uses the mnemonic COM; x86 ASM uses NOT.

"Two's complement" is formed from x by calculating 2^N-x (256-x for 8 bit numbers), and as you say it is very useful in performing signed arithmetic. For 8 bit numbers, The C programming language denotes this operation with the - (minus) character. x86 ASM uses NEG. I don't believe Samsung has a notation for this operation. Offhand, I can't think of a use for two's complement in forming IR signals.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> Code Search (Closed) All times are GMT - 5 Hours
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central