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.

Hardware

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.

Pictures:




Software


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.
 
Files:

Monday 4 November 2013

LED Matrix Display and Controller

Background

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.

Hardware

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.

Pictures:



Files:
 

Software

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.

Files:

Saturday 2 November 2013

Bell / Dish Network IR to UHF Pro

Abstract

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.

Introduction

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
TypeHD / SDSD
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

Solution


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.

Components:

  • 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


https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh3MQgvkCWA0aodufpKA4-ltYMjGqaHa6bbZ7Y18lptSyk7KXAv_vklUAIwIBVga5yuG7zz_QAmppcCTEcP5VDQnSXA_OZT2jWDh5vkwdO8qWjOcej9iL2JIm-5WOI-Xxbei059I0e65jq_/s400/block_diagram.png

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:

BitsValue
0-5Data
6-9Address
10-15Data

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.

UHF Pro

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
1TX_EN
2MOD_CTRL
3PLL_ON
4OSC_SEL
5DATA
6GND
7VIN
8PWR_EN

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

}

Hardware

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.

Files:

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.

Pictures:

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.

Files:

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.

Pictures:


Software


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)
IR ADDR 10 UHFPRO ADDR 11

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.

Files: