BHPC vs Herts petanque trophy

This weekend the might Brighton & Hove Petanque Club are playing their annual challenge match against Herts. It's an occasion in the boules calendar that everyone looks forward to - because it's boules at the beach with beers.

This year, we thought it'd be nice to play for something other than just bragging rights. As the competition has been dubbed "the stags against the seagulls" I cobbled together this concoction:

The stag in rampant pose is from the Hertfordshire County shield. Instead of an opposing stag and shield in the middle, I thought we needed something a bit Brighton-y. And a boule. A quick hunt around on Google images and some manual tracing in Inkscape (pencil tool set to 40% smoothing) and the resulting outline looks quite nice.

Note to self: don't ever Google search images for "rampant stag" unless safe search is turned off....

I figured we could cut the design from some nice shiny acrylic (sourced from Brighton and Hove Plastics in Portslade no less) and mount it on a posh plinth as a trophy to play for at the weekend. For anyone who plays petanque in either Brighton or Hertfordshire, has a laser cutter and who wants to look like they're a member of the winning side in this illustrious competition, here are the design files to create your own:

Herts v BHPC trophy

 
EDIT:
The trophy has since been awarded. So we don't have a photo of it with our spangly Stags v Seagulls topper on it. However, here's a photo of the two teams - on a lovely sunny August afternoon.

The Arduino vs Arduino battle ranges on

Here's an interesting blog post from a "genuine Arduino reseller". Or, they were, until quite recently. http://blog.pimoroni.com/why-we-wont-be-selling-genuino-arduino-any-more/

The Arduino vs Arduino argument one of those things that created a massive fuss in the "maker community". But having never really been fans of Arduino (for a whole slew of reasons, not just because of the association with hipster-wannabes) it's an argument we've not really had much of an opinion on.

Except that we recently decided to try to open-source one of our ideas. It's something we've been against for a long time. There are too many people who believe open-source means "you do all the work and I'll just bitch from the sidelines until you change your product to be what I want it to be then hand it over to me for nothing". We get requests for all kinds of things from the number of blog posts on here.

We don't mind sharing ideas, schematics and code. But we release only as much as we want to. Sometimes we don't release anything. We have no commitment to "openness". Because, in the main, a lot of Open Source Fans tend to be quite militant.

It's why we've never tried or claimed to make anything open source. On this blog we just brain-dump whatever is being worked on; sometimes full code listings are included. Sometimes just an explanation of how something works and a few diagrams. Sometimes we'll reply to emails asking (politely) for help with something. Aggressive demands for source code/schematics/abuse for not publishing under an open-source licence are just ignored.

Arduino was originally designed as an open-source platform to enable people to get stuff done. It's not the best platform for coding, and it's certainly not the best hardware compared to other, similar, microcontrollers. But it did allow people to get stuff made quickly and relatively easily. And it became very popular. Partly because it was open-source. So why is there even a lawsuit, when all the schematics, source files and code have been published as open-source? They're all out there for anyone to make their own copy of the hardware.

Well, it seems that now, Arduino is not a platform, but has become a brand. And in doing so, the people behind Arduino seem to have forgotten the reason it exists. With so many capable clones available so cheaply, people pay a premium to support "original" Arduino because they believe in the whole architecture and want to give credit where it's due. It's not because one "arduino" board from the "official supplier" is better (or even different) from a cheap Chinese clone. But official arduino suppliers enjoy lots of loyalty from informed customers who are willing to pay more for their boards, to support the whole ecosystem.

But now, the people behind the original Arduino are actively discouraging sellers from selling Arduino-branded boards into different territories. They're not just making it difficult, but imposing commercial restrictions on who can sell their "brand" into which territories.  The summary of the blog post (by a company who want to sell offical Arduino) is quite telling:

It's a real shame that Arduino LLC seem to have lost any of the Maker-vibe it had.
They seem more pre-occupied in playing at pretending to be one of the big boys with lawyers working double-time and focussing on "brand identity" to the detriment of anything else.

What a crock.
Here are some tips:

• Don't make resellers stock twice as many SKUs for no reason. It hurts their ability to stock your product which is dumb.
• Everyone sells worldwide now. This agreement affects pretty much all of your resellers. They should be angry (I know we are).
• ...<snip>...
• No one else cares about this. Not resellers, customers, or existing users. Only you. It might be worth thinking about that.

The bottom line sums up the situation quite nicely.
No-one really cares what an Arduino board is called (Arduino, Genuino, Funduino....) in the user-world, it's a generic term for the platform. Much like we push a hoover around to clean up the carpets, not a vacuum cleaner. Arduino is a term used to easily describe the hardware/software/architecture. There's no point being precious about it. Hoover don't try suing people who say they're doing the "hoovering" while pushing a Henry or a Dyson around. The only people who seem to care about "brand Arduino" are Arduino LLC.

What really caught our attention about this particular post was the very essence of open-source hardware seems to be fizzling out in recent years. While the end-users are getting more militant about insisting on getting stuff for free for no input / developers honouring the "purest" open-source principles, the people who originally embraced openness as a way of furthering their products (through a community-based debugging and improvement re-iterative development process) suddenly started turning their backs on open-source, in return for stocks and shares and venture capital investment.

Bre Pettis and Makerbot are the ultimate example in this. The way Makerbot actively encouraged the community to get involved, make and show-off their improvements to a once-open system, only to take these ideas and then obscure them behind walls of lawyers and patent applications demonstrated that even the loudest advocate of openness didn't - once cold hard dollars were involved - actually believe in it.

But now, it seems, the guys behind Arduino have got tied up in this kind of nonsense too - what was originally a by-word for an open platform that anyone could learn to build stuff with has become a euphemism for infighting and stupid, commercial, restrictions on who can and can't buy the "official" Arduino hardware.

Arduino isn't a trademark.
Well, it might be.
But so is Hoover.
But we still push hoovers around to clean the carpets when we actually mean vacuum cleaners.
The truth is, no-one cares what it's called.
So why are the people behind Arduino going out of their way to annoy the very people who actively want to support them? Do they still live by "openness"? Or are they more concerned about protecting a "brand identity"? (and if so, who else other than themselves cares about a "brand"?)

Adafruit have managed to demonstrate that you can be commercially successful and still embrace openness. It just seems curious that the people behind Arduino are throwing away the goodwill that the community wants to show them (by buying their hardware at a premium cost) and imposing commercial restrictions on resellers.

And all the while, this just makes the idea of open-hardware all the more confusing. If leading lights behind the original "maker movement" no longer live by their founding principles, where does this leave the very idea of "open source" hardware?

Maybe we should just save ourselves a whole load of hassle and abandon our plans for releasing anything as "open source" now, before we get going. From what we've seen going on with (Makerbot and) Arduino, it might just make things much easier in the long run! After all, we've never really been committed to it anyway. And those who once were seem more concerned about protecting their commercial interests and trademarks nowadays too......

EDIT: http://arduinohistory.github.io/
Interesting post from Hernando Barragan.
He's the guy who invented Wiring.
And Arduino is built on Wiring.
But there's something wrong with Massimo's version of events; he claims a lot of credit and makes a lot of inferences about "open source" as if Arduino is improving or changing the terms of Wiring licencing. Turns out, it's nothing of the sort. In fact, Massimo Banzi doesn't come out of this very well at all: http://arduinohistory.github.io/

Placing copper strips on our board game panel

We're making a matrix of hall sensors in a 280mm x 280mm square. Getting PCBs made this size is really expensive (especially after the Brexit vote which made the GBP/$ rate pretty piss-poor, so buying anything from China has suddenly become quite expensive!).

But we don't need a complicated PCB - just copper strips running up and down and left-to-right that we can stick some hall sensors to will do just fine. So that's what we're doing, with copper tape.

After marking out the places for the hall sensors, we need to place the horizontal copper tracks for our hall sensors.


This video only ever had an intended audience of one. We made it to give to one person who hadn't seen any of the ongoing builds, to see if they could understand and follow it. It's poorly lit, the sound is terrible, the noise from slurping coffee is distracting, and hands and arms get in the way all over the place. 

Making an electronic board game playing surface

It's been a while without posts, but that doesn't mean nothing's been going on at Nerd Towers. In fact, quite a lot has. And in real-life work too (but that's all confidential, hush-hush, say-no-more). But one of the things we've been playing about with is CyberLink Power Director (Deluxe) to make some videos.

Now video isn't our preferred format. Written words and pictures are what the blog is all about, not videos. Some people make great video blogs - but there's a degree of dedication in editing, lighting, getting everything "just so" required that we simply can't commit to. Whether it's because we're working in a poorly lit loft, a messy, noisy hackspace, or a freezing cold shed in the winter, videos just don't work for us right now.

With all that said, however, we've been asked to put together an instructional video, demonstrating how to create our electronic board game playing surfaces. So here goes with the first rough cut.

This video only ever had an intended audience of one. We made it to give to one person who hadn't seen any of the ongoing builds, to see if they could understand and follow it. We gave them a kit of laser-cut bits, some components and wanted to see if they could make a board section, without any intervention, just by watching the video.

It's poorly lit, the sound is terrible, the noise from slurping coffee is distracting, and hands and arms get in the way all over the place. But that's partly the point of it - so when we come to make the "proper" version of the video, and have gone to the trouble of hiring a properly lit studio and all the right video equipment, we know what to avoid doing and where best to put things and so on. 

The quality of the video is terrible. But in the name of sharing what you do and all that, here goes....

Files and links to the templates, schematics, firmware and all that will be released as soon as we're happy that they're complete - at the minute, we're changing things as we go; making a tutorial video really does show us where things we thought we'd finished actually need much more improving upon!

EDIT:

On reviewing this, perhaps we should have created an introduction video, showing the final thing working, to demonstrate what it actually is we're creating! But there are more than just one or two posts throughout this blog that bang on incessantly about the electronic board game idea. So maybe not.

Unity fonts PC vs mobile

Unity is a great, cross-platform development environment. Ok, it uses crappy C# and Monodevelop (which, despite it's problems, knocks crappy Visual Studio into a cocked hat!). But it's pretty good.

The 3d engine is great, the built-in physics work well, and the asset store is a god-send for us non-artistic coders who are used to placing blocks, cubes and pyramids as place holders in our games and never really progressing from there.

But Unity is also a bit buggy.
Sometimes it just craps out and closes. Sometimes Monodevelop just throws up a runtime error and wipes out your latest code changes. But these things are few and far between (unless you're working with a particularly badly written asset-store script).

And we've got a particularly quirky bug in our latest game/app for our electronic board game. It's all the more frustrating because it only appears after compiling and deploying onto a mobile device. On the PC, and in the runtime/test environment, everything works as it should. But on our mobile device, something as simple as changing a textbox is causing no end of headaches.

(in the editor, click the boxes in the bottom left, and the character successfully changes and the character name and weapon text changes as it should)

[image]

(on the mobile device, each time the text is updated, the previous entry looks like it remains on screen, creating a white blobby mess instead of clear, easy-to-read text)

Also we're struggling to understand how lighting works - particularly baked lighting and optimising for mobile. The first time we baked the lights for this demo scene, the bitmaps for the textures were updated and had an amazing, realistic looking set of shadows on them. But every subsequent compile rendered the entire scene as black (as if no lights were present in the scene).

The only way we've managed to make our characters visible again is by using an unlit shader to render the scene.

Is this another bug? Or just a fundamental lack of understanding of Unity?
Or both?

Troubleshooting WTV020-SD-16P and arduino

Today was quite a trial, getting our .ad4 files playing consistently well on a WTV020-SD-16P module with an Arduino. We'd had this running for a few weeks, and all appeared to be well. But today, after we put some different .wav files onto the SD card, and tried running it from a usb-based device, things started to go awry.

It's not that the sound files wouldn't play - they did. But quite often they would "clip" during playing; so after a second or two of sound, the audio would stop, but the module would remain in a "busy" state, and refuse to play any more sound files. The problem was particularly noticeable if we interrupted one file that was already playing and tried to play a second file.

Unfortunately, there were a lot of changes between the module we had working (running off an Arduino Pro Micro at 3.7v with a lipo battery) and the one that gave us so much trouble today (an Arduino Pro Mini, off a changeable 3.3v/5v laptop usb supply).

• We were using a different SD card - although both were branded Sandisk, it's quite possible that one, neither or both actually were! The working sd card was 2Gb, the non-working one was 1Gb.
• We were using a different power supply - the working module was powered off a 3.7 lipo, the non-working one was problematic at both 5v and 3.3v
• We were using different sound files - though even when we copied the .ad4 files off the working sd card onto the non-working one, the problem remained.

Clipping has already been identified as a possible problem with these modules.
Because the module uses the data instruction 0xFFFF to stop the audio playing and values 0xFFF0-0xFFF7 to change the volume, any clipping in the audio data might accidentally fire the "stop" command

So we made sure that all our sound files had no clipping in them. But the problem remained.
We tried copying the working .ad4 files onto the non-working sd card - but the problem remained.
We tried powering the non-working device off a lipo battery - but the problem remained.

We tried playing each sound file in it's entirety, instead of interrupting the file and trying to play a different one, mid-way through. Success was more frequent. But every now and again the module would "lock up" and get stuck in the busy state.

It was starting to look like we had two identical-looking modules, potentially with different firmware versions handling how the audio data is read and played back off the SD card. And that's when Steve had a bit of a breakthrough - a full, complete, FAT-format of the card, then copy the files onto the disk in one go (instead of copying them one-at-a-time).

When we did this, the audio playback worked as expected.

The more we pondered why this was, the more we were reminded of when we created our own audio module a few years back. Parsing FAT tables was quite arduous. And most of the time, a file was written to disk using consecutive sectors. So when the file was written to a blank, virgin disk, it would be written onto sector one, then two, then three etc.

We spent quite a bit of time making our playback routines work with a FAT-based file system. It was tempting at the time to simply find the start of the file and assume that is was written on consecutive sectors - it would have saved a lot of messing about every 512 bytes! But while we went out on a limb to ensure that our playback routines would work with files anywhere on the disk, it appears that the WTV020-SD modules don't....

So if you've copied files onto your sd card and then deleted them (in doing so, the 8.3 file format name is simply prefixed with a ? character) then it's quite possible that any subsequent file might get written to sectors one, two, then nine,  forty-seven etc. The FAT table does the job of bringing all the file fragments together.

But if your playback routine assumes that the file continues on consecutive sectors, it's easy to see why playback would fail. And it would also explain why the WTV020 module doesn't like playing back files that have been copied onto a disk after other files have been deleted off or moved around on it.

So, in short, to get your sound modules to work consistently well, always format the SD card fully before copying your files to it. Not a "quick format" (we tried that, it didn't work, since quite format simply blanks down the FAT table but leaves the data still written on the sectors). But a full, slow, 3-4 minutes to blank a 1Gb disk type format.

Do that and everything should be golden!

Arduino Pro Mini - it's ok as it is

Sometimes, making custom PCBs can be quite fun. There still remains - even after all these years - that little tingle of a thrill when you boot up your custom circuit board and everything works.

It's like committing to your idea. Once etched in copper, there's no going back and changing it (although given the number of times we've forgotten to add a ground plane, it is easy to tack on a wire or two to correct a couple of mistakes!),

I still love making PCBs (at least, I do, when they work). But that's only for one-offs or small volume prototypes. The idea of having to make 100 identical circuit boards leaves me cold.

Which is probably what Tony was thinking when he asked why, for our latest board-game-controller-idea, we'd stuck a "hulking great big atmega" onto a board and simply extended all of the i/o lines to the edges.

But that's all we actually need - we're multiplexing an array of hall sensors, and sending the data out to a bus-connected serial port. That's all there is to the board! Size is important, so we made the board as small as we could. But not everyone is a whizz with hand-soldering surface mount parts, so we used the large, through hole components.

So he asked "why are you making your own boards? Why aren't you using an Arduino Pro Mini?"

And we couldn't think of a single good reason.
Although not everyone may be comfortable hand-soldering surface mount parts, there are more people comfortable with ebay than a soldering iron - so why not just buy the boards, ready-made?

It seemed like such a dumb question. Which made our current approach look even more stupid! So that's what we're doing - not only going open source, but using off-the-shelf parts. Steve would be so proud!