Results 1 to 2 of 2

Thread: Running the XJ-A140 without anything connected

  1. #1
    Join Date
    May 2009

    Default Running the XJ-A140 without anything connected

    As a continuation of the project to run an XJ-A140 without the lasers connected (see, I have managed to get the motherboard to power up with only a +5/+12v supply, and the DLP chip. The purpose of this is to allow the DLP device (native resolution 1024x768, 10um mirror pitch, see for more info) to be used without needing the rest of the projector, ex for holography purposes.

    I have been using the MSP430G2553 microprocessor to systematically spoof all of the devices that are attached to the motherboard, and of this evening I managed to get the projector to run without any of the original devices connected (except the DMD device, and power of course), displaying an image provided over VGA/HDMI on the device. I am still working on writing up all of the info, but here is a data dump of some of the specs I have managed to get together so far:

    cn101 - Speaker
    The easiest of them all, simply unplug it

    cn908 - IR detector
    Again, just unplug it

    cn901 - Case Interlock
    Simply short pin 1 to pin 3

    cn401 - Lens Module
    This is the first non-trivial component to spoof, after some work I found that connecting OPRST, IRQ, ZP1 and ZP2 to +3.3v, and logically NANDing the 4 control lines (req0-req3) and feeding that signal back into move, the projector will allow the projector to power up just fine. Be careful, the reqx pins are open collector, so you need a pullup, and I didn't do anything about the limit switches (zp1,zp2) so if you try and focus the module too far in/out the projector will throw an error along the lines of 'your projector is broken', but a power cycle will clear this.

    pin # - name - function - connection on spoofer - direction
    1 - opv5 - 5v - n/c - to focus module
    2 - n/c - n/c - n/c - n/a
    3 - req0 - zoom (in) - pin6 - to focus module (open collector, needs pullup)
    4 - req1 - zoom (out) - pin5 - to focus module (open collector, needs pullup)
    5 - req2 - focus (in) - pin4 - to focus module (open collector, needs pullup)
    6 - req3 - focus (out) - pin3 - to focus module (open collector, needs pullup)
    7 - oprst - ??? - +3.3v - to projector
    8 - move - high when motors are moving - pin3 - to projector
    9 - irq - ??? - +3.3v - to projector
    10 - n/c - n/c - n/c - n/a
    11 - opgnd - gnd - n/c (alternatively - msp430 gnd) - to focus module
    12 - zp1 - lens 1 home posisition, goes low when lens is homed - +3.3v - to projector
    13 - zp2 - lens 2 home posisition, goes low when lens is homed - +3.3v - to projector
    14 - ce - ??? - n/c - from projector
    15 - cnvss - gnd - n/c - from projector

    The focus module is a complete focus/zoom assembly. You can cause outside of the projector by connecting power and using the control lines req0-req3 to to control the zoom/focus. You can force it to home by pulling all of the control lines high (high impedance from the host), which will cause it to home both lenses and go to a default state. Then pull rec0 through rec4 high to adjust the focus/zoom adjustments.

    CN1401 - Fan Controller
    This one gets even trickier, requiring a microprocessor able to interpret I2C serial data.

    Physically, it us just a basic breakout board for the EMC2305 fan controller module, with one oddidity that each fan has an additional control transistor associated with it (connected to FPCN1-5), which disables the fans during the projector startup period (the default state for the fan controller is max power, so without these the fans would briefly spin up to full speed whenever powering up the projector). That said, to spoof it the only signal that needs to be considered is the I2C serial data I2SDA/I2SCL.

    To spoof, only the I2C data buss needs to be spoofed. Additionally, when the diode array is spoofed using DTR's method, returning 0x80 to every read byte and ACKing all writes will work. If the diode array is in place, the actual fan speeds must be returned (requires a more advanced state machine-not implemented yet). Note - there are other devices on this bus so be careful to not interfeare with them. The master does support slave clock stretching, which allows it to be spoofed with a slow (1MHz) microprocessor.

    pin # - name - function - connection on spoofer - direction
    1 - V12FAN - 12v supply for fans - nc - to fan board
    2 - V12FAN - 12v supply for fans - nc - to fan board
    3 - V12FAN - 12v supply for fans - nc - to fan board
    4 - V12FAN - 12v supply for fans - nc - to fan board
    5 - V12FAN - 12v supply for fans - nc - to fan board
    6 - V12FAN - 12v supply for fans - nc - to fan board
    7 - V12FAN - 12v supply for fans - nc - to fan board
    8 - gnd
    9 - gnd
    10 - gnd
    11 - gnd
    12 - gnd
    13 - gnd
    14 - gnd
    15 - gnd
    16 - gnd
    17 - V33PMD - 3.3v supply for fan controller - MSP430 power - to fan board
    18 - I2SDA - data line for EMC2305 - MSP430 P1.7 - bidirectional
    19 - I2SCL - clock for EMC2305 - MSP430 P1.6 - bidirectional
    20 - FPCN1 - fan1 enable - n/c - to fan board
    21 - FPCN2 - fan2 enable - n/c - to fan board
    22 - FPCN3 - fan3 enable - n/c - to fan board
    23 - FPCN4 - fan4 enable - n/c - to fan board
    24 - FPCN5 - fan5 enable - n/c - to fan board
    25 - RX - ??? - n/c - ???
    26 - TX - ??? - n/c - ???
    27 - PHSENS - ??? - n/c - ???
    28 - V5PMD - 5v power - n/c

    To use the fan controller board outside of the projector, tie FPCN1-5 high (these each go to a transistor which enables the +12v to each individual fan, not pulling them high prevents the fan from running), and apply +3.3v power for the controller, as well as +12v power for the fans (requires at least 2amp power supply on +12v). Fans will default to max speed, to slow them down talk to the controller over I2CSCL/I2CSDA

    cn905 - Diode Driver Board
    The driver board was a little tricky to spoof, because it uses a serial bus to communicate with the projector. Luckily, Xdev managed to figure out a way to trick the projector into some kind of 'limp home mode' by connecting LDCPN to LEBL, which disables a good amount of the internal error checking. That said, I still ended up having to decode some of the protocol, but I managed to get it working. It looks like it should be possible to get the board to power up on its own, (or power up the red led without the blue diodes, which was my original goal...), but that will be for another day.

    pin # - name - function - direction - connection to spoofer
    1 - lum - ??? - n/c - to driver board
    2 - rxdbg - receive data to dbg - jump to txdbg - to driver board
    3 - txdbg - transmit data from dbg - jump to rxdbg - to projector
    4 - ldcpn - ??? - jump to ldcpn - to driver board
    5 - cidx - sync pulses to fire lasers - to driver board
    6 - rx0ld - receive data to laser controller - to driver board - connect to msp430 p1.1
    7 - tx0ld - transmit data from laser controller - to projector - connect to msp430 p1.2
    8 - llitz - sync pulses to fire lasers - to driver board
    9 - lebl - laser diode enable - jump to ldcpn - to projector
    10 - vdup - ??? - to driver board
    11 - vp500 - +5v - power to the driver circuitry - to driver board
    12 - gnd - gnd - gnd - to driver board - connect to msp430 gnd
    13 - ldoff - to driver board

    CN801 - color wheel
    pin # - name - function
    1 - c-c - coil c
    2 - c-b - coil b
    3 - c-a - coil a
    4 - gnd - gnd (for hall effect sensor)
    5 - sens - hall effect sensor output (+3.3v pulse at window for blue to pass)
    6 - C3V3P - +3.3v (for hall effect sensor)
    7 - cmn - common for motor windings

    The color wheel uses the hall effect sensor to detect the rotation of the color wheel, and provides an analog signal to the motor controller (PMD1000) to control the motor speed. There is an internal phase lock loop (or something equivalent) in the main microprocessor on the motherboard, which adjusts the analog control signal (pin8 of the PMD1000), and compares the phase of the color wheel to the incoming video signal, and adjusts the speed to get them to lock up. The PMD1000 drives the color wheel as a brushless 3 phase motor, using the back emf voltage induced from the spinning rotor to detect the speed of the color wheel internally. Luckily, it does not complain when the motor is disconnected, so we just need to spoof the tachometer signal going back. To do this I wrote some code which controls a timer on the MSP430, and whenever the control signal is high it increases the frequency, and whenever it is low it decreases the frequency. Currently it has a bit more gain than the motor did so the feedback loop oscillates (however, the projector does not complain, 2 green lights when running), however if anyone wants to extract the color information this issue will need to be solved.

    I am still cleaning up the code, if anyone is interested in trying to replicate these results let me know and I will try and set you up with what you need. If you are looking for a more direct solution, I am planning to have pre-modded motherboards available, which will 'just work' when you apply power.

    In the mean time I need to go back to working on homework and whatnot

  2. #2
    Join Date
    Dec 2009


    Excellent work. Thanks for this, krazer!

    It's good to know the lens and fan modules can be controlled quite easily outside of the PJ.

    From what I can tell of the Driver board protocol, it's standard serial (rs232) at 19200 baud, is this what you found?

    Is it just a case of sending back the same response packet all the time, or does it need a different packet at start-up, then different packets after each response?

    After a few seconds (Phlatlight on etc.), the projector seems to just send "0x03 0x01 0x04 0x3E 0x30" all the time.
    The response packet is then 16 bytes, like this...

    0x03, 0x0C, 0x57, 0x8E, 0x30, 0x00, 0x00, 0x1A, 0x0D, 0x1B, 0x0D, 0xD3, 0x0C, 0x77, 0x0E, 0x6F

    Only around 6 of these response bytes appear to change each time.
    I'm hoping they're temperature values, and maybe "current feedback" values as many of them seem to be increasing over time?

    Oooh, you've just given me an idea! Have you tried getting the Red Phlatlight working from the driver board on it's own using just the MSP430 and PSU?!

    I'm thinking that the CIDX pulse timing to an extra driver board could be "shifted" so the board could directly drive the Green Phlatlight!
    (ie. The duty-cycle of the Red LED is similar to the Green LED, the Blue LED might prove trickier though as it's only on for a short time.)

    I may have to go back to the idea of squeezing three driver boards into one projector so all three R/G/B LED's can be driven.

    Thanks again, this stuff is starting to look fun again!

    P.S. Do you think the colour wheel feedback loop could be slowed down in software?

    EDIT: Actually, I think I missed an important point - I forgot about the different ECO levels!
    It looks like this is sent to the Driver board when each ECO mode is selected...

    0x03, 0x02, 0xDD, 0xD1, 0x24, 0x06
    (driver responds by echoing this packet back to the PJ)

    0x03, 0x02, 0xCF, 0xF2, 0x24, 0x04
    (driver responds by echoing this packet back to the PJ)

    0x03, 0x02, 0xEB, 0xB4, 0x24, 0x00
    (driver responds by echoing this packet back to the PJ)

    The PJ then continues sending the same "0x03 0x01 0x04 0x3E 0x30" sequence to request the status (16-byte response).
    Last edited by OzOnE; 04-12-2012 at 19:30.
    "It's like lasing a stick of Dynamite."...
    Surely all PL members have seen this movie?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts