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:
This year in March, Massimo Banzi announced on the Arduino blog the production of a new revision (Rev.2) of the Arduino Yun board.
In addition to some improvements on the hardware design, the new revision offers a complete update of the software side of the Yun, that is the Linux distribution (OpenWrt) running on the board. The original Yun was indeed stuck to a distribution released in 2014 (still available in the download section of Arduino website) and that distribution contained outdated software packages which also presented some security vulnerabilites.
Who now buy a new Yun board, has the new OS version pre-installed. If you own a “Rev.1″ board, in this article you’ll learn how to update it…
In the Arduino forum, Martino Facchin (one of the contributors of the OpenWrt porting to Yun) published a post with links to an automatic updater for the different platforms (Windows, Linux, Mac). The application updates both the bootloader and the operating system (rootfs). You have to also update the bootloader because of the new OS requires a bigger partition than the original one.
Before running the updater process, there are 3 prerequisites:
the Yun board must be connected both to your computer via USB and to your home router/switch using an ethernet cable (the update process cannot happen using wifi)
your computer, which runs the updater application, must be connected to the same home network the Yun is connected to
your computer must not run softwares (like firewalls) that could block incoming connections
The third point in particular is the one that can give more problems… for example I use the Eset Internet Securitysuite and I had to temporary disable the protection:
An additional suggestion is to disable other network cards in your computer, keeping active only the one connected to the home network:
If you’re using Windows 10, it may happen that the yun-go-updater.exe program is blocked… in this case you have to cancel the block from the file properties:
If you run the program, the update process should go automatically. When complete, if you connect to the Yun board you should see the new version:
During the update process, the Yun board requests a valid IP address for your network using the DHCP protocol. Sometimes this request could fail; in this case you can assign a static IP to the board answering “n” to the first question:
USB MIDI controllers (such as Launchpad Mini Mk II for example) are common and often quite low in cost.
To interface such a controller with a Eurorack synth system, often a host computer and a MIDI to CV interface might be used. The host computer would take USB MIDI data from the MIDI controller, perhaps store and manipulate that data in some way (e.g. a sequence), using a MIDI to CV converter to then control a Eurorack synth system.
It would be useful to use USB MIDI controllers with Eurorack synth systems without needing a computer and MIDI to CV interface in between the two.
Teensy 3.6 is a great microcontroller that can be programmed using the Arduino IDE. A very useful feature of the Teensy 3.6 is the USB host port.
Rui Santos over at Random Nerd Tutorials wrote a series of three posts on how to use the SerialDebug library created by João Lopes with Arduino IDE (programming Arduino, ESP32, ESP8266):
After programming the ESP32 using ESP-IDF, João noticed that debug for Arduino IDE needed some improvement. So, he created the SerialDebug library to bring better debugging to Arduino IDE. He also created a desktop application called SerialDebugApp that adds a UI and other useful functionalities.
To show you all the useful features of the SerialDebug library and the SerialDebugApp, he created three tutorials dedicated to this subject:
While I loved the Nokia 5110 LCD’s readability in full sun, the pressure sensitivity was a real problem for the underwater units. So I started noodling around with some cheap OLED screens from eBay.
With the exception of the init & XY functions (which are more complicated on the 1306 controller) the rest of the code ported over from the Nokia screen with no changes at all. My guess at this point is that the shift-out method will work with most of the other cheap OLED screens, provided they don’t exceed the pin current limits implied by my method.
Lies, damn lies and statistics.
You have a high school science fair and want to know how your project was perceived by the visitors. Modern online behaviour will direct you to “taking the online survey”. That requires an extra step for the visitors, usually by taking hold of their mobile device and fiddling with a small screen.
One problem you will encounter is designing good computer interaction and a proper look and feel on the tiny screen. It is a lot of work. A second problem is the distraction of using the mobile device with respect to the project being surveyed. The visitor will concentrate on the mobile device and that will diminish focus on the project for a moment. A third problem is anonymity and proliferation of data. Do we really need to be online and spread all that information one’s device sends?