Archive | November, 2017

Embedding myself in devices

19 Nov

Embedding myself in devices

This blog's been a litte dead the last year as I've been head deep in two big projects in addition to teaching more than before at Westerdals ACT. I'm not dead and I'm having a blast!

I'm doing exactly what I want at the moment and I feel that I'm creating really good stuff.


For the two brothers Simonsen, I'm creating the electronics and software for their Røst coffee roasting machine. It's a beautiful machine that has already won a RedDot Award for the design and "Best New Product" in the technology category at World of Coffee in Budapest. The software and electronics is controlling fans, brushless motors, stepper motors, super high precision temperature sensors, gas burner, spark ignition, capacitive touch screen, encoder, sensors and has a host of safety features. Read more about the machine here or check the video below.


This project I've worked on for almost two years by now. Imagine you're at a festival and need a beer. There's always a beer-line and the guy in front of you will always wait until it's his turn at the bar to start planning. Wouldn't it be nice if the bar had glasses ready and they started tapping the second you hit the BUY button on your phone?

What we've managed with this project is to take the already great BottomsUp system (taps a beer in 4 seconds!) and added an ordering system via an App. The App talks to a controller box under the bar that can remote control the entire tapping system. From you click the Buy-button until you have (up to) 6 beers is just 5 seconds - including payment! This has been a blast to develop and it's now ready for the masses. You can see an older version of the system in action here and this is how the (injection moulded) box now looks after 3 iterations.

Westerdals ACT

Four years ago a friend told me to apply for a job teaching Embedded Systems at Westerdals Oslo School of Arts, Communication and Technology (or Westerdals ACT for short). At that time I felt a little under-qualified, but they really needed someone to do the course. I said yes and over the years I've found that I'm certainly just as qualified as many of the other teachers. I built the course so that it's one of the most complete Arduino courses there is. It's 12 weeks with 4 hour lectures each week that takes the students from complete noobs to someone that could make a simple prototype for a project. I try to cover all the basics whitout going too far into the details, while covering all the things I think will be useful for them. One of the last lessions we have a PiDay where we go through some of the same projects in Embedded Linux, so they get to try it from that side also.  I've now done the course 7 times and the students love it!

Last year the school asked me to build a second course that builds upon the Embedded one. The topic is Machine to Machine communications and briefly said - it takes the prototypes that the students learned to make in the Embedded course and teaches them how to connect them to the cloud. We go though lots of cloud related technologies, play around with radios, communications protocols and build complete M2M networks. I score very well when the students review their teachers each year and I really enjoy the interation with the students. I've always loved presenting and teaching, so I think I might do more of this in the years to come. 


Anyone knowing me will probably know that I don't just have my office at Oslo's biggest Hackerspace, I also help organize it. I'm no longer in the Board, but I maintain our contact with the landlord (Olav Thon) and make sure things "just work" in general. Bitraf is a Do-ocracy and it's amazing how well this works even if there's just a few people doing things. Bitraf has grown from a 20 ppl Hackerspace with coworking (130 sq/m) to a massive combined Hackerspace/Makerspace/Coworking space with 250+ members and several events each week (now with 950 sq/m space). Back when we started, we dreamed about getting a laser. About two years ago I purchased one and last week we just received our second laser cutter. We now have 2 lasers, 4 CNC's, 2 lathes, complete SMD workstation, huge workshop, a sewing room, a chemistry/bio room, seven 3D printers, all the hand tools you'll ever need, lots of workspace for projects…

It's just grown really well organically and only with members funding it. We have done this completely without government grants, so I'll do a writeup on how to run and fund such a space soon.



Basic Blink example for dsPIC30F4013

20 Nov

Basic Blink example for dsPIC30F4013

With an Arduino, I can teach someone to blink a LED in 15 minutes. It will always work. In the world of PIC microcontrollers, there's nothing "that just works". To help others trying to make a dsPIC30 family microcontroller do just the simplest thing, I'm posting this mini tutorial including what they expect you to know and what you actually need to know.

The Arduino community has always been a place where newcomers could feel welcome. Even the simplest questions are answered politely and nobody looks down on someone just learning the ropes. In general, it's a very welcoming platform. You just download the IDE, plug the Arduino in via USB and you're already moving. I've now tought microcontrollers to students for 4 years and they really love using Arduino as their first hardware tool. So what's different with the microcontrollers from Microchip you may ask? The answer is simple - everything!

What they expect you to know

For a freelance project I'm working on, I have a piece of hardware designed in the US. It's using a dsPIC30f4013 and it has been doing it's job for many years without major problems. Now I've been tasked with adding new features into it and it's been very interesting to see how the culture around the product is extremely different.

In the Arduino world you are expected to be a beginner, but in the PIC-world you are expected to be an expert - even if you're just starting. Let me illustrate this with an example from this thread where a guy starts off by saying he is an absolute beginner and that he just wants to blink a LED.

Here are some of the comments he receives:

Refer to your  micro datasheet. bye!

Do you have access to a logic probe or an oscilloscope to check if your crystal is oscillating?

And anyway I cannot see your CONFIG settings…

you need a pullup on MCLR, and a small bypass capacitor (say 100nF) mounted as close as possible to each pair of power pins

The first of these comments is just terrible? The datasheet for a MCU (like the dsPIC30F4013 that I am using) is no less than 221 pages. The worst is - that is just the parts that are specific for that single MCU. To get the full picture, you also need the datashee for the family of CPUs. For the dsPIC30F family that is no less then 772 pages! To top this off - to use anything remotely advanced, you'll also need to study the dsPIC Language Tools Library. These 400+ pages detail how to use core features like UART, SPI and I2C - all features that an Arduino user will explore within the first few days of use. With a PIC, you should read almost 1400 pages of dense and highly technical documentation BEFORE even blinking a LED?

I can't even imagine how long it would take to read close to 1400 pages? These manuals are not written for a beginner. I would say that datasheets in general are written by engineers that want to impress other engineers. Its not light reading, but requires focus so it's quite tiresome for most to read.

Regarding comment #2 - how on earth can you expect someone that says he is a beginner and cannot blink a LED to have a logic probe or an oscilloscope? Regarding #3 - what CONFIG? Now - I know that config is important when it comes to PIC, but I have yet to find a good tutorial that explains how that is done correctly. I know it's in the datasheet, but the text here really isn't meant for beginners.

Comment #4 is actually quite good, but I'd guess it's somewhat confusing to a beginner? The pullup is essential, but the capacitors are not required to get this working. You would be wise to have them in a PCB design, but they are really just complicating things for beginners trying to blink a LED.

What you REALLY need to know

To get a bare bones dsPIC30F4013 up and running blinking a breadboard, you will need the following:

  • DIP version of the dsPIC30F4013
  • 10K ohm resistor
  • LED
  • 220-510 ohm resistor (for the LED)
  • PICKIT 3 programmer (or similar)
  • breadboard
  • Jumper cables

Locate the datasheet for the dsPIC30F4013 and find the page that explains the PINOUT.

Pin number 1 is marked with a dot on the chip. The text next to the pin shows that this is the pin with the MCLR function. We'll need that later. Place the chip so that pins 1-20 align with the numbering on the breadboard. Connect the 10k resistor from pin 1 (MCLR on the datasheet) to the 5V rail that runs along your breadboard. Connect all the pins marked as Vdd to the 5V rail and all the pins marked as Vss to the minus/ground rail. If you use the power rails on both sides of the breadboard, make sure you connect the minus on one side side with the other and the same for the 5V rail.

Next, connect the shorter PIN on the LED to Vss (minus/ground) and the longer to one end of the 220 ohm resistor. The other end of the resistor should go into the hole connected to Pin 19 (marked as OC4/RD3).

That's all that is needed for the Microcontroller itself. Now we need to connect it to the programmer.

On the PICKIT 3 programmer, there's 6 pins and one is marked with a small arrow. This is Pin 1. Here's how you connect the various pins:

PICKIT 3 dsPIC30F4013
Pin 1 (MCLR) Pin 1 (MCLR)
Pin 2 (Vdd) Vdd (5V power rail)
Pin 3 (Vss) Vss (Ground rail)
Pin 4 (PGD) Pin 9 (PGD)
Pin 5 (PGC) Pin 8 (PGC)

Note that these pin numbers will only be correct for the dsPIC30F4013. Other variants will need to use different pins, but you can locate these by looking at the correct datasheet.

With that connected, it's on to the code.

The code and the config

There are several things that are difficult to know that is required. The main reason for this is the absolute lack of good resources when it comes to tutorials and examples. MicroChip has examples in both the docs and online, but few of these are suited for beginners. The online examples are not publicly available in search engines. They are listed in a cumbersome tool that tries to be smarter than Google that allows you to filter. It's not smarter than Google and Google will never find and index these example files since they are ZIP archived.

Anyway - there's a few things you need to know before starting:

  • What to download
  • How to setup
  • How to set the frequency
  • How to configure
  • What to include

Start by downloading the MPLAB X IDE. This is modern IDE that has the features you'll need, but it's impossible to make it work on anything other than Windows. It comes with most, but not all the features you'll need. If you need to use Legacy libraries, you'll need to do some digging to find these. The normal download is sufficient for the LED example, but there's one confusing thing you must resolve - what compiler should you download? You've got to hand it to the people that named the microcontrollers from Microchip - they really did their best to confuse people! In my case I have a dsPIC30. Should I use XC8, XC16 or XC32?

For obvious reasons you would think that what compiler to use is mentioned in those almost 1000 pages of datasheets, right? Well, it isn't. You need to KNOW that the dsPIC30 is a 16 bit Microcontroller and that for any 16 bit microcontroller from Microchip you should use XC16. It amazes me that nobody thought of distributing all 3 compilers with the IDE and then just automatically select the correct compiler. The IDE will know what compiler to use when it's time to compile the projects since you have to tell what microcontroller it's working with. That brings us to the next part - setting up a new project.

Setting up a new project is fairly simple using the MPLAB X IDE. Select File -> New Project -> Microchip Embedded -> Standalone Project. Select your chip family and device and click through the dialogues. This only does the project setup. It doesn't even set up a single source file, so you'll need to right click the Source Files folder in the Projects window and then choose New -> mainXC16.c. You can rename this to anything you want (like main.c). This newly created file is more or less empty, but it does include the xc.h file that in turn includes the basic files for your microcontroller.

Next you need to know what frequency that your dsPIC30F will be running at. In most examples, this is referred to as FCY and the value of this is confusing. It varies across different microcontrollers, so you can't just use one you found in an example somewhere online. You'll need to search the datasheet for the "Oscillator Operating Modes". This is a long and confusing list of basic clock speeds that your microcontroller can run at. It is however easy to find the one needed for this example. Since we have no external clock signal attached, we need to use the internal oscillator built into the microcontroller. According to the datasheet, this is 7.37Mhz and you can find this set in the example below as SYS_FREQ.

Another important thing is to set the FCY variable. On this specific microcontroller this should be SYS_FREQ/4, but figuring this out is difficult. Reading the datasheet you can see that FCY =1/TCY. So what is TCY then? It's the "Instruction Cycle Time" dummy, don't you know? Well how on earth could I? Digging further I find that TCY = 1/MIPS and that MIPS = (FOSC*PLL)/4. So now you need to know what FOSC and PLL is then? Figuring that part out is difficult if you're not using either an external clock or crystal (if you're experienced enough to know what that is), but lets just leave it at that?

Next up is the CONFIG mentioned in one of the comments. Few beginners include this since ... it just looks insanely complicated I guess? It isn't all that hard, but it does require some former experience to get this right. What looks scary is all those FWPSB and WDT's. Luckily there's a tool built into the MPLAB X IDE that can set this up for you Window > PIC Memory Views > Configuration bits. In this dialogue, you tell the tool what oscillator you are using (hey, didn't you already do that?), prescaling,  watchdog and lots of other things that beginners really should not have to know… I understand that it's there for the advanced users, but to become an advanced user you just need to get a stupid LED blinking first, right?

Behold - now you're ALMOST there! The last thing you need to know (without anyone telling you) is that to just wait a little on a PIC you can't just use the builtin "delay" function. Why? It's not builtin… Include the libpic30.h file that includes the second most required utilities for the dsPIC30F family and your projects should compile. Phew!

// Useful advice!

// FCY must be defined before the includes or things go wrong.
// For some odd reason, the config tool does not set this based
// on the MCU + Oscillator selected
#define SYS_FREQ        7370000L
#define FCY             SYS_FREQ/4

// Device Config; generate using Window > PIC Memory Views > Configuration bits

#pragma config FOSFPR = FRC             // Oscillator (Internal Fast RC (No change to Primary Osc Mode bits))
#pragma config FCKSMEN = CSW_FSCM_OFF   // Clock Switching and Monitor (Sw Disabled, Mon Disabled)

#pragma config FWPSB = WDTPSB_16        // WDT Prescaler B (1:16)
#pragma config FWPSA = WDTPSA_512       // WDT Prescaler A (1:512)
#pragma config WDT = WDT_ON             // Watchdog Timer (Enabled)

#pragma config FPWRT = PWRT_64          // POR Timer Value (64ms)
#pragma config BODENV = BORV20          // Brown Out Voltage (Reserved)
#pragma config BOREN = PBOR_ON          // PBOR Enable (Enabled)
#pragma config MCLRE = MCLR_EN          // Master Clear Enable (Enabled)

// FGS
#pragma config GWRP = GWRP_OFF          // General Code Segment Write Protect (Disabled)
#pragma config GCP = CODE_PROT_OFF      // General Segment Code Protection (Disabled)

#pragma config ICS = ICS_PGD            // Comm Channel Select (Use PGC/EMUC and PGD/EMUD)

// Device Config /end (paste config between these two)

#include <xc.h>
#include <libpic30.h>

int main(void) {
    _TRISD3 = 0;
        _LATD3 = 1;
        _LATD3 = 0;
    return 0;

Oh? you don't know what those TRISD and LATD's are? Let me repeat that with comments so you have a remote idea:

int main(void) {
    _TRISD3 = 0; // set D3 to output
        _LATD3 = 1;       // turn D3 on
        __delay_ms(1000); // wait a second
        _LATD3 = 0;       // turn D3 off
        __delay_ms(1000); // wait a second
    return 0;

Yup. _TRISD is what Arduino calls pinMode, you know the method you use to set the mode of a pin? And yes - setting _LATD3 to 1 is similar (but not too similar or explanatory) as the Arduino digitalWrite method. Obvious once you know it, right?

You must be kidding, right?

No I'm not. It does sound like a joke, but it really is this convoluted to get a simple LED blinking. This is the exact reason that Arduino was founded - to be a counterweight to this elitist, top down world. I should note that I have seen similar things on the AVR Freaks forum also, but not this bad. I should also point out that the hardware itself works great, it's just incredibly hard for beginners to learn how to use it. One might argue that you can’t compare a chip manufacturer to a platform like Arduino that use many different chip’s in their designs. I’m not really comparing hardware here - I’m comparing the developer experience for beginners. As a teacher, that is a concern for me. If you start with an Arduino (like most do these days) you expect solutions to be that easy to work with in the future. If you come from Arduino, then you’ll instantly dismiss PIC as being unnecessary difficult. This is hardware, so you’ll loose slowly but you will eventually loose completely.

The forum thread mentioned above is not unique. After working with PIC the last months, I can tell that this top down view persists across the entire forum and unless you prove worthy you won’t get an answer. Developers from across the world are fleeing solutions based on PIC controllers. There is no reason you should have to pay the massive extra cost of poor documentation and a lack of examples. Even Chinese chip manufacturers such as Espressif (the makers of the popular ESP8266) managed to make better tooling and API within a year. Microchip should really look to companies like Particle and Electric Imp that sell advanced microcontrollers with builtin wifi and hardware encryption/decryption. Their APIs are super solid across multiple devices and they just work. If they want to be really impressed, they should study Paul Stoffregen's work on the Teensy. It's so much cool stuff happening in the microcontroller world, but Microchip isn't part of it.

PS: I know that Microchip makes lots of other things apart from Microcontrollers. It's just that this blog post is about just that and not the other things they do like sensors.

PPS: If you go to the Microchip website after reading this - they have an error in the website JS so no links will open normally in Chrome. Just right click and select "Open in new window" to view the pages. If you open the console, you can see that the error thrown is "Uncaught ReferenceError: ga is not defined" referring to the Google Analytics implementation that is broken.


Makeblock mBot review

02 Sep

Makeblock mBot review

One of my favorite tools is the Makeblock Robot contruction system. I've actually spent more than $7000 on parts, so you can certainly call me a fan! This weekend I'm hosting a robot workshop for kids and based on former experience, I suggested that we'd use the mBot robot kits. That suggestion has cost me quite a bit of time, so I'll take this oppourtunity to review of the kit to tell what's good & bad.

I sincerely hope that Jasen Wang (Makeblock CEO) and others will read this review and find it a useful tool to improve the product. At it's current state the mBot offering is unprofessional and not a good product.

What's good and not

Let me get that out of the way - the hardware and the entire kit itself is great! The build quality is solid and the electronics works like a charm. The mCore electronics board is compatible with Arduino Uno so it's easy to use. The instruction booklet is solid & all that is needed (apart from batteries) is included. What is lacking is two things: documentation and software. In the case of Makeblock, they are targeting the Maker Community and especially kids.

When you unbox the robot and build it the first time, it is pre-programmed with three nice modes: Line follower, obstacle avoidance & IR remote. These all work as they should - until the kid tries to do what is the whole intention with the kit - program the robot. When a kit like this is purchased by a non-technical person and it does not work, it's basically just a piece of trash?

Terrible software and documentation

The accompanying booklet is solid, so assembling is easy but then it's time to download software. Following the link to will let you download either the Mac or Windows version of mBlock. This is based on the now abandoned offline version of Scratch and it really shows that the person that made this does not care very much about user friendliness. The main problem here is that mBot will NOT work in cojunction with the original Scratch commands such as "when Flag clicked". It will only work if you pull out the brick marked with "mBot Program" and stack commands beneath this. All other things will fail silently and you will have a kid sitting there thinking that both the robot and programming is stupid.

Most of the examples on the learning site will not work at all since they are based on non-working parts of Scratch. They do more or less also hint at this since if you check the "Arduino mode" menu item, you can see that other commands are being greyed out so why even have them there? They do after all have the entire source code for the Scratch program available, so it would be super easy to remove all the things that does not work. One such thing is that if you by accident check some of the menu items, your entire code will be corrupt since unsupported code blocks are just set to Undefined and are made red. I bet it's less than an hours job to make this program user friendly for someone that knew the codebase. All they need to do is to remove what does not work.

The Getting Started tutorial is also mixing in the Orion board (the larger Arduino-compatible from Makeblock) and that will confuse the users even more. It's just a mess. The Arduino code preview could have been really useful, but since nobody ever cared how it looked like (code formatting wise) it has very limited educational value. Placing a block of Motor control code at the top of all projects (even if it's not using a motor) just makes it messy, but I found the preview very useful when trying to figure out all the bugs in the software. If you've done something and it does not generate Arduino code, it won't work at all.

Oh - this is based on the Mac OSX version of the latest mBlock software (3.3.7). According to Avast Antivirus the PC version of mBlock is infected with malware so I don't feel like testing that just now… It could be fine though, but there’s room for improvement.

Poorly used support resources

The mBlock website also says that if you go to the Makeblock Forum, you will "Learn advanced techniques and get questions answered". This is very far from the truth. Makeblock used to have people employed for helping people on the forums, but for more than a year, practically all questions go unanswered unless they are answered by other community members (not affiliated with Makeblock). Unless they have fired all in their support team, someone is really not doing their job at all. They do however have a support-chat, but imagine how much more effective it was if these people just helped people in the forums? Then they could save maybe 90% of the requests?

There are lots of long Forum threads with unhappy customers that go completely unanswered and nothing happens when it comes to improving the software. This ensures that absolutely none of the customers will recommend Makeblock to their friends. Here's a great example, a user is so frustrated that he creates his own software that is much better than the original. Another example, a user asks how to blink a LED and is sent to an Instructable with incorrect info and defunkt video links. If the person asking tried to use this example with either his mBot or an Arduino, it wouldn't work.

Pin mapping for Makeblock mCore (mBot main board)

What does work is using the mBot with Arduino, but only if you fix some obvious mistakes in the Makeblock library (see below). It is however impossible to figure out HOW to use the RGB LEDs, light sensor, buzzer, button, IR input and other integrated pheripherals in the mCore board. It's just not documented either on the Wiki or in downloadable documents.

The first four ports are well marked on the mCore board itself: PORT_1, PORT_2, PORT_3, PORT_4. These are where you plug in sensors such as the accompanying Ultrasonic & LineFinder module. The remaining pheripherals is a different story. In a classical Chinese fashion, they are not documented at all. If you have been trying to access any of these, here is my unofficial documentation of how to use these:

PORT_6 Maps to the onboard Light sensor (LDR). Use with the MeLightSensor class.
PORT_7 Maps to the two onboard RGB LEDs. Use with the MeRGBLed class.
PORT_8 Is mapped to the Buzzer, but isn't used in any example. Instead you should just use pin 8 to access the buzzer (as in the default Arduino examples)
PORT_9 Is the same as motor 1. This will work with most sketches since it maps to M1. Use with MeDCMotor.
PORT_10 Is the same as motor 2. This will work with most sketches since it maps to M2. Use with MeDCMotor.

The IR receiver looks to be mapped to pin 3 from the schematics, but if you use the MeIR class like this you don't need to think about it.

To use any of the examples in the Makeblock library with mBot, use the PORT values above + replace the include for "MeOrion.h" with:

#include "MeMCore.h"

That should make most things work, but this should of course either be as comments in the code or be documented in the Makeblock Wiki. Sadly, it is not. The way I figured this out was by reading the schematic (that luckily is public) and some testing. Most people would have given up long before that.

It's not getting better

Code quality has gotten much worse over time with regards to Makeblock. I know they are growing, but their team has lost many talented people that actually had decent English skills. Their current support department is an insult. Language is always a problem, but they also lack basic knowledge about their own products. In terms of software, they regularily steal other peoples code and pass it off as their own by removing license information.

Just to name a single class, the MeStepper class is directly stolen from Mike McCauley's excellent AccelStepper library. They have deleted his version history as well as his copyright notice and replaced it with "Copyright (C), 2012-2016, MakeBlock". Unless they have signed an commercial agreement to use his library, this is just incredibly rude and also downright theft?

It's not just his library that have been stolen. Makeblock have a bad habit of republishing other people's code without following the original license that came with it. Not just that - they will also often make it worse than the original. A good example is that if you download and install the current Makeblock libraries according to their instructions, you'll get nothing but troubles. They've included their own versions of several standard libraries such as the Servo library and they didn't even check to see if it compiled. You can get around this problem by deleting the entire "utilities" folder that they include. This folder holds duplicate versions of files that already come with Arduino and they are not meant to be duplicated like this. You must also update the references to these files in some of the other source files:

#include "utilities/servo.h"

to the correct:

#include "servo.h"

The above change will remove errors & ensure things work like they should.


I'll manage to make a good workshop with mBot, but this is DESPITE and not BECAUSE of the quality of the Makeblock's software and documentation. I had to give up on mBlock, fix their library, research to find the missing documentation and I ended up using the Arduino IDE since mBlock is in such a sorry state. I'm amazed that they still have not solved these extremely basic problems within their organisation, so I hope this review can put some fire under somebodys butt before they ruin the last remains of credibility they have. Their last Kickstarter Codeybot was a pure consumer product and if they deliver similar quality - the consumers will completely ruin their entire business with bad reviews. They really need to brighten up!

Update 2 November 2016

I just realised that installing mBot screws up your Arduino IDE installation. It distributes a full Arduino IDE inside their app that will be outdated. This may then cause compilation errors. Not the best way to do this either.


Playing with LoRa radio

30 Jul

Playing with LoRa radio

I've played around with different radio technologies the last year. Some are cheap, some are expensive, but most of these have a fairly short range. LoRa is different and well worth checking out! Here I'll go through the dev-boards I used, power usage and what range you can expect from LoRa radios.

A little different history

LoRa is a spread spectrum technology jumping between frequencies is at the core of the technology. Looking at the history of this technique, you'll discover that one of the inventors stands out by being a female Hollywood Actor! Hedy Lamarr developed this technique with a friend (who was a composer!) to prevent the Germans from jamming the Allied torpedoes in WW2. Not shabby?

Radios based on the techniqe have been available for some time, but they have mostly been used by military and niche businesses.

Availability and pricing

There is a lot of LoRa dev-boards out there. The castellated modules from Hope RF are nice and you can get these separately to build your own board, but I always have a preference for Adafruit when playing with new technology. It just makes things so much easier since they excel in doumentation and quality.

The Adafruit LoRa boards are $39 a piece and you can choose between 16Mhz 32u4 or 48Mhz ARM M0 microcontrollers to control the radio and do I/O. These come with a voltage regulator that switches automatically between exernal USB power and the builtin LiPoly battery charger. If USB is connected, it will use this to both run the MCU+radio, but also to charge any connected LiPo battery. Very convenient!

Test setup

For my test setup I used 2500mAh LiPo batteries and these lasted much longer than I had expected! For convenience, I stacked a 15x7 led matrix shield on the first radio. This one was just plugged into a 400 hole breadboard and I taped the LiPo battery underneath the breadboard. This made for a nice and fairly compact package that I could hold in my hand while walking. The output on the led matrix feather was the dBm received from the stationary transmitter.

The other radio was put on a protoboard for some testing of basic sensors. It was then put into a waterproof project box with a transparent lid. After some testing, I've now drilled a hole for the antenna on this one. Its a 10 dBm penealty to enclosing the antenna in such a plastic box. That's quite a bit more than what I expected, but easy to fix.

I used basic whip antennas made with solid core copper wire. I experimented with using half-wavelength antennas (15.59cm) but cut this down to 7.79cm as it produced a better signal. I used the excellent Radiohead library and set the radio to the recommended 23dB power setting. The software was the server/client sketch with a modification to confirm that the radio did indeed receive the full text sent by the stationary radio.

What kind of range can you expect?

I've tested 315Mhz radios before but they have rather limited range, so I was expecting more from the LoRa radios despite the higher frequency. I had seen some claim 20 and even 50km in some cases, so I was curious to see what I got.

My first test was just leaving one radio inside my house and walk around. From this, I got about 300 metres of range, provided that my house was in sight. Not shabby? If there was something big blocking the radio, no signal got through.

The second test was placing the radio on (fairly high ground) outside a local school. First with the antenna inside the enclosure and then with the antenna out through the enclosure. I was quite disappointed with the first of these two, but as soon as the antenna was sticking out and had free sight it looked better.

I went for a walk to a local petrol station a few kilometers away and kept checking the radio status. When measuring in a straight line, I got 1.8km of reach until I lost the signal. During this distance, the radio never got a partial message. It got the full text always. I walked a road further up when going back and that gave me a better signal overall.

I live in a small town with up to 6 storey buildings. In this area, the signals bounced a bit between buildings but you can't expect many kilometers in such a setting. 2-300 meters is more realistic, unless you manage to place the radios really high up on the tallest building.

How about battery use?

This is the part that impressed me the most. These things are really not using a lot of power. None of my tests tried to conserve power in any way. I sent a signal twice per second and I blinked the LED on the server on each transmit. The receiver had the 15x7 LED matrix, so I expected this to drain the battery quickly. To make it last a little longer I only lit the display for 100ms after receiving a transmission. I expected maybe 3-4 hours for this one, but it lasted 12.5 hours before the 2500mAh battery drained. Not shabby?

The server is a different story! It transmitted for 71.5 hours(!) on that single 2500mAh LiPo. This really wasn't expected at all. I presume that by just turning off the LED and transmit just once every 10 seconds, I can make it last much, much longer! Then If you start playing with putting the entire microcontroller to sleep… My intent is to play around with solar charging next, so this could become something that keeps running for a very long time.

Final thoughts

I think there's no need to doubt that these radios can reach tens of kilometers given the right conditions. The ideal condition would be free sight to the receiver, so you need to get the radio high up on a house or a radio tower if you want to go really far. They were surprisingly solid and never skipped a beat. They work well in office buildings, so they could be well suited for sensors in a building where WiFi is spotty. I'm really looking forward to using these when teaching the M2M Communications topic at Westerdals this autumn!

90 RSSI at Kolbotn Church, 750 meters from the transmitter. Some nice Pokemons there as well. Pokemon Go goes really well with radio testing! smile


Milling 2-sided PCB’s

08 Jan

Milling 2-sided PCB’s

Before xmas I did a lot of PCB milling for a client. Compared to getting the PCB's commercially made somewhere, this is the equivalent of rapid prototyping for circuits. Getting a board produced in the UK, Germany or Asia will typically take at least 2 weeks (but often 3). If you can reliably produce 2-sided boards using a mill, you'll iterate and find errors faster.

Milling is a lot cleaner than etching and you really don't want to hand-drill several hundred holes on an etched PCB. Getting perfect results every time took a bit of learning though, so I thought I'd describe my process for 2-sided boards here so others can use it.

Preparing the PCB

Unless I need components that only exist in Eagle, I make my boards using Fritzing since it's quick and it has a great UI (compared to Eagle). Fritzing allows me to export both Gerber files for production and SVG files for home etching or milling. Fritzing is super easy to work with so I won't go into details on it, but here's some things to keep in mind when laying out the PCB.

When creating the layout, set the PCB to be the exact sub-millimeter size of your PCB milling blanks. Don't be tempted to use a smaller size in the PCB design software since "you won't need that much". This will only give you headaches. Remember that using the size of the PCB blanks, you can easily add some cutting lines, so that when the PCB is perfect you can cut it to size. If you don't do it like this, you can't flip the board precisely enough. Trust me - I've tried and failed many times. It's just not precise enough.

Many components in Fritzing such as via's offer select a Home Etched version that is larger and easier to work with if you make the board yourself. You can also tweak components such as headers to be easier to mill.

One thing that isn't obvious is that on a home-made board, it's much easier to place components on the top and solder them all from the bottom of the board. Professionally made boards have through-hole plating so all holes are connected from top to bottom, but you won't have this so all solder points should end up on the bottom in some way. You can still place traces on the top layer, but you'll have to take them down to the bottom using a via for soldering. Don't forget that rotating components makes a world of difference when laying out the PCB. If you manage to get the top layer as a solid ground plane with no vias, you're saving a lot of manual labor.

A via for a homemade PCB is basically just a drill hole in which you solder a wire connected to both sides. Make sure to set the via to be large and not the tiny default used for professionally produced PCBs. This makes it much easier to solder them later.

It took some iterations to get it right...

Use the widest possible traces that will fit with the connectors and other components in your PCB design. The standard is to use 24mil traces. As we'll be milling along the outline of the traces, so by using 32 or 48mil traces, you can run your mill on the outlines and still have a trace left. Alternatively, you can widen the traces in a vector editing program later, but I find it easier to do it straight in Fritzing.

The next important step is exporting the files (Export > For production > Etchable). This will export files for the silkscreen, paste mask, etch mask and copper traces. We only need the copper. What you'll want is the "Copper top" and the "Copper bottom mirrored". If you select the wrong files, you'll have to redo (or mount the components on the "wrong" side of the board). I suggest that you print out these files on paper at 100% size, glue them together and cut to size so you get a "dummy" PCB before milling. Place your components onto it to see that it's all correct from both top and bottom.

Preparing the output for milling

The exported SVG files will still need some "massaging" to work well. I use Adobe Illustrator, but you can also do this with free software as Inkscape. It just takes a little longer. First go into outline view so you can see any objects that the PCB software has placed two of. It's quite common that square pads have a circular outline under them so clean this up.

Then merge all the vectors into solid shapes so that we can follow the outline to cut the trace out. Remember to copy the holes onto a separate layer before merging, so you have what you need for drilling the holes. I usually use the "Outline stroke" feature to turn lines into fills and then I'll use the Pathfinder panel to Unite all the connected/overlapping vectors. Illustrator does this in seconds, but Inkscape can take 15 minutes for even simple boards.

When you have all the shapes merged into solids, you can move the file to your CAM software. At Bitraf, we use VCarve but all you need to do is to set up paths and drills based on the vector file you've made. I'm using a 90 degree V-bit for the traces and all I have to do is to follow the outlines and cut just deep enough to break connectivity. For the holes I use 0.8mm drills or 1mm if I'm to add through hole rivets like these

Now that we have the files ready, it's time to move on to the milling. For this project I used the huge Shopbot PRS Alpha that we have at Bitraf, but the process will be identical for any other mill.

How to make a good Jig

The entire secret to getting two sided PCBs perfect is to have a good "jig" - a setup that ensures 100% identical placement on both sides. I made my jig using a scrap piece of High Density Fiberboard (HDF) but you probably use can use many other materials for this.

- Fix a piece of fiber board blank to the drilling surface. This will become our jig. It should be somewhat bigger than the PCB itself.
- Use a mill to by mill away a millimeter or so of the surface. This will compensate for any deviations when mounting the fiber board blank and ensures the surface is 100% planar.
- If your PCB is 1.5mm thick, mill a pocket for the PCB that is a little less than the thickness of the PCB. I used 1.2mm, so the PCB was only sticking out a tiny bit. I made the entire pocket 0.05mm wider than the PCB and that gave me "push-fit".
- If you're making many copies of the PCB - mill a hole on the side of the pocket that is big enough for your finger, so you easily lift the boards out.
- Put the PCB in the pocket and make either a full frame (slightly smaller than the PCB) or use some small wooden pieces that you the fixate the board with. Don't over-tighten as that can cause the PCB to become slightly bent giving you uneven

With this technique, your board will be 100% in the same place when you flip it around to do the other side. On the boards that I make now, I cannot see any sub-millimeter deviation from one side to the other.

I initially tried tape/glue rather than milling a pocket. The result was that I bent the boards ever so slightly and that caused some traces to get uneven widths since the mill went deeper. This approach of just holding the board down solves this.

The finished jig with Polycarbonate pieces to hold the PCB down during milling

The importance of having identical blanks

For the jig to work well it's extremely important to have PCB blacks of identical size. Initially I was unable to find suitable size PCBs at my local electronics store, so I picked of some boards that were twice the required size and cut these in two. Despite using the mill, I didn't get these to the exact size and it bit me later on. I waited until my supplier had restocked and then this was no longer an issue.

Signs that something's wrong

Cutting 0.18 into the board should isolate the traces when using a 90 degree V-bit. If more is required, check alignment of the board in the jig! Twice I've spent hours on milling just to get the other side of the board wrong. Always start with the drills, then the layer with the least amount of traces (usually the top layer). This will give you the shortest route to seeing if things are correctly set up. Alternatively, do the drill holes from both sides to verify that they align.

I hope this helps others making two-sided milled boards. If you use the instructions, feel free to email me a picture of the jig & result?

Buying a laser cutter for your Hackerspace

15 Nov

Buying a laser cutter for your Hackerspace

At my local Hackerspace, many of us wanted access to a laser cutter. I had plenty of ideas of what to use it for and it's also one of the "Maker tools" that are the easiest to get started with. I started looking at DIY lasers like the Lasersaur project, but I felt like they were above my skill level and a little too big in size for our limited space. Now that we've purchased a laser cutter, I've gotten several questions from friends and other hackerspaces/makerspaces about the purchase process, how well it works and what to look for/avoid when buying a China-laser. Here's some of my experiences.

Picking a brand / model

We tried to save up for a laser that we could buy from a local supplier, but it was simply out of reach. Then I started looking into Ebay lasers. Ebay lasers are 3-5 times cheaper than what the commercial suppliers offer here in Norway. The drawback is that they come without any warranty or support. I gave it some thought and decided that we really needed to have a decent laser @ Bitraf - both for myself and for attracting new members.

I scoured different forums, but CNCZone in special and looked for reviews of China-made laser cutters. After much reading, I opted for a Redsail X700. It has a 700x500mm work area, a 60 watt CO2 laser tube, motorised Z-height and that's about it. They claim a lot of other features like auto-focus, but that's not really true. It can move along preprogrammed X, Y & Z paths and blast a laser that moves at up to 300mm/sec. There is no way to runtime-adjust the strength of the laser. It's on or off, but it runs off a PWM output so you can blast it for shorter or longer periods to "fake" that a bit. Setting the laser power on these cheap lasers are basically the same as setting the PWM frequency.

By comparison - a professional laser can tweak this quite a bit and even adjust the focal point at runtime. Using this, you can do a 2cm deep 3D engraving without leaving the wood burnt. With these chinese lasers you can easily engrave and cut at various "strengths" as well, but it's something you set per object. The software that comes with China-lasers are also extremely crappy, but I'll get back to that later.

Buying expensive stuff from Ebay

I looked around and there's at least 5 companies on Ebay that sells the X700. You won't find them by searching for the RedSail brand though, so search for "60W CO2 laser" and then you'll see the listings. After looking around, I went for the ebay seller CNCCheap. I decided this based on the usual thing you do on Ebay, I looked at the buyer ratings. It turns out that this is highly irrelevant for anything that ships in a container and takes longer than the maximum review-period to arrive. This post is in many ways a review of cnccheap and I'll tell you right away - they're not the least professional.

Up until I transferred the money, the sales personell at CNCCheap were really snappy. I asked questions and got replies back by the next day. The list of standard accessories is quite long:

  • Laser Engraving software Package (English Version)
  • User Manual (CD)
  • CW-3000 chiller
  • Air exhaust fan
  • Air Pump
  • Communication cable
  • 3 Reflect optics (installed in the machine)
  • 1 Focus optics (installed in the machine)
  • 1 60 watt laser tube
  • Other tools

These are all things that you'll need. The Chiller is crucial to keep the temperature of the CO2 laser tube where it should be. Water circulates inside the tube and keeps the fancy 3-layer glass tube at just above room temperature. The air exhaust fan and air pump (for air-assist) are also pretty much required, as are the rest of the list. They also offer a good list of accessories:

  • Honeycomb
  • Reddot Positioning
  • Rotary tool
  • Motorised up and down platform
  • Extra optics
  • Extra laser tube

I basically went for the "full package" of accessories with one exception - I did not buy an extra 60 watt laser tube. Why? I had learned that CO2 laser tubes only last about a year and then you have to replace them, so why keep a spare that you'll only throw it away? Turns out this was actually my biggest mistake. More on that later, but always buy that spare tube...

It feels a little odd to buy something worth $3800 via Paypal/Ebay, but not to worry! Ebay has their buyers protection, Right? Just 4 weeks after I hit the Checkout button (and before the laser arrived), the purchase disappeared from my Ebay history. Repeated emails / tweets to Ebay's support never resolved this and I never got an opportunity to leave my 1-star review of CNCCheap as a company. So - keep in mind - don't select your laser supplier based on the Ebay rating. Look around for real-world cases of companies that offer good service. CNCCheap is not one of these. I ordered the laser the 11th December 2014.

Shipping and getting it in the door

I read about the shipping process online and it's pretty straightforward. The seller will ship the laser to the nearest harbor and they'll also help you organise the last part as well. A local shipping company will then pick it up when it arrives, do the paperwork and after you've paid them - they'll deliver it to your door. Pretty straightforward. Due to unforeseen circumstances (these apparently happen all the time in shipping), the laser took quite some time to arrive in Oslo, Norway. I received the laser the 25th February 2015

The package was huge! It was well packaged and secured and had no obvious damage. Unpacking the laser we quickly realised that getting it up the stairs would be an issue. One of the Bitraf members had one of these neat electrical trolleys for moving heavy loads up stairs. Immensely useful, so if you have stairs - find someone that has one of these!

Assembly and sparks flying!

Setting the machine up was easy enough. Not because of the incredibly crappy documentation offered, but due to some videos I found on Youtube (from RedSail, not CNCCheap). The documentation was 10 pages of assembly for a different laser cutter and then 120+ pages on a different software than what we received. The software itself (AutoLaser) was delivered on a recordable CD. So much for "original software"? Me and Jon assembled the machine the same evening but it didn't work at all.

When we hit the Pulse-button, sparks flew about inside the laser Powersupply. A laser excites the gas inside the laser tube by shooting 27.000 Volts though it. You don't want to be near it when this goes wrong. Here's how it sounded:

The rest is a fairly long story that I'll condense here for brevity, but a log is here (in Norwegian) and my chat-log with the CNCCheap salesperson Lucy is here. Here's some dates and briefly what happened:

  • 2015-03-15 We confirm by testing that the laser PSU is working and that it's the lasertube that is dead
  • 2015-03-16 CNCCheap was told about the problem. They recognised the problem and said that they would ship a new tube.
  • 2015-03-25 The package arrives in Norway, but it's declared as worth $5. We need a proper invoice to get it out and CNCCheap takes forever to supply us this
  • 2015-04-07 We get the package and discover that they didn't send a laser tube - they sent us another power supply?
  • 2015-04-08 Despite solid proof, the seller refuses to send a new tube since they don't believe us. I get tired of arguing and order a tube from someone else.
  • 2015-04-14 New tube arrives and works on first attempt!
  • 2015-04-15 CNCCheap is told about the working tube and they still protest. They even go as far as claiming that we are past the 3 month warranty. Then I explode....
  • 2015-04-27 CNCCheap finally admits that the tube does not work, but insist that we smash the old tube. Apparently, they really don't trust us despite our problems...
  • 2015-05-04 Two and a half month after telling them about the defective tube, we receive the replacement.

Five and a half month after ordering it, we eventually have a working laser cutter on the cheap. We also realised that we never received the exhaust fan promised, but the non-working laser made that quite irrelevant. With the help of members Peter, Mubin, Kyrre, Vidar, Torfinn and Jon we finally got it up and running, but without their debugging experience from high voltage circuits I'd never make this. Thanks a bunch guys! I suggest that you find some allies that know a bit about high voltage circuits before buying.

Among the things we solved:

  • The interlock switch was loose
  • The safety connector to the chiller may be inserted the wrong way despite having a notch
  • Soldering the anode and cathode wires are incredibly hard. Use stranded wire as shown in this instructable, wind it really hard around the anode and then solder. Don't forget to add the isolation before soldering!
  • If the display does not light up, check the red emergency button. It's of really low quality.

Big thanks also go out to the other RedSail owners on CNCZone. They deliver much better support than the resellers or Redsail themselves. If you want to see how it looks when you intentionally break a laser tube, check the video below:

Breaking the old tube was a requirement from CNCCheap. They wanted to ensure that I did not try to fool them into sending me a new tube while the old one was actually working.

How we like it

Despite the incredibly unprofessional behavior from CNCCheap, we're happy with the machine. You really should avoid CNCCheap at all cost and I truly think that RedSail should kick them as a reseller for treating customers like this. They are not the only bad reseller though, so be sure to check for good reviews by trusted sources.

Overall I'm pretty impressed with what we can do with this thing given the price. We can engrave lots of different materials and we can cut the following with good results:

  • 8mm clear acrylic
  • 6mm MDF board
  • 6mm plywood
  • leather

These are the max thicknesses we've cut. Anything less also goes fine obviously. 

The AutoLaser software is notoriously bad. It's unstable and only imports DXF format without crashing. It does work fairly well apart from those very noticeable flaws. The undocumented meny system on the machine may seem like a joke as the English is very poor. There's also three different "Enter-buttons" depending on what part of the menu you are in, so the usability of this thing is practically zero.

The most important thing you need to know is that "Back" actually means "Home" and that the X700 has several undocumented (but nice) features. To zero the X-height on the material, you either click 12 times in the crazy menus, or use the undocumented command of pressing the dot-button and then pressing Enter. To show the outer bounds of the area to be engraved, press the Range-button and then enter. There might be more of these, but it's hard to tell. These we stumbled on by random chance.

We started using the machine without a filter. Then I built a DIY filter. It did well for a while, but now we're getting a commercial grade filter. My self-built filter sent all the warm air out of the building. This is convenient during summer, but not so much during winter. The commercial filter will clean the air enough that we don't need to vent it outdoors.

Below is a video of the most elaborate project I've made thus far. It's a timing gate for the Nerdy Derby race at Teknisk Museeum in Oslo. I learned quite a bit from that - but primarily that objects made of laser cut wood should not be in public spaces were kids run around wink

React with Javascript package managers

13 Nov

React with Javascript package managers

One of the best ways to learn new software is to take on a commercial project and force yourself to use it. I do this all the time and with all the cool kids ranting about React, I felt that it was time to do a project based on it. It's been a bit painful, but I've come to enjoy the way React works. It's actually quite beautiful!

I've used Angular before and React feels much more solid and natural. It does require that you learn how React thinks (or want you to think), and that part might take a little time. Here's some of what I've learned while using React.

Javascript - the new frontend AND backend favorite

To create a HelloWorld on the web, all you need is a HTML page with a few lines of inline JS. How can a 200+ file download possibly be an upgrade from that? It just does not make sense that a simple HelloWorld-project should become a folder with 139Mb of Javascript based libraries, right? Like it or not - Javascript is the language that takes over both frontend and backend development these days.

You can use it old-style (and write it all by hand) or use one of the many hundred frameworks that are out there to make your life easier. So while the initial download may be large when using frameworks, the files will normally be cached by the browser. If you use a CDN for your framework, odds are that it's already cached.

I've always known JS and it's very close to Actionscript. Learning React has not only been yet another nail in the Flash coffin (it's really completely dead). Learning React has also taught me several new programming concepts that I'll keep using for other projects.

How React is different

I've had to do lots of refactoring every time I've understood how a new thing worked in React and that’s been a bit painful. Initially I tried to fight against how React worked since I wanted to be in control. The React way of doing things is to not do things directly, but to always do things based on state. The data model controls the GUI in reactive programming. React only re-renders if an object has changed, so to change something on screen, you need to implement a visual change in response to an object/variable changing. This happens asyncronously since the React DOM and the browser DOM are two different things. With React, you never manipulate the DOM directly. It always happens because of a change in the data model of the app.

Changing an object/variable to change the GUI sounds cumbersome until you've used it. The super-neat thing about this is that if you do things correctly, you'll be able to start your app from ANY state and also to change it while it's running! You just set the variables and the app will render straight to this state! No more clicking 20 times to get to a certains state for debugging. Now you just set the data of that state and you're there? Understanding how to solve things "the React way" is what really takes time, but once you get the hang of it you'll wonder why not all software is based on this principle.

A React application starts at a root component, that then renders sub-components that renders sub-components. It takes time to understand where in such a hierarchy certain data should be, how it's passed most effectively and how to implement the visual changes in response. I won't say I'm completely on top of this yet, but I really feel that I'm getting a lot back from this approach of working. The very clean separation of responsibilities between each component makes you much less afraid of breaking stuff than with other ways of working with code. You basically jump straight to the module you want to work on and do your thing, knowing that it won't break stuff. I really recommend trying out this way of developing web apps if you haven't!

Getting up to speed

When you start out with React, you'll most likely start like me using the in-browser JSX transformer to convert JSX to pure javascript at runtime. This process is called "transpiling", since you're not really compiling but rather converting the React's custom JS format (JSX) to plain ECMAScript JS. Following the official docs from Facebook, you'll get your project started but to really grasp the full power of React, you should go through setting up the NPM and JSPM package managers.

Why? For one thing - most of the example code you'll find online will require it. Package managers are great tools since they keep track of all the dependencies used in your project and they download all dependencies from CDN's. The most important is however that they can convert your app to a pure JS class that is much faster than the runtime-compiled JSX script.

So how do you get started with Package Managers? There's several to choose from, but if you've played with Node.js you probably already have "npm" installed? If not, click here to learn how to install it. Once you have npm installed, open a terminal window (or CMD command line on Windows) and type:

  sudo npm install jspm -g

This will install JavaScript Package Manager (JSPM) on your system and make it easy to install any library you want to use. JSPM seems like a solid choice among a flurry of others that pop up and then disappear and it can pull in code-packages from both npm and github.

To create a new project from scratch, you'll make a new folder, go into it and type the following:

  npm init
  jspm init

This will create a couple basic files that the package manager needs to keep track of what libraries your project is using. It will also download some base packages you need to start developing: Systemjs makes it easy to include libraries on your app. Babel compiles JSX to a variety of JS (including ECMAScript 6 / ES2015), makes sense out of error messages and adds support for missing features in some browsers. You'll find these and some others in a folder called "jspm_packages". With these files in place, you'll want to get ready for React programming by installing React itself:

  jspm install npm:react

These are now added as dependencies in the package.json file in your folder and you can start using React with a package manager to ease your development.

JS and it's blazing speed of development

This talk from Jack Franklin was of great help to me in learning JSPM, but it's also quite typical in the JS-world that the talk from May (6 months ago) is already full of "bugs". JS libs are rarely consistent over time, and if you try to run his code, you'll get errors like:

  Warning: React.render is deprecated. Please use ReactDOM.render from require('react-dom') instead

If you then try to use that code, you'll realise that you didn't install the package "react-dom" since that wasn't needed 6 months ago. Looking at the official documentation from Facebook you'll see that you should not use the import-statement as Jack does, but rather use "require" like this:

var React = require('react');
var ReactDOM = require('react-dom');

Running that will give you the error:

  Error: require is not defined

Facebook just takes it for granted that you've installed the "browserify" package. This is what give you the require-statement and other goodness since there's no such thing in JS. They take this for granted in all their doumentation, so be aware that you'll need that to have browserify or webpack installed if you want to just cut and paste their examples. They do actually mention it on their Getting Started page, but if you're new to Javascript package managers, it's quick to skip that single mention.

But - armed with your new knowledge about JSPM, you could just pull it down

  jspm install npm:browserify

The problem is that this requires that you reconfigure your app from scratch, and since you're now following Jack's great tutorial, you should rather do the following:

  jspm install npm:react-dom

Once that is in place, you can use "import" rather than "require" like this:

  import React from 'react';
  import ReactDOM from 'react-dom';

I don't find these error messages intuitive at all, so I thought I'd better jot this down for Google to find, so others can skip some frustration smile

Using "import" or "require" syntax is just a matter of preference. You can use both, but since none of them actually exists in JS they're implemented as Polyfills - placeholder syntax for methods that may or may not end up in the ECMA language.

Why Javascript should become what students learn first

When I started using Node.js on both the server & client some years ago, I never thought it'd become as popular as it is today. Now that I'm teaching a bit, I keep thinking that it's crazy that students don't learn JS in school. Think about it - why should students not learn a language that can cover both the client and the server? It is after all the programming concepts you should be tought at school, not the syntax. The Syntax is bound to change and keep changing, but the general concepts of programming is something that you'll carry with you from one language to the next.

If I could affect the students carriculum at University and higher education, I'd use Javascript as the first programming language to learn. Once students know the basics of the language, I'd make a frontend and a backend track. Having one language for both makes it quicker to get past the syntax and tooling stage, and get into the concepts and useful stuff. The frontend track would be focused on using React, Angular and other frameworks. It would be more about how to learn frameworks than creating big projects. Knowing how to learn a new framework is much more useful than focusing on the fine details of a language.

The backend track would be foused on Node.js making multiuser apps and games, controlling hardware and persisting data. Compared to starting with Java, C,C++ or PHP, this would be much more useful to the students. They'd get results faster, they'd learn skills that are instantly useful in a job situation and they'd have a huge and great community to learn from. Once they've learned JS, they'll easier pick up the more advanced features in more mature languages. JS is basically a much better starting language.

Call me! (with Adafruit FONA)

09 Sep

Call me! (with Adafruit FONA)

About a year ago, Adafruit launched the FONA. It's a neat little breakout board that packs all the features you'd want in a phone such as Calling, SMS, Data and Lipo battery operation and charging. Add to that a good API that is easy to extend and we have a winner.

By itself, the module can't do much, so you'll need a microcontroller of some sort. My preference is using a Teensy 3.1 since these are just incredibly flexible, fast & cheap. They're also small and placement friendly. By now I've used the FONA for two commercial projects and I thought it'd be nice to collect my experiences in this post.

Call for pizza using the ad on a bus station

The first project had me build the FONA into an advertising board. Check this video to see it in action. The large timer was connected to a motor that pulled it slowly back to zero. At each end position of the timer, there was a manual switch that triggered the FONA in different ways. When the timer was set to 15 minutes, the Teensy set the FONA to call up the pizza delivery. If the person turning the timer wanted, they could get a free pizza within 15 minutes. When the timer was set back to Zero, the Teensy prepared the FONA for the next customer.

As can be seen in the video, it was a snowy morning and I got to do some extra troubleshooting in the bus shed since the timer motor accidentally burned out the evening before and the replacement motor made so much electrical noise that it messed up the sensing on the button pins. I solved this by moving the button pins to analog pins and using a different threshold than the normal digital I/O used.

The FONA used a normal headset-mic to pick up the sound. To play it back I used some more Adafruit components - a 3.7W amplifier and these neat transducers. Despite being only 5W, it was not a problem to hear the sound on a busy Bus-stop when attaching the transducer firmly to the board itself. While the person waited for their pizza, we also played them some cheezy elevator-music. This came from the Teensy using the Audio Adaptor board. I really dig this board. So many cool audio things you can do. Really powerful!

The installation stood there for a whole day and worked without any issues despite the moist weather.

Call anywhere in the world for free!

The second project had us set up a telephone booth that looked kind of like a 1.2 meter tall iPhone. It was to promote the mobile provider MyCall and the idea was to make a phone booth where you can call for free (3 minutes at a time). JCDecaux also made a nice video for this one that highlights that the campaign gave 30% boost in sales.

The interface to the user was a 47" touchscreen showing a multi-screen AIR app that communicated with a Teensy 3.1 via Serial. Before calling, the user was asked to input their existing phone number. After their free call was finished, we used their phone number to send them a polite SMS telling that MyCall offered great prices on calls abroad (their specialty). The project stood outside in a very public space (outside the Oslo central station) for 10 days and worked without a single error. I'm really happy with the stability of the FONA/Teensy combination!

Both projects were done for JCDecaux with MesseTjeneste making the enclosures and me doing the software + electronics.

Fona tips and tricks learned

Here's some things that are nice to know about FONA that you won't find on the (as always) solid tutorial pages on

A lipo battery is indeed Required
The FONA needs a battery to be able to source the required power upon connecting to the network. A 2.2A / 5V dedicated power supply was not enough, but a half-charged 150mA lipo in addition to the USB connection did the trick. The lipo battery is now added as a requirement on the FONA product page.

GSM calling produces serious EMP
Once a call was placed or the FONA connected to the network, the audio chip in the Teensy Audio board was completely messed up. It produced random and unpleasant audible noise. I solved by moving the FONA away from the Teensy, putting them in two separate boxes. I also tried shielding them from each other, but I got very varying results. Much easier to just move them away from each other.

Not all SIM cards will work
I initially picked up a dirt cheap SIM card at a kiosk and it worked right away. This was from MyCall, the company I later made the kiosk for. I then needed to make a copy of the installation, but when I tried to use a SIM card from Norway's largest telco Telenor, it didn't work.

The SIM worked like a charm when inserted into a phone, but on the FONA I was unable to connect to the network. The SIM unlocked successfully, but I was denied access to the network. I later learned that holding down the KEY button for 20 seconds can solve this.

Library only covers some
I needed to blink some lights while a call was in progress and play some audio when the call ended. There currently isn't a method in the default library to check this, but all I had to do was to look up the SIM800L datasheet to find the required AT command.  I then looked through the Adafruit code to see how they had implemented similar features and added this (gist). It's all just serial AT-commands that are wrapped nicely. Super simple!

Using Teensy
Since the Teensy has several Serial ports, you may need to make some minor changes to the default FONA sketches and lib. I've detailed these in this gist.

Ideas aplenty

My initial thought seeing the FONA was to build a phone, but I still haven't done that. Instead, I've used it for installations. Using a phone rather than wifi or bluetooth has advantages and drawbacks, but there are some pretty cool things you can do with this. As an example of something I'd love to do:

  • Imagine an interactive window display controlled via SMS?
  • Using it as a transparent network access point?
  • Click-this-big-button-to-talk-to-support/sales?
  • Circuits that allow you to check status or remote control vending machines or controls? It would be really simple to make a machine send an SMS if it fails to do it's task, so it can alert you that it needs service.
  • It could also be perfect for simple surveilance of hunting spots or beehives in rural areas where there's no phone coverage
  • Turning on the heat at the family cottage via SMS

It's so many cool things you can do with this when you don't need to think about having wifi available!

I really dig how easy it is to build connected installations with the FONA board and it looks like others also think so since Adafruit has now expanded the range to also include a board with a GPS and some convenient starter packs. I'm looking forward to play much more with FONA in the future!

Fixing avr-eclipse paths

20 Aug

Fixing avr-eclipse paths

Just before summer, I started consulting work for a hardware startup here in Oslo. As part of this I've gotten to play around with and integrate lots of new toys such as VISA card readers and various communication solutions. I also inherited some AVR code for a circuit developed specifically for the project and yesterday I set up the tooling.

I guess I could have used all sorts of software alternatives to program the microcontroller, but since the people that created the codebase used Avr-Eclipse, I figured that I'd check it out. Using a GUI makes finding the right fuse settings a breeze and I love to have proper syntax highlighting and completion. Setting it up was easy using this guide, but getting the code to compile properly was somewhat difficult so I thought I'd jot down what I learned in case it helps others.

Setting path for AVR tools in Eclipse

All my problems boiled down to Eclipse not using the PATH variables for avr-gcc and avrdude. On my system I have CrossPack installed for working with pure AVR projects and then I typically use the Arduino tool + Sublime for anything Arduino-related. The Arduino tool automatically adds some things to PATH on the Mac/OSX so in theory, avr-eclipse should just find and use this. It didn't. Instead it pointed to an old, uninstalled version installed by MacPorts on my old Mac that got ported over to my second Mac. All the folders were empty as I unsinstalled MacPorts to use Brew instead several years ago, but the "smart" feature insisted that these empty folders were better than looking at the system PATH variable. I altered the PATH values to point to the CrossPack installation but that didn't help either.

The creators of the avr-eclipse plugin have tried to add some smarts to the configuration, but that failed completely for me. To set the correct location of the AVR tools you want to use, open the Eclipse menu > Preferences and then expand AVR > Paths like this:

Forget the Rescan button if you know what path you want to use. If you don't know the path to avr-gcc and the other tools, just open a terminal window and type:

which avr-gcc

This will tell you the path of the avr-gcc that can be reached through the normal PATH settings on your machine. Now you'd think that this is all you need to do, right?

Fixing the standard includes

I kept getting errors like this.

undefined reference to `debug'
undefined reference to `asm'

It basically means that AVR-eclipse can't find the class definitions for these files. To fix it, Right Click the name of your project in the Package Explorer window and select Properties at the bottom of this menu. This brings up the local preferences for the project. Go to the "C/C++ General" entry and expand the "Paths and Symbols" option. Make sure you're linking to the right version of the include files here:

If you've set the correct AVR hardware and the right programmer, you should now have a working setup. Hope this helps someone as it was rather hard to google all the bits required to get to this.


Testing with Testflight

10 Jul

Testing with Testflight

After Apple purchased Testflight, the service has been integrated into the workflow when publishing apps. Any app with a distribution profile can be sent to users for testing and the process is actually quite smooth compared to the old version. First your build is vetted by Application Loader (or XCode) and then you turn on testing for that specific build. I did however run into an issue worth publishing in case others run into it.

Normally, you'll just flick a switch to turn on Testflight Beta Testing and the app is ready to be tested by all internal to the team. In my case, I could flick the switch but nothing happened. I called Apple Developer support, but the guy I talked with completely failed at understanding what my issue was and he insisted on sending me something I knew was incorrect. He just wouldn't listen when I tried to tell him that something was wrong:

I eventually understood that the first of the two warnings (... must contain the correct beta entitlement) did not have anything to do with my certificate or provisioning file, but rather a missing directive in my app descriptor. Some googling led me to this article that explained how one had to add the beta-reports-active key to the Entitlements part of the descriptor. I now got an error when uploading the 

Build 168 does not contain the correct beta entitlement.

After reading all the replies to this thread I realised that I should not set the mobileProvision-file to be for AdHoc distribution. It should just be a Distribution profile for App Store. That's it.

I also had another issue getting my AIR app published this time. After updating to the latest XCode, I got the following error when uploading the app:

Invalid Bundle: The bundle does not support the minimum version os specified in info.plist

Turns out one have to add a bit about MinimumOSVersion to the InfoAdditions-section of the descriptor file as well. My entire iPhone descriptor settings are now like this: