Particle memory limitations and workarounds

18 Sep18

Particle memory limitations and workarounds

When coding in C/C++ it's crucial to do memory management correct. For a device that is expected to "just work" you simply cannot have any memory leaks. The simple way to solve this is to never allocate memory dynamically. By just instantiating all objects statically, you can be guaranteed that you always have enough memory. What do you do when you past this?

With the first Particle hardware platform called Spark Core, you had about 108Kb for your program and 35Kb of runtime memory available. With the Particle Photon, you have 128Kb program and about 60Kb runtime. This extra memory does however come with an undocumented limitation - for the Setup wifi feature (known as Listen Mode) to work, you have to leave at least 21.5Kb of the 60Kb free. You are free to use more, but if you do so the Listen Mode will not work correctly. Saving credentials will seem to work, but eventually fail.

If you've gotten to this, the trick is of course to start allocating memory dynamically instead of statically. That way you can utilise the same memory for multiple things. Jumping through some hoops and rethinking what needed to be in memory at what time, we found a fairly simple solution. We have a lot of debug features that take up valuable memory. Customers will normally not use these, so by making it all dynamic we suddenly had a lot of memory to spare. Here's how the memory usage looked before and after:

Memory use:
   text    data     bss     dec   note
  89884    2148   43360  135392   (before dynamic allocation)
  89868    2148   33128  125144   (after dynamic allocation of a large buffer)
  90012    2148   18468  110628   (Debug screens moved to RAM)

We basically halved the memory usage without sacrificing any features by just rethinking what we needed to load at what times in the program. I'm quite happy with how this turned out and I wanted to share in case others run into the same issue. Big shoutout the the great community and employees at Particle that helped solve this issue!

Level shifting NeoPixels for Particle Photon

14 Sep18

Level shifting NeoPixels for Particle Photon

I just miscounted how many GPIO pins I had for a project, so I had to find a way to save some pins. In this project we have a status LED that is either red, green or both (producing a somewhat orange color). I need 4 of these per Photon, so that's 8 pins. What about using programmable ws2812, sw2812b or SK6812 LED's?

They only need a single pin to drive many LEDs (NeoPixels is just the marketing name that Adafruit apply for all of these), so I can potentially save up to 7 pins, but also make other colors than red/green possible. Surely enough, I had some of these floating around from a former project.

For my Bitmart marquee sign I used maybe 90 of these, but I kept having bugs causing random flashes if I pulled too much power. Back then I used a 74HCT125 for level shifting, but I couldn't find either that or the 74AHCT125 variant in my component shelves. I did however find some 74HCT245 deep down in a drawer and surely enough - these are what is perferred for driving these programmable LED's in the Teensy community. Both will do the job!

I plugged it up and it worked perfectly! No glitches, just perfect timing. From the datasheets, the 74HCT125 and 74HCT245 looks to have very similar characteristics, but the first shifts 4 lines and the other shifts up to eight lines. The one I used in the Bitmart-sign was just one I found in a shelf at Bitraf. Maybe that one was damaged? Hmmm. I'll have to revisit that project to fix the glitches, but for now I've solved my problem.

I had a hard time locating pinouts / connection schematics for these IC's so here they are for use with Particle Photon.

Connecting Particle Photon to NeoPixels using 74HCT125

Connecting Particle Photon to NeoPixels using 74HCT245

Yellow wire is data out from the Photon. Purple is the level shifted data signal. Red is 5V. Black is GND. Do not omit the fat Capacitor that feeds the fast PWM LEDs.

 

Odd Particle Photon error messages and what they can mean

23 May18

Odd Particle Photon error messages and what they can mean

This post will eventually become a serachable collection of info that I have not found any other place. I usually make my projects based on the P1 module that has an extra 1Mb of Flash built in, but it's the same device as the P0 used in the Photon. If you look inside a P0 and a P1, you'll quickly see the familiarity. It's basically just the extra Flash and the FCC approved PCB antenna that differs.

Errors

"Potentially unhandled rejection [3] Serial problems, please reconnect the device" usually means that you have another serial connection open so you can't get access to the port. Just close this and Particle Setup (and other things that require Serial access) This happens ever so often if you're using the super-neat --follow option that keeps a serial connection open even though the device is restarting.

If you read/write beyond the length of an array, you'll easily see the readed red blink. Another way to achive this is using Serial inside a constructor. It's really hard to flash your device when it keeps crashing, so what if there was a way to get the device online but without running your firmware? Of course there is! Hold down RESET and SETUP buttons. Release the RESET button and when you see the device blink purple, release that button also. The device will now blink green, but when it's connected it won't run the firmware. Instead it will fade purple to show that it's online, but not running your program.

Nice to know!

If you need to clear the wifi settings, just hold down the SETUP button for 10 seconds or more. Instead of slow blue blink, you'll then get a very fast blue blink. This means that wifi setup has been fully cleared.

When you're debugging, it's super annoying to have to restart the Serial monitor all the time. You don't have to! Just use this instead:

particle serial monitor --follow

This will try to find the serial port when the device reconnects (for OTA programming and other things)

Easter funtime with KiCad

06 Apr18

Easter funtime with KiCad

This Easter, my 17 year old son got sick for the last days of the holidays, so we left the mountains were we usually stay. All of a sudden had a couple days of spare time, so I sat down and made two PCB’s that I had been thinking about for a while!

The first is a huge 8x8 LED matrix made with 10mm LED’s. Every year at Westerdals ACT where I tech Embedded Systems, the students have a hard time understanding how these work, so I made a BIG one that I can pass around for them to understand. Each row and column has a switch, so they can easily toggle between GND, 5V and having that line controlled by the onboard ATMega328P. When controlled by the MCU, it’ll scroll a text. By turning a potmeter, the code will run slower and slower so that you eventually see each single line in the Matrix light up. I also added a button just in case I wanted to change the program or so. The parts for it arrived in just two days from Farnell and I orderd the board from PCBWay. It should arrive in about a week. Here's how it looks in the KiCad 3D view:

Persistence Of Vision research

I love how we humans use the slowness of our eyes to display pictures. For a long time I've wanted to make a board where I can use the programmable and tiny APA102 LED's (that Adafruit sell as DotStar) to produce POV imagery. For this board I wanted to try out a lot of things that I haven't had time to play with. I have a Lipo charger so the device can both run and charge from a small battery. The APA-102 RGB LED's require 5V and a single cell LiPo battery is anything from 3.6V to 4.2V, so I needed a Boost converter that only works when the battery has enough voltage. If not, the LiPo battery will drain and eventually it'll puff up and get destroyed. The setup I use should have this covered so that I won't need to disconnect the battery. The Microcontroller I'm using is one of the cheapest STM32's I could find that still has USB support. It's super tiny!

How tiny? Just look at the match I added for scale and the dust between the legs of it! The micro requires 3.3V so I needed to add that to the board & I've also added a Hall sensor and two Phototransistors on the board to input various data. Can't wait to get these boards and start writing the software! :-D

 

Embedding myself in devices

19 Nov17

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.

Rost

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.

OrderX

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. 

Bitraf

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 Nov16

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! http://www.microchip.com/forums/m790211.aspx

// 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
//*****************************************************************************

// FOSC
#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)

// FWDT
#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)

// FBORPOR
#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)

// FICD
#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;
    while(1)
    {
        _LATD3 = 1;
        __delay_ms(1000);
        _LATD3 = 0;
        __delay_ms(1000);
    }
    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
    while(1)
    {
        _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 Sep16

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 http://learn.makeblock.com/mbot-get-started/ 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.

Conclusion

I'll manage to make a good workshop with mBot, but this is DESPITE and not BECAUSE of the quality of the Makeblock 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 Jul16

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!

 

Milling 2-sided PCB’s

08 Jan16

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 http://www.ebay.co.uk/itm/200x-best-quality-pcb-copper-via-vias-through-hole-rivets-ID-0-8mm-OD-1mm-/321930742366?

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 Nov15

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…