Minimal ATSAMD21 computer


Johnson Davies shared detailed instructions of how to build an ATSAMD21-based computer on a prototyping board using a 32-pin ATSAMD21E:

If you’re looking for something more powerful than the ATmega328 in the Arduino Uno a good choice is the ATSAMD21. This is an ARM Cortex M0+ processor with up to 256KB flash memory, 32KB RAM, and a 48MHz clock, so it’s substantially better equipped than the ATmega328. In addition it has a USB interface built in, so there’s no need for a separate chip to interface to the serial port.
Arduino have designed several excellent boards based on the ATSAMD21, such as the Arduino Zero or smaller-format MKRZERO. However, these boards are an expensive way to use an ATSAMD21 as the basis for your own project, and they probably include many features you don’t need.

More details on Technoblogy.

Arduino interface for TFA9842AJ power amplifier


Dilshan Jayakody writes, “I tested a couple of TFA9842AJ based amplifiers in the last couple of years. The main reason I liked TFA9842AJ is its simple, clean design, wide operating voltage, and high-quality bass-rich audio output.  Thanks to it’s built-in DC volume control circuit this audio amplifier can easily interface with MCU. In this article, we provide a generic TFA9842AJ module which works with most of Arduino boards, MCUs and SOCs.”

See the full post in his blog.

Arduino Shield for CAT M1 and NB-IoT modems


Michael Krumpus designed and built an Arduino shield for Nimbelink Skywire CAT M1 and NB-IoT modems, that is available on Github:

Nimbelink has a development kit for use by product developers, but it’s rather expensive. I wanted to try out a Nimbelink CAT M1 modem without the dev kit, and since there are so many hobbyists using Arduinos out there, I wanted to provide a nice Arduino library for the modem. I chose the Nimbelink module based on the Sequans Monarch CAT M1 modem and got to work designing an Arduino shield to hold it.

More details on Nootropic design Project Lab site.

An Arduino version of Brooks Shera’s GPSDO


Jeff (aka K6JCA) has a great write-up on implementing the Brooks Shera Phase-Locked Loop GPSDO on an Arduino Platform:

This blog post is a continuation of my two earlier GPSDO blog posts. The first one (from a few years back) details a simple Frequency-Locked Loop GPSDO design, based around an Arduino processor. The second (more recent) blog post discusses simulating Brooks Shera’s GPSDO algorithm (from the July, 1998 issue of QST) using The MathWorks Simulink program.
This third blog posts describes my modification of my original Frequency-Locked Loop (FLL) GPSDO to be a Phase-Locked Loop (PLL) GPSDO, and it includes the hardware schematics, Simulink models, and the Arduino code I wrote to implement Brooks Shera’s GSPDO algorithm on an Arduino processor.

More details on K6JCA blog.

Irrighino and Yun Rev.2

Irrighino has been one of my most appreciated projects: it’s a automatic irrigation system – based on Arduino Yun – with a web-based interface, optimized for smartphones.

After having published the project on this blog, it was reviewed by Open Electronics and a dedicated shield was also produced. The shield is still sold on Futurashop:


When it was launched the new Arduino Yun (named Rev.2) and the Yun Shield, the Linux distribution running on the board, OpenWrt, was updated as well. In particular, a key component for Irrighino has been replaced with its newer version, the php engine.

If you own a “first generation” Arduino Yun and you’d like to test the new functionalities shipped with Rev.2, in this post I explain how you can update the operating system of your board!

The commands you have to issue on your Yun to install all the required components for Irrighino now are:

install php with cgi and cli

opkg install php7 php7-cgi php7-cli

install curl, json and sqlite modules

opkg install php7-mod-curl php7-mod-json php7-mod-pdo php7-mod-pdo-sqlite

install zoneinfo

opkg install zoneinfo-core zoneinfo-europe

(replace zoneinfo-europe with the one related to your continent)

Final step is to configure the uhttpd webserver to run the php engine.

Edit the /etc/config/uhttpd file adding the following line (pay attention to its position!):


then restart the webserver with:


Now the Yun is ready to run Irrighino!

Pro mini logger project for the classroom


Edward Mallon writes:

Dr. Beddow’s instrumentation class has been building the 2016 version of the Cave Pearl datalogger for more than three years, and feedback from that experience motivated a redesign to accommodate a wider range of student projects while staying within the time constraints of a typical lab-time schedule. The rugged PVC housing from the older build has been replaced with an inexpensive pre-made box more suitable for “light duty” classroom deployment. The tutorial includes a full set of youTube videos to explain the assembly. We hope this simplified build supports other STEM educators who want to add Arduino-based experiments to their own portfolio of activities that develop programming and “maker” skills.

Via the comments.  More details on Underwater Arduino Data Loggers blog.

DIY Arduino based RC transmitter



Dejan over at HowToMechatronics posted a detailed how-to on building DIY Arduino RC transmitter:

Now I can wirelessly control any Arduino project with just some small adjustments at the receiver side. This transmitter can be also used as any commercial RC transmitter for controlling RC toys, cars, drones and so on. For that purpose it just needs a simple Arduino receiver which then generates the appropriate signals for controlling those commercial RC devices. I will explain how everything works in this video through few examples of controlling an Arduino robot car, controlling the Arduino Ant Robot from my previous video and controlling a brushless DC motor using an ESC and some servo motors.

More details on HowToMechatronics’ project page.

Check out the video after the break.

DCC, configure the decoder with CVs

In my previous tutorial I explained how to build a simple DCC accessory decoder with Arduino.

To keep the sketch simple, all the configuration parameters for the decoder (in particular its address) were defined as constants:

dcc-cv-001Often it can be useful to change the configuration of the decoder without re-programming its firmware (= the sketch that runs on the ATMega microcontroller). The DCC standard includes a document (S-9.2.2 DCC Configuration Variables) that introduces – for the decoders – the idea of Configuration Variables (CV).

CVs are parameters, stored in a non-volatile way (it means that the values are kept also when the power is off) in the decoders, which can define the behavior of the decoder itself.

NMRA defines, in the same S-9.2.2 document, a list of CVs – numbered from 1 to 1024 – and a meaning for each of them. For example, for an accessory decoder it is established that its address (9 bits) is contained in CV513 and 521:


When you buy a commercial decoder, in the manual it is always given a table that indicates, for each supported CV, the meaning. For example, the manual of the ESU SwitchPilot Servo decoder, a decoder able to command servos to activate turnouts or other movements, lists the CVs that control position and speed of the 4 servos:


Many digital stations support the service mode (document S-9.2.3), that is, they are able to program the values of the CVs of a decoder connected to a particular output, called the programming track. The model maker can therefore adjust the behavior of the decoders installed in the locomotives or that control accessories simply positioning the locomotives (or connecting the accessory decoders) on the programming track and programming the correct values in the CVs.

CV1 vs CV513

The NMRA standard provides that the CVs that can be used by accessory decoders are those from 513 to 1024. In fact, many manufacturers, in order not to create confusion or differences between the different types of decoders, have decided to use “low” CV numbers for accessory decoders. This is the reason why many accessory decoders use CVs 1 and 9 to configure their address.


Once you have learned the meaning of the CVs, let’s see how to manage their programming in our sketch.

We have to store the CV values in a memory that is not erased every time we turn off the decoder. The ATMega328 processor used by the Arduino Uno has a non-volatile memory of 1024 bytes and, thanks to the Arduino’s EEPROM library, we can store and read values from this memory.

The NmraDcc library can independently manage the CVs or – alternatively – leave it completely to the external program.

For example, in the case of writing a CV (the command station that writes the value of a CV in the decoder), the NmraDcc library offers two callback functions:

  • extern uint8_t notifyCVWrite( uint16_t CV, uint8_t Value);
  • extern void notifyCVChange( uint16_t CV, uint8_t Value);

The first substitutes the standard CV handling of the library, while the second one is called to notify that a CV changed its value. If you inspect the source code of the library, the difference is clear:


The library also defines the numbers of some standard CVs, including those related to the decoder address:


LED decoder

Let’s go back to the sketch of the LED decoder of the previous tutorial and add the CV management.

Define two CVs:

  • the working mode (CV10)
  • the blink frequency (CV11)

Thanks to CV10 it will be possible to choose whether the activated LED will be stready on (CV value = 0) or blinking (CV value = 1). In this second case, the blink frequency will be configured via the CV11 (from value 1 = 5 seconds to value 100 = 50ms).

First, let’s define a constant for each CV and its number:


You also need some variables that will contain the runtime value for those CVs to avoid continuously reading the EEPROM (which, according to the datasheet, has a life cycle of about 100,000 reads/writes):

int decoderMode;
int blinkFrequency;

In the setup() method, you have to read the values of the CVs from the EEPROM and store them in the variables:


Let the library handle the CVs. To be informed about when a value changes and update the variables accordingly, implement the notifyCVChange() method:

void notifyCVChange(uint16_t CV, uint8_t Value) {
  if(CV == CV_ACCESSORY_DECODER_MODE) decoderMode = Value;
  else if(CV == CV_ACCESSORY_DECODER_BLINK_FREQ) blinkFrequency = Value;


To make the led blink, you can use the Timer1 library which allows to trigger a callback function periodically:

This callback function simply changes the led status:

void blinkLED() {
  digitalWrite(ledActive, !digitalRead(ledActive));

If the decoder is in blink mode, when the output status is changed, the active led is identified and the callback function is scheduled according to the frequency configured in the appropriate CV. Otherwise the led is simply switched on:

if(outputInPair == 0) {      
  digitalWrite(GREEN_LED_PIN, LOW);
  ledActive = RED_LED_PIN;
} else {
  digitalWrite(RED_LED_PIN, LOW);
  ledActive = GREEN_LED_PIN;    
if(decoderMode == 1) {
  Timer1.setPeriod(5000000 / blinkFrequency);
else digitalWrite(ledActive, HIGH);

lettura CV

The DCC standard also includes the possibility – for a command station – to read the value of a CV of a decoder connected to the programming track. In a next article you’ll learn how to implement this feature!


Here’s a video that shows how it is possible to modify the behavior of the led decoder programming its CVs using a laptop that runs the Rocrail application connected to a SPROG command station: