It now has a more streamlined design, with a reduction in height (almost 20%!), and, therefore, weight. The machining of it has also been simplified significantly, tightening tolerances. And KuroBox now proudly has a rough sandblast finish. Labels are laser-etched in high-contrast lettering, making it very easy to read.

Internally, an upgraded, more precise and reliable sensor has been fitted, along with altimeter, giving more precise geotagged data. A special varnish is applied that locks out any environmental effects, such as humidity and dust, further increasing its reliability. Connectors are anchored to protect against vibrations.

In effect, I’ve done everything I can to make KuroBox as rugged and reliable as possible.

KuroBox has taken so long to get pushed out because I had manufacturing reliability concerns. I had been testing out 4 different CNC manufacturer’s on 3 continents, but all of them failed to meet the requirements in quality and repeat manufacturing that I needed in order to be able to deliver a product that I could be proud of. But finally after much search I found a very good manufacturer, with excellent track record, quick turn-around. They even quote tolerances in ISO/DIN!

I now have a tightly controlled supply chain with enough capacity to deliver KuroBox units with a 2-week turnaround.

Up until now, you’ve only seen kuroBox in its 3D-printed white enclosure, but no more, behold my newest arrival:

It is truly a thing of beauty. It has been machined out of a solid billet of 6061-T6 Aluminium and then anodised. Its weight feels just right in the hand, 266gr, sturdy but not heavy. Anyway, here’s the rest of the shots:

Well, that’s not entirely true. Every tweak I make, I increment my internal version number, and I’m now up to 15 tweaks. They have been minor and major. But I now have a fully functionally board, no, not board. I have a fully functional SYSTEM!

My current set up is fully mobile, running off some batteries.

Timecode input is needed once per power-cycle, but not needed continuously. The internal time keeper is accurate to within 1/4 of a frame (at 30fps) over a 24 hour period – by design and tested in practice.

I have sourced high-quality cables, for power, timecode and IO. All the connectors are industry-standard LEMO (0B-size) and SMA for the GPS. The mounting hardware is 1″ aligned – but can be ordered in metric.

The current demo setup has a Horita LTC generator, a 7-30V DC power supply and an external display box. The display box can display 4 numerical digits of your choice, whether it’s Seconds+Frame coming off LTC, the Yaw, Roll or Pitch coming off the IMU or partial Longitude/Latitude off the GPS. This is just a proof-of-concept display box, and is infinitely customisable.

All the software that comes with kuroBox is open sourced, meaning that the end user is not stuck with what they have, but can extend it, modify it, and change its abilities to suit your particular needs.

Things are coming together nicely. I received the boards a couple of weeks ago. Everything is as expected, no major dramas, just a couple of minor fix-ups, like a minor modification of a footprint of the reset button. All components soldered, and the complete board is working as expected:

The cable coming off the the top is the debug/programming cable, it’s attached to my SWD interface at the back. The rest of the cables are on the back, nicely tucked away.

You can just see on the bottom of the board there’s a daughterboard attached, which is held in place with the 3D printed spacers, which turned out quite nice and tidy. Also, the light-pipe holder next to the LCD is 3D printed.

My current challenge is writing the software, which is also coming along very well, though, as always, there’s lots of polishing to do. It current logs the RTC along with the LTC input, perfectly aligned.

The enclosure is also proving a challenge. Getting it CNC machined is quite an initial investment, given that everything has to fit exactly, and I don’t know what tolerances I should be looking for. The design has been finalised, and I’m currently getting a good 3D print done to make sure everything fits correctly and the whole thing works as a unit.

I’ve created the feet, which are detachable. They are currently made for imperial mounts, spaced at 3×5″, and have 1/4″ holes, which should fit most camera cheeseplates without an issue. Metric mounts will also be simple enough to make – it’s just a different pitch.

If you are interested in the kuroBox, drop me an email at dmo@nanibox.com and we can work something out.

So, I promised lots of updates, but so far, I haven’t delivered! I’ve had some setbacks, as expected, but I’ve made incredible progress on so many fronts. Btw, if you’re not the geeky type, this post may not be for you, but just so you know: things are looking awesome!

But first, let me show you what my board currently looks like:

Current state of the kuroBox layout.

Yep, it looks like an absolute mess! But there are lots of very good reasons for this. I’ve abandoned a poor design choice I made early on. I was hoping to be able to use a SoC (System On a Chip) to offload writing to SD card. My idea was to buy a chip that would do the hard work of writing reliably to an SD card for me, so I wouldn’t have to learn about all that stuff, and could concentrate on the important things. It turns out that the datasheet for the SoC was … incomplete, and that it was actually quite crap. But it’s totally my fault, I didn’t do complete due diligence and I suffered a setback. That’s what all those red wires are for – I’m bypassing that SoC and going to the SD card directly. Good news is that I now have 4x more bandwidth to burn through, my board is cheaper to make (because of a lot less components), and I’ve learnt a lot!

Along the way, I’ve proven many of the independent systems, LTC, the graphics, RTC time keeping, RS232 interface, overcurrent protection, etc.

And this is what my current design looks like:

kuroBox_v11

It kinda looks messier than before, but there’s only one main chip in there (a mighty 32bit, 168MHz processor with FPU), and wiring it up is a lot better. There’s also much more space for expansion for future projects. It’s currently at the fab house.

On another front, I think I’ve finalised the design for the enclosure:

Exploded view of boards, enclosure and connectors.

It’s quite simple, just the lid with windows for the screen and buttons, and 4 LEMO connectors on the side, for power, LTC and 2 external serial ports. Once I get the PCB’s back from the fab house, I’ll do a 3d printed fitting and form test of the enclosure, and, once happy, I’ll send them off to get machined out of aluminium, and then black anodised. It’s going to look amazing!

I’ve fleshed out the design of my first product, which is to be called kuroBox.

It’s an extensible platform for me to build upon. At its root, is a data logger for film-related stuff. It has a system to write to SD card, TimeCode input, a TTL/RS232 serial port and an expansion header. Through this expansion header I can extend its functionality by creating daughterboards with specific functionality for a particular task. It can be an IMU, several serial ports for lens encoders, inclinometer, etc. Or all the above in one.

For the prototype, I’ve separated out the power supply front end from the rest so I can test it to destruction to establish performance parameters. I can power it from 8-30V, which is great for most situations on set.

I haven’t been able to destroy the thing though. I’m using a dummy load which a friend is selling (re:load – it’s amazing) – which is basically something that will use burn off electricity as heat – ideal for testing power supplies. I’ve powered it up 30V with no issues. I’ve also tried shorting it out, and the fuse kicks in nicely and recovers without a problem. Reverse polarity is no problem either – though if you are using the specified cables you will never run into this. And it doesn’t get hot either! So, in all, it’s a success.

Below is the main logger board. There’s a reason it’s a prototype, I made a mistake with the footprint of the SD card connector and it’s currently upside down on the board! New boards are on their way. You can see the left side of the board is not populated – that’s the power supply front end, currently being handled by the other prototype, off-board. Most things work, but there’s a few things to iron out, like all version 1 prototypes. Most things on the board respond exactly how I would expect them to, so I’m happy with them.

I’m currently working on software, using ChibiOS as my base – and it’s a great OS, very complete, easy to use, well documented and an incredible community.

I’ve been hard at work making a proof-of-concept demo of a IMU feeding rotation data into a 3d program. In order to proceed with my idea and plan, I first have to prove that it works, testing the IMU under various conditions of speed, vibration, magnetic interference and long-term stability.

I found that the easiest way to test all this is to have instant feedback when I change the different parameters.

So I built this little box that houses the IMU, the VirtualCom chip, a Webcam and a USB Hub to join them together. This is by no way indicative of what the final box will look like – there will be no webcam and the data will be recorded on board onto an SD card. On the photo above you can see the webcam, and the microphone that came with the webcam (I didn’t want to remove it, so I just made a hole for it), and 2 rubber feet to avoid scratching the lens. The blue light indicates power and the green that the webcam is on.

I made a program using OpenCV for webcam capture and OpenGL for drawing. I overlaid some static geometry over the webcam footage that responds to the input from the IMU and I captured the result (which was a very interesting experience itself). You can see from the following video just a sample of the output.

Now that some sort of proof is done, that gives me the confidence to move onto the next step: designing the custom hardware. I will continue to do further tests and improvements in the meantime.

Of all the crazy (but controlled) things I have done in my life, this is right up there!

When Fury Road finished, we were going to move to London, and find a job at one of the major studios, MFC, DD, etc. But I saw that I really liked the hands-on nature of what I was doing in Namibia, and the stuff I was creating had a real future.

So I decided to try and get my projects off the ground on my own, and for electronic work, there’s no better place than Japan! I am very fortunate to have an incredible wife who is Japanese, since this gives me residency rights in Japan.

So here I am, in Osaka, looking for a place to live, so I can set up my studio and get to work on these electronic gizmos for the film industry. Because there’s a whole bunch of ideas that I have that need implementing!

Over the next month I’ll be fitting out my studio with new soldering station, oscilloscope, IR reflow oven, 3d printer and (very importantly) fume extractor!

Now, at the end of the year, looking back, how did the Aronia turn out? What worked, what didn’t, what did I learn and what would I do next time?

What Did Work

The TS7500 worked quite well, very easy to program (it’s basically straight C/C++ for linux), enough example code to get you into trouble and back out of it and the tech support people are very friendly, fast and helpful.

In the past, I had tried running a RS232 through the XUARTS at very high speeds (921600 baud) for continuous streaming (not burst transfers) and it had ended up giving me grief. The TS7500 locks the SPI bus every second for something, and that was enough for me to lose packets of data. But now, I decided to go through the USB port, through an FTDI USB serial port chip (more on this in another post), and not a single lost packet in 6 months of operation. I you don’t even have to boot all the way into linux – the image on the sdcard loads USB drive drivers, checks for a script called “tsinit” on the USB drive (if present) and executes it. I put all my code in that tsinit script (loading USB serial / ftdi drivers, making folders, setting up UARTS) and walked away!

The serial-enabled LCD from Seeedstudios was dead easy to use, you just have to make sure to flush commands before issuing more, since the UART driver on linux is buffered, and if you try to do packet-wait-packet type transfers, it won’t work as expected.

The Aronia PCB itself was designed with enough flexibility to change the way it was put together quite easily. I was using Molex Picoblades for my main connectors, but had also put in through-holes just in case. In the end, I ended up replacing some Picoblade connectors for direct soldering – much faster and easier, and I didn’t not require that particular part to be removable.

What Did Not Work

Well… the TS7500 also gave me its fair share of grief. Well, it’s mainly that I was trying to use the TS7500 as a pure embedded, real-time platform, which its not, so it’s my fault really. I was reading data off 3 serial ports, at different baud rates, with varying amount of data coming through. In theory, I should be getting packets like this: A, A, A, B, B, C, A, A, A, B, C, A, A, A, B, B, C, … (imagine I send 3x A packets, then 2x B packets, 1x C packet, etc…), but in reality, since the linux USB drivers would be “helping me” by buffering, I would read 20x A packets, then 10x C, then 5x B… etc, so not really as interleaved at I had hoped. In the end, it didn’t matter as much, since the A packet is the “master” one, and the others don’t really change that much. In hindsight, I need a proper embedded system, with proper low-latency interrupts and where I have control at the end of each byte read.

We also blew up about 4 of these TS7500 boxes, kinda. We don’t actually know what’s going on with them. But they boot, get to the prompt screen, then reboot. Forever… We are abusing them quite a bit, so it’s quite a surprise that they are surviving this well though.

I had a couple of design flaws in the Aronia PCB. First and most important: I knew nothing about thermal design (operative word: knew, past tense). I now know a lot more! We were plugging these guys into 14v, I was then regulating to 5V with about 0.7A current usage. On a linear regulator – that’s a LOT of wattage coming off it. with only 2.5cm^2 of radiating copper thermal pad, in an airtight polycarbonate box. Yes, these linear regulators got so incredibly hot that they actually discoloured the PCB! I tried adding a 2x10cm aluminium plate, but that was also getting into the 90ºC+ range after 5 minutes. I ended up getting some SMPS from Recom, some 1A 34v-in, 5v-out ones and reworking them onto the board.

I also added, on the wires supplying the current, some diodes and fused to make sure that nothing blows up (except the fuse). All this should have been on the board, not added as an afterthought…

Another thing I would change with the PCB is to put the connectors at the very edge of the board instead of the middle. In its current form, I have to remove the TS7500 from on top so I can plug a connector in, which is very annoying when in the field. And of course, adding a console header to the board helps!

A massive let-down for me was my “brilliant” “UPS” “solution” that I had “envisioned”! Here’s my theory: 12V -> 5V regulator -> LiPo Rider Pro -> Aronia. The LiPo Rider Pro takes 5V in and outputs 5V. It also has a connector for a single-cell LiPo battery. When running off its input, it will charge the LiPo, when the input is disconnected, it will seamlessly switch to LiPo and boost it to 5V – exactly as what I want! The only problem is that the LiPo Rider does not care about the minimum voltage of the cell, so it will squeeze it for all the juice it has, even if it means over-discharging the cell. The cell has a built-in over-discharge protection circuit, where it stops giving anything if the voltage falls below 3.4V (or 3.3V, I forget). This, for the moment, sounds good. Except that the LiPo Rider will not supply anything on its output if a battery is not connected, even if it has a perfectly good 5V input. And this condition is exactly what happens when the battery is over-discharged, that it looks like no battery is there!

In the end, I just got rid of that whole thing and if power goes down, then power goes down. In practice, it didn’t really affect us much, but it did leaving me scratching my head for a few afternoons.