Skip navigation
1 2 Previous Next

Upcycle It

16 Posts authored by: Andy Clark (Workshopshed) Top Member

As mentioned in the Furby Hacking post the Furby is powered with a motor and cam system with different actions at different points in the rotation. The position of the cams is determined by a simple spring switch that is closed once per revolution. Then the relative position is determined using an optical sensor consisting of an LED, phototransistor and some buffers. So to control all this from the Edison I need to provide power to the 74HC14 chip, turn on the LED, monitor the gear position sensor and drive the motor.


Furby Control Schematic


Board modifications

As mentioned I've already removed the Furby's brain and voice box.  I did think about if I could use all or part of the H-Bridge as a level shifter to pass the signals to the TB6612FNG board. However due to the tiny surface mounted resistors not really having appropriate values I decided instead to remove all of those transistors to avoid any unintended behaviour such as shorting the power rails. I also removed the wires for the back sensor as those were directly attached to the board rather than being jumpered. That allowed me to work on the board completely separate from the mechanics.

Stripped down board



The Furby has a surprisingly sophisticated power setup. It has raw 6v from the batteries, 5.13v used by the main processor, 4.86v used by the EEPROM and a switched 6v used by the audio and IR sensors.

Power Supplies

One thing that is missing from the schematic is what powers the 74HC14 which is used for the driving the LED and processing the opto-sensor signal. I checked and it was connect to the 6v line.


The Edison has an even more complex setup. The key thing here is that the 3.3v line can only source 100mA so I'd have to be very careful if I wanted to use that to drive any part of the Furby.


USB Breakout Notes


So my chosen approach is to power the Furby from its own battery connectors. The voltages will be slightly lower than design as I'm using a 5v supply rather than 6v but are still well within the range of the 74HC14 and sensor components.


The Edison will be powered from the J21 connector so that I can connect an audio card to the USB.


I've broken down a second powerbank into it's constituent components. It's interesting to see that there is just a single MP3401A chip and a few discrete components.


Home Switch

The home switch is the simplest part of the circuit. I confirmed that one side was grounded and soldered a wire onto the COB header so that I could test it. To test, I added an LED and resistor connected to the positive supply.



The LED for the opto-sensor is linked to the inverting buffer. I checked the schematic and the LED was connected to +Vcc but as suspected the orientation was reversed. I tried to get it to light and there was nothing so I pondered if it was an IR LED. So I soldered a second LED in parallel. This also produced no result (retrospectively this could be due to different junction voltages) so I unsoldered the original LED and replaced with a white LED. My theory was that the sensor might be only sensitive to a specific wavelength so the white would cover the most options, it also allowed be to visually check that it was on.



The output of the phototransistor is fed into a Schmitt Trigger inverting buffer in the form of a 74HC14. The Schmitt trigger cleans up the signal to a nice square wave so it will be easy to detect a rising edge with the Edison. As suspected the schematic for the transistor was reversed.

To test the photo-transistor I wired an LED and resistor in series. The Furby was re-assembled and the slotted disk was rotated. The LED turned on and off as desired. When this is run from the motor it flashes faster than the eye can see so I'll have to ensure that the signals are processed fast enough.




As mentioned the H-Bridge transistors were removed. This provided some spare sockets to attach a connector. A right angled connector was used as there was not a lot of vertical space. I plan to us the PWM option on the motor driver board so that the motor runs more slowly. The process for that is the same as [Upcycle It] Interactive Race Car Driver - Powering Motors


Eyelid Fix

Whilst testing the motor, I realised the eyelids on this Furby were closing but not re-opening, I discovered that the rubber coated cam was slipping on the back of the eyelids so I used a knife to score the plastic. That now works as correctly.



Level Shifters

I soldered up my FRB590 transistors as per Harry Fairhead's suggestion in Exploring Edison - Life At 1.8V again using one of the scrapped Protozero boards.



Next Up

The driver is a complex part of the project so there's going to be another week of work on this. The main item is connecting up the sound to the Furby's speaker.



Hardware Guide for the Intel® Edison Breakout Board

Hardware Guide for the Intel® Edison Compute Module

Furby Schematic

Schmitt trigger design

Exploring Edison - Life At 1.8V (Harry Fairhead)


Previous Posts

Upcycle It Blogs tagged with upcycled_interactiveracecardriver

For my indicators, I wanted a simple function that would blink them 5 times then stop. I found a suitable piece of code on Stack Overflow which did the same thing for some flashing text and ported it across to node. However, I did not have the Edison to hand so pondered how I would test it. A quick google found mraaStub  a mock version of mraa that you can use on platforms that don't have mraa hardware. I installed this and discovered that it needs a logging package called "winston" which I also installed. I also had to tweak the mraaStub library so that it would log by default. My version can be found at


//Simple function to test the indicator

var platform = require('os').platform();
var m;

if (platform === 'win32') {
    m = require('mraaStub'); //also needs winston
} else {
    m = require('mraa');

var myLed = new m.Gpio(13); //LED hooked up to digital pin 13 (or built in pin on Galileo Gen1 & Gen2)
myLed.dir(m.DIR_OUT); //set the gpio direction to output

function indicate() {
    var count = 1;
    var ledState = true;
    var intervalId = setInterval(function() {
        ledState = !ledState;
                if (count++ >= 10) {
    }, 500);



Here's how it looks in Visual Studio Code when it is running.



javascript - Making text blink a certain number of times? - Stack Overflow


Previous Posts

Upcycle It Blogs tagged with upcycled_interactiveracecardriver

3d Printing

The 3D printing and car modification has run into a second week. Although each of the components does not take a long time to print there are a lot of them so it does add up. I've been printing with the recycled filament which has printed ok with the exception that the PET does not span well. This means I need to design my parts accordingly.



A curved section was printed to support the lighting components. Although curved this was printed curved side down with supports so that I did not need to create a complex scaffold to do the cutouts for the lights. This printed without issue and I cleaned off the supports.

Light Block

A lamp housing was created for the headlights. Which was a simple box with a concentric rings on the front. This was put together with the previously printed indicators and the above plate.


These were tested by simply hooking up the supply.



A block was added to the bottom so that this section could be bolted to the bumpers.



The bumpers went through a few changes since last week. To produce the best flex in the bumper the pivot point was moved right to the middle and the design was adjusted accordingly. Some mounting holes were added so that this could be bolted to the bumpers.



The chassis has been slimmed down as previously mentioned and the mounting points for the bumpers were spread apart so that they cleared the existing frame. The chassis was printed with the black ABS from Refil (ex car dashboards) and it printed without problem. I did drill out the mounting holes to 3.5mm as I suspected that my printed sizes were a little small.



The front lights wiring has been finished off this week with a NPN transistor being added so that the headlight LEDs can be driven. The grove connectors have also been wired up. I realised that I could also put the bumper switches through the same board so an additional grove connector has been added and wired up to the resistor network described in [Upcycle It] Interactive Race Car Driver - Bumper switches and wiring loom I just need some spade connectors to finish the complete assembly.

Putting it together

When I came to assemble the printed parts there were a few issues. The first was that the new lights and bumper clashed with the existing frame. A hacksaw quickly solved that problem and the frame was shortened. I also dug into my bag of reclaimed screws and bolts and found 4 that would fit the chassis nicely. I also found that the lights and bumpers were higher than I wanted so I chopped up the back bumper and glued it to the top of the front lights to allow those to hang below. This meant that the front assembly hangs a long way from it's supports. So I'll need to add an additional brace at the bottom, there's a handy screw point that I'll likely attach that to. With a three point mounting the lights and bumper are solid. I'll likely incorporate these changes into the models so that the back bumper/lights are simpler to assemble.


As you can see the battery pack and Edison balance each other out and since I've taken these photos I've moved the batteries further back to give my driver more space.



I've been preparing the driver which my daughter has nicknamed Freddie. The second Edison has been flashed, connected up to the network and configured for SSH.


As mentioned in the previous discussion the Edison breakout board runs at 1.8v volts. The 74HC14 Schmitt triggers that are used on the driving the LED and monitoring of the position sensor can run down to 2v so to interface these to the Furby something is needed. Referring to Harry Fairhead's book on the Edison Exploring Edison - Life At 1.8V the approach of using a simple transistor to boost or lower the voltage seems the best option.




In my collection of salvaged parts I had 5 identical transistors. The "FRB" code seemed the ideal choice to put in the Furby but I could not find out what transistors they were. Luckily a friend from twitter @MrTomsWorld has a gadget (Peak Atlas DCA55) to test them so I posted him one and he identified it as NPN and sent me the pin details. Following this, I was showing the results to my radio ham friend Alan. From the design he commented it was likely to be a silicon transistor and commented that if you prefix with "2SD" then you should find the transistor that way. A google search found me the datasheet and spec.



Material of transistor: Si

Polarity: NPN

Maximum collector power dissipation (Pc), W: 1

Maximum collector-base voltage |Ucb|, V: 100

Maximum collector-emitter voltage |Uce|, V: 90

Maximum emitter-base voltage |Ueb|, V: 6

Maximum collector current |Ic max|, A: 2

Maksimalna temperatura (Tj), °C: 200

Transition frequency (ft), MHz:

Collector capacitance (Cc), pF:

Forward current transfer ratio (hFE), min: 100

Noise Figure, dB: -

Package of 2SD590 transistor: TO39



Exploring Edison - Life At 1.8V


2SD590 transistor


Previous Posts

Upcycle It Blogs tagged with upcycled_interactiveracecardriver

The observant amongst you will have spotted that there was an item in the  [Upcycle It] Interactive Race Car Driver - 3D Printed Parts article that did not relate to any of the things I was printing. That was because I did not know if it was going to print ok or not. The part is some "exhaust pipes" to add to the Edison to turn my "engine" into a hotrod.

Edison EngineIMG_20170508_210714.jpg

Because I was concerned about the exhausts wobbling about when printing I added some 1mm horizontal supports to the model which were then cut off using a knife following the print. The print went well until layer 165 of 168 at which point it came detached from the print bed. As I was printing at 100% fill this did not actually matter and I've gone with fractionally shorter pipes by 0.9mm. If I was going to print it again I'd likely use a brim around the base to give it a bit more grip.


You can find all the models at


I don't think my modification will make any difference to the Edison's performance but I do think it looks cool. Hopefully, I'll have time to give it a coat of silver paint so it looks more like exhaust pipes.


Previous Posts

Upcycle It Blogs tagged with upcycled_interactiveracecardriver

Recycled filament

I had intended to use some recycled filament from a Kickstarter. However, as with many Kickstarters it has been delayed. So Instead I ordered some filament from a dutch firm, Refil. They get their filament from 2 different places. The first is from bottles, these are a material called "PET" and comes in a transparent but coloured materials. The second is ideal for my chassis, it is black (dark grey) ABS which comes from old car dashboards, it seems fitting that an old car should become part of a new car.



I've used different CAD packages over the years but recently I've been doing a lot with OpenSCAD. This is different from a lot of CAD packages in that the only way you can create objects is via scripting.


Here's a simple example of a cylinder joined to a circle which has been extruded around a 70degree corner.


module Exhaust() {
    translate([1.81,4.66, 0])
            cylinder(r1=1.5,r2=2.5,h=30, $fn=100);

    rotate_extrude(convexity = 10, angle=70, $fn=100)
        translate([5, 0, 0])
            circle(r = 1.5, $fn = 100);


I find it is good for 3D printing as you can tune the parameters as you build different models. As it's a coding language naturally parts that are repeated in arrays or circles are easy to reproduce. It's less good at producing organic items such as trees although you could use "fractal" algorithms for that kind of thing.

I have been working around a bug where the "difference" function causes things to disappear on one of my Win10 machines. Something to do with Java and incompatible video drivers apparently.


One technique I used on several of the parts was to print out a couple of layers and then cancel the print to give a floppy template. This allowed me to cross check the dimensions and ensure things would fit together.



The chassis serves several purposes: it's there to strengthen the middle section that was weakened by the cutting down; it provides mounting for the battery and Edison, and it provides an attachment point for the bumpers. This has gone through many iterations, the initial models were massively over engineered with 10mm thick struts and would have taken many many hours to print. So it's been slimmed down and simplified. The other key design feature was making it short enough to fit on my 210mm printer bed. After watching a video by Vicki Somma, I realised that the buffers that held the bumpers in place would be better as octagons so that when I print the sockets on the mating parts they won't have a big span to cross. The design changes cut the predicted print time from 4hrs to 2hrs 20minutes and also the amount of filament used is reduced.



I had initially thought about attaching the bumpers with rods and springs but I realised that I can use the springy properties of the PET plastic and just attach them directly to lugs on the chassis. Here's my sketch and models of how these might be built.

Buffers.jpgBumper1.png Bumper3.png

Edison Support

The Edison needs attaching to the car so I wanted something that looked like it was part of a car. I created a part with a fuel tank, exhaust, battery and a belt driven pulley. To reduce the material used in the print (and hence reduce print time) I added some hollowing out below the parts. I printed the part in draft-mode using some green ABS that I had available. I've a selection of self-tapping screws harvested from various old computer parts over the years so I'll use those to attach the Edison to the support.

EdisonSupport.png IMG_20170501_200711.jpg IMG_20170501_211603.jpg

Battery Clip

My initial model for the battery clip was all in one part. I realised that this would mean that the clips would be quite tall. This has two issues, firstly a long print time and secondly, it was a risky print as the vertical parts might move during the print and cause failures. So I redesigned it in 3 parts connected with a dovetail joint. This meant that the clip parts could be printed on their sides and hence would be a lot shorter and more stable. Initially, the material seemed to bond well to the bed but there were a couple of failures where it broke off. So I fined tuned the temperature settings and sizes and re-printed, I also added a brim although I'm not sure that was strictly necessary.

BatteryClip.pngBatteryBox (1).jpgBatteryBox (3).jpg

BatteryBox (2).jpg

Drivers Seat

The seat is there to hold the Furby driver in place, it will also hold the motor driver board in place. Key design features will be that it will straddle the chassis and need space for routing the cables. As the photo below shows the driver board will likely be mounted vertically on the back of the chair.


Car Body

I've not started designing the car body yet but the plan is to use a green recycled PET for that. Hopefully, it will be possible to print a thin walled model so the electronics can be seen through the plastic.



OpenSCAD - The Programmers Solid 3D CAD Modeller

Refil - The makers of recycled filament

Embedding Nuts into 3D Printed Tap Handles


Previous Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

[Upcycle It] Interactive Race Car Driver - Detailed Plan

[Upcycle It] Interactive Race Car Driver - Edison

[Upcycle It] Interactive Race Car Driver - Drive Motor Testing

[Upcycle It] Interactive Race Car Driver - Car modification

[Upcycle It] Interactive Race Car Driver - Furby Hacking

[Upcycle It] Interactive Race Car Driver - Powering Motors

[Upcycle It] Interactive Race Car Driver - Bumper switches and wiring loom

[Upcycle It] Interactive Race Car Driver - Securing MQTT

In my previous look at the software I looked at connecting up a web client to an MQTT server.


Picking a broker


Thanks to Jason I realised that the Mosquitto Broker that's provided is an old version (1.3.4) that does not support WebSockets. I tried to update using "opkg install mosquitto" but that told me I was on the latest. So instead I removed it and it's the packages that depended on it.


# opkg remove mosquitto --force-removal-of-dependent-packages

Removing package iotkit-comm-c-dev from root...
Removing package iotkit-comm-c from root...
Removing package iotkit-comm-js from root...
Removing package mosquitto-dev from root...
Removing package mosquitto from root...
rm '/etc/systemd/system/'


I then installed the Mosca broker using npm, that had worked well for me on Windows for testing so I might as well use that for the car.


npm install mosca


There were some errors about not being able to compile Kerberos due to missing missing gssapi/gssapi.h. I realised that kerberos was just for cross domain authentication so would not be an issue for my configuration.

So that we can easily start mosca, a link can be added as follows:


ln ./node_modules/mosca/bin/mosca /usr/bin/mosca


I'll also add in a boot up option so that it starts automatically.


I also installed the npm modules mqtt and queue.


Creating a certificate

I'm developing on windows so I used a simple powershell cmdlett to create the certificate in my local store.


New-SelfSignedCertificate -DnsName "", "" -KeyFriendlyName "Workshopshed"


I then extracted the certificate and private key as a .pfx file with a simple password. This needs the format converting before you can use it with an MQTT broker so I did that with ssl-converter and ended up with a .PEM file.

Note, that you can also do these steps using the OpenSSL toolkit or you can create a real certificate with something like LetsEncrypt

Configuring the MQTT Broker

To run Mosca with a certificate you can add a couple of command line parameters.


./mosca -v --https-port 1884 --only-http --cert TestCertificate.pem --key TestCertificate.pem


Configuring the client

The client uses the Web Browser to determine the certificates so we can add the test certificate viewing the certificate manager, adding an exception by browsing to the location of the mqbroker and getting the certificate (Firefox). It will likely report that this is the wrong site and is not trusted. You can view the certificate to confirm that it's the one you added to the broker.

Exception.png ExceptionManager.png

The code also needs to change slightly to tell Paho to use TLS encryption.


var client = new Paho.MQTT.Client("localhost",1884, "MyClientID");
client.connect({useSSL:true,onSuccess:onConnect, onFailure:onConnectFail});}


Configuring the listener

On the server side, our command listener also needs to be configured to use TLS. This is done using some options when we connect. I've chosen to ignore the unsigned certificate but it is also possible to set options to load up the certificates so that we can validate them.


var options = {
  rejectUnauthorized: false,
  protocol: 'wss'

var client = mqtt.connect('mqtts://localhost', options);


Change to use JSON

I've also changed my code to use JSON rather than simple messages.


On the client I create my messages as follows:


       var message = new Paho.MQTT.Message(JSON.stringify({ action: "DOWN", timeOut: 1000}));
       message.destinationName = 'E14_UCDC/MyClientID/Commands';


And on the server, the listener converts this back and passed them over to the controller for processing.


client.on('message', function (topic, message) {
    var command = JSON.parse(message.toString());


This decouples the listener from the commands so that I can add new commands into the controller in future without worrying about the transport.


My controller queues up the messages and can play them back when it receives a "Run" command.


var queue = require('queue');

var controller = function() {

  this.q = queue();
  this.q.concurrency = 1;

  //Expect a movement object formed of a command and timer to be passed { action: action, timeOut: timeout}
  this.addMovement = function(move) {

     if (move.action == "RUN") {;

     if (move.action == "HALT") {

     if (typeof move.timeOut == 'undefined') {
        move.timeout = 10; //Default to 10ms

     var c = this;

     this.q.push(function(done) {
                setTimeout(function() {
                }, move.timeOut);

    this.halt = function() {
    } = function() {
       this.q.start(function(err) {
          if (err != null) {

    this.doMovement = function(action,timeout) {
        //Todo: this is where we'd talk to the hardware

    this.shutdown = function() {
        //Todo: If we need to shutdown any hardware handles etc.

module.exports = new controller();



You can see all of the code at



JsDoc Reference - Paho.MQTT.Client

Run a Script on Edison Boot | Shawn Hymel


Previous Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

[Upcycle It] Interactive Race Car Driver - Detailed Plan

[Upcycle It] Interactive Race Car Driver - Edison

[Upcycle It] Interactive Race Car Driver - Drive Motor Testing

[Upcycle It] Interactive Race Car Driver - Car modification

[Upcycle It] Interactive Race Car Driver - Furby Hacking

[Upcycle It] Interactive Race Car Driver - Powering Motors

[Upcycle It] Interactive Race Car Driver - Bumper switches and wiring loom

So that I could tell if the car had bumped into anything I wanted to put some microswitches into the bumpers. I had recently stripped down a paper shredder and had stripped out a few useful parts including a couple of micro-switches. Luckily these were the same size as a couple of others I already had (which may have come from my previous shredder).


As mentioned in the discussions I was concerned over the number of I/O used by the car and wondered if it was possible to connect all of the switches on one input. I'd previously seen the idea of using a resistor ladder into an analogue input. However, I wondered if that could be adapted to support multiple buttons. I came up with a schema using the change over connections of the micro switches before realising that I did not have these connections on my two new switches. However, I also realised that I could use a couple of ports, one for the front and one the back. Unfortunately, this means I don't have ISRs on the bumper switches but that can be handled in the software instead.


I put the circuit in the simulator again so I could rapidly play with resistor values. I came up with the ratio of R1 = R2, R3 = 2 x R2 which gave the values of 5v, 3.3v, 2.5v and 2.0v for the different switch settings. I had originally used push buttons but then realised I could not press 2 at once in the simulator. Of course, you could also do this with simple maths too. BBC - Higher Bitesize Physics - Resistors in circuits : Revision



Software for sensors

I did look into using the MCU to monitor the switches but the ADC is handled by the Arduino breakout and the MCU does not handle floating point. So I'm not saying that it's impossible but it is undocumented and there are numerous challenges to resolve.


So I stuck with using MRAA and Node for the Analogue inputs. The code in the "setInterval" function polls the analogue input every 100ms. If it has changed from one of the 4 states then it raises an event which is picked up by the "listener" function, this simply writes the data to the console but in the real car it would cause the car to stop and the driver to say something like "ouch".


var mraa = require('mraa');
var events = require('events');

var listner1 = function listner1(value) {
   console.log('Bumper:%d' , value);

var eventEmitter = new events.EventEmitter();
eventEmitter.addListener('bumper', listner1);

var previous = -1;
var analogPin0 = new mraa.Aio(0); //setup access analog input pin 0

//Monitor the bumper analogue pin and raise events if it changes
setInterval(function () {
    var analogValueFloat = analogPin0.readFloat();
    var newval = floatToSwitch(analogValueFloat)
    if (newval != previous) {
        previous = newval;
} , 100);

var BumpEnum = {
  None: 0,
  Left: 1,
  Right: 2,
  Both: 3

//Scale the input to one of our 4 values depending on
//which of the two switches are pressed
function floatToSwitch(value) {
    if (value < 0.45) return BumpEnum.Both;
    if (value < 0.58) return BumpEnum.Left;
    if (value < 0.83) return BumpEnum.Right;
    if (value >= 0.83) return BumpEnum.None;

process.on('SIGINT', function () {
    console.log("Shutting down SIGINT (Ctrl-C)");


Pins and cables

I came up with the following wiring that allows me to use the grove connections without modification and not need to create any clever split cables to handle front and back.



  • Brake lights - Pin 1
  • Headlights - Pin 5 (PWM)
  • Indicator L - Pin 3
  • Indicator R - Pin 4


  • Motor Speed - Pin 6 (PWM)
  • Motor 1 Direction - Pin 7,8
  • Motor 2 Direction - Pin A3, A4

From:  - AIO pins are treated as 0-5 in mraa_aio_init() but as 14-19 for everything else.
Therefore use mraa_gpio_init(14) to use A0 as a GPIO


  • Bumpers A0 and A1 (split front and back), resistor ladder to be used to allow left and right switches to be independently detected.

Light Sensor

  • Light sensor - A2

Cables (10 needed)

  • Front Lights - D2, D4
  • Rear Lights - D3, UART
  • Motor - D6, D7, A3
  • Bumpers - A1
  • Ambient light sensor - A2


So that's pretty much all that can be added so if I need anything else it will have to break out via I2C and need to buy some more cables



I've started soldering up some of the sub-modules that make up the car.


The main drive motors have been fitted with new wires that came from an old PC power supply, the motor drive board has been started and the headlights / indicators have been soldered up. As there are quite so many LEDs for the headlights, I'll use a simple transistor switch to boost the current to those and for the brake lights too.

PCCable.jpg MotorBoardWorkInProgress.jpg HeadlightsAndIndicators.jpg


Previous Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

[Upcycle It] Interactive Race Car Driver - Detailed Plan

[Upcycle It] Interactive Race Car Driver - Edison

[Upcycle It] Interactive Race Car Driver - Drive Motor Testing

[Upcycle It] Interactive Race Car Driver - Car modification

[Upcycle It] Interactive Race Car Driver - Furby Hacking

[Upcycle It] Interactive Race Car Driver - Powering Motors

After discounting the transistor based H-Bridges in the original car, I started experimenting with the TB6612FNG module. Despite its small size, it should be able to easily to take the few hundred mA needed for the motors.


My first experiments with this were not successful, every time I hooked up the motor supply connector the current shot up and the supply voltage collapsed causing the Edison to reset. After a few hours of double checking all the wiring and general frustration, I swapped to using LEDs to determine if my code or wiring was at fault. This worked fine with the direction LEDs turning on and off, and the PWM one fading on and off. I did get caught out by the fact that not all pins support PWM but you can swap those with the "swizzler", a set of header connectors that I've not quite worked out yet.

Testing with LEDs

var mraa = require('mraa');
console.log('MRAA Version: ' + mraa.getVersion());

var pwm = new mraa.Pwm(6);  //PWM available on default swizzler positions. (3,5,6,9)
var forwards = new mraa.Gpio(7);
var backwards = new mraa.Gpio(8);
var dir = true;
var value = 0.0;
var step = 0.01;



setInterval(function () {
    value = value + step;
    if (value <= 0 || value >= 1) {
       if (step <= 0) {
        step = -step;
    } , 50);

function toggleDirection() {
    dir = !dir;

process.on('SIGINT', function () {
    console.log("Shutting down SIGINT (Ctrl-C)");


After success with the LEDs, I tried a second H-Bridge module (from a different supplier). That did not have the same issue so I concluded the problem was with the first board which is now discarded.



Power supply

Given the motors are the main power drain being about 300mA each, I was looking for a supply that could supply about 1A, was light, easily recharged, had capacity for a few hours play and was in around the 5v - 9v range. Despite having a range of different battery boxes and rechargable batteries I did not have anything that met those requirements. I also had a small 6v lead-acid battery but that was very heavy. Finally, I looked at buying some RC car batteries but these were very expensive and I'd need a charger too.


Then I realised that I did have a phone "power bank" that I'd won in a prize draw the previous year.

Power Bank


Capacity: 4000 mAh

Output: 1A

Input/Output Voltage: 5V

Battery Type: Rechargeable Li-Ion

Charging time (to charge power bank): Up to 4 hours

Standby Time: Up to 4 months

That should be perfect, so I doctored a USB cable so I could attach it to my breadboard. Unfortunately my cables were not coloured coded as per "standard" but I worked it out with a multimeter. The battery box happily powered my test LED and also the motors.

Motor Test 1Battery Test 2



TB6612FNG Hookup Guide

Power Consumption for Intel® Edison Board for Arduino*

Power Banks | My Doodles

Previous Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

[Upcycle It] Interactive Race Car Driver - Detailed Plan

[Upcycle It] Interactive Race Car Driver - Edison

[Upcycle It] Interactive Race Car Driver - Drive Motor Testing

[Upcycle It] Interactive Race Car Driver - Car modification

[Upcycle It] Interactive Race Car Driver - Furby Hacking

I'm not quite sure when I bought the Furby but I do remember the Furby Autopsy website inspiring the purchase. So that suggests it was perhaps after 1998.


When I recently checked there are some others that have also done some investigations including puppeteers and universities. A big thanks to Kelly Heaton for giving me permission to re-use her image showing the key parts of the Furby. As you can see there are loads of switches and sensors all over the Furby, there are also lots of moving parts but those are all run from a motor and cam mechanism.


Furby Anatomy


Furby Anatomy: From Kelly Heaton - anatomy of the furby


All I can say are that the original designers from Tiger Electronics were absolute wizards. They also did not skimp on construction with all the key components being attached via plugs and sockets. The "brains" of the operation are 2 boards with black blobs, it looks like one is a controller and the other is for processing the sounds. There is also an Eprom, Microphone and pre-amp and IR communications.


Schematics created by Chris Brown.


The motor seems to be controlled by a transistor based H-Bridge to the one I found in the RC car, so I think that I'll be swapping that out with a module again. To control the motor I also need to be able to count the pulses from the optical sensor and monitor the home switch. I think there's a couple of errors around this part of the schematics, the H-Bridge seems lopsided and the sensors on the gear position seem to be reverse. However they have saved me a whole load of work and I should be able to hook in my circuits to the connectors where I'll be removing the controller and sound chips.

Motors.pngMotor Sensors

Equally helpful, the team at Northwestern University Mechatronics Design Laboratory have mapped out the Encoder Pulses for the different kinds of motion.

Number of pulses relative to the home position

Pose of the Furby

0 to 30

ears up, eyes open, mouth closed, not tilted

30 to 60

ears down, eyes open, mouth open, not tilted

60 to 100

ears down, eyes open, mouth shut, not tilted

100 to 130

ears down, eyes shut, mouth shut, tilted

130 to 170

ears up, eyes shut, mouth open, not tilted

170 to 200

ears up, eyes open, mouth open, not tilted


The encoder generates about 200 pulses per revolution of the motor and the number of pulses goes back to 0 again after one complete revolution.

The motion of the Furby is continuous and there the poses described above are just approximations. In many cases, the eyes or ears are partly open or closed.

By looking at the mapping above, however, you can have a rough idea of which number of pulses corresponds to which pose.

The comment "The motion of the Furby is continuous" does seem to tally with my experiments on the drive motor h-bridge which suggest that the motor does not have a stopped option. As per the maindrive my plan is to use a TB6612FNG module for the Furby motor, I'll use transistors to turn on and off the signals to the module.


Inside the Furby

I removed the casing and the speaker assembly and that allowed access to the PCB. I disconnected all of the sockets and extracted the board. Using some desolder braid I carefully removed the two "COB" (chip on blob?) boards. I wanted to keep the main PCB operational as that had signal conditioning and a driver for the opto-sensor for the main drive motor.


{gallery} Inside the Furby

Inside the Furby

Furby Guts: Inside the back of the Furby


Mechanics: Main drive gear and cams to activate the movements


Situp Plunger: This plunger causes the Furby to tilt forward

Home Switch

Homing Switch: These contacts are closed once per rotation


PCB: Note the after production modifications, LED for the optical sensor top left, the 2 daughter boards for control and sound, and the black circle bottom left is the tilt switch

PCB underside

PCB underside: The black and white wires connect up the power connection

Battery Compartment

Battery Compartment: Looking at the battery compartment as a place to put the Edison and a battery

Brain Removed

Brain removal: With the two daughter boards removed there might be space for the Edison in the main housing


I wanted to understand the optical sensor as that would be needed to determine the positions for the animations. I realised that the LED on the PCB sticks into a tube and the sensor must be at the other end of that. There's some Schmitt triggers on the output of the photo transistor so we should get a clean signal from that.


As per the car, I also wanted to check that the motor was running and the mechanism was working, so I hooked up the motor directly to a 5v USB from a powerbank. The circuit diagram has this running from 6v so I wanted to be sure it would run correctly from 5v, which it does.



The next thing to do for the Furby is to hook up a H-Bridge and the two sensors to the Edison to check it can be controlled. Some of the other furby hackers have reported problems with the signal from the optical sensor.



Furby Autopsy


Puppet studio - Furby

Northwestern University - Mechatronics - Furby Dissection

Anatomy of the furby


Previous Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

[Upcycle It] Interactive Race Car Driver - Detailed Plan

[Upcycle It] Interactive Race Car Driver - Edison

[Upcycle It] Interactive Race Car Driver - Drive Motor Testing

[Upcycle It] Interactive Race Car Driver - Car modification

My main concerns about the car were the high driving position and general space for the electronics. There were some handy screws on the front and back so I though those would make good points to attach my own platform. There is also a bit of flex in the chassis now so my additions will need to include re-enforcement.


{gallery} Car Modifications


Before: The car base

Step 1 Remove Battery Box

Step 1: After removing the battery box the platform was still quite high


Stripped: So I stripped it down even further

Lower driving position

Driver: New lower driving position

Edison on Car

Edison: There should be space in the engine compartment for the Edison


Disaster and repair

Although I'd previously thought that the gearboxes were fine, I noticed that one of the wheels was freewheeling whereas the other side turned as a pair. I opened up the gearbox again and spotted that one of the pinions was rotating freely on it's axle. When I removed it, it split into two.


I looked through my collection of gears and found a replacement, except it was connected to another gear. I sawed it off with a junior hacksaw and it fitted onto the spindle. It was a little loose so I added some cyanoacrylate adhesive (superglue).


New GearGearboxIn place

Now my vehicle is back on the road and ready for some new electronics.


Previous Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

[Upcycle It] Interactive Race Car Driver - Detailed Plan

[Upcycle It] Interactive Race Car Driver - Edison

[Upcycle It] Interactive Race Car Driver - Drive Motor Testing

Motor investigation

Before committing too much time to the car, I wanted to check over the motors. The key things to look at were ensuring they rotate freely and to determine the correct motor voltage. Because the motors are sealed it's not possible to check much else such as brushes or bearings. I have taken these kind of motors apart before but I did not want to risk being in the situation of not being able to put them back together.


I started by disconnecting the RC controller board so the motors could be tested. The coil resistance was approx 4Ω so I knew I'd need to be careful about limiting the current. Looking at the board the capacitors were all rated at 10v so I suspected this was powered from two or three old style  batteries e.g. 3v or 4.5v. So I started with my power supply set to 2v and 300mA. The motor turned and did not take a lot of current so I increased to 3v and took a reading.

Motors (3).jpg

I tried to measure the stall current of the motor but it went over 1A and I was not comfortable setting my current limit any higher as I did not want to burn out the motors. I did, however, measure the motor under load and it took 600mA. This will be important when I look at the supply as I'll need to have something that can provide these kinds of currents.


After re-assembling the car I ensured that both motors worked in both directions and the wheels turned. I'll likely open up the car chassis a little so that I can get to the wiring without having to keep unscrewing everything.


Driving the motor

I had thought about using an off the shelf H-Bridge module based on the L298. However looking at the RC board it divides easily into 2 halves for the radio and the power to the motors. I guessed that the latter is two, 6 transistor based H-Bridges.


RC Board Reverse Engineering

To reverse engineer the board, took a photo and blew up the print. Normally I would use any chip on the board to determine where the power supply lines are located but the numbers drew a blank, the name on the top is a toy manufacturer. So I followed the electrolytic capacitors instead, also the screws are typically in the ground plane. The transistors were easily identifiable as C3279 (NPN), A1015 (PNP) and A1300 (PNP) the resistors were mostly 1K and 100R. I had big pads for the motors.



The circuit seems to have promise but I was a little concerned that I did not fully understand the circuit, so I opened up to simulate it.



With one input high and the other low the circuit worked as I wanted it to. The motor turned in each direction.

If I took both inputs high then it seemed not to switch off, staying with which ever direction had previously been selected.

If I turned both low then my worst fears were confirmed in that the circuit did not properly turn off the transistors resulting in the current limit being hit and the supply voltage dropping.


I wondered if there was anything specific about the combination of my transistors that might cause it to work differently to the simulation. My final experiment with the simulated circuit was to drop the supply voltage down to 1.5v. This worked better but the current draw for both inputs low was still quite large at 350mA.


Simulated circuit -




I removed the RC chip and wired up a spare motor to the H-Bridge. I set the voltage to 3v and the current limit to 100mA. It behaved exactly the same as the simulation, when the motor was running it was fine, when the inputs were all low then the current limiter kicked in.


My conclusion is that the motors perhaps never stopped, the controller could have kept them running all of the time. I'd like to be able to stop my motors so it's back to my initial plan of using an off the shelf module, I've got a L298 with a big heat sink and a smaller TB6612FNG module. Both of these will run from 3-5v and logic levels at similar levels. The motors and gearboxes seem to be fine so otherwise the car is good to use.




Previous Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

[Upcycle It] Interactive Race Car Driver - Detailed Plan

[Upcycle It] Interactive Race Car Driver - Edison

As mentioned previously my daughter helped me assemble the Edison and Arduino breakout board.



I followed the Getting Started with the Edison guide for Win32. The drivers download page suggested that the drivers were only for 64bit Windows but installed just fine, as did the FTDI drivers. However when I ran the setup the Intel Edison Setup application it seemed to remove those drivers and replace with some others. Once the new drivers were installed I picked the option to download and install the latest firmware.


We named the board "Eddie", enabled SSH and connected up to the Wifi. Once the board finished and rebooted I checked I could ping


Ping Eddie.local

I also checked we could connect with SSH and login as root, using Putty. Once in I double checked the version.


root@Eddie:~# cat /etc/version


I checked for newer software from the repositories with:

opkg update
opkg upgrade


It upgraded mraa and upm which connect up the hardware so that's probably a good thing.



Node and MQTT are the main components I needed installed, I checked node using


node --version


That came back as v4.4.3, that's not the latest so looking at how to upgrade that might be a good idea.


I also checked mosquito was installed using

opkg info mosquito


Given that mosquito is installed, I'll swap to that rather than Mosca which I've been using for testing.


Quick test with MRAA

I mashed together a few articles to get myself a blinking LED on D7 on the grove shield


#!/usr/bin/env node
var mraa = require('mraa'); 
console.log('MRAA Version: ' + mraa.getVersion()); 

var led = new mraa.Gpio(7); 

var ledState = true; 

setInterval(function () { 
 ledState = !ledState;
}, 1000);


Then I put together an example for using the input and an interrupt.


#!/usr/bin/env node
var mraa = require('mraa'); 
console.log('MRAA Version: ' + mraa.getVersion());

var button = new mraa.Gpio(5);
var led = new mraa.Gpio(7); 

var ledState = true;


button.isr(mraa.EDGE_RISING, function () {
 ledState = !ledState;

setInterval(function () {} , 1000); //Do nothing, stops the apps exiting

process.on('SIGINT', function () {
    console.log("Shutting down SIGINT (Ctrl-C)");




mraa: Intel Edison

Exploring Edison - Mraa GPIO


Previous Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

[Upcycle It] Interactive Race Car Driver - Detailed Plan

Looking at my overall objective for the challenge I've broken down the work into some steps.


  • Motors testing
  • Furby testing
  • Lighting
  • Power supply
  • Driving motors
  • O/S and prerequisites
  • Playing sounds / speech
  • Activating the Furby
  • Software


Motors testing

Review the car motors to see what voltage and current they require. Ensure that the car platform still works.


Furby testing

See how the Furby is put together, look at controlling the main drive motor and reading sensors. Look at the speaker to see what we need to drive that.



For the car lighting, look at what we need to drive some LEDs for the headlights, indicators and brakes. Assemble sub boards that can be plugged into the grove connectors to power them. If I have time I'll take the suggestion from Jason and implement the light sensor so that the headlights can come on automatically.


Power supply

Review the Edison's power requirements, add to that the various motor and LED requirements. Ensure we have a battery that is capable of providing the voltage and current demands and has sufficient capacity for a reasonable run time.


Driving motors

Connecting the motors up to the H-Bridge, controlling speed and direction from the Edison.


O/S and pre-requisites

The system relies on some form of operating system to host the software so time will be needed to check versions, ensure I've got Node and a MQTT broker running and hook it up to the Wifi.


Playing sounds / speech

Getting the sound card connected to the Edison, reading files from the SDCard and playing them through the headphone connector. Connecting that up to the Furby speaker and reviewing if it will need an additional amplifier


Activating the Furby

Getting the Furby controlled from the Edison.



Controlling the hardware, looking at what we need so that the car can turn through 90° in each direction


Car Chassis

Putting the physical aspects of the project together. See if we can put some microswitches or other sensors into the bumpers.


Other posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

[Upcycle It] Interactive Race Car Driver - Lights

One of the key features of the car is the lights. This will consist of headlights, brake lights and indicators. The thought is that the headlights can be controlled by the users and the indicators and brake lights will trigger automatically based on the motion of the car. Either way they will all ultimately be controlled by the Intel Edison and it's likely I'll use the Arduino breakout and Grove shield for its pluggable headers.



The other year I had some LED downlights that failed on me. Curious to know what they had inside I cracked one open to see. After removing the glass and a load of potting compound I broke out a simple board with some LEDs on one side and a bridge rectifier and some resistors and capacitors on the other.


After desoldering the components I tested the LED using an adjustable powersupply. The voltage was set to 2v and the current limit 20mA. I then increased the voltage until it started glowing. At 2.8v I had a workable brightness and at that voltage the LED was drawing between 3 and 5mA.


In the process of soldering these to some scrap PCBs, I discovered that the reason for 3 lots of connectors is that there are 3 individual LEDs in each package. I also discovered that some of the packages not all three of the LEDs were working. This might account for why the light failed in the first place as the original circuit seems to chain all the LEDs in series like Christmas tree lights. I'll likely need to re-measure the current now that I've worked out that there are potentially 3 times as many LEDs. If they take a lot of power then I'll use a PWM signal to dim them down a bit.

You might recognise the PCB if you are a Raspberry Pi Zero fan, it is from a batch of AverageManVsPi ProtoZeros where the silk screening failed quality control. I got them for the price of postage and they make great "tri-pad" boards for prototyping regardless of if you attach them to a Pi or not.

Once I've worked out the rest of the car chassis design I'll chop up the PCBs to mount them on the front of the car.


Brake Lights

In my box of electronic components I've a large number of 3mm red LEDs, I'm not actually sure where I got these but they have very short legs so I presume they came straight off a PCB. I've checked I've enough for a couple of sets of 6 LEDs to make for a nice bright brake light. The plan is to mount these on some stripboard or PCB similar to above.



I also checked to see if I had any orange LEDs. I had 3 which was annoying as I'd need 4 for the indicators. However, I did have lots of white LEDs. So I designed an indicator block in OpenSCAD to be printed from some translucent orange filament that I bought the other year. I printed out a few tests and in the process noticed two things. Firstly that the light shone best where there was minimal infill I'd tried 40% and 8%. Also that my initial drill holes were so small that they just closed up. I realised that I could combine these two and have a zero infill to give a hollow box and then add some slits to force the slicer to add some extra supports for my screw holes. I also added a bubbly texture to the top to help diffuse the light.



To test the light I inserted a white LED in the back and powered it from a couple of button cells. I'll print out the other three when I've a better idea as to how the bumper assembly will be put together.



Other Posts

[Upcycle It] Interactive Race Car Driver - Plan of action

[Upcycle It] Interactive Race Car Driver - Software

For the software, I wanted to keep the UI loosely coupled from the control, I also have been wondering about blue tooth vs wifi. By using Node.js for the server side components that means the same language (javascript) can be used for all of the software which should make things simpler. Another advantage of Node is because it is multi-platform it can be written and tested without the need for the Edison. So I've been doing this on Windows so far.



My plan to achieve this is to use an MQTT broker to pass the commands. These will be simple text strings such as "L" for left, "R" for right, "F" for forward etc. Initially, the commands will be sent using WebSockets but it is also possible to send the messages over bluetooth via a client side API and an MQTT-SN to MQTT gateway such as Aquilla . I'm also wondering if I should change these commands to be JSON objects to simplify processing and also to allow the motion controller to queue up commands and hence make the system programmable.



The broker will be run on the Edison so we don't need to have any external dependencies. The idea is to use Mosca to do this. It is possible to use Mosca directly in the code, but my plan is to have a separate Node application which I'm calling the "motion controller" this will take the messages and call the appropriate APIs to make the hardware move.




In its the simplest form the motion controller subscribes to a topic and listens for messages.


#!/usr/bin/env node
// Listens for messages on a queue and moves car and driver
var mqtt = require('mqtt')
console.log('Connecting to Queue')
var client = mqtt.connect('ws://localhost:1884');

client.on('connect', function () {    

client.on('message', function (topic, message) {
    //Todo: Add movement code here.


The client side uses a different library as it runs in the browser. In it's simplest form it can send a message to the queue, on response to a button press, as follows:


  // Create a client instance
  var client = new Paho.MQTT.Client("ws://localhost:1884", "CarController");

  var message = new Paho.MQTT.Message("F");
  message.destinationName = "E14_UCDC/CarController/Commands";


For connecting to the hardware I'm looking at MRAA which can be accessed from Node and provides a simple way to access digital pins, I2C and PWM. This will be the first area to test once the Edison has arrived.


var mraa = require('mraa');
var pin13 = new mraa.Gpio(13);


Writing JavaScript for an Intel Edison


Other Posts

[Upcycle It] Interactive Race Car Driver - Plan of action