The main HPRGB2 library has been updated with three new functions:
- goToRGBHI() uses 1024 CIE lab brightness corrected values (vs. 256 for goToRGB) for smoother fading at low values and when fading slowly.
- goToHSB10() provides much improved HSB accuracy. goToHSB() uses 256 values for Hue, which depending on fading speed can result in visible steps. The new routine uses 768 values and provides much smoother fading.
The SoftI2CMaster library, which is needed in order to change the I2C address of the MCP4728 LDAC, contained an error, which resulted in the sketch not being able to read back the correctly programmed I2C address and made it appear like the address programming failed. A big Thanks! to Mark_H who posted a comment about this here on the blog.
Finally I was able to put the shield up for sale at Tindie. If there are any questions in respect to volume discounts or shipping rates please contact me be before buying by posting the question to the the STORE section of thIs blog.
I still have some work to do on the library before I will commit it to GitHub but the shield will work fine with the library for the V2 of the shield.
As I’ve mentioned before in my own projects I’ve never used the temperature sensor. When redesigning the shield I decided to move the temperature sensor from its proximity to the LT3496 LED driver chip to the edge of the board in order to free up some surface close to the LT3496 for better cooling. The TMP421 temperature sensor has one on-die temperature sensor and one for remote temperature sensing by means of a cheap small-signal transistor. In the previous shields the on-die temperature sensor helped measuring or rather estimating the LT3496 temperature. Now that the TMP421 is moved to a different location on the shield far away from the LT3496 it still measures a temperature but it’s rather ambient temperature.
If measuring the LT3496 temperature is still desired this can still be accomplished through the remote sensing connections. In that case it is best to use a thermal adhesive and glue the transistor directly to the top of the LED driver chip. This provides much more direct measurement of the LED driver chip temperature. Another topic that just became clear to me when working on updating the documentation is that when more than one shield is used in an application, either stacked or otherwise connected to the same I2C bus, then only one shield should be populated with a temperature sensor. The current documentation mentions in more than one spot that there are two I2C components on the shield, but that is incorrect. There can be three I2C components on the board:
- The LED driver chip – LT3496 – data sheet
- The digital Analog Converter for analog dimming - MCP4728 – data sheet
- The optional temperature sensor – TMP421 – data sheet
While the LT3496 and the MCP4728 have configurable I2C addresses the TMP421 in the current version 2.5 shield only has one fixed I2C address. That means only one temperature sensor can be addressed on one I2C bus. However, if for example you have 2 or more shields on the same I2C bus and all of those shields are populated with the temperature sensor the PWM and analog dimming functions will still work. Only the temperature sensor functions cannot be used in that case. In a previous post I mentioned that all chips with the exception of the temperature sensor are FM+ components and can be operated at I2C bus frequencies of up to 1MHz. The data sheet states in the SERIAL INTERFACE section that the chip can actually be operated up to 3.4 MHz.
The first shields have shipped and meanwhile I have created a little reference that at a later date will be complemented by updated more complete instructions. However, this should be enough to get anyone started with the basic operation of the shield. Yellow indicates default configuration and the basic connections needed to operate the shield. Blue indicates additional options and configurations:
Finally after what seems like an eternity I was able to make a small series of 32 boards over the thanksgiving holidays. All of the first run of boards do not have the Temperature Sensor or the Heatsink. However, both of these can be added relatively easy.
While I will ultimately will sell these on Tindi.com, however realistically this will be early next year. Of these 32 boards only 9 are still available. I may add another batch of 8 soon if supplies run short. That’s all I can make in an evening after work. Over the Christmas Holidays I am hoping to make another 40-50.
Also, after all the blog of the original creator of these previous versions of this shield – neuroelec - seems to have gone offline. So over the next few weeks I’ll also be updating the instructions.
Enough of the talk. Here are some photos:
Actually, most of the components are in already. A small shipment from Mouser will arrive soon and I still have enough conductors to build 20 shields. More are on order and will here within 2-3 weeks. As with the ones needed for the prototypes I have not been able to find these at any source her in the US so I sourced them again from the UK through Allied Electronics / RS components.
I’ve also decided to invest in a laser-cut stainless steel stencil from Stencils Unlimited. The mylar stencil from Pololu.com was fine for the prototypes and likely would have lasted a good number of boards longer but the print quality of a stainless steel stencil is simply better and more consistent. Also of course a SS stencil is much more durable.
Another project I have been working on is a micro controller project with the aim to have “something” that can take advantage of the capabilities of this LED shield. One of the unique features of this shield is that it is controlled through the I2C bus. All components on the LED shiled (with the Exception of the temperature sensor) are FM+ capable. The FM+ specification allows I2C bus frequencies of up to 1MHz. Instead of 3mA FM+ components can drive 30mA, which allows much longer connections between I2C components. On the other hand most normal Arduino’s allow max 400KHz. So here is the Frankenduino I’ve described in a previous post:
It features an I2C bus extender based on the PCA9600 chip from NXP. I’ve successfully used a shield on 5 meters of CAT5 Ethernet cable and on my oscilloscope signals looked crisp even at 1.5MHz, so there is quite a bit of headroom to use even longer cables and more devices such as the shield.
Also, what can’t be seen on the Photo is a IR receiver and the Teensy3 happily receives and decodes IR signals from my Apple Aluminum remotes. A nice feature of the Apple remotes is that they can be paired to a device. I have not quite yet finished the code but I have determined the codes that the remote uses to be paired. However, before I do that I need to make a second prototype, which features an SD card slot for permanent data storage. It would not make much sense to having to re-pair a remote every time the micro controller has been powered down.
In order to function together with the I2C bus extender I also re-designed the little Arduino I2C extender board. It has SMD pads for different pull-up resistors and also needs a small Schottky diode when operated in conjunction with the PCA9600 I2C bus extender. Below is a picture of a “complete” system, including a micro controller, WiFi Ethernet Hub for remote control ability through OSC / TouchOSC and a LED shield with the I2C extension board. More shields can simply be daisy chained onto each other using inexpensive pre-configured CAT5 Ethernet cable.
Another interesting idea I had is that it could be quite useful to expose all the functions of the LED shield through the OSC protocol. That way you could create LED effects code directly from a computer e.g. with MaxMSP or Pure Data without having to program the micro controller.
Yesterday I received the 100 boards I ordered from Hackvana.com. It’s a surprisingly small packet, mainly due to the fact that with 0.8mm these boards (for thermal performance reasons) are only half as thick as standard boards. The different thickness also did not cost any extra, it was actually a little less expensive. Most services I had checked before actually charge more for non-standard thicknesses.
Below is a photo of one of these. I focussed my point-&-shoot camera on a more intricate part of the board. Due to the shallow depth-of-field much else is rather unsharp, but enough can be seen to say that these are doggone gorgeous!
And, Yes, it’s been just two weeks since I ordered these. That’s pretty speedy if taking into account that these boards come from Shenzen/China!
On the other hand, due to the number of boards I chose DHL and not China-, or Hong Kong post.
A while ago I had done some more research on possible PCB manufacturing. Not the full assembly just the bare board. The difficulty was finding a source that had acceptable prices but at least offered 2oz copper.
Now I’ve placed an order of 100 pcs with hackvana.com after having a very fruitful email conversation and an IRC chat with Mitch who runs Hackvana. Ive read some very good reviews of the quality of these boards and am looking forward to receiving them. I will likely take 2-3 weeks as the actual manufacturing happens in Hong Kong.
Board specs are as follows:
- Blue Stop Mask
- White Silk Screen (top and bottom)
- RoHS finish (not ENIG)
- 2oz copper plated
- 0.8mm thick
- tab routed into single pieces
After a discussion with Mitch who runs Hackvana.com I decided not to get the immersion gold finish (ENIG) . Yes, it looks great on a bare board but on a populated board with tented vias there is nothing left visible of the gold plating. The real purpose for the ENIG finish is to have e very flat surface and a longer shelf life. The flatness of the boards will be fine for the intended purpose with the RoHS finish – no BGA chips in the design – and I don’t intend to have the bare board laying around for more than 3 months.
I also chose the 0.8mm thickness for better thermal performance as described in an earlier post. In fact and quite to my surprise, this was actually a little cheaper so there was no reason not do do it. I’ll post some pictures of the boards as soon as they have arrived.!
It’s been a while since the last update and unfortunately not much has happened in terms of getting the Tindie Fundraiser started. Not only our private and professional lives have kept us very busy but our initial idea to have the shield manufactured by a Company in Germany is associated with complications that have nothing to do with the LED shield itself but are rather of logistical, and possibly financial nature. For business insurance reasons the small company is not able to conduct business with a private person in the US. I’ve looked into registering a business and will eventually do that, but that is rather a long term goal and may not happen within the next two months.
Given that Tindie is a US website, pledges on a project would be trickling in in $US and once successfully funded we’d have to transfer funds per PayPal to Germany and into Euros. Then my partner would have to ship most of the assembled boards back into the US through customs. For a single shield customs would unlikely a problem, however, for a larger number one needs to make sure these are declared properly and customs fees have to be paid. Wile I have done some research it is unlikely that there would be FCC implications, these are all consideration that in the end will somehow result in additional cost and may render the project unfeasible.
Long story short, I’ve found two sources for low volume PCB manufacturers that offer PCBs with 2oz copper plating and have requested quotes. I have also found a company that can assemble the boards. While they don’t provide turnkey including sourcing the parts, the price that was provided in the initial contact is very attractive. While we have not spoken about details I am hoping to have more information by the end of this week.
Another area of concern is that I’ve never tested these shields under the full load of 40W. Buying enough LEDs, heat sinks would of course work but is rather inflexible. But I’ve found a product on Tindie that fits the bill perfectly, the Re:load 2, an adjustable Dummy Load. I’ve ordered three of those and will test one of my prototype LED shields as soon as they arrive.
Once all the above has settled to my satisfaction I will start the Fundraiser.
Well, both, kinda sorta eehhh….. But let’s take a step back.
A good while ago I designed and made an adapter board that combines a Teensy++2 and a WIZ812MJ Ethernet Module and currently the hardware in the photo below is installed and happily working in a Lighting system that employs five(5) HP LED shields (the older version). To the left is a TP-Link TL WR703n pocket router that connects to the WIZ812MJ Ethernet Module. An additional Ethernet Jack and Cable is used on the board to connect the I2C bus signals to another little adapter board plugged into the LED shield . This way 5 LED shields are daisy-chained together in the said LED lighting system.
I had to modify it from what is shown in the photo though and that was one of the reasons that I wanted to upgrade the concept for future installations. I had a Teensy3 as a Reward from the Kickstarter Project and as shown in the last post it works quite nicely and uncomplicated with the LED shield. It has to be said though that the shown configuration is NOT recommended. The Teensy3 is a 3.3V micro-controller and the outputs are not 5V tolerant. An I2C level converter should be used, e.g the one from DSS circuits or from Adafruit.
Also, the system above had some limitations. The Teensy++2 employs an Atmel processor that can run the I2C bus at max 400KHz, so it is not FM+ compatible, however all the components on the the HP LED shield are FM+ compatible (with the Exception of the temperature sensor!) so can be operated up to 1MHz. Also FM+ compliant components allow for much more drive current (30 mA vs. 3 mA) allowing for much higher allowable bus capacitance (4000pF vs. 400pF). In essence one can operate the I2C bus much more populated with devices and/or longer cable length at higher bus frequencies resulting in higher data transfer rates. The Teensy3 is able to operate the I2C bus at frequencies well in excess of 1MHz. Alltough it is not per-se FM+ compatible.
Another problem that I ran into and which is the reason I had to modify the hardware shown above, is that the power supply for the whole equipment to the left of the LED shield came from the little on-board 5V switching power supply of the HP LED shield. As long as it only has to operate an additional Arduino or Teensy that’s fine but the Ethernet & WiFi router hardware is more demanding and instead of the +5V from the LED shield I had to hardwire the VIN from the HP LED shield to an extra TSR-1xxx switched mini power supply to supply power to the Teensy++2 WIZ812MJ adapter board.
It would be nice as well to be able to just stack a processor board directly onto an HP LED shield or onto a stack of these, without the immediate need for an Ethernet cable.
So I started to lay out a board with all the necessities, but noticed it looked rather bare in terms of traces. The WIZ820io needs the usual SPI connections (+3.3V, GND, MISO, MOSI, SS, SCK) and the I2C bus only requires 3 traces (SCL, SDA, GND). That would have been a total waste of all the pins the Teensy3 has to offer and I decied to see if I could route at last some of these these to the usual Arduino pins on the periphery of the board. And the results of that effort is what I jokingly call an Ueber Arduino or perhaps its more a Frankenduino :