Friday, April 1, 2016

Makeblock mCore Information


mCore board
The great folks over at Makeblock have created a nice little board for creating robots, the mCore.

The mCore is basically an Arduino Uno plus
  • dual motor controller
  • two serial RGB LEDs (WS2812 aka "NeoPixels")
  • piezo buzzer
  • light sensor
  • IR LED
  • IR receiver
  • button
  • header block for either a bluetooth or 2.4GHz radio
  • four RJ25 connectors for external peripherals

The board is intended to be used for teaching programming, robotics, internet of things, etc.  As a learning tool, it is primarily used with the custom version of the Scratch programming environment called mBlock.  There is also a library for regular Arduino IDE programming as well.

What is lacking, however, is a good write up on the various pin assignments used for the on-board peripherals that Makeblock added.  Thankfully, at least there is a schematic to help us out.

Pin assignments

Based on the schematic, here are the pin assignments.  Additional detail on each peripheral is provided below the table.

Arduino mCore pin assignments
D0/RXD RXD on external radio connector
D1/TXD TXD on external radio connector
D2 IR receiver input
D3~ IR LED output (HIGH = ON)
D4 M2 direction (HIGH = CCW)
D5~ M2 PWM (speed)
D6~ M1 PWM (speed)
D7 M1 direction (HIGH = CW)
D8 Buzzer output
D9~ Pin 5 on RJ25 #2
D10~ (SPI) SS Pin 6 on RJ25 #2
D11~ (SPI) MOSI Pin 5 on RJ25 #1
D12 (SPI) MISO Pin 6 on RJ25 #1
D13 (SPI) SCLK Blue LED / Serial out to WS2812 LEDs
A0 Pin 5 on RJ25 #4
A1 Pin 6 on RJ25 #4
A2 Pin 5 on RJ25 #3
A3 Pin 6 on RJ25 #3
A4 (I2C) SDA Pin 2 on all 4 RJ25 connectors
A5 (I2C) SCL Pin 1 on all 4 RJ25 connectors
A6 Light sensor input
A7 Button input, low when pressed
Arduino Pin mCore function

Motor Controller

Motor Controller
The Toshiba TB6612 is used as a dual channel motor controller.  The inputs to the controller for each motor are a PWM pin for speed and two direction pins.  The mCore designers simplified the interface such that a single Arduino digital pin controls direction (it is inverted in hardware to provide the second direction input to the motor controller) while a second PWM pin controls speed.

The M1 connector on the board is controlled by D6 (PWM speed) and D7 (direction).  When D7 is HIGH, the motor turns CW.  When D7 is LOW the motor turns CCW.

Likewise, the M2 connector is controlled by D5 (PWM speed) and D4 (direction).  However, in this case the function of D4 is reversed. When D4 is HIGH the motor turns CCW, and when it is LOW it turns CW.

Reversing the function of the two direction pins may seem odd, however, when you think about it, the motors are generally on the opposite sides of the robot so they need to turn opposite directions for the bot to move either forward or backward.  Consequently you can use the same 'direction' setting (HIGH or LOW) on both outputs to get the bot to go in one direction, for example, forward.

Serial RGB LEDs (WS2812 aka NeoPixels)

WS2812 Serial RGB LEDs
There are two WS2812 RGB LEDs on the board.  These share a pin (digital pin 13) with the traditional LED seen on most Arduino boards.  You can use any of the existing NeoPixel libraries to control these LEDs.

In addition, the pin (D13) controls a blue LED on the board so the standard Arduino blink sketch will work correctly on the mCore.

Piezo Buzzer / Speaker

 The speaker is connected to digital pin 8.  You can drive this pin using the standard Arduino tone() library call.

Light Sensor

The light sensor is a standard CdS photocell configured as a voltage divider.  This is hooked to analog pin 5 so you can read the voltage (and hence the amount of light) using analogRead().


The IR LED is simply hooked to a digital output pin (digital pin 3). You can use this to transmit data or to detect objects in front of the bot (by bouncing light off of objects and reading it with the receiver).

IR Receiver

IR Receiver
The IR receiver, on digital pin 2, is intended to be used with the included remote control. It can also be used in conjunction with the IR LED for communications between bots.  The Makeblock library includes routines to read the button presses from the remote.


This is just a basic pushbutton with a pull-up resistor hooked to analog pin 7.  When the button is pressed, the value on A7 will be low.  It can be used to start your program or pretty much any other function you program in.  Unfortunately the designers wasted an analog input with just one button.  They could have included more buttons on the same pin by simply creating a voltage divider network with each of the buttons having a different resistor (and thus a different voltage / value when reading A7).

Radio Headers

Radio headers
The bot comes with either a bluetooth or 2.4GHz radio. This is the connector for the radio.  The design allows the radio to communicate using the standard Arduino Serial() calls.

RJ25 Connectors

RJ25 Connectors
The four RJ25 connectors make it easy to connect a variety of peripherals to the mCore. The top of each connector has a color coded block to indicate the types of peripheral that can be attached.  In turn, the peripherals themselves have color coded connectors.  Hooking things up is as easy as matching the colors.
Each connector has power (+5) and ground connections along with the I2C bus clock and data pins.  The remaining two pins on each connector have either two digital or two analog port pins, depending on which connector it is.
Port 1 has digital pins 11 (PWM) & 12.  Port 2 has digital pins 9 & 10 (both PWM).  Port 3 has analog pins 2 & 3.  Port 4 has analog pins 0 and 1.

Thursday, January 14, 2016

Internet sales tax

Internet sales tax just makes no sense.  It is simply another version of interstate sales tax which also makes no sense.  The simple solution is to pay sales tax where an item is sold (it is called "Sales Tax" after all) and be done with it.

Let's look at the edge cases which are often instructive in revealing issues and problems.

1. Let's say you are traveling outside your home state and you have a flat tire.  You buy a new tire, paying sales tax in the jurisdiction where you purchase the tire, and drive home.  Do you now owe additional tax to your home state for that product (the tire) you brought into the state?  If so, haven't you been double taxed?

2. Now let's look at the exact same transaction slightly differently.  What if I live in another state and I'm now in the process of moving to my new state. During the trip, while still in my previous state of residence, I have a flat tire.  I buy a new tire in my old state and then drive across the line into my new state.  Do I owe sales tax to my new state of residence?  How is this any different than the example above?  What if I bought new tires a day (or a week, a month, a year) before I moved?  Does that change the answer?

3. What if I buy a burger at a fast food restaurant just over the state line on my way home?  Do I owe tax to my home state when I get back?  Does it matter if I consume the burger before or after I cross the state line?  What if I stay out of state for several days (thus the food is consumed, processed, and completely 'used' out of state)?

4. Do I owe sales tax to my home state on gasoline that I purchase during a trip to another state? What if I bought that gas just before crossing the line into my home state?  What if all of the gas is used in the other state?  What if only 1/2 the gas is used outside the state; do I owe sales tax on only the 1/2 I brought back?  What if that gas is only used in a rental car that stays entirely in the other state?

5. What if, during a car trip in another state, I have my oil changed and I bring that new oil back into my home state (in my crankcase)?  Would it be any different if I bought a case of oil in another state and brought it home to change my own oil?  Do I have to pay sales tax to my home on both the oil and the service or only on the oil portion of the transaction?  What if my home state doesn't tax services, only tangible products?  What if I drove 2000 miles (of the 3000 before I need another oil change) out of state; would I only owe on 1/3 of the cost?

6. What if I purchase a service in another state (say a massage or a car wash)?  Do I owe tax on the service that was entirely performed in the other state?  What if my state doesn't tax services?

7. Let's say my home state doesn't tax a particular class of item (food for example).  If I buy that item in another state do I still owe sales tax to my home state for the out-of-state transaction?

8. Compare this to adjacent cities with different tax rates.  Do I owe sales tax to my home city if I buy something in the next town over?

There are numerous other edge cases as I'm sure you can see.  These cases make it clear that interstate sales tax just makes no sense whatsoever.  There are an equal number of edge cases that apply to internet sales tax which is really no different.

The basic concept of sales tax is to pay for the costs of doing business in that area (infrastructure, police, fire, etc.).  Since you are using none of those infrastructure bits when you buy something out of state, it makes no sense to pay tax to your home state when they contributed nothing to the transaction.

In addition, there is no way to get 'credit' for the taxes you did pay at the point of sale.  Thus, any interstate taxes you pay constitute double taxation which is also unfair.

Sunday, January 5, 2014

Walgreens 15 C9 Multi-color Light Show LED Christmas light hack


After Christmas I purchased a few strands of the Walgreen "15 C9 Multi-color Light Show" LED Christmas lights (WIC 276754; UPC 049022715905).  These have 15 individually addressable LED lights (3 sets of 5 LEDs arranged as red, green, blue, orange, white).  If you can find them on sale for a few dollars, they are a great deal.

The packaging available at Walgreens
BriteStar version of the same light set

The lights are apparently manufactured by BriteStar (  Unfortunately they have very little info on their website.  It appears that they intend to sell these and other similar light sets directly but they are not quite there yet.  Maybe by next Christmas season?

Seeing these lights in the package with the little "Try Me" button made it very obvious that the bulbs were individually addressable.  The brief demo in the package provides a few patterns.  I was immediately curious if they could be hacked to do other things.  Turns out that the protocol is very simple and easily implemented with an Arduino.

Tear Down

A quick look at the string revealed several interesting things.  First, there was a transformer at the head of the string labeled 5V at 500 mA.  That seemed promising.  Second, there was a small box, near the transformer that had two lines (presumably power) going in and out of it, plus a connector for the "Try Me" button on the outside of the package.  The first bulb in the series had two wires going in and three wires going out.  That seemed interesting as well.


I started by pulling apart the small box next to the transformer.  My initial thought was that this might be the controller for the strand.  Alas, that was not the case.  In fact, this little box is only there to provide the connection point for the "Try Me" button and is otherwise useless.  However, it might provide a good place to slip in a controller (such as the Arduino Pro Mini) later!

Input for Try Me button
Closeup of the board mounted in the box

A quick test with the VOM confirmed that the strand ran on 5V DC (as listed on the transformer at the head of the strand).

Next I pulled apart the first bulb in the strand.  Inside I found a gold mine.  There was a simple board with two wires (power) coming in and three wires going out.  Two wires were obviously the power and that left one for signal. In addition to the inputs and outputs there was a bonded processor and an LED.

First bulb in the string (red)
with an added input interface wire (white)
Back of the board
I pulled apart the second and third bulb in the strand and found that the output of bulb one goes to the input pins of bulb two.  Likewise, the output of bulb two goes to the input of bulb three.


The next step was to reverse engineer the protocol between the boards.  First I hooked up the trusty DSO Nano to confirm that the third line was a data line and that it was a 5V signal.

Next, I hooked up the Saleae logic analyzer and took a look at the data signals.  After looking at the data for a bit it became obvious that there were basically two packets being sent; an "on" and an "off".  Below you can see the output of the first three bulbs.  It is clear that each board forwards it's previous state on to the next bulb after receiving a new packet.

The top line is an "on" packet (note the 4 'wide' pulses at the end).
The second line is an "off" packet (note the 4 'short' pulses at the end).
It was also obvious that we had a very simple protocol going on.  The string of lights is basically a big shift register.  Each light stores whatever it is sent, and forwards on it's previous state to the next board.  Thus, we can keep pushing packets down the line to update the entire string.  The default firmware pushes out 15 packets each time.

Here are the specs for the packets:
  • 3 start bits, each 6.25 us (microsecond) wide high followed by 6.67 us wide low pulse
  • 4 data bits, each is either a 'wide' or a 'narrow' high followed by a 4.33 us low pulse
    • A "one" is indicated by a 3.75 us wide high pulse
    • A "zero" is indicated by a 1.24 us wide high pulse
An "on" packet consists of 4 "one" data bits while an "off" packet consists of 4 "zero" bits.  The astute reader may quickly think to themselves, "I wonder what would happen if I sent something other than all zeros or all ones."  Excellent question.

PWM capability

The default firmware on the string only uses full on or full off.  However, the boards support 16 levels of brightness.  It turns out that sending any value between 0 and 15 (LSB first) will generate increasing intensity levels in the LED.  A packet of SSS (3 start bits) followed by bits 1000 will be the dim value of 1; a packet of SSS0100 is a dim value of 2; etc.

Packets (S = start bit, 1 = wide pulse, 0 = narrow pulse)
  • SSS0000 = off
  • SSS1000 = dimmer value of 1 (dimmest)
  • SSS0100 = dimmer value of 2
  • SSS1100 = dimmer value of 3
  • SSS0010 = dimmer value of 4
  • SSS1010 = dimmer value of 5
  • SSS0110 = dimmer value of 6
  • SSS1110 = dimmer value of 7
  • SSS0001 = dimmer value of 8 (half brightness)
  • SSS1001 = dimmer value of 9
  • SSS0101 = dimmer value of 10
  • SSS1101 = dimmer value of 11
  • SSS0011 = dimmer value of 12
  • SSS1011 = dimmer value of 13
  • SSS0111 = dimmer value of 14
  • SSS1111 = dimmer value of 15 (full brightness)


You might be wondering how the first board knows it is the master.  The short answer is that if you don't see any packets on your input pin, you are the master.  A very simple startup protocol is to raise your output pin high for 150 ms (milliseconds) while looking at your input pin to see if you have an upstream neighbor (who would be doing the same thing on their output pin).  If you don't see anything on your input, then you must be the master.  

There is also a failsafe in the system that if you do not see any input for approximately 20 seconds, you should become the master.  Likewise, if you begin seeing valid packets on your input, you go into slave mode and start doing whatever you are told.

Below you can see the 150 ms wide high pulse on the left that occurs at startup.  The wide white areas in the center of the display are the first regular packets being sent

Startup protocol zoomed way out (note the scale at the top of the chart).
At startup, the master sends 10 sets of "off" packets.  It appears that if a board has no current state, it simply consumes a packet and does not send anything.  You can see this in the following capture.  Each white bar represents an entire packet.  I zoomed out so you can see the cascade of the first three bulbs as packets are being sent.

Startup packet sequence

New Controller

After discovering the basics of the protocol, I quickly created an Arduio program to simulate the protocol and started controlling the string myself.  Since the Arduino doesn't directly support this protocol I had to bit bang the line.  My ultimate goal is to be able to run multiple strings of lights from a single Arduino.  Since the times are so short (as small as a single microsecond) I had to disable interrupts during the packet transmission.

Source Code

Source code for a class implementing the protocol and a quick test program is available in github.

Interpacket gap

The default firmware waits about 1.13 ms between sending packets.  This gives more than enough time for a packet to propagate all the way to the end of the strand.  This seemed wasteful to me so I shortened the gap to 100 us.  It seems to work just fine.

New Arduino based controller showing 100us interpacket gap


If anyone has suggestions for improvements please let me know.  Also, if you implement this in a project I'd love to hear about it.  Please post in the comments below.

Monday, January 23, 2012

Cell phones and driving

Read my analysis of research into cell phones and driving.  I believe that the studies done to date all suffer from some problems in scientific method.  Most of them fail to take into account what I call the 'human factor'.  Most people are not idiots, they will not continue talking on the phone (or doing any of a number of other distracting actvities; eating, hunting for a CD, changing the radio station, dealing with a fussy child, etc.) when they are in a dangerous driving situation.

Here's the simple synopsis, if cell phones are truly a big distraction, explain this chart:

Accident rates continue to drop despite exponential growth in cell phone usage.  Either people are not talking on their phone while driving, or using a phone while driving is not dangerous.  Either way, I don't think we need legislation preventing us from doing something that is clearly not a significant danger.