SmartMatrix APA102 Library / Open Hardware Photon APA102 Shield

Here’s the latest schematic and rough part placement on the layout. I’ll share the Eagle files on GitHub next time I work on the board.

Some notes:

  • I used AND gates instead of plain buffers to give the option of using the APA102 lines for something other than driving the LEDs (same as the Teensy prop shield). I don’t know if they will ever be used, but the AND gate was the same cost as a buffer, and adding a resistor is trivial, so why not. The default configuration is that the LED drivers will be always on, and the LED_ENABLE pin will be disconnected so it only takes 2 pins to control the LEDs.
  • C2 might not be necessary to smooth out ripples in the power supply, but I put it on anyway
  • You can connect VIN to VEXT directly by jumping the pads of JP8 (SMT) or JP6 (THT). I placed the THT holes far from the APA102 pads to give some space for putting some pins and a jumper. I figure adding right-angle pins pointing toward the USB connector is the best option, as it will be out of the way. The SMT pads are currently on the top layer, hidden under the Photon. I could easily put them on the bottom layer so they’re exposed, I don’t have a big preference here.

Feedback requested:

  • What should be done with the extra space between the mounting holes?
    SparkFun leaves this section open. Do you think adding unconnected prototyping pads here would be useful? There’s enough space for two rows on each side.
    • Downsides to adding more prototyping pads on the edges:
    • That space is needed to provide labels for the pins. Because of the 2x12 female sockets, there’s no blank row like where SparkFun put labels on their shields.
    • it would make it more difficult to break off the edges of the board to decrease the size of the shield.
  • Where should the SMT jumper for semi-permanently connecting VIN to VEXT go, top or bottom layer? (It’s a bit hard to see the jumper right now, it’s the red rectangles centered between the two green THT pads below the microSD shield.

The latest schematic and layout is now on GitHub:

I made a hybrid footprint for the shield with SMT and three rows of THT pads on both sides. I used the blank space on the sides for labels.

If anyone has feedback (see previous post), now’s the time. I hope to get this routed and sent off to OSH Park in the next day or two.

1 Like

I wrapped up a V0.1 version of the board and just placed an order with OSH Park. The Eagle files, PDFs, and Excel BOM are up on GitHub, and I shared the project on OSHPark.

I won’t know what issues this version of the board has until I receive it and assemble a few, but if you’re brave you can order now.

The 2x12 female connectors are quite expensive, the BOM lists the same ones used in the Internet Button because they are readily available. There are some alternatives, 4Uconnectors makes a ~$0.35 part but they are short enough the Photon’s pins will stick out a bit, and have a 1000 piece MOQ (though you can order samples). I also got some samples from China that are a good match for the 3M part used in the Internet Button, but no part number or price yet.

3 Likes

Hi, this loods good, will you sell kits ? I wonder how to solder the SD card connector, so if you would also offer finished PCB’s i would be happy to go for that.

Hi @rudyvan, I think the microSD connector needs to be soldered with solder paste and a hot plate or oven. I do plan on selling the boards assembled when the design is finished, though I don’t know the details yet.

If anyone is ordering parts to build one themselves, I found another source for the SMT 2x12 connector. Samtec has the SSM-112-F-DV-BE (little too tall) and HLE-112-02-F-DV (little too short), and they do free samples with free overnight shipping. I’m not sure if either of these is an exact fit for the pads on the board, but I ordered 10x samples of each and will try. They’re a little too expensive for low-volume production at ~$2 ea, but better than the 3M part currently on the BOM.

My China source said the 5mm high connectors are a special order item with 1k piece minimum and cost of about $0.70 ea. I looked on eBay and Aliexpress and found similar connectors but either not enough pins (2x10) or way too many pins. I’d prefer not to do a special order, but it’s an option. I’m asking for quotes on a ~3.8mm connector, which is short enough the Photon’s pins will stick out the end of the connector, but I don’t think that’s a big problem.

OSH Park delivered early! The boards were supposed to be received from the fab and then mailed on May 11th, but I received them in the mail May 9th, gotta love that.

I assembled two by hand with a soldering iron, no solder paste, hot plate, or hot air. Despite how it looks, you can solder the microSD connector with an iron: use the window on the top of the connector to feed solder and see what you’re doing, and use a thin tip iron through the front of the connector.

I’m pretty happy with how the board turned out when used with the Photon. I used the 3.5mm high sockets from Samtec, and the pins stick out a bit through the socket, but I don’t think it’s a problem. For the Electron, I didn’t consider that the parts on the bottom of the Electron would interfere with the microSD card on the top of the APA102 shield. The inductor on the bottom of the Electron hits the shield and prevents the Electron from sitting properly. With the short sockets, I believe the pins are actually making good contact, but it’s not ideal. I don’t have a good fix for this, so the shield is unlikely to have Electron compatibility.

Quick tests are good, I can run a SmartMatrix sketch and drive the APA102 LEDs, and the Photon gets powered through the APA102 wires. I can run a SDFat library sketch and read/write to a file on a microSD card.

I added the jumper that connects VUSB and VEXT powered the board and LEDs through USB only. I ran FastLedNoise on a 16x16 matrix with brightness 64/255. The display looked fine, and a USB charger doctor showed the voltage had dropped to about 4.5V, and current draw was about 600mA peak.

I want to do a few more tests:

  • Test microSD and driving the LEDs simultaneously
  • Test something that taxes the power supply (e.g. flashing all white at full brightness on and off), and see how VIN looks on a scope, with and without the 10uF cap I’m still considering making DNP
  • Test writing to the microSD while taxing the power supply, check the scope
  • See what happens with a high current sketch on USB power - where does it break?
  • Test the optional enable circuit
5 Likes

Thank you for sharing this design. I’m powering ledstrips with an external power supply, however I don’t what that they draw power over the Vin when I connect the Photon to USB.

I think in your design D1 serves that purpose?
I see in the BOM that you didn’t use D2 anymore? Is that because it actually on the Photon board already?

Why is there a 10uF cap on the Vin?
In another designs with CE mark test I see that they apply 100nF caps (see also: Passing a CE test with a Photon with headers [sharing my solution])

Hi Kasper,

D1 allows VEXT to power the Photon and prevents current from flowing in the opposite direction. D2 is DNP but I added jumpers to give people the option to power the strip through USB. I'm considering adding pads for a SMT 2-pin header on the bottom side of the shield that can easily be used with a jumper.

I'm not sure if C2 is necessary. I want to make sure that if the voltage on VEXT fluctuates, e.g. if there's a lot of LEDs turning on at once, that VIN is stable. I'll do some tests, e.g. writing to the SD card while VEXT is fluctuating and see how VIN looks on the scope with and without C2.

1 Like

Thanks. What does DNP mean?

@kasper, DNP = Do Not Place as in don’t install. :grinning:

3 Likes

I haven’t posted a real update in over a month, but the project hasn’t stopped. The first item on my testing checklist was: “Test microSD and driving the LEDs simultaneously”, and I started by trying to port the AnimatedGifs sketch. It’s taken me probably about 20 hours longer than I expected.

  • AnimatedGIFs is now a lot more stable, I was seeing crashes when trying to play large GIFs on the small 16x16 APA102 matrix I have.
  • I had a difficult time trying to figure out what SD libraries were available for the Photon and which library to use. There’s not an up to date port of Arduino’s SD Library, the most recent is this user-contributed port which was out of date and doesn’t compile for the Photon, but can be fixed with a one-line change. There’s a port of SdFat, but I wanted the sketch to maintain compatibility with the Arduino SD Library which comes bundled with the Arduino IDE. I’m really hoping Particle dedicates some time to make their build tools compatible with the Arduino 1.5 library spec as right now it’s not a lot of fun to be a library maintainer or library user with Particle tools.
  • I refactored a lot of the AnimatedGIFs sketch to turn it into a GifDecoder class that doesn’t care where the GIF is stored and how you access it. There are callback functions for the file operations, so you could fairly easily port the sketch to use SdFat instead of sd-card-library if you wanted, or store your GIF in EEPROM or a SPI flash chip instead and use another library to access it.
  • I made the class templated so you can set the max GIF size and max LZW decoding complexity (managing memory usage) in the sketch. Before these were hardcoded inside the decoder.
  • AnimatedGIFs had it’s own while(1) loop inside of loop(), and the ProcessGIF() function didn’t return until the GIF had finished playing. This doesn’t work well with Particle firmware which expects to get to the end of loop() to keep the cloud connection alive. Now there’s a startDecoding() method, and you can call decoder.decodeFrame() once per loop and it doesn’t block.

You can try the AnimatedGIFs sketch yourself if you want. I tested it building locally and with Particle Build in the cloud, but not with Dev. Change kMatrixWidth/kMatrixHeight to whatever you’re using. I’ve tested it with 16x16, but it fails at 32x32 on the Photon (I’ll investigate). You can use larger GIFs (e.g. the 32x32 and 64x64 examples included with the library), it will just show the upper left corner of the GIF and throw out the rest during decoding.

For Particle Build you’ll need to import this version of the sd-card-library so it compiles (and delete the original one if you’re using it to avoid a name conflict). Hopefully the author merges my one-line pull request soon.

2 Likes

Did some testing, nearly done:

  • Test microSD and driving the LEDs simultaneously
    • AnimatedGIFs sketch works
  • Test something that taxes the power supply (e.g. flashing all white at full brightness on and off), and see how VIN looks on a scope, with and without the 10uF cap I’m still considering making DNP
  • No noticeable difference with the cap removed. Voltage changes are slow - e.g. VIN changes for 33us at a time - a small cap isn’t going to make a difference

DC - yellow = VEXT, blue = VIN

AC - yellow = VEXT, blue = VIN

  • Test writing to the microSD while taxing the power supply, check the scope
    • Works
    • There’s less ripple on VIN when the 10uF cap is placed
    • There’s also less ripple on VIN when the board is idle and the 10uF is placed: I’ll keep the cap in for production

VIN while idle - no cap

VIN while idle - 10uF cap

  • See what happens with a high current sketch on USB power - where does it break? (16x16 matrix, 100% white, varying brightness, jumper connecting VIN to VEXT)
    • Sketch steps through brightness from 0-255 (min-max) rising then falling, 100ms per step.
    • In general, the voltage will drop very low at high brightness (<3V), but the LEDs stay on, and Photon stays on - some exceptions
    • Apple 5W charger - gets very red at high brightness, Photon stays active
    • Apple 12W charger - gets very yellow at high brightness, Photon stays active
    • HP ZR22w USB port - gets very red at high brightness, Photon goes to inconsistent flashing red on RGB led, APA102s are flashing, VIN < 2V
    • Monoprice USB Hub, 500mA Limit/port - white gets less and less blue at high brightness, Photon stays active
    • Macbook Air 2012 - USB device warning and serial connection is dropped (~248/255 brightness), but Photon remains running and Serial connection is eventually established when brightness drops, cycle repeats. Color gets a bit yellow at high brightness
    • EasyACC USB 3.0 Hub (Data not charge port) - color fairly stable at high brightness
    • I never saw more than 1.5A going through the shield using a current meter between the VIN and VEXT pins. I’m not sure what the limiting factor is. Some of the USB sources should be able to supply >2A
    • The VUSB diode on the Photon gets burning hot, and the Photon and shield gets quite warm. The shield traces connecting VIN/VEXT could be a bit larger to support higher current
    • USB power should used with caution as there is no fuse, high brightness can lower the voltage enough to disable the Photon from running, and the board (not to mention the LEDs) heat up at high currents.
  • Test effect of powering strip at far end vs end close to Photon
    • On 16x16 matrix, powering through the far end resulted in a ~300mV drop across the strip, no change in behavior though
  • Check CLK/DAT lines on the scope with various brightnesses
    • VEXT does vary a lot depending on the brightness of the LEDs, as the CLK/DAT buffers are powered through VEXT and a diode. CLK/DAT will be a few hundred millivolts below VEXT, sometimes this is quite low, e.g. 3V. The communication works even with lower voltages, as in that case the APA102 is only being powered with around 3.3V. If the voltage needs to be kept more stable, another power source can be connected to VUSB or VIN so the buffers get a consistent voltage.

Todo:

  • Test optional enable circuit
2 Likes

I've been working on the shield layout. I have a small list of changes for V1 (the first rev was V0.1).

  • Add a 1x2 SMT jumper on bottom side of board for VIN and VEXT
  • Add a 1206 100uF 6.3V cap to help with USB power kickback when long strip switches. I'm not sure if this is necessary, but there's space so I added the footprint, but it will probably be DNP
  • Increase width of VIN/VEXT traces
  • Improve the Photon footprint
    • Make it two parts as the connectors are two separate 2x12 headers
    • Fix the unnecessary DRC errors that show up in Eagle
  • Cosmetic Changes
    • Label the pins used on the Shield

Label the pins used on the Shield

There are now labels on the sides of the shield to show the pins used for driving the APA102 and reading the micro SD card

Improve the Photon footprint

The Photon footprint seems trivial, and you can totally skip over this part if you don't use Eagle or don't care about using this or a similar footprint in your design. I figure I should document this for others making their own Photon shields:

This was actually a big project. The footprint used in V0.1 is a combination of SparkFun's Photon Shield footprint, and Particle's Photon footprint used in the Internet Button. It's a single piece which causes confusion as it results in a single item on the Eagle-generated BOM when there should be two 2x12 sockets on the BOM. If generating XY data for a pick and place, there will only be one point for the Photon sockets, and if it's in the center of the part, won't match the actual location of either socket. Lastly, the overlapping THT and SMD pads and traces connecting the pads causes a lot of distracting DRC errors in Eagle that make it difficult to look for actual errors when using the footprint in the board.

210 overlap errors - all unnecessary as they are related to pads on the Photon footprint that we want to be overlapping

I found that Eagle has an Arbitrary Pad Shape feature, where you can use a polygon to make the pad any shape you want. I used that to extend the THT pad in the shape of the SMT pads on both sides, with wires connecting both SMT pads. It's essentially the same shape as the Particle footprint, with slightly rounded corners due to the polygon and wire size. The mask and paste layers were made manually with rectangles for each pad. I used 16-mil wires for the bounds of the polygon to avoid getting trace width DRC errors.

I split the footprint into a left and right side, so it would create two items in the BOM. When the parts are put next to each other on the schematic or layout, it's not obvious they are separate.

Each Photon pin has three THT pads in this footprint, which will be disconnected by default. You need to put a wire on each pin to tell Eagle these pads are actually connected so the layout knows the overlapping pads are intentional. If you're not using the Photon pin for anything else in your circuit, Eagle will give you an ERC warning that there is only one pin on the net, so I created a single-pin "NC" part (looks like a "X") with no footprint that you can put on the other end of the wire to make Eagle happy.

Even though the THT pads for each Photon pin in the footprint are all connected through the polygon, Eagle doesn't realize it and puts airwires between the THT pads. You can just route wires on the bottom layer between the THT pins to make Eagle happy.

There's a lot of workarounds in place here, but it's not too time consuming to use the parts. It only takes a minute or two to add wires to all the unused pins in the schematic, and route the airwires in the layout.

I plan on using these parts for future shields, and will add the parts to a standalone library at some point. For now, you can grab the parts from the schematic if you want to use these parts in your design.

2 Likes

@Pixelmatix, what’t the latest on this? :sunglasses:

Thanks for the ping! I had 100 shields manufactured, and got samples of 10 (the rest are in China). I found the JST cable supplier reversed the polarity on the connector, so the 90 still in China had to get reworked, but other than that I’m pretty happy with how the shields turned out.

The project has been stalled for a while as I’m working on a test fixture. Normally the test fixtures I’ve built have been hand wired, fragile, and are very product-specific in both hardware and software. Inspired by this post and the fact that there are about 64 test points on the APA102 shield (that I have no desire to hand wire), I started working on a reusable test fixture design. Right now it consists of an Arduino Uno shield with 64 GPIO and ADC inputs (96 in the future), custom adapter for the APA102 shield, and an Arduino shield-shaped board to hold pogo pin receptacles. By the end of this next week I will have put more hours into this test fixture design than into the APA102 shield and APA102 SmartMatrix Library modifications.

I’m flying to China in early November - for a few reasons, not just to work on the APA102 shield - and I plan to bring my test fixture, get all 90 shields tested, and if I’m lucky, find a company in China who can do worldwide fulfillment of the shields affordably. When the shields are available I’ll post a link here first.

I don’t plan on finalizing the SmartMatrix Library with APA102 support until the “Libraries v2.0” details get worked out. I want to be able to have a single release that supports both Teensy and Photon. @peekay123 do you have any insight into when that might be?

4 Likes

@Pixelmatix, sounds like your having a good time! Paul and his Teensy line never cease to impress me. As far as I know, Libraries 2.0 is due any time now and lots of folks are waiting. I’ll ping the Particle Team to get an update. :wink:

2 Likes

Just a follow-up. GBC works perfect with APA102. This enables me to lower the update frequency a lot (from 16Mhz to 2Mhz).

Since the APA102 leds where not so good available past year, I gave the SK9822 a try. However steps in GBC are visible on that chipset. Especially on the higher values. So I’ll stick with the APA102 leds.

Thanks for the followup! I was just in China visiting LED strip suppliers and they all said to switch to the SK9822 if possible as APA continues to have supply issues. Heard everything from that they have old fabs, oxidation issues, to disagreements with their Chinese side of the business (they’re based out of Taiwan).

I wonder if the ratios on the SK9822 for brightness adjustment are just a little bit different than APA102, and it can be adjusted with a tweak to the algorithm. I have some samples, but no time as of yet to try it out. I’ll report back if I get it to work.

The APA102 is great, especially with your algorithm, because that will give you essentially a 12/13 bit grayscale. Too bad, that they still keep having those suppling issues.

How would you see the algorithm, because now you step on each half value 128, 64, 32, 16, 8 with bit math. That would mean several if-statements with the SK9822?

How did you found the algorithm with the APA102, was it directly a lucky shot?
If you have some ideas I might be able to try something.