Motor driven valves Radio
[ Cliccare quì per la versione in Italiano ]

This project born with the intent to participate with an original idea to the 2nd edition of the "Turn on your solder" competition at Piana delle Orme premises, near Latina (Italy) that will occur in March 2017.

A friend brought me an old tube radio, with no more defined brand and model marked on. Anyway it works very well, giving an excellent sound performances both in AM and FM bands. My idea was just to give to this retro-tech object some modern aspects. So, I decided to add two motors to the Volume and Tuning axes, and to manage them with a common TV infrared remote command. Finally I needed to send five different commands to the equipment: Tune+, Tune-, Volume+, Volume-, and Power. The last one to remotely turn on and off the Radio. The other four to move the wheels forward and backward around their axes. The tuning was not much difficult: I just removed the plastic wire connecting the existing wheel to the knob, then I reused the original wheel placing a motor beside. For the volume, I had to add to the knob a new wheel. I asked to another friend to build me a wheel of 6 cm, using a 3D printer. Once attached the wheel to the rear side of the knob, I added another motor near it. At this point, the circuit project begun.

Since I like to face a problem from beginning, I just take some hints from the web, then I studied the most commonly adopted protocol for remote commands: the NEC protocol. Then I ordered a DRV8835 motor driver from the web, as well as other components. The motors was two [ MODELLO DA INSERIRE ] that I already bought one year ago for another project, that I postponed. The mechanic parts procurement taken me a few other days, visiting various shops.

NEC Remote Commands protocol

Hereafter a summary of the NEC protocol used by the most of common consumer remote commands.

The web has plenty of information about the NEC protocol. As matter of example: 

http://www.circuitvalley.com/2013/09/nec-protocol-ir-infrared-remote-control.html

https://techdocs.altium.com/display/FPGA/NEC+Infrared+Transmission+Protocol

The following diagrams depict the de-modulated flow coming from the output pin of a receiver module (like TSOP1738) submitted to the incoming infrared raw transmission.

The above flow summarizes the global flow. The Message packet is detailed hereafter:

The initial Leading pulse duration establishes the unity of each following pulse or space. We have to consider 16 unities in the 9ms leading pulse. So each “Tick” will have 9/16=0.5625 ms duration.

Once the transmission completes, after 67.5ms (+ one End pulse of one Tick to close the last bit), a series of “Repeat” commands may arrive, to communicate that the remote command key is still under pressure.

The transmitted contents

Each transmission is composed of one MESSAGE plus a number of REPEAT frames. Both MESSAGE and REPEAT frames have a fixed total length of 108ms. During the not used portion of each interval the Low level is maintained.

The following rules represents simple pulses as High or Low and their number of Ticks. As example H9 means a High pulse during 9 Ticks. The bold words are complex structures composed of simple pulses and/or other complex structures:

MESSAGE = H16 + L8 + BYTE1 + BYTE2 + BYTE3 + BYTE4 + H1

BYTE = BIT0 + BIT1 + … + BIT7 (where BIT0 comes first as LSB)

BIT of type “0” = H1 + L1

BIT of type “1” = H1 + L3

REPEAT = H16 + L4 + H1

Contents of the collected BYTEs:

Due to re-transmission of the same byte as one-complement, both for Address and Command, there are always a fixed number of 8 bits of type “0” and 8 of type “1”. As result, the MESSAGE frame has always the same length of 67.5 ms that is 120 Ticks, plus a One-Tick High state of End Frame pulse. Moreover, this technique improves the transmission reliability.

The two collected Address and Command bytes indicate the pressed key, and they are specific per each remote command brand and model. So that, it will be necessary a first Learning phase to assign a function to the desired key. This phase has to be repeated when a new model of remote command will replace the learnt one.

The management Automat

The microcontroller receives the signal from the connected Infrared Receiver module. After a proper setup, it will possible to treat each level change (from Hi to Lo or vice versa) by means of the Interrupt-on-change (IOC) function of the adopted mcu. A finite state automat, called when an IOC Interrupt occurs, interprets the level changes. Any unforeseen condition will reset the state to “Stand-By”. At the end of all the states actions, the tic counter is always reset to zero, so that it will represent the duration of the previous signal level.

A Timer updates a global variable through the interrupts it generates, in order to supply a precise time reference. The resolution of that reference is 0.2 milliseconds. The Automat will reset the timer once a Message or Repeat is treated. In case of Timeout, over 120 ms, the Automat will reset to the initial “Stand-By” state.

IOC Interrupt management:

120 ms timeout management:

Reset Collection: This function will zeroes the number of collected Bits and Bytes, and sets to False the EndMsg flag. It also resets the output in order to stop any motion.

Handle the collected command: This function elaborates the collected Bytes, managing their contents in order to set the desired output or, when the Learn phase is running, to register the chosen keys. The output Leds are turned on to signal the learning progress, without to activate the motors. We use this state to signal that the circuit is in learning state. The command contents is not reset after usage, in order to treat any possible Repeat case. Sending for more than 5 s the same key stream to the circuit, the mcu will learn that code and starts a Learning session memorizing the received command as the “Power” command. The user shall then choose in sequence the “Tune –”, “Tune +”, “Volume –“, “Volume +” keys to record in the mcu memory. The output Led(s) will be cleared once the whole learning phase is complete.

Collect a bit: The “0” or “1” bit is collected in the current Byte, updating the current Bit counter. When the Bit counter overflows, the current Byte counter is increased. When that last counter overflows, the EndMsg flag is turned to True.

Simulations

Some FreeBasic programs aided me during algorithm tuning. Hereafter a screenshot showing the correct treatment of several frames and Repeat pulses. The white pulses simulates the signal. The red vertical blocks depicts the timeout interrupts. The thin vertical coloured lines correspond to the IOC interrupts.

I also launched a simulation session introducing a random error in pulses duration, evaluating the capability of the interpreter to correctly detect the sent Address and Command codes. Varying the tolerance adopted during the pulses length matching, I established that the best performances are obtained setting this tolerance to a value of 0.6 ms.

The way the pulses are organised explains why the tolerance can be longer than the minimum pulse duration: we could have 1 or 16 Ticks of 0.5625 ms for the High state duration, while the Low state can have 1, 3, 4 or 8 Ticks length. The only ambiguity between 3 or 4 Ticks is solved by the specific state reached by the Automat once it detects the leading pulse and space since, in the state it enters, the only allowed space has now a 3 Ticks length (in a “1” bit case). A similar consideration can be assumed for the Repeat frame.

In another simulation session, I established a fixed MCU time slice to emulate a physical microcontroller, which temporizes the events by incrementing a variable each Time Slice supplied by the interrupt generated by a Timer. In order to minimize the effort of the MCU I searched the maximum time slice usable without affecting too much the performances of the received pulses interpreter algorithm. I found a good value for Time Slice near 0.2 ms. Trespassing of a limit of 120 ms the function will stop any motion, and will call the Reset Collection function.

At this time I migrated the simulation code to MikroC in order to program the MCU, making it able to manage the infrared protocol and to produce the wanted output to drive the motors.

The circuit design

Since just a few commands were needed, I adopted a PIC12F638 to manage the protocol. There are no many other components added around: as motor driver I used a DRV8835 break-out mini board, requiring 4 wires to move two motors in both directions, and two distinct power supply: 11 volts for motors, and 5 volt for logic. I created a separate power supply module, to generate both the voltages. In the same board I added the Relays used to power on-off the Radio.

Main board

The PCB layout foreseen to mount part of the components on the copper side, as shown by the pictures. Print the B/W version to create the master. 

Hereafter some pictures to show the components mounting. Notice the IR receiver with its twisted pins: unfortunatly there is not a precise standard about pinout. So when I "burned" the first one, I had to take a different one, with another pinout! ...But you can easily arrange it on the component side of your board.

Power board

Here some other pictures

An artiscic arrangement

The Radio has  been put into a wood and glass container. The remote command has been hidden into a raw wooden box, with retro-lighted tubes giving it a scenographic aspect.

CLICK HERE TO SEE A VIDEO

On board firmware