Trantec radio microphones

[cedd]

Hi everyone
Bit of a different use for IR here.
I'm a theatre sound engineer and own 24 Trantec S5.3 and S5.5 wireless microphones. They have a neat feature where you can get the receiver unit to lock the beltpack transmitter worn by the actor so they can't fiddle with any of the buttons. This locking is done by infrared. I got frustrated having to hold 24 of the things in front of the receivers (which are often stashed under the stage in a pretty inaccessible location) so ages ago I bought myself a sunwave learning remote and taught it the IR codes for lock and unlock.
There's a slight quirk to this though. I own 24 of them, but there are 3 different variants among them depending on their operating frequency (of the RF audio transmission side of things - nothing to do with the infrared). 12 of what we'll call variant 1 (606-614MHz S5.3 model if you're interested), 4 of variant 2 (863-865MHz S5.3 model) and 8 of variant 3 (863-865MHz S5.5 - the posher model with a few more features). Each variant of beltpack requires its' own variant receiver to lock or unlock it, so I always assumed they just had a different IR code for each variant (why they'd do that, i've no idea!).

Anyway, the remote is getting past its' best and I can't find a replacement (bought a few others from ebay and for whatever reason they just won't learn the code successfully) so I thought i'd come up with a more elegant solution. As i've had to teach the remote all 3 pairs of lock/unlock codes for the 3 variants of mics (so, 6 buttons, 3 lock, 3 unlock) I thought it'd be more elegant to use an arduino and just send all 3 lock commands one after the other when a lock button was pressed, and all 3 unlock codes when the unlock button was pressed. 2 buttons to lock and unlock everything - simple, right?

I've got the IR receive code running on my arduino and here is the code I receive (for reference, this is the learning remote that i've been using - doing this at work and bringing the rack of receivers in with me is going to take some explaining! I can try it later with the actual receivers themselves, but the remote functions correctly so I can only assume its' codes are correct and identical to what the receiver is putting out when it sends the commands).

Lock;
732B064A
2FF45DCA
FEAC02E5

Unlock;
732B064A
F40E874F
FEAC02E5

What's really odd is, I get the same codes no matter which variant lock or unlock button I press - the code sent is identical. Bang goes my theory of each variant using different code! Those above codes are exactly as they are printed, including the carriage returns.

Anybody got any clues as to what's going on, or what the difference could be between the variants to make them all only respond to their corresponding variant receiver only? My one and only theory is they're each using a different IR frequency, maybe clocked or referenced from somewhere in the RF circuitry - hence it's different for the different frequency bands. Can't see it being likely though when internally clocked transmitters and receivers are so widely available.

I haven't tried sending the above code yet as I haven't really worked out how to put it in to the IRSendRawDemo sketch to make it work (especially with the carriage returns - i'm guessing I need to send them if the receive code prints them in serial monitor?).

IR isn't my thing - RF is! I'm therefore stabbing in the dark a little bit here. Any help would me much appreciated!

Thanks a lot.
Chris

[AnalysIR]

Hi Chris

An unusual use case indeed.

Irremote can confuse things with non-standard signals...sometimes. For example if it cannot match the signal it will try to provide a number, regardless of what the protocol is. However, the max number is 32 bits & if your signal has more than 32 bits the info is essentially bad or suspect or partial. There could be other causes too.

If you post the raw signals you get using the sendRaw demo of IRremote, I will have a look at them.

Other comments:
Its unlikely to be different carrier frequencies.
Make sure to leave a good gap between sending the signals when testing, as receivers can get confused if you send multiple signals without a gap.For your use case leave a couple of seconds between each signal you send using:

Code: Select all

delay(2000)

[cedd]

Brilliant, thank you so much for the offer to take a look.

The mics went out on hire this morning (I was seizing a quick opportunity while I had them home) so it'll be 3 or 4 days before I get them back and can properly play again. Have loaded IRrecvDumpV2 on to my arduino in readiness - i'm assuming that's what you meant instead of the sendRaw sketch, as that one doesn't have and serial printing as part of it? I've just tried IRrecvDumpV2 with a tv remote i've got here and it appears to spit out all sorts of data including the raw data, so i'm guessing i've got the right one.

Will post my findings once i've got them back.

Cheers
Chris

[AnalysIR]

Yes of course the receive example is what I meant

[cedd]

Right, managed to get at least a little more information.

I haven't got all of the systems back from hire, but I have a single receiver sat at home as a spare. This is the variant 1 I mention above.

Got the following out of it;

Lock;
Encoding : UNKNOWN
Code : 732B064A (32 bits)
Timing[9]:
+1650, - 800 +5000, -1600 +1700, - 750 +3350, - 800
+ 850
unsigned int rawData[9] = {1650,800, 5000,1600, 1700,750, 3350,800, 850}; // UNKNOWN 732B064A

Unlock;
Encoding : UNKNOWN
Code : 732B064A (32 bits)
Timing[9]:
+1650, - 800 +5000, -1600 +1650, - 850 +3300, - 800
+ 850
unsigned int rawData[9] = {1650,800, 5000,1600, 1650,850, 3300,800, 850}; // UNKNOWN 732B064A

So there are some differences in the timing section, and in the raw data, but the code that is derived appears to be the same for both - which maybe fits your theory.

I'll post the codes for the other 2 variants as and when I can get hold of them but thought this might give you something to be working on at least for the time being.
If I put that raw code in to the IRsendRawDemo sketch just as it is, would you expect the mic to lock and unlock as it should, or is it not that simple?

Cheers
Chris

[AnalysIR]

Yes, sending these values with sendRaw should work fine.

You could also try to capture using the following sketch which is more accurate: (IRremote provides +/-50uSecs by default)
https://www.analysir.com/blog/2014/03/1 ... s-arduino/
and repost the timings

Comments:
- both signals do indeed look identical & with the sketch above you will get more accuracy.
- regardless, all ir receivers can distort the timings by up to +/- 200uSecs
- If I were to guess, it looks like a serial signal sent over IR using 1200BAUD (Or individual time units of 833.33 uSecs
- This is not an issue, as using RAW signals you can reproduce easily enough.
- I saw online that some people think it may be an IRDA type signal, which also suggests serial.

So the next step is to post the timings from the sketch above.

[cedd]

Right, i've finally got the full set of raw timings from these things. Sourced from the sketch you suggested. Here we go;

Variant 1 lock;
Raw: (29) 1692, -800, 4972, -1640, 1692, -796, 3356, -772, 864, -13256, 840, -1648, 4992, -1620, 872, -2436, 4172, -1620, 868, -2468, 2512, -768, 868, -13232, 872, -2436, 2512, -796, 840,

Variant 1 unlock;
Raw: (27) 1656, -796, 5024, -1608, 1684, -796, 3304, -828, 840, -13252, 7496, -1612, 844, -2476, 4152, -1636, 836, -2456, 2524, -792, 836, -13240, 840, -2480, 2500, -792, 864,

Variant 2 lock;
Raw: (29) 868, -768, 5840, -1636, 1676, -800, 3332, -796, 872, -13220, 864, -1640, 5000, -1604, 868, -2452, 4176, -1640, 868, -2424, 2524, -792, 864, -13252, 836, -2456, 2524, -792, 864,

Variant 2 unlock;
Raw: (27) 844, -796, 5844, -1612, 1688, -776, 3348, -800, 868, -13228, 7476, -1616, 868, -2440, 4168, -1648, 868, -2440, 2512, -792, 872, -13196, 860, -2448, 2504, -800, 836,

Variant 3 lock;
Raw: (29) 868, -1644, 5008, -1644, 1684, -824, 3348, -800, 868, -1640, 864, -1620, 5040, -1612, 864, -2492, 4172, -1636, 872, -2456, 2536, -792, 868, -1640, 860, -2468, 2532, -796, 864,

Variant 3 unlock;
Raw: (29) 304, -23476, 868, -1644, 5008, -1644, 1684, -800, 3352, -820, 860, -1624, 7516, -1648, 864, -2460, 4200, -1636, 840, -2488, 2504, -824, 868, -1616, 864, -2464, 2524, -800, 872,

[AnalysIR]

OK...they seem like much better captures.

I loaded them up into AnalysIR....
Variant 1&2
variant 1 seems identical to variant 3...however on closer inspection there seems to be 1 bit difference between both variants (the same difference on both lock & unlock), so its probably(could be) just an ID difference. However, the protocol is the same.
As i mentioned before it looks liek a serial protocol with a time unit of 833.33uSecs (So if yoy change all the timings in your signals to the nearest multiple of 833.33, you may get even better performance.

Variant 3
variant 3 is a different style/type & length of signal.
However, it is also based on a serial protocol with each bit length being 833.33 uSecs.
So the same applies as above.

833.33uSecs equates to a 1200 BAUD serial signal.

If you want ot investigate further, pick up a copy of AnalysIR & one of our IR modules from our store.
Alternatively, you can just use the captures above to replicate the signals with an arduino, using IRremote etc.

[cedd]

Brilliant, thank you so much for your time looking in to this. I'll be donating via your store.

Final question - I had some initial raw data and then went back and got more accurate timings, and there was a question mark over if the sketch had derived the code correctly. From what you've seen of the timings does that change anything in terms of the raw data I put in to the sketch? Do I just put the raw data that I found in my post on the 17th nov and it'll just work, or does the timing and what you've managed to discover from that mean i've got to put something else in there instead?

[AnalysIR]

The timings you had on the 17th will not work.

You need to use the timings from our sketch and use sendRAW with IRremote to send them.

If that does not work, then adjust the timings to multiples of 833 uSecs each.(They may actually work without this step)