Microsoft Teams Deep-Dive – Canberra follow-up

I presented a Teams Deep-Dive session at Microsoft’s office in Canberra this week.

At the end there were a few links I wanted to share with the participants, and a few homework questions I wanted to research and respond to. A blog post seemed the obvious way to provide them with that info.

The below will be of greatest relevance to the attendees, but even if you weren’t there I think you’ll find some bits of interest.

Continue reading ‘Microsoft Teams Deep-Dive – Canberra follow-up’ »

SfB 2015 Server Update – August 2019

Hot on the heels of last month’s CU10 comes CU10 HF1 – the “whoops” fix-up release.

This is build 6.0.9319.562, and it updated three components on my Standard Edition Front-End.

What’s Fixed?

  • 4518680 Can’t transfer external calls by using Polycom VVX phones in Skype for Business Server 2015
  • 4518679 Skype meeting disconnection due to missing session refresh in Skype for Business Server 2015

Note The fix for the following issue is reverted and it is not included in this cumulative update.

  • KB 4507230 Support LBR and branch site voice resiliency conflicting requirements in Skype for Business Server 2015

What’s New?

Nothing noted. No cmdlets have been added to the SfB module in this update.

Continue reading ‘SfB 2015 Server Update – August 2019’ »

Cscp logs Event 35009 – “Authorization Failed”

My colleagues and I recently encountered an intermittent problem with the CSCP reporting “Authorization Failed” when you tried to sign in.

This was a Skype for Business 2015 Enterprise Edition pool, and so it didn’t take long to localise the issue to just one Front-End server.

Each failed attempt dropped an instance of event 35009 into the “Lync Server” log:

Remote PowerShell cannot create InitialSessionState for user S-1-5-20. Cause of failure: Cannot find user in Active Directory with the following SAM account name: "S-1-5-20"

That SID belongs to the NT Authority / Network Service – and when we succeed on another machine, we see the traces* correctly trying to sign in as the SID of my admin account.

(* The reference to PowerShell in the log gave us cause to review the Centralised Logging for the “PowershellWebService” scenario, but it didn’t seem to add a great deal of value.)

A successful sign-in also drops the more friendly 35008 into the log:

Continue reading ‘Cscp logs Event 35009 – “Authorization Failed”’ »

Review: Poly EagleEye Mini USB camera

I’m a little late to get my mitts on an EagleEye Mini USB camera, but circumstances recently gave me cause to take a closer look.

If you’ve not encountered it before, the Mini is a compact 1920×1080 HD USB camera, initially designed to slot into the top USB port on your VVX501 or 601, but nowadays also supported on a Trio with Visual+, and even on a PC or Mac.


Poly’s website reports its features thus:

  • High-definition 1080p60 capture with true color hue saturation and brightness for the most accurate color rendition and life-like images
  • 4x electronic zoom and a 74-degree field of view
  • Simulcast video stream
  • Installs in seconds – no drivers needed

It’s officially a supported peripheral for Skype for Business video calls on a computer or video conferencing device.
Continue reading ‘Review: Poly EagleEye Mini USB camera’ »



I have the occasional need to send log files to Microsoft and other vendors from customers who have strict IT security requirements. These customers usually require all files be de-identified before they leave the premises, removing all host names and IP addresses.

This can be quite a tedious process, so I’ve created a small script file that edits a provided text file and:

  • uses a “find/replace” CSV file to replace all instances of sensitive text with replacement values.
  • obfuscates any unchanged IP addresses, replacing them with dummy text in the format “”, where the “nn” is the same number where-ever that IP address is encountered in the document. (e.g. the third IP address that’s found in the file will be renamed “”).

At a minimum, you only need to provide an -InputFile. With only this, the script will replace all IP addresses with dummy values, then save a copy of the file with a “-new” suffix.

Continue reading ‘New-ObfuscatedFile.ps1’ »

Azure – Resource Provider Not Registered

I’ve been following one of Tom Morgan’s excellent tutorials on creating Bots for Microsoft Teams, and I hit an unexpected hurdle very early on in the process – but as it turns out, the fix was a simple one.

Resource provider 'Microsoft.BotService' not registered for the subscription

Fair enough, I say. Let’s register.

I navigated to All Services then searched for and selected Subscriptions, then selected my Subscription and Resource Providers. There were a lot there, so I filtered for, only to be greeted by the news that I *was* already registered:

Seeing as I was already here and there was an option to Unregister, I went down that path. Refresh, wait a bit, Register and BOOM, I was back on the air.

The moral of the story? Even in the cloud, turning something off and back on again remains a viable fix.

Revision History

9th August 2019: This is the initial publication.

– G.

SfB 2015 Server Update – July 2019

It says August 1 on my calendar, but this update is badged July 31st on the download site, so July it is.

Known Issue: “call hold,” “transfer,” and “resume” options for the Polycom VVX series may fail. (See below for more details.)
Fixed: See SfB 2015 CU10 HF1

Our last CU (May’s CU9 / 6.0.9319.548) has now been rendered obsolete by CU10 – 6.0.9319.559. It updated 7 components on my Standard Edition Front-End server.

What’s Fixed?

This cumulative update includes a defense in depth fix and enables Location-Based Routing to support the Skype for Business mobile clients. It also fixes the following issues:

  • Kb 4510852 UCWA client is disconnected because w3wp.exe crashes when using clarity connect in Skype for Business Server 2015
  • Kb 4510851 SCOM SQL alerts are created every hour on SQL Secondary Replica server if “Always On” for Monitoring Server is set in Skype for Business Server 2015
  • Kb 4510850 Skype for Business on Mac user’s latest photo can’t be seen until signing in to a Windows client in Skype for Business Server 2015
  • Kb 4511313 “Too many outstanding requests for a single user” error occurs on Front-End servers in Skype for Business Server 2015
  • Kb 4510847 Rate My Call on UCWA clients still shows after installing the January 2019 Cumulative Update for Skype for Business Server 2015
  • Kb 4510846  “InstallDatabaseInternalFailure: An internal error has occurred…” error when installing new databases in Skype for Business Server 2015
  • Kb 4507230 Support LBR and branch site voice resiliency conflicting requirements in Skype for Business Server 2015
  • Kb 4459114 The installed local XDS database version isn’t matched with the expected version in Skype for Business Server 2015
  • Kb 4507232 Resuming a PSTN call that was put on hold results in one-way audio in Skype for Business Server 2015
  • Kb 4510845 UCWA Event ID 20002, 20003, and 20033 occurs after you install the July 2018 cumulative update for Skype for Business Server 2015
  • Kb 4510844 Can’t find the response group agent that’s synced from an existing distribution list in Skype for Business Server 2015
  • Kb 4510843 Forwarding a missed call from Shared Line Appearance fails in Skype for Business Server 2015
  • Kb 4507228 No notifications from UCMA conference subscriptions after a network disconnection in Skype for Business Server 2015
  • Kb 4510842 Form-based authentication still works after you disable external basic authentication in Skype for Business Server 2015
  • Kb 4510841 Skype for Business 2015 Mediation Server doesn’t respect the codec prioritization for outgoing PSTN calls
  • Kb 4510840 Error ID 28042 and UCMA sign-in fails in Skype for Business Server 2015
  • Kb 4510839Skype for Business still rings if a PSTN call is ended before it’s answered by an online user in Skype for Business Server 2015
  • Kb 4510855 Can’t edit interactive RGS workflows via the web interface in Skype for Business Server 2015
  • Kb 4507233 Enterprise users can’t request control of an anonymous user’s shared screen in Skype for Business Server 2015
  • Kb 4510856 User can’t create Skype meeting for a delegator via Skype for Business on Mac if they’re homed in different pools in Skype for Business Server 2015
  • Kb 4512879 UCWA client can’t make a P2P call or join a conference when EnableExternalAccessCheck is True and EnableOutsideAccess is False in Skype for Business Server 2015
  • Kb 4503584 “The Audio/Video Conferencing Server has failed to create a conference” error (ID 32005) occurs on Audio/Video Conferencing Server in Skype for Business Server 2015

What’s New?

Nothing noted.

Continue reading ‘SfB 2015 Server Update – July 2019’ »

Yes, I’m gay. Why even mention it?

Occasionally someone will be brave enough to ask why I give my sexuality top billing in my Twitter profile and bios:

It probably seems a little out of place given that if you search the word “gay” on my blog you’ll find the only hit – singular – is on my “about” page (until now that is).

That I’m gay isn’t relevant to what I do for a crust – no questions about that.

It’s purely a visibility thing.

Continue reading ‘Yes, I’m gay. Why even mention it?’ »

DHMG2019 – the Disco Death Star – Pt.2

This is part 2 of a 2-part series covering how we built the “Disco Death Star”:

Part 1 – The Build – construction and assembly
Part 2 – Control, programming & examples – (this post)

The controller

Here’s the final version of the control PCB. It’s a bit of a dog’s breakfast, but it’s what you get when your proof of concept morphs through prototype stage to become the finished product.

At the left is the Teensy 3.6 that’s running the show, and on the right is the “Octo Level Shifter FeatherWing“. The level shifter is there purely to convert the Teensy’s 3.3V IO pins to the 5V required by the LED strips. I SHOULD have used a “Teensy 3.2 OctoWS2811 Adaptor“, but I didn’t know at the time it existed – and of course that explains why there wasn’t a Teensy version in the store and was forced to compromise on this Feather version. (D’oh!)

To the right of the Level Shifter are 8 header pins – those are the data feeds to the ball.

As it was initially built, that’s all there was. When you applied power the ball ran the chases in a random order, each for a semi-random period of time (in between two bounds I’d hard-coded).

Let’s add some DMX

Later some friends decided they thought it would look great at the annual Tropical Fruits New Year’s party in Lismore, and for that it would need some proper remote control – and for that it would need to respond to the “DMX512” digital lighting protocol.

I won’t go into the DMX side of things here in much detail, but suffice to say I didn’t think there was enough grunt in the Teensy to balance the timing requirements of receiving the DMX512 data string AND driving all the LEDS out 8 IO pins simultaneously – and if there was, I doubted my own ability to pull it off.

Accordingly, I opted for a discrete controller, based on a SparkFun ESP32 Thing Plus and its DMX to LED Shield. Special commendation here goes to luksal for their ESP32-DMX-RX, which worked for me where the native SparkFun library would not.

My DMX interfacing needed to be primitive because I didn’t want to add a processing load to the Teensy, and so it uses 5+3+3 IO pins in a parallel arrangement to signal pattern, speed and brightness, respectively. All of this is the cluster of cables at the top of the board in the image above. Five of the connections are the top five bits of the eight bits of the first DMX channel, giving a possible 32 patterns, whilst the other six pins are two lots of three IOs that give eight possible speeds and eight brightnesses.

The heavy black cable in the image is the “panic button”. Should the ball controller lock up at all – as it’s done on very few occasions – taking that IO pin high out of the DMX receiver would pull the Teensy’s hardware reset pin low. This inversion is done by the BC547 transistor visible among the yellow cables at the top left of the board.

Finally, what’s the back-end of a toggle switch at the top right switches the controller in and out of DMX mode. With DMX switched off, the ball goes into an automatic mode (subject to the code).

Programming it

It may come as no surprise to learn that the ball’s code started life as the “DemoReel100” example from the FastLED codebase on GitHub.

// FastLED "100-lines-of-code" demo reel, showing just a few 
// of the kinds of animation patterns you can quickly and easily 
// compose using FastLED.  
// This example also shows one easy way to define multiple 
// animations patterns and have them automatically rotate.
// -Mark Kriegsman, December 2014

Thank you Mark.

To that I added the XYMatrix for the “serpentine” layout, and later the parallel output and eventually the OctoWS2811 code which saved the day, giving the ball the speed boost that it so desperately needed at the time. (I had help from Reddit here too, as I was way out of my depth and running out of time.)

With the code running – albeit on the “test ball” referenced in Part 1 – I created some basic patterns of my own. Here’s an example of how simple this can be: turn on every LED in a column (`for (int y = 0; y < kMatrixHeight; y++)`), and rotate around the ball - remembering to turn the previous column off as you go. When you increment the column counter and it overflows off the edge of the ball into invalid space ('x >= kMatrixWidth’), reset the column to zero and keep going.

Once I had it running I added “int stripes = n;” which then let me make the lighthouse’s “beam” multiple columns wide.

void lighthouse()
  int x = patternLastX + 1;
  if (x >= kMatrixWidth) { x = 0;}

  int stripes = 2; //How many columns wide is the lighthouse beam?
  for (int y = 0; y < kMatrixHeight; y++)
    leds[ XY( x, y)] = CRGB::White;
    if (x - stripes >= 0)
      leds[ XY( x - stripes, y)] = CRGB::Black;
      leds[ XY( kMatrixWidth - (stripes - x), y)] = CRGB::Black;
  patternLastX = x; // ... and pass back to the main loop.

I find it amusing that our persistence of vision sometimes makes it look like more LEDs/columns are lit than really are.

Here are some of the amazing patterns we were able to find on the Internet:

“Matrix effect” – Jeremy Williams

“Pride” – Mark Kriegsman

“Fire2012WithPalette” – Mark Kriegsman

“Applause” – Jason Coon

“Plasma” –

“BPM” – Mark Kriegsman

“Rainbow – with glitter” – Mark Kriegsman

… and here are a couple of my own creations:


“Reverse Corkscrew”


  • The ball started life as a ~4′ beach-ball, to which we applied 20 layers of papier mache, consuming around 8L of PVA glue.
  • The ball is covered with 96 meters of WS2812B strips, cut into 64 x 1.5m lengths.
  • Each of those 64 strips has 45 LEDs, to a total of 2,880 LED pixels.
  • Each pixel contains a separate red, green and blue LED, all individually addressable.
  • Each coloured LED in the pixels will draw 20mA at full brightness, so if you wanted the ENTIRE ball white at FULL intensity, that’s 3 x .02A x 2880 = 172.8A @ 5V.
  • There are two Mean-Well LRS-350-5 60A supplies mounted to the shaft inside the ball. This “theoretical” shortfall of 52.8A means I can’t run the ball at full white, which I never intended would happen. The power supplies have over-heat and over-current protection, but I’ve never put this to the test.


The ball wasn’t the cheapest to build. Here’s a VERY quick back-of-an-envelope summary:
$145 – the ball itself.
$365 – the WS2812B LEDs – courtesy of “Chinly” on eBay.
$128 – the big-ticket electronics (Teensy, Level Shifter)
$180 – 2 x power supplies

That’s a total of $818, to which you’ll need to add several $hundred of misc electronics and hardware, so let’s call it easily a thou+. (We’ll overlook the LED string on the “test ball”, the second set of Teensy & level shifter, and some of the eBay power supplies I binned in disgust.)

All prices are $AU. Divide by 1.45 to get a rough $USD conversion.


SO many people have contributed to the FastLED project, and I’m indebted to them all. Thank you!

The patterns I’ve found online made up the lion’s share of the 32 that are coded into it. I’ve endeavoured to credit them all in the code, and in the videos of them on my YouTube channel.

Special thanks to Rocky for patiently papier macheing the ball over more than a fortnight. Had we realised at the outset how much effort would go into this step alone, we would have abandoned this as a technique, and maybe the whole project altogether.


  • The DDS code. It ain’t pretty, but it’s there to poke at.
  • My fairly rudimentary DMX control.

    Lessons Learnt

    If we had our time over, we’d do a few things differently. Here’s the short version:

    • If you don’t know what “FastLED” is and couldn’t tell a ws2811 from ws2812, you’re going to probably need months of nights if you’re going to do anything complicated – and that’s AFTER all the bits arrive from China/where-ever. The PacMan pattern only took a couple of hours to knock together once I had the ball going, but complicated patterns like those of the other contributors take some in-depth understanding of the module (and possibly a maths degree).
    • From my own personal experience, I’d say DON’T BUY power supplies from eBay. It seems to me that all of the vendors selling into Australia at the moment are selling what I’d consider to be seconds stock – or as you’ll see above, repaired returns, sold as new.
    • DO buy proper Mean-Well supplies from the likes of Power Supplies Australia. I’d never heard of them until I started desperately searching for power supplies I can trust, and they rescued me at the 11th hour with *proper* supplies, well-packed and shipped overnight. Exceptional service and I can’t recommend them higher.
    • We fluked this one, but if you’re building a ball like this, DO choose a spacing that lets you run a number of columns that are a power of 2 – and by that I mean 16, 32, 64 or 128. Why? When it came time to stick the LEDs to the ball, we wanted to make sure we didn’t screw it up. By being a power of 2 it meant we could start with one strip, then put the next halfway around the ball, and continue dividing it in half with each strip. The end result is any errors should be averaged out, and you won’t get to the end of the ball and not have enough space – or too much space – for the last strip(s).
    • One mistake we made was sticking all the LEDs down starting at the top, and the result is that some of the strips ended up out of vertical alignment by the time they got to the bottom, which is visible when the patterns are chasing. As the ball is above people, we should have laid the strips on from the bottom to the top.
    • The adhesive on the LEDs will not hold. You’ll need to add some drops of SuperGlue at regular intervals.
    • You’d have to be nuts to choose this papier-mache path. SOMEONE will be able to sell or make you a sphere / two hemispheres of fibreglass.


    Revision History

    31st December 2019. This is the initial publication, back-dated in the blog’s timeline to July 27th.
    8th January 2020. Corrected the $US conversion maths. (Thanks James). *blush*

    – G.

    DHMG2019 – the Disco Death Star – Pt.1

    If you’re new to the “DHMG” – our annual housewarming party – and its attendant excuse for some crazy home-brew tech, there’s some back-story and an index of the things we’ve done here.

    This is part 1 of a 2-part series covering 2019’s “Disco Death Star”:

    Part 1 – The Build – construction and assembly – this post
    Part 2 – Control, programming & examples

    The Lead-up

    At some stage in around April each year we realise it’s 12 weeks until our annual party (nowadays always the last Saturday in July), and we madly thrash around in some kind of panic state until we come up with an idea for “the effect”. This year was no different.

    The concept we settled on was a large ball COVERED with as many individually-addressable RGB LEDs as could fit onto it: like a giant self-illuminating mirror ball.

    We’ve used RGB strip LEDs before, but only the 4-wire ones where the whole strip is the one colour. This time we needed to take the plunge to the “WS2811” family and its derivatives.

    Having committed to the idea, the build commenced with two parallel streams: the construction of the ball, and all of the electronics we were going to adorn it with.

    Building the Ball

    I shopped around for big hollow balls and drew a blank. That left us with the default position of covering a beach ball with papier-mache.

    Having sourced and inflated the ball, the first fear set in. This thing is HUGE! I probably coulda gone with the next size down. Oh well, too late for that.

    In preparation for papier-mache, we covered the ball with a few layers of cling-film. This was to ensure we could easily deflate and remove the ball later. The black gaffa tape around the middle is just to keep the cling-film in place until we had some layers of paper over it.

    The internet suggested we use either a glue made of flour, or alternatively PVA glue, and given our more industrial intent we opted for the latter. The whole ball took around 8 Litres of PVA, diluted in a 3:1 ratio with water.

    Luckily for us some of our more elderly neighbours still buy newspapers, so a bit of domestic dumpster-diving over several weeks provided the other required raw material.

    We were only a layer or two in when we noticed some cracks in the ball. This was as a result of the air inside the ball expanding and contracting between the warmest peaks of our winter days and what we Sydney-siders consider the freezing depths of night. It was with some relief that that stage seemed to pass without causing any problems.

    We ended up layering the ball with 20 layers of paper, and the resulting crust is maybe 8mm thick. Each layer was applied in two sessions, with the top (or bottom) half going on first, let to dry a little, then the ball gently inverted and the rest of the layer applied. Each of those 20 layers took between 3 to 4 hours to apply, so we’re talking 2 solid person-weeks of gooey crafting (all the while trying to keep the cats out of the splash zone underneath).

    Thankfully it came out looking spherical – although the layer of matt black paint helps that effect. (BTW, we deliberately added extra paper at the very top and bottom of each layer to add extra strength at the critical load-bearing points.)

    Once we’d decided we were done, a hole was drilled near the top to puncture the ball, then after it deflated a little naturally we enlarged it so we could get to the inflation point and attach the vacuum. It didn’t take long to remove all the air and fish the ball out.

    Here’s Rocky modelling it.

    LEDS & the Electronics

    While all the papering was taking place, the serious bits of the electronics were sourced and prepared.

    WS2812B LEDs

    I got off to a false start here and learnt a lesson in the process. Lots of eBay vendors seem to deliberately list their LEDs as “WS2811 / WS2812B”, quote the price for the cheaper one (the 2811), and play upon the inexperience of n00bs. Ouch. Insert ~2 week delay here.

    I had set my heart on using 12V LEDs so I had less current to deal with on the ball, and thus lower power losses. Alas, it turns out that WS2811 runs on 12V, but has three discrete LEDs per ‘pixel’ (addressable channel), resulting in what would be an unacceptable loss of resolution on the ball.

    That forced me back to the 5V WS2812B, where each little white LED square is truly individually addressable.

    WS2812B is available in 3 LED densities: 30, 60 or 144/150 LEDs per metre. The more LEDs the higher the ball’s resolution, but with the added extra procurement cost, increased power consumption and driving complexity.

    I settled on the 30LEDs/m variant. Its ~3cm LED spacing meant I could space the columns 3cm apart around the ball and have each LED roughly equally spaced.

    Given the diameter of the ball, that came out to 64 columns, a fortuitous figure we’d only appreciate the value of the week before the party. (More on that in “Final Assembly”, below, and in the next post’s “Lessons Learnt”.)

    Some research online ‘led’ me (sorry) to vendor “Chinly”, and I bought TWENTY 5m rolls of the 30 LEDs/metre, non-waterproof configuration.

    While I waited for them to arrive from China, I built a “test ball”, using a 5m roll of WS2812B’s @ 60 LEDs/m that I horse-traded with my eBay vendor after the WS2811 fiasco. I wrapped 16 strings of 16 LEDs around a piece of PVC downpipe to become my test rig. I was working away from home each week during this period, so I was able to pack the test ball in my luggage and set it up in my hotel room, trying to figure out how to code it at night. I honestly expected to be paged in the airport lounge the first day I flew with it, figuring it to have set the luggage X-ray machine into apoplexy, but I guess our domestic checked luggage isn’t scanned…


    The magic behind all this is the FastLED project, a “Fast, easy LED library for Arduino”. I’m truly in awe of this community and what they’ve been able to create.

    Part of the reason behind these two posts, and the videos of what I’ve been able to create with FastLED and OctoWS2811 is my way of paying back the contributions of all those without whom we wouldn’t have been able to pull this off – and of course to show the authors of the patterns I used what they look like when rendered on several thousand LEDs.

    I digested what I could and decided on a parallel drive setup, where 8 IO pins would operate in tandem, each driving 12.5% of the ball’s LEDs. I figured that would be able to drive them fast enough for my purposes. I was in for a nasty surprise.

    Cartesian Maths & a Serpentine Setup

    Despite the spherical nature of our creation, I’d always envisaged the LEDs as a flat Cartesian arrangement, simply wrapped around the ball. Viewed flat, the top left LED was at xy co-ordinates 0,0 and the last one was 63,44.

    As far as the FastLED code’s concerned though, this ball is one 96 meter length of LEDs laid end-to-end. The first pixel is LED 0, and the last one is LED 2879.

    It made the plans a lot easier when I realised that plenty of people have made “panels” of LEDs like this and conceived of the “Serpentine” setup where each alternate row of LEDs faces the other direction. You tell the code how many strips you have and how many LEDs are on a strip, and a function in the code decides if the LED you’re addressing is in an even or odd column/row (depending on your perspective/layout), and if it’s an odd row it “flips” the number of the LED in the strip (where the “first” becomes the “last”, etc) so that the correct one is lit.

    Here’s the concept graphically, using an image borrowed from the OctoWS2811 website, edited and rotated 90-degrees to reflect my layout:

    Each of my strips has 45 LEDs on it, and there are 8 strips per IO pin.

    With this working, much of what’s written – and certainly all my fairly simple routines – are a matter of an outer x loop and an inner y loop taking care of what we’re going to light.

    Teensy 3.6

    With the “how many LEDs can I drive” question having a “piece of string” answer, I decided early on that I’d throw everything I could at this, and I made several lucky guesses that thankfully paid off.

    I’d looked into high-powered Arduino-compatible devices recently for another project, so I was aware of the Teensy family.

    The latest-and-greatest Teensy is the “Teensy 3.6“, which sports a 32 bit ARM Cortex-M4 processor ticking along at the seemingly blinding 180MHz! The 3.6 doesn’t seem to be supported (by any documentation I could find), but its precursors were, so I rationalised it was the doco not up-to-date rather than a technical limitation, and took the plunge. Or tried to.

    It turns out that the 3.6 is in short supply. So short in fact that someone managed to snaffle the 2 out of my online shopping cart between me clicking “add” and making it to the checkout. Thankfully my Plan B – littlebirdelectronics (my new Plan A) had stock, and were able to get a pair to me quick-time.

    Note that the Teensy’s IO pins operate at 3.6V and the LEDs run on 5V, so you’ll need a 74HCT245 to do the voltage conversion. I was to have my OctoWS2811 realisation a little later in the piece, and so at this stage I bought one of Jason’s level shifter PCBs, and then set about interfacing it to the Teensy. With the benefit of hindsight I now realise that I’d basically just built an OctoWS2811 Adapter the hard way. Ouch.


    With the LEDs on order I needed to find a power supply. Each LED pixel contains 3 discrete LEDs (red, green and blue), and each of those can draw 20mA. Decide you want a given pixel white – which you get by turning all three on – and you’re talking 3 x 20mA = 60mA, aka 0.06Amps.

    THEORETICALLY, if I was to turn the ENTIRE ball white at full intensity, I’m going to need to find 2880 x 0.06A = 172.8A @ 5V. I decided that I will never let this happen, and compromised down to a situation where I’d power the ball with 3 x 40A power supplies, which should leave me plenty in reserve.

    Now came the eBay fiasco.

    I swear all of the sellers of LED power supplies on eBay in Australia are the same vendor, selling the same rubbish stock, to which they fail to add any packing and which will nearly always arrive damaged two weeks later (so much for “local stock”).

    Here are two examples: the first is just one of the several supplies that arrived crushed or with a broken PCB. The box you see is the one it was shipped in. Not a dot of bubble-wrap to be seen anywhere.

    The second is a supply that arrived with a very prominent rattle, which turned out to be one of its large storage capacitors floating freely inside. Imagine our surprise to find that this “new” power supply is repaired stock, and this unit has had such a catastrophic failure in the past it’s vapourised part of the track, necessitating the addition of the black wire in the repair.

    Others – replacements, re-orders from another seller but probably an alias of the same merchant – arrived with slightly less damage, but signs of tarnish that only reinforced my belief that these were all reject or repaired stock.

    Having lost trust and with time running out, I abandoned the lot – and eBay – and went in search of “proper” supplies online.

    I was lucky enough to find Power Supplies Australia, who sold me a pair of solid 60A “MEAN-WELL-LRS-350-5” supplies that I have a great deal more trust in. Oh, and they ship them well-packed. I can’t thank these people enough for rescuing the project at this late stage.

    I don’t have a proper photo of the final power ‘board’, but you can see it sitting on the bench in the final image in this post.

    The two supplies are each mounted on a piece of plywood, back-to-back with a piece of ~3cm pine through which an 8mm hole has been drilled. The power supply assembly then slides down the shaft and is held in place with more locking nuts. A mains cable comes out of the central hole, as do 46 short leads to which each of the LED strips plug. The 2 extras I used to power the Teensy and for a utility “power-on” indicator LED. A weakness of this setup is that the power-on LED is only monitoring one supply and should the “wrong” one shutdown through an accidental overload, it’ll take out the Teensy and thus the whole ball. Ideally your Teensy will be powered by an independent 5V source.

    Final Assembly

    I mentioned earlier that deciding on 64 strips on the ball turned out to be a magic number, as it let us nicely divide the ball in half over and over again.

    We started with the ball upright, and used a laser leveller we happened to have here to mark a vertical line on the ball. We then rotated it 180° (confirmed with a cloth tape measure) and made another vertical line, then rotated it another 90° – halfway between the existing lines – and repeated the process until we had 4 vertical ‘bearings’ from which point we’d keep dividing the ball in half.

    From here we moved the ball to a horizontal position so the strips could be applied.

    Each LED strip had been previously terminated with a power lead to make for easier connection and debugging. 32 of those have the power fed at the “top” (“signal in” end) and 32 are the other way ’round. (Refer the serpentine layout drawing earlier.) Eight were deemed the first in each string, so had a long wire attached to take their feed from the Teensy, and all bar eight (the end strip in each group) had a short data wire that I would later solder to its neighbour to loop the data circuit through. Having done all of this in advance made the task of getting the strips on the ball a lot easier.

    We mounted the first four following the lines we’d made before, using the cloth tape measure to double-check the alignment before we peeled the covering off the adhesive backing. (It’s definitely a 2-person job).

    From here on in all we did was divide the ball in half each time with the tape measure, adding a new strip at the mid-point between two strips. We measured at the top, middle and bottom of each strip before committing it to its final position with the adhesive.

    Here’s Chip surveying our work while we paused for a dinner break at the half-way point:

    32 strips in – all facing the same way – we’d divided the ball into an even number of slices, and we were left with 32 gaps. That then meant we could layer the next 32 in the other direction, each mid-way between the first lot. (If you look at the image above you’ll find no data tails visible. The first 32 strips were the “down” strips, so all the tails are at the other end.)

    Here’s the ball, mounted “spit-roast style” after we’ve finished sticking the strips to it. Its central shaft is 8mm threaded steel rod, with the papier mache at the bottom (the ladder end in this image) sandwiched between two circular metal plates providing a relatively large surface over which to spread the load, and at the top with the criss-cross of gal strapping, also with matching pieces of strapping on the inside of each 3/16″ screw.

    With all strips placed and checked it was a relatively simple matter of soldering the data tails at the end of each strip to its neighbour… and the smoke test.

    Powering it up

    I’ll confess now that that I wasn’t so bold as to throw the switch and pray. There was too much at stake for that.

    I made a little test rig with a random 5W resistor (10 ohms) in series between a 2.5mm plug and socket. Across the resistor I clipped the multi-meter set to read volts, and I plugged in each strip in turn, looking at the voltage dropped across the resistor. Each read something like 200mV, which I decided was OK. That was just providing an indication of the ambient/quiescent current drawn by the strip, and indicated no fault. If the voltmeter had read 5V or anywhere near that, it would have meant there was a short on that strip that needed to be investigated.

    With the strips deemed OK, *then* it was the time for the smoke test. Success!

    I then did a quick logic test, feeding a single IO pin into each of the 8 “slices”. Each lit 8 strips, so we were good to go.


    From this point in I could focus on the programming, but that’s a story for Part 2.

    References / Research

    If you’re still contemplating such a project, here are some resources that will hopefully smooth some of the bumps out of that learning curve:

    Stay tuned for Part 2 where I show some code, link to the GitHub Repo that hosts the ball’s code, and videos of it in action.

    Revision History

    31st December 2019. This is the initial publication, back-dated in the blog’s timeline to July 27th.
    – G.