HV Ir Format x-post

["Dr John Tankard" <john@xxxxxxx>]

For those of you like me interested in IR formats, below is a post from the
HV list that might be useful

John
---------------------------------------------------------




Schelte,

Congratulations on your detective work!  See comments inserted below.

Thanks,

Craig Chadwick
President
Custom Solutions, Inc. (a.k.a., HomeVision)
mailto:csi@xxxxxxx
http://www.csi3.com
----------------------------------------------------------------------------
--------------
HOMEVISION: Home automation controller with two-way X-10,
two-way infrared, 24 I/O ports, over 50 video screens
on your TV, and much more!  Add-on phone interface, serial
ports, analog inputs, digital temperature sensors, and more.
----------------------------------------------------------------------------
--------------

> -----Original Message-----
> From: sbron@xxxxxxx [mailto:sbron@xxxxxxx]
> Sent: Sunday, March 04, 2001 9:04 AM
> To: homevision-users
> Subject: [HOMEVIS] Infrared signal format.
>
>
> In the past there have been a number of questions about the format of
a
> homevision infrared signal file. I have figured out enough of it
> so I could
> download the discrete signals for my TV (JVC) in Pronto format from
> www.remotecentral.com and convert them into a working homevision
> .irl file.
> I just discarded the Pronto header (4 words) and used the
characteristics
> (carrier frequency, duty cycle) of other ir signals learned by the
> homevision controller. Perhaps someone with knowledge about the
> Pronto codes
> can come up with that conversion. I don't have any information on
> raw pulses
> because I don't have a remote that uses that type of signals.
>
> Below is what I found out, for those of you interested.
>
> A .irl file seems to consist of three blocks: Header, Signal
> information and
> Pulse information (optional).
>
> Header (6 bytes):
> 2 bytes: Number of IR signals in the file (little endian)
> 4 bytes: Size of pulse information (little endian)
>
> Signal information (78 bytes for each IR signal):
> 30 bytes: Signal name, padded with spaces
> 1 byte: Signal type:
>         0 = Standard
>         1 = Pulse lengths
>         255 = None
> 1 byte:
>         Standard signals: Device code
>         Pulse lengths: Timer value for "on" duration
>         None: unused (0)
> 1 byte:
>         Standard signals: Key code
>         Pulse lengths: Timer value for "off" duration
>         None: unused (0)
> 1 byte:
>         Standard signals: unused (0)
>         Pulse lengths: Number of pulse cycles
>         None: unused (0)
> 4 bytes:
>         Standard signals: unused (0)
>         Pulse lengths: Pointer to pulse information (little endian)
>         None: unused (0)
> 40 bytes: Signal description, padded with spaces
>
> Note 1: The timer values are the values used to preload the
> microprocessor's
> 8-bit timer. The actual duration is the time it takes for the value to
be
> incremented until an overflow occurs. The microprocessor clock has a
> frequency of 11,059,200 Hz (?). The timer is incremented every 4 clock
> ticks, so at a frequency of 2,764,800 Hz.
> Example: The timer on value is 227 and the timer off value is 213.
> The "on" duration will be (256 - 227) / 2,764,800 = 10.489
uS
> The "off" duration will be (256 - 213) / 2,764,800 = 15.553
uS
> The carrier frequency is 1 / (10.489e-6 + 15.553e-6) = 38.4 kHz
> The duty cycle is 10.489 / (10.489 + 15.553) = 40.28 %
>
> Note 2: The pointer to the pulse information is relative to the
> start of the
> pulse information block, which is at 6 + (78 * <number of
> signals>) from the
> start of the file.
>
> Pulse Information (4 bytes for every cycle):
> 2 bytes: Number of pulses (big endian)

To clarify, this is the number of repetitions (or pulses) of the carrier.
So a 25uS carrier width (40Kz carrier) repeated, say, 20 times gives a
total
period of 500uS during which the carrier will be active (i.e., IR will be
transmitting)

> 2 bytes: Idle timer preload value (big endian)
>

> Note: Again the timer value is basically the preload value for a timer
> incrementing at a frequency of 2,764,800 Hz, except for bits 0-2.
These
> three bits of the indicated value are really a counter of how many
timer
> overflows should be skipped. Bit 0-2 of the preload value are always
0.
> Example: The idle timer value is 62585 (0xf479). The preload
> value will then
> be 62584 (0xf478) and 1 timer overflow will be skipped. This results
in a
> total delay of ((65536 - 62584) + 1 * 65536) / 2,764,800 = 24.771 mS.
>

This indicates how long IR will be off before turning on the carrier for
the
next pulse.  To be precise, we subtract 28uS from the desired time (to
account for the software delay in starting the timer, which is 28uS), then
add the carrier pulse off-time to the total desired off time (to account
for
how the prior pulse was transmitted).  For example:

- Assume we want a 500uS gap before the next transmission.
- Assume carrier is 25uS (40Kz carrier) with a 40% duty cycle.

We first subtract 28uS from the desired 500uS gap, then add 15uS, giving us
487uS that the timer must be off for.  This means we use an "Idle
timer
preload value", as Schelte called it, of 64192 (0xFAC0):

- Intermediate value = 65536 - (0.000487 * 2,764,800) = 64190 (rounded
off)
- 64190 is 0xFABE.  We zero out bits 0-2 by rounding up to 0xFAC0 (64192)


> Regards,
>
> Schelte Bron.
>
>   Post message: homevision-users@xxxxxxx
>   Unsubscribe:  homevision-users-unsubscribe@xxxxxxx
>   Homepage:     http://www.onelist.com/community/homevision-users
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>


Post message: homevision-users@xxxxxxx
Unsubscribe:  homevision-users-unsubscribe@xxxxxxx
Homepage:     http://www.onelist.com/community/homevision-users

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/





Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/