Return of the Christmas Tree Project (ch 5): More LEDs!

It's been two years since I started my Christmas tree project. Last year, I didn't work on the project at all, but this year, we're back in full force. And I bought more led lights to put in my tree. In fact, we'll be doing five times as many LEDs as before!

Because it had been so long and because I had moved since I worked on it last, the first thing was to get the project up and running again. And the first thing to work on was my Raspberry Pi. Unfortunately, the sd card in the Pi that I was using before had gotten corrupted.

I spent quite a bit of time looking for my card reader, but all it did was confirm that the sd card did not work at all. Luckily having found the card reader also made it very easy to get a new sd card ready. The next thing was to find the code. It wasn't on my desktop, so it had to be on my private git server. However, that server failed a while ago, so I had to track down the storage I used in that server. This took some effort, but I found it eventually. And then it turned out that the code wasn't on there either...

The code had apparently only been on the sd card, so I would have to write it again. The amount and complexity of the code was such that that was feasible enough, but it was still a bummer. I took a look at the code from the project that had been the inspiration for this one to look at what libraries had been used. Looking at that repository made me remember that I had shared my own code with the world as well. And that was where the code was! You see, I only kept my private projects on my private git server. My public projects were all on GitHub. And indeed, the lost code was right there on GitHub.

It seems that I did have some code that was only on the sd card. In particular, I seem to be missing the three dimensional effects that I wrote. One was a rainbow effect and that should be easy enough to recreate, especially because the one effect that I still have does have much of the general structure I'd want to use. The other effect was an effect that never really worked that well, and isn't really that much of a loss.

With the pi running again and the code being back in my possession, I could get to working on the thing again. I was unsure if I would be able to run all the LEDs from one power source, so that was the first thing to test. I connected all my new LEDs and set them to white light at 25% brightness.

Several interpretations of white...

To be fair, all lights turned on and all of them being white is the worst case. But, 25% brightness is roughly 75% below the worst case. And the results were pretty bad. However, this looked like the power adapter was handling it just fine. Instead, it looked like voltage drop to me, which is not related to the adapter but to the lights and the wires between them.

So, I rigged up a quick test and saw that indeed, things looked a lot better if I connected the power source to each string of lights separately, even if it was still the same single adapter. The light strings do have extra wires that help you do this, but the bare wires aren't too easy to use. So, I decided to take some of my Dupont cables, cut them in half and splice the halves onto those wires to make them much easier to use. Using these tools and this skill set was a lot of fun, which surprised me because I had forgotten how much I liked doing this.

A bit of solder

Some tape

And some more tape

I added a breadboard to map from one input coming from my micro-usb breakout boar to multiple wires going to the different strings. This actually made for a surprisingly good setup.

Now, that's what I'd call white

I also worked a bit on my code. I took some of my old one-dimensional code and cleaned it up. I also wrote a simple rainbow effect. It's not as good as an effect that includes a tree and coordinates of the LEDs, of course, but it's still quite nice. And I did use some of the lessons I remembered from making the rainbow effect for in the tree two years ago.

The next step will be to try to cram all these LEDs into my small tree. (I'm at half the number of LEDs Matt Parker used, but my tree is also a lot smaller.) And then I can start using the most essential and complex code I wrote last year to map all the LEDs. I'm happy I won't have to rewrite that code!

Christmas Tree Project Step 4: Improving the Mapping

Last time, I got the first 3D mapping of the LED coordinates. I wasn't entirely happy with the results, though, so it was time to improve them. So, I started by working on code that I could use to verify the results of the scan. The idea was to turn a few LEDs on at a time, so you can visually verify that those LEDs are in the right order on one of the axes. However, while the y axis is completely obvious, the x and z axes aren't visible in the real world, so that was the first thing I did: create a gradient from red to blue on one of the axes so you could identify the axis.

The x axis

From there, I turned the lights green one by one according to their order on that axis. My original idea was to turn just the light after it and the light before it on, or perhaps a few, but I ended up just turning everything on, with the ones that were before the green LED being red, and the ones after it blue. Then, you could press either space if the LED appeared to have the right coordinate when it came to that axis, or x if it didn't. The software would then remember the incorrect coordinates and write them to a file when done.

Verifying the green LED

A modified version of the mapper can now also be used to scan only the incorrect coordinates. In that case, it will read which LEDs need to be rescanned from the file. It then scans every such LED from all four directions, but only updates the coordinate components of the axes marked as incorrect. With those changes made, I got back to the physical tree and got working on my new coordinates.

I decided not to use my previous mapping results, but start over instead. I had marked the position and orientation of the tree and the camera stand hadn't moved, but the camera wasn't in it in the exact same way. The way the webcam was mounted on the stand was a bit improvised and the webcam was borrowed from my work setup, so it hadn't stayed in the stand and the result was that I didn't put it back in the exact same way.

Improvised does not mean bad!

So, I took a few pictures with the new setup to get the tree properly in frame again and then started scanning. I alternated between judging the coordinates and rescanning them several times until I ended up with something that I was happy with.

Deciding what LED was wrong and what wasn't always obvious. When two LEDs are in the incorrect order, this method just isn't great for determining if the first one or the second one was wrong. When there are more LEDs involved, it gets even more complicated. I did develop a bit of a feeling for it, I just chose for rescanning more than necessary in a number of cases and I restarted the verifying process without saving the results a number of times. I could probably improve things by allowing you to go back in the LED order as well, so I will probably do that if I end up mapping another tree.

I was also important to learn that the result just wasn't going to be perfect. Slight changes in perspective can have big results, and we're already combining several perspectives into one coordinate. Whenever two LEDs were a close call, it was best to just go with whatever result the scan had. The mapping wouldn't be perfect, but it was never going to be perfect and as long as it's close enough, it'll look good, especially considering that the viewer won't have a fixed perspective either.

Finally, there was one LED left that just didn't get a good scan for its Z coordinate. I checked the photos and saw that it was indeed on, but just wasn't visible from either of the two opposite sides. I decided to just set the coordinate manually, so I lit it up as well as some LEDs around it. I identified which were its closest neighbors and gave it a coordinate between them, which I manually put into the output file.

With the new mapping, the next thing to do was of course to run the test effect again. I think the actual changes were relatively small, but the whole effect looks a lot more smooth to me...

(Well, I promise it does in person, at least.)

As before, all the code I wrote for this project can be found on GitHub.

Is the this the end of this project, then? Not just yet. The basic setup is done now, but I do still need to run effects on the thing. I am planning to both write some of my own and run the ones submitted to project that serves as inspiration for this one...

Christmas Tree Project Step 3: Mapping

Spoilers of what I pulled off

With the hardware gathered and the lights working, the next step was to put the lights in the tree. I took a bag of zip ties that I think I bought with the intention of using the for cable management in my computer (I bought way too many, though). For the most part, this was pretty uneventful, but there were a few things that I would do different if I'd do this again. The first is that I would plan it more carefully and use more zip ties and attach in more places. The second is that I dislike the colored wires between the lights, so I think I would sleeve them in something green to make them stand out less.

The colored wires do stand out...

I also wanted wifi on my raspberry pi, so I wouldn't have to run a network cable to it. As I realized last time, the device itself doesn't have wifi hardware, so I went looking for wifi adapters. I found two. Both are old and were probably cheap, but they were worth a shot. The first adapter didn't get recognized by the Raspberry Pi, but the second one worked well and after some messing with the configuration, I was able to freely move the device anywhere I had power.

Getting wifi running

The next part was the real challenge: mapping the LEDs to three dimensional coordinates. I did actually send an email to Matt Parker to see if he could share the code he used for this, but unfortunately, he didn't have it in a usable form. Not wanting to wait, I started working on my own.

Getting the camera to take a picture was both easy and hard at the same time. Basically, copying some code from the internet and saving an image wasn't that hard. However, there were basically three libraries to choose from, and none of them was exactly what I wanted and I definitely didn't like that you have to install non-python dependencies for each of them. In the end, I went with pygame, which uses sdl2 under the hood.

My complete mapping setup

There were also several issues with the camera that I had to solve once I started using it more extensively. The first was that the first photo would often have different brightness at the top than at the bottom, with a clear dividing line about a fifth from the top. However, this didn't show up at first, as it starts happening when you run the program more than once. I solved this by taking an image from the camera on startup, discarding that and then working only with the images taken later on.

The next problem was something I started noticing when I was working on the mapping: the photos taken were often from well before I gave the command, sometimes by ten or more seconds. I got around this by re-initializing the camera every time I wanted to take a picture, as then the picture would always end up being current. To prevent the previous brightness issue, though, I had to discard an image each time I did this.

With the camera working, the next step was to start identifying the LEDs and their location. The idea was simple: turn on a LED, take a picture, identify the brightest pixel in the picture and repeat this for the next LED. I also added a step of drawing some lines on the picture, so I could see the result.

Pretty orange lines

The first result wasn't bad for some of the LEDs, but just going with the brightest pixel didn't quite work for others. So, I changed my code to take the average of several bright pixels. My first implementation was quite bad and allowed a gradual increase in brightness to shift the average towards the top of the image. But even after fixing that, the results weren't to my satisfaction at all. So, I decided to take a different approach. Instead of looking for the brightest pixels, I just look with pixels that are above a hardcoded brightness.

For the most part, that gave pretty good results. However, when a lot of light was being reflected, the reflection of the LED would sometimes throw off the calculation. The way I solved this was by lowering the brightness of the LEDs. Originally, I had assumed that full brightness was a good idea, but in the end about 20% brightness gave better results because there were far fewer reflections that were bright enough to be taken into account.

Next, it was time to do multiple scans and combine the results. Doing multiple scans was straight forward: just put the code in a function and all that function four times, with a bit in between where tell the user to rotate the tree. For combining, I gave each mapping result a score, based on the brightness and on how many pixels were involved. Then, I took the y coordinate from the highest score on any of the four scans, the x coordinate from the best among the front and back scans and the z coordinate from the best of among the left and right scans. And those results I printed to a file.

In order to check the results, I quickly threw together some code that read the file (this was basically a copy-paste job from Matt's code) and then changed the color of each LED in order of either the x, y or z portion of the coordinate. And I must say, I'm not at all displeased with the result. It's not perfect, but it's quite good, especially if you consider this was based on the first time I did a full scan of the tree.

There are still LEDs that pretty clearly have inaccurate coordinates. So, that's what I'll have to do for next time: build the tools to see what LEDs are wrong and correct those...

Oh, also: my code is now on GitHub.

Christmas Tree Project Step 2: The Lights

Last time, we left off with all supplies gathered. Now, it was time to wire things up and get the lights lit up in some pretty colors. First, though, I had to solder headers onto one of the breakout boards. Soldering isn't something I'm great at, but this seemed like a manageable task.

Headers

With that behind me, I could start wiring things up. My first try was to just connect the power wires to the lights. But the result was nothing. However, I didn't know if this was because I had made a mistake, or that they just wouldn't light up until there was a data signal telling them to do so. So, I took out a Raspberry Pi that wasn't doing anything at the moment. After spending way too much time on things that should have been simple (like trying to configure wifi on a device that doesn't have wifi), I managed to get things up and running.

Here, I used a little bit of a trick. In order to make it work. In order to make two power supplies work together nicely, you need to wire up the Grounds. However, the Dupont cables I was using didn't have an easy way to go from the breakout board to the lights and to the Pi. However, the Pi has multiple Ground pins, which are wired up internally, so I connected the Lights to one of them and breakout board to another, basically letting the power flow right through the Pi. Unfortunately, nothing happened yet again.

Nope

Still nope

Now, it was time to do some debugging. I wasn't even sure if I had gotten the right one of the two connectors, so I messed around with that for a bit, but to no avail. Then, I realized that I could just get rid of the power adapter and breakout board for a bit. As long as the power draw wasn't too high, powering the lights from the Pi's 5V rail shouldn't be a problem. And indeed, I got things to light up!

My one LED program works

This meant that the Pi, the code and the wiring were all good. The problem had to be in the adapter or the breakout board. I should probably have gotten out a multimeter and started measuring. I decided to try something else: powering the Pi from the breakout board. This could definitely potentially damage to Pi, I went with it anyway. And I did see that the Pi's power LED only powered up when I was touching the ground pin on the breakout board. Apparently, I had done poor job soldering and there wasn't a good contact there...

Green across the board!

After making sure the soldering job was done properly this time, I hooked things up again. And I got the lights to turn on this time. It seemed that the hardware part of it was done now. And because programming is what I feel comfortable doing, I was quickly writing several effects. These weren't actually getting me closer to my Christmas tree goals, but I liked doing it nonetheless.

The effect that I liked the most was one that picked a random color for the first LED, and another color for the last LED without changing the last LED just yet.  Then, it gradually moved through the lights in the order of the wire to turn them a color that was slightly closer to the color for the other end each time. Once done, it would pick a new color for the first LED, and do the same thing on the way back. I wanted to include a video of that happening, but the effect didn't show too well on video and there were also some interference patterns causing lines of darkness. So, instead, a picture of each LED in a different random color will have to do.

A poor substitute, I know...

Next time, I suppose I'll have to start involving the actual tree.

The Pinebook

In the past, I have written about Single-Board Computers a number of times. Today, I want to do something similar. This time, though, it's a product by a SBC-manufacturer that is still more or less an SBC, but at the same is a lot more than just that. I'm talking about the Pinebook.

So, this manufacturer joined the SBC market with a strong offering: the Pine A64. It was on Kickstarter and it promised to do 4 cores for less money than the Raspberry Pi. Once you started looking at it more closely, you'd find that you probably wanted at least some of the extras and probably wouldn't end up paying less, but the idea was still there.

There was something else that made the Pine A64 stand out. That was that this wasn't going to be just another Raspberry Pi-clone. Most of the other SBCs were either quite a bit more expensive than this thing, or tried to be as close to the Raspberry as possible. Without the word "Pi" in the name and a brand-new form-factor, the Pine A64 made it very clear that it wasn't going to be another clone, which was a rarity for devices that weren't in a different price range all together.

However, it was something else that drew me to the device. It was the HEVC (aka x265) playback support that was promised. This was several years ago and the Raspberry only got HEVC support earlier this year with the RPi 4, so it was something really nice to look forward to. Unfortunately, this turned out to rely on proprietary drivers which basically meant that it only worked on Android, which wasn't really the operating system I wanted to run. I ended up finding this out before the end of the campaign, but decided not to cancel my pledge after all. In the end, though, this is the reason that my Pine A64 has basically been idle ever since I first tried it out just to see if it worked.

But then came the Pinebook. This was basically a Pine A64 (though they made a different board, the main components were all the same) put into a laptop. The whole thing cost only $99 which is incredibly cheap for a laptop. I read about it on a forum I frequented and decided to just go for it. After shipping and taxes, I was down quite a bit more money, but in the end it was still a good deal.

My Pinebook has served me well ever since I got it. It's all about expectations, though. The device isn't really going to play back video well* and it's not going to be flashy or let you have a bazillion tabs open. However, it does extremely well as a digital typewriter, which is what I've mostly been using it as. I've also done some simple GIMP (photoshop but open source, basically) work on it and I've even run some old games in DOSBox.

More importantly, though, I've never been careful with this laptop, which was largely possible because of its price. I've put it in bags I wasn't entirely sure would be handled carefully, I've taken it with me to the strangest places and I've stuffed it in lockers where it barely fit. The result is that the screen is damaged in quite a few places. Of course, the other result is that I've always had a laptop with me when I needed - or even just wanted - it.

In a way, this post may feel a little outdated. That's because the next big thing is the Pinebook Pro, which is a new version of the device that costs twice as much and is meant to be much more usable as a daily driver. I have ordered it and it's supposed to arrive somewhere next month. I might use it to write a sequel to this post at some time. However, I don't think it will completely replace the Pinebook that I currently have, so this piece still feels somewhat relevant to me. And besides, I felt like writing about this device and ultimately, that's what this blog is all about.

*: I should probably check if this is still as bad in newer versions of the software.

SBCs: Orange package recevied, over

A couple of days ago I received a package. Or actually, I had to pick it up because it didn't fit in mail box and I wasn't home when they tried to deliver it. It was a new piece in my collection of SBC, the Orange Pi Zero:

As the name might betray, it's the competitor to the Raspberry Pi Zero and the CHIP from the Orange Pi line.

With a full-size network, a USB port and a one presoldered header, it actually gets more in line with the CHIP than the Raspberry Pi Zero.

It has wifi and that combined wifi in addition to its network port, so it's also not as poorly connected as the RPi Zero. On the other hand, it's the only in its class not to have any display output, while at $9 (or $7 for the model with less RAM) it is the most expensive of the three similar boards (unlike the CHIP, it still needs a SD card to be added to that cost).

Of course, that higher price does get you something: a processor that actually competes with the normal Raspberry Pi line rather than the Zero. And of course, little to no software support.

For size comparison, here's the new board together with an Orange Pi PC, a Raspberry Pi 2, a Raspberry Pi Zero and a CHIP. The OPi Zero actually has quite different dimension than any other the others. Perhaps the Orange Pi is actually starting to take its own direction instead of just copying others.

The same package also included a case for my Orange Pi PC. Now that it has a real function in my infrastructure, I felt it deserved that. If you look closely, you can actually see that the case is artially transparent:

In fact, that was not the only case in the package. There was also a case for the Orange Pi itself. I have a plan for it too, so this seemed only fitting. I want to use it for NAT (if it's going to work is another story all together, but we'll get to that when we get to it). This may in fact be the first time that I buy a non-Raspberry board with a specific use in mind!

Speaking of Raspberry boards, there's actually a board that has joined the family without me writing about it on this blog. High time for some photos, don't you think?

It's the official Raspberry Pi Touch Screen! It's inside a SmartiPi Touch case.

And it's being driven by a Raspberry Pi 3.

Alright, that's what I've got for you for now.

Taiga on my Orange Pi PC

Recently, one of my hobby projects made it to a very nice first prototype state. It doesn't do much yet, but it is in a state where I can show it to people and personally I think it shows a lot of potential that is in the ideas I had. However, working on the prototype was kept simple because it was so basic; there were only a couple of tasks to work on. In order to keep the further progress of the project structured, I decided I need some form of an issue tracker. I have used Taiga.io for such a project in the past and it worked well. Unfortunately, though, their hosted version only allows a single private project and I already had one.

Remember all the Single-Board Computers I wrote about a while back? The Pi 2 is still actively running Kodi, the newest Pi 3 is driving an official Pi touch screen and some of the CHIPs are part of the project I mentioned while their versatility means I have ideas for quite a few more of them. However, the Pine and the Orange Pi have been idle since my last post about them. However, for the Orange Pi, this has recently changed.

I took the Orange Pi and installed Taiga on it. It is quite nice to have my own "dev server" and I'm quite happy about the current situation. I won't describe the exact procedure I followed to get where I am now, as it was basically following their guide for installing it. However, I will post a list of notes. Some of them will relate to installing it on the Orange Pi (or on an SBC or on an ARM based device) whereas others will just be my personal gripes with the installation or the guide.

• The guide uses the user "taiga" instead of telling you where to use your own username. This makes it easy to miss a spot if you are using a different user.
• To make matters worse, they chose the name of their software, so not every instance of the word should in fact be replaced by your user.
• I would probably have been better off creating a user and naming it taiga, though. The procedure installs quite a lot in the home directory and now that's under some other user.
• The procedure calls for installing postgresql 9.5, but Debian only has 9.4 on stable. By simply replacing the 5 by a 4 it works, as the minimum requirement is version 9.4. (Alternatively, I could have used 9.5 from unstable.)
• The guide installs python3 and then just uses Python 3.5. On Debian, you will have installed Python 3.4. This earlier version does simply seem to work for me.
• Installation of lxml is known to be problematic on the Raspberry Pi, but can be achieved by increasing the amount of virtual memory. For me, it worked without such hacks, though I do not know if this is due to running Armbian, running a headless image or using an Orange instead of a Raspberry.
• Circus isn't available in Debian stable, so I had to add the testing repositories and get it from there.
• Pay attention to the output of "service circus status". This is the only way to tell if the backend is actually running.
• I skipped everything that was even remotely optional, so I might revisit some of that in the future. The optional parts are sometimes somewhat out of order, which makes it seem you have to pick them up again before the end, but this isn't really the case.
• I currently use a .local domain. I think that means I use mdns, but it works on Windows (which mdns shouldn't) so I'm not 100% sure how this is working. It definitely isn't working from android, though, which is a shame. 

It's a real pity there is no "normal" installation procedure like running a script or installing a package. Nevertheless, I do now have the whole things running and I am quite happy with having my own development server.

SBCs: All hands on deck!

The C.H.I.P.

Introducing: the C.H.I.P.

 Today I received the last of the Single-board computers I ordered. Despite ordering the devices spread over a year, they all ended up arriving within one week. The C.H.I.P. was the device that I was most excited about, so it's sort of appropriate that it arrived last. This way, it couldn't steal the thunder of any of the other packages.

There are many reasons why I was so excited about this delivery. I had waited for this device the longest. I had spent the most money on it. The device has the most interesting features in my opinion. The PocketC.H.I.P. is just pure awesomeness. And there's probably more reasons.

Top view and bottom view

The C.H.I.P actually has some of its most important components moved to its bottom side, including its processor. This happened late in development, as they changed to a larger version of the same processor. To protect the processor, the computer now comes with a case, which only covers its bottom. This is definitely true for all the Kickstarter C.H.I.P.s, but I'm not sure if the "store-bought" C.H.I.P.s will also have this case.

Safe and well

Additionally, the Kickstarter version of the C.H.I.P. also comes with a Composite cable. This is a cable you can just buy at many stores, but it seems to be a bit undermarketed. It is also the same cable you could use for analog video on your Rapberry Pi 2 or 3.

In NTC Pink!

Unlike many of the other boards, this board is definitely not trying to be another Raspberry. Fro example, it uses female GPIO headers, as opposed to the male headers we've gotten so used to since the original Raspberry. This has the advantage that they could actually mark all the headers on the board.

You'll have no reason to use the wrong header

 For comparison's sake, let's just put it side to side with a Raspberry (it's a model 2B).

They're quite different - at least, to the trained eye

I actually own three C.H.I.P.s now. There was one in my pledge, another in the PocketC.H.I.P. that was in my pledge, and then finally one extra I added after the Kickstarted ended. I also pre-ordered a couple more, so there's several more of these machines on the way. I guess I may have gone a little overboard...

The power of threes!

Compared to the Pi Zero

The Chip lives in the same product space as the Pi Zero. It's the closest product in size and cost, and its specs are in fact rather similar. Let's put the two side by side.

Fighting for <$10 mastery

 As you can see, they are actually rather comparable in size. The Pi Zero is thinner, but it's also slightly longer. In the end, the C.H.I.P. is a bit bigger, though.

That's TWO computers!

Putting the Zero on top of the Chip, shows how close in size they are. The Zero actually fits so nicely between the GPIO headers of the Chip that it almost looks like there's only one board there. When talking about height, though, the story is a bit different.

No competition there...

The extras

I backed at the "All the things" level, so there's more things that were in the package. Let's have a look.

All the things!

There's the two C.H.I.P.s, the HDMI extension board, the VGA extension board, the Composite cables (which we already looked at) and the PocketC.H.I.P. Though it's a bit outside of the scope of the single-board computer - and a bit more expensive, I really like the PocketC.H.I.P. so let's have a closer look at it.]

Not truly pocket-size, is it?

On the front, we see a fully featured keyboard and the screen. The screen has a resolution of 480x272 and has a resistive touch layer (so no multitouch!). Neither is exactly optimal, but they definitely kept the costs down. There's also the possibility of using your GPIO headers, as they seem to be connected to the holes at the top of the device.

On the other side...

The backside clearly shows the C.H.I.P. It is held in place by its GPIO headers, so you can get it out with some carefully applied force. You can also see the battery, which gives the device its portability. The battery is charged through the CHIP, which has the required circuitry for this.

Jumpin' 'n' Dashin'

Getting the PocketC.H.I.P. up and running was extremely easy. I just held down the power (and home) button for a couple of seconds and that was it...

The whole family

Since this was the last of the boards I was expecting, let's all pose together for a photo.

Clearly, if a board's green, it must be a Raspberry

Alright, alright. The raspberry belongs in there as well...

You see?

And finally

Before I end this blogpost, there's one more thing I've got to do. You see, I've completely forgotten the shot with the pen for comparison. So here you go:

Same pen as before.

SBCs: The saga continues

Today, the Orange Pi arrived. Of all the boards, this one will probably be the one that is the most challenging to get to work. Its main problem is that the software support and documentation is simply non-existent.

The model that I got is called the Orange Pi PC. I ordered it from China for about 17 euros including shipping, with of course the drawback that it takes a couple of weeks before it arrives. It is clearly modeled closely after the Raspberry Pi. It's specs are very reminiscent of the Raspberry. It trades the DSI connector for a microphone and a power switch, while it has a different type of power supply and has a processor that is significantly faster (at least, on paper). However, the rest of the specs closely match and the two boards are even exactly the same size.

I'm expecting to receive my pledge rewards for the CHIP tomorrow, so then I should have all the boards (and all within the span of a week). The next thing is to get "making". I've already managed to run Debian on both the Pine and the Zero, but I haven't had the time to get much further than that. Let's see what we can do with all these boards.

SBCs: And so it begins

Over the past year or so, I have invested money in a number of different Single-Board Computers (that's Raspberry Pi-like things or credit-card size computers). I Kickstarted both the C.H.I.P. and the Pine A64. I also ordered an Orange Pi recently and ordered a Raspberry Pi Zero as soon as it became readily available. It seems the delivery dates all magically converged. While the CHIP and the Orange Pi are currently in transit, I received both the Pine and the Zero today.

Let's start with the Pine A64.

The Pine A64

I hadn't realized quite how big this board is. I mean, a Raspberry Pi (a normal one, not the zero) fits in it twice!

Raspberry for scale

It's a pretty powerful board that was pretty cheap as well (though once you added shipping it was comparable in price to a Raspberry). When I backed the project, I thought that I would perhaps be able to use its hardware supported HEVC decoding to my advantage, but I learned later that it will be a challenge at best to get a grapics driver with hardware support working under linux.

The case does look really good, if you ask me

And once again, it's big...
That pen easily fits on top of the case

But of course the better known product is the Raspberry Pi. I didn't quite realize how small this thing was! (Well, not until a coworker showed me his Zero this morning.)

The Raspberry Pi Zero
That's the same pen, by the way

I don't know what I'll do with the Zero, but I definitely had to have it. And besides, I have to add to the comparison I wrote late last year once my CHIP arrives.

Raspberry for scale. I just love being able to say that.

Alright, I guess I'm off to see if I still have two SD cards lying around. And, more importantly, whether I can still find my card reader.

The Raspberry Pi Zero and Pine A64 side by side