Archive | July 2015

It’s not you, it’s me

Actually, I lied. It’s you.

bgfx is no longer relevant to the project. Why? Well, I wasn’t doing all that much with it and really it’s not benefitting me that much. Easy window creation? It uses SDL for that. Easy rendering? Well, you still have to use OpenGL and for vector stuff you can use NanoVG. So why not use NanoVG directly?

And SDL won’t help hide away the X11 vs native Pi window creation anyway.

So that’s what I did. A little Screen class to hide the OpenGL ES stuff. Now, as I’m doing my main development on my Linux desktop, I need to create the native X11 window. For the Pi, you can use some Broadcom headers (that also allow you to use GPIO) to create this window without X11, so that’s something I can integrate at a later date.

It has to be said that I wasted quite a bit of time trying to figure out why my OpenGL ES window creation didn’t want to paint. It resulted in a blank X11 window with some garbage in it. This turned out to be because there was a slight problem with my build setup. Not all of the OpenGL ES libraries were being linked, whereas there were proper OpenGL libraries. This caused an incompatibility that means all calls were succeeding but not actually doing anything. Ugh.

This all brings me to another problem. Third party libraries in general. It takes time to learn them and so often they don’t do exactly what you need, so you spend time working around the library to make it do that.
This applies more to the niche libraries that I’ve been trying to use than the more mature ones I’ve used in the past though.

Up and Atom!


Something that’s been bugging me lately is robustness.


There are a few components that can fail catastrophically.


As this acquires all sensor data, so if it fails, we’re flying blind. In order to remedy this, some manner of redundant Arduino could be used. The Pi has at least 2 native serial ports, so that would be achievable.


If the Pi fails, we’re pretty dead. It drives the screen. One solution would be to have two running and try to combine the signals from both Pis to the board. HDMI isn’t the best protocol for it, being encrypted and stuff like that.

Display board

This is a cheap board, it’s likely to fail in some way. Failure would be very bad, it would kill any output. I’d wager this fails before the Pi or Arduino. Is dual board an option? It could be. The output is a simple ribbon.


The screen could fail too. In my lifetime of many monitors I’ve not seen one fail after successful running for a while. There’s nothing much that can be done about the failure. Having dual screens wouldn’t do much.


Connections can come loose. After speaking to a friend who’s also doing things with Arduinos, perhaps I should use automotive grade locking headers.

A likely source of trouble would be the vibrations. Designing the frame so that the electronics live suspended from some rubber mounts would possible extend the lifetime.

Subtle failure

This is a tricky category. What’s even worse than total failure? Getting a wrong result and not knowing about it.


The most likely problems here would be incorrect calibration, some kind of wiring harness problems. As we’re doing ADC, it’s possible that we get some outside interference. Not unhead of to have some random errors. This can be generally filtered out in the Pi.

If there is a more serious failure, like a non response, the Arduino can be soft reset by the Pi through GPIO. Perhaps cutting the Vin through GPIO would be an option too.


The Pi would be best served by general defensive programming and thorough error checking. As we were merely monitoring, a hard fail is an option. Providing we can restart quickly, running the executable in a loop could be acceptable. There isn’t a great deal of variance, so once we’re up an running there really shouldn’t be any reason for failure.

Display board

A reset would be possible here. There is a simple control board with buttons. Problem being is that we wouldn’t know when to do it.


If this fails, we can’t detect it, so that’ll be up to the driver.


Had better solder well..

Star Trek

Whenever something fails in any of the Star Trek series fails, there always seems to be an explosion. Yet I don’t think that other than fuel related problems, any space craft so far has had any problems with exploding consoles. Why would you even put something that could explode so close to the interface? Wouldn’t you keep that in a Faraday cage some distance then operate it with servos?
This especially bugs with be Star Trek: Enterprise. The NX01 is your first prototype. Before you send something so precious out, wouldn’t you sort something like that out. In fact, once you have discovered it, why wouldn’t you solve in within several hundred years?