I was in an vintage collectables store and saw a beaten up old ‘Robie the Robot’ forgotten at the back of a shelf. It’s dome was cracked and it’s remote missing. Robot collectors are quite voracious in Canberra with most robots snapped up within days. However, it seems nobody relished this rough robotic remnant, so I got it cheap.

This robot was also known as: Tandy Robie, Radio Shack Robie, Robie the Robot, Talking Robie, RS 4061, Robocom 1000, Robie Parlant, Robocom Robot (Super). There is a good write up about the robot on theoldrobots.

Tear Down

Disassembling Robie I discovered a typical 80’s remote control toy. RC circuitry oozing with leaking capacitor electrolyte and decayed protective lacquer. Apparently the built in speaker could talk, but looking at the circuitry, my guess is it functioned as a wally talky, playing a voice signal from the remote. I didn’t have the remote so I can’t confirm.

The motors were the “old style”; power hungry and weak. The Achilles heel that made all 80’s moving toys kinda nerfed.

The front screen was fake, the heads and arms were not designed to move. I will need to fix all this.

A New Brain.

Decided to throw a pi in there, with a monitor that fits the front screen and a camera because that would be cool.

For the display, a generic five dollar 2.2″ SPI TFT LCD that sells for arduino projects works well (fits just behind the front monitor panel). The stock plastic used for Robies display is way to dark for the screen to be visible, so I used a Fresnel lens instead (you can get them from the two dollar shop, sold a book magnifiers).

A front assembly was 3d printed to hold the pi, monitor and camera (such that everything lined up, and the camera could see out of the hole previously used for the frontal on/off switch.

Motorising the Head

A turntable system was created in OpenSCAD, using the awesome parametric gear library by Dr Jörg Janssen. I didn’t have a 3d printer, so I printed via the ANU Makerspace.

The turntable is driven by a 28byj-48 stepper motor, with a ULN2003 Darlington transistor array driver.

I discovered the original broken dome was most likely not a custom mould, but a security camera dome. I had some difficulty justifying a proper replacement as Australian retailers wanted over $50 for a replacement security camera dome (just the one piece of plastic). So I just replaced the head with a plastic dome from a toy shop.

The result is not quite as fast as I would like, but it was unexpectedly charming.

Getting the arms to move.

A bracket was designed to get some cheap tower-pro servos to fit aligned with the arms. The brackets neatly affixes to old circuit mounting points in the plastic. A custom servo horn will friction fitted the arms to the servo. The existing arm bearing was sanded a bit to get it to slide freely. The result is a much more expressive robot.

Whats next.

I have made files for the progress thus far available via github, encase anyone has a Robie of their own and wants to try this. https://github.com/busyDuckman/robbie

Next up I will work on:

• Drive system so Robie can move around.
• Microphone array so voice interaction is possible.
• Control software.
• Personality and human interaction.

You can download it via: https://www.thingiverse.com/thing:4300602

Background

Some manufactures put the VESA mount at the bottom of the screen, others in the middle. This can cause an issue for many situations, especially if monitors need to be used on a shared mount or in portrait mode.

Lets compare the pro’s cons of the mounting styles:

The result for a shared mount was quite noticeable.

The plate which pokes out, should connect to the monitor. The other to the VESA mount (See below).

Customisation

The mount can be customised in OpenSCAD, or via the Thingverse customiser: https://www.thingiverse.com/apps/customizer/run?thing_id=4300602.

The following parameters should be altered to suit your need.

A friend who recently acquired a CO2 laser cutter for his school sent me a message. “What is the difference between a laser that will cut metals and one that won’t?”. I thought this is a good question, as the answer will help with understanding how to work with many materials.

But before the answer will make sense, we need to revisit the basics of how a laser cutter works in more detail.

How the laser cutter works: 101

The common C02 laser cutter can be thought of as “thick” beam of IR light that moves out of a laser tube, bounces of mirrors until to get to the head. In the head it passes through a lens that focuses the beam, such that it is strong enough to ablate certain material though heat. A jet of air clears debris, and if upgraded from the piddly inbuilt compressor, will minimise scorching on materials like wood. The fact the beam is wide means that it can be bounced around off mirrors wit out imparting too much energy to one spot, such that it burns though a mirror, or the lens.

How the laser cutter works: 102

Now think of a laser cut in slow motion and zoomed in massively.  The laser hits a material. The focal point is probably beneath the surface and the beam is still a bit wide (less hot).

The area at the surface vaporises and a little pilot hole forms. This hole is like the first domino, the material near it is now deformed. This deformed material (sub millimetre area) is like the plastic left in the sun, less robust and more sensitive to light. The cut now picks up momentum and deepens as a “pool of vaporising material eating into the ground”. The air stream is ejecting loose material and anything ‘molten’ that was not instantly vaporised.

The ability to cut well is a balance of many factors, primarily the right laser strength, air flow and movement speed – for a given material at a certain thickness.

Relevant to later discussions with metal, is getting a good movement speed.

• Slow enough that the pit will work all the way through, before the beam moves on.
• Fast enough that the material is not given too much heat (see diagram to right, not all the beam is vaporising goodness and its not all equal in strengths.
  • From the parts of the beam not near the focal point that are not hot enough .
  • From outer areas of the beam not as intense
• Different lenses will help with thicker materials, butt you first limitation is you will need more power for thicker materials. Otherwise you will need to move at a slow speed that brings many other problems of heat dissipation.

Reading the above may lead you to think you will need to get the most powerful laser cutter you can afford, for those times when you want to do a thick material. But… power is a two edged sword. The laser will only fire at a minimum of say 40%. So your 120W laser that will get you through 20mm acrylic, won’t be any good for etching designs on clothing (it will punch straight through at it minimum of 48W).

Problems that will affect metal

• Many metals are reflective of IR beams (C02 lasers), preventing even etching of the surface.
  • NB: other lasers, such as solid state lasers which work with a different wavelength will be several times more efficient than C02 lasers for most metals.
• Metal is a heat sink, it will draw heat away from the cut. Preventing the laser beam from melting any of the metal, or forming the initial pit.
• Many metals are not cool/safe in gaseous form. You may need venting.

Etching metal

Your enemy for etching, is not the heat conductivity of the metal, it’s the fact it reflects.
On cutters around your size it is often possible to etch certain metal. You will need to paint the surface with something (there are products that are sold for this purpose, but some people just use black $3 fiddly bit paint from buntings). The pit will form in the paint and you will get sufficient heat in to mark the metal. But then go no further down.

Cutting metal

Generally laser cut metal is not ablated/vaporised (turned to gas) like other materials. It is instead it is melted (turned to liquid), and blown out of the way by forced airflow. This is sometimes referred to as ‘melt and blow’ cutting. It is messy and provides issues that can damage a machine:

• Bits of molten metal can settle on the lens, this will absorb heat that the lens would otherwise transmit. The lens will now heat up and be damaged / burnt though.
• The metal / molten metal can reflect focused beam of light back at the lens. This can damage the lens, because the amount of IR radiation passing though it is now double.
  • The focused light can even propagate back along the mirrors and into the laser tube (damaging the very expensive parts of the machine).

Its worth mentioning that metal needs a lot more power to get the piloting pit going. And the pit is not a nice vaporised area with laser friendly material next to it. It’s a stubborn pool of liquid that sits in the way of your laser. This means cutting requires bigger lasers, or one or more assisting technologies to reduce the necessitated “bigness” of your laser.

Such assisting technologies, for CO2 lasers, may include.

• High pressure gas, to blow the molten metal out of the hole.
• Blowing Oxygen or Nitrogen into the cut to make things more efficient.
• Using a more focused beam to get the metal to melt before heat dissipation sets in.
• A lens that moves, so that the focal point travels with your pit as it goes down.

As some lasers can be coerced into cutting metal, why is it not more common?

Firstly, the risk to the machine means many operators don’t feel it is worth it.

But there are other issues:

• Solid state lasers are becoming more popular for cutting metal over the use of a large C02 Laser.
• The cut speed of lasers on metal can be slow, and the depth of cut limited.
• Tuning air/ laser/ lens /speed parameters is more difficult, and the results are not always a clean cut for inexperienced operators.

But more importantly there are many more attractive  alternatives for cutting of metal, including water jet cutting and CNC milling.

Further reading:

For clarity I simplified and glossed over some less important concepts in the above explanation.

The following industry articles explore things in more depth:

• Laser comparison – cutting speed and rate of feed. http://jmtusa.com/laser-comparison-cutting-speed-and-rate-of-feed/
• Lasing reflective metals http://www.fsmdirect.com/cutting/laser-cutting/326-lasing-reflective-metals
• Back to basics: The subtle science of burr-free laser cutting. https://www.thefabricator.com/article/lasercutting/back-to-basics-the-subtle-science-of-burr-free-laser-cutting

Recently I have been building a train set, I will blog the progress, in six parts, highlighting how I get certain things done.

• Part 1 – Design and Woodwork
• Part 2 – Electrical design.
• Part 3 – Mechanical servicing
• Part 4 – Construction
• Part 5 – Painting of buildings and natural elements.
• Part 6 – Embedded computing and setup of DCC controllers.

Base Setup

Firstly I am designing a track that is movable from a storage hook on a garage, to a pool table in my living. This requires a baseboard, which I constructed with three cross breams, an MDF sheet and Tasmanian oak edging.

Designing the layout.

I used  the Simple Computer Aided Railway Modeller (SCARM) to plan my layout.  A read over an old German railway construction guide gave me a lot of practical hints as to what made a good layout.

Layout as viewed from the front.

layout as viewed from the rear.

Setting up the levels for hills and track.

The frame work is wood and MDF. Before getting into some neat tricks, lets look at a time lapse.

Steps:

• The track plan is printed 1:1 on a standard printer using 40 pieces of paper, there is a trick to doing this in SCARM.
• The layout is placed on the board and a toy train is run over it, just to get a feel for what it will be like to interact with.
• Spacers are cut on a table saw, so that the MDF can be set to the correct height for the track.
• Contours are cut from MDF using a jigsaw and the track carver up and placed on top of the MDF.
• Everything is assembled, a brad gun and wood glue is a quick way to get this done. I screw down the MDF, without glue, so I can  run wires later.

Train storage Cabinet.

I built a cabinet to hold the trains and keep them dust free.

• It is build like a picture frame, but I used the table saw to create a ‘grove cut’ on the frame.
• The grove allows two pieces of acrylic to slide like doors in the frame.
• If your not 100% on table saws, this video is terrific. (10:20 explains grove cuts).
• Using acrylic instead of glass lets me insert the doors after assembly (acrylic bends)
• The wood is Tasmanian oak (to match the table) and the finish is Linseed oil followed by a glossy furniture polish.
  • Frame Cutting  in Tasmanian oak is fraught with random peril. If you cut the long edges first, you can reuse failed cuts for the short edges, saving timber.

Rule of thumb. If you would you would not be happy with this kind of material on the surface of whatever you are coating, remove your finger prints.

• So a very thin coat of paint is 0.02mm, but often thicker.  So wash your hands, then it’s probably OK to touch. But don’t “Pizza and Paint”.
• Thermal paste on your CPU is 0.07mm  to 0.12mm thick, So Pizza hands are a definite problem. A single normal finger print may well produce a small but noticeable effect to cooling. A well handled CPU with a few prints is probably not good, you would not leave scraps of plastic wrap on the CPU after all.
• Some glues may dilute your finger print and not care (super glue). While other (silicone adhesives) will probably bond poorly.
• Solder – The NASA soldering standards (NASA_STD_8739 .3) state: “When handling metal surfaces that are to be soldered is unavoidable, clean, lint-free gloves or finger cots shall be used. “. Many commercial soldering standards also follow this advise for handling of both solder and parts.
  • Whats interesting is that some manufactures are particularly concerned about what is on your hands (moisturisers and hand lotions cited as being particularly problematic to solder).
  • The finger print contamination of solder joints is often resolved by just keeping the joint hot until the solder takes. This extra heating burns of enough contaminate to allow solder to flow, but can damage components amongst other problems.
  • UPDATE: The new IPC standards (IPC-J-STD-001ES), which NASA, and many other companies, have adopted, don’t mention fingers or gloves specifically. They only broadly reference that handling mechanisms stall not contaminate the board or parts.

So I present the code, updated to work on the latest platform. As per the last article:

• This is not an intro to progmem article. The readership level is set at those who are already familiar with the arduino PROGMEM documentation here and the use of the F() macro and __FlashStringHelper*.
• Its’ designed as a reference on how to accomplish many different common tasks in PROGMEM.
• It’s  here  to save you the “lets see how to make this work” time and communicate common pitfalls.
• The code is well documented, so you should be able to find what you need quickly.
• There is data declarations out front,  assorted unit tests in setup() and a simple unit testing framework at the end of the file.
• Some of the examples have  //JBYCDMUS after the line. This stands for “just because you can, doesn’t mean you should” implying It works but is not recommended.
• To use this search for the method you need to use, and see it running in working tested code.

//----------------------------------------------------------------------------------//
//                                    BUSYDUCKS.COM                                 //
//                           _         _                  _                         //
//                         ( o)>     ( o)<     __       ( o)<                       //
//                      ____\\    ____\\   __ (.. )  \\\_\\                         //
//                 ~~~~\_///__)~~\_///__)~~\_\\V__)~~\_____)~~~~~                   //
//                                                                                  //
//                            Making you pro-duck-tive                              //
//                                                                                  //
//  Author: Duckman   Date: 08/02/16   Ver: 1.6   Licence: Creative Commons (by-sa) //
//                                                                                  //
//  Demonstrates the use of PROGMEM.                                                //
//  Compile with Arduino environment 1.6 or later                                   //
//                                                                                  //
//  Permision given to freely copy/paste "code snippets" into your own code. For    //
//  other uses (e.g. derivative works) the Creative Commons Attribution Share-      //
//  alike license applies (cite busyducks.com). This means comerical use is ok.     //
//----------------------------------------------------------------------------------//

#if !(defined(ARDUINO) && ARDUINO >= 140)
#include <environment.h>
#endif

void setTestName(const __FlashStringHelper* name);
void setTestName(const char *name);
bool assert(bool isTrue, Print *outStream=NULL);
void pass();
void fail(Print *outStream=NULL);
void printTestSummary(Print *outStream);

/*
char,                             (1 byte)    -127 to 128 also letters i.e. 'a'     pgm_read_byte
unsigned char, byte               (1 byte)    0 to 255                              pgm_read_byte
int, short                        (2 bytes)   -32,767 to 32,768                     pgm_read_word
unsigned int, unsigned short      (2 bytes)   0 to 65,535                           pgm_read_word
long                              (4 bytes)   -2,147,483,648 to 2,147,483,647       pgm_read_dword
unsigned long                     (4 bytes)   0 to 4,294,967,295                    pgm_read_dword

For ATMEGA based arduino's double is the same as float
float, double                     (4 bytes)   -3.4028235E+38 to 3.4028235E+38       pgm_read_float
*/

//--------------------------------------------------------------------------------------------------------------
// Data structures for test
//--------------------------------------------------------------------------------------------------------------
struct Person
{
  int height;
  char *name;
  int age;
  Person *spouse;
};

//--------------------------------------------------------------------------------------------------------------
// Test Data Sets
//--------------------------------------------------------------------------------------------------------------
#define BYTE_TEST_PATTERN_DATA {0, 1, 2, 3, 4, 9, 15, 16, 21, 31, 32, 64, 100, 201, 212, 255, 7}
#define BYTE_TEST_PATTERN_SIZE 17
#define MAX_STRING_SIZE 100

//--------------------------------------------------------------------------------------------------------------
// Test Data
//--------------------------------------------------------------------------------------------------------------
//  regular data
const byte  progMem_ucharArray[]     PROGMEM = BYTE_TEST_PATTERN_DATA;
const byte  progMem_uchar            PROGMEM = 130;
const int   progMem_int              PROGMEM = -3021;
const long  progMem_long             PROGMEM = 2000000001;
const float progMem_float            PROGMEM = 3.14159265359;
const char  progMem_string[]         PROGMEM = "Snollygoster";
const char  progMem_string2[]        PROGMEM = "Problem Alchemist";
const char  progMem_string3[]        PROGMEM = "Lead Paradigm Architect";
const char  progMem_emptyString[]    PROGMEM = "";
const float progMem_floatArray[2][5] PROGMEM = {{0.2, 0.1, 0.5, 0.7, -3.2},
                                               {0.4, 0.2, 1.0, 1.4, -6.4}};

//  NB this used to be in the form "PROGMEM const char *progMem_stringArray[] =",
//  now the extra const is required.
PROGMEM const char *const progMem_stringArray[] =
{   
  progMem_string,
  progMem_string2,
  progMem_string3
};

//  STRUCTS
//  this line is a foward decleration, it allows person1 to create a valid pointer 
//  to person2 even though person2 is not defined yet.
extern const Person progMem_person2;

const char     _name[]         PROGMEM = "Papa Smurf";
const Person   progMem_person  PROGMEM = {189, (char *)_name, 32, (Person*)&progMem_person2};
const char     _name2[]        PROGMEM = "Muma Smurf";
const Person   progMem_person2 PROGMEM = {160, (char *)_name2, 41, (Person*)&progMem_person};

//--------------------------------------------------------------------------------------------------------------
// Stats
//--------------------------------------------------------------------------------------------------------------
long passCount = 0;
long failCount = 0;
long countAtLastNameChange = 0;
char currentTestName[64];

//--------------------------------------------------------------------------------------------------------------
// setup and loop
//--------------------------------------------------------------------------------------------------------------
void setup() 
{
    byte localData[] = BYTE_TEST_PATTERN_DATA;
    char buffer[MAX_STRING_SIZE];
    
    Serial.begin(9600);
    
	//JBYCDMUS = just because you can, doesn't mean you should
	
    Serial.println(F("---------------- single variable tests"));
    setTestName(F("single variable tests"));
    assert(  progMem_uchar == 130                                       ); //JBYCDMUS
    assert(  pgm_read_byte(&progMem_uchar) == 130                       );
    assert(  progMem_int == -3021                                       ); //JBYCDMUS
    assert(  progMem_long == 2000000001                                 ); //JBYCDMUS
    assert(  (int)(pgm_read_float(&progMem_float)*10000) == 31415       );
    
    Serial.println(F("---------------- array tests"));
    setTestName(F("array tests"));
    for(int i=0; i< BYTE_TEST_PATTERN_SIZE; i++)
    {
        assert(   pgm_read_byte(&progMem_ucharArray[i]) == localData[i] );
    }
    for(int i=0; i<5; i++)
    {
        //  the easy way of accessing the array
        float a = pgm_read_float(&progMem_floatArray[0][i]);
        //  another way of accessing the array same as [1][i]
        float b = pgm_read_float(((unsigned int)progMem_floatArray)+(5+i)*sizeof(float));
        a = a * 2;
        //  to check two floating points are "equal"
        assert (abs(a - b) < 0.0001                                     );
    }

    
    Serial.println(F("---------------- struct tests"));
    setTestName(F("struct tests"));
    assert(  progMem_person.height == 189                               ); //JBYCDMUS
    assert(  pgm_read_byte(&progMem_person.height) == 189               );
    //  NB: this used to be (prog_char *)pgm_read_word(&progMem_person.name) but prog_char is depreciated
    assert(  strcmp_P("Papa Smurf", (char PROGMEM *)pgm_read_word(&progMem_person.name)) == 0 );
    assert(  pgm_read_byte(&progMem_person.age) == 32                   );
    assert(  progMem_person.age == 32                                   ); //JBYCDMUS
    
    //  get person1's spouse
    Person *p= (Person *)pgm_read_word(&progMem_person.spouse);
    assert(  p == &progMem_person2                                      );
    assert(  pgm_read_byte(&p->age) == 41                               );
    //get person2's spouse
    p = (Person *)pgm_read_word(&progMem_person2.spouse);
    assert(  p == &progMem_person                                       );
    assert(  pgm_read_byte(&p->age) == 32                               );

    Serial.println(F("---------------- memory operation tests"));
    setTestName(F("memcmp [memory compare]"));
    //  compares len bytes of the memory s1 and flash s2
    byte data[] = BYTE_TEST_PATTERN_DATA;
    assert(  memcmp_P(data, progMem_ucharArray, BYTE_TEST_PATTERN_SIZE) == 0 );
    data[BYTE_TEST_PATTERN_SIZE-1] = 0;
    assert(  memcmp_P(data, progMem_ucharArray, BYTE_TEST_PATTERN_SIZE) < 0  );
    data[BYTE_TEST_PATTERN_SIZE-1] = 255;
    assert(  memcmp_P(data, progMem_ucharArray, BYTE_TEST_PATTERN_SIZE) > 0  );
    
    //  copy len bytes from flash to SRAM
    memset (data, 0, BYTE_TEST_PATTERN_SIZE);
    assert(  memcpy_P(data, progMem_ucharArray, BYTE_TEST_PATTERN_SIZE) > 0  );
    assert(  memcmp(data, localData, BYTE_TEST_PATTERN_SIZE) == 0            );
    
    Serial.println(F("---------------- string function tests"));
    
    //  ---- strcmp & strncmp Compare two strings
    setTestName(F("strcmp [string compare]"));
    assert(  strcmp_P("Snollygoster", progMem_string) == 0                ); 
    assert(  strcmp_P("sNollyGostEr", progMem_string) != 0                );
    assert(  strcmp_P("Bug", progMem_string) < 0                          );
    assert(  strcmp_P("Zoo", progMem_string) > 0                          );
    
    setTestName(F("strncmp [string compare, first n chars]"));
    assert(  strncmp_P("Snollyfoobar", progMem_string, 6) == 0            );
    assert(  strncmp_P("sNollyGostEr", progMem_string, 6) != 0            );
    assert(  strncmp_P("Bug", progMem_string, 3) < 0                      );
    assert(  strncmp_P("Zoo", progMem_string, 3) > 0                      );
    
    //  ---- strcasecmp & strncasecmp, Compare two strings, ignoring case  
    assert(  strcasecmp_P("Snollygoster", progMem_string) == 0            );
    assert(  strcasecmp_P("sNollyGostEr", progMem_string) == 0            );
    assert(  strcasecmp_P("Bug", progMem_string) < 0                      );
    assert(  strcasecmp_P("Zoo", progMem_string) > 0                      );
    
    setTestName(F("strncasecmp [string compare ignoring case]"));
    assert(  strncasecmp_P("Snollyfoobar", progMem_string, 6) == 0        );
    assert(  strncasecmp_P("sNollYGostEr", progMem_string, 8) == 0        );
    assert(  strncasecmp_P("Bug", progMem_string, 3) < 0                  );
    assert(  strncasecmp_P("Zoo", progMem_string, 3) > 0                  );
    
    //  ---- strcpy, strlcpy & strncpy: makes a copy of a string
    setTestName(F("strcpy [copy a string]"));
    clear(buffer, MAX_STRING_SIZE); //empty string buffer
    assert(  strcpy_P(buffer, progMem_string) == buffer                   );
    assert(  strncmp(buffer, "Snollygoster", MAX_STRING_SIZE) == 0        );
    
    setTestName(F("strlcpy [copy a string of maximim size, ensure null terminated result]"));
    char smallBuffer[12]; //  not long enough to hold "Snollygoster" AND the final null terminator
	
    clear(buffer, MAX_STRING_SIZE); //  empty string buffer
    clear(smallBuffer, 12); //empty string buffer

	
    assert(  strlcpy_P(buffer, progMem_string, MAX_STRING_SIZE) == 12     );
    assert(  strlcpy_P(smallBuffer, progMem_string, 12) == 12             );
    assert(  strcmp(buffer, "Snollygoster") == 0                          );
    //  This is the difference between strlcpy and strncpy, the whole string was not copied 
    //  to ensure a null terminator was present
    assert(  strcmp(smallBuffer, "Snollygoste") == 0                      );
	
    
    setTestName(F("strncpy [copy a string of maximim size, null terminate iff space allows]"));
    clear(buffer, MAX_STRING_SIZE); //  empty string buffer
    assert(  strncpy_P(buffer, progMem_string, MAX_STRING_SIZE) == buffer );
    assert(  strcmp(buffer, "Snollygoster") == 0                          );
    
    //  ---- strcat, strlcat & strncat: Concatenate two strings
    setTestName(F("strcat [join two strings]"));
    strcpy(buffer, "Chief ");
    assert(  strcat_P(buffer, progMem_string) == buffer                   );
    assert(  strcmp(buffer, "Chief Snollygoster") == 0                    );
    
	
    setTestName(F("strlcat [join two strings, limiting final size, ensure termination]"));  
    strcpy(smallBuffer, "Chief "); //smallBuffer is only 12 characters
    //  NOTE strlcat_P n = sizeof destination; while strncat_P n = number of chars to copy
    assert(  strlcat_P(smallBuffer, progMem_string, 12) == 18             );
    //  12th character is the nul terminator
    assert(  strcmp(smallBuffer, "Chief Snoll") == 0                      );
    
    strcpy(buffer, "Chief "); //smallBuffer is only 12 characters
    assert(  strlcat_P(buffer, progMem_string, MAX_STRING_SIZE) == 18     );
    assert(  strcmp(buffer, "Chief Snollygoster") == 0                    );
	
    
    setTestName(F("strncat [join two strings, limiting final size]"));
    strcpy(buffer, "Chief ");
    //  NOTE strncat_P n = number of chars to copy; while strlcat_P n = sizeof destination
    assert(  strncat_P(buffer, progMem_string, 6) == buffer               );
    assert(  strcmp(buffer, "Chief Snolly") == 0                          );    
	
    
    //  ---- strlen & strnlen: Finds the length of the string (searches for the null terminator)
    setTestName(F("strlen [find the length of a string]"));
    assert(  strlen_P( progMem_string) == 12    );
    setTestName(F("strnlen [find the length of a string, limited to n]"));
    assert(  strnlen_P( progMem_string, 6) == 6                           );
    assert(  strnlen_P( progMem_string, MAX_STRING_SIZE) == 12            );
    
    //  ---- strstr: searches s1 for the first occurrence of (the substring) s2
    setTestName(F("strstr [find a string inside another string]"));
    //  one item to find
    strcpy(buffer, "A Snollygoster sounds like something you would find in a handkerchief.");
    assert(  strstr_P(buffer, progMem_string) == &buffer[2]               );
    assert(  strstr_P("foobar", progMem_string) == NULL                   );
    //  what is defined to happen when searching an empty/null strings
    strcpy(buffer, "foobar");
    assert(  strstr_P(buffer, NULL) == NULL              );
    //  this is why "if(strstr_P(s1, s2) != null){...}" is a bad idea!"
    assert(  strstr_P(buffer, progMem_emptyString) == buffer              );
        
    Serial.println(F("---------------- done"));
    if(failCount > 0)
    {
        Serial.print(passCount); Serial.println(F(" test(s) passed"));
        Serial.print(failCount); Serial.println(F(" test(s) FAILED"));
    }
    else
    {
        Serial.print(F("All tests passed (")); Serial.print(passCount); Serial.println(F(" tests rum)"));
    }
}

void loop() 
{
}

void clear(char *buffer, int len)
{
    memset(buffer, '\0', len);
}

//----------------------------------------------------------------------------------------------------------
// Testing framework data
//----------------------------------------------------------------------------------------------------------
#define TEST_NAME_BUFFER_LEN (64)
extern long passCount;
extern long failCount;
extern long countAtLastNameChange;
extern char currentTestName[TEST_NAME_BUFFER_LEN];



//----------------------------------------------------------------------------------------------------------
// Testing framework
//----------------------------------------------------------------------------------------------------------

template<typename T>
__attribute__ ((noinline)) bool assert_EQ(T a, T b, Print *outStream=NULL)
{
	bool ok = assert(a == b, outStream);
	if((!ok) && (outStream != NULL))
	{
		outStream->print(F("  error:  0x"));
		outStream->print(a, HEX);
		outStream->print(F(" != 0x"));
		outStream->println(b, HEX);
	}
}



template<typename T>
__attribute__ ((noinline)) bool assert_NEQ(T a, T b, Print *outStream=NULL)
{
	bool ok = assert(a != b, outStream);
	if((!ok) && (outStream != NULL))
	{
		outStream->print(F("  error:  0x"));
		outStream->print(a, HEX);
		outStream->print(F(" != 0x"));
		outStream->println(b, HEX);
	}
}

template<typename T>
__attribute__ ((noinline)) bool assert_GT(T a, T b, Print *outStream=NULL)
{
	bool ok = assert(a > b, outStream);
	if((!ok) && (outStream != NULL))
	{
		outStream->print(F("  error:  0x"));
		outStream->print(a, HEX);
		outStream->print(F(" <= 0x"));
		outStream->println(b, HEX);
	}
}
template<typename T>
__attribute__ ((noinline)) bool assert_LT(T a, T b, Print *outStream=NULL)
{
	bool ok = assert(a < b, outStream);
	if((!ok) && (outStream != NULL))
	{
		outStream->print(F("  error:  0x"));
		outStream->print(a, HEX);
		outStream->print(F(" >= 0x"));
		outStream->println(b, HEX);
	}
}

void setTestName(const __FlashStringHelper* name) 
{
	currentTestName[0]= 0;
	if(name != NULL)
	{
		strlcpy_P(currentTestName, (const char PROGMEM *)name, TEST_NAME_BUFFER_LEN);
	}
	
	countAtLastNameChange = passCount+failCount;
}

void setTestName(const char *name)
{
	currentTestName[0]= 0;
	if(name != NULL)
	{
		strlcpy(currentTestName, name, TEST_NAME_BUFFER_LEN);
	}
	
	countAtLastNameChange = passCount+failCount;
}

bool assert(bool isTrue, Print *outStream)
{
	if(isTrue) 
	{
		pass();
		return true;
	}
	else 
	{
		fail(outStream);
		return false;
	}
}

void pass()
{
	passCount++;
}

void fail(Print *outStream)
{
	if(outStream != NULL)
	{
		outStream->print(F("TEST FAILED: "));
		if(currentTestName != NULL)
		{
			int localTestNum = (passCount + failCount) - countAtLastNameChange + 1;
			outStream->print(F("(")); 
			outStream->print(currentTestName); 
			outStream->print(F(" [test ")); 
			outStream->print(localTestNum);
			outStream->print(F("])"));
		}
		outStream->println();
	}
	failCount++;
}

void printTestSummary(Print *outStream)
{
	if(outStream != NULL)
	{
		if(failCount > 0)
		{
			outStream->print(passCount); Serial.println(F(" test passed"));
			outStream->print(failCount); Serial.println(F(" test FAILED"));
		}
		else
		{
			outStream->print(F("All tests passed (")); Serial.print(passCount); Serial.println(F(" tests run)"));
		}
	}
}

After seeing an item stamped “return to sender”, I got thinking.
The word “return” is based in latin: re (back) + tornare (to turn). ie to turn back.

I figured I’d make few other useful phrases, that I could use in my postal affairs, which stemmed from the word ‘return’.

The List of Alternate “Returns”.

• abturn [ab = away from]:   “quick send it anywhere, but here”
• scopeturn [scope = examine]:   “on closer inspection, you can have it back”
• teleturn [tele = distance]:   “I decided it was best to send it far, far away”
• anturn [an = without]:   “I sent it back empty”
• adturn [as = toward]:   “send to this John instead”
• ambiturn [ambi = both sides]:   “I don’t want it back, you have it.”
• antiturn [anti = against]:   “this thing seems un-returnable”
• disturn [dis = not]:   “I refuse to send it back”
• poleinturn [polein = money]:   “I will sell it back to you… how’s $50 sound?”
• archturn [arch = ancient]:   “It took them way too long to return it…”
• autoturn [auto = self]:   “Everything is sent back automatically”
• agereturn [agere = agent]:   “I’m sending it back on their behalf”
• biturn [bi = turn]:   “I sent it back in two parts”
• polyturn [poly = many]:   “I sent it back broken into many parts”
• bioturn [bio = life]:   “it turned mouldy, have it back.”
• mortiturn [morti = dead]:   “it died, have it back.”
• egoturn [ego = myself]:   “I gave it back…. to myself!”
• preturn [pre = before]:   “on the way to a returner”
• postturn [post = after]:   “on the way back from the returner”
• psycheturn [psyche = mind, soul]:   “believed to be returned”
• sinturn [sin = together]:   “returned with some other stuff as well”
• phageturn [phage = eat]:   “After starting to eat it, I decided to send it back.”
• periturn [peri = around]:   “Gave it to John, to give to Bob, to give to you.”
• nomenturn [nomen = name]:   “Sent it on, to the correct person…”
• liberturn [liber = free]:   “I set it free”
• publicusturn [publicus = public]:   “gave it back, but made a big scene in public.”
• portoturn [porto = carry]:   “I had to carry it back”
• maniturn [mania = obsessive]:   “absolutely has to return everything on time”
• fraterturn [frater = brother]:   “actually, I sent it to your brother”
• identurn [idem = the same]:   “returned to you something identical”
• homoturn [home = same]:   “returned to you something similar”
• geoturn [geo = earth]:   “I buried it.”
• exturn [ex = out]:   “I threw it outside.”
• epiturn [epi = over]:   “I threw it over the fence.”
• ripariaturn [riparia = river]:   “I threw it in the lake.”

Managing arduino projects can be a nightmare because you only see the software side in your code documentation, the hardware is hard to keep track off.

To enable easy documentation of pin assignments, I created a couple of ASCII art arduinos; complete with ports, PWM and coms all marked. Simply paste as a comment into your code and marvel at your new found organisation.

I suggest altering the image (eg. a letter or X in the [ ]) to keep track of the pins you ended up using.

Find this project on gitHub

Plain Text – Arduino Pinout

Here is copy/paste-able Arduino Pinout ASCII art ready to go (tip: you can use the copy button, at the top of each ASCII art piece, to make the process easy).
     I place them in the Creatice Commons [Creative Commons Attribution (BY) license].
     Attribution via the url: “http://busyducks.com/ascii-art-arduinos”

                                      +-----+
         +----[PWR]-------------------| USB |--+
         |                            +-----+  |
         |         GND/RST2  [ ][ ]            |
         |       MOSI2/SCK2  [ ][ ]  A5/SCL[ ] |   C5 
         |          5V/MISO2 [ ][ ]  A4/SDA[ ] |   C4 
         |                             AREF[ ] |
         |                              GND[ ] |
         | [ ]N/C                    SCK/13[ ] |   B5
         | [ ]IOREF                 MISO/12[ ] |   .
         | [ ]RST                   MOSI/11[ ]~|   .
         | [ ]3V3    +---+               10[ ]~|   .
         | [ ]5v    -| A |-               9[ ]~|   .
         | [ ]GND   -| R |-               8[ ] |   B0
         | [ ]GND   -| D |-                    |
         | [ ]Vin   -| U |-               7[ ] |   D7
         |          -| I |-               6[ ]~|   .
         | [ ]A0    -| N |-               5[ ]~|   .
         | [ ]A1    -| O |-               4[ ] |   .
         | [ ]A2     +---+           INT1/3[ ]~|   .
         | [ ]A3                     INT0/2[ ] |   .
         | [ ]A4/SDA  RST SCK MISO     TX>1[ ] |   .
         | [ ]A5/SCL  [ ] [ ] [ ]      RX<0[ ] |   D0
         |            [ ] [ ] [ ]              |
         |  UNO_R3    GND MOSI 5V  ____________/
          \_______________________/
		  
		  http://busyducks.com/ascii-art-arduinos

                                      +-----+
         +----[PWR]-------------------| USB |--+
         |                            +-----+  |
         |           GND/RST2  [ ] [ ]         |
         |         MOSI2/SCK2  [ ] [ ]  SCL[ ] |   D0
         |            5V/MISO2 [ ] [ ]  SDA[ ] |   D1
         |                             AREF[ ] |
         |                              GND[ ] |
         | [ ]N/C                        13[ ]~|   B7
         | [ ]IOREF                      12[ ]~|   B6
         | [ ]RST                        11[ ]~|   B5
         | [ ]3V3      +----------+      10[ ]~|   B4
         | [ ]5v       | ARDUINO  |       9[ ]~|   H6
         | [ ]GND      |   MEGA   |       8[ ]~|   H5
         | [ ]GND      +----------+            |
         | [ ]Vin                         7[ ]~|   H4
         |                                6[ ]~|   H3
         | [ ]A0                          5[ ]~|   E3
         | [ ]A1                          4[ ]~|   G5
         | [ ]A2                     INT5/3[ ]~|   E5
         | [ ]A3                     INT4/2[ ]~|   E4
         | [ ]A4                       TX>1[ ]~|   E1
         | [ ]A5                       RX<0[ ]~|   E0
         | [ ]A6                               |   
         | [ ]A7                     TX3/14[ ] |   J1
         |                           RX3/15[ ] |   J0
         | [ ]A8                     TX2/16[ ] |   H1         
         | [ ]A9                     RX2/17[ ] |   H0
         | [ ]A10               TX1/INT3/18[ ] |   D3         
         | [ ]A11               RX1/INT2/19[ ] |   D2
         | [ ]A12           I2C-SDA/INT1/20[ ] |   D1         
         | [ ]A13           I2C-SCL/INT0/21[ ] |   D0
         | [ ]A14                              |            
         | [ ]A15                              |   Ports:
         |                RST SCK MISO         |    22=A0  23=A1   
         |         ICSP   [ ] [ ] [ ]          |    24=A2  25=A3   
         |                [ ] [ ] [ ]          |    26=A4  27=A5   
         |                GND MOSI 5V          |    28=A6  29=A7   
         | G                                   |    30=C7  31=C6   
         | N 5 5 4 4 4 4 4 3 3 3 3 3 2 2 2 2 5 |    32=C5  33=C4   
         | D 2 0 8 6 4 2 0 8 6 4 2 0 8 6 4 2 V |    34=C3  35=C2   
         |         ~ ~                         |    36=C1  37=C0   
         | @ # # # # # # # # # # # # # # # # @ |    38=D7  39=G2    
         | @ # # # # # # # # # # # # # # # # @ |    40=G1  41=G0   
         |           ~                         |    42=L7  43=L6   
         | G 5 5 4 4 4 4 4 3 3 3 3 3 2 2 2 2 5 |    44=L5  45=L4   
         | N 3 1 9 7 5 3 1 9 7 5 3 1 9 7 5 3 V |    46=L3  47=L2   
         | D                                   |    48=L1  49=L0    SPI:
         |                                     |    50=B3  51=B2     50=MISO 51=MOSI
         |     2560                ____________/    52=B1  53=B0     52=SCK  53=SS 
          \_______________________/         
         
         http://busyducks.com/ascii-art-arduinos

You may notice that the clean layout of these diagrams makes them very readable, personally I feel many graphical versions present too much information at once.

Some Updates (new models)

This idea seems to have caught on quickly, so I will keep the art coming.

Redit user plasticluthier adapted a nano version here, I thought that was spiffy, so I fixed an error tweaked it a bit and added chips and ports.

                      +-----+
         +------------| USB |------------+
         |            +-----+            |
    B5   | [ ]D13/SCK        MISO/D12[ ] |   B4
         | [ ]3.3V           MOSI/D11[ ]~|   B3
         | [ ]V.ref     ___    SS/D10[ ]~|   B2
    C0   | [ ]A0       / N \       D9[ ]~|   B1
    C1   | [ ]A1      /  A  \      D8[ ] |   B0
    C2   | [ ]A2      \  N  /      D7[ ] |   D7
    C3   | [ ]A3       \_0_/       D6[ ]~|   D6
    C4   | [ ]A4/SDA               D5[ ]~|   D5
    C5   | [ ]A5/SCL               D4[ ] |   D4
         | [ ]A6              INT1/D3[ ]~|   D3
         | [ ]A7              INT0/D2[ ] |   D2
         | [ ]5V                  GND[ ] |     
    C6   | [ ]RST                 RST[ ] |   C6
         | [ ]GND   5V MOSI GND   TX1[ ] |   D0
         | [ ]Vin   [ ] [ ] [ ]   RX1[ ] |   D1
         |          [ ] [ ] [ ]          |
         |          MISO SCK RST         |
         | NANO-V3                       |
         +-------------------------------+
         
         http://busyducks.com/ascii-art-arduinos

I have a Pro Mini project coming up, so knocked one of these out as well.

		                  D0   D1   RST
		   GND  GND  VCC  RX   TX   /DTR
        +--------------------------------+
        |  [ ]  [ ]  [ ]  [ ]  [ ]  [ ]  |
        |              FTDI              |
    D1  | [ ]1/TX                 RAW[ ] |    
    D0  | [ ]0/RX                 GND[ ] |    
        | [ ]RST        SCL/A5[ ] RST[ ] |   C6
        | [ ]GND        SDA/A4[ ] VCC[ ] |    
    D2  | [ ]2/INT0    ___         A3[ ] |   C3
    D3  |~[ ]3/INT1   /   \        A2[ ] |   C2
    D4  | [ ]4       /PRO  \       A1[ ] |   C1
    D5  |~[ ]5       \ MINI/       A0[ ] |   C0
    D6  |~[ ]6        \___/    SCK/13[ ] |   B5
    D7  | [ ]7          A7[ ] MISO/12[ ] |   B4
    B0  | [ ]8          A6[ ] MOSI/11[ ]~|   B3
    B1  |~[ ]9                  SS/10[ ]~|   B2
        |           [RST-BTN]            |    
        +--------------------------------+  
		
		http://busyducks.com/ascii-art-arduinos

How to use them

Just fill in the spaces, either with an X, or with a reference letter which you document below the ASCII art.

They can be pasted into code comments, (use /* and */ in the arduino IDE to create a block comment). They can also be useful in forums, when you need a quick arduino diagram, but don’t want to fire up an image editor.

This is a snippet from a recent project. The sketch starts out with comments that set-out how the hardware is setup, this helps me a lot when I have to look at it again in a years time. Its also great if I want to share the code, as people don’t need to dig-around in the code to see how to connect the arduino to other devices.

/*

                                      +-----+
         +----[PWR]-------------------| USB |--+
         |                            +-----+  |
         |           GND/RST2  [ ] [ ]         |
         |         MOSI2/SCK2  [ ] [ ]  SCL[ ] |   C5
         |            5V/MISO2 [ ] [ ]  SDA[ ] |   C4
         |                             AREF[ ] |
         |                              GND[ ] |
         | [ ]N/C                    SCK/13[A] |   B5
         | [ ]v.ref                 MISO/12[A] |   .
         | [ ]RST                   MOSI/11[A]~|   .
         | [ ]3V3    +---+               10[ ]~|   .
         | [ ]5v     | A |                9[ ]~|   .
         | [ ]GND   -| R |-               8[B] |   B0
         | [ ]GND   -| D |-                    |
         | [ ]Vin   -| U |-               7[A] |   D7
         |          -| I |-               6[A]~|   .
         | [ ]A0    -| N |-               5[C]~|   .
         | [ ]A1    -| O |-               4[A] |   .
         | [ ]A2     +---+           INT1/3[A]~|   .
         | [ ]A3                     INT0/2[ ] |   .
         | [ ]A4      RST SCK MISO     TX>1[ ] |   .
         | [ ]A5      [ ] [ ] [ ]      RX<0[ ] |   D0
         |            [ ] [ ] [ ]              |
         |  UNO_R3    GND MOSI 5V  ____________/
          \_______________________/
		  
		  http://busyducks.com/ascii-art-arduinos
*/

//------------------------------------------------------------------ 
// [A]		Adafruit music shield
//------------------------------------------------------------------ 
// Connect CLK, MISO and MOSI to hardware SPI pins. 
// SPI Clock, shared with SD card
#define CLK_PIN (13)       
// Input data, from VS1053/SD card
#define MISO_PIN (12)      
// Output data, to VS1053/SD card
#define MOSI_PIN (11)      

// VS1053 reset pin (unused!)
#define SHIELD_RESET_PIN  (-1)   
// VS1053 chip select pin (output)
#define SHIELD_CS_PIN     (7)      
// VS1053 Data/command select pin (output)
#define SHIELD_DCS_PIN    (6)      
// Card chip select pin
#define CARDCS_PIN (4)     
// VS1053 Data request, ideally an Interrupt pin
#define DREQ_PIN (3)       

//------------------------------------------------------------------  
// [B]		WS2811 LED stip
//------------------------------------------------------------------ 
#define LED_STIP_PIN  (8)

//------------------------------------------------------------------  
// [C]		Servo Motor
//------------------------------------------------------------------ 
#define SERVO_PIN (5)

Related Projects (based on this work)

• I modified a version of this for markdeep and made it available for download  here.
  • There is a unofficial mirror (by vanderZwan) of the markdeep work here
• A console version, by paulfantom, for terminal users is available here.

Our markdeep version (click image to download)

Stay Up To date and Provide Feedback

• Contribute  to the project on https://github.com/busyDuckman/ascii-art-arduinos
• I will check back on the facebook page for any comments, like the page to stay up to date.
  • https://www.facebook.com/BusyDucks/
• I set up a redirected URL http://busyducks.com/ascii-art-arduinos  that is both the CC-BY attribution line, and will always redirect to the latest version of these ascii art arduinos.

Version History

• 18-11-2015   markdeep version added (as suggested by vanderZwan here)
• 19-11-2015   typos fixed (as noted by oroki here)
• 21-112015    Added nano (derived from plasticluthier’s contributions ) &  Pro Mini
• 1-12-2015     Fixed typo’s spotted by Basile Laderchi. Also minor visual tweak to the arduino CPU.

Bias Lighting is a light around your display that helps you perceive contrast and reduces eye stress. It also just looks just plain cool, and create a kind of relaxed vibe.

There is a lot of theory on optimising bias lighting, but really any light will help quite a bit. So why not see if we can do anything inventive with the bias lighting colour.

The Idea

Lets use a bias lighting that changes colour, and experiment with:

• Altering the colour to  correspond with the time of a day
• Blink light to warn you that you have a meeting soon
• Having the colour change match the movement of the sun
• Changing the colour to green (or whatever) when its your “bed time”
• Using a colour change scheme set to work with your circadian rhythm

Materials

What you will need:

• Some WS2811 LED strips (approx 30cm per monitor)
• An arduino
• Some 3 core wire
• About an hour free time
• Electrical tape

Results

WS2811 RGB Strips

WS2811 strips can be acquired via Ali Express at a reasonable price, they are a strip of RGB LED’s that are individually addressable (set any LED to any colour).

Pros’

• Each chip has an active data repeater that forwards the data signal. Provided the 5v power to the strip is strong, the data signal is propagated to as many chips as you like.
• Very good value
• Strong bright lights
• Fast data channel
• Only requires one GPIO pin.

Cons’

• PWM control used for arbitrary colours is not super fast. Use of 7 colours that involve any LED being either full on or gull off produces results that work better for moving items / camera.
• Poor build quality occasionally causes minor issues
• Some visual artefacts from “fast moving pixels”.  (that can look very cool if used correctly).

The strips look like what you see below. They can be cut to length, and have a soldered connection every 30cm or so.  The arrows indicate the direction the data signal is propagated in, your controller (eg an arduino) must be connected to the left most (first) arrow. However the voltage to run the strip can be applied anywhere.

A close up look shows a chip (black part on the left) and three LED’s, the middle one being red.

Arduino Setup

For effective bias lighting, stick an adhesive LED strip to the back of your monitor, about 5cm from the top. The arduino can be mounted with stick on velcro to what have you. If necessary, connect up multiple sections of LED strips (one for each monitor) using a good 3 core wire.

The LED strip’s data line is connected to a single arduino GPIO pin configured as an output.  Its important to note the strip has an arrow on it, this arrow shows the direction the data will travel. Your data cable must be connected to the first  LED in the strip (not the last).

For my three monitors I was able to power the strip directly from my arduino, using only USB power. Though your mileage may vary.

Setup via USB Power

If you can get away with it wire up the strips shown in the top diagram. Be aware that your PC or USB hub will be responsible for providing power to a large set of lights.

Consider some issues with this:

• There will remain a significant current draw on the PC even while its in sleep mode (or running of batteries).  Be aware not all PC power supplies sleep well , they may turn their fans off even though you are drawing enough current to necessitate a low amount of active cooling.
• Your arduinos regulator will may get hot.
• Your USB port may well not be up to task.

For these reasons I would advise:

• Connection via a powered USB hub. 
• Use of a USB Doctor Device to check your current draw is sensible (eg 350mA or below, the 500mA max in the USB spec does not always pan out well)
• Configuring the brightness of the LED output (programmatically) to reduce current draw.
• Don’t connect the Arduous power jack to a DC wall adapter (see note on ground loops later in this article).

If your Arduino fails to start, or the strip displays a gaudy set of flashing bright colours, you will need to use external power to run the strip. The cutt-off regarding how long your strip can be, before problems appear varies greatly between different production runs (of the RGB strip, not the arduino).

Setup via External 5V power supply

To use an external power supply  to power the strip is not difficult (see image below). But it leaves us with the annoying issue of ground loops (see ground loop section later in this article).

To use external 5V power:

• Connect the 5V ground to both the arduinos ground and the LED strips ground.
• Set-up a 7V(ish) power for the arduinos DC Jack, and use a cheap buck DC-DC power supply (eg LM2596 module) to drop that voltage down to 5V, which is connected to the LED strips power supply.
• Resist the urge to just get a 5V power supply and connect it to both the arduous 5V pin and the LED strip, unless you have a good regulated 5V supply.

A little more safety to this circuit

The soldering of wiring to the LED strip is often problematic, and the area is often moved / stressed / bent.  This can cause the electrical connection to come loose, short or form an intermittent contact.

We may want to protect the first LED package in the strip from damage caused by too much current passing though the data line (I suggest using a 330 ohm resistor).  It’s also not a bad idea to provide a 1000uF decoupling capacitor (use an electrolytic capacitor and watch the polarity). Without this you risk a wiring issue, or power connection issue, damaging the first LED unit on the strip.

In practice, you may never have a problem without these extra components, and the damage is often repaired easily by removing the first pixel and re-soldering. So the decision is yours, a ‘best practice’ version of the above circuits is shown below.

Watchout for ground loops

If you need more power than just the USB connection you will have to give some thought to protecting your computer from ground loops.

The possibility of a ground loop exists when your arduino is connected to the PC via a USB cable and both the arduino (or connected circuitry) and the PC are mains connected in some way (even via a plug pack).

Possible solutions include:

• USB isolator (eg: this one)
• Powering the PC from battery (eg laptop)
• Powering the arduino from battery (eg 6v SLA)
• Powering the arduino and circuitry from a plug-pack and using a wireless connection to communicate to the arduino
• Don’t connect the usb cable
  • Use a network enabled board (the network ports are very well isolated). The etherten is great for this.
  • Use wifi via a $5 esp8266 (for example this one)
  • Use an infra red serial connection (2400 baud)
• Just live with a potential ground loop
  • Plug everything into the same wall socket and keep your fingers crossed.

Basic arduino code to test out the LED Strip

Now we have to check our electrical project functions as predicted. For this article, and part 2, I will be using the FastSPI_LED2 library from  fastled.io.

This demo code will create the effect shown in the video at the top of this article. If all you wanted was cool looking bias lighting, your’e done!

#include "FastSPI_LED2.h"

//----------------------------------------------------------------------------------------
//
// LED stip driver for smooth HUE trnsitions radiating from the middle of the LED strip.
//
//----------------------------------------------------------------------------------------

//Alter this to suit your setup
#define NUM_LEDS 91
#define PIN_LED 4

//This is where the individual pixel for ever LED is stored.
//use LEDS.show(); to sync the strip with the data in this array.
struct CRGB leds[NUM_LEDS];

void setup() 
{
	  // sanity check delay - allows reprogramming if accidently blowing power w/leds
   	delay(2000);

   	//to prevent too high  a power draw use 25% brightness
   	LEDS.setBrightness(64);

    //setup the LED controller
    LEDS.addLeds<WS2811, PIN_LED, RGB>(leds, NUM_LEDS);
}


void loop()
{ 
  byte hueMiddle=0;
  byte hueEdge=0;
  byte hueStep = 48;
  int maxHue = 255; //NB: hue may not be in the range 0-255, if we use a differnt hsv2rgb function.
  bool sync = false;
  
  while(true)
  {
    //pause a second
    delay(1000);

    //push the hue of the middle part of the bias light forward
    for(int s=0; s< hueStep; s++)
    {
        hueMiddle++;
        if(hueMiddle >= maxHue)
        {
          sync = true;
          break;
        }
        updateStrip(hueMiddle, hueEdge);
    }

    //have the edge of the bias light catch up to the hue in the middle
    for(int s=0; s< hueStep; s++)
    {
        hueEdge++;
        if(hueEdge >= maxHue)
        {
          sync = true;
          break;
        }
       updateStrip(hueMiddle, hueEdge);
    }

    // Reached the end of the hue cycle, wrap to the begining.
    // We do it this way because if the hueMiddle wraps around, but the
    // hueEdge remains before the end, then a full rainbow is creted
    // when updateStrip smooths the pixels over the strip
    if(sync)
    {
       hueMiddle = 0;
       hueEdge = 0;
       sync = false;
    } 
  }
}


// This method creates a smooth transition of pixels, from one hue in the middle
// to another hue at the edge.
//
//note: Could be faster with symetry away from middle.
//note: Could be faster with integer math.
//note: Because of the long delay, this does not need to be fast.
void updateStrip(byte hueMiddle, byte hueEdge)
{
    float mid = NUM_LEDS/2;
    int hueDiff =  hueEdge - hueMiddle;
    for(int i = 0; i < NUM_LEDS; i++) 
    {
        //get the hue for the pixel
        CRGB pixel;
        float h = abs(i-mid)/mid; //0 at mid, 1 at edge
        h *= hueDiff; //0 at mid, hueDiff at edge
        h += hueMiddle; //hueMiddle at mid, hueEdge at edge

        //set the pixel
        hsv2rgb_spectrum(CHSV((byte)round(h), 255, 255), pixel);
        leds[i] = pixel;
    }
    delay(150);
    LEDS.show();
}

What’s next?

In a follow-up article (part-2) we will cover syncing your arduino to the computers clock, choosing good colours for different times of the day and using your location to calculate where the sun is (in case you want to tune your your lighting to the time of the day).

Today, after an errant purchase, I am a little peeved at how certain companies deceive consumers with electrical smoke and mirrors. So I am creating the tag “Elec-TRICK-s” and going through devices that are tricking you into making a purchase.

Yes, this is nothing new, there are a bunch of companies/devices out there that peddle complete BS.  What is unique to electronics is the way good devices can be turned into crap devices for the sake of saving 20 cents on parts. On the scale of mass production this is a great saving. For millions of consumers this is just bad news. You would have much rather paid the extra 20c and received something that’s not junk.

The Trick.

To start things of, I bring to your attention this pair of speakers. They retail for about $15 in various Australian electronics shops. But don’t be fooled by the fact its a pair of speakers with a stereo plug, it is in fact a mono speaker set.

In case there is any doubt, the cable running from the plug to the speaker has only two wires, I cut it off and stripped it back, as I needed the speaker for parts anyway. The tip and middle section are simply shorted together, the cable is mono.

Now, nowhere on the packaging does the item claim to be stereo.  There is no left speaker / right speaker markings. There is no overstep of a legal line in the sand. However, one would assume two speakers on a stereo plug is a stereo sound device. The relative saving of not making the device stereo is minimal. and 99% of people would be fooled.  There are plenty of stereo devices in the same price bracket, so it’s not like you would be wary.  Checking computer speakers to see if they are in fact a stereo devices feels like checking a car to see if there is actually an engine inside.

The lesson: “If your radio / speakers / whatever does not explicitly say stereo, then they probably aren’t.

Stay tuned, next up the shenanigans of the common alarm clock.