Hello - I've just found out about Arduino, and I think it may be perfect for a project I've been wanting to create for quite some time. However, I'd just like to make sure that it is possible before I buy one and learn all the ins and outs (it sounds fascinating!), hence this post. XD
I have an LCD shutter that I want to blink on and off 25 times a second. For it to be "on", 3v or above (not specific) must be applied to the shutter. For it to turn off, however, both terminals of the shutter must be shorted, otherwise the shutter slowly fades into transparent (it needs to be instant).
Because it would need to be synced with something else, it would be handy to have some kind of knob or button to adjust the timing (though not the hz rate) until it comes into alignment (visually) with what I'm trying to sync it to (which is entirely independent and there are no modifications I can make to allow it to "talk" to Arduino to let it know the timing).
So, are both of these things possible to do with Arduino? I'd be quite happy with the former being possible, but for the latter to also be possible would be fantastic!
Grumpy_Mike:
Yes all these are non demanding tasks for a processor of this power (which is not too great in modern terms).
Great! Do you think that it would be a reasonable first project for a novice like me? I know zilch about programming. Would much additional circuitry be required, other than Arduino itself? I mean, would I be able to pretty much just attach my LCD shutter's positive and negative terminals to Arduino without much in-between?
Well I would start with a few of the examples in the tutorial section of this site first so you get the hang of things.
Would much additional circuitry be required, other than Arduino itself?
It depends on what your LCD needs in terms of voltage, at best you can connect them directly, at worst you will need a transistor and maybe another power supply.
Get a meter and measure what the voltage between you LCD leads before they are shorted together.
What are you trying to sync the LCD shutter to? There might be a non-invasive way to do it. Is it exactly 25Hz, and if so, what timing reference does it use?
No matter how accurate and stable the 25Hz is, it's likely that you will need a small amount of frequency adjustment, because the Arduino clock is only accurate to within 0.5%. Rather than use a potentiometer to adjust the phase (i.e. timing), it might be better to use a rotary encoder, so that you don't hit end stops if you keep adjusting it in the same direction.
If it is a passive device (i.e. no separate power supply) needing 3v DC or above to turn on but can tolerate 5v, then you should be able to drive it direct from an Arduino pin. A series resistor of 100 to 220 ohms would be a good idea in case it has appreciable capacitance. A logic low on the pin will short the display (through the resistor, which is unlikely to slow it down appreciably).
which is entirely independent and there are no modifications I can make to allow it to "talk" to Arduino to let it know the timing).
My concern would be keeping it in-sync.
How long does it have to stay sycnhronized? For example, if you are talking about PAL video (25 frames per second), I suspect that the timing will drift off by more than 1/25th of a second during a 90 minute movie.
it would be handy to have some kind of knob or button to adjust the timing (though not the hz rate) until it comes into alignment (visually)
Probably a button. It would be best to avoid anything "analog" like a knob/pot. You can simply pull-up or pull-down an Arduino input to read the state of the button.
Maybe you push the button and the timing changes to something like 25.01 Hz 'till everything comes into sync, and then you release the button. Or, every time you push the button it adds (or subtracts) a couple of milliseconds to a single pulse, to "shift" the timing.
If we are talking about a shutter on LCD glasses, they will need synchronising with the frame fly back signal of the monitor. You can't just set it going and it remains in sync.
That sort of thing is what you get for only asking what you think the solution to a problem is, not what the real problem actually is.
I would actually go with an analogue knob to provide the phase adjustment between sync pulse and shutter. Having said that I have made several 3D shutter systems like that and I have not had to make that adjustment at all. The trick is getting the phase correct, that is sending the right signal to the correct eye. Unless the computer outputs something you will have to just use a switch to flip it over to get it right.
In fact there is no need to use an arduino at all, it can all be done with simple electronic circuits, there is nothing for the arduino to do.
Thanks very much everyone for the input - very interesting! Definitely food for thought.
dc42:
What are you trying to sync the LCD shutter to? There might be a non-invasive way to do it. Is it exactly 25Hz, and if so, what timing reference does it use?
DVDdoug:
My concern would be keeping it in-sync.
How long does it have to stay sycnhronized? For example, if you are talking about PAL video (25 frames per second), I suspect that the timing will drift off by more than 1/25th of a second during a 90 minute movie.
I'm syncing the LCD shutter to PAL camcorder. I can understand it drifting, but thankfully it only needs to be in sync for a few minutes at most. My project idea is fairly simple - block the light to the lens every other frame.
In fact there is no need to use an arduino at all, it can all be done with simple electronic circuits, there is nothing for the arduino to do.
Hmm, worth considering actually. Would it be possible to get tighter timings with a dedicated circuit, so that drift would be minimal?
It seems to me that you need your shutters synched to the source frames. You may find that your shutter timer and the source are both consistent enough that you can preset the frequency and they'll simply stay in sync, but personally I'm not optimistic about that. You really would be better off triggering your shutter from the PAL stream, which I think is what Grumpy_Mike was suggesting.
You may find that your shutter timer and the source are both consistent enough that you can preset the frequency and they'll simply stay in sync, but personally I'm not optimistic about that.
Well you are a bit more optimistic than me, personally I would say there is no chance of them staying in sync.
Trouble is that young people do not remember the problems TVs had locking to a frame sync pulse. You could adjust the frame oscillator but without the sync signals there is no way that the frame would not roll. All the adjustment in the world would not keep it stable for longer than a second or two. This was the problem on the old 405 line TVs with positive modulation. This meant that the sync pulses were send with the lowest RF power, hence in marginal signal areas the picture would roll due to a lack of sync pulse to lock to.
Two free running oscillators no matter how stable can not be synchronise. That is why we invented phase locked loops.
The preliminary experiment that I did to see whether this idea had a hope of working was to make a video clip running at 50fps with every other frame black (the others white). I played it back on my LCD computer monitor (running at 50Hz), with the camcorder recording it. The camcorder was running at 50i (50fps) and sure enough every other frame was black, and the other white with absolutely no phase shift that I could see (though I only recorded about two minutes). I think I still have the clips somewhere.
The only problem was that I had to randomly turn the camcorder on and off until it was in sync with the monitor (if it wasn't in sync it could potentially (and infact did on occasion) look completely gray with no flashing at all).
This lead me to believe that I merely had to make a 25hz oscillator (I've tried it with 50hz oscillation just to see what would happen - but it's simply in sync with the camcorder and looks solid), with some method to fractionally adjust the timing. I heard about Arduino and thought that it would be perfect, and indeed it seems like it will be worth a shot as the general consensus is that it is indeed possible to do with Arduino (and is in fact a bit to easy, hehe!).
So, I think I'll give it a go. Who knows, maybe it'll just work like the monitor did.
Edit: actually, here's a thought... I've got a 9V adapter that outputs AC rather than DC. Because mains is 50hz, couldn't I just connect my LCD shutter up to it and get 25hz oscillation due to the polarity change and LCDs being dependent on the correct polarity?
TheGuy92:
Edit: actually, here's a thought... I've got a 9V adapter that outputs AC rather than DC. Because mains is 50hz, couldn't I just connect my LCD shutter up to it and get 25hz oscillation due to the polarity change and LCDs being dependent on the correct polarity?
I think you are ignoring the underlying problem.
It doesn't matter what source you use for your nominal 50Hz. Unless the PAL stream and your shutter are driven by the same timing source, they will not stay in phase. You don't imagine that your PAL source is synchronised with the mains, do you?
PeterH:
I think you are ignoring the underlying problem.
It doesn't matter what source you use for your nominal 50Hz. Unless the PAL stream and your shutter are driven by the same timing source, they will not stay in phase. You don't imagine that your PAL source is synchronised with the mains, do you?
Of course not! I was merely wondering whether hz rate would be correct. It doesn't have to stay in phase for too long (a minute or two). I've had good experiences with the monitor test that I mentioned above (which was an entirely separate devices, and yet resulted in absolutely no phase shift problems). XD
Stability of the Arduino clock over a minute or two should be better than 0.1%, which at 25Hz is one cycle in 40 seconds. Maybe if the temperature and supply voltage are stable it will be OK over a couple of minutes. You will definitely need to be able to adjust the frequency as well as the phase, otherwise the frequency could be as much as 0.5% out which is 1 cycle in 8 seconds.
I don't know how LCD TVs work, so this is largely speculation. But I think they must work fundamentally the same as an LCD computer screen, and I know a little about how they work.
On a CRT TV the screen would be drawn pixel by pixel and line by line as the signal arrives, and any slip between the shutter and the signal would result in the top or bottom of the screen being out of phase and 'chopped off'. So with this old school analogue solution there's no tolerance at all.
But LCD TVs may be different. I think they have a frame buffer and perhaps even with an analogue signal there's more buffering going on than with a CRT. That might mean the screen is updated frame by frame rather than pixel by pixel as the signal is received.
If so it would be much more tolerant of phase shifts between the signal and your shutter, and would tend to jump by half a cycle at a time (i.e. reversing the even/odd frames). I suppose that might be workable over a short time. You really need somebody like Grumpy_Mike to tell you whether that makes any sense though - it could be complete hogwash.
But also in that case, if the shutters are being used to filter the output of an LCD screen the idea of taking alternate half-frames might not make much sense, since the LCD screen would show the whole frame at all times rather than showing alternate lines.
No essentially it is right but it is a bit more complex with a lot of ifs.
This site has a good explanation
see the bit where it says refresh rate.
I must admit my 3D shutter experiments have always been with CRT monitors, which tells you more about how long ago I did them than anything else. However, I did read that the early LCD monitors would not work with shutter glasses, they might be better now I will have to try some experiments.
I was merely wondering whether hz rate would be correct. It doesn't have to stay in phase for too long (a minute or two). I've had good experiences with the monitor test that I mentioned above (which was an entirely separate devices, and yet resulted in absolutely no phase shift problems). XD