My guess is the tsu 7000 is NOT capable of sending these signals. But it is just a guess.bisterfinnen wrote: i would say that the tsu 7000 is capable of sending the signals, we just have to figure out what ingredients to serve it.
I don't think so. Even if it can be made to send that signal, we won't figure that out flying blind. You need to know what it actually sends when you try something. The CaptureIR program and associated hardware are the best way to find out.bisterfinnen wrote:We now have most ingredients of the receipt
After knowing what the 7000 is sending, I think we'd need to be editing the XML version of the hex, not the Pronto Hex version in order to avoid losing the details in the translation.
That's a lot more "ingredients".
I think they're just less willing to make unsubstantiated guesses about something neither I nor they know the answer to.bisterfinnen wrote: 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.
I remember noticing long ago that it was the same structure but different timing as pid_2A. I think I decided to make DecodeIR distinguish them, but then forgot to do so.bisterfinnen wrote: Were you familiar with the ITT protocol before i mentioned it?
I think Rob said the actual UEI executor 2A uses an spare bit to decide between two version of the timing. So probably DecodeIR and protocols.ini ought to be tweaked to get better support for this. Maybe even KM and devices.xls should be adjusted.
Other Nokia models use other protocols, which would tell nothing about how to make an NG Pronto send fast unmodulated signals.bisterfinnen wrote: 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.