Close
0%
0%

Lexitron RSS Reader

A self contained remote display system provides notification and display of feeds, weather reports, email, messages and of course, a clock.

Similar projects worth following
Fellow hackers, allow me to present my most cherished project. Like many of you, I do not have time to keep up with the news. I spend my free hours on code and wires. Surely they could provide a solution? For headline news, RSS is perfect, but keeping up with many feeds becomes a daily chore. I wanted RSS presented to me like what rolls past under the presenter of breaking updates on a display, large and clear to hang on the wall.

We have all seen hardware RSS readers, but perhaps not like this. I determined to dig into the junk box and build a complete, stand-alone system from scrap. It is a true hack, a hand crafted, one-off crazy tangle of wires and leftover chips running open source software. A strange, quirky and unique system, fully connected and currently keeping me up to date with all the breaking news and other important events.

The Lexitron system has two physical parts. The first is a LAN-connected base station I call the TickerNut that is a small, ultra low power embedded webserver running custom firmware to gather information and communicate it to the remote display (the Lexitron) through a remote radio modem link. The decision to have it in two parts was to keep the display itself small and lightweight yet fully capable with a minimum of connections and to give me a chance to play with RF data transfer.

What does it do?

  • RSS Reader

The Lexitron shows new RSS items as breaking headlines as they arrive. Any practical number of different feeds are supported, each with it's own icon and notification sound. Items can be filtered by category, browsed and reviewed on demand using the IR remote control.

  • Weather forecast

The Lexitron displays the local weather forecast as a popup from time to time, and updates weather data from the Bureau at specific times accompanied by a more detailed report.

  • Email gateway

The Tickernut has it's own email address to which short messages can be sent. These are displayed on the Lexitron with a trumpeting alert as they arrive.

  • XBMC Client

The Tickernut can control our entertainment system from the IR remote and the Lexitron shows what's currently playing as it comes on.

  • Mail check

The Lexitron lets me know when I have new mail.

  • Clock

Of course, the clock. With alarms, chimes, network updated for accuracy.

There are other more mundane activities (like user message)

Configuration:

The heart of the system is a software activity sequencer on the Tickernut that reads a list of activities from an XML file on the SD card and performs the activities as needed. An activity can be any of the above examples or a user activity.

An embedded web interface allows configuration and interaction with the Tickernut. It can list and modify activities, browse onboard files, show settings and performance statistics and control the Lexitron directly.

A Windows application written in C# called Nutboot provides lower level interaction with the Tickernut. As well as being able to test and program both devices over the network, Nutboot has a log server and a CLI for the Tickernut and a pixel and icon editor for the Lexitron. It can also use the Tickernut's radio to scan the 2.4GHz band to look for free channels.

The Tickernut:

Tickernut is based on Ethernut, an Open Source implementation of a Embedded Operating System called Nut/OS and a TCP/IP protocol suite named Nut/Net. This is running on custom hardware, home brewed from mostly second hand parts.

TickerNut uses radio communication to control the Lexitron to provide short text messages and notifications. Information and updates are gathered through an ethernet connection to the local network which provides Internet accessibility. An onboard SD card interface provides local file storage. Audio output from the TickerNut speaker can produce alert sounds from WAV files. An infrared receiver can decode messages from most common remote controls.

The secret of how the system copes with documents bigger than it's own physical memory is an XML parser able to selectively extract information of interest from big XML documents and capable of dealing with and removing the vagaries of web formatting. This module reads just about any large RSS feed without using more than about 8k of physical RAM.

The TickerNut has several hardware peripherals additional to the Ethernut reference design. This includes PWM audio, infrared remote, nRF24L01 radio communication and hardware health monitors.

Tickernut Specifications:

CPUATmega2561 @ 18.432Mhz
OSEthernut NUT/OS 4.10.1.1
NetworkRTL8019S, 10Mbit.
Memory256K Flash, 40K RAM, 4K EEPROM
RadionRF24L01+, 2Mbps
StorageSD Card, up to 2MB, FAT32
Audio8-bit, 11.025Khz playback, LM386 audio amplifier.
ProtocolsHTTP 1.1 Server - Web access for control and configuration.
FTP Server - Full remote SD card access.
Telnet Server - Low-level configuration and debugging.
WINS Client - For Windows...
Read more »

  • 1
    Step 1

    Warning: hacker construction project

    If you are interested in making something like this, be warned. This project is a total hack job and will not run on any out-of-the-box hardware I am aware of. Development boards are available, but would require modification or additional peripherals to be a Tickernut clone. Possibilities include the Ethernut 2.1 or maybe the smaller MMnet01, either of which would need a CPU upgrade to an ATmega2561.

    Thanks to the portable nature of Ethernut, the Ethernut 3 or 5 boards with ARM CPUs are probably a better choice and should only require minor code changes. The rapid prototyper would probably be best served by a Raspberry Pi running a subset of the application code, whereas the AVR fan might consider an Arduino Mega with a RAM expansion and an ENC28j60. At the end of the day, the hardware is not important.

    I built mine on protoyping board following the Ethernut 1.3g reference design. At the start I was not sure if the design would prove capable enough, and as it turned out, it wasn't. Upgrades during development included the addition of an SD card, a move from the ATmega128 to an ATmega2561, altering the address decoding to make a full 40K RAM available rather than 32K and changing 434Mhz radio modules for the 2.4Ghz nRF24L01+. Even then it took a lot of trickery, training and some sleight-of-hand to make it do as it's told.

    I was inspired to this approach when I came across this device, demonstrating to me that connected computers could be hand made from junk and wires. I was mightily impressed by the home brewing resourcefulness of this creation and resolved immediately to follow in kind.

    For the display I had nothing to suit my desires, so the cheapest, most cheerful LED arrays were sourced and purchased from China. Wiring them together in a useful fashion was the single hardest task of this build.

    All up it has been a challenge that pushed the boundaries of my abilities and has brought me both great elation and deep despair. I now have invested so much effort and time into seeing this mad device work I would be heartbroken were it to fail beyond repair, which on several occasions it seemed to me was precisely what had happened.

    But despite all the setbacks and obstacles the system now works reliably well. We here are now right up to date with all the latest.

  • 2
    Step 2

    Lexitron circuit design and hardware:

    LED display:
    The display is constructed using Red 8x8 square LED matrix displays, each containing 64 LEDs wired in a square grid with the 16 column and row pins available out the base. It is designed to be used in a multiplexed mode, with just eight or less LEDs illuminated at once in a row or column that is only energised briefly as the whole array is swept through quickly like a raster.

    In this design each display module gets it's own column driver to act as a current source allowing the row connections to be shared along all the display modules into a single set of current sink mosfets.

    The display control circuit is a multiplexed column design using cascaded shift registers. The layout is organised into 8x8 cells, each with their own shift register. In each cell the data in the shift register energises the rows while the chosen columns of all cells are parallelled together to be selected by 1 of 8 mosfets. This design requires one chip, one capacitor and eight resistors with each 64-LED display module, and one set of eight power mosfets with gate resistors for the whole display.

    This diagram shows the layout of a single display cell. There are 20 of these, the output of one feeding to the input of the next. Besides power consumption there appears to be little practical limit on the number of these cells that could be cascaded. Not shown is the eight 470R current limiting resistors in series with the row drive connections. Also not shown is a later modification to remove a faint background illumination where the Latch Clock was brought out and series connected like the existing Shift Clock for sharper control.

    Current consumption of the whole display is potentially quite substantial, even with each LED drawing only 10mA turning every LED on at once would require nearly 13 amps and throw more lumens than a car headlamp! The power supply in the display is only rated at 2A continuous, 3A surge. For this reason, and the fact that the shift registers would be seriously overloaded, it is important that only one column of each array be energised at any one time giving a potential maximum draw of 1.6 amps which remains well within ratings. In practice, the current limiting of the supply regulator I used prevents any issue arising from accidental overloads.

    Displaying text has a much lower consumption, on average less than half of the maximum current draw, allowing one to use a relatively small heatsink for the supply regulator. In practice the regulator barely gets warm for normal scrolling text display.

    If the power consumption limit is very badly exceeded the regulator's output voltage slumps as it's current limiting protection circuit kicks in. This reduces the microcontroller's supply rail causing it to brown out and release the column drive. This appears to provide crude but effective protection against software glitches, code errors and other accidents.

    Radio Communication:

    The transceiver is based around inexpensive modules on the 2.4 Ghz band. These modules use the nRF24L01+ chip designed for low power, short range applications like wireless keyboards and mice. They have a host of features like multiple endpoints and auto-ack, most of which I do not use.

    This module connects to the microcontroller using the USART, configured for SPI bus mode. It listens for packets from the Tickernut and responds with ACK or data to every one. The link layer includes packet sequencing and automatic retries for a more robust connection.

    Power supply:

    The 5 volt power supply built into the display is using components recycled from an early ink-jet printer IIRC. It is based around a very large integrated regulator, the STR2105. This chip is deprecated, new designs would be better using a more modern IC like the LM2575-5.0 or similar.

    The STR2105 is a 5 volt switch-mode design and requires only an external inductor and capacitors to work but adding trimpot VR1 allows precise output voltage trimming. Despite the size of the device the specifications are quite modest at 2 amps continuous, 3 amps surge. The advantage of such a large package is it has lots of thermal dissipation allowing for a relatively small heatsink in this application.

    The external power supply has been borrowed from a very early Toshiba laptop (T1200?) and has an output of 12 volts at 2.2 amps. It is being used without modification and may be returned to the vintage laptop if a suitable substitute is later found.

    Display microcontroller connections:

    An Atmel ATmega8 was initially chosen for the display mainly because there was one on hand and it fulfills the requirements of being physically small, possessing a hardware SPI interface and supporting a bootloader. This was later upgraded to an ATmega328p for more resources and a second SPI interface.

    The SPI interface is well suited to shift data into the shift register chain as it can do this many times faster than bit-banging the serial data out in software and also saves the small amount of code that would be required for this.

    The clock source is a 14.31818 MHz crystal, initially chosen to match the Tickernut base station in order to eliminate baud rate errors. Even though this is not a standard baud rate crystal the display and base station's baud rates were the same. With the upgrade to nRF24L01+ modules, this was no longer a requirement and the Tickernut has since been given an 18.432 MHz crystal for improved processing speed.

    Due to the use of switch mode power supplies and lots of heavy current switching, extensive decoupling on the supply lines is used throughout the circuit and especially around the microcontroller to ensure the noisy 5 volt supply does not interfere with normal operation.

    The awkward choice of column drive connections was mainly dictated by how the veroboard layout evolved. If it had been possible to assign all eight columns to a single port more effort would have been made but as all ports had some pins already in use for their alternate functions it was necessary to share the columns between two ports. This being the case, the bit order became much less important as the column control routine needed to be bit-oriented rather than byte-oriented anyway.

    More to come..

  • 3
    Step 3

    Tickernut circuit design and hardware:

    Enclosure:

    The motherboard is shaped to fit tightly inside a standard ABS jiffy box which set its limited size. The box has cutouts to expose all motherboard connectors on the left side and a small speaker and antenna has mountings on top.

    The front panel is drilled to accommodate switches and LEDs with a cutout above having a bezel with a transparent window for the alphanumeric LCD. Above that, a window for the infrared remote receiver is covered with tinted perspex.

    The motherboard:

    The Tickernut's main board is constructed using phenolic prototyping spot board. The processor, memory and all peripherals other than the front panel controls are mounted on this board. The core of the design is based on Egnite's Ethernut reference design v1.3 rev. G and initially used the same major components, an ATmega128 processor, 32k static ram and RTL8019 network interface. These were arranged into the same memory map as the Ethernut design allowing the firmware to run unmodified.

    Peripherals located on the motherboard include the memory card, radio modem, audio amplifier, RS232 interface, in-circuit programmer, brown-out monitor, real time clock and power supplies. Much of the circuit wiring is point to point between solder stakes and to keep the wires neat they have been laced together into a loom.

    Processor:

    The first processor used was an ATmega128, then one of the higher end devices in Atmel's AVR microcontroller range. It is a great chip, one of my favourite 8-bit microcontrollers. It has 128k of program flash, 4k of static ram, handfuls of on-chip peripherals and is only available in a 64-pin surface mount package.

    The processor was mounted on a hand made breakout board that provides standard spacing between pins to allow the whole unit to socket straight into the motherboard.

    Most of the processor's support components including the system clock crystal, 32k real time clock crystal, DS1233 brownout monitor, analog supply and decoupling are mounted on the motherboard inside the area used by the processor socket leaving the area around the outside of the socket free for peripheral connections.

    The system was initially clocked at 14.31818 Mhz. This clock speed was chosen as it is an easily obtainable crystal and proved close enough to the Ethernut's original specification of 14.7456 to allow serial communication to work without firmware changes. This proved very handy during initial testing.

    Memory Module:

    The memory module consists of a 74als573 octal buffer and 32K of static RAM on a small scrap of prototyping spot board with a large connector that sockets vertically into the motherboard.

    The separate module was constructed to hold the memory because I ran out of space when planning the layout and couldn't find an arrangement that would easily allow the memory chips to be mounted directly on the overcrowded motherboard.

    The memory module sits on the processor's external memory bus and functions independently of all other peripherals. It exposes the demultiplexed address and data bus lines from the processor for use by the network module. The memory module is positioned close to the processor and the physical connections are short enough not to require wait states.

    Network Interface Controller:

    The network interface module is a Realtek RTL8019 NIC chip on a small carrier board with a crystal, network transceiver and RJ45 connector. This module interfaces power, interrupts, address and data bus through two 20-pin connectors. The network module requires address and data signals from the memory module and will not function if the memory module is not present.

    The network module as I obtained it was wired to only provide the low 5 bits of the address bus but it had many spare pins on the connectors. To avoid extra decoding hardware or unsightly software hacks the network module was modified to make the remaining 11 address bits and 3 status LED signals as well as another reset signal available through the spare pins.

    A 74hc00 quad NAND on the motherboard matches the network module's signals to suit the system bus. It is wired as inverters, one on the A15 line to map the NIC's registers directly above the 32K memory space while another corrects the sense of the NIC's interrupt signal before it is fed into the processor's INT5 pin. A third inverter flips the motherboard's active low reset signal to suit the NIC's reset requirements. (Note - this section of the circuitry was later completely rewired to provide the full 40K of RAM, more details later.)

    Radio communication:

    Originally, the transceiver was based around separate inexpensive transmitter and receiver modules on the 434MHz LIPD band. According to their datasheet they were originally designed for garage door openers. These proved to be poorly suited to the job. Communication was so slow and error prone as to be practically useless.

    The transmitter's modulation method is simple on-off keying (OOK), These modules were rated to max out at 5000 bps and seem to work best at 2400 baud. After adding protocol overhead this halves to 1200 baud. The receiver uses a simple circuit known as a bit slicer to recover the serial data stream. This allows the modules to be connected directly to the microcontroller's second USART, RxD and TxD lines. I got them to work in the end but was not happy with their performance at all.

    A major update to the design introduced nRF24L01+ radio modules to the system. These proved far more successful and are able to provide an effective, robust communication link. These connect using an SPI interface, which became available when the CPU was upgraded to the ATmega328p with a USART capable of SPI.

    Audio Amplifier:

     The audio system is driven by a pulse width modulated signal from the microcontroller's second timer on OC1B (PB6). The modulation frequency is high enough to not require filtering. The PWM is ac coupled through a volume attenuator before being fed to an LM386 audio power amplifier. The output of the amplifier is stabilized by a Zobel network and is made available to the speaker through a connector on the motherboard.

    The power supply for the audio amplifier is somewhat choked by heavy decoupling and is below the LM386's minimum operating voltage specification of six volts. For these reasons the audio output clips sometimes and could hardly be described as hi-fi.

    Fortunately the TickerNut's enclosure with the mylar squeaker baffled in the top turns out to be an effective resonator and the squeaker does not need to be driven full blast to be heard loud and shrill. This allows the underpowered amplifier to be driven at a level it can easily sustain. Announcements and speech are clear and legible and easily loud enough to require a volume control.

    In the original design, interference issues meant the amplifier could not produce sound while the radio modem was in operation. After the upgrade and with better audio drivers the system is now virtually noiseless all the time and sound is pretty much seamless without clicks or pops.

    Brownout Monitor:

    The main 5 volt supply rail is monitored by a DS1233 Econoreset. This chip is conveniently packaged in a TO-92 enclosure with just three pins which made it a simple matter to connect it to the circuit inside the processor socket area. The DS1233 watches for sags in the supply rail and activates the reset line when a brownout is detected. It also debounces the reset button which is located on the front panel.

    The microcontroller includes it's own brownout detection circuitry but having the external monitor ensures the network module is always in a known state when the processor comes out of reset.

    ISP programming port:

    The processor's in circuit programmer is accessible through the serial RxD and TxD lines in combination with the SPI clock and system reset line. These four signals are made available along with earth and jumpered power over the 6-pin Atmel ISP socket which is exposed through a cutout in the case. Another jumper isolates the on-board power supply allowing device powered and device powering programmers to be selected.

    The microcontroller's ISP shares it's serial communication pins with the first RS232 port. To prevent the RxD output of the serial line receiver from interfering with the programmer's MISO signal it is coupled to the shared RxD line through a 4.7k resistor. This allows the serial port to function normally until a programmer is connected. The programmer can easily override the weak serial signal and control the processor without trouble although anything connected to the serial port gets bombarded with nonsense during programming.

    Serial Port:

    The RS232 communication is used for debugging. In Nut/OS it has been assigned to stdout and stderr making it the default output device for the stdio library.

    The first USART on the microcontroller is level translated through a MAX232 serial line driver and brought out a 9-pin D-sub connector. the CTS and RTS handshake signals are also routed from the MAX232 to the connector but are not connected to pins on the microcontroller as they are not currently needed.

    Front panel control board:

    The only circuitry in the Tickernut not on the motherboard is on the front panel control board. Peripherals on this board include the alphanumeric LCD display, infrared receiver, bi-colour status LED, network status LEDs, reset button and power switch. 

    The front panel is connected to the motherboard by a shaped 20-conductor connector socketed at both ends. The control board is held to the front board by the nuts on the two switches.

    LCD display:

    The backlit alphanumeric LCD display is used for reporting device status and debugging. It is a standard Hitachi HD44780 compatible unit with green LED backlighting. The LCD is connected directly to the microcontroller with the 4-bit bus DB4-DB7 going to PD4-PD7 and RS and Enable going to PE2 and PE3.

    To save microcontroller port pins the read/write signal from the display is not utilised. This means the processor can only write data to the display. The LCD device driver provided with NutOS allows for this and works perfectly through just six connections to the LCD.

    The LED backlight is powered through a current limiting resistor and is permanently wired on. There is provision in the loom for backlight control but this feature was considered low priority and the switching circuit is yet to be installed. Now, as the system currently stands I have no free pins. Isn't that always the way?

    Infrared receiver:

    The infrared remote control reciever is based on an integrated reciever module scavenged from a satellite decoder set top box. It is positioned on the control board so it peeks through a window in the front panel when the control board is mounted. Powered with a well-decoupled supply, it delivers it's demodulated output directly to the INT4 pin PE4 on the microcontroller where it is decoded in software.

    The decoding routine implements the NEC infrared protocol rather than the more frequently implemented Phillips RC5. In my experience the NEC protocol is more commonly used on modern consumer devices. During testing more than half of a random selection of a dozen junk box remotes were found to use NEC's standard including the one remote that was close to ideal for use with the Tickernut.

    System status LED:

    The overall status of the TikerNut can be determined at a glance by checking the bi-color status LED. This is connected to the microcontroller pins PE6 and PE7 through two current limiting resistors. 

    The pins are energised using pulse width modulation allowing the brightness and color of the status LED to be easily set from green through orange to red.

    In normal operation the LED presents a pulsing heartbeat to show the system is alive. The pulses are green to indicate good health while other colors indicate problem states. Current status reports have LAN connectivity issues pulsing orange and radio connectivity issues pulsing red. The LED also briefly blinks red on infrared remote reception and blinks yellow during SD card access.

    Network status LEDs:

    The three original network status LEDs proved quite handy, showing link status and network activity. Originally they were mounted directly on the network module and would have been obscured within the case. 

    To make the LEDs visible they have been repositioned to the front panel and the status signals have been routed from the network module to the control board.

    Power supply:

    The internal power supply produces and regulates the main 5 volt rail which supplies power to all of the components throughout the system.  

    The input to the supply is designed to suit a wide range of low voltage adapters and it can use either AC or DC between 7 and 15 volts with at least 500 milliamps.

    A supply fuse is mounted on the motherboard to protect against possible fire hazards. It is first to receive the supply voltage after it returns from the front panel power switch. A bridge rectifier then sorts out supply polarities and connects negative to ground. Supply positive is fed via a reservoir capacitor to a 7805 linear regulator on a small heatsink. The output of the regulator connects via another reservoir capacitor through the supply isolating jumper before feeding the main 5 volt rail.

    Additional to the original design is the addition of an LM35 temperature sensor to monitor the heatsink and voltage dividers to monitor voltages before and after the 7805 regulator. These monitors feed their analog outputs to ADC inputs 0, 1 and 2 on the CPU and are sampled a few times a second to check for out-of-range conditions and can shut down the Tickernut to try and prevent damage. I felt this could prove wise given the brutally hot summers we have been having in Australia.

View all 5 instructions

Enjoy this project?

Share

Discussions

mohaned sonier wrote 05/25/2016 at 11:38 point

thanks for sharing this.

mobiles

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates