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.
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.
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.
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:
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 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.
I’ve been playing with a multislope ADC design. Multislope ADC are often used in high end multimeters, and as I have a mild obsession with 8.5 digit multimeters, I wanted to try making a multislope ADC.
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.
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.
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.