I decided to add a bunch of CCTV cameras to my 3d-printer. Apart from obvious reasons of remotely controlling the process (Just from your cellphone while you are running in the park in another city 😉 ), it also allows you to create awesome time-lapses of your prints.
All things come to an end at some point, so do uSD cards. And they tend to do that just about the time you normally LEAST expect them to.
Anyways, at my country house, away from the noise of the big city I had a cheap cellphone tethering internets over an OpenVPN connection. The operator does not offer proper external IP service, so I have to run an OpenVPN connection to have access to surveillance.
I have a bunch of cams here and there, mostly watching after these guys:
The cellphone itself runs a rooted android and a debian chroot with OpenVPN off an SD card. The SD card died this weekend and at some point I realised that I don’t have a recent backup. It was no big deal, just a debian rootfs + a bunch of config files for OpenVPN, but since I spent a while then and now perfecting configs and tuning OpenVPN for performance over the celluar network those weren’t backed up. Ooops.
Anyways, this note talks about data recovery from such an SD card and the common pitfalls.
One of the few things that was annoying about my new 3d-printer was the thing that it didn’t have a proper way to keep the wires away from XY carriages as well as any filament guides. So, I fixed it. Twice!
To clean up the mess around my desk I made this nifty little instrument holder for all those hex wrenches and screwdrivers that I often use to service my 3d-printer. Made for P902, but should fit any other model with similar extruded aluminum frame.
I recently got myself a new toy, so to speak. It’s a brand new Flying Bear P902 3d printer. For it’s price (~300$) it’s an awesome machine and is way better made than my old 2nd gen Solidoodle. So I’ll be posting a series of hacks that I had to do to work comfortably with it and this is the first post in series, starting with this one.
It’s been a while since I’ve posted anything in my blog so many of you might’ve thought that I’ve abandoned it. Well, on the contrary, I decided to put a little more life in it, so I will be posting way more tech tips here. And, since apparently there’s no other way, I’ve set up social integration for this blog. For now – only twitter and vkontakte. This is basically a test post to see if everything works as expected.
Do not expect me to answer any friend request/private message/retweet whatsoever. If you really want to contact me – email is still the best option. Why? Because it took 5 minutes since registration on vk for first spammers to start doing their dirty work: .
Okay, time to introduce the rare reader to a brand new section of this blog: “archery”. Something that you’d never expect, right? And this will be the very first post covering this topic. Everyone who starts archery as a hobby soon has a terrible itch to cut down the costs on it… somehow. Since there aren’t many archers out there archery stuff is quite pricy, especially if you want to to compete on at least amateur level.
A few months ago I needed to write a VPI extension for verilog HDL and (just as I would normally do) I needed a proper buildsystem for that stuff. Unfortunately in terms of build/debug/test tools the folks doing ASIC are living… Well, not in the stone age, but in their own small isolated world and keep reinventing the wheel over and over again. OpenSource iverilog simulator didn’t go far away from the proprietary counterparts that tend to ditch commonly used in linux environments best practices.
Okay, now let’s stop bitching about the way things are and decide how to deal with that kind of stuff. In this note I’ll try to describe how to make a CMakeLists.txt for compiling a VPI extension and unit-testing it with ctest.
It’s been a hell of a summer with loads of work at my dull dayjob so that I’ve almost forgotten about everything including this very blog. However once the hell cooled down a little bit I found myself with a few spare days and my usual itch to tinker for a little bit with something. It happened I also needed another linux single-board computer to do some dull geeky stuff. Instead of ordering one from aliexpress once again I dived into the junk and found this little dead piece of hardware:
For a handful of projects work and hobby alike I use Debian. However, when you deal with embedded systems (e.g. ARM SoC) you normally don’t have the installer CD or even the disk drive. You end up creating a filesystem, compiling the kernel. Well, pretty much the usual way it goes.
The process can be somehow lengthy if done by hand using debootstrap and multistrap and especially mind-blowing if you are a total newbie. (Alas, I’m already no n00b here. Getting older, heh)
The worst part of it is that you not only need to create a root filesystem for debian, but set it up in a more or less sane way, e.g. set the default password, ssh keys… The usual thing.
In the Big Enterprise ™ we can see tools like vagrant creating us a base box in the VM and chef or puppet actually setting the system up. While we can use, say chef or chef-solo on an armhf board (why not?) we still have to make sure we have some base image it will set things up on, right?