|
|
View previous topic :: View next topic |
Author |
Message |
vinnyc
Joined: 25 Sep 2008 Posts: 1
|
Decoding Pronto Hex for infrared device control |
Posted: Fri Sep 26, 2008 12:03 pm |
|
|
Hello Folks,
I was hoping someone can point me in the right direction. I am trying to put together a small circuit board that will allow me to control my TV and other A/V devices through infrared emitters. I have all of the infrared codes required from a pronto universal remote. The codes are stored in 'pronto hex format' which seems to be pretty standard across all of these IR control products.
More information about the Pronto IR format can be found here:
http://www.remotecentral.com/features/irdisp1.htm
I was wondering if there was some information on how to read in these pronto hex codes and emit the infrared flash sequence through an IR blink emitter/ ir blaster.
Thanks!
-VinnyC |
|
|
Rohit de Sa
Joined: 09 Nov 2007 Posts: 282 Location: India
|
|
Posted: Sun Sep 28, 2008 11:12 am |
|
|
Hi VinnyC,
Apparently, from the link attached, the Pronto Hex format is nothing, but ON / OFF times for each pulse, nothing more, and nothing less. The hex numbers indicate the time for each ON / OFF pair.
If you want the specs for each protocol try, this link, I've found it very helpful:
www.sbprojects.com/knowledge/ir/ir.htm
You could simply design a program to read the hex value and create an appropriately long delay based on that value. Do note that you will have to strip the hex files of superfluous data. From examples given ( www.remotecentral.com/features/irdisp3.htm ), the Pronto Hex Format seems to be 16 bits long, with a preamble, modulation frequency, delay length for a repeat transmission, etc etc. Do note that since you want to implement various remote controllers, the modulation frequency may vary (though I find that most remote use a 38kHz carrier), and hence, the microcontroller code will have to be intelligent enough to adjust for this.
So my approach would be:
(read Pronto hex) --> (figure out modulation freq) --> (setup length of repeat transmission, if any) --> (work out length of repeat delay) -->(send start bit) --> (use the hex values to generate appropriate delay between On and Off)
Rohit |
|
|
sanddune008
Joined: 23 Oct 2008 Posts: 38
|
Pronto code transmission |
Posted: Thu Oct 23, 2008 7:12 am |
|
|
Hi Rohit,
How does one transmit the preamble , As per
http://www.remotecentral.com/features/irdisp2.htm
burst pairs are not used to represent preamble.
for e.g. if i have to send a preamble
0000 006D 000C 0018
is it just toggling my pin 38khz.........as 006D represents 38khz.
correct me if i am wrong...........
Thanks |
|
|
Rohit de Sa
Joined: 09 Nov 2007 Posts: 282 Location: India
|
|
Posted: Thu Oct 23, 2008 9:46 am |
|
|
Sanddune:
Thats right (as per the data given in the link).
0000 represents that data has been 'learned'
006D is the IR carrier frequency (with the correct conversion formula applied)
000C says that there are 12 'burst pairs' in the first sequence
0018 says that there are 24 'burst pairs' in the second sequence
I myself have not worked with Pronto Hex files, so I can't comment on the veracity of the information. But I'll google around and post if there are discrepancies.
Quote: | for e.g. if i have to send a preamble |
Do understand that in the case of the Pronto Hex file, the preamble is not really transmitted. Actually, I would refer to it not as the 'preamble' but rather as the 'information header'. This header tells the transmitting hardware how to set itself up. Keep in mind, this Pronto Hex file is probably used by something similar to a universal remote control. There will be hundreds of remote control types that the universal remote will have to 'remember' the exact data specifications for. The Pronto Hex file is simply a format for this. The only things that are transmitted are Burst Sequence 1 and Burst Sequence 2 (if applicable).
Rohit |
|
|
sanddune008
Joined: 23 Oct 2008 Posts: 38
|
Pronto code transmission |
Posted: Fri Oct 24, 2008 12:54 am |
|
|
Hi Rohit,
Then there is no need for a preamble.
As per my understanding, receiver will wait for the preamble
from the transmitter. After decoding the preamble, the receiver
will be tuned to the frequency encoded in the second word of the
preamble.
Hence isn't it necessary to send preamble ?
If so then how ? Should the preamble data need to be
modulated at carrier frequency(38khz) or just send the
preamble data to the pin.
Your help is appreciated.
Thanks, |
|
|
Rohit de Sa
Joined: 09 Nov 2007 Posts: 282 Location: India
|
|
Posted: Fri Oct 24, 2008 3:07 am |
|
|
In communication terms a 'preamble' is that data which is sent just prior to the 'payload' (ie, the useful data). The preamble may contain several synchronizing bytes, timing bytes, etc. Typically, in IR remotes, the preamble is used to 'wake up' the IR receiver and controller. In the Sony protocol (SIRC), this 'preamble' is just a high pulse of 2.4ms followed by a low of 0.6ms. I wouldn't call it a true 'preamble', but I will not go so far as to say that it isn't a preamble at all. It's more like a 'start' bit.
Now, in the case of the Pronto Hex format (which is just a file on your PC) the 'preamble' refers to setup information. The preamble, as given in the file, is not actually transmitted. That is why I said in my earlier post that I don't like calling it a 'preamble'; I would rather call it a 'header'.
The true preamble that is really transmitted is encoded in the Burst Sequence Pair as simple ON/OFF times.
If you are looking to make some sort of transmission hardware I would recommend you take a look here:
Try to understand the different protocols. It will help you to figure out the Pronto Hex format.
Here is a quick example to help out:
In the SIRC protocol when I press the button '1' on my remote the following IR pulse train is sent out of the remote at 38Khz:
(high 2.4ms)(low 0.6ms) Start
(high 0.6ms)(low 0.6ms) bit0
(high 0.6ms)(low 0.6ms) bit0
(high 0.6ms)(low 0.6ms) bit0
(high 0.6ms)(low 0.6ms) bit0
(high 0.6ms)(low 0.6ms) bit0
(high 0.6ms)(low 0.6ms) bit0
(high 0.6ms)(low 0.6ms) bit0
(high 1.2ms)(low 0.6ms) bit1
(high 0.6ms)(low 0.6ms) bit0
(high 0.6ms)(low 0.6ms) bit0
(high 0.6ms)(low 0.6ms) bit0
(high 0.6ms)(low 0.6ms) bit0
If encoded as the Pronto hex format this would probably be:
0000 006D 000C 0000 9624 2424 2424 2424 2424 2424 2424 2424 4824 2424 2424 2424 2424
Rohit |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|