How to get rotation working


Staff member
Mar 4, 2003
Well, first the good news:

notaz got the rotation with the SSD working! We now have a stable, nonshifted and proper picture rotated by the SSD on the LCD.

One issue remains: The LCD has some tearing right now, be we haven't setup the AntiTearing system, so that was to be expected. It'll be the next thing - and then that's it for the LCD part.

In case you were wondering why it took so long:

It was a mixture of hardware and software issues.

As mentioned, the hardware had power issues, so even with the correct software setup, the SSD didn't work - so we poked around with the software for a while, but it could've never worked.

Once Nikolaus fixed the power issues, the SSD started to work with proper timing setups, and then rotation REALLY was easy (compared to the rest).

notaz did all the testing via remote connection on my dev setup.

Many of you have asked how this worked and wanted to see a picture of it - well, here it is, picture and explanation:


As you can clearly see from the background, the setup is standing around in my gaming room :)

First, let's list the parts we have here:

  • Pandora
  • Webcam
  • LCD
  • Pyra Main PCB
  • Pyra Display PCB

The device above the Pandora (where the webcam is clipped on) is simply a cheap old DVD player, only there to keep the webcam in place.

The RaspberryPi2 box is just there to keep the LCD in place :)

Now what's connected with what and why?

The Pandora

The Pandora is setup so notaz can access it externally via SSH and VNC.
The webcam plays back the video stream using mplayer on Pandoras display which can be accessed by notaz via VNC.

The Pandora is also connected to the serial output debug port of the OMAP5 devboard for low-level terminal access (without network). He can also reset the devboard with that in case it crashes.

Another USB cable connects the Pandora to the devboard and features a direct network connection (g_ether). This is simply because using Wifi on the Pandora is not that good for VNC and SSH, so he can also connect to the Pandora from the devboard and cable ethernet.

So: If the Devboard runs, he can connect to the Pandora from there, if the devboard has crashed, he can connect to the Pandora via Wifi and restart the Devboard, debugging it using the serial out connection.

The Devboard

The devboard also is setup so that notaz can access it via SSH.
It has a normal ethernet cable which connects it to the internet, and it also provides internet access to the Pandora using a USB cable (as mentioned above).

The second USB-Cable (MicroUSB) is the debug / serial out port connected to the Pandora.

We have a special adaptor attached which connects the devboard with Pyras Main PCB (so the devboard is a replacement for Pyras CPU PCB right now), and Pyras Display PCB is connected to the Main PCB the same way it will be connected in the final device.

Finally, on the Display PCB, the LCD is connected.

That's a pretty neat setup, isn't it?

It shows how versatile the Pandora is (and the Pyra will be).

Let me know if you have further questions :)
Really nice. Almost everything can be controller remotely.

I've worked on projects where I had to ask a colleague from the remote site to push the reset button on the board. And the time zone difference between sites meant I could only work on the board only for a couple of ours a day. You, on the other hand, seem to have everything covered.
It's only a little time since Nikolaus found what needed to be boosted to fix the LCD cable power issues (I'm a little hazy on why that required changes to the cpu board and not the peripheral/main board where the LCD is connected, but hey ho). If he's even done the revised schematics yet, he'll have had to order more prototype boards, which will take more time.
Did you notice those crazy flying leads apparently running from the CPU board connector to somewhere near the 3G chips?

Also, is VNC any good for video over the internet these days? Last time I used it, even on the local network, FMV came out more like a slideshow.

I guess that's enough for checking for tearing most of the time mind you.
Last edited by a moderator:
Why is there a yellow relay attached to that?
It's a Switchable USB port I used a standard relay as I figured there may be some applications where It may draw more than an Amp. So I have it so it's being controlled by the Raspberry Pi also shown in the photo. I planned to use it to remotely switch OSs installed on thumbdrives on the OMAP Devboard. I got the USB port switch working fine, however never did get to installing different OSs on the thumbdrives.  

With my setup I can also remotely reset and power off the OMAP5 devboard, which is what the other small relays on the solderless breadboard are being used for.  

Edit: cleaned up my wording... I think.
Last edited by a moderator:

TrashyMG .. good christ dude :) (by which I mean, your devboard pic fails, it has no boxed carts behind it!)


TrashyMG .. good christ dude :) (by which I mean, your devboard pic fails, it has no boxed carts behind it!)

I'll remember for future pictures...

I've actually cleaned it up a bit as the OS is pretty stable now and don't need to reboot remotely as much as when I was using Ti's ubuntu install with the flaky kernel.

I have a fairly big project revolving around the omap5 devboard, will post more on that later.
how bad is the tearing what is this "AntiTearing" system?? :)
Well, right now it's a small line moving from left to right slowly :)

The Anti-Tearing is a special trace that synchronizes the video stream with the SSD and the display, so that no such tearing happens.