JP1 Remotes

There were some old threads at RemoteCentral in which I explained the structure of IR signals in that format, which is similar to the NEO Hex that others have reverse engineered and documented in other threads. I've forgotten all the details now, so I'd need to find and reread those threads just to understand it myself.

I expect that with enough effort you could do much better modifying the signals in that form rather than anything you could do in ProntoProEdit. But I think it would be a lot of effort.

I also never figured out how to match the buttons to the codes. That seems to be strangely indirected through a few XML id numbers. I expect someone with a better understanding of XML might just know how that works (XML is supposed to be very general) and I've read threads about people building support for programs understanding this specific XML form.

I probably don't have enough time to lead you through the whole process, though I'm glad to answer questions about any aspect of it that I remember.

I'm pretty confident of the structure and timing details of this protocol as described in IRP notation under pid-002a at
http://john.fine.home.comcast.net/ir/De ... l#pid-002A

The threads about the XML hex codes go into enough detail to contruct the hex codes that correctly describe these signals. But we don't know how much of the problem is in ProntoEdit (that is bypassed by editing the XML) vs. how much is in the process of transfer to the remote and/or in the transmit firmware. I suspect a big part of the problem is in transmit firmware. Without a good IR capture tool you would be experimenting blind if the first try didn't work.

Here in JP1 we have documented an easy to build IR capture device from very low cost parts. I built one and few people are as inept at soldering as I am. With that and the associate CaptureIr software you can see what your remote is sending. If tweaks to the hex code could fix it, you would see which direction it needs to be tweaked.

Now you lost me...

1. I have found some more learned pronto hex for different nokia tv´s, none of them working though. Would it help you help me if i pasted some examples of them here?

2. What do you think about the possibilities for success if i borrow another multiremote like ofa/jp1 or similar and use them as a link between the original remote and the pronto or if i use the other mulitremotes built in/downloaded codeset for nokia tvs and send them to the pronto via learn ir. Could that work better than learning directly to the pronto from the original remote?

Do you have any other idea on how to solve the problem without having to learn complex computer and protocol editing? Im a real beginner at understanding that type of data and it would take unreasonable time to succeed.

Maybe i´ve just have´nt tried the optimal way of learning from the original remote, or does the pronto hex code i pasted earlier look "clean" enough?

bisterfinnen wrote:Now you lost me...

Sorry.

bisterfinnen wrote:1. I have found some more learned pronto hex for different nokia tv´s, none of them working though. Would it help you help me if i pasted some examples of them here?

No. We're pretty sure we know what the right Pronto Hex looks like, but it isn't working. More of the right Pronto Hex won't change anything and wrong Pronto Hex (incompatible model) certainly won't help.

bisterfinnen wrote: 2. What do you think about the possibilities for success if i borrow another multiremote like ofa/jp1 or similar and use them as a link between the original remote and the pronto or if i use the other mulitremotes built in/downloaded codeset for nokia tvs and send them to the pronto via learn ir. Could that work better than learning directly to the pronto from the original remote?

No. This is not the sort of protocol that is easier to learn from another universal remote than from the original remote.

bisterfinnen wrote:Do you have any other idea on how to solve the problem without having to learn complex computer and protocol editing? Im a real beginner at understanding that type of data and it would take unreasonable time to succeed.

Sorry, I don't know. Is there any kind of customer support available for the TSU7000? I think this sort of thing is a correctable defect in the firmware and editing software and the company ought to stand behind its product.

bisterfinnen wrote: Maybe i´ve just have´nt tried the optimal way of learning from the original remote, or does the pronto hex code i pasted earlier look "clean" enough?

I don't think learning could work.

I´ll call Philips customer support tomorrow. I´m not too hopeful about that though. Right now i´m so frustrated that i shiver. Time to sleep a couple of hours perhaps?

Let you know as soon as there is any progress.

Thanks for your help so far. Please dont give up on me and please continue to search for possible solutions.

Sorry! I realize now i left som very essential information out. I have a american tsu7000 and the nokia is an european pal tv. I did´nt realize the IDB and .pcf´s were different and locked to the regional models.

The IDB is different for ru980 and tsu7000 .pcf:s. i tried to make a completely new .pcf and choosed european model ru980 instead. When i looked in the ru980 IDB there were many code sets for nokia tv´s. Among them the 0190 (0163+27) and 0388 (0361+27) ones.

I configured a little .pcf just to try, then the next problem appeared. A tsu7000 wont load a ru980 .pcf. So i tried to save the .pcf as a tsu7000 one, that worked, but now the selected IDB codes had been changed to the first choice in the tsu7000 IDB (Device:cable, Brand:ABC, Code set:Codeset - 0030, Functions:"A").


Maybe you can help me to convert the commands in the ru980 nokia tv code set 0190 and 0388 to pronto hex or is there any other way to get them into my tsu7000?

Or is there any way to get a ru980 pcf into my tsu7000? by editing the .xml?

Warm regards and sorry for the mess-up.

Stefan

When you say IDB, do you mean UDB (for Universal Data Base) ?

I don't know much about how the various Prontos are configured internally, but I expect that the UDB is loaded as part of the ROM, which means it's hard wired into the physical remote itself, you can't just select a different one because you want to.

I just looked up the protocol in question again (ie, $002A with fixed data "80") and the only setup code that I could find for US remotes is TV/0078, and even that code isn't in very many remotes so there's no guarantee that it's in the Pronto.

This forum is as good a place as any to discuss IR signal issues. But for discussing ProntoEdit, XML, and PCF file issues for NG Prontos, you should be in
http://www.remotecentral.com/cgi-bin/mb ... g/list.cgi

I don't know the answers to what you just asked (I assume the other regulars here won't either).

The Robman wrote:When you say IDB, do you mean UDB (for Universal Data Base) ?

Yes, sorry

The Robman wrote:I expect that the UDB is loaded as part of the ROM, which means it's hard wired into the physical remote itself, you can't just select a different one because you want to.

Ok, that sounds logic. Too bad.

The Robman wrote:I just looked up the protocol in question again (ie, $002A with fixed data "80") and the only setup code tha I could find for US remotes is TV/0078, and even that code isn't in very many remotes so there's no guarantee that it's in the Pronto.

I´ll have a look. Thank you.

0078 means i should look for code set 0105 (0078+27) in the universal database right?

I looked for both code set 0078 and 0105 and actually found both. None that worked with my TV though.

0078 Curtis Mathes
GE
Midland
Panasonic
Penney
Prism
RCA
Technics
Techwood

0105 Harman/Kardon
Kloss

This is the protocol i guess?

http://www.xs4all.nl/~sbp/knowledge/ir/itt.htm

The setup code is 0473

What would the pronto hex be, knowing that?

Regards

Stefan

Now i´ve tried to understand the making of a ITT protocol pronto hex for my Nokia TV.

The code i have produced is

0100 000D 0006 0008 0003 005F 0003 001C 0003 003E 0003 003E 0003 003E 0003 003E 0003 001C 0003 003E 0003 001C 0003 003E 0003 001C 0003 003E 0003 005F 0003 93B1

The 4 first codes are
0100 raw unmodulated hex
000D = 13 = 320000 cycles per sec = 3,1 us per cycle
0006 number of burst pairs in once command
0008 number of burst pairs in repeat command

The following is the initiation sequence and the 4 adress burst pairs
0003 005F 0003 001C 0003 003E 0003 003E 0003 003E 0003 003E

Initiation and start burst pairs (2 burst pairs)
0003 10 us preliminary pulse
005F 290 us delay
0003 10 us start pulse
001c 90 us delay

Adress code (4 burst pairs)
0003 003E 0003 003E 0003 003E 0003 003E
This is the code for binary 1,1,1,1 in the protocol, which in hex is 15. That should correspond to TV

Command code (6 burst pairs)
0003 001C 0003 003E 0003 001C 0003 003E 0003 001C 0003 003E
This is the code for binary 010101 in the protocol, which is binary 21, in the command list it corresponds to one of the mid range digit buttons (4, 5 or 6 i think)

Lead out and stop pulse (2 burst pairs)
0003 005F 0003 93B1

First, why does PPENG mangle this code when i put it into PPENG and second why does´nt it work. What have i done wrong?

The NG Prontos have an internal format that is different from Pronto Hex.

I'm not sure whether the format stored in the Pronto itself is similar to the format stored in the XML file. Some experts have said it is not. But at least the format in the XML file is significantly different from Pronto Hex.

Even with no bugs nor other constraints, there will be at least rounding errors when you translate from Pronto Hex to the format in XML and back again.

There are also limits on the speed of signal that a Pronto NG can transmit. 100uS (the zero burst) is probably too short for it to process.

You may not have done anything wrong. The programmers who coded the firmware for the NG Prontos did a lot wrong.

also, all bursts are 10 us, it´s the gap that´s 100us. In ITT protocols it´s the gaps between the bursts that are the protocols.

Why would´nt TSU 7000 work to remote my TV when the codes are in the UDB for RU980 (the european equivalent)

I borrowed another philips multiremote from a friend yesterday, the SBC RU 760 and with code set 500 ( -27 would be 473) it worked great to control my Nokia TV.

bisterfinnen wrote:also, all bursts are 10 us, it´s the gap that´s 100us. In ITT protocols it´s the gaps between the bursts that are the protocols.

Difference in terminology: By "burst" I meant the total of a pulse and the following gap.
I'm pretty sure it is the burst duration that matters, both for the TV's interpretation of the signal and for the NG Pronto's inability to send the right signal.

bisterfinnen wrote: Why would´nt TSU 7000 work to remote my TV when the codes are in the UDB for RU980 (the european equivalent)

Just because the codes are in the UDB doesn't prove they work. Maybe an RU980 would fail just as badly as the TSU 7000.
On the other hand, maybe the firmware treats UDB signals differently than ordinary signals. The whole problem comes from some crappy coding in the NG firmware.

bisterfinnen wrote: I borrowed another philips multiremote from a friend yesterday, the SBC RU 760 and with code set 500 ( -27 would be 473) it worked great to control my Nokia TV.

I don't remember which model is which, but we certainly knew that older Prontos can send fast unmodulated signals that NG Prontos can't send.

Probably the older Pronto could even learn the signal.

While you have both, try using the older Pronto to capture (learn) the failing signal from the NG Pronto. We can then look at the Pronto Hex and see how far it is from correct. If it is near correct, maybe we can tweak the original Pronto Hex on the NG in the correct direction to make its output closer to correct.

The sbcru760 isnt a pronto, its a quite new good looking and cheap 6-in-1 steel remote, with a built in database, plus the ability to learn and to build simpler macros. These facts make my pity for not getting my expensive remote to work even greater

Unfortunately the sbcru760 has´nt the capability of showing the learned codes in a display and there is neither a cable input to connect it to a comuputer and therefor nor a editing program.

But i would say that the tsu 7000 is capable of sending the signals, we just have to figure out what ingredients to serve it.

We now have most ingredients of the receipt, but where the heck is the cook to make the dish

BTW, thanks John for your patience with me. As you can see noone at RC is at all interested in taking part in solving my problem.

Were you familiar with the ITT protocol before i mentioned it?

Next i´m going to examine some other protocols for nokia TV´s that i have gathered in an old prontoedit that doesnt mangle the hex to see how these codes are built.