App note: CeraLink® Capacitors


Compact and high capacitance ceramic capacitors from TDK electronics. Link here (PDF)

CeraLink is a family of very compact capacitors for stabilizing voltages in the DC link. They are therefore suitable for use as either snubber or DC link capacitors. These products are based on PLZT ceramics and are designed to provide engineers with compact components optimized for fast switching converters, converters with very tight space requirements and converters that need to withstand high operating temperatures. The basic component is a ceramic chip which either is manufactured with lead frames or which can be combined modularly to form capacitors with higher capacitance values.

Regaining debug access of NXP i.MX RT1064-EVK executing WFI


Erich Styger writes:

Working with low power modes can be challenging. It can severely affect debugging capabilities of a microprocessor or microcontroller. I ported a FreeRTOS application using the Tickless Idle Mode to the NXP i.MX RT1064 board, and all of a sudden, the board was unresponsive to any debugger connection. Luckily the board was not really bricked, but it took me while to find a way to recover it. So for when you end up in a situation with a ‘bricked’ i.MX RT1064 board, this article might be helpful for you to recover it.

More details on MCU on Eclipse blog.

Polar Coaster drawing machine


Barton Dring designed and built a Polar Coaster drawing machine to draw custom, round drink coasters:

I recently decided to update the Polar Coaster project. The primary reason was to update the controller to use Grbl_ESP32 firmware. I also thought I could make it smaller, lighter and remove a little cost.
The old controller was not custom made and just sort of tacked onto the back. This increased the size and didn’t look very good. It had a Bluetooth module, but you still had to stream the gcode. You could use an Android app, but that was still a little awkward.
The controller runs Grbl_ESP32. This was recently updated to include pen machine features. This allows precise control and calibration of the pen servo. You can control the speed, timing and endpoints of the servo travel.

Project info at Buildlog.Net blog.

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:

App note: Linear regulator specifications


Thorough items on a linear regulator datasheet provides valuable details about its proper usage discussed in this App note from ROHM semiconductor. Link here (PDF)

A linear regulator data sheet includes a specifications table that lists output voltage values and precision. Besides, very important information such as maximum ratings, operating conditions and characteristic graphs are described in the table.

App note: Connecting LDOs in parallel


App note from ROHM semiconductor on combining LDOs for higher load capacity. Link here (PDF)

When you want to increase the output current capacity of an LDO, or when the power dissipation of a single LDO is insufficient, you might think of connecting LDOs in parallel if you need to disperse the dissipation using two LDOs. This application note provides some hints on how to connect LDOs in parallel.

BMP180 based USB atmospheric pressure monitor


Dilshan Jayakody published a new build:

We initially developed this USB atmospheric pressure monitor to study some operating characteristics of Bosch BMP180 sensor. BMP180 is low cost sensor to measuring barometric pressure and temperature. According to the data sheet this sensor can use to measure pressure ranging between 300hPa to 1100hPa. This sensor is introduced couple of years back but still it is popular due to lower cost and simplicity of it’s interface.

See the full post on his blog.

App note: Basics and low-cost solution proposals to move from legacy USB2.0 connector to USB Type-C™ connector with STM32 devices


App note from STMicroelectronics about interfacing STM32 legacy USB 2.0 to USB Type-C. Link here (PDF)

This application note is a guideline to introduce this USB Type-C connector onto platform to replace legacy USB2.0 connectors. It introduces some basis of the two new standards USB Type-C™ and the USB Power Delivery.

App note: Quad-SPI (QSPI) interface on STM32 microcontrollers


Extend memories by using external high speed memories interfaced to Quad-SPI modules on STM32 micros, app note from STMicroelectronics. Link here (PDF)

This application note describes the Quad-SPI interface on the STM32 microcontrollers and explains how to use the module to configure, program, and read external Quad-SPI memories. It describes some typical use cases to use Quad-SPI interface based on some software examples from the STM32Cube firmware package and from the STM32F7 application notes.