Lectrosonics IR Sync Protocol

[jawharp]

Hey,

 

I was wondering if anyone knew if the IR frequecy syncing that Lectro gear uses is just an IR-ified version of the audio deeedle tones, or is it something different?

 

Thanks

[DanieldH]

Afaik most IR remote applications are "digital"/binary on/off blinking, i.e. pulsed signals, not different "colors". Dweddle tones are... well sequences of different tones. 

What are you trying to do?

Sidenote: lirc may be worth a look for capturing/reproducing IR stuff. There are also some Ardurino projects.

[jawharp]

A couple years ago I made a small bluetooth audio receiver that went between a lav mic and the transmitter with a passthru for the mic.  When the BT receiver was sent a dweedle tone, it would mute the mic and play the dweedle into the transmitter so the settings could be changed remotely without having to play the dweedles into the mic.  

 

My low level analog audio circuitry skills are in a word "terrible," so to bypass having to mess with the mic signal, I was wondering if I could make another version that would mount over the IR receiver.  That way I could change the settings remotely, and also save anyone on headphones from having to hear the dweedle tones.

 

I was thinking ultimately the whole thing could be rechargable and be mounted in a specialized beltclip you could screw onto the unit.

[DanieldH]

Sounds like quite a bit of engeneering and programming effort.

Wisycom's protocol is bidirectional, in the way that you see a success report on the RX, e.g. when syncing frequencies. I'd guess this is also true for various Lectro families. 

If you only need it unidirectional it might simplify things.

There is quite some stuff out there for relaying unidirectional IR signals for home electronics via IP or BT. Most of it is too big to put it on actors, though something like the raspberry zero w might do the trick but is still bigger than an audio BT box these days.

 

[Matthew Steel]

@jawharp, the IR sync format is not the same as the audio dweedle tones.  However, it is a fairly simple protocol that uses a standard 38kHz IR frequency and modulates it with 300 baud asynchronous serial data. Unidirectional only.  Yes, Raspberry Pi GPIO has enough current drive capability to supply an IR LED.

[jawharp]

Do you know anywhere I can get any more info on it?  I'm curious if it accepts other commands besides just changing frequencies.

[Matthew Steel]

The spec is not published as far as I know.  Here are some notes based on my poking around.  The only transmitters I have experience with are the LMb and the HMa, so the scope is limited.

 

The IR sync is 38kHz carrier modulated by an asynchronous serial data stream.
The serial data is 300baud, 8 data bits, no parity.
Logic 0 is carrier present, logic 1 is carrier absent.

 

The format of the data stream is as follows:

<0x18><parm1>=<value1>;<parm2>=<value2>;...<parmN>=<valueN>#<CC><CR>

<parmX>        Description        <valueX> (a decimal number)
irblk        The block number

                    19:    Block 19
                    20:    Block 20
                    ...
                    470:    Block 470
                    606:    Block 606
channel        The channel number

                    0:    Block base frequency
                    1:    Block base frequency + 25kHz
                    ...
                    1023    Block base frequency + 25575kHz
compat        Compatibility mode - NOTE: These are not the same as used by VRWB serial commands.
                    0:    Passthru (not sure what this is, sounds dangerous to me)
                    1:    100 series
                    2:    200 series
                    3:    Mode 3 - Sennheiser HiDyn Plus (Usable for EW G3 but Mode 6 may be better)
                    4:    NA Digital Hybrid
                    5:    IFB series
                    6:    Mode 6 - Shure UHF, pre UHFR (Usable with Sennheiser EW G3)
                    7:    Mode 7 - Audio LTD 2020/2040
                    8:    300 Series
                    9:    EU Digital Hybrid
                    10:    Mode 10 (possibly unused)
                    11:    Mode 11 (possibly unused)
                    12:    Mode 12 (possibly unused)
                    13:    NU Digital Hybrid
tuning        Tuning mode 

                    0:    100kHz
                    1:    25kHz
                    other:    25kHz (probably a side effect)
talkback    Talkback on/off

                    0:    Off (LMb seems to ignore)

 

<0x18> is a start code - actually it is the ASCII "cancel" character, so it probably means to cancel any previous transmission and begin handling a new one.
<CC> is a checksum, in ASCII hex, representing the two's complement of the sum of character values in the string.  It does not include the initial start character <0x18>, the '#' character, the checksum itself, or the terminating <CR>.
<CR> is ASCII carriage return (0x0D)

 

Generally all parameters should be specified, although some combinations without all parameters may (at least partially) work.

<irblk><channel><compat> works; combinations missing any of these generally fail to provide the expected result and usually generate an error message.

 

I have reason to believe that in at least some models, any command that is permissible via USB would be accepted via IR.  The only IR capable transmitters to which I have access are the LMb and HMa transmitters.  I didn't find any additional commands for the LMb, and I don't have any notes either way about the HMa.

 

All experience I have with the IR format is unidirectional (RX->TX) but something I read in a spec of some newer device made me think that newer devices may have bidirectional capability.

Edited August 30, 2022 by Matthew Steel
Formatting