Saturday 21 February 2015

Sega Konami Justifier Hack: Convert Player 1 (Blue) Gun to Player 2 (Pink) Gun

For any of you that would like to play Sega games with two light guns, but can't find a second player (pink) Justifier, this post describes how to convert a player 1 (blue) gun to a player 2 gun.

Note: In order to complete this mod you must be able to solder.

Required Materials:

  • 6P6C Cable (Phone cable with 6 pins/conductors loaded)
  • Wire strippers
  • Soldering Iron
  • Solder
  • Screwdrivers (Phillips, Flat Head)


1. Unscrew all of the screws on the side of the gun and carefully pry open the two plastic halves. Be careful not to break the mating pins between the two sides. You may need to use a flat head screwdriver to help pry the two parts. Be careful not to lose the lens, it is critical and hard to replace.

2. Desolder the conductors to the controller PCB and remove the controller PCB and the black cable.

3. Assemble 6P6C cable, or save yourself some trouble and buy one already assembled. If the colours of your cable do not match mine, and they probably won’t, ignore the colour coding and just make sure that the correct pins are connected to each other.

4. Solder the wires as follows. Note that the pin numbers were assigned arbitrarily. Look at the photos for clarification.

5. Screw the gun back together. Plug the 6P6C connector into the Player 1 gun and enjoy.

6. (Optional) Cover the opening on the butt of the player 2 gun by gluing a small scrap piece of plastic into place. Alternatively, if you have access to a 3D printer, here is the model for a small cap that is easily installed and removed.

Download: STL File

Sunday 1 December 2013

Sony Alpha Remote Control

The goal of this project was to make a simple remote control for a Sony Alpha camera that is small enough to fit on a keychain. The only functionality required is the shutter.

IR Signal

The first step was to understand the IR protocol. Sony uses a standard protocol for all of their devices (SIRC), but without knowing the version (12/15/20-bit) used, the device address and the commands, it would be quite difficult to determine the correct code for the shutter. Luckily, the codes were posted on a forum in Pronto format.

The Pronto codes were then decoded to obtain the commands with help from the Pronto IR Format Manual.
0000    (wFmtID = Raw Oscillated Code)
0067    (wFrqDiv = 103 => 4MHz / 103 = 38.8 kHz)
0000    (nOnceSeq)
0015    (nRepeatSeq)

0060 0018 (Start Sequence)

Command (7-bit):
0030 0018 (bit = 1)
0018 0018 (bit = 0)
0030 0018 (bit = 1)
0030 0018 (bit = 1)
0018 0018 (bit = 0)
0030 0018 (bit = 1)
0018 0018 (bit = 0)

Device (5-bit):
0018 0018 (bit = 0)
0030 0018 (bit = 1)
0018 0018 (bit = 0)
0030 0018 (bit = 1)
0030 0018 (bit = 1)

Extended (8-bit):
0030 0018 (bit = 1)
0018 0018 (bit = 0)
0018 0018 (bit = 0)
0018 0018 (bit = 0)
0030 0018 (bit = 1)
0030 0018 (bit = 1)
0030 0018 (bit = 1)
0030 0018 (bit = 1)

0030 03f6 End of code???

SIRC uses T = 600 us timeslots, which corresponds to ~24 pulses at 38.8 kHz.

0018 = 24 = 1*T
0030 = 48 = 2*T
0060 = 96 = 4*T

The signal was constructed in MATLAB and then output on an arbitrary function generator (Instek AFG-2125) with an IR LED connected to its output. The command executed successully on a NEX 6.



In order to ensure a small board size, an ATTINY9 (SOT-23-6) was selected as the microcontroller. The microcontroller has two signal outputs: a carrier (~40 kHz) and a data signal. The carrier signal is generated by the system clock output (CLKO), therefore the device must be clocked at 40 kHz. This can be accomplished by dividing the internal oscillator and purposely detuning it by changing the oscillator calibration register. The signals are logically AND-ed in order to modulate the signal for transmission. Due to current output limitations of the microcontroller, an output driver is used to power the IR LED.

Tests were done with two transistors in series to AND the signals, but the VCE voltage was too high and the circuit only worked for supply voltages above 3V. The circuit provided uses a simple BJT transistor circuit to amplify the carrier signal to drive the LED. The data signal is configured as an open-collector output and drives the base low to disable the LED. While the output is disabled, the base resistor wastes power, but this was required to ensure operation at the voltage provided by the battery.



The data signal (not modulated) is generated by bit banging a GPIO. A timer could not be used because the time required to service an interrupt does leave enough time to process the signal. Instead, a loop was implemented that takes exactly 24 cycles. The code is written in assembly in order to precisely determine the number of cycles per loop iteration. Interrupts and sleep modes are not used during signal generation to elminate any code with unpredictable cycle counts, however the device does sleep between transmissions.



A keychain LED flashlight was used for the first prototype. The LED was replaced with an infrared LED and the circuit was dead bugged inside.

An enclosure was also designed that could easily be printed with a low cost 3D printer.


Tuesday 5 November 2013

Bicycle Wheel LED Display

This project consists of a line of RGB LEDs that are attached to the wheel of a bicycle. As the wheel rotates an image is drawn. When the speed of rotation is high enough an image can be seen.


A microcontroller samples accelerometer data to determine angular position and the rate of rotation in order to properly display the image. The image is drawn line by line to the LEDs using a series of shift registers. The board also contains an EEPROM which can be used for added storage.

Unfortunately, I lost the schematic and layout when my laptop died, but the circuit is quite simple and could easily be re-designed.



I finished this up this project in mid-June of 2011, so I decided to make a Canada day message. This program demonstrates how to display both text and images.

Monday 4 November 2013

LED Matrix Display and Controller


Every year the local Cub Scout pack has a Kub Kar race, where the children carve blocks of wood into cars of their own design and then race them. In order to help them identify which car passed the finish line first, I built them a detector using photointerrupters. Naturally, the winner needed to be displayed and I thought we could go all out and have an LED matrix display the winner.

Display Operation

In order to display an image, the LED matrix works by sweeping an image horizontally across the display; persistence of vision allows us to see the complete image. The controller contains a parallel bus that sets the on/off state of all of the LEDs in each row. Shift registers enable a single column at a time allowing the controller to illuminate each single column sequentially. The columns are drawn at a rate much higher than perceivable by the human eye, so we see the full image and do not see any sweeping or flicker.


This project consists of two board designs:
  • Display Module Board: This board consists of the shift registers and LED drivers needed to select which LEDs are illuminated. A standard 8 x 8 bi-colour LED module in soldered directly to this board. The board is designed to be able to connect multiple identical boards in series to extend the length of the display.
  • Controller Board: This board is the brains of the system and incorporates an Atmel XMEGA microcontroller. The extra muscle of the XMEGA was needed in order to make the control of the display completely hardware driven, leaving processing power to the display image generation and the main application.

The following is a block diagram describing the various signals and buses used to control the display.

The controller board includes circuitry for digital inputs/outputs, a speaker driver, LEDs and push buttons. Although not currently implemented, these circuits allow for the expansion of this system for features such as an automated car release mechanism, sound effects, and as an interface to other sensors and displays.

The Display Module board layout consists of a panel of 2 x 3 boards since most cheap PCB fabricators round charges based on specific board sizes. The boards can always be cut from the panel if needed. For convenience, the modules on the panel are electrically connected horizontally.




The software provided flashes between "READY!" and "PRET!" indicating that the system is ready for a race. When an edge is detected on one of the photointerrupter inputs the winner's colour ("RED" or "GREEN") is displayed. After a timeout, the system returns to ready.


Saturday 2 November 2013

Bell / Dish Network IR to UHF Pro


An IR to Dish UHF Pro converter was built in order to control a Dish compatible satellite receiver with a universal infrared remote control. This article documents the results of my experimentation with Dish UHF Pro and the Dish IR protocol. The objective of this document is to provide a working solution for people with a similar scenario as me and to provide information for those wishing to build similar projects.


The Problem

I have a TV in one room with a dual tuner satellite receiver. I would like to add a second TV in another room that can view either tuner. I would also like to control both tuners with a universal remote from the second room. The solution is not trivial since the first tuner must be controlled by IR and the second must be controlled by UHFPRO. Since a universal remote cannot natively send UHFPRO commands and IR signals cannot pass through walls, a custom solution must be developed.

Satellite Receiver Features:

Tuner 1Tuner 2
Video OutputsHDMI (Digital HD) Component (Analogue HD)Composite (Analogue SD, low quality, yellow/white/red cables) RF (Analogue SD, very low quality, coaxial cables)
Remote ControlIRUHFPRO

Note: This project is also useful if you have a single TV with your receiver in a separate room or in a cabinet.

Supported Receivers

The following is a list of receiver compatible with the UHFPRO remote used in this project. Compatibility with other UHFPRO devices is unknown. All testing was done on a Bell 9200 receiver.
  • Bell 3200, 5200, 6100, 9200, 9241, and 9242
  • Dish Network 381, 811, and 921


An active HDMI splitter will be used to distribute the first tuner output to both TVs. The second output will be wired directly to the second TV. If the second tuner signal is required on both TVs, a passive analogue splitter can be used.

In order to control the receiver from the remote room, some circuitry must be designed and built. The first board, in the remote room, shall receive infrared signals from a universal remote and retransmit the signal to the appropriate receiver. If a command to the first receiver is received, the board will convert the command to a 433 MHz ASK signal that will be received by a second board. This conversion is required in order to transmit through the walls. The second board, located near the satellite receiver, will receive the 433 MHz ASK signal and retransmit it over IR. If a command to the second receiver is received, the board will convert the command to a UHF Pro command.


  • Universal remote capable of emulating two remotes (purchased)
  • HDMI splitter (purchased)
  • Board 1 (built).
  • IR to UHF Pro
  • IR to 433 MHz ASK
  • Board 2 - 433 MHz ASK to IR (built).

Block Diagram

Dish IR

Note: All information in this document is from measurement and reverse engineering. Timing values are those measured, but the protocol may be tolerant of variations from this. Bit labelling is defined herein, and may not be standard with other sources.

The infrared signal used by the receiver is modulated on a carrier of ~57 kHz. When selecting the receiver be sure to choose one designed for this frequency. IR receivers tend to be quite tolerant of frequency mismatches of a few kHz, but don't expect to use a 38 kHz IR receiver you salvaged from something else.

The encoding used for the infrared communication is pulse length modulation (the length of the pulse indicates the bit value). The diagram below shows an example of a command. For the chosen IR receiver, the idle state is high. This document assumes this to be the case. If an alternate IR receiver is used where the idle state is low, the levels referred to in this document will be reversed. The encoding can be broken down in to time slices of t = 0.54 ms. A bit is identified by a low period of t (0.54 ms). The duration of the high portion following this determines the bit value. A duration of 3t (1.62 ms) indicates a '1', a duration of 5t (2.7 ms) indicates a '0'. The line must remain high for 11t (5.94 ms) between commands (or repeats of a command).

Data is transmitted in 16-bit messages, Least-Significant Bit first. The message format is as follows:


Decoded message: 0b0000001111000010 = 0x03C2 (LSB first)

A list of valid data values I have discovered can be found in DISH_COMMANDS.h in the source code.


In order to send UHF Pro commands to your receiver, you will need a transmitter module. The cheapest/easiest solution is to purchase a used UHF Pro compliant remote; you can find used ones at your local electronics surplus store or on eBay. I started with a Dish Networks IR/UHF PRO 8.0 Remote control, but I'm sure that any other Dish/Bell UHF Pro capable remote will be similar. The wireless transmitter is the smaller daughter board attached by a ribbon cable. Below is an image of the board removed from the remote.

(approx. 3.8 x 3.2 mm or 1.5" x 1.25")

Pin #Function

Interfacing to the UHFPro transmitter module is slightly more complicated than the infrared receiver. The module requires two (2) control lines as well as a data line. The format of the data is also more complicated in that it requires a start sequence, the command message and a hash of the data. The timing of the UHF Pro interface can be broken down to time slices of t=0.5ms.

Before sending a message, the module must first be enabled by raising the PWR_EN line. After 40*t (20 ms), the TX_EN line is raised to enable transmission of the message. After 10*t (5 ms), the data is then transmitted. Firstly, a fixed start sequence is transmitted. Following this is the message and hash, which are Manchester encoded. Once data transmission is complete, the module should be disabled by lowering the PWR_EN and TX_EN lines.

Start Sequence

Before any data is transmitted, the following sequence must be output on the data line starting 5 ms after the TX_EN line is pulled high:

1*t HIGH, 2*t LOW, 4*t HIGH, 2*t LOW, 4*t HIGH , 1*t LOW (0.5H, 1L, 2H, 1L, 2H, 0.5L ms)

The total duration of the start sequence is 14*t (7 ms).

Data Encoding (Manchester Code)

Each bit occupies two time slices (2*t = 1 ms). For the first time slice, the value of the data line is the inverse of the current bit, the second time slice is the value of the bit. For example, the transmission of the nibble 0b1011 is shown below (LSB first):

UHF Pro uses the same 16-bit message format as is used in the IR message as discussed above.

Hash Function

In order to validate that a received message was not corrupted during transmission, the UHF Pro transmission contains a 10-bit hash appended to the end of the message. The hash code is encoded using the same Manchester code as is used by the message. The algorithm to compute the hash seems to be a modification of a CRC function. I will not go in to the details of the hash function at this time, but will simply provide a function for computing it. Note that there may be a more efficient way to compute this (you can almost see a pattern in the hash keys), but this is what I figured out so far:

const uint16_t hash_keys[] = {139, 278, 556, 239, 478, 956, 975, 809, 

        741, 381, 0, 323, 0, 0, 0, 603};


uint16_t UHFPRO_hash( uint16_t input ){

        uint8_t i;

        uint16_t hash = 0;

        uint16_t current_bit = 1;             // Initialize bit mask

        for( i = 0; i < 16; i++ )             // Loop through all bits


               if( ( input & current_bit ) != 0)// If current bit is set

                       hash ^= hash_keys[i];  // XOR current hash with key

               current_bit <<= 1;             // Shift to next bit


        return hash;                          // Return computed hash



Universal Remote Control

I happened to use a Logitech Harmony remote since it works nicely to configure all of my home theatre devices, but since the IR protocol used throughout is the Dish Network protocol, any IR remote that works with your receiver may be used. In order to differentiate between commands for the first and second receiver, the remote must be programmable with 2 addresses or else two remotes must be used.

Board 1: IR to UHF Pro/433 MHz ASK Board

This board is the brain of the project. The board receives an IR command, identifies the address and then retransmits it over a 433 MHz RF signal or a UHF Pro signal depending on the address. This board should be placed in the room with the second TV.

Note: This board includes push-buttons and LEDs originally used for testing/debugging purposes, but are no longer required.


A DC wall adaptor of 7-15 volts is required to power board 1. I would recommend putting the board in an enclosure of some kind for protection (don’t forget to cut out a window for the IR receiver). The board must be placed in the remote room (the room without the receiver) with the infrared detector pointing in the general direction of where the remote will be used.


Board 2: 433 MHz ASK to IR Board

The second board takes the digital signal from a 433 MHz ASK receiver and retransmits it over 57 kHz IR.


A DC wall adaptor of 7-15 volts is also required to power board 2. I used a 4 x AAA battery holder as an enclosure, which worked nicely. The board must be placed in the room with the receiver with the infrared diode pointing at the receiver. You may need to play with the distance between the board and the receiver. I found that placing it too close didn't provide the best results.



The ATMEGA88 on Board 1 must be programmed with the .hex file supplied below. An AVR programmer can be purchased on eBay for ~$5-10.

The default remote addresses are as follows. If another address is needed, the software will need to be recompiled.

Input Output
IR ADDR 04 IR ADDR 04 (over 433 MHz ASK)

Note: The address values above (as in the code) are 1 higher than the number entered on the keypad of your remote when programming it.


Tuesday 17 September 2013

Switching Current Source

This circuit was designed and built to replace the linear current source I repviously designed. The linear design heated up quite a bit because of the power loss from the regulator and required a long warm-up time before the current stabalized. The new design uses a buck converter to reduce power loss and therefore reduce the heat produced. Of course, any design with a switching supply will have some switching noise, but this can be reduced by using a large output capacitor.

Note: I did not layout a PCB for this design; instead it was constructed on a proto-board.


Sunday 1 April 2012

AVR Xplain (ATxmega128A1) IR Transmitter (PC Remote)

This circuit is used to test a usb IR "PC Remote" receiver available on eBay. The USB-Serial bridge is used to communicate with the ATxmega128A1 with the custom firmware provided below. Bytes received over serial are retransmitted over IR. Alternatively, commands may be selected by pressing SW0-SW6 and then sent by pressing the SW7.

The IR transmitter circuit is simply an IR LED with a 180 Ohm resistor in series. This is fine for testing purposes, but the range is not great. A transmitter circuit can be added to increase the range of the signal.

  • Source code (.zip)