Skip navigation
1 2 Previous Next

Gough Lui's Blog

18 posts

One of my regular blog readers submitted an LED globe for post-mortem analysis, having failed well before the expected lifetime. I take a look inside, determine the configuration and analyze the relatively "anonymous" product which seems to show several design shortcomings which I discuss and think might be relevant to other readers at the element14 community.

 

The article is posted at http://goughlui.com/2016/06/01/failed-click-ltmr5w3k-5w-led-mr16-replacement-globe/

 

What really gets me is that many products are still designed using multiple-parallel LEDs without any current balancing mechanisms (e.g. remember emitter feedback resistors when paralleling BJTs?) and that leads to potential for a single string to be overstressed continually, fail early, and begin the cascade of failure as other LEDs are forced to soak up current in excess of their ratings, and operate in less efficient regimes resulting in greater heat production and degradation of the semiconductor material. Of course, if you went all-series, you would have an all or nothing situation and require higher voltage driver electronics, but I personally would gravitate to this arrangement for reliability reasons, or go with multiple independent channels if reliability is demanded.

 

Any comments, or stories related to LED globes or LED light designs are very much welcome.

 

- Gough

I suppose all the car owners out there love the luxury of having a remote keyfob to lock and unlock their cars, but periodically, they need their batteries replaced. Imagine my surprise when my Dad said that "the battery doesn't seem to be replaceable" ... when every remote I had met to date had a socket for some odd-ball A21 12v cell or a lithium coin cell.

 

Thanks to element14 and their prompt order fulfillment, we were on our way with nothing more needed than a soldering iron, desoldering braid, solder, superglue and an AU$1.18 part. Beats buying a new remote for $88 ... one with an unknown lifetime, but it does give pause to think why they would engineer a product in this way, and whether this inbuilt obsolescence was the right thing to do in the first place.

 

Full work-log at http://goughlui.com/2016/05/31/repair-teardown-toyota-camry-2000-remote-key-fob/

 

- Gough

As many hobbyists like to experiment with wireless devices, having a good 433.92Mhz transmitter is necessary to optimize the reliability of their systems and their range. While these modules can be finicky to use for data link purposes (and I won't go into that), they are quite simple for replicating remote control signals to control wireless switches, etc. To improve range and reliability, users often recommend buying a particular sort of module or increasing the input voltage I wanted to find out whether such strategies were effective and whether any of the low-cost modules were significantly better than the others so I decided to use the Tektronix  RSA306RSA306 I received in a RoadTest along with a probe lead from the PicoScope 2205A also from a RoadTest to investigate

 

The results are published here: http://goughlui.com/2016/05/01/shootout-four-433-92mhz-askook-transmitter-modules-compared/

I couldn't help but wonder, based on the previous posting and the discussion, exactly how did the 1 million combinations come about? Also, what are the functions of the fixed bits? Are they fixed pre-amble as my experience would suggest? Are there more hidden channels in the equipment than are used by the senders and that I know of? Can it cope with over-speed transmissions, shortened repetition delay times, less repetitions?

 

I embarked on a journey of "knowledge" by building myself a generic 433Mhz ASK/OOK transmitter that took a string of the following variables:

zero pre-low (us), zero high (us), zero low (us), one pre-low (us), one high (us), one low (us), delay (us), repetitions, data

 

I figured that, by using these timing variables, almost all my ASK/OOK fixed code protocols can be represented, thus a serial to ASK/OOK "universal" bridge was born. This was used to probe the switches and find the truth.

 

The answers are in my blog post at http://goughlui.com/2016/04/13/reverse-eng-pt-2-watts-clever-easy-off-wsmart-box-es-aus1103/

It's been a while since I've had the time to post anything around here. Luckily, I had recently just submitted my PhD thesis so that gives me a chance to take a short break and do some of the stuff that I like.

 

Recently, I came across a bunch of cheap remote controlled 433Mhz power sockets which I decided to pick up, tear down and reverse engineer on my blog site. Because of the recent discussions regarding remote control that I've been a part of on this forum, I thought it would be rather interesting to some of the people here as well. What I found was most intriguing - a fixed code system with no checksum/CRC, a 3-bit address space and 1-bit switch command for 4 variable bits in a 25-bit message, and hard coded broadcast-to-all switches including fresh un-learned switches out of the box.

 

I think it's probably worth a read as I go through the whole process from start to finish, and now I have an Ethernet bridge to the 433Mhz system built out of my efforts. It doesn't improve security, but it does improve usability. However, it's a key point that even if a system has a "learning" button and doesn't seem to respond to "other" codes that it's not necessarily secure by design. It may just give the impression of security.

Thanks to element14, I've managed to get my hands on a copy of the first hard-copy MagPi magazine. It's a great milestone for The Raspberry Pi Foundation and The MagPi. Seeing as many people around the element14 circles have already reviewed and blogged about The MagPi, I've decided to blog about it on my own site instead.

 

To find out what I think about The MagPi, head on over to http://goughlui.com/2015/08/19/surprise-package-the-magpi-arrives-by-air-in-hard-copy/

Some of you might have gotten a little suspicious seeing that I had stocked up on Wi-Pis earlier. Well, you are right to be suspicious, as I was thinking of a little Wi-Fi-based project.

 

Screenshot_2015-07-21-15-23-53.png

 

I came to the realization that a wireless network's SSID can serve a "beacon" and "advertising" opportunity. Coupled with some nefarious networking tricks on the Raspberry Pi, I can make a small device that I can carry with me to advertise my site to everyone that is nearby.


How did I do it? Find out at my posting on my blog at http://goughlui.com/2015/07/25/project-adverpising-a-wi-fi-beacon-with-raspberry-pi/

When it comes to me getting some work done, there is really only one place in the house where that happens. Coincidentally, it's the same place where I get some sleep, hack about with electronics, write code, record videos, take photos of products, etc. I call it my "room", it gets a little cramped, but that's the least of my issues. What I really don't need are interruptions. Creatives and coders would probably best sympathize with me - once you get in the "groove", find your "muse" or get in the "rhythm", the last thing you need is someone opening your door unexpectedly. Even worse is when you're trying to catch some shuteye, and someone opens the door and barges in. My family has a habit of doing this, and it's not helped by the fact I tend to have odd sleeping hours as I'm not "limited" by regular 9-5 engagements, and my hobbies often dictate being awake at odd hours.

 

Anyway, it was getting to breaking point several months ago, and I decided to try and solve it once and for all. I looked around my room to find the PiFace Control and Display I had from the Raspberry Pi New Year's Party Pack RoadTest which remained unused, as well as a Raspberry Pi Model A (original) which I bought out of curiosity, having no Ethernet port and just one USB connector. Great! Virtually everything I need to solve this problem - by making an electronic network-connected door sign which I can change at will from any computer on the network (or beyond, by tunneling through another Raspberry Pi set to expose its SSH to the world).

 

Before I continue further, I must warn everyone that this was a hack borne out of frustration, where time to a solution was the key. As a result, there are known security problems, namely no authentication, user-side validation only and web server running on an account with root privileges. Unless you can guarantee the security and non-maliciousness of the environment where the unit will be deployed, you should NOT use this as an example to set-up your own door sign. Even then, I probably have missed out a few steps, having done this a few months ago, fixing any issues I found on the fly and not writing anything down. It's more an inspiration for others to see what is possible.

 

Raspberry Pi Model A Set-Up

 

Setup of the Raspberry Pi Model A is actually quite confusing because of the limited hardware. It's probably best done interactively, so using an HDMI monitor, USB keyboard and mouse, and USB wireless network adapter. In order to do this, you will need a USB hub, preferably powered. Or, if you're sneaky like I am ... just set up the card on the Model B first, then transfer it over to the Model A once you're ready.

 

The first thing you will need to do all the normal raspi-config configuration. Expanding filesystem, overclocking, enabling SSH, setting locale, timezone, keyboard layout, disable overscan, enable SPI, change hostname, change password. The norm. To simplify wireless configuration, I decided to startx and configure Wi-Fi using the graphical utility, which seems to store any required information in /etc/wpa_supplicant/wpa_supplicant.conf. Once that's done, it's always good to keep yourself up to date with sudo apt-get update and sudo apt-get upgrade.

 

Because we will be working with the pi remotely, and we would like to find it easily, a static IP was allocated by modifying /etc/network/interfaces - in my case, to 192.168.0.36.

 

iface wlan0 inet manual

wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

iface default inet static

address 192.168.0.36

netmask 255.255.255.0

gateway 192.168.0.1

 

Not only that, we also need to modify /etc/resolv.conf to have one line, nameserver 192.168.0.1 or whichever nameserver you want. In the case of the latest Raspbian distribution, resolv.conf is generated from resolvconf.conf which needs its local nameserver line commented out, and 127.0.0.1 replaced with your nameserver of choice, so that DNS resolves work properly (otherwise you will have trouble installing or updating things. It's good to reboot your unit again and test that it is reachable via SSH on the IP configured. Another tweak you might want to do is to go back to sudo raspi-config to configure the GPU memory split to be 16Mb - as you will probably only be running in text mode, so freeing RAM for other processes. Now that we've got the configuration workable remotely, you can pull the card and shove it into the Model A along with the one wireless adapter and the PiFace Control and Display module.

 

Then, we need to install the relevant packages. My initial thoughts was that it would be enough to be able to change the sign by SSHing into the box and running a shell script, but that would get tedious very quickly, so I wanted a web interface as well. As a result, I decided to install the support packages for pifacecad and lighttpd as the web server. That's as simple as sudo apt-get install python{,3}-pifacecad lighttpd. At this stage, the PiFace Control and Display module should be working (or might be after a reboot) - a simple Python3 program like the following should write a message onto the screen.

 

#!/usr/bin/env python3

import pifacecad

cad = pifacecad.PiFaceCAD()

cad.lcd.blink_off()

cad.lcd.cursor_off()

cad.lcd.clear()

cad.lcd.backlight_on()

cad.lcd.write("Gough: AWAKE    \nCome in!")

 

If that is working, then we are ready to make the interface work.

 

Gluing the Web Server to the PiFace Control and Display

 

I decided to go with lighttpd and the tried and trusted cgi interface to allow the web server to make calls to python. Despite the above example using python3, I decided to go with python (2) instead for this. The first problem I found was the issue of configuring the web server correctly. In the end, my /etc/lighttpd/lighttpd.conf looks like this:

 

server.modules = (

    "mod_access",

    "mod_cgi",

    "mod_alias",

    "mod_compress",

     "mod_redirect",

#       "mod_rewrite",

)

 

server.document-root        = "/var/www"

server.upload-dirs          = ( "/var/cache/lighttpd/uploads" )

server.errorlog             = "/var/log/lighttpd/error.log"

server.pid-file             = "/var/run/lighttpd.pid"

server.username             = "pi"

server.groupname            = "pi"

server.port                 = 80

 

 

index-file.names            = ( "index.php", "index.html", "index.lighttpd.html" )

url.access-deny             = ( "~", ".inc" )

static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

 

compress.cache-dir          = "/var/cache/lighttpd/compress/"

compress.filetype           = ( "application/javascript", "text/css", "text/html", "text/plain" )

 

# default listening port for IPv6 falls back to the IPv4 port

include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port

include_shell "/usr/share/lighttpd/create-mime.assign.pl"

include_shell "/usr/share/lighttpd/include-conf-enabled.pl"

 

$HTTP["url"] =~ "^/cgi-bin/" {

    cgi.assign = ( ".py" => "/usr/bin/python" )

}


Significant changes include making the server use the pi username and pi group, and the addition of mod_cgi, and the last few lines which configure the .py extension to call /usr/bin/python as the interperter. Lighttpd needs to be restarted with a sudo service lighttpd restart for the changes to take effect (or you could try to use reload, but restart is just as easy).

 

Now we need an interface and the cgi-script to perform the action. I decided to go and write a simple python script for the cgi-handler called pidisplay.py, placed inside the cgi-bin directory under /var/www. Of course, it must be sudo chmod +x pidisplay.py to ensure it is executable.

 

#!/usr/bin/env python

 

import cgi

import cgitb

import pifacecad

 

cgitb.enable()

cad=pifacecad.PiFaceCAD()

cad.lcd.blink_off()

cad.lcd.cursor_off()

cad.lcd.clear()

cad.lcd.backlight_on()

 

print "Content-type: text/html\n\n<html>"

 

form=cgi.FieldStorage()

 

if "lineone" not in form:

    print "<h1>Line 1 is Blank</h1>"

else:

    text=form["lineone"].value

    print cgi.escape(text)

    cad.lcd.write(cgi.escape(text))

print "<p>"

cad.lcd.write("\n")

if "linetwo" not in form:

    print "<h1>Line 2 is Blank</h1>"

else:

    text=form["linetwo"].value

    print cgi.escape(text)

    cad.lcd.write(cgi.escape(text))

print "<p>"

print "Screen Updated!<p><h1><a href=\"/\">Go Back</a></h1></html>"

 

The interface was coded as a hand-coded HTML file, called index.html in the /var/www directory. There is a form for a custom message to be submitted, and there is a list of URL-encoded presets, both of which provide the lineone and linetwo values to the pidisplay.py file.

 

<html>

<title>Raspberry Pi Door Display</title>

<h1>Raspberry Pi Door Display</h1>

Enter message and hit submit to be displayed on PiFace Control and Display.

<p>

<form action="/cgi-bin/pidisplay.py" method="POST">

    Line 1: <input type="text" name="lineone" maxlength="16" size="20" value=""><p>

    Line 2: <input type="text" name="linetwo" maxlength="16" size="20" value=""><p>

    <input type="submit" value="Submit"> 

    <input type="reset" value="Reset">

</form>

<p><h1>Presets:</h1>

<ul>

<li><a href="/cgi-bin/pidisplay.py?lineone=Gough: SLEEPING &linetwo=Do not disturb">Sleeping</a></li>

<li><a href="/cgi-bin/pidisplay.py?lineone=Gough: NAPPING  &linetwo=Do not disturb">Napping</a></li>

<li><a href="/cgi-bin/pidisplay.py?lineone=Gough: WORKING  &linetwo=Do not disturb">Working</a></li>

<li><a href="/cgi-bin/pidisplay.py?lineone=Gough: AWAKE    &linetwo=Knock to enter">Awake</a></li>

<li><a href="/cgi-bin/pidisplay.py?lineone=Gough: ON PHONE &linetwo=Do not disturb">On Phone</a></li>

<li><a href="/cgi-bin/pidisplay.py?lineone=Gough: NOT HOME &linetwo=Returning later">Not Home</a></li>

</ul>

</html>

 

With the files in place, we can give it a go.

 

Mounting it and Using It

 

The Raspberry Model A board was mounted in the base on the old Multicomp Raspberry Pi case. This was then Blu-Tacked to the wall above the light switch just outside my door. The power lead was supplied from a manhole into the roof, where I already had a power supply (XP Power 5v 8A, on formerly on clearance from element14) running several other Raspberry Pis in the roof.

20140816-1347-7872.jpg

 

The wireless adapter used is one of my favourites for Raspberry Pi - it's a TP-Link TL-WN722N with external antenna connector allowing better antennas to extend range. It's an Atheros based adapter and it's very sensitive. I've been running this for months without any drop-outs!

 

20150720-1046-2424.jpg

 

Visiting the web page on a web browser provides the main interface with a form.

doordisp-main.PNG

Clicking on one of the presets, causes the web browser to submit a GET request and sit there for a few seconds while the python file executes. Then it returns the successful status.

pidisp2.PNG

If we go and find the display, we will see that it has been updated.

20150720-1048-2428.jpg

The interface works equally well from virtually any web browser because it doesn't use anything special, HTML wise. I could easily whip out my phone just to tell everyone that I'm working.

20150720-1048-2427.jpg

It might look relatively straightforward, although I did have to spend some time working around user permissions to try and persuade the web server to execute with root privileges, or at least enough privileges to access the hardware directly. If you find it doesn't work, and results in blank pages, or internal server errors, you're probably running into a permissions issue. It's a lot of computing power for a display sign, which might be equally well achievable with the Arduino Yun and a LCD shield, although I had the Model A and PiFace Control and Display, so I used what I had.

 

Limitations

 

As this was hacked together in under an hour, it's clear that there is no provision to read-out the screen to determine what it is showing. None of the other PiFace Control and Display peripherals are used. No scrolling of the display is supported at this stage. The web server is being run as the pi user which has root privileges making it insecure and possibly prone to compromise in case of bugs. Validation of the text is done on the user-side for length, extreme lengths could result in unpredictable overwriting of the display. No simultaneous access management is provided - simultaneous calls to the .py file will result in a blanked display or corrupted display. No authentication is provided, although HTTP Basic should be fairly easy to set up. No automatic updating occurs, so you must keep an eye on it and update it from time to time to maintain some security. The interface is not particularly good looking, but it works.

 

There are probably many more limitations that I haven't thought of, but in the end, it was a quick hack that works. It's fine if you're using it at home, in a network which you keep secure and safe, away from persistent malicious actors.

 

Conclusion

 

At last, the PiFace Control and Display finds a use around the house. Now I have a door sign I can control from virtually anywhere in the world with my phone and a data connection (Connectbot SSH tunneling + Web browser). Now, as long as I remember to set it to the right status, I can inform anyone who passes by whether it's okay to come in. Now, if only my family would actually READ the sign ...

The end of financial year sales at element14 definitely got me shopping around the Connect catalogue, where a deal leaped out at me - the heavily discounted Wi-Pi wireless adapter. Sure, it's a pretty basic device, but it's handy to have a few around to help your Raspberry Pis and other devices "go mobile" for basic data-shuffling.

 

I've gone into depth, tearing apart one for all to see on my blog here: http://goughlui.com/2015/07/19/teardown-element14-wi-pi-usb-wireless-802-11n-150mbits-2-4ghz-dongle/

Last week, I delivered a review of the Keysight U1461 Insulation Resistance Test Multimeter. It's a lovely unit, and as with all new and wonderful tools, it's become my new "go to" unit when it comes to experiments. In my review, I commended it for the convenience feature of being able to detect an open fuse without actually taking it out and testing it by using the Earth Bond test selection as the manual said ...

fuseverify.gif

Had I been a little more awake this morning, I might not have had to use this feature ... and subsequently feel like an absolute fool.

 

The Story

 

Just last night, while I was sleeping, a thought came to me that I should probably investigate the old E-I core laminated transformer I pulled out of some gear a while ago. Its condition was unknown, but it was an unremarkable step-down transformer from an old discarded piece of equipment, maybe even 30 years old. It was pretty small, no more than 10VA at the most. I was thinking of using it in series as a current limiting choke for some AC experiments with a miniscule load, as we know, the transformer should be perfectly safe just hooked across the mains anyway, so in case of a short, we shouldn't be getting dangerous levels of current. After all, this is basically the same principle behind an old-fashioned magnetic/iron fluorescent tube ballast.

 

Being ever cautious, of course, I don't like playing with mains directly, and I don't like the massive fault currents that can arise. I don't even like using mains through an isolation transformer, fused. Instead, I opted for my go-to - a pure sine wave inverter driven by a lab benchtop supply. As the inverter is "insulated" and the benchtop supplies are "floating", there is no likelihood of me tripping RCDs or having current flow through me and ground - it's purely isolated. Better still, as it's a wimpy 300W inverter, the fault currents are limited too. For an additional safety measure, the power has to go through a 1A Variac/autotransformer (so I can vary the voltage) and it's fused too.

 

Connection-Diag.gif

With this sort of arrangement, I should be able to measure the magnetizing current of the transformer to see what it's quiescent losses are (and hence, the current it will "let through" on a worst case scenario). Simple enough right? Not quite.

 

I did have a thought about whether such an arrangement would be good - there's likely some form of inrush (despite the small transformer) current which may be large enough to stress the fuse (although I doubt it). Of course, with 10VA, the quiescent current should be a lot smaller than 440mA, so I thought, what the heck, lets just get the measurement before I get breakfast. Bad move.

 

Whoops, I did it again ...

 

I flipped the switch on the lab supply and immediately, something didn't feel right. There wasn't any sound, but the meter was reading an infinitesimal amount of current when I was expecting something in the order of at least milli-amps. I check my wiring, and it's fine. I check the output voltage on the Variac, all good.

 

Then I decided to flip the U1461A over to Earth Bond mode ... and the bad news was there ...

20150502_110412.jpg

That would explain it. A fuse open, meaning the circuit had opened inside the meter and somehow we've exceeded 440mA for long enough to blow the HRC fuse inside. Damn, I feel like a fool now. I blew a fuse when reviewing the Tektronix PA1000 due to inrush currents. You would've thought I'd have learnt my lesson by now.

 

Interestingly, it wasn't due to inrush currents. Further investigation with the resistance showed what appeared to be a shorted primary turn, meaning that the transformer was busted anyway. Why didn't I check that before I powered it up? It's so obvious in hindsight. Lesson learned ... maybe.

 

The Fuse

 

The fuse is housed in the bottom panel section on the U1461A and requires two screws to be removed to get to it. The rear panel markings state the specifications for the fuse. It is to be a 440mA fuse, with a working voltage of 1000V and an interruption rating of 10kA minimum. The size isn't specified, but since I have to replace it anyway, it gives me a reason to pull it out.

20150502-1220-4991.jpg

The fuse used is a type specially used in digital multimeters, and is a fast, high-rupture capacity fuse with a large size. Levering it out of the clips took the use of some screwdrivers.

20150502-1219-4988.jpg20150502-1219-4989.jpg

The original fuse comes from SIBA - a reputable German manufacturer of fuses. It is designated as a DMI fuse. It has a length of 35mm. The unit exceeds the requisite 10kA interruption capacity, and has 30kA interruption rating.

20150502-1220-4990.jpg

The fuse has a diameter of 10mm. With this information, lets scour the element14 Australia catalogue for some replacements.

 

Replacement Fuses

 

After looking for some replacement fuses, did the actual sense of what I had done finally sink in. I wished I could just say "sorry" and everything would be forgiven. Okay, it's not quite that big of a mistake, but if I were to do it again, I wouldn't be too happy. There are several options for replacements:

 

As a result, there are plenty of options if you're looking to replace the fuse, but none of them particularly cheap. That being said, I'll probably go with the Fluke unit, as it's the cheapest one that meets specs. If you're looking to be most authentic, the SIBA one is available at about twice the price. None of the other options seems to be in the realm of reasonableness.

 

Conclusion

 

In the end, it was a case of mea culpa - I didn't check the winding resistance and shoved power right onto the winding which happened to be shorted. I didn't think carefully about the discrimination of the fuses - I'm just used to the 1A fast blow fuse in the Variac going before anything significant happens, but when your meter has a 440mA fast blow as well, that will be the "weak" spot which goes first. It's a good thing that it worked for the safety of the meter. I suppose this is why I wished the U1461A also had a high current range, which might be fused less aggressively. At least it's not a permanent mistake.

 

The fuse is a relatively expensive part, and after you blow a few, you'll do your darned best not to blow any more. That being said, it's an integral part of the safety of the meter, and your safety as well, so it's critical to replace it with a part that meets specifications - regardless of the cost. If you're looking for a replacement, it just so happens that element14 stocks several alternatives, so that's nice.

 

Maybe next time, I should have breakfast first before I try doing anything.

Recently, after having posted a review of the Raspberry Pi 2 here, I was tipped off by mcb1 that his Raspberry Pi 2 looked a little different. A little discussion also had clem57 letting me know of some RAM differences between original RPi boards which got me wondering - what sort of variations of Raspberry Pi 2 are out there?

 

For research purposes, I collated photographs from different online shops, forums, from my own board, from the board my colleague received, and from Mark and put it all in one post for your enjoyment:

 

The Raspberry Pi 2: Not all from the UK?

 

The conclusion reads:

While the Raspberry Pi 2 boards may have cosmetic differences, they should function identically from a user’s perspective. It seems that some parts have alternatives in the BOM, so you might have different combinations of cosmetic differences. For now, it seems, the RAM is something that stays the same now (before, varying between Hynix, Samsung and later Micron).

 

The bigger (and more interesting question) is why the production itself was done in China, given their earlier resolve to keep as much of it as possible in the UK. We might never know the answer.

Suffice it to say, an early criticism of mine from Part 1 was a lack of decent documentation for the board itself. Oh how I'm forced to eat my words as I realize that there actually is a perfectly good board manual from Infineon that you can grab from here. To be completely fair, I have gone back and added the link for it back into Part 1 - but as to why I didn't find it when I was doing my searches still remains a mystery.

 

The manual itself fully details the board's design topology, capabilities, but more importantly, the I2C command-set and the parameter optimizations necessary to match the driver to your LEDs.

 

The Board Topology

 

The board itself uses a buck converter architecture, but the actual details as to its implementation only become clear with further examination of the board manual. In this posting, I will excerpt many relevant block diagrams from the manual - these are made by Infineon.

Channel-Schematic.PNG

Each channel has a topology as shown above, somewhat simplified. The top part forms the current freewheel loop, with a sense resistor to ground and a MOSFET to control the on-part of the cycle and provide feedback. The current control loop has a counter which controls the off time and can be configured, and the reference current value can be configured to accommodate different forward current needs. A sigma delta block generates the pulse-density modulation which is combined to drive the MOSFET.

Ripple-Output.PNG

Because of this control loop, there is a problem of stability and propagation delay - which is why some optimization is required to ensure the best results (i.e. less overshoot, lower ripple).

 

Measuring the Current Waveform and Optimizing the LEDs

 

I had initially just loaded the sample sketch, thinking that it was all "safe values" and there won't be anything bad. After some closer inspection, I saw the current value was set to 0x80 for a value of 780mA. Yikes. Don't just blindly load the sketch if your LEDs aren't capable! That is what got me onto the whole line of optimization and current waveform measuring.

 

The whole of Chapter 6 of the board manual covers the optimization process and is well worth a read to ensure you aren't overstressing your LEDs or the board itself, and you minimise the ripple current. You will need an oscilloscope with a current probe but you might be able to get away with something less. The optimizations need to be performed on a channel by channel basis, and will result in different values for different input voltages, and LEDs. There is a reference table of values, if you are using the modules they have, although that is somewhat unlikely.

 

Of course, part of the optimization process involves setting a given colour channel to fully on. You can use RGBLEDS.SETCOLOR, but be warned, as red and blue are the expected values, green is not 0x0fff for the green channel! It took me a moment of going through the library to work out that you need to use Lime if you want 0x0fff on the green. Alternatively, you can just directly specify the R, G, B values, with a dimming value of 0x0fff to ensure they get passed "as is" to the channel.

Green-Lime.PNG

Of course, to do the optimization, you will need to have a current probe and an oscilloscope. I decided to use the Picoscope 2205A that I had been awarded in a prior RoadTest as the oscilloscope.

 

In a hack, I grabbed a spare 0.1 ohm wire-wound resistor from the shelf and added some terminal connector blocks to it. I'm sure the more experienced guys will be jumping up and down right now going don't do that - and I know what you're thinking. I just had to do it for myself to see why.

20150216-1018-3622.jpg

For those who haven't had the lightbulb moment, the problem is that wire-wound resistors are themselves inductive and will severely affect the operation of the circuit by adding inductance to the system. Also, not to mention, the thing has 10% tolerance for values. Initially, I thought that it would only induce a small error into the result, and it would be better to get a reading than none. I filmed a whole video, and in it, we get rather strong ripples and strange behaviour. I didn't expect it to be that bad. This is a frame grab from the original video.

Inductive-R.png

Of course, there was no way the shield was performing this poorly after optimization. I really needed to get a non-inductive shunt of some sort. I scoured my room for some composition resistors, and I found 11 metal film type 1.1 ohm 1% precision resistors. Whacking them all in parallel for another ugly hack, and we have a 0.1 ohm shunt with a (likely) <1% tolerance (statistically speaking).

20150216-1511-3623.jpg

If you looked at the topology above, you might just think "why not measure across the feedback sense resistor?" The thought did occur to me, but there's actually an issue. If you look at the PCB itself, the sense resistor is paralleled with a capacitor to smooth out transients and stabilize the feedback system. As a result, it's not possible to capture the ripples accurately if you use the feedback resistor, and you won't capture the freewheeling current part of the cycle either.

 

There's another complication with measurement as well - as the Infineon's power supply ground is connected to the Arduino ground, and the Arduino ground's connected to the USB ground, and the USB ground is connected to the Picoscope's ground, to perform the measurement would require using ground as the ground, and measuring one side of the resistor with Ch A, the other with Ch B and doing the subtraction, multiplication (for scaling) to get your values. This is possible, but not my favourite way.

 

I decided to get lazy, knowing the potential difference is 12v with 2A current (from the limited power supply), so I used a laptop with the PicoScope, unplugged from the mains, and not plugged into the Arduino either, so it was operating floating. I connected the ground of the Ch A to the 12v + side of the LED drive, and the negative side to the other side of the sense resistor so it would read an inverted value. This was done purely out of habit - I could have hooked it up the other way, but I generally like having either + or - as a ground, rather than an intermediate node. I set up the Math channels to read -10*A to provide the current in Amps.

 

In fact, it was such an interesting experiment on its own that I spent the time to recreate the video with the less-inductive resistors after I had spent a few hours uploading the first one with the inductive resistor problem. This one is a little more concise, but leads you through the optimization process and provides some basic measurements of waveform frequency and modulation which is related to flicker. I hope you enjoy, and it comes in useful. You might want to view this one full-screen so you can read the values.

 

After I had hand optimized the channels, I made a few discoveries which corroborate well with the lessons taught by the manual. For one, if your input voltage is > 4x the voltage drop of the LED, you will have difficulty achieving good ripple performance. This was an issue to some extent on the red channel, where according to the datasheet, my LED was specified for 2.5v typical forward voltage drop at 1000mA (less for 700mA of course). The values I got for the green and blue channels were fairly similar, and on checking, their forward voltage must have been as well with the green specified for 2.7 to 4.25v at 700mA, and the blue specified for 3.3v typical at 1000mA. The final measured ripple values were about 30-50mA, which corresponds to a ripple percentage of 4% to 7% which is generally considered good! I suppose 12v would better suit pairs of these LEDs in series.

 

The shield is capable of driving almost any LED current value up to 700mA, but because of the ripple, it's not advisable to use any LED with less than a 350mA forward current rating, as the maximum current could be exceeded during optimization to the point of damage. Safe values from the datasheet are actually lower than the ones in the sketch, so it may pay to replace the values in the sketch with the ones in the manual first before trying it out.

 

All in all, I was able to show that the worst case flicker is a 1khz flicker at the lowest brightness - well above the flicker fusion threshold. The ripple from the buck topology was reduced to nearly insignificant levels, and itself cycles at 2.2Mhz which is exceptionally high.

 

The Command-Set

 

Thanks to finding the board manual, we have a full description of the command set on this board. Importantly, many of the commands are more advanced direct-register access, pertain to the DMX bus which is not fitted by default, or are about reading values from the shield which you really don't need to have. This reduces the commands we need to know about to just a short list - excerpted from the Infineon Board Manual.

Command-List-Excerpt.PNG

In fact, you probably don't even need the first three, as INTENSITY_RGB can perform the same function. WALKTIME, DIMMINGLEVEL, FADERATE are global to all channels. CHANGEADDRESS is only necessary if you wish to run several boards on the same I2C bus, or you have a conflict of address for some reason. Full details are in the board manual, of course.

 

The global dimming level function deserves a little mention here - it's an interesting function because it's exponentially weighted, and it affects all channels at once, allowing you to keep a constant colour while reducing the brightness by scaling each of the channels by the global dimming value / 4095, so you don't have to do it by yourself.

Global-Dimming.PNG

Another nice function is the walk-time which allows you to set the amount of time, in 0.01024 second units, that the board takes to transition to the next colour value.

Walk-Colour.PNG

 

Library and Sketch Clean-Up

 

After examining the command set, there doesn't really seem to be much of a need ever to actually read anything back from the shield via I2C unless you plan on doing read-modify-write style operations. To simplify operation, we can live with just using write based commands to set the values required - the main values being for INTENSITY_RGB, FADERATE, DIMMINGLEVEL, WALKTIME, OFFTIME_RED, OFFTIME_GREEN, OFFTIME_BLUE and CURRENT_RGB. I've ignored the fact that the shield itself does also accept values for overwriting the NVRAM defaults which might save you from reprogramming the one-off parameters (i.e the last four that I listed).

 

The example code provided seems to handle all reads by dumping the result to the serial port - this is why the Serial.begin(9600) command is invoked in setup. Ideally, I'd like to free the serial port in case I needed it - say to push RGB+Walk+Fade+Dim values to the Uno via the USB port.

 

The first step was to open Infineon.cpp and comment out (by preceeding with //) the lines that invoke Serial functions. Those are line #'s 209-212, 266-269, 395-398. Additionally, line #2 which states #include <Arduino.h> can also be commented out now that Serial is no longer needed. Once that is done (I've attached a copy to this post), then you don't have to invoke Serial.begin(9600) if you don't want to have the serial port, and or otherwise use it solely for your own purposes.

 

The next thing was to clean up the sketch. It's not the easiest to read, as I've stripped out most to all comments (as I don't like clutter) and I have particularly oddball styling which is a carry-over from my CS days, but I've removed needless initializations and created a new function setLEDColour and rangeClip which allow me to set the LED colour, fade, walk and dim values by invoking a single command, and it filters for out of range conditions (also attached).

 

#include <Infineon.h>

#include <Wire.h>

 

Infineon RGBLEDS = Infineon();

 

void setup() {               

    Wire.begin();

    while (RGBLEDS.on != 1) {

      RGBLEDS.I2CWRITE2BYTES (ADDRESS, FADERATE, 0x0000);

      RGBLEDS.I2CWRITE2BYTES (ADDRESS, DIMMINGLEVEL, 0x0000);

      RGBLEDS.on = RGBLEDS.I2CREAD(ADDRESS, READ_DIMMINGLEVEL);

      if (RGBLEDS.message == 1 && RGBLEDS.on == 0) {

        RGBLEDS.message = 0;

        RGBLEDS.on = 1;

      }

    }

    RGBLEDS.I2CWRITE2BYTES (ADDRESS, OFFTIME_RED, 0x10);

    RGBLEDS.I2CWRITE2BYTES (ADDRESS, OFFTIME_GREEN, 0x06);

    RGBLEDS.I2CWRITE2BYTES (ADDRESS, OFFTIME_BLUE, 0x06);

    RGBLEDS.I2CWRITE6BYTES (ADDRESS, CURRENT_RGB, 0x60, 0x5E, 0x5A);

    RGBLEDS.I2CWRITE2BYTES (ADDRESS, FADERATE, 0x0000);

    RGBLEDS.I2CWRITE2BYTES (ADDRESS, WALKTIME, 0x0000);

    RGBLEDS.I2CWRITE6BYTES (ADDRESS, INTENSITY_RGB, 0x0555, 0x0555, 0x0555);

    RGBLEDS.I2CWRITE2BYTES (ADDRESS, DIMMINGLEVEL, 0x0FFF);

    RGBLEDS.I2CWRITE6BYTES (ADDRESS, INTENSITY_RGB, 0x0, 0x0, 0x0);

    delay(500);   

}

 

void loop() {

   // Set random R,G,B value, Walk 1s, No Fade, No Dimming, Every 3s

   setLEDColour(random(0,4096), random(0,4096), random(0,4096), 97, 0, 4096);

   delay(3000);    

 

void setLEDColour (int r, int g, int b, int walk, int fade, int dim) {

    r=rangeClip(r);

    g=rangeClip(g);

    b=rangeClip(b);

    walk=rangeClip(walk);

    fade=rangeClip(fade);

    dim=rangeClip(dim);

    RGBLEDS.I2CWRITE2BYTES (ADDRESS, FADERATE, fade);  

    RGBLEDS.I2CWRITE2BYTES (ADDRESS, DIMMINGLEVEL, dim);

    RGBLEDS.I2CWRITE2BYTES (ADDRESS, WALKTIME, walk);

    RGBLEDS.I2CWRITE6BYTES (ADDRESS, INTENSITY_RGB, r, g, b);

    return;

}

 

int rangeClip (int value) {

  if (value > 4095) {

    value = 4095;

  } else if (value < 0) {

    value = 0;

  }

  return (value);

}

 

I did discover something strange which pertains to unreliable or inconsistent shield operations if certain lines are removed - specifically in setup():

RGBLEDS.I2CWRITE6BYTES (ADDRESS, INTENSITY_RGB, 0x0555, 0x0555, 0x0555);

RGBLEDS.I2CWRITE6BYTES (ADDRESS, INTENSITY_RGB, 0x0, 0x0, 0x0);

 

These two lines really don't seem to do anything critical as they set the output brightness values, before setting the dimming level and after setting the dimming level - however, I have discovered that removing them will result in inconsistent shield operation where reloading a sketch on the Arduino results in no light output or only certain RGB values working. A power cycle restores the operation but doesn't allow for sketch reloading otherwise you get the strange result again. Leaving these lines in, however, seems to cure the issue and I'm not entirely sure as to why. In the interests of having it work, I'm not going to tinker with it any more.

 

Needless to say, now I have a colour changing desk lamp which changes colour every 3 seconds to a random colour with a 1 second "transition" period (value 97 * 0.01024 = 0.99328s). I added a pad of white gauze over the LEDs which makes the colour mix a little better but does cut down on the light significantly. I might need to find some opalescent perspex or something better ...

20150216-1927-3624.jpg20150216-1927-3627.jpg

20150216-1927-3628.jpg

 

Conclusion

 

Sometimes, tinkering with things can get addictive, and you just can't put it down even when you should. The whole issue of ripple current and actual current in buck converter topology, and the modulation waveform had been an intriguing element, which has been well documented in the Infineon Board Manual, but I felt that I really needed to delve into it on my own. In the process, I discovered, and performed the relevant optimizations required to match the shield to my LEDs, and further understood why there were some matching issues.

 

Further delving into the manual gave me a better understanding of the command-set available, and just how few of these commands really matter. By cleaning up the library and wrapping some code in as a basic function, I have prepared myself better (as far as my experience goes) into allowing some sort of computerized control. In the end, I didn't end up bothering implementing computerized control on the Uno, although it should be as easy as writing a simple Serial command receiver, instead just relying on the Arduino to produce some random RGB values and write them into the shield to make a colour-changing lamp (3 second change interval, 1 second fades between colours).

 

Thanks for reading - the next part will probably deal with the Arduino Yun, when time permits.

---

Feel free to visit me at my personal blog at http://goughlui.com

The timing of these blog posts is a bit irregular because of previous engagements with medical appointments, my PhD, other RoadTests and my personal blog. It's not easy to find the time to write the posts sometimes - but I'm sure somebody would appreciate them, so lets keep this show rolling . Before anyone asks - no I didn't receive the items, prepare them, and get something working all in a day.

 

The parts themselves arrived on 19th January 2015, right after I got back from my international conference, and I took photos of them right away. The first thing I needed was a concept - how to utilize the items. I'm not really one for originality, but a colour changing browser-controlled LED desk lamp came to mind. It's probably the most basic thing one can envision. In order to get this show on the road, I would build something simple, illustrated in the following sketch, using the Uno first to confirm that the Infineon LED Shield and LEDs are working.

Initial-Proto.PNG

Several key points needed to be kept in mind:

  • The Infineon shield natively supports up to 700mA per channel. In reality, this means you should use LEDs with 700mA or greater forward current ratings to ensure that even when the maximum brightness is mis-configured, there is no way the LEDs would be blown. I suppose, with appropriate care, you could use lower current rating LEDs if you ensure that your dimming values are set correctly.
  • With 700mA of drive current available, it doesn't really make sense to run low-current 20mA 5mm LEDs. You would need at least 35 of them in parallel to sink the 700mA current, and then you have issues of ensuring current balance (e.g. via feedback resistor) to ensure that you don't get one LED taking the majority of the current.
  • The voltage, however, is more flexible with the shield being able to run off 6 to 48V DC. Because of the buck DC-DC architecture, your input voltage must be at least 2V greater than your output voltage. Having more input voltage than is strictly required isn't much of a problem as it is "transformed" into output current. The outputs are strictly current-driven. As a result, in order to get your 100W (33W/channel) output, you would have to series-up enough LEDs to equate to 46V voltage drop, all of them rated at 700mA, with 48V into the shield.
  • If you don't care about getting the most from the shield itself (and believe me, 100W of LEDs is expensive and a heat problem), then you can choose to drive less LEDs. In my case, I settled on one LED per channel, 700mA current rated or higher. Commercially, these would often be marketed as 3W LEDs, so I'd have a total of ~9W of LEDs. Because the voltage drop of a single LED is not very great, you can probably get away with running at 6V input, but since I had a 12V 2A power supply left over from an old external drive, I decided to use that. As the PSU's capacity is 24W, that's plenty more than the LED consumption, meaning that we have some room to run the Arduino Yun and a cooling fan as well from the same PSU.
  • LEDs get hot - at 700mA, you can expect your "average" 3W LED to put out about 1.5-2W of that in heat. If you don't get them some sort of heatsink, they will overheat and damage themselves. As a result, I decided to grab a heatsink as well - but you will need to think about size, shape and customizing it too.
  • Using a 2W per LED figure, the array is likely to put out about 6W of heat. As LEDs run best below 85 degrees C, with an ambient of 25 degrees C gives a thermal rise of 60C. As a quick back of the envelope, your heatsink needs to have a thermal resistance of 10C/W (or 10K/W) or less to ensure the LEDs don't overheat. That normally means it's not going to be some thin metal stamped unit. In reality, it will need to have a thermal resistance slightly less, because the junction to case, case to MCPCB, MCPCB to heatsink junctions all contribute additional thermal resistance which you need to account for.
  • You can significantly improve the thermal resistance to ambient if you use a fan with your heatsink - while I might not need it, I decided to go with one for additional safety margin. Running LEDs cooler will result in a higher lifetime.
  • Buying LEDs on bases or with easy to mount packages is generally advisable, otherwise you will have to devise ways to do surface mounting of the LEDs with the additional challenge of thermal management of the LEDs. Many of them cannot be sensibly mounted to regular PCBs and need specialized aluminium core MCPCBs to ensure the heat can be dissipated fast enough.
  • Staring at these bright LEDs directly is potentially going to cause you eye damage - so something to diffuse the light, and combine the light to create a homogenous colour is necessary. For now, I've just settled on a sheet of paper, wrapped around into a "cone" shape.

 

With those considerations in mind, I had to purchase my additional parts to make the design come to life.

 

Shopping List

 

None of these items came with the Off-RoadTest, but I deemed them necessary to create my concept, so I spent about AU$63 or thereabouts (with GST and free shipping) getting parts from element14 Australia to make it happen.

- 1178396 Elkay-1276-18-Terminal Block, Barrier, 12 Pos AU$0.84 - this is used to make some wire-to-wire connections when necessary

- 1850074 Fischer Elektronik SK 570 25 SA LED Heatsink, Standard Extruded AU$7.73 - 1.75C/W heatsink - should be more than necessary to keep the LEDs happy

- 1973700 LEDEngin LZ1-10B200 High Brightness LED Blue 5W AU$19.37 - Blue LED for blue channel, 1.2A maximum continuous rating, star base

- 1901495 LEDEngin LZ1-10R200 LED Medium Red AU$10.74 - Red LED for red channel, 1A maximum continuous rating, star base

- 1716760 Multicomp OSW-4334 LED 3W High Power Leaded True Green AU$18.68 - Green LED for green channel, 700mA continuous rating, TO-220 package

 

I would have really liked to have matched the green channel with an LEDEngin product, but element14 Australia doesn't have the LZ1-10G100 in their catalogue, so I settled for an alternative part with enough current rating and a package which can easily be handled/mounted.

 

The remaining things I managed to scrape out of my spares box, or I had spare on hand:

- M3.5 screws to secure the star base/TO-220 packages to the heatsink

- M3 HSS Drill Bit to drill into the heatsink

- Cordless drill to make the holes

- Screwdriver to drive the screws into the heatsink

- Arctic Ceramique thermal paste to improve the thermal contact of the LEDs to the heatsink

- Hook-up wires of various colours taken from old ATX power supplies to make the connections

- 12V 2A DC power supply from an old external hard drive

- USB A to B cable to connect the Arduino to the PC

- Straight header pins to connect the Infineon LED Shield onto the Uno

- Solder to solder the pins on

- A soldering iron to make the joints

- An old spare 80mm computer fan and screws to provide some extra cooling

- A buck module to reduce 12v to 5v to power the Arduino (for the Yun which has no internal regulator)


Getting the necessary parts was a great cause of delay, with a little more than one week spent waiting for backordered parts from element14 to arrive. But since they all arrived just this week, I could finally prepare the hardware and get it to a stage where I can confirm the hardware actually works.

 

Preparing the Hardware

 

The Infineon shield comes "naked" and the first thing that you will need to do is solder on some header pins to make the connection to the Arduino. In general, I would recommend tall stackable header pins, but since I didn't have any on hand, and I was pretty eager to get going, I decided to grab some spare standard header pins I had spare.

20150129-1721-3451.jpg

With the header pins, it's pretty simple to snap them to the right lengths in preparation for soldering.

20150129-1722-3452.jpg

It's at this point that many novices make a mistake - they try to solder the pins on with the board standing free and then find that their pins are skewed at strange angles and don't want to plug into the board. As a result, here's a tip that I've heard - you should just plug the pins into the Arduino itself, using it as a holder, then you put the board onto the pins.

20150129-1723-3453.jpg

20150129-1723-3454.jpg

People with more advanced soldering skills can go on and solder all the pins in sequence, but more novice people should just solder the end pins on each header segment, remove it from the Arduino and then solder the rest of the joints to avoid overheating the header sockets on the Uno and damaging it.

20150129-1731-3457.jpg

Because of the nice ENIG finish on the PCB, and the red solder resist, the board is very easy to solder to. The joints look pretty good for hand-done .

 

Now, the more difficult task of preparing the LEDs. The LEDs have very intricate internal grid structures and wire-bonds - it's quite nice to look at.

20150215-1349-3594.jpg20150215-1351-3598.jpg20150215-1351-3599.jpg

I didn't take pictures of the initial stages, but suffice it to say, it's necessary to solder leads to each LED unit first. If mounted to the heatsink, the heat from the iron will be drawn away and it's not possible to make good joints. Once leads are soldered, the heatsink has to be marked out for drill holes, the holes drilled, thermal paste applied, and the screws tightened to secure the LEDs on the heatsink. Then the wire connections can be made - for something that looks something like this ...

20150215-1406-3601.jpg

I didn't pay attention to my own diagrams, so I totally forgot this connection scheme is common anode. I colour coded the anodes nicely, but for no good reason! I used a terminal connector block to common-up all the anode leads. The connection blocks on the Infineon Shield are of a type I haven't ever encountered before, and using them is a bit of an unusual experience. Provided you strip the end of the wire, insert it in far enough and push down on it, a connection is made. Unfortunately, I'm not sure if the connections can be undone afterwards - so consider these "one shot" punch-down blocks. If worst comes to worst, I suppose the connectors can be de-soldered.

 

The final step is to prepare the power supply leads, and fan leads - another terminal connector block is used to make the wire connections for additional flexibility in reconfiguration later.

20150215-1423-3602.jpg

Add a USB lead, and now we're ready to prepare the PC-side of things.

 

Preparing the IDE and Arduino Uno for First Light

 

I hadn't updated my Arduino IDE for a while, so I downloaded the latest version and unzipped it. It's necessary if one is to have any chance of programming the new Yun later on. The IDE still cosmetically looks the same as before. I then downloaded peteroakes library from here and unzipped the files to a new folder called Infineon under the Library folder.

LibraryFolder.PNG

I ensured the board was powered - the Uno via USB, and the LED Shield via the 12v DC PSU. Opening the IDE, copying the code in the RGBLED.ino demo file into a new sketch, allows you to compile and load it onto the board for a test to see whether it works.

IDE.png

The sketch begins running immediately upon upload - success! It works! We see first light from the LEDs.

20150215-1447-3605.jpg

Here's a quick (not so very nice) video of the endless loop running with a sheet of paper as a crude diffuser.

(I tried uploading to element14 as a video, but it kept erroring out despite multiple retries with Unexpected error occurred, so it's on Youtube instead)

 

Conclusion

 

Thanks to the efforts of the previous RoadTesters, particularly peteroakes, it wasn't that much of a hassle to get to the stage of first light. The demo sketch and library provided worked a treat, and the LEDs lit up as expected. The shield does make a little acoustic noise, which is expected to some degree (as many switching converters will produce such sounds due to magnetostriction in the inductors), but the light appears steady to the eye, with smooth fade transitions between the colour values.

 

The next step will be to code up something which drives the LED colours based on some input which I provide, which I can then use to expand the system under direct PC control, and then control through the Yun. I figured out getting acquainted with the Yun would take a while, so don't expect to see an update for a while - but this is how I envisage the sketch would look like with the Yun in the picture.

Proto-Yun.PNG

Thanks for reading! Thanks to mcb1 and ipv1 for their support on my previous posting !

---

Feel free to visit me at my personal blog at http://goughlui.com

Just around Christmas-time, element14 ran a RoadTest entitled Internet of Holiday Lights. I was a bit busy around that period, with overseas conferences to worry about, so I never bothered to apply for the RoadTest. Alas, I didn't end up missing out, because doctorcdf sent me an e-mail, letting me know that I was going to get a little bonus with my other RoadTest - I would be receiving the Arduino Uno, Arduino Yun and Infineon RGB LED Shield as well for my own tinkering. I'm so very lucky to have element14 supporting me - thanks guys!

 

The main benefit of this arrangement was that I could take things a little easier - the RoadTesters had a deadline to meet, and I didn't. Instead, I'd spend some spare time reviewing the products and blogging them here, on my element14 blog. I thought that would be the best arrangement, seeing as my workload is very unpredictable. So, lets just call this an "Off-RoadTest".

 

The Parts

 

The Internet of Holiday Lights bundle consisted of the Arduino Uno, Arduino Yun and Infineon RGB LED Shield.

 

Arduino Uno

20150129-1520-3432.jpg

The Arduino platform has been very instrumental in introducing people into the world of embedded microcontrollers. They made the Atmel Atmega 328P very popular and accessible, by producing an inexpensive prototyping board which contained everything necessary to program and interface with the microcontroller. Additionally, it came with an Integrated Development Environment (IDE) which was open source, and based on the Wiring language, which is very much C-like. This very much reduced the learning curve and cost - there was no longer a need to be familiar with AVR-ASM, or invest in programmer devices which would easily cost more than the development board itself.

 

I am a seasoned Arduino user, and it has been quite instrumental in my own tinkering. Even for making basic interfaces to the outside world, dumping EEPROMs or for generating signals, it's an indispensable part of my toolkit. Having used the Arduino since the Duemilanove, the general recipe hasn't changed much. The initial Uno R1 introduced a second Atmega 8U2 to replace the FTDI USB to Serial interface, to allow for more flexibility in the USB interface. The Uno R3 retains the socketed DIP Atmega 328P, and the shield pin-layout (including the odd spacing on the top row), although the they added I2C pins onto the top row, IOREF to the bottom row, replaced the Atmega 8U2 with a 16U2, improved the reset circuitry and moved the reset button to a more accessible location. The readability of the silkscreen design has been improved as well.

 

It's the most "general purpose" and most-compatible board in the Arduino line-up with most shields targeting this particular board, and a very reasonable price tag, which makes it quite desirable to own.

 

The board itself comes packed inside a matte-finish cardboard box, adorned with a sketch-up of the Arduino Uno PCB which is inside.

20150129-1521-3434.jpg

As has been the case with all genuine Arduino packages, you get a set of stickers and a small pamphlet to go with it.

20150129-1521-3435.jpg

The Arduino Uno is proudly Made in Italy and feels like a quality board (when compared to clones). The top silkscreening is very useful, clearly identifying the power pins, digital PWM pins and analog input pins. The board features indicator LEDs for power, serial receive/transmit and a debug LED connected to pin 13. PWM capable output pins are marked with a ~ symbol. The board runs on an Atmel Atmega 328P, which is an AVR 8-bit 32kB microcontroller running at 16Mhz. The Uno is a 5v board, and hence features 5v TTL I/O.

20150129-1521-3437.jpg

The bottom of the board contains a very unique silkscreen pattern and clearly identifies this board as an Uno R3.

20150129-1521-3436.jpg

A nice change from previous Uno boards is that the header sockets are marked with silkscreening as well, which makes the function of the pins apparent even when the PCB is obscured by jumper pins. A very convenient feature indeed.

20150129-1525-3446.jpg

The reset switch is relocated to the corner near the USB plug, so that it can be pushed even when a shield is covering the button (which used to be positioned near the ICSP header). The board does retain its traditional USB B-type connector, which is considered somewhat archaic now, and has multiple-power source functionality - it can be powered through USB, or via a 2.1mm DC barrel jack connector with a recommended range of 7-12v  as it features an onboard linear voltage regulator.

 

Getting started is pretty simple - you can download the IDE here, install it and leaf through the examples within minutes! This board is available for AU$32.07 from element14 Australia at the time of writing.

 

Arduino Yun

20150129-1522-3438.jpg
The Arduino Yun is a new addition to the Arduino family. It seems to be a bit of an interesting combination device, marrying together an Atmega 32u4 and an Atheros AR9331, which normally would power a Wireless Router. In fact, I seemed to have expected its existence when I first reviewed a $22 TP-Link WR740N wireless router based on the AR9331 running DD-WRT and OpenWRT. One of my comments was that - if we were able to get a device with Ethernet ports, Wireless LAN, a MIPS CPU with a bunch of GPIO, and USB support, along with a case, power supply and cable for $22, why doesn't someone turn it into a development board?


Alas, this device isn't quite what I had in mind when I said that, and instead, it's more of a Wireless-router SoC connected to an Arduino. The Atheros SoC runs OpenWrt-Yun, which runs Linux and has access to 64Mb RAM and 16Mb Flash. It also hosts a USB port and microSD storage slot, for further expansion. It features Ethernet connectivity, and in approved countries, it also has built in Wi-Fi. This allows you to run a full networking stack and process or produce queries using the power of shell scripting in Linux and utilities such as cURL. However, coding for it becomes less straightforward because the Atmega segment runs almost independently, with a special bridge API between the two to exchange data or call certain functions. This is diagrammatically represented in this diagram from here:

BridgeInShort.png

The board arrives packaged in a very similar cardboard box to the Uno, with the Yun pictured instead. The contents are pretty much the same as the other Arduinos.

20150129-1523-3440.jpg

A closer look at the top of the board shows just how packed the Arduino Yun is.

20150129-1523-3441.jpg

Unlike the previous boards, this board actually features three reset buttons - one of which controls the Atmega, the other resets the Atheros SoC, and the last resets the Wi-Fi to factory configuration as an Access Point. The board also features a set of indicator LEDs along the side with additional LEDs to indicate Ethernet, Wireless and USB status. The Wi-Fi chip antenna is situated just above the ICSP header. The Atheros SoC is underneath the soldered-down metal shield/can.

20150129-1523-3442.jpg

The underside of the board is where the microSD connector is. Interestingly, this is not directly hardware-connected to the SoC, and instead goes through an Alcor Micro AU6350 USB Card Reader/Hub chip. Unlike other Arduino boards, this one seems to have been developed by dog hunter, in Switzerland and manufactured in Taiwan.

20150129-1524-3444.jpg

Unlike the Uno, the markings on the header sockets aren't actually printed on - they are stuck on as labels. However, it is just as convenient!

20150129-1525-3445.jpg

Unlike the other board, there wasn't any space for a voltage regulator, so this board doesn't have a barrel jack. There is an optional PoE attachment which can be installed though. The power is supplied via the MicroUSB-B connector (which replaces the USB-B connector on the Uno). There is a USB-A connector for attaching storage or peripherals which can be used by OpenWrt-Yun. Also on this side is a 10/100Mbit/s Ethernet interface.

 

The board itself is quite a bit pricier, at AU$99.73 from element14 Australia, but that's technically not too bad. In the earlier days of playing with Arduino, an Ethernet shield was the better part of AU$66, and along with the Uno base which is another AU$33 or so, we still wouldn't have Wi-Fi, USB or microUSB capabilities. The biggest difference, however, is that the previous solution is extremely limited with a hardware TCP/IP stack supporting only 4-concurrent connections, needing everything handled by the Atmega328P. There was no Linux scripting, because there was no Linux running, and so making workable servers with the Ethernet shield was a difficult challenge. As a result, the Yun actually represents fair value, and it might even be possible to use the board like a smaller router, or just use it like a low powered small Linux server.

 

Infineon RGB LED Shield with XMC1202

20150129-1527-3447.jpg

This appears to be a very unique shield which is exclusive to element14. This device is built around Infineon's XMC1202, which is an ARM Cortex-M0 microcontroller. This lighting shield features three buck-regulated channels, with a maximum input voltage of 48VDC, an output current of up to 700mA per channel and smooth pulse-density modulated dimming for flicker-free results. The board is interfaced to the Arduino via I2C. The board also has optional DMX512 interface which can be installed. The total power controlled can be up to 100W, which is about 33W per channel which is very very bright. The shield can operate on input voltages of about 6V and up, as long as the input voltage is at least 2V higher than the output voltage which is dependent on your LED configuration. This is a common requirement with buck-based DC-DC designs.

20150129-1527-3448.jpg

The board comes in a relatively large box, with the board in an anti-static shielding bag. A one-page leaflet is provided, which outlines the parts of the shield.

20150129-1527-3449.jpg

The shield itself comes in bare form, on a red PCB, with no header pins populated. I would recommend (if you have them, that) you use extended stackable headers to allow for stacking multiple shields and avoid interference issues with the Ethernet connector on the Yun. The DC input and LED outputs have (relatively interesting) connectors populated which take bare wire. The design features a common anode connection, with individual R, G, B cathode connections. All the necessary inductors, MOSFETs, diodes and capacitors have come preconfigured, which makes evaluating the solution much easier. The DMX512 hardware is not populated. Debug connection is provided for the XMC1202, in the case you wish to reprogram the ARM micrcontroller. There is also an LTC3630 High Efficiency Synchronous Stepdown Converter near the top as well.

 

The shield interfaces with the Arduno using the new SDA and SCL pins next to the AREF pin. If you have an Arduino Uno R2 or earlier, you will need to redirect these pins to A4 and A5 instead to make it work.

20150129-1528-3450.jpg

The underside of the PCB seems to be dated Week 17 of 2014, and doesn't contain any components of note.

 

One of the main issues with this product is a lack of documentation and libraries. The main documentation provided is in the form of introductory fliers, which don't provide sufficient information to design with. After a bit of digging, there is a board manual with the required information to design with, but it takes a bit of time to go through.


However, thanks to the RoadTest participants peteroakes, ipv1 and @beavertank, there is now a selection of Arduino libraries which has been helpfully compared by jancumps in this posting. The shield itself is available for AU$35.77 from element14 Australia but keep in mind that you will need to purchase headers, LEDs and an appropriate power supply to make it all work.

 

Conclusion

 

In this posting, I've unpackaged and shown you all of the parts included in the Internet of Lights Holiday RoadTest and provided some commentary on the parts. It might seem a little bit strange that the RoadTest included both the Arduino Uno and Arduino Yun, seeing as the Yun is a more sophisticated Arduino, but it's actually a great idea as it allows for users to prototype and test their code on the Uno which is generally more straightforward, before introducing more complexity with connecting it to the network using the Yun. It also means that, should the user make some sort of mistake, they won't be sacrificing the costlier Yun straight-up.

 

That being said, it's not quite possible to build a full concept with just these parts ... you do need a few more parts - wire, LEDs, heatsink, power supply, header pins and screws to name a few. In the next posting, I will explore the preparation of the hardware up to the first lighting.

---

Feel free to visit me at my personal blog at http://goughlui.com

Well, it's past new year and I finally got a little time to sit down and do something. The first thing I did was to publish my review on the Christmas present to myself, alluded to in my last blog post here.

 

So, what was the present? An Agilent U1241B DMM and Accessories of course! You could've guessed it if you were following my postings about 3.5 digit multimeters and the like.

 

Without any further ado, here's the mega-article - a self-funded RoadTest: Review: Agilent U1241B 4-Digit Handheld DMM & Accessories