Multi-color (RGB) LED lightstrips seem to be very popular at the moment, so I set out to control them with an Omega. The strips I purchased seem to be wired much the same as the majority of lightstrips: all LED anodes are tied together to a common node (+12V for my strips), while the cathodes of each color are also tied together, but at the other end of a current limiting resistor. Therefore my lightstrips have a white wire connected to a node labeled +12V, and there are red, green, and blue wires corresponding to the common connections for the red, green, and blue LEDs (respectively). If I connect a power supply such that 12Vdc is applied to the +12V wire and then connect the red wire to the power supply's ground (0V) terminal, all of the red LEDs in the strip light up, with around 180mA flowing. Similar results are achieved for grounding the blue wire or green wire, with typical current around 160 to 180mA. The Omega's GPIO pins can't handle this much current, so I used a simple interface circuit, one for each color (and tying the power supply's ground (0V output) to the Omega's ground:

To control the LEDs, I just issue a fast-gpio pwm command like this:

 fast-gpio pwm 14 200 50

This command produces a 200Hz square wave output with 50% duty cycle at GPIO14 (where I have my red LED interface circuit connected). Similarly, I have the interface circuits for green and blue connected to GPIO23 and GPIO26, respectively. So for example, to produce violet at a relatively low brightness, I can issue the commands

fast-gpio pwm 14 200 20
fast-gpio pwm 23 200 0
fast-gpio pwm 26 200 20

I have noticed that setting the duty-cycle to 0 doesn't actually produce a 0% duty-cycle, but there are actually very short pulses output (probably intended to keep servos "happy"), so the command

fast-gpio pwm 23 200 0

actually causes the green LED to glow very dimly. However, since the red and blue LEDs are operating at 20% duty-cycle, the green isn't really noticeable. To remedy this situation, you can use a number above 100 to turn a given color OFF. To save from having to issue a full fast-gpio command for each color, I wrote the following sh script:

#!/bin/sh
if [ $1 -gt "100" ]
then
   echo "value is over-range"
   echo "use a whole number from 0 to 100"
elif [ $1 -lt "0" ]
then
   echo "value is under-range"
   echo "use a whole number from 0 to 100"
elif [ $1 -eq "0" ]
then
   fast-gpio pwm 14 200 101
else
   fast-gpio pwm 14 200 $1
fi

I saved the script under the filename red, and made similar scripts for green and blue, substituting 23 for 14 in the green script, and 26 for the blue script. I also typed

chmod 744 red
chmod 744 green
chmod 744 blue

to give me (the file owner) execute permissions for each script. So now, for example, to get a violet color at around medium brightness, I type the following at the user prompt

red 50
blue 50
green 0

The scripts check to make sure that the user types a value between 0 and 100, and also substitutes 101 for 0, as noted above, to turn a given color off. I recently used this light strip to decorate a table at an event, and the effect was very well received.

Note: With the LED strips I've tested, a 50% duty cycle is actually a lot brighter to me than halfway between fully on (100% duty-cycle) and fully off. I actually used a duty-cycle value of around 30 to achieve a medium brightness.

Also, the 20k resistor in the circuit is not strictly necessary if the circuit is connected to GPIOs set as outputs. This resistor is used to keep the driver turned off if the GPIO pin is left as an input (high impedance) without internal pull-ups or pull-downs (the default state for most of the GPIOs upon boot-up.

Here you go - can't say you haven't gotten a round tuit anymore!

I recently spent a couple of hours debugging a boot problem with the Omega, and I thought it would be a good idea to pass on what I discovered.

I am using the following circuit to control high-brightness LEDs connected to the Omega's GPIO pins:

The circuit works fine, allowing around 180mA to flow through the LED when the connected GPIO pin is driven high (and 0mA when the pin is driven low). However, when the circuit is connected to GPIO1, the Omega refuses to boot when power is removed and reapplied. If the circuit is connected AFTER the Omega is connected to power, the Omega boots properly AND will reboot when the reset button is pressed. The problem only occurs when power is applied after the circuit is connected.

Each of my four Omegas exhibited the same behavior, and after I checked and rechecked my circuit and connections multiple times, I considered the possibility that the voltage level of the GPIO1 pin was affecting the boot sequence. So I checked the recently unveiled Omega schematic, and I see (on the schematic's last page) that GPIO1 apparently is being polled to see where the Omega's boot code is located. GPIO is pulled high via a 10k resistor (the node labeled "LED1" is connected to GPIO1 on page 1 of the schematic):

My circuit's impedance is low enough that the pin is at a low logic level on power-up, and the Omega doesn't boot. I haven't played with the other similarly connected nodes in the above diagram, so I can't say if other GPIO pins are also vulnerable to this problem.

I expect that this behavior will be spelled out in user documentation, but as yet I haven't seen this mentioned elsewhere.

Yes, GPIO12 appears to be coded to be an input. perhaps in the mode settings for the AR9331. For now we can PROBABLY use it as a general-purpose input, but I personally would not do so until we at least have schematics for the Omega.

GPIO8 is a little more confusing to me, mostly because the Atheros AR9331 spec sheet seems to ignore this I/O pin in the section on GPIO registers. This suggests to me that the pin may be reserved for some future functionality. It's probably okay to use GPIO8 for experimenting, but I wouldn't use it in a finished product.

I have tested GPIO pins 8 and 12 using the Console and also from the command line using fast-gpio commands.

Let's just say that for GPIO8, the Console's GPIO Tool is messed up! I established a terminal SSH session in PuTTY, and using fast-gpio commands could set GPIO8 as an output or an input; as an output, I could write HIGH or LOW values to the pin and read these values back again, and as an input the fast-gpio read command reports "1" (HIGH) for input voltages above 1.54V and "0" (LOW) for input voltages below 1.48V. Since the I/O runs off of 2.5V (my 2.5V node was at 2.7V), these are pretty reasonable threshold numbers (though they don't agree with the AR9331 spec, but we can talk about that another time). Oddly enough, the Console's GPIO Tool DOES report the correct logic level of the pin after the Sync button is pressed. I think the Console's GPIO Tool code is to blame. I have today submitted a helpdesk ticket for this issue.

GPIO12 is just as bizarre! Regardless of the Console's GPIO Tool settings OR fast-gpio commands, the pin is stuck in the INPUT direction and appears electrically as if it has a weak pull-down resistor to ground (though the resistance is voltage-dependent, so I suspect that a FET might be used instead of an actual resistor). If a voltage above 1.54V is presented to the pin, fast-gpio reads show a logical HIGH state, and below 1.48V show the pin as LOW. The Console's GPIO Tool also reports the correct pin logical state after the Sync pin is clicked. I have also submitted a helpdesk ticket for this issue.

An additional graph and corresponding data for a "typical" GPIO pin are presented below:

Some comments are in order:

The Vol(measured) and Vol(measured) are plotted against the voltages as taken from the current SoC (AR9331) specification. Note that although Voh(typ) is specified at 2.4V, the actual output voltage drops below this value for output current of around 8mA. However, the measured output is always above the 0.7V Vih spec, so if the output is connected to another GPIO pin configured as an input, Voh will always be interpreted as a logical HIGH for currents up to 30mA.

For Vol, the situation is a bit more complicated. For load currents below about 4mA, the Vol is always below Vol(typ) - specified as 0.1V, but rises above it as load current increases. At about 12mA, Vol increases above the 0.3V specification for Vil, which means that if the output is connected to another GPIO pin configured as an input, it MAY not be interpreted as a logical LOW. Then if load current is increased above about 24mA, the Vol actually rises above the Vih level (0.7V). This means that for load currents above 24mA, a "LOW" Vol WILL BE interpreted as a logical HIGH if connected to a GPIO pin configured as an input.

The points to understand are this:

• the specified values of Vol and Voh are only valid for output currents of up to 4mA and 8mA respectively, and
• a GPIO pin configured as an output and set to a LOW level may not be interpreted as a LOW if connected to another GPIO pin configured as an input IF the output load current is greater than about 8mA, and it WILL be interpreted as a HIGH level for load current above about 24mA. If you are using LEDs to show the state of output pins, use current-limiting resistors. I HIGHLY recommend using low-current LEDs (LEDs that have adequate illumination at 2mA). Also realize that LEDs with forward voltage rating above 2.2V may not light up well when connected between a GPIO pin and ground. Some green and yellow LEDs (and nearly all blue and white LEDs) fall into this category.

[For the purists out there, the current values for Voh technically should be shown as negative numbers, since positive current is defined as current flowing into a node. I showed all currents in absolute values (i.e. magnitude only) to make it easier to show all of the output curves in a single quadrant for graphing ease.]

I have done some additional testing on another Omega, and the data shows these GPIO outputs have the same V/I characteristics. I'll post the data and graphs soon.

I have also done testing at levels of output current from 0-30mA, with data points at every 1mA step, which gives a higher resolution view of the V/I curves. I will also post this data and graph with datasheet values superimposed. There's a lot of useful information to be taken from the graph, so I will include my conclusions. I hope to have these posts completed in the next few days (it's a busy weekend!).

Have you tried a factory reset? Offhand, this looks to me like a possible baud rate issue, but it could be a number of other things that can mess up communications. If you're not interested in doing a factory reset, you might want to tinker with your serial communications settings (baud rate, data length, number of stop bits, parity, and flow control). My PuTTY settings for the Omega are: baud rate = 9600, data length = 8 bits, 1 stop bit, parity = none, flow control = Xon/Xoff).

@Lazar-Demin,

Feel free to do so.

I have measured and plotted Output Voltage vs. Output Current for the GPIO pins (0, 1, 6, 7) on my Onion, and the results are shown below in spreadsheet. These are only measurements of a single Onion, so the results do not give any indication of chip-chip or lot-lot variations. Nonetheless they offer a glimpse of what you might expect (making the HUGE assumption that my Onion is representative of the "average" Onion). I have noted that my Onion's V25 node was actually reading 2.68V, so another table and graph were plotted to show the expected Output High values (Voh) for V25 = 2.5V. I hope this information is valuable to other hobbyists/designers/makers.

GPIO output voltage vs. output current.xlsx

@Guest,

The maximum length of the LED strip ultimately depends on the current handling of the interface circuit. The Omega GPIO pins can sink or source upwards of 30mA - see my post on this at https://community.onion.io/uploads/files/1456930109030-gpio-voltage-curves.png

The interface circuit I designed was specifically for a single 5 meter strip containing 150 RGB LEDs, with a maximum current of around 180mA. The 2N3904 is only rated for 200mA maximum collector current, so a different transistor would be needed for longer strings. The value of R1 is likely to change if the replacement transistor's gain is different from that of the 2N3904.

I also have a simple Python script (see below, and available at https://gist.github.com/jverive/a24a206154ff751e67437a57ae88a154) for controlling these strips with relays, but it doesn't use PWM, so lights are either off or full brightness (electro-mechanical relays don't work well with PWM). Note that this script imports "omega_gpio", which can be found (omega_gpio.py) on GitHub at https://github.com/BravoPapa/OmegaGPIO

# filename: colors.py
# written February, 2016
# last edit: February 22, 2016
# 
# This is a Python 2.7 script for controlling some relays attached
# to an Omega Onion microcontroller board. This specific code was written
# for a relay control board with four separate relays, each having a set of SPDT contacts.
# The drive circuitry energizes a relay when the input signal is at a low voltage
# (logic LOW), and de-energizes the relay when the input signal is at a HIGH
# logic level. This may seem "backwards", so the script corrects for this (see the 
# variable assignments below).
# 
# For my application, three of the relays are being used, each
# relay's "normally open (NO)" contact connected to the common anode of a 
# string of red, green, or blue LEDs; the common contact for each of the relays
# is connected to a +12V source (the LED strings have internal series current
# limiting resistors). Finally, the common anodes for all or the strings are
# connected together and this connection is then tied to the ground (0V) terminal
# of the 12V power supply. To turn on a given color, we send a LOW to the 
# corresponding GPIO pin. See below for color:pin assignments.
#
# The script is very simple, asking the user to choose a color to be illuminated. 
# Options are as follows:
#
#     'r' - red     (illuminate red LEDs)
#     'y' - yellow  (illuminate red and green LEDs)
#     'g' - green   (illuminate green LEDs)
#     'c' - cyan    (illuminate green and blue LEDs)
#     'b' - blue    (illumintae blue LEDs)
#     'v' - violet  (illuminate red and blue LEDs)
#     'w' - white   (illuminate red, green, and blue LEDs)
#     'k' - black   (turn off all LEDs)
#     'q' - quit execution
#     'i' - (i)nitialize GPIO pins (only needed if colors aren't responding)
# Note that the user input is case sensitive: only lower case letters will be recognized
# as valid inputs. All other characters will not affect the illuminated colors. Also note
# that the color choices are limited (for example, no pink or orange). This is because any
# colors other than the displayed choices require intensity modulation of the various
# component colors, and relays are not really suited for this purpose.
#
#

# the 'sleep' routine adds some delays to give the user time to interpret the screen
# results. All instances of sleep() may be deleted without changing the script's 
# functionality.
#
 
from time import sleep

# import the functions for controlling the GPIO port pins
#

import omega_gpio

# initialize variables to reflect GPIO port pins
#
RED = 0    #GPIO port 0 pin controls red LEDs
GREEN = 1  #GPIO port 1 pin controls green LEDs
BLUE = 6   #GPIO port 6 pin controls blue LEDs

# initialize variables to represent ON and OFF states. Since the LED strings are turned
# ON with a LOW logic level signal and turned OFF with a HIGH logic level (which may
# seem counter-intuitive), we create variables named ON and OFF to represent the signal
# levels instead of using HIGH and LOW (or 1 and 0). This improves readability.
#
ON = 0
OFF = 1

# main program execution starts here:
#
while 1:
  sleep(1)
  print ""
  print ""
  print "r - (r)ed      (illuminate red LEDs)"
  print "y - (y)yellow  (illuminate red and green LEDs)"
  print "g - (g)reen    (illuminate green LEDs)"
  print "c - (c)yan     (illuminate green and blue LEDs)"
  print "b - (b)lue     (illumintae blue LEDs)"
  print "v - (v)iolet   (illuminate red and blue LEDs)"
  print "w - (w)hite    (illuminate red, green, and blue LEDs)"
  print "k - blac(k)    (turn off all LEDs)"
  print "q - (q)uit execution"
  print "i - (i)nitialize LED controller (all LEDs will be turned OFF)"
  print ""

  reply = raw_input('What color is desired? (r,y,g,c,b,v,w,k,q):')
  if reply == 'q':
    break
  elif reply == 'r':
    omega_gpio.setoutput(RED, ON)
    omega_gpio.setoutput(GREEN, OFF)
    omega_gpio.setoutput(BLUE, OFF)
  elif reply == 'y':
    omega_gpio.setoutput(RED, ON)
    omega_gpio.setoutput(GREEN, ON)
    omega_gpio.setoutput(BLUE, OFF)
  elif reply == 'g':
    omega_gpio.setoutput(RED, OFF)
    omega_gpio.setoutput(GREEN, ON)
    omega_gpio.setoutput(BLUE, OFF)
  elif reply == 'c':
    omega_gpio.setoutput(RED, OFF)
    omega_gpio.setoutput(GREEN, ON)
    omega_gpio.setoutput(BLUE, ON)
  elif reply == 'b':
    omega_gpio.setoutput(RED, OFF)
    omega_gpio.setoutput(GREEN, OFF)
    omega_gpio.setoutput(BLUE, ON)
  elif reply == 'v':
    omega_gpio.setoutput(RED, ON)
    omega_gpio.setoutput(GREEN, OFF)
    omega_gpio.setoutput(BLUE, ON)
  elif reply == 'w':
    omega_gpio.setoutput(RED, ON)
    omega_gpio.setoutput(GREEN, ON)
    omega_gpio.setoutput(BLUE, ON)
  elif reply == 'k':
    omega_gpio.setoutput(RED, OFF)
    omega_gpio.setoutput(GREEN, OFF)
    omega_gpio.setoutput(BLUE, OFF)
  elif reply == 'i':
    # If the relays are not responding, the GPIO pins must be re-initialized. 
    # Note: 'out' is previously defined in the omega_gpio library we imported;
    # if instead we had wanted the pins to be inputs, we would have initialized them to 'in'.
    #
    omega_gpio.initpin(RED, 'out')
    omega_gpio.initpin(GREEN, 'out')
    omega_gpio.initpin(BLUE, 'out')
    omega_gpio.setoutput(RED, OFF)
    omega_gpio.setoutput(GREEN, OFF)
    omega_gpio.setoutput(BLUE, OFF)

@Kit-Bishop,

I have found that the PWM at 100% doesn't quite turn the LEDs off, but rather they illuminate dimly. I can compensate for this at the command line by issuing

fast-gpio pwm 15 200 101
fast-gpio pwm 16 200 101
fast-gpio pwm 17 200 101

Is this your experience as well? I haven't done much playing around with servos, but I'm presuming that the "thin" pulse stream at 100% is meant to keep servos happy (since they generally don't like constant DC waveforms).

@Guest,

Here are photos of the light strip. The strip itself is 5 meters long, and is usually sold wrapped around a spool:

Multi-color (RGB) LED lightstrips seem to be very popular at the moment, so I set out to control them with an Omega. The strips I purchased seem to be wired much the same as the majority of lightstrips: all LED anodes are tied together to a common node (+12V for my strips), while the cathodes of each color are also tied together, but at the other end of a current limiting resistor. Therefore my lightstrips have a white wire connected to a node labeled +12V, and there are red, green, and blue wires corresponding to the common connections for the red, green, and blue LEDs (respectively). If I connect a power supply such that 12Vdc is applied to the +12V wire and then connect the red wire to the power supply's ground (0V) terminal, all of the red LEDs in the strip light up, with around 180mA flowing. Similar results are achieved for grounding the blue wire or green wire, with typical current around 160 to 180mA. The Omega's GPIO pins can't handle this much current, so I used a simple interface circuit, one for each color (and tying the power supply's ground (0V output) to the Omega's ground:

To control the LEDs, I just issue a fast-gpio pwm command like this:

 fast-gpio pwm 14 200 50

This command produces a 200Hz square wave output with 50% duty cycle at GPIO14 (where I have my red LED interface circuit connected). Similarly, I have the interface circuits for green and blue connected to GPIO23 and GPIO26, respectively. So for example, to produce violet at a relatively low brightness, I can issue the commands

fast-gpio pwm 14 200 20
fast-gpio pwm 23 200 0
fast-gpio pwm 26 200 20

I have noticed that setting the duty-cycle to 0 doesn't actually produce a 0% duty-cycle, but there are actually very short pulses output (probably intended to keep servos "happy"), so the command

fast-gpio pwm 23 200 0

actually causes the green LED to glow very dimly. However, since the red and blue LEDs are operating at 20% duty-cycle, the green isn't really noticeable. To remedy this situation, you can use a number above 100 to turn a given color OFF. To save from having to issue a full fast-gpio command for each color, I wrote the following sh script:

#!/bin/sh
if [ $1 -gt "100" ]
then
   echo "value is over-range"
   echo "use a whole number from 0 to 100"
elif [ $1 -lt "0" ]
then
   echo "value is under-range"
   echo "use a whole number from 0 to 100"
elif [ $1 -eq "0" ]
then
   fast-gpio pwm 14 200 101
else
   fast-gpio pwm 14 200 $1
fi

I saved the script under the filename red, and made similar scripts for green and blue, substituting 23 for 14 in the green script, and 26 for the blue script. I also typed

chmod 744 red
chmod 744 green
chmod 744 blue

to give me (the file owner) execute permissions for each script. So now, for example, to get a violet color at around medium brightness, I type the following at the user prompt

red 50
blue 50
green 0

The scripts check to make sure that the user types a value between 0 and 100, and also substitutes 101 for 0, as noted above, to turn a given color off. I recently used this light strip to decorate a table at an event, and the effect was very well received.

Note: With the LED strips I've tested, a 50% duty cycle is actually a lot brighter to me than halfway between fully on (100% duty-cycle) and fully off. I actually used a duty-cycle value of around 30 to achieve a medium brightness.

Also, the 20k resistor in the circuit is not strictly necessary if the circuit is connected to GPIOs set as outputs. This resistor is used to keep the driver turned off if the GPIO pin is left as an input (high impedance) without internal pull-ups or pull-downs (the default state for most of the GPIOs upon boot-up.

@Lazar-Demin

Thanks a bunch! Your code almost worked, but the syntax that actually worked (to control an LED connected to GPIO 14) was as follows:

#!/bin/sh
if [ $1 -gt "100" ]
then
   echo "value is over-range"
   echo "use a whole number from 0 to 100"
elif [ $1 -lt "0" ]
then
   echo "value is under-range"
   echo "use a whole number from 0 to 100"
elif [ $1 -eq "0" ]
then
   fast-gpio pwm 14 200 101
else
   fast-gpio pwm 14 200 $1
fi

Indeed, sh is extremely picky about syntax, but once I saw some working examples, I was able to develop working code. By the way, this code is stored as file called red, so the way it is used is as follows:

red value

where value is the duty-cycle percentage requested, from 0 for minimum brightness (OFF) to 100 (fully on). For example, to set the duty cycle to 40% we enter

red 40

which lights up the LED using a 50% duty cycle. One peculiar aspect of PWM using fast-gpio is that at 0% duty-cycle (which should theoretically have no ON time) the output still contains pulses (probably to satisfy servos), so an LED still illuminates - though dimly. Using a duty-cycle value greater than 100:

fast-gpio pwm 14 200 101

actually produces 0% duty cycle. Since this is not intuitive for the average intended user of my code, I substitute 101 for 0 in the code. Cheating? Maybe, but the user is none the wiser!

@Lazar-Demin,

Follow-up Python-newbie question: how do I make calls to fast-gpio in Python?

Jeff

I'm using the Omega to illuminate LEDs, and for this purpose software PWM works great. For example, the command-line command

fast-gpio pwm 14 200 25

lights a (red) LED connected to GPIO 14 at 25% duty cycle with a frequency of 200 Hz.

I have created a simple sh script ("red.sh) containing just a single line:

fast-gpio pwm 14 200 $1

so I can just type

red 25

at the command line to obtain the same results. Everything is working fine, but I'd like to do some range checking on the argument $1 to ensure that it is between 0 and 100 (duty cycle between 0% and 100%). I've tried things like

if [$1 < 0] then echo "value is under-range"
else if [$1 > 100] then echo "value is over-range"
else fast-gpio pwm 14 200 $1

but I keep getting errors. How do I accomplish this simple task? I've tried looking at various tutorials on "sh scripting" but nothing is working so far. I admit to being a total newbie at Linux and its variants, so I don't really know where to turn. I believe that the Omega is running a version of OpenWRT, but I haven't been able to uncover much about scripting in OpenWRT. Help!!

Are there any Python libraries for outputting PWM signals on GPIO pins without having to use the PWM Expansion Module? I am controlling some LED light strings by GPIO pins (through a simple interface circuit), and would like to be able to vary brightness. I'm getting comfortable with Python programming on the Omega, and this would be a reasonable application for software PWM (doesn't require the precision of dedicated PWM hardware.

I recently spent a couple of hours debugging a boot problem with the Omega, and I thought it would be a good idea to pass on what I discovered.

I am using the following circuit to control high-brightness LEDs connected to the Omega's GPIO pins:

The circuit works fine, allowing around 180mA to flow through the LED when the connected GPIO pin is driven high (and 0mA when the pin is driven low). However, when the circuit is connected to GPIO1, the Omega refuses to boot when power is removed and reapplied. If the circuit is connected AFTER the Omega is connected to power, the Omega boots properly AND will reboot when the reset button is pressed. The problem only occurs when power is applied after the circuit is connected.

Each of my four Omegas exhibited the same behavior, and after I checked and rechecked my circuit and connections multiple times, I considered the possibility that the voltage level of the GPIO1 pin was affecting the boot sequence. So I checked the recently unveiled Omega schematic, and I see (on the schematic's last page) that GPIO1 apparently is being polled to see where the Omega's boot code is located. GPIO is pulled high via a 10k resistor (the node labeled "LED1" is connected to GPIO1 on page 1 of the schematic):

My circuit's impedance is low enough that the pin is at a low logic level on power-up, and the Omega doesn't boot. I haven't played with the other similarly connected nodes in the above diagram, so I can't say if other GPIO pins are also vulnerable to this problem.

I expect that this behavior will be spelled out in user documentation, but as yet I haven't seen this mentioned elsewhere.