Hi all. I'm new here to Remote Central and thought I'd share my latest remote control project/challenge.
So I've been working with a client that owns a Screen Innovations projector screen and it's one of their older ones. This one uses an NECB22 controller board in it, which uses a PIC16C54C microcontroller. Screen Innovations was able to provide me with the hex code data, but not in Pronto format.
This customer is expecting us to program it to his URC MX980i universal remote control, which only takes hex codes in Pronto format.
I've been really researching the controller in this projector screen. It's one of their older ones and apparently their screen controllers are designed and manufactured off site so they have no technical data on them whatsoever. So I embarked on a journey to reverse engineer this controller both inside and out.
If you ever encounter one of these projector screens that is hexagonal in shape and uses the NECB22 controller board in it, here is what I know -
The IR data uses the NEC format with the exception that bytes are sent and received MSB first. I'm not yet clear on the carrier frequency that it uses but I'm pretty sure it uses a 38kHz carrier frequency. The data decoded by the IR sensor is inverted from this logic, but as sent from the remote, the bit timing is as follows -
Lead in bit is a 9mS high followed by a 4.3mS low
Logic low is a 550uS high followed by a 550uS low
Logic high is a 550uS high followed by a 1.8mS low
Lead out bit is a 550uS high followed by a 20mS low
Each command sends 4 bytes. The first and second bytes are a device code and are the 1's compliment of each other. The third and fourth bytes are the command bytes, again both are each others' 1's compliment.
Example...screen up is 0xB1 0x4E 0x90 0x6F -
0xB1 = 10110001 0x4E = 01001110
0x90 = 10010000 0x6F = 01101111
The data stream is sent with the lead in bit first, followed by all 4 bytes sent in the order listed as one 32-bit value MSB first. The last data bit sent is proceeded by a lead out bit of 550uS high, followed by a 20mS low. All this for a total of 34 bytes.
Following articles written here on Remote Central, I came up with the following Pronto hex code for the screen up function -
I have not tested this code yet but will be by the end of the week.
I have also been working on writing new firmware on a PIC16F628A microcontroller for this projector in case I'm unsuccessful in getting this to work. The URC CCP software has hex codes for lighting controllers made by Screen Innovations that also use the NEC MSB first format. Everything about the signals sent out by the URC remote is identical except for the codes themselves. My new firmware will allow the projector screen to work with those codes while also working with its original codes.
Anyone who is well versed in pronto code please feel free to correct my above pronto code. I calculated the values assuming a 38kHz carrier frequency and was aiming for the criteria listed above.
