It is currently Sun Jan 20, 2019 11:33 am



Reply to topic  [ 101 posts ]  Go to page Previous  1, 2, 3
 [DIY] Universal sutterglasses controller 
Author Message
One Eyed Hopeful

Joined: Tue Jan 11, 2011 6:45 am
Posts: 2
Reply with quote
excellent job!
little of-topics:
i like to know if is it possible to modify the ssg-2100 to reduce the time of single (open shutter) in order to reduce the crosstalk?
thanks


Last edited by zorro101 on Tue Jan 11, 2011 9:46 am, edited 1 time in total.



Tue Jan 11, 2011 6:52 am
Profile
One Eyed Hopeful

Joined: Tue Sep 28, 2010 5:28 am
Posts: 18
Reply with quote
Technically, yes. All that you need a programmer who writes for PIC.


Tue Jan 11, 2011 7:21 am
Profile
One Eyed Hopeful

Joined: Tue Jan 11, 2011 6:45 am
Posts: 2
Reply with quote
easy! :(
there is someone interested and good will?
thanks again


Tue Jan 11, 2011 9:45 am
Profile
Golden Eyed Wiseman! (or woman!)
User avatar

Joined: Tue Feb 12, 2008 5:22 am
Posts: 1515
Reply with quote
I have the old sammy plasma that uses the 3pin vesa and ssg1000 glasses or the elsa glasses im using now. Was considering buying an xforce kit to use but its not much of an upgrade because they still have the nasty little screens.

Will this emitter allow me to use modern samsung glasses?

_________________
"I did not chip in ten grand to seed a first investment round to build value for a Facebook acquisition."
Notch on the FaceDisgrace buyout.


Tue Jan 11, 2011 10:41 pm
Profile
One Eyed Hopeful

Joined: Tue Jan 11, 2011 4:09 am
Posts: 11
Reply with quote
Something far simpler could be built to drive glasses from a VESA 3-pin shutterglasses sync port, rather than using this Nvidia based solution (obviously, assuming you're not NEEDING to use it with a Nvidia based solution). I'm planning to build a minimal one just for driving some Samsung / Mitsubishi glasses to use with my DLP set.


Wed Jan 12, 2011 1:20 am
Profile
One Eyed Hopeful

Joined: Tue Jan 11, 2011 4:09 am
Posts: 11
Reply with quote
Mission Accomplished! Got a working IR emitter driving these Samsung glasses. Going to give it a proper "test drive" and watch some Shrek now. :)

Image

I'll clean up the code and put together some actual circuit schematics and such sometime in the next few days. It's really pretty simple.

I do plan to later build a "universal" style one based on the ATMega16 based one already in this thread, just modified to run off VESA shutterglasses interface instead of NVidia. This one is just a simple little ATTiny12 based device that only does the Samsung / Mitsubishi shutterglasses IR protocol.

Couldn't have done it without evgenln's solid documentation or the IR waveform!


Sat Jan 22, 2011 5:31 am
Profile
One Eyed Hopeful

Joined: Mon Jan 18, 2010 6:16 am
Posts: 31
Reply with quote
BioSehnsucht wrote:
Mission Accomplished! Got a working IR emitter driving these Samsung glasses. Going to give it a proper "test drive" and watch some Shrek now. :)

I'll clean up the code and put together some actual circuit schematics and such sometime in the next few days. It's really pretty simple.

I do plan to later build a "universal" style one based on the ATMega16 based one already in this thread, just modified to run off VESA shutterglasses interface instead of NVidia. This one is just a simple little ATTiny12 based device that only does the Samsung / Mitsubishi shutterglasses IR protocol.

Couldn't have done it without evgenln's solid documentation or the IR waveform!


Is the Emitter of Samsung the same as Mitsubishi's? Or have you builded a auto-swich between the different protocols?


Mon Jan 24, 2011 3:44 am
Profile WWW
Sharp Eyed Eagle!

Joined: Wed Jan 13, 2010 7:12 am
Posts: 436
Location: UK
Reply with quote
Hi,

Good solid build there, Petrus!

I'm still working out the best way of fitting my controller into the HDMI switch case. I've also bought some relays, so I can switch between two different HDMI inputs using the menu on the controller!

I will build the high-power IR LED (Golden Dragon) into a separate small housing connected via Cat5 cable. That way, the emitter can be put next to the projector to reflect off the screen (like XpanD etc. in the cinema).

I'm also improving the motors in my projection screen controller box so it will finally do vertical masking (black roller blind in front of screen). I recently had a bit of a brainwave with this setup, I'll keep you posted on this unless somebody guesses it first! ;)

Well done to BioSehnsucht too! Are those 940nm LEDs btw?

I also just got hold of Shrek 3D - nice to see more 3D content, even if most of the movies are CGI animations.

I still can't believe the SS protocol turned out to be so straightforward. This will make it easy to produce controllers similar to yours for VESA control of Samsung / Mitsu glasses. I'm not sure what the original pulse width for the SSG glasses is - if you try different values, you might see big improvements in the IR range?

btw, I've read more about the nVidia dongle hacking stuff - for people with nVidia GPU's, it looks like it will be fairly simple to build a super cheap "nVidia compatible" dongle which will work with other brands of wireless glasses (similar to what evgenln was working on).

@lish - As far as I've read, the Samsung glasses work with Mitsu 3DTV's, but the Left / Right eye shuttering is reversed. People have been testing this by wearing the glasses upside-down! It is simple to correct this problem using something like Petrus' or BioSehnsucht's controller. The only wireless glasses I currently own are Samsung, so I haven't tested any others yet.

I hope to have some photos of the setup on the weekend, as long as all the parts arrive.

OzOnE.


Mon Jan 24, 2011 7:09 pm
Profile
SD&A Co-Chair

Joined: Sat Dec 22, 2007 3:38 am
Posts: 57
Reply with quote
For those interested in understanding the differences and similarities between a wide selection of various Infrared 3D Sync protocols, we have just issued the following white paper:

"A Survey of 3D Sync IR Protocols"
http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf

Let us know what you think!

For your reference, we used Petrus' universal shutterglasses controller in part of the testing.


Thu Mar 31, 2011 9:26 pm
Profile
One Eyed Hopeful

Joined: Tue Jan 11, 2011 4:09 am
Posts: 11
Reply with quote
OzOnE2k10 wrote:
Well done to BioSehnsucht too! Are those 940nm LEDs btw?


I'm still (off and on when I feel like toying with it) trying to nail down the timing, somehow I missed your post way back when.

The LEDs are 880nm, SFH485 from Digikey. I'm not sure if 940 would work better in terms of sync distance / reliability, but I can generally get fine range it's just a matter of getting the timing right. They're going either a bit early or late and I've not quite gotten it going just right.

I've found the menu loop on Despicable Me to be perfect for testing the issue ...

Quote:
I still can't believe the SS protocol turned out to be so straightforward. This will make it easy to produce controllers similar to yours for VESA control of Samsung / Mitsu glasses. I'm not sure what the original pulse width for the SSG glasses is - if you try different values, you might see big improvements in the IR range?


After posting the info to AVSForum, someone used the basic IR info to duplicate the functionality (with apparent greater success) using a TI MSP430 Launchpad kit, which is fine if it works but more pricey than the AVRs (if buying the whole kit to do it... ). He never did get around to posting his code for the MSP430 either...

Quote:
@lish - As far as I've read, the Samsung glasses work with Mitsu 3DTV's, but the Left / Right eye shuttering is reversed. People have been testing this by wearing the glasses upside-down! It is simple to correct this problem using something like Petrus' or BioSehnsucht's controller. The only wireless glasses I currently own are Samsung, so I haven't tested any others yet.


L/R shuttering is identical for Mitsu and Samsung, reversal is only when using meant-for-front-projection glasses with RPTVs or vice-versa. The Samsung and Mitsu glasses are identical other than branding.

At this point, with Ultimate 3D Heaven about to start shipping cheaper-than-OEM but still not super cheap emitters ($40 + s/h, http://www.ultimate3dheaven.com/3dtrformisa3.html) I may just buy one and then assuming it works 100% I can probe it to figure out whats wrong with my timing and still kick out el cheapos that work properly 100%.


Sun Apr 03, 2011 7:22 am
Profile
One Eyed Hopeful

Joined: Tue Jan 11, 2011 4:09 am
Posts: 11
Reply with quote
AWoods wrote:
For those interested in understanding the differences and similarities between a wide selection of various Infrared 3D Sync protocols, we have just issued the following white paper:

"A Survey of 3D Sync IR Protocols"
http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf

Let us know what you think!

For your reference, we used Petrus' universal shutterglasses controller in part of the testing.


Thanks for the info, maybe this will enlighten me as to why I can't quite nail down the timing.


Sun Apr 03, 2011 7:23 am
Profile
One Eyed Hopeful

Joined: Sun Jan 09, 2011 11:09 pm
Posts: 5
Reply with quote
AWoods wrote:
For those interested in understanding the differences and similarities between a wide selection of various Infrared 3D Sync protocols, we have just issued the following white paper:

"A Survey of 3D Sync IR Protocols"
http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf


Nicely done!
Looks like you even got paid to do it. LOL

Some important things that are missing from all the descriptions is the carrier frequency (if any) and the position of top of frame (V sync).
It would also have been nice to include the LCD shutter response (transparancey) with respect to the data sent.
Perhaps you have this data and could add it to the charts in a revised document.

If not, are the raw data captures available for review and analysis?

Given the slow response time of the shutters, it should be possible to send some protocols simultaineously, straddling the V sync marker.
And of course there is the additional study of what timing range is valid for a given brand shutter glass.

Thanks for doing this and publishing it where we can all use it.

Bob


Tue Apr 05, 2011 1:17 pm
Profile
SD&A Co-Chair

Joined: Sat Dec 22, 2007 3:38 am
Posts: 57
Reply with quote
Ampfan2 wrote:
Some important things that are missing from all the descriptions is the carrier frequency
Some of the protocols don't appear to work with a carrier frequency so didn't include discussion of it. It can be inferred from the information provided if needed.

Ampfan2 wrote:
position of top of frame (V sync). <snip> the LC shutter response (transparency) with respect to the data sent.
We have that information and plan to include it in a future paper.

Ampfan2 wrote:
Given the slow response time of the shutters, it should be possible to send some protocols simultaneously, straddling the V sync marker.
And of course there is the additional study of what timing range is valid for a given brand shutter glass.
These aspects are mentioned in the discussion section of the white paper.
We're currently investigating the ability for different protocols to coexist - unfortunately many won't.
We did a little bit of work examining the acceptable timing variation of some glasses, but it's a lot of effort for minimal gain.


Tue Apr 05, 2011 8:43 pm
Profile
One Eyed Hopeful

Joined: Tue Jan 11, 2011 4:09 am
Posts: 11
Reply with quote
AWoods wrote:
Ampfan2 wrote:
position of top of frame (V sync). <snip> the LC shutter response (transparency) with respect to the data sent.
We have that information and plan to include it in a future paper.


If you're able to and have the info at hand, what delay if any is there between the VESA signal and start of frame (or vice versa)?

The timing information in your paper for Samsung/Mitsubishi glasses was slightly different from what I was using, after adjusting my code accordingly the shuttering is much more stable even when looking at funny angles from the screen and syncs more quickly, but I still have the same problem I'm having where I'm either a bit too soon or too late and I haven't been able to guess my way to the proper offset.


Thu Apr 07, 2011 12:50 pm
Profile
One Eyed Hopeful

Joined: Sat Dec 22, 2007 3:38 am
Posts: 35
Reply with quote
AWoods wrote:
For those interested in understanding the differences and similarities between a wide selection of various Infrared 3D Sync protocols, we have just issued the following white paper
[...]
Let us know what you think!


very intersting read! A lot been going on since I frequented these forums.

Just out of curiosity: from looking at it, it appears to me that all of these protocols look strikingly suspective to be simple PCM /BiPhase codes. I mean, given the glasses use cheap and energy efficient electronics, I do not see that they would have exact timing circuitries to differentiate between something like 21.1 or 23,75 uS or 12.1 and 14.2 uS - especially since this would also differ depending on the exact refresh rate.
I would almost guess that, sticking with nvidia's example we are just looking at 2 different cycle rates of roughly some where between 40-50 and 80-100 uS respectively which would simplify the code:
Right On / Right Off / Blank / Left On / Left Off / Blank/...
to something like
IO / DD / IO / Blank / O / DD / II / Blank / ...

where DD is the duty delay for the time the shutters are opened up.
Might be worth trying - for somebody with the options to simplify the protocols according to this and give it a try.


Fri Apr 29, 2011 11:03 am
Profile
Cross Eyed!
User avatar

Joined: Wed Nov 25, 2009 9:47 am
Posts: 148
Location: Bordeaux, France
Reply with quote
nothing.
I should not have post.

_________________
Image


Sat Oct 22, 2011 7:41 am
Profile
One Eyed Hopeful

Joined: Tue Jan 24, 2012 5:37 pm
Posts: 5
Reply with quote
@Petrus & OzOnE2k10 & evgenln & all
can you please say me a code to activate and use samsung glasses?
i use arduino board and cant send right signal
Image
is not a same
Image

Code:
// This sketch will send out a Nikon D50 trigger signal (probably works with most Nikons)
// See the full tutorial at http://www.ladyada.net/learn/sensors/ir.html
// this code is public domain, please enjoy!

int IRledPin =  3;    // LED connected to digital pin 13
 
// The setup() method runs once, when the sketch starts
 
void setup()   {               
  // initialize the IR digital pin as an output:
  pinMode(IRledPin, OUTPUT);     
 
  Serial.begin(9600);
}
 
void loop()                     
{
  Serial.println("Sending IR signal");
 
  SendCode();
 
  //delay(1000);  // wait one minute (60 seconds * 1000 milliseconds)
}
 
// This procedure sends a 38KHz pulse to the IRledPin
// for a certain # of microseconds. We'll use this whenever we need to send codes
void pulseIR(long microsecs) {
  // we'll count down from the number of microseconds we are told to wait
 
  cli();  // this turns off any background interrupts
 
  while (microsecs > 0) {
    // 38 kHz is about 13 microseconds high and 13 microseconds low
   digitalWrite(IRledPin, HIGH);  // this takes about 3 microseconds to happen
   delayMicroseconds(14);         // hang out for 10 microseconds
   digitalWrite(IRledPin, LOW);   // this also takes about 3 microseconds
   delayMicroseconds(11);         // hang out for 10 microseconds
 
   // so 26 microseconds altogether
   microsecs -= 31;
  }
 
  sei();  // this turns them back on
}
 
void SendCode() {
pulseIR(180);
delayMicroseconds(8700);
pulseIR(180);
delayMicroseconds(2650);
pulseIR(180);
delayMicroseconds(8700);
}

not work for me :(


i recive raw codes with arduino
1st methid
http://www.arcfn.com/2009/08/multi-prot ... brary.html
Raw (20): -8100 200 -8000 250 -8050 200 -8000 250 -8050 200 -8000 200 -8050 250 -8000 200 -8050 250 -8050 200

2nd
http://www.ladyada.net/learn/sensors/ir.html

OFF ON
64960 usec, 180 usec
64960 usec, 180 usec
64980 usec, 160 usec
64980 usec, 180 usec
64980 usec, 180 usec
64980 usec, 180 usec
64980 usec, 160 usec
64980 usec, 180 usec
64960 usec, 180 usec

@evgenln
tread in russian
http://www.pristavka.de/index.php/topic,10228.0.html


Tue Jan 31, 2012 3:09 pm
Profile
One Eyed Hopeful

Joined: Tue Jan 24, 2012 5:37 pm
Posts: 5
Reply with quote
is this right logik?
400us sync(<17us on 15us off> x 15) 8000us(8ms) pause ?


Wed Feb 01, 2012 8:09 am
Profile
Sharp Eyed Eagle!

Joined: Wed Jan 13, 2010 7:12 am
Posts: 436
Location: UK
Reply with quote
Hi, nitrogen,

Sorry, I must have missed your message before. I don't think I'm getting e-mails on new posts for some reason?

OK, I've read through most of your posts on pristavka.de, but with the translation it's difficult for me to understand exactly what you're doing...
Have you managed to get the Samsung glasses working reliably yet?

For the Samsung IR glasses, the protocol that first worked for me was simple - I only sent ONE short pulse every FOUR frames! (no carrier!)

I don't have a Samsung TV to test the real protocol, so I only found it by trial-and-error. (It took me months to realize the FOUR-frames pause!)
I only have a pair of SSG-V2100's and a cheap pair of "Samsung compatible" glasses from China. They both worked OK with the single pulse...

So, at 120Hz, I was sending...

Short pulse (around 20uS),
Wait for 33.333mS (FOUR frames at 8.333mS each)
Short pulse (around 20uS), and so on...

This worked OK, but probably isn't best. I then saw the "Samsung 2010" protocol in the Woods / Helliwell PDF (page 11)...

http://cmst.curtin.edu.au/local/docs/pu ... ync-IR.pdf

So now I send the "proper" group of three 17uS pulses every FOUR frames...

High pulse for 17uS,
Delay for 31uS,
High pulse for 17uS,
Delay for 31uS,
High pulse for 17uS,

Wait for 33.333mS (FOUR frames at 8.333mS / 120Hz)

High pulse for 17uS,
Delay for 31uS,
High pulse for 17uS,
Delay for 31uS,
High pulse for 17uS,
and so on...

This works great, and the glasses seem to get better range from the emitter.
My emitter is actually a Osram Golden Dragon IR LED which sits on top of my projector pointing at the screen.
The LED is so powerful that only one LED is needed, and it reflects the IR signal around the whole room!

I can compile Petrus' code for you so it will test the Samsung glasses at 120Hz, but it would be easier for me if you used AVR Studio instead. :)
(I don't like the Arduino software, but I do use an Arduino board.)

To use AVR Studio with the Arduino board, I just add a comment at the start of the code to remind me about the Arduino pin layout.
I then just use "avrdude" to program the Arduino board itself.

Are you trying to receive the 3D sync code from your Sony TV and convert to Samsung IR?
How are you extracting the sync from the TV / PS3?

I hope I haven't been too confusing. :D

OzOnE.
btw, I don't think that IR receiver code is working too well for finding the 3D sync codes, your DSO Nano should be more reliable.


Sun May 20, 2012 4:57 pm
Profile
Sharp Eyed Eagle!

Joined: Wed Jan 13, 2010 7:12 am
Posts: 436
Location: UK
Reply with quote
Oh, also - have you had any success getting the Sony IR glasses working yet? I gave up months ago trying to get mine to activate?

I wanted to use the Sony IR glasses because they can use different duty-cycles for the shuttering. That means I could use them for doing Colorflipping on DLP projectors (and possibly on plasma TV's too). The Sony glasses are very cheap now as well.

OzOnE.


Sun May 20, 2012 5:19 pm
Profile
Sharp Eyed Eagle!

Joined: Wed Jan 13, 2010 7:12 am
Posts: 436
Location: UK
Reply with quote
@nitrogen - Try this sketch...


// Testing Samsung / Mitsubishi 3D shutter glasses at 120Hz.
// (using Samsung 2010 IR protocol!) OzOnE.

int IRledPin = 3; // IR LED connected to digital pin 13 (@nitrogen - is this meant to be 3 ?)

// The setup() method runs once, when the sketch starts

void setup() {
// initialize the IR digital pin as an output:
pinMode(IRledPin, OUTPUT);

Serial.begin(9600);
}

void loop() {
samsung_ir_pulse(); // This should start with the RIGHT shutter clear first (the Mitsubishi glasses apparently start with the LEFT).

delayMicroseconds(8333); // Wait for FOUR frames to pass (@120Hz), before next IR pulse.
delayMicroseconds(8333); // (the glasses will auto-shutter RIGHT/LEFT/RIGHT/LEFT during this time)
delayMicroseconds(8333);
delayMicroseconds(8333);
}

void samsung_ir_pulse() {
cli(); // Turn off any background interrupts (temporarily).

digitalWrite(IRledPin, HIGH); // this takes about 3 microseconds to happen
delayMicroseconds(14); // I actually want around 17uS, so we subtract the 3uS.
digitalWrite(IRledPin, LOW); // this takes about 3 microseconds to happen
delayMicroseconds(29); // I actually want around 32uS, so we subtract the 3uS.
digitalWrite(IRledPin, HIGH);
delayMicroseconds(14);
digitalWrite(IRledPin, LOW);
delayMicroseconds(29);
digitalWrite(IRledPin, HIGH);
delayMicroseconds(14);
digitalWrite(IRledPin, LOW);

sei(); // Turn interrupts back on!
}


I haven't tested this code yet, but hopefully it will work for very basic testing.
If you want to sync the glasses to an external trigger (VSYNC or VESA), then you might need to do some frame counting, so it only outputs a pulse once every four frames.

It shouldn't need a carrier routine because the above pulses directly generate the carrier at around 20,576Hz.
I took the delay timings from the Woods / Helliwell PDF, so I don't know what the REAL carrier is supposed to be?

I had to "round" the microseconds a bit though, so the actual output should be closer to 20,408Hz.

If it doesn't work too well at first, try changing the "(29)"s to "(28)"s.

The glasses seem quite forgiving with the pulses. As I say, they also work with just a single pulse!
I guess the idea of using a carrier is to give better immunity from external IR interference and normal remote controls.
In theory, the carrier might increase the range too.

(btw, I split the frames delay into four separate "delayMicroseconds(8333)" statements because the maximum delay is 16,383 before the timer starts loosing accuracy.)


Let me know if it works!
It should only need to be simple like the above code - try not to rely on the Arduino libraries too much if it can be done more easily at a lower level. ;)
Many of those IR libraries are designed mainly with Remote Controls in mind, so capturing a 3D emitter might cause strange results.


OzOnE.


Tue May 22, 2012 11:01 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 101 posts ]  Go to page Previous  1, 2, 3

Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by STSoftware.