Hi,
I have a Barco Graphics 808 CRT projector (build before 2000, i.e. before Barco swichted to RC5 codes) and want to make it work with my TSU7500. I had no success so far, however. I found CCF Files on Remote Central for the BG808s (BARCOGRAPHICS 808-S last-1.ccf; as the "s" variant of the BG808 only uses diffenrent tubes (Sony) I expected it to work perfectly), but after importing it nothing worked. I tried also others for the Barco800 or 701 series, but the codes that I found in the IR-Dialog were the same with those as well. It appears to me that the "great" Code Cleaner is messing up the learned code from those CCF Files in the same way it does so when I learn them myself.

Here the results of my attempts so far:

I use the Standby Command as an example. First the result of the learning process (no difference between learning via ProntoPro Edit NG (PPENG) or via the TSU7500 alone). The learned Code does not work. As far as I can tell it is an unmodulated code, of which I know only one format, which is TTL or PPL. The learned command consists of 14 words and seems similar to that of a TTL code, but the timing differences are too great to work as TTL. For a TTL code the Lead in (0003 0054) would need to be with 300µs three times as long as the following start puls (0003 0027) which should be 100µs long. 54 hex and 27 hex, however, are no not even close to the needed 3:1. The logical 1 in TTL-coding should be 200µs long and should relate to the start pulse as 2:1. That is not the case either, since 2D hex is not even close to twice of 27 hex. The complete code as learned is as follows:

Learned Stby
0100 000D 000E 0000 0003 0054 0003 0027 0003 002D 0003 0027 0003 0027
0003 002D
0003 0027 0003 002D 0003 002D 0003 002D 0003 0027 0003 0027 0003 0054
0003 0054

Since I assumed that the projector needs TTL code, I tried to calculate what the correct values for the needed timing in TTL should be. While keeping the freq. value of 000D (hex) I came up with the following sequence, which I entered manually:

manual entry
0100 000D 000E 0000 0004 005C 0004 001C 0004 003C 0003 001C 0004 001C
0004 003C
0004 001C 0003 003C 0004 003C 0004 003C 0003 001C 0004 001C 0003 005C
0004 005C

After closing the IR-code dialog and reopening it again I found that the stored code was not what I entered, but the same as the result of my learning attempt above. It seemed that the code cleaner was at work and changed my code (which I hope would have worked) into something that did not. To make sure I had not made a mistake entering the code I started with a new button without first learning a code into it. The result was the same as before. Since the code that was stored was not the one I entered, I can only conclude that the code cleaner completely messed up my code to render my (hopfully) funktional code into a non-funcional one.

Hoping to outwit the code cleaner and to get the remote to send the seqence I want to try, I tried again with a different freq. divisor and calculated a new sequence for that. The code I entered manually was:

Stby with div=1
0100 0001 0000 000E 0029 04B2 0029 017B 0029 0313 0029 017B 0029 017B
0029 0313
0029 017B 0029 0313 0029 0313 0029 0313 0029 017B 0029 017B 0029 04B2
0029 1000

But alas, the code cleaner was busy again and mangled the code back to the result of the learning process. This time therefore it also changed the freq. divisor to get back to the non-functional code.

Still hoping I could get anywhere I tried a suggestion I found on remote central and used a modulated signal, but with a freq. setting so that one cycle would produce the needed on time of about 10µs. The code I entered was as follows:

Stby with div=42 modulated:
0000 002A 000E 0000 0001 001D 0001 0009 0001 0013 0001 0009 0001 0009
0001 0013
0001 0009 0001 0013 0001 0013 0001 0013 0001 0009 0001 0009 0001 001D
0001 001D

But no luck this code was changed too, but only the first bit (0001 0013) was affected and the 0013 change into a huge number (I don't have it around right now, but it was big like 5784 (hex)). Each time I closed and reopend the Dialog this number was changed again while it got slowly smaller and smaller, but never small enough. With this long off-time in between the code could not work of course.

With each entered code I also tried changing the values of each word-pair somewhat (but within 20% of the needed timing), but this did not prevent the changes as described above.

I'm now out of ideas.

Therefore my question: How can I keep the code cleaner from touching my manually entered code? Is there a chance to get my projector working with the TSU7500 or will the code cleaner efficiently prevent that?

Why is manually entered code run through the code cleaner at all? After all a human entered it and it seems likely that what was entered was what was intended. For learning code cleaning seems to make sense but not for manually entered code!!

If it is not possible to avoid the code cleaner touching manually entered code now, then this should definitly be an option in the next release of PPENG (checkbox to swich of the code cleaner would be sufficent). After all: What chance is there to produce an exactly specified code if the code cleaner mangles it beyond recognition?


Any input? Thanks.



P.S.: I used decodeCCF to find out what the ccf file for the BG808 I found on remote central contained. The field that for the timings of the stby command read as follows:

23_275 23_78 23_173 23_78 23_78 23_176 23_78 23_173 23_176 23_173 23_78 23_78 23_275 23_124219 23_275 23_78 23_173 23_78 23_81 23_173 23_78 23_176 23_173 23_173 23_81 23_78 23_275 23_124239 23_269 23_78 23_176 23_78 23_78 23_173 23_78 23_173 23_176 23_173 23_78 23_78 23_269 23_275

I assume those numbers are the on and off times in µs and if so they seem to confirm my assumtion that the projector expects TTL code. Also the timings as stored in the CCF file seem to be close enough to be a working TTL code. Therefore it (and the ones for the other commands) probably would work, if the code cleaner would just leave them alone.

You may not be aware that the hex code you enter is not in the same format as what is actually stored in a PCF. Some (but not all) of the "cleaning" you see is a result of converting it to the internal format then back to what is displayed.

ok, but still the result is that after "converting" back and forth the hex code I see is drastically changed and decoding it makes it clear that those changes are not only cosmetic or rounding differences but are a completely different timing and therefore signal, which can't work as intended.

How do I enter the presumably needed signal so that it will not get changed into beeing non-funktional?

I've been involved in a number of threads concerning failure of the NG Prontos to transmit high speed unmodulated signals correctly.

I don't recall any in which the problem was solved.

The errors that occur in the translation process to or from the internal format are just a small part of the problem. You can access the xml file inside the pcf file and find and directly edit the internal format, avoiding all those translation problems, but the NG Pronto still doesn't transmit the signal correctly.

That is why I tried using modulated signals as described. But PPENG mangles those hex values too (be it because of code cleaner or conversion).

I presume, that what really counts in TTL-format is the start times of the different pulses. Therefore I could probaly use a 20µs on time plus 80µs/180µs/280µs off time as long as the total length is more or less observed (i.e. 100/200/300µs) with +- 20% accuracy so that the different flashes of IR are the correct distance apart.



Has Philips Support reacted to the problem of high speed unmodulated signals?
Does this also apply to modulated signals as the ones I tried?


Hm. Seems hard to find in the PCF files. What would I need to look for?

Sorry I gave the wrong impression with "high speed unmodulated". I have no reason to believe the "unmodulated" aspect of the signal is a significant part of the problem. The NG Pronto firmware can't generate high speed signals. The home entertainment devices that use high speed signals almost all use high speed unmodulated signals, so that's the subject of most of the threads. But the issue is the high speed, not the unmodulated.

I have tried even more imaginative ways of using a modulated signal to duplicate an unmodulated signal. I reached levels much faster than an NG Pronto can achieve as a simple unmodulated signal, but not fast enough to meet the needs of the actual device, so no direct way to tell if such tricks could really work (measured how close it could get by relearning with another remote rather than the simple binary pass/fail of the actual device).


I did those tests directly in XML to bypass that mangling. It still didn't work.


Correct. I went even further and made the modulation wavelength the entire duration of the shortest total. That way instead of one short pulse being 1 unit one and N units off, multiple short pulses in a row were that many units of modulated on, then a longer pulse would need extra off time. That could generate significant subsets of the correct signal but mangled things when there were two long pulses in a row.


If aiming for 100/200/300, my system would have used 10Khz modulation, getting 50 On / 50 Off for the 100's. The NG Pronto firmware (back when this was tried) could do multiple cycles of 10Khz easily. But a 200 that isn't precceded by 100's should be 1 modulated on followed by 1 off. That's what is too fast for the firmware.


Not that I've heard.


Yes.


You mean extract the XML file from the PCF file? Or you mean find the internal IR hex code in the XML file? Or what do you mean?

The instructions I just gave here:
[Link: remotecentral.com]
for BMP are equally good for XML.

Ok, but that would seem to only affect the 7000/7500 as there is a ccf file for the BG808s on remotecentral, which I presume worked on the model it was created for.

If the firmware is the problem and the problem is known for a while already, then why is Philips not correcting it?
Anybody from Philips Suppor reading this?


I mean how do I find the code that I would need to edit in the XMl to bypass the mangling.

I never figured that out. But I think some of the other experts here have better tools for navigating XML.

I used a tiny configuration with only a few IR signals (emailed back and forth between me and the person actually testing, since I never had a Pronto). Since there were so few IR signals in the config, I could use some secondary clues about the signals themselves to figure out which signal in the xml went with which button.

There are a few old threads somewhere describing the partial understanding that I and others (independently) reached regarding the hex encoding used for IR signals inside the xml file. That format is very similar to the Neo Hex format that others had investigated and writen about even earlier.


I said it affects the "NG" Prontos. I have no idea what a BG808s is. I don't know which Pronto models are in the "NG" family. But I think "ccf" indicates it is not an "NG".

BG808s means the crt projector Barco Graphics 808s. I agree that ccf file means its not a ProntoProNG. What I meant is, if it worked for earlier models of the pronto family, then it should not be too complicated for Philips to fix the firmware so that it works on the NG too.