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.
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.”
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.
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.
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:
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.
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.
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:
Often 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:
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:
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:
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:
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: