Don't follow it. Do not use the X725.

As it turns out, it can (and will) at some point fry the SD card, leaving you with a bricked NAS. From the looks of it, chances of this are highest when it loses main power, which you'd think would be the main point of a battery-backed UPS system.

It is not a question of whether this will happen, but when. For me it was a few months. Luckily, this was only the SD card; the RAID array and the Pi itself were fine.

Anyway, since being able to have remote and timed startups and shutdowns, I have no converted the system to one with an official PoE-Hat, and a PoE switch that can be controlled remotely. It wakes up every night for backup tasks, and then nicely goes to sleep again.

So far, amazingly, without destroying the SD card :)

Recently, my old NAS system died on me, and I was in the market for something else. The only thing I use it for is backups, so I don't really need much in terms of fancy NAS features like seamless streaming and a web-interfaces.

One thing that had been annoying me for several years (on several ready-made NAS boxes) though was the software in general: either it was propietary, or it was Linux-based but modified for the NAS hardware. In both cases the manufacturer stopped updating it, and -if at all possible- updating the firmware and OS was a major hassle.

So I was wondering: why not get a bare RAID enclosure, and make a NAS from a Raspberry Pi?

My system would have the following hard requirements:

• RAID-1 support, with other RAID types as a bonus
• IPv6 support
• Accessible through ssh
• Ability to automatically go to sleep or shut down when not in use (both because of power saving and because RAID enclosures are noisy)

Points 1, 2 andd 3 are easy: Raspbian (and many other operating systems) have decent software RAID support, and of course fully support IPv6.

Point 4 however, was an issue: Not only does the Raspberry Pi not have a real way of shutting down, it also doesn't support wake-on-lan, which would be the easiest way to power it up again.

But there's nothing some additional hardware can't fix.

One way to overcome that would be to power it through a smart power hub, and simply enable/disable power as needed. But there would be a drawback: simply cutting power is dangerous when doing file-system intensive things, such as backups. I wouldn't want to shut it down halfway through a write operation.

But I found something else: The Suptronics X725 expansion board. This provides 3 things:

• Option to fully shut down the raspberry pi
• Wake-on-Lan
• UPS functionality with a few batteries

That third one is a bonus that makes this a better solution to the smart power outlet option: not only can we have controlled shutdowns, we can also have them when the power is out! Although, the most useful thing for this would be to prevent data write errors in case of a power loss, which in the current setup wouldn't actually work, since the RAID enclosure has its own power supply (without UPS, atm).

The documentation on the X725 is a bit on the sparse side though; it has several bold-lettered but not-so-clear warnings about how to blow up your hardware. So let's start with that.

With the board placed on the Pi, there's three ways to power the board and the Pi. USE ONLY ONE OF THEM.

• The USB-3 socket on the Pi itself
• The micro-USB socket on the board
• The power plug socket on the X725

On thing that makes this a bit scary it that there are 2 micro-usb ports on the board. The usb power socket is the one on the long side (it has the helpful text "2A CHG" next to it.

So what's the other micro-usb for? It's for the second network interface. Since the Pi can't do wake-on-lan, this board adds a network interface that does support it, but it works through usb.

With that, I have a system that is low-powered, well-supported by software, and able to wake up in the middle of the night to perform backups, then go to sleep again.

A LED-based clock, with light as hands.

It all started out when I found the awesome NeoPixel line of products from Adafruit, one of the more interesting ones being the 60-LED strip.

I picked one up (because you know, because), and the best thing to use it for for now was a clock. I had an ATTiny AVR lying around, and wanted to make something to replace my pretty boring standard clock.

Luckily I had a 3d printer to print a clock case at exactly the right size, so I 'only' had to make something to set the time, show it, and if possible, adjust colors etc.

Of course it wasn't as simple as that. For starters, the led strip didn't work out of the box. When supplied with some power, it would light up randomly for a fraction of a second, then go dark again. My first guess was that it didn't get enough power (a full 60 LED with controllers for each led can take a bit of power that may not be supplied fully by a small chip such as an ATTiny), but as it turns out, it simply came with wires soldered on the wrong side of the strip.

Luckily it's not that hard to resolder with the right connections, so once I had discovered that, lighting up the right LEDs was quite simple. Except for one, the last one on the strip. But 59 out of 60 is good enough for now.

It turned out to be more of a challenge to actually show the time with only one AVR that doesn't have a very accurate internal oscillator, and worse, one that can easily run out of program stack space and start behaving eratically.

After some measurements, tweaking, and rewriting, it still doesn't serve as a clock very well; it runs fine for about 24 hours, but then it goes haywire and needs a reset.

But it does look mighty fine. It can show the time in different colors, and the second hand is completely optional.

Plans for v2 are in the works. Starting with an RTC, and I'm thinking about adding a light sensor to automatically adjust its brightness.

But first I need to figure out where to hide the electronics then. I guess I really do need to figure out how to make custom form PCBs at some point.

TBH, the app serves pretty wel to configure scenarios, but I am not a really big fan of its interface.

I want buttons! Actual, physical buttons.

I also wanted to do something with RF anyway to see how it works.

Combine those to, and you get a remote for your Hues!

The receiving end it currently still just a breadboard and an Arduino, plugged into a computer running a python control script, but version 1 of the remote is finished.

As you can maybe see, it has 5 buttons, for 5 scenarios (one being 'off'), and one slider to set the brightness.

Here's the 'normal' scenario, and dimmed:

And for those emergencies, all lights set to red:

I may post a larger build report later, with more details (and perhaps some code), but for now I'll leave you with some keywords; ATTiny84, Cosa libraries, lots of wires (I really need to figure out how to make custom pcbs), and the case was printed on an Ultimaker.

On to v2 ;)

Way, way before I even had a printer I saw this Instructable. And immediately fell in love with it. It had never left my mind as a want-to-build-at-some point thing, and some time ago I finally got around to doing it.

But of course mine is completely different ;)

For starters, I did not want 'just' a speaker, I wanted one that had an integrated amplifier, much like those computer speakers you see everywhere. I wanted it to have a standard jackplug so it could play from most devices, and I wanted it to have physical power and volume buttons.

After doing some (well, hours of) online browsing for parts, I settled on a parts list, with which I shall not bore you, and got to designing the shell parts. As my parts would have different dimensions and properties than the ones used in the Instructable, I had to design everything myself. Which of course is 90% of the fun. Even with the countless failed attempts.

(Okay I lie, only some initial designs were made at this point, somewhere along the line I changed them completely but I don't have screenshots of the earlier attempts. Also the button came after everything was done and built. But hey, what's a little temporal randomization among friends.)

The parts arrived and it was time to do some serious soldering, first the speaker parts.

And once that was done, I could test the amplifier and all components.

(this actually has music coming out of it but that's a bit hard to capture in an image)

Satisfied that it was working, I could assemble the main dodecahedron part:

And then it was time to make the big print, solder everything else together and shout and curse it all into one big shiny package:

It is awesome, if I say so myself, even though I did make a number of mistakes:

• I 'forgot' to ground it (so depending on what is connected, it can have background static)
• I only included simple speaker parts and forgot to add ones that are suitable for low sound waves, so it's not really suitable for loud music with a lot of bass (but yes, it can be VERY loud).
• I did not include a shiny "i'm on" led.
• The dial has no numbers, so it does not go to 11.

But hey damnit, I have built my own dodecaspeaker!

My latest weekend project was to find a use for an Arduino that (due to some recent electromechanical fail on my part) could only be powered over USB.

After a few false starts, and with a lot of ideas left to implement, the first prototype is ready:

Das BlinkenSphere

It's a little sphere-like object that now sits quietly on my desk and emits a soothing color-of-choice.

By default, it's blue, because, you know, everything must be blue these days.

But of course, just having some colored light isn't any fun, or any use, so it's controlled by my computer; It has a direct client to set it to any (rgb) color, but the most direct use is the 'bs_run' command; any command prepended with 'bs_run' will make it orange for the duration of the command, and either red or green when the command finishes (respectively when it succeeds or fails).

So now I can let those long compilations or test runs do their thing, and no longer have to regularly check if they are done; the light will inform me.

Cast your light upon us, for the code is dark and full of errors

I also built in support for light sequences and transitions, but still need to write client control code for that (and find any use for it).

Now I need to find something to compile.

So I was looking around for replacement plates (preferably ones with octagons or maybe even smarter restriction holes), but couldn't really find any. And then I realized I have an f'in 3d-printer.

So I took out one of the existing plates, measured it, and fired up openscad to create new ones.

If you want to build it or see more pictures, you can get it at thingiverse

I'm starting to worry, I may run out of things to tweak on my cabinet soonish. Then what will I do with it.

So the final cabinet looks a little something like this:

Every nontrivial endeavour starts out with a little bit of research, and luckily the idea wasn't exactly original; there are a lot of tips and howtos, as well as some very strong opinions on How It Must Be Done to be found online.

Now one of the tips given most often is not to start from scratch, but to get an existing cabinet an repurpose it to your needs. It is less work, and much cheaper than going at it yourself.

But hey. Where's the fun in that?

Despite not having any significant woodworking skills (and, now that I'm done, to be honest, apart from some common sense needed to keep your fingers attached, you don't really need to be that advanced at it for a project like this), I wanted to build my own; partly because it is fun (or at least, that was what I hoped, and I was right), and partly because strangely enough, I don't really like most cabinet designs. IMO they are often too big and too flashy, especially if they are intended to be placed in a home instead of an actual arcade.

So after some basic research (there are lots of good tips on ArcadeCab, and a couple of initial designs, I went out to the local hardware store, got a bit of wood and some tools I did not have already. And I was off!

I shall not bore you with a step-by-step guide, there are enough of those on the Internet already, but here are a few pictures:

The whole process took a couple of saturdays (sorry for the noise, neighbours!), and a lot of obsessing over How To Do It, but I'm quite happy with the results:

Some observations and lessons learned:

• Building Stuff Is Fun.
• I'd do lots of things completely different if I were to do it again.
• Routers (of the woodworking, not the packet switching kind) are awesome!
• Covering a room with plastic to paint big pieces of wood feels pretty awkward if you have just watched two seasons of Dexter.
• The people at arcadewinkel.nl are great.

Again, I am pretty happy with how it turned out!

Now I only need to find a place to put it.

Personal Information

• Name: Jelte Jansen
• Date of Birth: February 7th, 1979
• Sex: Male
• Nationality: Dutch

Profiles

• LinkedIn: Jelte Jansen
• Twitter: @twitjeb
• GitHub: tjeb
• Website: tjeb.nl

Experience

• Programming languages

  • C, C++, Go, Python, Perl, Ruby, Java, Javascript, Lua

• Hands-on experience in protocol implementation

  • DNS, DNSSEC, TCP/IP, HTTP(s), AS2, AS4, PEPPOL, SMTP, S/MIME, PKCS#11

• Operating Systems developed for

  • Linux, BSD, Solaris, Windows, OS X

Employment History

• 2018-present: Ionite

  • Description: Consultancy, technology development, and services regarding electronic invoicing
  • Function: Freelance
  • Tasks: Consultancy, protocol development, services development
  • Specifics:
    • Advice and technical support for Simplerinvoicing, regarding AS2, PEPPOL, EN-16931, NLCIUS, SMP, SML
    • Advice and technical support for the NPa, regarding AS4, PEPPOL, EN-16931, NLCIUS, SMP, SML
    • Developed the NLCIUS Schematron validation files
    • Developed and maintains the NPa Peppol Test Tool
    • Developed and maintains the NPa Senders Directory

• 2013-present: Stichting Internet Domeinregistratie Nederland

  • Description: Foundation that administrates the .nl country-code top-level domain
  • Function: Research Engineer
  • Tasks: Technical Advisor, Internet protocol research and development
  • Specifics:
    • Technical project lead of SPIN
    • Technical project lead of SIDN Valibox
    • Involved in protocol design and standardization (IETF, RIPE)
    • Technical Lead SimplerInvoicing (SI-UBL and PEPPOL transport) (2017-2018)
    • Prototype Development for new protocols and services, this ranges from brand new services, such as the Domain name Surveillance system (www.sidn.nl/a/internet-security), to extensions of the PEPPOL Transport network (www.peppol.eu)
    • Member of the Privacy Board at SIDN, as a technical expert
    • Editor for Privacy & Informatie (www.uitgeverijparis.nl) (2016-2018)
    • Program Committee Member for RIPE Meetings (meetings.ripe.net) (2015-2017, 2018-2021)
    • Member of the Board of Advisors for SIDN Fund (https://www.sidnfonds.nl/excerpt/)

• 2009-2013: Internet Systems Consortium www.isc.org

  • Description: Non-profit public benefit organization that produces and distributes quality Open Source software, and provides professional services based on that software.
  • Function: Software Engineer
  • Tasks: Software design, Software development, Protocol engineering, Scrum Master, member of Best Practices board
  • Specifics:
    • Design and development of the http://www.isc.org/bind10 software.
    • Involved in standards work at the Internet Engineering Task Force http://www.ietf.org
    • Scrum master. Since ISC is a very distributed company, with small teams consisting of people working all over the world, this involved applying the Scrum methodology as befits our team, which posed a unique set of challenges.
    • Represented my engineering team at a best practices board, where common practices from different teams were combined and formed into a set of company-wide best practices for software engineering.

• 2004-2009: NLnet Labs NLnetLabs.nl

  • Description: Foundation to develop, implement, evaluate, and promote new protocols and applications for the Internet.
  • Function: Developer
  • Tasks: Research, development, protocol engineering, application testing, systems maintenance
  • Specifics:
    • One of the two original developers of the ldns DNS library, a C library to simplify DNS programming. It supports RFCs like the DNSSEC documents (RFC4033-4035). Apart from being a general library, this contains several specific tools, amongst which:
      • Simple Resolver and debugging tool (drill)
      • DNSSEC signer (ldns-signzone)
      • DNSSEC validator (drill)
      • DNS traffic analyzer (ldns-dpa)
      • DNSSEC zone walker (ldns-walk)
    • With ldns, created an example and interoperability testing implementation for the DNSSEC extension NSEC3 (http://www.rfc-editor.org/rfc/rfc5155.txt)
    • Involved in the creation and validation of several RFCs, most notably RFC4033-4035, RFC4648 and RFC5155.
    • Developer and maintainer of a second iteration of NLnet Labs' and RIPE NCC's DISTEL Testlab, a test setup for performance and regression testing of DNS authoritative servers. Created a way to do basic classifications of differences between server implementations. Reimplemented the control and configuration tools of the testlab in Python.
    • Provided assistance with the design and code reviews of NSD 3, an authoritative name server.
    • Provided assistance with the design and code reviews of Unbound, a validating recursive name server
    • Involved in the first iteration of the OpenDNSSEC software suite. Mainly responsible for the initial signing engine, and transparent abstraction from HSM devices.

• 2000-2004: First8 B.V. www.first8.nl (part-time)

  • Description: ICT Company specialized in creating inter- and intra-net applications
  • Function: Software Engineer
  • Tasks: Design and development of Java-based Internet applications

• 1998-2000: InterNLnet B.V. www.internlnet.nl (part-time)

  • Description: Internet Provider
  • Function: Helpdesk for an Internet provider.
  • Tasks: Provide technical help to customers with their network and Internet connections

Other Functions

• 2019-present: RIPE Programme Committee
  • Description: Planning and presentation selection for RIPE meetings
  • Function: Member
• 2017-present: __SIDN Fonds Advisory Board
  • Description: Review project proposals and funding requests, general advice for SIDN Fonds
  • Function: Member
• 2016-2018: Editor for Privacy & Informatie (www.uitgeverijparis.nl)
  • Description: Review submitted articles on Privacy in the information sector, write news and opinion articles
  • Function: Editor

Publications

• Protecting Home Networks From Insecure IoT Devices
• Whois-data; domeinnamen, persoonsgegevens en de openbaarheid daarvan
• Resilience of the Domain Name System: a case study of the .nl domain
• SPIN: A user-centric Security Extension for In-home Networks
• Ervaringen met privacybeheer voor DNS-‘big data’-toepassingen
• Experiences with privacy management for DNS 'big data' applications (Translation of original article)
• A privacy framework for ‘ DNS big data ’ applications (translation of original paper)
• Een privacyraamwerk voor ‘DNS big data’-toepassingen
• RFC 5702
• DNSSEC Key maintenance
• An Introduction to the use of HSM
• Measuring the effects of DNSSEC deployment on query load

Education

• High school: Gymnasium Beekvliet
• University: University of Nijmegen (now known as Radboud University)
  • Master's degree in Computing Science
  • Graduated on Security and Development
  • Aia Master award for master thesis Slicing Midlets

Other

• Several personal projects can be found on http://tjeb.nl/Projects and http://www.tjeb.nl/blog
  • One notable personal project is Mailbox Alert (AMO link), an addon for Thunderbird with over 16.000 daily users.
• 1999 - 2001: Chair of Thalia, the student association for Computing Science at the University of Nijmegen
• 2000 - 2001: Treasurer of 'Stichting Beet', a student association encompassing the technology studies at the University of Nijmegen
• 2001 - 2002: Chair of 'Stichting Beet'