Archive | January, 2019

Requiem for a Reprap - packing down the BAM printer

18 Jan19

Requiem for a Reprap - packing down the BAM printer

At 4.5 years, this is my longest running personal hardware project. I've learned incredibly much about building machines that "just work" and I've taken the project as long as I feel it makes sense. Since my focus these days are on electronics and IoT hardware, 3D printing is now more of a tool for me. So why swap out a 3D printer that works great already?

After posting this video, I realised that there are a couple things i did not mention that has affected my decision. The major one being that a 3D printer you make yourself can never become complete. It's been my bad concience for a long time as I had so many plans for it, but I'm not prioritizing it over electronics these days. With so many projects I want to do, I had to cut away something and since it's a more or less complete project, I felt it was the time. Swapping it for a Prusa MK3 opens up quite a few new possibilities. The machine also takes a valuable space on my desk, so rebuilding my office to be geared towards electronics did also affect this. I simply won't be using 1/3rd of my desk for the printer any more. I couldn't just pack it down though, so in this video I'm summarising the project and some of lessons I've learned while building it.

I discuss filament diameters and selection (2.85mm or 1.75mm), electronics (Ramps, MegaTronics,  Beaglebone + Replicape), extruder alternatives (Wades, Bulldog XL, E3D Titan Aero), Mechanical challenges (rigidity, Flex3Drive, Lulzbot) and solutions when building robots using Makeblock and what I'm replacing the printer with. This VLOG also marks the start of a new Youtube channel as a place to post video's that are somewhat more "polished" (or at least edited) than what I post on my old (and rather messy) Youtube channel.

BAM project links

Lots of pictures on my Tumblr

Build log from 2014

Blog entry on the original design goals

The BAM wiki page on

Megatronics 2.0 documentation (that I have contributed to)


General PCB design tips

07 Jan19

General PCB design tips

When I made my first PCBs, I had no idea what I was doing. I played around with Fritzing and looking back on those designs, it's a wonder that some of them worked at all. I now make many designs per year and most of my income is from creating electronics and writing the accompanying software for customers. This post sums up all those tiny things I wish I knew when starting out creating my first circuit boards.

PCB layout

Laying out PCBs is something you'll learn as you go along. There’s lots of things you don’t do like placing delicate signals near a switching buck converter or let signals run anywhere without a good ground plane nearby. Learn to use ground planes correctly for both preventing traces from becoming antennas (they do!) and as a way to dissipate heat when needed. Watch video tutorials showing how to design boards from scratch. There’s so many thing that experienced designers know, but only will share as they stumble upon it while designing.

Always read the last pages of datasheets where they suggest PCB copper layouts for that specific chip. These will usually also suggest clever placement and sizing of passives like capacitors and resistors.

Rounded corners

The FR4 glass fiber that PCBs typically are made from are really sharp. You don't need to make many PCBs to understand how clever this is, but you are likely to make sharp corners until the first time you cut your finger or the pocket in your backpack where you put the boards to transport them.

Always add mounting holes

You may not need them initially, but there is seldom any cost to adding them. Use 3mm holes since Nylon studs are easily available for this. Buy the big kit of nylon M3’s, not just a small one. Having these holes on the board makes fixing the board or fixing things to the board so much easier.

Always add a button and a LED

If you use a microcontroller, just do this. You don't need to populate these on the board as long as you added the footprints, but if something does not work as expected these makes debugging so much easier. Most projects will need a status led or button input at some time, so it's just nice to have it on the board.

Always trust the DRC

This feature in any EDA program will tell you the obvious errors in your design. I have never seen it report something incorrectly so I don't ever doubt what it says. If there is an error or unconnected component and it's hard to spot the location on the board, remember that it may be at both ends of that wire. Hunt the error down and never ignore these warnings.

Also - never submit a board without running the Design Rule Check (DRC) before exporting the files. I once managed to send a board off for fabrication without any GND and 5V. If I only used the DRC one last time before submitting, I would have saved both time and money.

Always add test points

If the Microcontroller on your board comes in a small package, it's critical that you add test points. I always add several of these for anything I may want to measure such as analog signals, sensors and voltage. It's so easy to remove them from a design, but it's a massive time saver to just solder up a wire when you need to test something more than once.

Reading datasheets

One of the core things you do when creating PCBs is reading datasheets. Here's a few things I wish that someone told me with regards to just that.

Pin defaults

See a line above or below the RESET pin? It tells how you should tie a pin by default. This is also called Active High. There is also Active Low, but that's less common.


In datasheets you'll often see a resistor marked as RL (lower pos L) and it's never documented what this means. I guess the reason it's not explained is that anyone with an electronics background will learn this at school? RL stands for Resistive Load and it's just there to explain that it represents your Load (what you're driving with your circuit). This can be a LED, motor, microcontroller or whatever, but RL is just something you're expected to know.

What the HEX?

Why do all datasheets obsess with these Hex numbers? Why can't they just use normal numbers? It's a matter of convenience and they're only there because they are easier to use than base-10. It's just not obvious until someone points it out.

A microcontroller is either 8 bit, 16bit or something more. That’s a bunch of one’s and zeros? To set bit 1 of an empty byte (b00000000), you just add 0x1 (b00000001). To set the second bit you add 0x2 and so on: 0x4, 0x8… But notice what happens for the upper 4 bits. You add 0x10, 0x20, 0x40 and 0x80. You can see a practical example in the ADS124S08 class I've published. You can set Bit 6 with 0x20 and bit 7 with 0x40 -> set both by adding them. Very clever when you see how it works out!

What EDA software should you use?

Hard one to answer but I get the question often, so I add my thoughts here. When you're just starting out, it's easiest to use a tool that you know someone using already. That way you have someone to ask as you progress beyond what you can learn from Youtube. If you don't know anyone, just drop by your local Hackerspace or check out the tons of tutorials available on Youtube. Popular choices are KiCad, EasyEDA, Eagle and Fritzing. Fritzing is the ideal choice for beginners, but it's unfortunately it is no longer actively maintained.

I primarily use KiCad and it's become a really good tool. I often find Open Source software to be either command-line based (and good) or half-working with a half-baked UI. KiCad is both well working and has a good UI. This is thanks to CERN supporting the software and making it their tool of choice. If it's good enough for CERN, it's more than good enough for me. KiCad is better than the former versions of Eagle that I have used (more intuitive), but the Fusion360 integration tempts a bit, so I'll likely poke into Eagle in 2019 to test it out.

Expect this article to be expanded over time. Got more good advice? Post it in the comments below!


Persistence of Vision with APA102

05 Jan19

Persistence of Vision with APA102

Back in April 2018 I made a board to play around with a few things I've wanted to learn. I added LiPo charging, a voltage boost circuit and the cheapest STM32 microcontroller I could find that offers USB connectivity. The main idea was to use this to make a Persistance Of Vison (POV) setup to play around with. I only had time to test the first iteration eight months later, but the second iteration is now up and running.

I've only just gotten it working, but it shows great promise already! The first version had several bugs (as expected), but none so critical that they couldn't be worked around. I got the LiPo charging and boost working on first try, but it didn't work just as expected when plugging in USB. To improve on this, I added a switch IC (TPS2113A) that would toggle between USB and battery as needed, but I didn't read the fine print so this circuit started oscillating and failed. I now have a much simpler and completely fool-proof solution to this using a clever MosFet switch. The shape of the first PCB made it hard to spin, so I fixed also that in the second version.

Why NeoPixels can't do POV

I've used ws2811 and ws2812 (often referred to as NeoPixels) programmable LEDs before, but they're not suited for Persistance Of Vision applications since the refresh is too slow.

Incorrect refresh produces a dot pattern

NeoPixels also have a lot of issues since they require very precise timing. This makes it very hard to use them with anything that also requires a wifi connection or anything that could disturb the timing. The APA102 is different. It has a dedicated clock channel that you can run at any speed so it will work with any computer, also Rasberry Pi and other things that can't offer precise timing. This requires an extra pin, but that's a very cheap price to pay to save all the hassle with NeoPixels.

The APA102 is also called DotStar or SuperLed and it comes in two form factors. The most common one is the 5050 (5x5mm) package, but it also comes in a 2020 (2x2 mm) version that offers the same light intensity in a smaller and cheaper package. The refresh rate of these are super-fast so they're well suited for POV applications when done correctly. A big thanks to Tim for his great writeups on all types of programmable LEDs! They've been of great help throughout the years.

POV with APA102-2020

If you're working on an Arduino-like platform, you can probably find a good project to start from. There is however no pre-made library for the STM32F0. I found a good place to start with this code, but the setting of max brightness is done incorrectly here so it won't work. The LED can be dimmed by adjusting the RGB channels, but you also have a power saving feature in the chip that you can set from 0 to 31 (32 steps). For POV, we need the LED to always be on and to do that, we set it to maximum brightness (31). I didn't fully understand how the first lib did this wrong, but after searching Github for apa102 and disregarding platform I found this code doing it right. Re-reading the datasheet I found that you can easily simplify this quite a bit and ignore storing the INIT and GLOBAL bits since these will always be 0xFF and I came up with this simplified solution.

With full brightness, all LEDs show as a continuous line.

The only thing that is STM32 specific here is the sendRaw-method. Replace this with how the platform of your choice does SPI and you can use it with Atmel AVR, Microchip, Parallax or whatever your favorite MCU is. The code will also work with the larger APA-102 LEDs. The Gist displays a beautiful rainbow pattern thanks to the super-smooth color methods used in many of Adafruit's libraries.

Further plans

Next up is displaying text and images, while I wait for the third iteration of the PCB to be fabricated. There's loads of great tools for converting images to C arrays, but I’ll make some custom code for displaying text also. The third iteration will have 100 pixels as well as an accelerometer/gyro combo so it can be used for POI-applications in addition to POV. For now I’m happy with storing data in the microcontroller itself, but I’ll eventually look into adding a simple Bluetooth wireless transfer to a Flash Memory chip so the device can be updated without USB or STLinkV2 programmer.


Getting started with STM32F0

04 Jan19

Getting started with STM32F0

I use the Particle Platform a lot and these have been based on STM32F4 up until the new Mesh radios they just delivered. The STM32 series is massive. There's microcontrollers for every need and budget, so I figured it would be a good learning experience to work with one of the cheapest ones available?

After some looking at datasheets, it looked like the STM32F070F6P6 was a good option for my POV-project. For just a few of these, you pay $1.5 per MCU. If you make something in volume (as in 2500), the price drops to $0.70 and below. If you only need a few pins, such an MCU can be a great budget alternative. It's a full 32bit microcontroller with all peripherals you'll typically need and it has the possibility of programming it via USB. It's cheap but has somewhat limited options and not too many pins.

Getting it up and running

Getting it up was super easy. No external components are required to run at 8Mhz, so you just slap the chip on a board and add pins to program and debug it (SWDIO + SWCLK). You can find a STLink v2 programming adapter on Ebay for less than $2, so this really is an affordable development platform. The drawback of running the chip without a crystal is that the internal RC oscillator is not precise enough that you can use USB. On the second iteration of the board, I added the crystal, but then realised that you need to upload a custom USB bootloader as the chip's don't come with one as stadnard. I still have not figured out how to make this work with my IDE, but I'll get there eventually. Speaking of IDE's for STM32 - I've now tried a few and the development experience is far from the 1-click Arduino installer. They're much more IDE's than the Arduino glorified text editor, but the install process is not as smooth.

      After testing some more it turned out that the STM32F070F6 line cannot use USB along with both I2C, Serial debug and Serial data. It simply does not have the required pins to do it? I can remap some pins to get USB working (PA9/PA10 -> PA11/PA12), but that prevents me from using an I2C based IMU. There is also the “minor issue” that the Virtual Com port driver takes up more than the available RAM in this rather constrained device… To work around this I’ll design the third version of the board based on the STM32F070CBT6. This is a 48 pin chip rather than just 20 pins. The price goes up to $2.26 per chip for 10+ and to $1.15 in volume. Its more expensive, but also offers 4 times the memory (128Kb) and that’ll come in handy to get USB working.

It also turns out that the MPU-6050 Accelerometer and Gyro I wanted to use is $8.31 from Digikey or Farnell? That’s for the IC alone. You can buy assembled MPU-6050 modules with all the required extra parts for $0.70 from Aliexpress. I already have 20 of them from another project, so I’ll just add holes to solder these modules in, rather than place them on the board. Reduces the price of each board and swift to solder in.

Setting up clock speeds and the rest of the hardware was really easy using the graphical tools provided in CubeMX. One of the very nice features of the STM32 family is that all pins can be setup as most anything. Want your analog pins on one side? Sure. Just set them up that way. Want two SPI controllers? Sure - just add them to the ports you want. The STM32F0 family is a little more limited than the STM32F4 that I'm used to, but they're still quite flexible. You can also set this up “by hand”, but using CubeMX to generate a set of files to start from is quite smooth. Just select your IDE, and CubeMX will generate suitable project files and a setup for that IDE. The main file will be full of comments indicating where you should put your code. If you follow this, you can then re-run the CubeMX tool to change pin config at any time without it overwriting your code.

What IDE to use?

The first IDE that I tried out was Atollic TrueSTUDIO for STM32 9.1. For an integrated IDE on Windows, this was rather clumsy to set up. I got it working, but it was far from a one click installer? I had expected it to be more plug and play. For my Mac I setup System Workbench for STM32 from OpenSTM32. Having worked with several Eclipse based tools before, this was easy to setup but it's kind of clumsy that the supplied downloads (both from OpenSTM32 and ST) have to be started from command line. ST supplies what looks like OSX installers, but these fail miserably and they've done so for many years. Given how popular Mac's are with developers, it's surprising that they don't even document this but rather just pretend to have a working solution.

It's also surprising that we still don't have proper 1-click installers for stuff like this in 2019. It's not super hard to install System Workbench with all required dependencies, but it's far from simple for a novice. They do however provide great written documentation to follow.

Both TrueSTUDIO and Workbench works well. You get access to full debug capabilities via stlink + openocd and both IDE's are completely free. Workbench is also Open Source. There's also commercial IDE's out there that support the STM32F0 family such as Keil's MDK-ARM and IAR Systems Embedded Workbench. I don't have $2-5k to drop on testing a platform on my spare time, but if you already have this software it's probably a little smoother to get things up and compiling.

Working with it

STM32's do not come with anything resembling an Arduino API, so it may take a little getting used to doing everything "manually" if you come from a more "managed platform". To turn on an output pin, you do something like this:


To turn it off, it's something like this:


Lot's of CAPS and everything is defined as constants, so having an IDE that has some intellisense to open and inspect is required. It's nowhere near as "verbal" as Arduino's digitalWrite, but its just another way to do things? If you play around with several platforms, you'll soon realise that this is how it works in the MCU-business. Neither Microchip, Atmel, Parallax, STM or any other vendor offer APIs that resemble anything you know already. They all want you to go deep down and toggle registers on the chip rather than use convenient and familiar methods that can gloss over how the chip works.

They do however give you a hardware abstraction layer (HAL). It's not anywhere near as complex as just working with registers, but  it's also not exactly smooth? To use GPIO you first have to enable the pheripheral. Then you use the following commands to set a pin as ouput:

GPIO_InitStruct.Pin = GPIO_PIN_3;
GPIO_InitStruct.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

This is equivalent of Arduino's single line pinMode command. No problem, it's just more work. I'm sure this is MUCH faster, but in general I do not care if something is a little slower if it’s easier to remember. If all the code is Open Source so I can learn from it, that will save me in the very few and narrow cases where I need to save a nanosecond or ten? You could of course just write your own pinMode commands if you think this is how it should be.

I know some ppl that prefer to not use any tools and rather go for the 83 page manual for the specific chip, the 91 page programming manual, the 779 page reference for the familiy of chips or the many hundred of documents detailing how features such as DMA, RTC, PWM will work in detail. If you're one of them - then good for you as you won't need to worry about what to do with your spare time?

I on the other hand think good thing they made CubeMX to type all the config out for you and include HAL files :-)
It’s not what I’m used to, but it does the job well and I don’t mind learning multiple ways to skin a cow.


Xmas cleaning and new workspace

31 Dec18

Xmas cleaning and new workspace

The last couple years I've done less 3D printing and more electronics, so I took the time to redo my home office over christmas. I got a motorised raise/lower desk for my computer and custom built an electronics desk that turned out really well.

Ending my 3D Printer project

My BAM 3D printer has been a great learning project! I've built a really advanced machine that have solved my wish for a large format printer that can print any material I throw at it. It's been super solid and I'm happy with the quality I get out of it, but I keep having bad concience for not doing more updates to it. One major upgrade I've wanted to do is to add a multi-material capability. Due to the design, I'd be limited to just two materials but that would be sufficient in most cases. I have had a hard time prioritizing this over other things, so I guess it's not really something I need - more something that "would be nice" to have.

Since I mostly use the printer for prototypes, it's been annoying that many of the new filaments I've wanted to test only were available as 1.75mm. The 2.85mm standard was based on what was available when Reprap started back in the days. Now it's basically only Ultimaker and Lulzbot that use it apart from Reprap machines like mine, so I took a leap. I sold all my 2.85mm filament and ordered a Prusa MK3. These are rock solid, print beautifully, has official multi-material upgrades and I don't need to do anything to it. I'll do a proper post-project video on the printer before I disassemble it.

Electronics desk

I work from home about 2 out of 5 days in a typical week. The lighting conditions in my home office have not been idea for electronics and I kept needing to clean my desk to do code at daytime after playing with electronics in the eve. A separate desk seemed like the best plan!

IKEA has these really nice 2.48 meter whole wood plates that are ment as kitchen countertops and similar things. They're also a perfect material for builing other things from and I wanted an integrated light that would not disturb others in the room (where our projector and gaming setup is located). By having an overhanging shelf with builtin light, I get:

  • Convenient storage on the shelf above the desk
  • A wall to hang my tools on
  • Lighting that lights the entire desk without coming into my eyes
  • Support poles that I can mount things to (like my electronic microscope)

I used standard office table legs from IKEA so I caould swap this with another raise/lower solution if I wanted it. It also comes wih a decent solution for cables. For the support poles I used 25mm steel tubing that allowed me to complely hide the cabling for the lights. The lights fit into pockets that I made using the CNC @bitraf. The lights are also from IKEA. They're kitchen cabinet lights that work with the Trådfri system that I have in my house, so I can turn it all on/off from an app or Google Home. I added holes in smart places to get a smooth solution to the cable salad I used to have on my desk.

All the tools I use on a regular basis has it's own place and I love having them at hand rather than having to dig for them in a drawer that I used to.

All my electronic parts were also placed at the other side of the room, so moving them closer was another important part of the solution. Just above the soldering station I have a small shelf with core tools such as soldering wire, pump, flux and tweezers. My magnifying desk lamp also fit well in in that corner and can be moved completely out of the way when not in use. On the other side, I have the electronic microscope. After I purchased one of these for Bitraf, I just had to have one at home also. It's such an invaluable tool when you work with surface mount parts that are less than a millimetre squared. The stand that it came with made it impossible to have it permanently on the desk, so integrating it directly into the desk was just brilliant. All that was required to do it was to use the same steel pole diameter that was used for the microscope.

Very happy with the result and as usual, there's more pictures on my Tumblr.



MegaMatrix 1.0

18 Dec18

MegaMatrix 1.0

Back in April I designed two boards just for fun. One was a Persistence Of Vision (POV) board and the other was an educational board for my students to understand how a Matrix display works.

I got the black PCB's quite quickly from PCBWay and got them soldered up. It all worked out as expected and I was able to use it with my students this autumn. It really worked out well. Rather than wondering how it worked, I told the students to come up to me after calss so they could play around with it. The result was much less confusion around how a Matrix works and it looks gorgeous with it’s 8x8 matrix of 10mm LEDs.

The Matrix has switches along the edge that pull each row High or Low. By playing with the switches, the students build an intuitive understanding of how the matrix works and why you never can turn on more than one row at a time. The switched also has a middle position where an onboard ATMEGA328P-AU will control the lines to display a scrolling text. The micro also has a potmeter connected to one of the analog inputs so you can decrease the scroll speed all the way down so you can see single lines lighting up. Since it's always nice to have - I added a button and a LED to it also that can be used for any purpose. The only thing I didn’t think through was adding either a regulator so that it could be battery powered or a USB power input. Will add that if I do another revision. Very happy with how this project turned out - both electronically and for teaching!


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.


"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