Hacking an Infoglobe - part 4

The next step, after the  necessary frequency generation and 38 kHz burst management, is to actually be able to send a message, following the specifications defined before.
Basically the next step is to sending out  a buffer (max. 40 bytes) using the 38 kHz burst to send the zero bits, with a 1 ms bit time.

Hardware
The purpose of the second prototype, is to develop a code capable to send messages to the rotating arm of the Infoglobe, driving the Infrared LED.

Because the memory capacity of this specific micro-controller, will not be possible to install a code to handle the Zig-Bee protocol, unless to use a complete external ZigBee module, like the ones MaxStream.

The second prototype is developed in two steps :

1. send a message to the rotating arm pressing a pushbutton
2. send a message to the rotating arm, received from a RS232 input 

The specific micro-controller used ( an MSP430F2012) has an internal USART capable to handle an SPI or I2C connection, but NOT a RS232 UART.
So in order to receive an RS232 message, a soft-UART is  developed, using a standard I/O Pin.

Here a basic schematic for the the second prototype

A quick explanation of the circuit.
The transistor enable or disable the signal from the base to the IR.
The two diodes basically forms an OR, mixing the two signals directed to the rotating arm.
One from the base (that can be disabled) and one from the micro.
In theory is possible to leave on  the base generator and send a message from the micro, however since we can not control the messages generated by the base, is possible to end up with some conflicts, obtaining only garbled messages.

The correct sequence to use is to prevent the messages generated by the base to reach the IR diode, and then send out the message from the micro.
As long the messages generated by the base are disabled, the rotating arm will display the last received message.

The RS232 section is optoisolated in order to protect the PC from possible spark from the Infoglobe, that it can be connected to the phone line (it is a caller ID).
The pushbutton allows to select different options or for test purposes.

List of the needed material/tools for the experiment :

• modified Infoglobe(see previous articles)
• USB development system for the MSP430F2012
• C cross compilator for MSP430 - IAR (with the USB spi-by-wire development system)
• cad Eagle to draw schematics

Electronic components (see schematic)

• micro MSP430F2012 (on the development kit PCB)
• male connector DIL 2.54 7+7
• female connector DIL 2.54 7+7
• PCB RJ11 connector
• 3 3k3 Ohm resistors
• 3 10k Ohm resistors
• 1 4k7 Ohm resistors
• 1 2k7 Ohm resistors
• 2 power supply regulator capacitors
• 1 power supply regulator 3.3 V Lm1117
• 1 10uF tantalium capacitor
• 1 optoisolator 4n35
• 1 transistor NPN
• 3 1n4148 diodes
• 1 pushbutton
• breadboard

There are many ways to connect the micro to the development system.
I prepared a flat cable that brings out the micro pins to a standard DIL plug.

First test circuit - breadboard

Connect the 7+7 male Dil connector to the microcontroller PCB, so to be able to have it connected to the test circuit (maybe using a cable to have it on a breadboard).
The 14 pins are basically in parallel to the micro-controller pins, so for prototyping is perfect.

On the experimental board, put the female 7+7 DIL, that will be used to connect the micro and the RJ11 outlet, connected to a cable to the Infoglobe, the power supply regulator, to bring down to 3.3 V the 5V coming from the Infoglobe.

Important Note.
Before to connect the micro-controller PCB to the test circuit, be sure to REMOVE the SMD resistor R1 from the micro-controller PCB.
In this way the micro-controller will be powered from the P1 pin instead the USB development system.

Software

Here the flow chart of the state machine to be included in the timer interrupt management.
This state machine will be called every millisecond and if something will be present in the buffer, will be sent.
The fetch part of the code will run in the main loop.

I made some measurement using the pin 1.0, the one connected to the LED put on the microcontroller PCB.
Here some time execution in the interrupt :

• ~1.4 uSec in IDLE
• ~3.8 uSec in START/SEND (sending bit)
• ~6.8 uSec in SEND (loading character/test)

I also included in the code a couple of defines, to create a test environment, capable to only generate the 38 kHz burst, for fine tuning.
Simply uncommenting one of the two defines CALL_MODE0 or CALL_MODE1 (not together at the same time) and compiling the code, the basic frequencies will be generated constantly, so to be able to measure and tune the timer.

In this way there is no need to switch back on the initial test code.

(note, I'm still deciding if/where/how/when to create a public repository for my code. For the moment if somebody wants the code, just write me)