Controlling 3D IR shutter glasses

[zkidz]

Some time ago I decided to try out the 3D feature on my TV set. I bought the cheapest "universal" IR shutter glasses I could find and was astounded at the horribly mistuned sync. Apparently 240Hz LCD 3D TVs occupy a no-man's land between the horrors of 120Hz LCD 3D TVs and the nirvana of DLPs, because the glasses had no pre-programmed mode that even approached being tuned optimally for my set. I'll spare you all most of the details.

So after more reading up on this supposedly-consumer-ready technology than any human should ever endure, I decided I was going to wait to see whether the newer XPand X104s coming out soon would displace the only solution currently on the market (rebranded BitCauldron-based TTL/IR-to-RF kit) that allows manual tuning of lens phase and duty cycle. Certainly I'm not going to pay the vig to the TV set manufacturer for their overpriced glasses that probably aren't tuned quite right either, since there's a trade-off between ghosting and other artifacts which is really a matter of taste.

In the meantime I managed to hack a PC together to transcribe from my TV set's IR protocol to another IR protocol on the universal glasses which had a more appropriate duty cycle for my set. Not perfect but a huge improvement. Then I was about to build a circuit to do it so I didn't have to run an entire laptop for that purpise, when it occurred to me, you know, a learning universal remote has all the necessary hardware (well, minus the light pipe to direct the original IR signal without letting it bleed out to the room.) Some more googling and I found you guys.

So for a while at least, I'll be attempting to build, essentially, an IR-to-IR version of the BC-100 emitter system out of a JP-1 remote.

Right now I'm just past the point of having built a functioning cable and am now ramping up on the tech details (and trying to figure out how to avoid Excel in the process since I'm a linux-only shop here at home

I'll ask my n00b questions elsewhere in the forums. This post is mainly to gather comments and first impressions on this prospect from experienced JP1 folks as to the feasibility (and also for any end-users to express interest in the idea.) Some of my unknowns so far:

1) For TTL level wired (Vesa Stereo) input, what the best route is... can a JP-1 pin be used/detected by an extender, or would a button have to be hacked, and if the latter, what the obstacles might be there timing-wise, e.g. unavoidable built-in pauses.

2) I imagine it is possible to figure out how to use the learning photodetector from an extender. I imagine that would be a model-specific or at the very least a CPU-specific routine. How many variations would we be talking about here, whether they would map to the probed remote ID, and how one goes about packaging that mess up neatly.

3) How long a run of the mill JP-1 remote would be likely to last on batteries while operating constantly, sending pulses up to 120 times per second (lower total duty cycle than normal control codes, however) and with the learning circuit maybe turned on. Also whether the hardware is durable enough for that.

Full disclosure, I'm probably not going to stick this out much past making myself a working proof-of-concept, and then I will get distracted and go back to booting linux on deskjets or some other endeavor. However, if I'm going to do it I figured I might as well do it out here in the open where anyone else interested could leverage whatever progress I make. So despite being tempted to just tear open jp12serial/RMIR enough to let me nuke the entire "OS" on the remote and install a simple custom event loop, I'll try to stick to doing things other people might be able to use.

And while I'm at it I'll be happy to apply what I now (unfortunately) know about IR shutter glasses signals to seeing if there isn't a way to map different brands of 3D IR sync signals and the necessary Pause extenders into a coherent set of protocols so such an application would fit into the current suite of JP-1 software elegantly, allowing one to download one protocol/device into the remote and reconfigure it for particular glasses/set combinations with macros/keymoves.

Thoughts? Advice? Laughter even?

[The Robman]

Sounds like an interesting project.

You won't need to use Excel as you can use RM instead, which is a Java based version of the KM Excel spreadsheet/program.

As for the batteries question, why not hack a DC adapter with the right voltage onto the battery terminals so you won't need batteries.

[zkidz]

You won't need to use Excel as you can use RM instead, which is a Java based version of the KM Excel spreadsheet/program.

That's what I'm trying to suss out right now -- how to go about building a new protocol. It seems none of the menus that help with this are active until you import something from "Protocol Builder" or whatnot, so perhaps I should just find a random protocol and try to import it. Or maybe I'm just missing the presence of an RM major mode -- RM doesn't look any different to me with or without the -ir flag.

As for the batteries question, why not hack a DC adapter with the right voltage onto the battery terminals so you won't need batteries.

Always an option, of course, but I'm just thinking about people who might hate wires. Then again there's going to be a fiber from the builtin emitter anyway, so a USB parasite cable from the TV might not be the worst thing in the world. Also for those using Vesa Stereo there might possibly be enough amps on that wire to run the remote.

[The Robman]

That's what I'm trying to suss out right now -- how to go about building a new protocol. It seems none of the menus that help with this are active until you import something from "Protocol Builder" or whatnot, so perhaps I should just find a random protocol and try to import it. Or maybe I'm just missing the presence of an RM major mode -- RM doesn't look any different to me with or without the -ir flag.

If you need a new protocol then you would need to use PB which is Excel based (though there is some development underway to add that ability to RM too, but it's not there yet).

So, if you do need a new protocol, tell us what you need and we'll make it for you.

As for RM, it currently defaults to RMIR (ie, with the -ir flag), so to get it back to the regular RM you need to use the -rm flag.

[Barf]

zkidz, do you have any type of documentation of the "protocol" you're are trying to manipulate? Or have you made any serious investigation yourself? (You may find the "IRWidget" and its software "IRScope" useful.)

As far as I understand it, the IR signal controlling a pair of shutters is about as different from a consumer IR signal as it gets: the control signal is (basically) active all of the time, and has (naively thinking) four states: left on/off, right on/off; possibly the transients are transmitted instead. The signal may be modulated (as in consumer electronics) or not. The timing requirements are tight. On the other hand, in a consumer electronics (CE) remote, such as a JP1 thingy, IR signals are sent relatively seldom, and contains a large "tail" of "silence" (50-100ms). From the hardware side, the current through the IR transmitting diode(s) is for a short time rather high (in the Ampere range), which does not harm the drivers, since it is sent for such short times. If you try (e.g. with firmware hacks) to have a CE remote send continuously, you will probably burn the electronics, not being designed for that case. Furthermore, a "protocol" in the sense Rob talks about, is really a relatively complex mapping from a few parameters (from a few bits to over 50) to a finite IR-signal, packaging these bits in a robust packing. Even if it contains a repeating part, it consists mainly of pauses. It is not designed to be able to deliver its results within a specific time period, making it probably useless for synchronizing IR shutters.

So, both the JP1/UEC software and hardware is probably useless for your endeavor..

[zkidz]

zkidz, do you have any type of documentation of the "protocol" your are trying to manipulate? Or have you made any serious investigation yourself?

Yes, and yes. Many of the protocols are documented in this survey:
http://cmst.curtin.edu.au/local/docs/pu ... ync-IR.pdf

As far as I understand it, the IR signal controlling a pair of shutters is about as different from a consumer IR signal as it gets: the control signal is (basically) active all of the time

That is only the case in TTL (non-IR) Vesa Stereo format. The rest of the protocols just send tokens when a state change is requested. There may be a few that send the tokens multiple times, but even in those cases, most of the shutter glasses are very simple circuits with high tolerances and are only looking for the initial pulses (sometimes not even very picky about the pattern, other than to tell the eye commands apart.) The shutter glasses basically have a free-running internal clock and they are expecting to miss a token here or there, so they are just syncing the internal clock to the pulses when they can.

The tokens usually contain essentially clocked bit patterns with a one represented by a single 50% duty cycle pulse and a zero by no pulse. That would be easily representable by a byte value or two. Some contain three or four on pulses of the diode with varying widths -- a little trickier but I believe the longest continuous diode-on duration is less than 200uS. Mainly this is because 3D TVs are as concerned about preserving the life of their overdriven LEDs as remotes are.

The fastest 3D shutter signal in existence will be the most useful one: a four token protocol that contains all four (left on, left off, right on, right off) state commands, which a 120Hz eye-frame frequency. That boils down to a stutter-stepped 240Hz frequency of tokens. The longest token I've seen documented so far is Sony's where one of the four is a total of 540uS (but the diode is mostly off even during the token.) So there will be an average cool-down time for the diode of about 3600uS between tokens in the worst case.

The timing requirements are tight.

This is my major concern. If the JP1 software is not down to the metal enough, it may leave mandatory delays inserted inside the manufacturer's XMitIR routine. Which was some of the point of my questions.

On the other hand, in a consumer electronics (CE) remote, such as a JP1 thingy, IR signals are sent relatively seldom, and contains a large "tail" of "silence" (50-100ms).

My hope is that the fact that the tokens are much shorter than the long bit strings used by remotes will (power-dissipation-wise) make up for the smaller interval between tokens.

Even if it contains a repeating part, it consists mainly of pauses. It is not designed to be able to deliver its results within a specific time period, making it probably useless for synchronizing IR shutters.

So, both the JP1/UEC software and hardware is probably useless for your endeavor..

Built-in pauses could kill the prospect of using the existing JP1 suite, because if I'm going to go further down to the metal than the JP1 suite does, the abstractions developed may fall apart, and the model-specificity of the software would increase. So yes, I am very interested in knowing where the internal software may insert pauses, especially if it is inside the XmitIR routine or if there is a built-in rate limit on keypress IRQs.

I'm sure in any case the JP1 codebase will be a huge help in doing this, so my thanks to everyone hacking away at it.

[Barf]

zkidz, thanx for the reference, it was very interesting. What it does is to identify a few very simple protocols, that are sent e.g. 240 times per second (with occasional lost signals permitted). Noticeable is that, at least according to the article (which does not make a completely reliable impression here), are not modulated with the typical carrier frequency (typically 35-40kHz). JP1-remotes can do non-modulated IR-signals, it is just not that common.

So again, what JP1s do good is relatively complex, modulated, protocols sent occasionally, with lax timing requirements. Here the requirements are almost completely complementary: simple protocol, sent a few hundred times per second (dropouts ok), timing requirements tight (possibly more "phase"-wise than absolute).

And, forgot to say that earlier, a JP1 with attached JP1-cable does not make up a programmable IR transmitter.

[zkidz]

Noticeable is that, at least according to the article (which does not make a completely reliable impression here), are not modulated with the typical carrier frequency (typically 35-40kHz).

That document leaves some details to be desired, for sure, but I've verified from real world samples that at least the Samsung 2010 protocol put out by my TV is identical to what they describe.

I note the carrier frequency can be adjusted, and do wonder what the limits around that are. Many of those protocols could be happily emulated as bit patterns if:

1) the frequency could be brought down into 25-30KHz range
2) the software is happy with bursts durations down in the 80uS range
3) the software triggers the burst on carrier rise or fall.

(which some of the things I'd appreciate answers for if anyone knows)

Aside, not listed in that document, the Sony protocol has a much longer activation token that turns the glasses on which is more similar to the more complex codes used in remotes. However, the Sony glasses themselves are pretty useless for cross-platform use, what with not having front polarizers, and most other brands have the user manually activate the glasses.

The electronics in most shutter glasses are fairly cheap with a wide reception band filter just looking for a vibration. On my pair there's an analog adaptive filter circuit that is hooked to the Holtek CPU by one signal wire, and from the behavior I've seen that analog circuit is simply sending one logic level in when it oscillates, and a different logic level in when the oscillation dies. The Holtek is (guessing here) programmed to look for the edges on that signal within a certain tolerance range.

I've successfully driven the universal pair I have here with pulse widths/periods somewhat shorter/wider than the protocols they are supposedly tracking. It's not necessary to get a perfect emulation of the protocol, just something that will trigger the glasses. The most challenging part is making sure the four-token protocols don't trigger across tokens, but a lot of third-party glasses really aren't parsing these tokens too strictly, just using heuristics to figure out where the eyes are and running on a PLL timer.

You'll note some of the protocols only send out tokens per eye-pair of multiple of eye-pairs and let the glasses generate pulses from there. The "fix" I found for my glasses/set actually uses one of these -- it takes the 4-frame (8-eye) Samsung signal and generates a 1-frame (2-eye) signal. The reason it fixes my 3D is it just so happens that in that mode, the glasses are pre-programmed for a lower duty cycle than they are in the mode that accepts the Samsung signal. That and I'm free to spin the phase around.

So again, what JP1s do good is relatively complex, modulated, protocols sent occasionally, with lax timing requirements. Here the requirements are almost completely complementary: simple protocol, sent a few hundred times per second (dropouts ok), timing requirements tight (possibly more "phase"-wise than absolute).

And, forgot to say that earlier, a JP1 with attached JP1-cable does not make up a programmable IR transmitter.

...well, unless you hijack the OS entirely. I'm pretty confident I could do that, what I'm mainly trying to determine is whether it's necessary, because if I could manage to wedge these signals into the JP1 paradigm, that would be more useful to an active hacking community than a single-model hack that requires one to be an adept assembly programmer to modify.

[Barf]

Noticeable is that, at least according to the article (which does not make a completely reliable impression here), are not modulated with the typical carrier frequency (typically 35-40kHz).

That document leaves some details to be desired, for sure, but I've verified from real world samples that at least the Samsung 2010 protocol put out by my TV is identical to what they describe.

What I am criticizing the article for, is that the described IR protocols neither has a particular modulation frequency, nor it has "no modulation". (I searched for the word "modulation", with no hits.) So what do they describe, really?

It is not unlikely, in particular in the view of the claimed robustness properties, that a receiver designed for a non-modulated protocol under some circumstances can accept a modulated signal.

...well, unless you hijack the OS entirely. I'm pretty confident I could do that, what I'm mainly trying to determine is whether it's necessary, because if I could manage to wedge these signals into the JP1 paradigm, that would be more useful to an active hacking community than a single-model hack that requires one to be an adept assembly programmer to modify.

Fine. Never wanted to scare you away. But might like to check out the catalog of output devices from LIRC, for example.

[zkidz]

Never wanted to scare you away. But might like to check out the catalog of output devices from LIRC, for example.

I don't scare so no worries. Problem with using PC devices, other than having the junker laptop cluttering the living room, is that OSes just are not up to the latency requirements. To get reliable timings I either have to boot an RT-linux kernel, or crash a kernel into a busy loop, and anything that uses USB is just plain out (unless there's an isocronous mode one out there.) So if this JP-1 stuff doesn't work out I'll just be heading back to wiring up salvaged CMOS to do the job.

[zkidz]

I wanted to update folks on this. So far it looks feasable. I've successfully managed to send a self-clocked sync signal to glasses, and also I've figured out how to check the state of the JP-1 pin 4 normally used for serial Rx and verified to the best of my ability that the software's internal use of this pin is clean enough to work around (and that pin should be up to the task, given it has the T0CAP/IRQ1 capability.)

That pin is where I'm figuring to attach either VesaStereo cables or a pulldown phototransistor. So no cracking the case required for a usable electrical connection, and because of that, screw the idea of a light-pipe-to-learning-sensor. Besides, scavanging a PT out of an old ball mouse or inkjet is cheaper than buying an optical audio cable anyway.

I'll be reworking the sync signal generation to use lower level primitives from the block of what appear to be ABI syscalls (what are called just "vectors" in the JP-1 parlance.) I think the output portion of the code can be implemented using these, but will have to rely on knowledge of which timer/IRQ systems they use and how, so maybe that part will turn out to be model neutral, (i.e. easily translatable between assembly codes) maybe not.

There is a subroutine for sensing the Rx pin state, but it is not in the "vector" block. So that part will have more chance of requiring model specific code. (Incidentally I notice each of the syscall vectors does a double jump through a secondary table in the 0x05XX address area, which has more "vectors" in it than in the primary syscall table. JOOC anyone know how stable those 0x5XX addresses are between models?)

To wit, I'm interested to know which pin S3F8/SC38 learning remotes use as the input from the learning circuit, suspecting P3.0 is double used for the serial Rx and for this purpose. The remote I have (not learning) is a 42/44 pin retrofitted onto a PCB that was
originally layed out for the 32-pin chip, and they seem to (can't see under the waterproofing) have taken great pains to jump the JP-1 pin 4 connection over the rest of the lines to get them down to P3.0, even though P4 has pins right where they need to be and those would be suitable for serial Rx. We could chalk that up to just not wanting to rewrite/test the code, or it might be a conscious effort to keep pin compatibility. Either way, that's a promising sign thatI might be able to come up with machine code that works across the majority of the S3F8/S3C8 family.

On the UI side it appears RM's protocol.ini file is quite nicely flexible. I'll be needing to play with it a bit first but when I'm happy I know what it can/can't do, I'll post a first draft of how this would look to any interested users from the point of installation and operation, so people can offer suggestions. If I don't get too sidetracked playing Wipeout HD when I get my first working model, that is

P.S. I noticed in the published list of vectors there are some comments like "another delay function?" Comparing a few of them, the difference between delay functions seem to be which hardware resources they use, whether the system is busy looping or in a power saving mode, and whether or not they feed watchdogs while they are waiting.

[The Robman]

For anyone who's been skimming over the long jargon-heavy posts here, without any real understanding of what's being discussed, here's a quick summary of what I've figured out.

"IR Shutter Glasses" are used with 3D televisions. Unlike the crappy red/green 3D glasses of the past, the way these glasses work is they have glass that can switch between blocking everything or blocking nothing and the glasses alternate between having the right eye blocked or having the left eye blocked.

The 3D TV will display an image intended for the left eye while the right eye glass is blocked, and then it will display an image intended for the right eye while the left eye glass is blocked. Obviously, this needs to happen really fast (ie, the refresh rate) in order for the eye not to detect what's going on, otherwise you'll see a flicker. Also, the glasses and the TV need to be completely in sync for the process to work.

The original shutter glasses would only work with the specific model of TV that they were designed for. Now there are universal glasses that claim to work with all (or most) 3D TVs.

IIUC, the TV emits an IR signal, that is picked up by the glasses, that controls when the glasses are in left-eye or right-eye mode and how fast it switches from one mode to the other.

But, I have no understanding of what sort of hack zkidz is trying to here, or how a JP1 remote will be used for it.

Here is a wikipedia article on the glasses themselves:
http://en.wikipedia.org/wiki/Liquid_cry ... er_glasses

And here's an article on universal glasses:
http://www.pcworld.com/article/191682/x ... plays.html

[zkidz]

I'm happy to report playing my first few rounds of WipeOut HD using a JP1 remote as an IR-to-IR protocol translator. So, proof of concept accomplished.

The easiest way to think of this little hack is to look at the MonsterVison Max 3D emitter product (which is just a rebranded BitCauldron product.) This would do the same thing, but the hacked remote uses IR to drive just about any pair of glasses (or set of glasses of the same model), instead of using RF to drive only the kind of glasses sold with the unit. Also, at way less expense.

FWIW, here are a few of the situations where you would want to do this:

1) You have a TV set with a built-in IR emitter that uses brand X's protocol. A truck rolls by and off fall a bunch of glasses made for brand Y TV's where Y != Sony. Or you just bought the wrong thing on E-bay and can't return it.

2) You have an old generation DLP TV and a 3D receiver that puts out a Vesa Stereo signal using a cable, and you have a friend over who brought IR glasses instead of DLP-link glasses.

3) You have a pair of glasses that *fully* support Brand X protocol, brand X's protocol is a 4-token protocol, your TV's protocol is not a 4-token protocol and/or your TV does not have the option to tune the glasses. This lets you tune the glasses to your taste. Some people would prefer a brighter image, some people really hate ghosting, etc.

Looking forward, this hack might or might not have a future beyond supporting 3D hardware sold after next year or so. IR glasses are going RF, and the way they are going RF is, of course, going to vary between manufacturers. Overall It's a good thing, because IR glasses really do interfere with IR remotes quite a bit. However there will be a mix of ZigBee, BlueTooth, and Proprietary RF protocols. It's possible a few of these might work with an RF remote control.

Now, on to find the "read a button" functions so I can hand tune...

[The Robman]

Could you do a write-up of what you did so that somebody else who might need this knows what's possible?

Do you have the remote hooked up to something that triggers it to send a signal? If so, could you describe the hook up.

Did you have to create a new custom executor in order for the remote to send the right signals?

[zkidz]

Could you do a write-up of what you did so that somebody else who might need this knows what's possible?

Yep. I'll do more than that. After I'm done with some playing I'll post a proposed set of RM parameters/translates and describe a proposed interface for what buttons do on the remote when using the "protocol".

Do you have the remote hooked up to something that triggers it to send a signal? If so, could you describe the hook up.

Yes, via software, I place pin 4 of the JP-1 connector into pull-up input mode (this is port 3.0 on the S3F80 42/44 pin package) and then merely connect a phototransistor (which you can scavange from any pre-optical mouse or various other electronics) between pins 4 and 3 (ground). Then I taped the phototransistor over the TV's emitter with opaque tape so that it gets a reliable signal.

I don't have a Vesa-Stereo out on my TV, but for those that do, it is a TTL level signal IIRC so it should be easy to hook up similarly. Plus it might be possible to power the remote off of that, we'll see.

Did you have to create a new custom executor in order for the remote to send the right signals?

Yes, I wrote an executor/protocol which enters an endless loop when you press a button and waits for an edge on the P3.0 pin (JP-1 pin 4), then runs vectors 16D and 14C to generate the signal/delays, then goes back to waiting for an edge. Since those vectors use the timers and the IDLE instruction, the remote is in IDLE mode most of the time. (And I think I can get the T0CAP hardware feature to do this as well when it is waiting for P3.0 edges) so it should be easy on the batteries as well.

P.S. I'm calling dibs on protocol ID # 01 3D