Posted: July 13, 2016 Filed under: Coding, Creations, Explorations, Getting A Clue, Reflections, That Totally Worked, Uncategorized | Tags: cdn, clearway, firesite, invention, inventions, patent, patents, startups
Bear with me here, because about 200 words from now I’m going to make a huge brag that I hardly ever talk about these days. OK, thanks. Let’s go:
In January 2001, “Web Hosting Magazine” published their “Top 100 Awards” issue.
Clearway Technologies, a company that I founded, shared an award for “Fastest Growing New Market: CDNs”. C.D.N. stands for “Content Delivery Network”, a system of helping deliver web pages, images, and videos faster over the Internet; the CDN that some people may be familiar with today in 2016 is Akamai, but back in the 2000’s, there were half a dozen CDN companies, all trying to get a slice of the CDN revenue pie.
On pages 42-43, Clearway, SolidSpeed, Speedera, EpicRealm, and Akamai were all called out for awards #5, 6, 7, 8, and 9, in the overall CDN area, and for developing this hot new marketplace.
And then, later on in the list of awards, we come to #68, given exclusively to Clearway, and to me, “For Inventing CDN”.
And you know what? They’ve got the facts right here. By the time Akamai was just barely getting started, I already had Clearway Technologies up and running, and we were already shipping our first CDN offering, and I’d already filed for the patent on our core technologies.
So while I’m a little too modest to be comfortable saying it, as far as I can tell, it’s true:
I invented the first CDN.
Now, while I do get to say that I invented the first CDN, “FireSite” and “FireSite.net”, I also have to say that I didn’t get rich from it. Clearway was initially a ‘bootstrap’ startup, and so grew very slowly at first. Here’s the entire company, in August 1996 doing our initial product launch at Macworld in Boston.
Later, we took in venture capital, and we grew Clearway to over 200 people. Here’s the team that helped do our ‘big’ launch at Networld/Interop 2000 in Atlanta.
So we grew the company and ultimately we sold it to Mirror Image Internet, another CDN company with complementary technologies and assets. And while Mirror Image is still around today, it, also, is not a success story. Mirror Image was never able to successfully monetize the union of their existing network infrastructure and Clearway’s advanced CDN technology, and so the company has never seen the growth that we hoped. (And thus I learned the meaning of the term “reverse stock split.”)
Other people have gone on to build bigger CDNs — most notably Akamai, who has become the dominant player in the CDN market, and they’re doing fine financially.
My original CDN patent (U.S. #5,991,809) was filed on July 25, 1996. In the U.S. the term of a patent is twenty years from the first priority date. That means my first CDN patent will expire in two weeks, on July 26, 2016. These twenty years have been a heck of a ride, and looking back, I’m proud of what I invented, and happy to see what it’s become.
-Mark Kriegsman, July 12, 2016.
Here’s the full text of what Web Hosting Magazine had to say about the invention of the CDN:
from Web Hosting Magazine, January 2001, page 77.
For Inventing CDN
Akamai may think of itself as the grandfather of content-delivery network services, but let’s not forget the man who invented the idea: Clearway Technologies founder Mark Kriegsman.
Akamai’s business plan was entered into MIT’s annual $50,000 Entrepreneurship Competition in 1998, by which time Kriegsman had already received Patent #5,991,809 for his “web serving system that coordinates multiple servers to optimize file transfers.” The U.S. Patent Office abstract somewhat cryptically describes Kriegsman’s intervention as a “networked system consisting of one primary and at least one secondary server, both capable of storing static and dynamic content. In addition the primary server houses at least one look-up table, with which the system can use various criteria to search for specific data files and allocate transmission of each file between the primary and secondary servers based on these criteria.” (What can we say? It was 1997.)
So Akamai and Digital Island can sue each other all they want about patent infringements, but Mark– we know who really came first. Wink, wink ; )
Posted: March 27, 2016 Filed under: DIY, Explorations, That Totally Worked | Tags: code, codes, CTF, cypher, cyphers, Easter, easter egg hunt, easter eggs, emoji, puzzle, puzzle hunt, puzzles, QR code, QR codes, rules
We’ve always loved Easter egg hunts, but with the girls getting smarter, faster, and more wily every year, we’ve had to make the hunt more… challenging. Our previous Easter egg hunt had infuriatingly complex rules as to which girl got which color of egg. But with the girls in middle school now — actual teenagers — I knew that I was going to have to step up my game if I wanted the hunt to last more than just a few minutes. Inspired by some of my puzzle-crafting Veracode coworkers, I put together our 2016 Easter Egg Hunt. Here’s how it went.
Step 1. Read the rules.
Once again, Eleanor and Abby were each given a sheet of paper indicating which colors of eggs they should each pick up. Here are the ‘rules’ they were given for this year’s egg hunt:
After a few false starts, the girls cracked the emoji substitution cypher. Since some symbols like🌀 and 👻 appeared only once on the page, it took some thinking to decode the whole set of color rules, but working together they did it.
Step 2. Find the eggs.
List of colors in hand, they ran outside to start finding the eggs hidden around the back yard. Each girl found all of their eggs within about ten minutes; finding the eggs themselves isn’t too terribly difficult — which is why we got into all these rules and colors and puzzles in the first place.
Step 3. Open the eggs… and wait, what’s this?
Once back inside, the girls opened the plastic Easter eggs… but wait! Where’s the loot?!? Instead of treats or trinkets, each egg held one small, oddly-shaped piece of paper with black and white squares on it: a QR code, cut into puzzle pieces.
Working quickly, the girls each assembled the pieces of their respective QR code puzzles. One went together easily, the other took some collaboration and a couple of different attempts before it all came together.
Step 4. Follow the clues.
Each girl’s QR code was different, and scanning the re-assembled QR codes led to two different URLs: two different tweets, by two different people (neither was me). Each tweet had a picture and a big clue about a different location around our house.
Step 5. Victory!
Eleanor dug down into our pile of birdhouses (why we have a pile of birdhouses is a long story for another day), and Abby popped open the lid of the grill. Each girl found a set of colored ‘crystal’ eggs — filled with sweet, sweet victory loot!
In just under 45 minutes, the girls had cracked a cypher, found the hidden Easter eggs, reassembled the QR code puzzles, and followed the twitter URL picture clues to find their well-deserved treasure. The chocolate was sweet, but from the looks on their faces, I think the taste of victory was even sweeter.
Now about next year…
Posted: March 25, 2016 Filed under: Art, DIY, Explorations, Getting A Clue, Pearls of Folksy Wisdom, Reflections, That Totally Worked | Tags: art, blinky, fastled, journey, learning, LEDs, light
Five years ago today I got my very first piece of LED art gear to light up for the very first time.
It was a Color Kinetics panel that you sent data to over ethernet, not an addressable LED strip & embedded microcontroller coding situation at all. The panel itself previously belonged to an LED art pioneer, “Frostbyte”, who had taken it with him on his desert adventures before his untimely and accidental demise. His old electronic gear was auctioned for charity, and without really knowing what I was getting in to, I bought this massive (28 pound!) metal box with 144 RGB LEDs in it, and the network controller to match.
I could find no open source software to drive it, and owning the commercial sequencing/design package was out of my reach. For three years, the panel sat in my workroom idle and dark. But at some point, I found that the vendor had a simple free “test program” available, and I decided to see what I could do. Since the color data was sent from the test program to the panel over ethernet, I was able to capture the network packets, reverse engineer them, write my own code to talk directly to the LED panel, and TA-DA! First light!
But even with that one LED panel up and running, more than a year passed before I started learning how to use addressible LED strips and Arduino microcontrollers. Another year after that, I had officially become ‘part of’ FastLED with Daniel Garcia.
And now? Now I’ve created LED art myself, taken it on my adventures– desert and elsewhere, sold it and gifted it. I’ve taught LED classes, and I’ve helped build an online community for thousands of FastLED users. I’m not sure what I expected when I first bought that LED panel, but I don’t think it was all this great stuff.
So if there’s a lesson here, it might be this: If something intrigues you, step toward it. You never know exactly where you’ll wind up, but the journey will be an adventure in the right direction.
Posted: November 27, 2015 Filed under: Coding, Creations, DIY, Explorations, Getting A Clue, How-to, Pearls of Folksy Wisdom, So that didn't work | Tags: arduino, blinky, DIY, fastled, fire, glow, glowy, LED, LEDs, light, power
When doing an LED electronics project, there seem to be three big “P”s that have to be tackled:
1. Pixels (which ones, how many, what configuration?),
2. Programming (what do I want, and how can I do that?), and
3. Power (how much, from where, and how do I distribute it?)
And people (by which I mean: perpetual newbies like me) tend to do them in that order: first wire up some pixels, then program them, then figure out how to power it all for real.
And of course, this often leads to a problem where you get stuck between steps 2 and 3, where you have your creation sort of up and running on the lab bench — but now there’s this little problem of how to power it, and you have to go back and rethink and rework other parts of the project to accommodate the power situation. So it’s worth planning for power from the start — which is easy to say, but hard to do!
What could possibly go wrong? (A list)
So what happens if you don’t plan for power? Well, here are some power problems that I have personally had. How many of these can you diagnose just from the description? (“Failure to plan” is a nice catch-all phrase here if you get stuck.)
- Hrm, now how do I get power all the way up there?
- Gee, that’s a long run of wire… but if I use fat wire, it’ll be expensive and heavy and cumbersome. Nah…
- I’ll use skinny wire, it’s much cheaper… Hey, why is it only reading 4v at the far end? And does anyone smell something burning?
- OK, I switched to thicker wire, and I’ll just re-use the power connectors from before. Holy cow now the connectors are getting hot!
- Fine, I’ll switch to these big thick nonpolarized connectors. Huh, that’s odd, it’s not working now. Does anyone smell something burning?
- For this other wearable project, I’ll use a simple battery holder and regular alkaline batteries… hey… why are the colors so ‘warm’.. no blue? And now no green, too…
- OK, switching power to one of those ’emergency phone chargers’ that takes AAs and puts out 5v from a USB socket. Hey! Why are the batteries dying so fast?
- OK, fine, I’ll switch to this lithium battery pack… hey, it said 5000mAh… so why did it stop powering my 5000ma project after only half an hour?
- How come my WS2811 project works fine from my computer, but then flickers like crazy when I power it from this cheap USB wall power adapter?
- For this big outdoor project, I’ll use this big, burly 12V lead-acid marine battery. Hey… how come it won’t hold a full charge after the first time I let the lights go all night?
- Everything was working fine yesterday, before last night’s rain!
- Everything was working fine yesterday in the cold and snow, so it should be working fine today now that it’s warming up, right?!
- I think I’m going to switch microcontrollers. The old one had a power regulator that could handle 12v input. Hey… do you smell something burning?
- Why is this power switch getting hot now? And why is it now totally stuck in the “on” position? And … do you smell something burning… again?
So: Plan For Power.
The lesson to learn here is that for basically any real project, calculate and plan the power first. Before you wire up any pixels. Before you write any code. Just stop for a minute and think about how much power you’re going to need, and where it has to come from, and where it has to go.
Use on-line calculators that will help you figure out how much power you’re going to need, and what gauge wire you’ll have to use given how long your cable runs are going to be. I also really like the “LEDstimator” app for iOS to help explore some “what-if” values for things like wire gauge. https://itunes.apple.com/us/app/ledstimator/id945794010?mt=8
And above all else… uh… wait… do you smell something burning?
Posted: February 16, 2015 Filed under: Art, Coding, Creations, DIY, Explorations, That Totally Worked, Uncategorized | Tags: APA102, Apple, Apple //e, Apple II, AppleII, arduino, art, blinky, CALL -151, DIY, DotStar, fastled, glow, glowy, LED, LEDs, light, LPD8806, retrocomputing, WS2801
These days, I hack LEDs. I’m the co-author (with Daniel Garcia) of the FastLED library for driving tons of high speed LED pixels and strips using microcontrollers like Arduino and Teensy.
But back in the day, I hacked a lot of Apple II. I published a couple of shoot-em-up games (with Geoffrey Engelstein), all written in lovingly hand-crafted 6502 assembly language.
Finally I decided it was time to link the present to the past: to connect a hundred high-speed RGB LEDs to an Apple II, somehow, and ‘port’ our FastLED library to 6502 assembly language.
Well, I did it, and it works. My new creation, “FastLED6502”, can drive a hundred 24-bit RGB pixels at more than 30 frames per second from an Apple //e :
Here are the details of “FastLED6502”:
- “FastLED6502” is a lightweight port of FastLED’s core functions to 6502 assembly language for the Apple ][, Apple ][+, Apple //e, and Apple //gs.
- Supports APA102 / Adafruit DotStar LED strips, as well as LPD8806 and WS2801 (though those two are not fully tested yet).
- The LED strip is connected to the Apple II using the 16-pin DIP game port on the computer’s motherboard. The 9-pin DB joystick/mouse port on the back of the //c, //c+, and //gs cannot be used, as it lacks the TTL digital output signals needed to drive the LED strip.
- 24-bit FastLED Rainbow colors are included, along with FillRainbow, Random8 and a number of other useful functions from FastLED’s main library.
- Everything had to be re-written from scratch in 6502 assembly language. Luckily(?), I still remember how to do that.
- The assembly code knows the binary serial protocols for the APA102 (Adafruit DotStar), LPD8806, and WS2801 LED driver chips. Depending on which one you select, FastLED6502 transmits the LED colors in the correct protocol over the game port TTL digital output lines.
Considering that the Apple II sports a 1MHz 6502 so slow that even a “NOP” takestwo cycles, overall performance is pretty good: more than 30 frames per second for a 100-pixel strip.
Speaking of speed, or lack thereof, “three-wire” clockless LED strips such as the WS2811 NeoPixel are not supported now, nor will they ever be. The CPU is would need to be at least 20X faster to support them, and it isn’t. For that you want an Arduino or Teensy, and FastLED proper: http://fastled.io/
I gave the code its public debut at Veracode Hackathon 7. (The theme was “Cozy Cabin” — I don’t usually wear plaid.)
FastLED6502 at Veracode Hackathon 7
How’s it work?
So how does this all work? Well, you connect the CLOCK and DATA_IN pins from the LED strip to a couple of pins on your Apple II’s DIP game connector port, add power, and you’re ready to go. The Apple II’s game connector not only has inputs for joysticks, paddles, buttons, and so on, but it also has a few digital outputs — and that’s what FastLED6502 uses to deliver signals to the LED strip. On all the 16-pin DIP Apple II game ports (except for the //gs!), there’s even one pin that delivers a super-fast digital pulse; pin 5 is the C040STROBE line, which can pulse twice as fast as the other digital outputs. If you choose that for your CLOCK pin, the FastLED6502 code automatically shifts into high gear, and you get faster performance. FastLED proper does this, too, in a much fancier way; it’s amusing that ‘little’ FastLED6502 does some of this, too.
The code is in the “extras” directory here (and eventually on FastLED’s main branch, but not yet)
This is Crazy
Overall, this bit of code is completely nuts, and we don’t expect anyone to use it. At all. Ever. Accordingly, we’re not going to really support it, either. At all. Ever. It was a labor of love and a creation of pure modern retrocomputing insanity. But here it is, in all it’s insane glory, “FastLED6502”.
And now, if you cut me, I’ll bleed 16,777,216 colors at thirty frames a second.
Posted: July 19, 2014 Filed under: Uncategorized
This thing that I am casually holding up in one hand is an 7′ x 3′ LED tapestry, plus diffuser, plus controller box, plus all mounting hardware, plus power supply and extension cord (rolled up inside for easy transport). It’d fit in the carrying bag for a folding camp chair.
Now, truth be told, I’m not crazy about the layout of LEDs on it (too gridular)…
…so there will be at least one more iteration of this “small” one before I build the “big one” for playa. But. It feels good to have come this far: the previous incarnation had to be wheeled around in a suitcase, and required complicated mounting due to it’s own weight.
Next iteration will focus on making the layout more ‘organic’ (the way I like it), and continuing to rethink how the diffuser is held at the right distance from the light.
Posted: May 25, 2014 Filed under: DIY, Explorations, How-to, That Totally Worked, Uncategorized | Tags: blinky, DIY, glow, glowy, invention, inventions, LED, LEDs, light, throwies, toys
At the last “HacKidThon”, we showed a passel of kids how to make LED “throwies”. Each one is a nothing more than an LED, a coin cell battery, and a magnet so the contraption can stick to metal surfaces, walls and buildings, and hang there glowing.
This week, someone asked me if we could modify the classic design somehow so that the LEDs could be attached to lanyards, instead of magnets. We wanted it to be as cheap and easy as the rest of the “throwie” recipe.
A little brainstorming with Eleanor, and we came up with this: plastic-coated paperclips!
The paperclips actually help hold the LED leads in place; we put tape around them as usual, though that’s not shown in the picture. The plastic coating keeps the paperclip from shorting out the positive and negative battery terminals.
The coated paperclips cost less than a penny apiece, and come in colors that match the LEDs. Victory!