Hmm...I have tried all thinkable combinations, analysed the code, tried learning the damn thing, but still no luck.

The situation is as this: I have an old ccf file (TSU2000) with 16 fully tested and working IR codes. My Pronto is the TSU3000 so to use the same codes, I have to either import the ccf or manually copy/paste them. By doing so, the leadout word changes from 07D0 to 0800 and the codes wont work.

One of the codes look like this (but they are all more or less identical)
0000 0009 0000 0023 0014 0069 0014 0032 0014 00c3 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 07d0

They are all within the "high" frequency range (from a IR point of view) at around 440KHz (0009h).

Have tried contacting Philips, but still waiting for an answer. Please help, cause I'm stuck?

Thanks
/Peter

I assume you actually tested that it didn't work, rather than just assuming it wouldn't work once you saw the leadout had changed.

It absolutely doesn't matter that the leadout changed from 07D0 to 0800. The device receiving the signal doesn't care. If it didn't work, then it was for some other reason.

Who "fully tested" the original codes? Do you have a TSU2000 to test with, or are you trusting the testing of whoever made that CCF, plus trusting that your device responds to the same code set.

As you noted, that's a rather high frequency. I don't know whether the TSU3000 can transmit that frequency, though it would be quite bad design if it can't.

If you have a TSU2000 as well as the 3000, can the 2000 learn at that frequency? If so (or even close) you should try learning from the 3000 to the 2000 the signals that were pasted from the 2000 to the 3000. Then inspect the learned hex from the 2000 and see what distortion was introduced by the 3000 in transmitting the pasted signal. If you understand the distortion, you can edit the hex to pre compensate it.

I keep asking, but it appears that no one has yet confirmed that high frequency codes work on the TSU3000.

Thanks for the reply johnsfine.

Ok then, at least I dont have to focus on the leadout word anymore.

The CCF file can be picked up from the website of the product to be controled by these codes. The ccf file has been available there for a long time and I have been in dialog with a couple of TSU2000 users who use it on a daily basis.

I only have the TSU3000 and for the next week or so also the original remote from which I hoped to be able to learn the codes from. But, as the Pronto cannot learn the high freq. codes I have to do it the hard way (whatever that is!?)

I have tried playing around with codetypes starting with 7000h as I believe they are used by the internal DB for brands as B&O and other high freq. devices, but cannot even get the TSU3K to accept such codes.

The original remote works 100%. The TSU2000 ccf file works 100% on a TSU2000 (though I cannot guarantee that the codes are 100% clean!!). So whats left? That the Pronto NG no longer support 440-450KHz? (I don't believe that). Or maybe their internal DB mess things up trying to match a "learned" code with a build-in code????

/Peter

BTW, I have tested it on the last two firmware releases and corresponding PENG versions - Same result!

What happens when you try to learn from the original remote to the 3000?

I found a B&O CCF online that (mostly) worked when I imported and downloaded the whole file to the TSU3000. v1.2 was not too happy editing the file. Toolbars and other elements would come and go and there were some odd, poorly formed messages in a pop-up window, but the resulting CCF could control the CD, Cassette, and Tuner in a BS-2500. Volume up, down, and mute would not work.

If I attempted to load the imported CCF and my own PCF into separate windows, then copy and paste the B&O IR codes into my own screens, nothing worked.

When I learn the code directly to the TSU3000 it wont work. As the Pronto learning eye is not cabable of learning the code correct due to the freq. it is expected that the learned code will be garbage. The Pronto however uses a buildin feature to lookup such garbage codes and compare them to its internal IR Database. If it finds a match, it will owerwrite the garbage code with it own clean high freq. code and it will appear that the Pronto can in fact learn high freq. codes after all (hope my explanation makes sence to you). Anyway, the learned code looks like this (compared to the one in my first posting):

0100 000D 0000 0022 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 002D 0003 0091 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 005F 0003 053E

This code is too neat to be garbage, so I believe it is a lookup code. But, it wont work which actually can be seen without testing it. The type has changed and 000D is too far from 440KHz. In spite of this I have of cause tried it (always hoping for a miracle) but as expected, it didn't work.

Knowing the correct frequency, one could translate that into normal Pronto Hex. The result would be significantly different from your original signal. I haven't yet thought of a good explanation for that.


It is not a lookup code. It is an unmodulated code.


The 000D is not a modulation frequency (since there is no modulation). It is used as a time unit for the other numbers, but the process of picking that time unit has little to do with the real signal. The values that matter should be the product of the time unit with the other numbers. A typical pulse is (3+5F)*22 = D04. In your modulated signal a typical pulse is (14+69)*9 = 465 (all numbers base 16).

It's hard to guess why the captured values are three times larger than expected. Maybe the internal format used by the 3000 is quite different from that used by older models and the editing program is doing a bad job of the conversion to display the results in Pronto Hex. Maybe the 3000 uses a higher speed clock for capturing and some firmware or editing program bug fails to take that into account.

All of that seems to indicate that more of the bugs are in the editing program and fewer of the bugs are in the firmware than one might have guessed from earlier results.

Also it seems to confirm that the 3000 can transmit the high frequency signals (once one somehow gets beyond bugs in the editing program).

How different is a PCF file from a CCF file? Do the people working on Tonto have the PCF file structure information? Are they adding support for it?

What online CCF file were you using? I'd like to see what is different inside that file between the signals that worked and those that didn't.

Oh, I see. But then, why does the Pronto regard it as an unmodulated code? Johnsfine, from what you have read so far, can you come up with any idea on how to proceed?

Thanks
/Peter

If there is any sort of analog or digital filtering or noise supression involved in the learning then one would expect to get unmodulated for any signal well above the frequency learning was designed for. What I didn't expect was for the pulses to be three times longer than in what we believe is the correct signal.

I don't really know how to proceed.

Anyone who has both a TSU3000 and any good IR learning device could investigate the nature of the bugs in the firmware and/or editing program and probably deduce a work around. I'd be glad to help with the analysis, but I don't have a TSU3000. I assume you don't have any good IR learning device.

If one knew or reverse engineered the format of the PCF file, one could investigate the bugs in the editing program.

The only IR learning device I have besides the Pronto is the TIRA but thats no good either.

I guess I have to wait until Tonto comes up with an PCF supported update or even better hope that Philips will recognize these problems as bugs they just have to fix.

Anyway, thanks a lot for all your help. I will make updates to this thread if/when I hear from Philips.

I think I have the solution (now that I've learned quite a lot about the format of a PCF file and the bugs in PENG).

Take each of you IR hex signals. The sample you posted above was:
0000 0009 0000 0023 0014 0069 0014 0032 0014 00c3 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 07d0

Change the frequency to something that doesn't trigger the severe bugs in PENG. I changed the 9 to 90 getting
0000 0090 0000 0023 0014 0069 0014 0032 0014 00c3 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 0069 0014 07d0

Paste that in to PENG.
Save the PCF file.
Use a zip program, such as WinZip or Wiz to open up the PCF file.
Extract the xml file (unless you're particularly good at navigating the primitive text editor that may be built into your zip program).
Open the xml file in a text editor (such as WordPad).
Find the IR codes. The one shown above will look like this:

32 0 f 6c 4 7f 7c 14 69 32 c3 3f 5f bc 12 32 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 c1 37
(you can search for the text "code>" and the IR code comes right after that.)

The sixth value in the IR code is the frequency. 7f in the TSU3000 corresponds to 90 in Pronto Hex. Change that to 8. So you get

32 0 f 6c 4 8 7c 14 69 32 c3 3f 5f bc 12 32 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 c1 37

Save the corrected XML file, then update it into the PCF file (how to do that depends on which zip program you're using).

Open the PCF file and load it to the remote.
You can open the IR signal and look at the Pronto hex and see that it is roughly right (PENG does only a poor job of translating its internal format to Pronto hex, vs. the horrid job it does translating Pronto Hex to its internal format). If you do so, don't press OK, and/or don't save the PCF file. Even if you just look at the Pronto Hex and don't edit it, PENG translates back corrupting the signal.

I hope your device isn't too picky about the exact timing because the above only gets things close. With all of PENG's rounding errors I can't compute its actual time unit, so I don't know for sure how much the timing drifts when you use a value like 0090 for the wavelength (frequency) word in the Pronto hex, so I don't know what tweaking is called for other than changing the frequency.

Yesterday I read about that other guys discovery about opening the PCF file as a ZIP file. Im amazed that Philips just covers up the ZIP format by changing the extension - Way to go Philips!!

Well, when I say your latest posting, I couldn't wait to try it out...but it didn't work :-(
Nevertheless your idea was great and if Philips wont fix the bug this might be the way around. BTW, have you mapped the complete code format in the XML sheet by now ;-) (I looked at it yesterday and couldn't make head or tail of it).

And just to foresee your next question I have to mention that I did not open up the IR code to view it after changing the XML data. I just changed it, put it back into the PCF file, loaded it and downloaded it. Sad sad sad, I was convinced that it would work!

/Peter

There are several file formats that are really ZIP files (The .JAR files used for Java applications are a good example). Philips isn't doing anything unusual by making that their PCF format.


Email a copy of your modified PCF file to me. If a TSU3000 really can't manage that high a frequency, or if I'm making an error in reverse engineering their format, or if something strange happens in the TSU2000 processing of this signal, then it will remain hard to crack (without a good IR learning device used together with a TSU3000). But the instructions I gave were complicated enough that maybe you just got a step wrong, which I should be able to spot by looking at the PCF file after you modified it.


I know much more than I explained there, but much less than "complete". My only major tool is using PENG to translate from its stored format to Pronto Hex. I have deduced certain minor bugs in that translation and certain major bugs in the reverse translation, but without learning test signals from a TSU3000 to some good learning device, there is no way to be sure about the PENG bugs. There are several features of the translation that I suspect are bugs even though they are consistent in both directions.