DLP® Pico™ Display Projector EVM-BeagleBone Black - Review

Table of contents

RoadTest: DLP® Pico™ Display Projector EVM-BeagleBone Black

Author: packetgeek

Creation date: 11 Apr 2018

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: For the price, none. I've not seen another DLP board offered at this product's price range.

What were the biggest problems encountered?: 1) RF interference with the wiring required to connect the DLP to the Raspberry PI. 2) BBB is somewhat under-powered when compared to other available SBCs.

Detailed Review:

================

== Short version ==

================

I enjoyed working with the DLP and BBB but, as a hobbyist, I had to learn a lot more than expected.  I wasn't able to finish my project due to having to troubleshoot issues that were mostly of my own creation (wiring).  It took forever to get the wiring between the DLP and the Raspberry Pi correct and it still doesn't function properly, which is mostly due to the quality and length of the wires that I had on hand (they are too long and pick up too much interference).  I've attached a picture of my less-than-successful attempt at "breadboarding"the display.

All that said, for the advanced hobbyist I do recommend purchasing and experimenting with the DLP.  However, it shoud be done with a SBC that is a bit more powerful than the BBB (e.g., a Raspberry Pi or similar device).  Also, I'll second the vendor's recommendation about creating an adapter board.  The device is very sensitive to noise, especially that picked up by overly long breadboard wires.  The majority of the allowed time for this review was consumed by troubleshooting an interference-caused video skewing issue that I was never successful in completely removing (caused by over-long breadboard wiring).

I have the product a all-10 review except for the "Specifications are sufficient to design with" and "Product was easy to use" categories.  Although the vendor did give a recommendation that an adapter board be developed, the "why" part wasn't explained (it turns out that the device is sensitive to noise introduced by standard breadboard wiring).  It was also initially a bit difficult in interpreting the documentation, especially the parts which describe the selection of various bit-length video, as the authors assume that the reader is experienced with working with the employed notation in the charts.

Note: when connected to the Raspberry Pi, use is limited to the lower bit graphics due to the number of available data pins in the Raspberry Pi's physical connection header.  For the same DLP connected to the BBB, those grades would be 10's but I give the "The price to performance ratio was good" category an 8 or 9.  This is because the BBB is somewhat under-powered and display of videos (with audio) requires some external transcoding of the video(s) to reduce the load on the BBB.

Advantages

1) The price.  I'm seeing the board for sale on various sites for less than $100.

2) The access to the controls.  Even when connected to the under-powered Beagle Bone Black (BBB), it's nice to have programmatic access to the device.

Shortcomings

1) Care must be taken when separating the DLP from the BBB.  I managed to bend a pin when prying mine apart.

2) This is not an easy project for the average hobbyist, mostly because only a handful of people have been successful in getting the DLP to work with the RPi (and their notes are based on a number of non-beginner assumptions).

3) Focus is performed manually, using a very small lever on the side of the black enclosure surrounding the lens.  It is a very rough focus and takes some patience to properly adjust.  Note: the vendor appears to have provided a solution for this, involving a screw which replaces the lever.

Recommendation(s)

1) I recommend purchasing the device as getting it up and running on either the BBB or RPi is a learning experience.  That said, the average hobbyist should be prepared for an extended learning curve and should be ready to research just about every step on getting the board working.

=================

== Longer version ==

=================

My proposal involved experimentation with the I2C interface, in getting it to work with a Raspberry Pi, to function has an alert display for various types of messages:

  - Twitter feeds

  - misc. alert messages (e.g., motion detected by XXX sensor, when a friend logs onto Facebook)

  - status of various network services

  - currently-playing song titles

My idea was that I could write code that would produce output via a frame buffer, as described in an interesting thread on Stack Overflow (https://electronics.stackexchange.com/questions/102695/how-does-a-gpu-cpu-communicate-with-a-standard-display-output-hdm… ) and later expanded upon by Seena Burns (Writing To The Framebuffer | Seena Burns ).  I didn't think that almost the entire review period would be consumed by troubleshooting the interface between the DLP and the RPi.  I was able to demo a couple tools (much below) on the DLP/BBB combination towards the end of the review period.

Unboxing and initial testing

Received the kit on the evening of 7 Feb 2018.  Included were the Beagle Bone Black (BBB), Texas Instrument's (TI's) DLP projector, a power supply for the DLP, and a USB cable for the BBB.  Also in the box was a printed User's Guide, a power supply, and a standard USB-to-micro USB cable.  The projector was already mounted on (and connected to) the BBB.

On that first evening, I only had enough time this evening to open the box and examine the contents.  The initial goal was to run the BBB and the projector through the "Example Application" in the User's Guide, to validate that the device works out-of-the-box (I've been known to release the magic blue smoke on certain devices so I've made a habit of proving a device works before I start connecting it to other things).  This was successful, as was pushing a m4v onto the BBB and playing it with mplayer (as per the docs).

I initially had trouble accessing the device, mostly because I skipped most of the reading and jumped straight into running the demo described in the Quick-Start section of the User Guide.  From what I did read, I noted the comment about the DLP's power supply also being sufficient to power the RPi.  I plugged in the provided power supply and connected an Ethernet cable to the BBB and... nothing.  This pushed me back into reading mode.  I finally noted on the TI web site that even though the power supply is capable of such, it's not connected in a manner to support it by default.  Adding a separate power supply for the BBB allowed me to boot both devices and complete the demo.

Once that was done, I downloaded all other applicable documentation from ti.com and started reading.  I also downloaded the BeagleBone Black System Reference Manual from Adafruit:

    https://cdn-shop.adafruit.com/datasheets/BBB_SRM.pdf.

The I2C commands expecially look interesting, though some will require additional research and experimentation (I learned to write I2C controls in C, on a device with a much smaller command set, though it was written mostly in Chinese and had to be run through Google Translate).  In reading others' reviews, I see that they've made use of this information (e.g., controlling color of displayed info by turning on/off one or more of the three LED colors).  Although the documentation states that the graphics engine cannot be turned off once the device is booted (short of discontinuing power), it appears that such can be emulated by turning off all three.

The BBB I2C script

To avoid having to type the two i2cset commands after every boot, I created a script containing the following and saved it to ~/bin/setup.sh (note: you may have to create the "bin" folder in your home directory if you're using something other than the default debian account).

  #!/bin/bash

  sudo i2cset -y 2 0x1b 0x0b 0x00 0x00 0x00 0x00 i

  sudo i2cset -y 2 0x1b 0x0c 0x00 0x00 0x00 0x1b i

Please note that the above are specific to the DLP when it's connected to the BBB and not the Raspberry Pi (those are below).

========================================

== Miscellaneous notes, in no particular order ==

========================================

Figuring out the initial IP address for the BBB

Since the documentation indicates that the device boots via DHCP, I went looking for it with the following command:

  nmap -sP 192.168.2.1-30

where "1-30" is the range of DHCP IP addresses that I allow in my network.  The BBB showed up with the following information:

  Nmap scan report for 192.168.2.18

  Host is up (-0.100s latency).

  MAC Address: 98:84:E3:9B:93:59 (Unknown)

It's interesting that Nmap doesn't recognize the vendor for the provided MAC address.  This is likely because the DLP is a prototype and uses a new(er) NIC.  That or I need to update my nmap instance.

Note: if you're going to configure a static IP address for the BBB, it's important to set it now, to avoid having to search for it again.  This is because it's likely to change once you reboot the BBB.

The inital I2C info

On the BBB, I attempted to locate the various I2C addresses using the i2cdetect command.  "i2cdetect -r -y 0" returned the following (when connected to the BBB):

  root@beaglebone:/etc/network# i2cdetect -r -y 0

        0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

  00:          -- -- -- -- -- -- -- -- -- -- -- -- --

  10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

  20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --

  30: -- -- -- -- 34 -- -- -- -- -- -- -- -- -- -- --

  40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

  50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

  60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

  70: -- -- -- -- -- -- -- --

"i2cdetect -r -y 1" returned an error and "i2cdetect -r -y 2" returned a response similar to that for the "0" bus.

During my initial attempt with the standard demo, I couldn't use the i2cset program to set either of the settings in the example application described in the docs.  The cause of this was my misinterpreting the statement about the DLP being able to power the BBB.  By default, it's not wired that way.  You either need to set up a jumper to the DLP's power supply or add a separate power supply for the employed SBC (BBB or Raspberry Pi).  Once I connected a separate power supply to the BBB, I was able to boot the DLP and BBB, and display a test video via the DLP.  As long as the BBB didn't have to do much transcoding, the videos appeared find.  However, playing HD videos through the combination of the BBB and the DLP cause mplayer to spit up the following warning, even though the video does play with little/no issue.

  ************************************************

  **** Your system is too SLOW to play this!  ****

  ************************************************

Disassembling the DLP and BBB

Visual inspection of the DLP/BBB assembly will likely lead one to believe that disassembly requires a screwdriver and a wrench.  It doesn't.  The DLP is only press-fit into the BBB's P1 and P2 connectors.  The stand-offs are there only to maintain stability and a clearance between the boards.  Care should be taken when prying the two devices apart as it is quite easy to inadvertently bend one or more of the DLP pins (I inadvertantly managed to do this).

Connecting the DLP to the Raspberry Pi 3

There's not much documentation available for connecting the DLP2000 to a Raspberry Pi.  There was even less of it before this Road Test was announced (much of the available information came from the other five reviewers).  Most articles involving the Raspberry Pi are comparisons between the Raspberry Pi and the Beagle Bone Black (BBB), for which the DLP2000 is connector-compatible.  Searching for DLPC2607 and Raspberry Pi returns similarly dismal results.  The majority of useful information comes from either the TI web site (https://e2e.ti.com/support/dlp__mems_micro-electro-mechanical_systems/video_and_data_display/f/947/t/617366) or the Element14 community.

My initial attempt at connecting the two devices took up an entire weekend.  I made things complicated for myself by attempting to use the cribbed diagrams provided by the vendor and employed by the other reviewers.  The Raspberry Pi has its GPIO header along one side of the board and the DLP has connectors (fortunately both male and femail) on two separate headers (one on each side of the board).  Aligning the RPi's GPIO header with the DLP's P1 header (where most of the connections to the RPi originate) requires a 180 degree rotation of one of the boards, to provide the shortest distance between the two.

I kept making mistakes and validating 50+ connections across the bundle of wires was tedious and time consuming.  I'd even attempted restarting the wiring again before I gave up and developed a spreadsheet, displaying the pin-outs of each board (with the DLP rotated 180 degrees to reflect the physical relation between the boards).  The end result was that, 5+ weeks later, the DLP displayed an image that was skewed diagonally and was mostly illegible.  However, I was encouraged after reading other reviewer's discussion in that all of the displayed colors appear correct (I have other Raspberry Pis with the same desktop background).  At the end of the review period, I have a correctly colored display that is skewed about 5% from the left, that is somewhat viewable, but annoying enough that a different approach is needed for connecting the two devices together (there's too much interference when breadboard wires are employed).  TI recommends development of an adapter board to connect the DLP to the RPi.  I believe this to be an understatement because "breadboarding it" is quite involved and takes hours to connect properly.

Side note: given that creating an adapter doesn't require any discrete components (just connectors), such may a good starter project for those looking to also get into board prototyping.  I intend to do this but have to learn the entire process first (my PCB training is from the 70's, where we'd hand-make the prototypes using photo-reduction/etching technologies).

For breadboarding, I had to become a bit inventive with the wiring as the connection required more conductors of one type than I already had (and initially assumed).  Luckily, the DLP has both male and femaile connections for both the P1 and P2 connectors.  This allowed me to mix in a few M/F conductors with the employed F/F conductors.  However, as explained elsewhere in this post, "breadboarding" turned out to be a poor choice (because of the length and quality of the wires involved).

Displaying messages

My project proposal involved alerting people in the room to various messages.  I came up with two methods: one an adaptation of the tickr program and the other a Python script that shows messages via overlays.

The tickr tool

For the initial application, I've selected Tickr.  Initial attempt will be to exchange an application for the employed lightdm window manager (i.e., set up the device in a Linux kiosk mode).  This is inspired by Rares Aioanei's article on running X applications without a desktop or window manager (https://linuxconfig.org/how-to-run-x-applications-without-a-desktop-or-a-wm ).

Tickr is a tool that will read one or more RSS feeds and horizontally scroll the titles across the screen via an overlay.  You can change the fonts, tweak the size of the fonts, and adjust the scrolling speed of the text.  (Side note: I'll attach my tickr config file here after I return from work-related travel).

Installation steps:

1) edit /etc/X11/Xwrapper.config and change "allowed_users=console" to "allowed_users=anybody"

2) install tickr by running

   apt-get install tickr

3) configuring tickr will be a challenge if you don't have a keyboard and mouse attached to the BBB.  You should tweak ~/.ticker/ticker-config to suit your tastes.

4) Tickr can then be run via:

    xinit /usr/bin/tickr $* -- :1

The Python script

I also wrote a Python script that will display a multi-line message via a desktop overlay.  It uses the python-pyosd package.  The script is included at the bottom of this post (vice attached as Element14 does not allow such attachments).  My intent is to also add an MQTT interface to this script so that it can display "now playing" songs from my home-grown jukebox (which already has the MQTT interface which shows currently playing titles on a Node-Red dashboard).  I'll update the attachment as I improve the interface and add capabilities.

Turning off the display

There's not a whole lot of documentation available for connecting the DLP2000 to a Raspberry Pi.  Most articles involving the Raspberry Pi are comparisons between the Raspberry Pi and the Beagle Bone Black (BBB), for which the DLP2000 is connector-compatible.  Searching for DLPC2607 and Raspberry Pi returns similarly dismal results.  The majority of useful information comes from:  https://e2e.ti.com/support/dlp__mems_micro-electro-mechanical_systems/video_and_data_display/f/947/t/617366

In reading the documentation, it was indicated that the graphics engine cannot be turned off to save wear and tear on the LEDs.  According to page 52, section 3.2, there is no programmatic way to power down the display.  That said, the vendor says that the Proj_ON pin can be driven low, which effectively accomplishes the effect (without actually turning off the LEDs).  With a little experimentation with the setup commands, I'm thinking that this can be accomplished with:

   sudo i2cset -y 2 0x1b 0x0c 0x00 0x00 0x00 0x00 i

Update: XXXXXXX has provided the i2c commands that can individually turn on/off the red, blue, and green colors.

Wiring tips

I was having a difficult time figuring out how to connect the projector to the Raspberry Pi (admittedly until almost the end of the eval period).  The bonus RPi3 wiring section of Frederick Vandenbosch's eval (https://www.element14.com/community/roadTestReviews/2662/l/dlp-pico-display-projector-evm-beaglebone-black-review) helped greatly, as did his pointer to Philip Hodges post (https://e2e.ti.com/support/dlp__mems_micro-electro-mechanical_systems/video_and_data_display/f/947/p/651931/2395243).  I recommend reading Frederick's review as he has a wiring trick that allows you to run both the DLP and the RPi off of only the DLP's power supply (providing a savings for outlet space).

Other valuable pin-out drawings are available via:

- https://pinout.xyz/

- https://pinout.xyz/pinout/dpi

- https://pinout.xyz/pinout/i2c

- Section 3.2 of dlpu049c.pdf

Oddities (investigate later)

First time test with my attempt at Frederick's wiring, both /dev/i2c-0 and /dev/i2c-2 have disappeared.  In their place, i2c-3 exists and returns variable answers when queried with i2cdetect.  Examples:

root@raspberrypi:~# i2cdetect -r -y 3

    0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00:          -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- 57 -- 59 -- -- -- 5d -- --

60: -- -- -- -- -- -- 66 -- -- -- -- -- 6c -- -- --

70: -- -- -- -- -- -- -- --

These numbers move around if I run the command again.

root@raspberrypi:~# i2cdetect -r -y 3

    0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f

00:          -- -- -- -- -- -- -- -- -- -- -- 0e --

10: -- -- -- -- -- -- -- -- -- -- -- 1b -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- 36 -- -- -- -- -- 3c -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- 4b -- -- -- --

50: -- 51 -- -- -- -- -- 57 -- -- -- -- -- -- -- --

60: -- -- -- -- 64 -- -- -- -- -- -- 6b -- -- -- --

70: -- -- -- -- -- -- -- --

I don't know if this is a good sign or a bad one.  Assumption is "bad", possibly related to my initial wiring attempt.  I did not retry these after the second or third rewiring.  I will investigate these as time allows.

Initializing the RPi screen

Once I thought that I had the wiring correct, running the following did take control of the screen (blacked it out)

  sudo i2cset -y 3 0x1b 0x0c 0x00 0x00 0x00 0x13 i

  sudo i2cset -y 3 0x1b 0x0b 0x00 0x00 0x00 0x00 i

Note: the above is slightly different than what is used on the BBB.  I added the above to the tail end of /etc/rc.local and rebooted.  At this point, I had a a slightly skewed display of the default Raspbian desktop and I could see the mouse if I moved it.  The background is non-linearly skewed horizontally, and the display shivers.  The colors are correct however.  I shut it down and worked on validating connections and /boot/config.txt settings.  These appeared to be correct so I went after the other possible cause: the length of specific wires being too long, picking up noise, and causing interference with the video signals.

I was able to remove much of the skewing by replacing the PCLK, DATAEN, VSYNC, and HSYNC wires with much shorter conductors. The skewing is minimal but not gone (about 5% on the left-hand side, vice 50%) but the jittering is just as pronounced.  Unfortunately, I have run out of allowable review time (60 days) and am posting this as part of the notes for the review.  I will continue to work on this until I have a working rig and will post the miscellaneous notes to Element14.

I intend to make an attempt at producing a DLP/RPi interface board but I'll be learning (mostly) from scratch.  I learned how to hand make circuit boards in the 1970's and haven't turned out much since.  I'm currently reading the Element14 thread (https://www.element14.com/community/thread/5197/l/cheapest-pcb-makers-low-volume) and watching Youtube videos on the topic.

Troubleshooting

1) The display does not come on.  This can be caused by a number of issues (most of which are user-related).

2) The graphics engine has no power (I've found that it requires a power supply separate from that which powers the BBB). Repair by providing power to the graphics engine and then reboot the BBB.

3) The two i2cset commands were not issued properly or sent to the propoer address.  Read the vendor's quick start notes about determining the address with i2cdetect and sending the two initial commands with the i2cset command.  Note: for the Raspberry Pi, the two i2cset commands are slightly different than those used for the BBB.

Other things attempted

- When I boot the RPi, I see the 4 raspberrys, with a blinking cursor below them.  When the RPi switches to graphic desktop mode, the display skews.

- I experimented with the test patterns and resolution settings from Christian-Gyozo Haba's review (https://www.element14.com/community/roadTestReviews/2629/l/dlp-pico-display-projector-evm-beaglebone-black-review)

- https://www.element14.com/community/roadTestReviews/2650/l/dlp-pico-display-projector-evm-beaglebone-black-review

- https://www.element14.com/community/groups/roadtest/content?filterID=contentstatus%5Bpublished%5D~objecttype~objecttype%5Broadtestreview%5D&filterID=contentstatus%5Bpublished%5D~language~language%5Bcpl%5D&start=20

- https://www.element14.com/community/roadTestReviews/2645/l/dlp-pico-display-projector-evm-beaglebone-black-review

- https://www.element14.com/community/roadTestReviews/2629/l/dlp-pico-display-projector-evm-beaglebone-black-review

RPi operating system install

1) download the Raspbian Stretch with Desktop distro (March 2018 version) from https://www.raspberrypi.org/downloads/raspbian/

2) unzip the download "touch" command to reach a 0-length file called "ssh" in the boot directory on the SD card

3) edit /etc/network/interfaces.d/wlan0 and make it look like:

  auto eth0

  iface eth0 inet static

  address 192.168.2.202

  netmask 255.255.255.0

  network 192.168.2.0

  broadcast 192.168.2.255

  gateway 192.168.2.1

  dns-nameservers 192.168.2.1

Note: of course, edit the above to match your network

Other things to research

- https://e2e.ti.com/support/dlp__mems_micro-electro-mechanical_systems/video_and_data_display/f/947/t/617366

- https://e2e.ti.com/support/dlp__mems_micro-electro-mechanical_systems/video_and_data_display/f/947/p/636432/2372382

- https://e2e.ti.com/support/dlp__mems_micro-electro-mechanical_systems/video_and_data_display/f/947/t/651931

- https://www.raspberrypi.org/forums/viewtopic.php?t=193754

- https://jp.raspberrypi.org/forums/viewtopic.php?f=107&t=140125&start=25

- http://blog.reasonablycorrect.com/raw-dpi-raspberry-pi/

- Add a Node Red interface for the DLP.

- create the adapter board and an enclosure for the resulting assembly (likely to require a fan) Anyone want to help?

- use the DLP as a display for a slow scan television receiver

- use the DPL as a display for a D-STAR radio

- interesting pieces in the DLP documentation (the i2c controls for the LEDs, resolution, and image rotation)

- Section 2.4.1.23.1 of the Programmers' Guide makes note of a software reset.

- Section 2.4.1.23.2 of the Programmers' Guide makes note of a front-end reset.

- Section 2.4.2 of the Programmers' Guide shows use of higher-than-default resolutions (853x480) and image rotation.

Python script

#!/usr/bin/python

import pyosd

parameters = {

'hoffset' : 12,

'voffset' : 6,

'width' : 38,

}

osd_settings = {

'font' : "-misc-fixed-medium-r-normal-*-64-*-*-*-*-*-*-*",

'colour' : "white",

'timeout' : 10,

'lines' : 100

}

def osd_print(osd, text, hoffset=0, voffset=0):

    #osd.display(text)

    text = text.split("\n")

    line_no = voffset

    max_line_no = osd.get_number_lines()

    for line in text:

        if line_no >= max_line_no: break

        osd.display(" "*hoffset + line,line=line_no)

        line_no += 1

def osd_clear(osd):

    max_line_no = osd.get_number_lines()

    osd.hide()

    for i in range(max_line_no):

       osd.scroll()

#Set up the on screen display

osd = pyosd.osd(font=osd_settings["font"],colour=osd_settings["colour"], timeout=osd_settings["timeout"],lines=osd_settings["lines"])

text="This is a really long line\nthat I hope wraps around\nor scrolls across the screen.\nHere's hoping that it really did work!"

words=text.split(" ")

wordsize=len(words)

# print wordsize

#osd_clear(osd)

osd_print(osd, text, hoffset=parameters['hoffset'], voffset=parameters['voffset'])

# this last is required for when using pyosd in scripts

osd.wait_until_no_display()