As the RAK11300 did not really match my requirements (it uses way too much energy), I looked further and found the RAK3172 which is based on an STM32WLE5CCU6 - an STM32 chip which usually include good powersaving modes. As with the RAK11300, I did not want to go down the Wisblock way and designed my own breakout board:
This was actually not complicated as the RAK3172 has all needed components on board. I just added an H7333 LDO for powering it from 18650 cells and two additional features: First, the i2c port was aligned with the pinout the the usual BME280 breakouts from your typical websources - so that I could directly plug those in. Secondly, I made a solderbridge that allowed this i2c port to be 3v3 powered either directly by the LDO or by an port of the STM32. The later option I actually now use in normal operations, as this allows the system to really cut the BME280 from power so that it does not drain energy while the setup is in sleep mode / not actively measuring.
As core I wanted to go with the stm32duino Core as it already had the STM32WLE5CC supported. The only thing missing was the fact that I actually bought the TCXO enabled 3172T variant and this was not yet supported - and so I got my first PR on the stm32duino repo.
For the radio library I was thinking about chosing the RadioLib again and made a lot of research already on how to get it implemented, but at that time, RadioLib was working around their LoRaWAN implementation quite a lot - and shooting for a moving target was getting my nowhere, so I tried out STMs own implementation.
This did work out quite well, however, there is to this day a bug with the timers which prevents the chip from ever waking up again - a workaround for it is given in the issue in case you want to try it too ( calling rtc.begin(true) after modem.begin() makes it work! ).
I also had an additional issue, I left the RAK3172T sleep usually for 10 minutes, wake up, do a measurement and transmitting it back - then go to sleep again. This worked in my testing until 28 "wake-ups" - then on the next sleep, the chip would never wake up again. I am not sure what is causing this, but I went down the road of just counting the wake-ups and restarting the chip after the 24 or so, just to have a safe margin. Again, this was not a project I spend too much time with, I just wanted something to replace my breadboard wired mess of two CubeCell HTCC-AB01 - which absolutly did not stay unchanged in place since a short test back in 2021 and were working like this ever since (and suffering from disconnect whenever looked at from a wrong direction ;))
So - yeah, if I were to have time I would probably look and test RadioLib support.
The Turing Pi 2 (v.2.4) has actually some secrets that just start to get uncovered. Looking closely at the board, you will find the red marked area with what seems to be an unpopulated 4-pin fan header (J16) and an unpopulated IC spot (U109).
These spots were, as found out by Sam Edwards (CFSworks) actually a place to install Molex 47053-1000 4-pin fan connector and a Microchip EMC2301 fan controller. It is not clear why they were left out of the production model, probably for cost savings, but without that the Turing Pi 2 lost a nice smooth fan controller. However, thanks to Sam Edwards work, the chip is now supported by the Turing Pi 2 BMC, so that after retrofitting, this will just work out of the box!
To do this little hack you just need to order an Microchip EMC2301 in its MSOP-8 / standard packaging. If you don't find the specific molex conenctor its also fine if you "just" use an male 2.54mm header pin. Yes, you will not have the locking feature of that connector and you will need to watch out for the correct orientation when plugging in fans - but it still works in a pinch.
When soldering I would advise to solder the EMC2301 first onto its spot, the orientation is as shown in the second picture. Afterwards you can solder the fan header.
Make sure the circle matches up as shown so that you got the chip in the correct orientation.
After the installation, update your Turing Pi 2 BMC to the latest firmware 2.0.5. Please make sure to read the comments on the repo, if you're updating from a BMC version < 2.0.0 you will need to make a first flash via a Micro SD card to get to version 2.0.0 and update further afterwards.
When everything is done and you log into your Turing Pi 2 BMC, you will see this nice slider to set the speed of your EMC2301 connected fan.
Currently there are still some things up for debate and configuration with the latest kernel release which changed naming of components but overall its already working and a nice and easy mod to get a better fan controller installed - instead of just the "on/off" as soon as one Turing node gets activated - or all deactivated.
Again, thanks a lot to Sam Edwards who had the idea and came towards with the PRs and implementation - thank you! 🙂
The Turing RK1 is a new Compute Module, made for the Turing Pi 2 board and with compability to the Nvidia Jetson cards in mind. While the board has some impressive specs ( https://docs.turingpi.com/docs/turing-rk1-specs-and-io-ports ) it had one small issue: The used Rockchip RK3588 needed a bootloader on its eMMC to be able to boot from an attached NVMe drive. As no isolated bootloader was available, most people flashed a whole OS onto the eMMC - just to be able to use the attched NVMe drive. This process can take quite a while via the Turing Pi 2 board ( e.g. 60 - 90 minutes: https://docs.turingpi.com/docs/turing-rk1-flashing-os ) it was never a good option.
Open it with an archive utility and extract the following files into your working directory:
a. idbloader.img
b. u-boot.itb
Create an .img file we’ll use later to flash the RK1: touch turing-rk1-uboot-only.img
You should now have the idbloader.img, u-boot.itb, and turing-rk1-uboot-only.img in your working directory. From there, use dd to create our combined image:
a. dd if=idbloader.img of=turing-rk1-uboot-only.img bs=512 seek=64
b. dd if=u-boot.itb of=turing-rk1-uboot-only.img bs=512 seek=16384
The resulting .img file can be used to flash the RK1 device through the Web UI or tpi utility.
Once generated, this .img can be used "as is" to flash the other nodes after moving them to NVME.
With that generated file you can directly flash the eMMC and use any NVMe to boot from.
After that, the RK1 will be able to directly boot from an NVMe, given the fact a suitable ARM64 image has been installed on it.
And to install the operating system image onto the NVMe, you can use balenaEtcher with e.g. your Linux, Mac or Windows computer and an USB to NVMe adapter. But please be careful not accidently overwrite one of your interal disks and ruin your computer - I don't take any responsibilty, just in case.
In April 2023 I finally got my Turing Pi 2 - happy to finally got it into my hands I plugged it in, headed over to the Turing Pi 2 Github ( https://github.com/turing-machines/BMC-Firmware ) got myself the latest BMC firmware and started to flash it. Thats when things got wrong: The power supply coils started to screech - and seconds later I was greeted with blue smoke and a dead Turing Pi 2. The firmware update actually flashed the board into a paper weight.
The one green led was still on, the BMC led was off and the board did not react - also the networking LEDs were off. To be honest, this was the first time a firmware update actually physically bricked hardware / got it up into smoke.
Luckily, Turing Machines, the company behind Turing Pi 2 did send me another board, thinking that the (also ordered at Turing Machines) small form factor power supply could have been the culprit - thanks a lot guys for that tremendous help!
The new board was working without an issue and did wait for quite some time until I updated it - horrified the same thing could happen again. I think I updated it to 1.1.0 and things were ok back then.
However, with half a year passed and still the dead board lying around I thought, maybe I could fix it?
The incident
What happened was a short circuit - but how? The only thing I could think of was an error in the firmware upgrade - and the BMC processor - a dual core Allwinner T113-S3 - shortcircuiting something as it did not have its initialization correctly. While this should never be possible (e.g. that a board is layouted in such a way that a processor would short-circuit if it has no program available), I had no other explanation. But how to find out what was broken? The incident actually burned the 5A SMD fuse for the 3v3 line - meaning the board was now powering up ok-ish, but without any of the 3v3 components (e.g. the BMC). Short-circuiting the fuse directly lead to warmth and a bad stench - something was still short-circuiting. So I build myself a Thermal Camera. I was quite sure that the T113-S3 was toast by now, so I removed it.
After that, I tried bridging the blown fuse again - this time with an ampere meter. About 6 Watts were going somewhere I did not know. The Thermal Camera showcased an SMD capacitor glowing red - that poor thing got mangled so badly that it decided to become conductive for DC - not good. I removed that capacitor as well - no excess power was drawn anymore after that.
The repair
I ordered two new Allwinner T113-S3 ( T113-S3 ELQFP-128, position 2 on the picture below ) as well as some spare 5A SMD fuses ( LF5A - 10PCS/LOT 1808 SMD fuse 125V fast 5A, position 1 on the picture below ) from the web. The capacitor with 570uF was replaced by a 12.2uF for testing ( position 3 on the picture below).
As soon as I had everything in place, I got the latest firmware image, 2.0.5 from the Turing Pi Website ( https://firmware.turingpi.com/turing-pi2/v2.0.5/tp2-firmware-sdcard-v2.0.5.img ). I flashed it onto a MicroSD Card with balenaEtcher and inserted the MicroSD Card into the appropriate slot on the backside of the Turing Pi 2. With everything in place, I hooked everything up, got myself a flathead screwdriver and shortend the MOSI and SCLK/Clock lines of the flash module on-board of the Turing Pi 2 as mentioned in this issue ticket: https://github.com/turing-machines/BMC-Firmware/issues/134 ( see position 4 in green, the left bottom two legs of the chip ). You can also see the both legs better on the picture below:
With my screwdriver still shorting both legs of the flash module, I applied power to the Turing Pi 2. After some seconds, the LEDs came on and the 4 LEDs of the ethernet ports started blinking slowly. I removed the short-circuit on the flash module, pressed KEY1 3 times rapidly and the ethernet ports started turning on one LED at a time. After about 30 seconds, the LEDs stopped the animation and all LEDs blinked twice (again and again) to show the flash was a success. I powered down the Turing Pi 2, removed the MicroSD card and powered it up again - and it was fixed! 🙂
( Usual procedure for update from a MicroSD Card can be found here: https://docs.turingpi.com/docs/turing-pi2-bmc-v1x-to-v2x )
Good ending
With that, the Turing Pi 2 was fixed - BMC is answering my calls, all four nodes are working. It was not an easy fix by all means, but using a microscope, loads of flux and patience made it work again. And the Thermal Camera! That less than 40 Euro thing really helped a lot, otherwise I would have not found the issue without turning the whole board into a burning mess.
Thermal Cameras are neat tools, especially in electronics: You can quickly diagnose short circuits, identify misbehaving components or quantify if subsystems get too hot. However, thermal cameras are still a luxury item which can quickly costs hunderds of euros. Sometimes - however - you do not need the accurarcy of a FLIR or similar system, somtimes its just enough to see which part of a PCB is heating up quicker than others. Enter MLX90640: A 32x24 pixel sensor in two different FoVs, exposing its data via i2c. These sensors can be had on different websites for as low as 25 euros during sale.
Components/BoM
1x MLX90640 Thermal Sensor
1x Waveshare RP2040 Zero
1x HT7333 LDO
2x SMD Capacitor 10 uF
2x SMD Resistor 2.2k Ohm
All in all about 30 Euros
Schematic
Nothing really surprising - a HT7333 with some filter caps to allow for a clean power source, two pull-up resistors to allow for the high-speed, 1 MHz communication via the i2c bus. Keep the i2c wires between RP2040 Zero and the sensor as short as possible and pull-up the i2c SDA/SCL lines directly at the sensor.
Operation modes
There are two operation modes here, you can either choose to use the sensor with the Adafruit and Sparkfun example, which will just write a (very long) ASCII line consiting of 768 comma seperated float values per frame, delimited by \n. This will also work with a Processing example to showcase the picture (about 4 FPS).
The alternative to that, would be using another approach, packing the 768 temperature values not in a data intensive ASCII line, but send them via SLIP protocol to the computer. The processing example is not available for that, but I got some other Python code in the making (about 7.5 FPS).
Serial
Firmware (Serial)
Programmed via Arduino using the Arduino-Pico framework, using the Adafruit_MLX90640 library ( https://github.com/adafruit/Adafruit_MLX90640 ) - please be aware that 1 MHz I2C operations and mlx.setRefreshRate(MLX90640_32_HZ) will only work with extremely short wires!
#include
Adafruit_MLX90640 mlx;
float frame[32*24]; // buffer for full frame of temperatures
// uncomment *one* of the below
#define PRINT_TEMPERATURES
//#define PRINT_ASCIIART
void setup() {
while (!Serial) delay(10);
Serial.begin(115200);
delay(100);
//Serial.println("Adafruit MLX90640 Simple Test");
if (! mlx.begin(MLX90640_I2CADDR_DEFAULT, &Wire)) {
Serial.println("MLX90640 not found!");
while (1) delay(10);
}
/*
Serial.println("Found Adafruit MLX90640");
Serial.print("Serial number: ");
Serial.print(mlx.serialNumber[0], HEX);
Serial.print(mlx.serialNumber[1], HEX);
Serial.println(mlx.serialNumber[2], HEX);
*/
//mlx.setMode(MLX90640_INTERLEAVED);
mlx.setMode(MLX90640_CHESS);
/*
Serial.print("Current mode: ");
if (mlx.getMode() == MLX90640_CHESS) {
Serial.println("Chess");
} else {
Serial.println("Interleave");
}
*/
// mlx.setResolution(MLX90640_ADC_18BIT); //default
mlx.setResolution(MLX90640_ADC_19BIT);
/*Serial.print("Current resolution: ");
mlx90640_resolution_t res = mlx.getResolution();
switch (res) {
case MLX90640_ADC_16BIT: Serial.println("16 bit"); break;
case MLX90640_ADC_17BIT: Serial.println("17 bit"); break;
case MLX90640_ADC_18BIT: Serial.println("18 bit"); break;
case MLX90640_ADC_19BIT: Serial.println("19 bit"); break;
}
*/
//mlx.setRefreshRate(MLX90640_2_HZ);
//mlx.setRefreshRate(MLX90640_8_HZ);
mlx.setRefreshRate(MLX90640_32_HZ);
/*Serial.print("Current frame rate: ");
mlx90640_refreshrate_t rate = mlx.getRefreshRate();
switch (rate) {
case MLX90640_0_5_HZ: Serial.println("0.5 Hz"); break;
case MLX90640_1_HZ: Serial.println("1 Hz"); break;
case MLX90640_2_HZ: Serial.println("2 Hz"); break;
case MLX90640_4_HZ: Serial.println("4 Hz"); break;
case MLX90640_8_HZ: Serial.println("8 Hz"); break;
case MLX90640_16_HZ: Serial.println("16 Hz"); break;
case MLX90640_32_HZ: Serial.println("32 Hz"); break;
case MLX90640_64_HZ: Serial.println("64 Hz"); break;
}
*/
//Wire.setClock(400000); // max 1 MHz
Wire.setClock(1000000); // max 1 MHz
// Wire.setClock(3400000); // max 1 MHz
}
void loop() {
//delay(500);
if (mlx.getFrame(frame) != 0) {
//Serial.println("Failed");
return;
}
//Serial.println();
//Serial.println();
for (uint8_t h=0; h<24; h++) {
for (uint8_t w=0; w<32; w++) {
float t = frame[h*32 + w];
#ifdef PRINT_TEMPERATURES
Serial.print(t, 1);
Serial.print(",");
#endif
#ifdef PRINT_ASCIIART
char c = '&';
if (t < 20) c = ' ';
else if (t < 23) c = '.';
else if (t < 25) c = '-';
else if (t < 27) c = '*';
else if (t < 29) c = '+';
else if (t < 31) c = 'x';
else if (t < 33) c = '%';
else if (t < 35) c = '#';
else if (t < 37) c = 'X';
Serial.print(c);
#endif
}
//Serial.println();
}
Serial.println();
//Serial.write('\n'); //10
}
import serial
import re
ser = serial.Serial('COM12', 115200, timeout=2)
while True:
line = ser.readline().decode('ascii') # read a '\n' terminated line
thermalData = re.split('\,', line[:-3]) # last ,\n needs to go!
print(thermalData)
SLIP
Firmware (SLIP)
Programmed via Arduino using the Arduino-Pico framework, using the Adafruit_MLX90640 library ( https://github.com/adafruit/Adafruit_MLX90640 ) as well as PacketSerial ( https://github.com/bakercp/PacketSerial ) - please be aware that 1 MHz I2C operations and mlx.setRefreshRate(MLX90640_32_HZ) will only work with extremely short wires!
#include
SLIPPacketSerial packetSerial;
#include
Adafruit_MLX90640 mlx;
float frame[32*24]; // buffer for full frame of temperatures
void setup() {
while (!Serial) delay(10);
Serial.begin(460800);
Serial.setTimeout(100);
packetSerial.setStream(&Serial);
delay(100);
if (! mlx.begin(MLX90640_I2CADDR_DEFAULT, &Wire)) {
//Serial.println("MLX90640 not found!");
while (1) delay(10);
}
/*
Serial.println("Found Adafruit MLX90640");
Serial.print("Serial number: ");
Serial.print(mlx.serialNumber[0], HEX);
Serial.print(mlx.serialNumber[1], HEX);
Serial.println(mlx.serialNumber[2], HEX);
*/
//mlx.setMode(MLX90640_INTERLEAVED);
mlx.setMode(MLX90640_CHESS);
// mlx.setResolution(MLX90640_ADC_18BIT); //default
mlx.setResolution(MLX90640_ADC_19BIT);
//mlx.setRefreshRate(MLX90640_2_HZ);
//mlx.setRefreshRate(MLX90640_8_HZ);
mlx.setRefreshRate(MLX90640_32_HZ);
//Wire.setClock(400000);
Wire.setClock(1000000); // max 1 MHz
}
void loop() {
packetSerial.update();
if (mlx.getFrame(frame) != 0) {
//Serial.println("Failed");
return;
} else {
packetSerial.send((uint8_t*)&frame, sizeof(frame));
}
}
Software (SLIP)
Using Python 3.x, pyserial and sliplib, giving back a list of thermal readings which can then be drawn into pictures
import serial
import sliplib
import time
import struct
ser = serial.Serial('COM12', 115200, timeout=2)
while True:
bytesToRead = ser.inWaiting()
if (bytesToRead!=0):
readData = ser.read(bytesToRead)
decodedData = sliplib.decode(readData)
if decodedData != b'':
thermalData = []
for i in range(0, len(decodedData), 4):
thermalData.append(struct.unpack('f', decodedData[i:i+4])[0])
print(thermalData)
# ca. 7.41 Frames raw
else:
time.sleep(0.07)
Finishing up
After connecting everything, I finished the build up by printing a small PLA housing and even printed a TPU cap for the lense itself, so that (via friction fit) the sensor could be just thrown into the toolbox and still would be protected from dust and other issues. Could the finish be gotten more pretty? Yes. Did this hinder its function? Not at all, it already helped me fix up a defective turingPi2 🙂 (maybe something for the next post).
Optimisation
As usual in engineering, some problems can be solved by throwing money at them. In this case, a Teensy 4.x as a processor could significantly increase the data throughput. However, I did not want to pair a 40 Euro MCU with a 25 Euro Sensor - be it for costs and footprints sake - and opted in for the 2.5 Euro RP2040 Zero. Still, performance can be improved over my first optimisation using SLIP - by just using the second core of the RP2040. Ideally you would multi-thread the application, having the first core always retriving new data, while the second core packs it into SLIP packets and sends them on their way. This should be fairly easy and might result in more fps :).
I just released my latest project, a CCSDS reassembler running on an NXP i.MX RT1060 in RT-Thread OS. You can find it on Github: https://github.com/nmaas87/CCSDS-TM-FSM
The folks over at RT-Thread decided to make a IOT-Contest using hardware from different vendors and their RT-Thread OS. I was luckily enough to get chosen for a networking project with the NXP i.MX RT1060 EVKB, so I decided to document my journey first getting started with RT-Thread. Here we go! 🙂
Getting started
First of all, its important to know that there are two version of the MIMXRT1060 - the EVK and the EVKB. The EVK seems to be an older version which also includes a Camera sensor module, the EVKB version the recent one. RT-Threads example on Github is for the EVK version, which means things like User LED blinking does not work out of the box, but we will take care of this later.
NXP i.MX RT1060 EVKB files and documentation
You'll need to create a free user account on NXPs webpage to download the User manual and Schematic, otherwise the last two links will not work.
Clone the repo ( git clone https://github.com/RT-Thread/rt-thread.git ) to your system, (e.g. to D:\RT-ThreadGithub)
First project
Start RT-Thread Studio
File -> Import -> RT-Thread Bsp Project into Workspace
Bsp Location (within the Github Repo): D:\RT-ThreadGithub\rt-thread\bsp\imxrt\imxrt1060-nxp-evk
Project Name: What you want, I choose blinky
Chip Name: MIMXRT1060
Debugger: DAP-LINK
click finish
This will lead to an error, pointing you to the workspace folder ( e.g. mine is D:\RT-ThreadStudio\workspace.metadata ) where a .log file resides. Open it up and scroll to the end. At this time in the development, there seems to be an error with the initial compilation shown with this error: "!MESSAGE D:\RT-ThreadGithub\rt-thread\bsp\imxrt\imxrt1060-nxp-evk>scons --dist-ide --project-path=D:\RT-ThreadStudio\workspace/blinky --project-name=blinky"``. To fix this issue, navigate with the windows explorer to the folder ``D:\RT-ThreadGithub\rt-thread\bsp\imxrt\imxrt1060-nxp-evk``. Within the folder, hold shift and right-click and choose ``ConEmu Here`` - the envTools will open up. Just copy and paste the complete scons command (``scons --dist-ide --project-path=D:\RT-ThreadStudio\workspace/blinky --project-name=blinky) into the envTools window and press enter. It should compile now.
After this step, click finish in the still open import menu in RT-Thread Studio again, it should work now and generate the new project.
Navigate within Project Explorer through the Projectname to applications\ and open the main.c file.
Replace
/* defined the LED pin: GPIO1_IO9 */
#define LED0_PIN GET_PIN(1, 9)
int main(void)
{
#ifndef PHY_USING_KSZ8081
/* set LED0 pin mode to output */
rt_pin_mode(LED0_PIN, PIN_MODE_OUTPUT);
while (1)
{
rt_pin_write(LED0_PIN, PIN_HIGH);
rt_thread_mdelay(500);
rt_pin_write(LED0_PIN, PIN_LOW);
rt_thread_mdelay(500);
}
#endif
}
with
/* defined the LED pin: GPIO1_IO8 */
#define LED0_PIN GET_PIN(1, 8)
int main(void)
{
#ifndef PHY_USING_KSZ8081
/* set LED0 pin mode to output */
rt_pin_mode(LED0_PIN, PIN_MODE_OUTPUT);
while (1)
{
rt_pin_write(LED0_PIN, PIN_HIGH);
rt_thread_mdelay(500);
rt_pin_write(LED0_PIN, PIN_LOW);
rt_thread_mdelay(500);
}
#endif
}
and save the file. The User LED on the EVKB board is not on IO PIN 9, but 8. Also, this pin is shared with the ethernet controller - so if we enable this later, the User LED will not work anymore.
Click on the hammer icon ("Build 'Debug'") and it should compile the new software.
Click on the downward green arrow ("Flash Download") to download the program to the hardware board. The User LED should now be flashing.
There can be multiple issues at Download:
A window with "J-Link Emulator selection" pops up and asks for connection methods. This error means that RT-Thread Studio tries to program via Segger Link, which is the incorrect flash tool for the EVKB. If this comes up, please click no on the J-Link screen. Then check on the little black arrow attached to the Flash Download icon, that "DAP-LINK" is checked. Afterwards try Downloading again.
"pyocd.core.exceptions.TargetSupportError: Target type 'mimxrt1060' not recognized." If this error arises it can mean two things:
You did not enter the Chip Name correctly. Please check that the error is really mimxrt1060 - and no spelling issues are there. If there are, go to the Cogwheel Icon ("Debug configuration"), Debugger tab and correct the Chip Name within the Device name area. Click Ok to save and try again.
Scroll up through the error list and you might see the path of the pyocd software, e.g. RealThread\PyOCD\0.1.3 - this would mean you're running the default PyOCD 0.1.3 - which has some errors that will mean you cannot download to flash. Directly next to the "Flash Download" icon is the "SDK Manager", open it up and scroll down to the "Debugger_Support_Packages", "PyOCD". Choose the latest version (e.g. 0.2.0) and click on "Install packages". You can then select the old version(s) you have installed and click on "Delete packages". Afterwards close the SDK Manager. This should fix the issue.
If there are no issues with the Download, can you also "Open a Terminal" (computer screen icon close to "Flash Download"). And start with the correct settings (e.g. 115200 BAUD and the correct Serial port, should be chosen automatically if you already flashed a program before). You should see the RT msh console running on your EVKB and be able to send a "help" to get an overview over the device
\ | /
- RT - Thread Operating System
/ | \ 5.0.1 build May 28 2023 14:25:59
2006 - 2022 Copyright by RT-Thread team
msh >help
RT-Thread shell commands:
clear - clear the terminal screen
version - show RT-Thread version information
list - list objects
help - RT-Thread shell help.
ps - List threads in the system.
free - Show the memory usage in the system.
pin - pin [option]
reboot - reset system
msh >
To get a little bit further into a project, I replaced the main.c PIN definition and main() with following code
// wrong definition, GPIO1_IO9 is ethernet leds on EVKB
// #define LED0_PIN GET_PIN(1, 9)
// D8 (GPIO01-08) is the user led
#define LED0_PIN GET_PIN(1, 8)
// SW5 (GPIO5-00) is the user button
#define SW5_PIN GET_PIN(5, 0)
int main(void)
{
#ifndef PHY_USING_KSZ8081
// set LED0 pin mode to output
rt_pin_mode(LED0_PIN, PIN_MODE_OUTPUT);
// set SW5 pin mode to pullup
rt_pin_mode(SW5_PIN, PIN_MODE_INPUT_PULLUP);
while (1)
{
if (!rt_pin_read(SW5_PIN)) {
rt_pin_write(LED0_PIN, PIN_HIGH);
} else {
rt_pin_write(LED0_PIN, PIN_LOW);
}
/*
rt_pin_write(LED0_PIN, PIN_HIGH);
rt_thread_mdelay(500);
rt_pin_write(LED0_PIN, PIN_LOW);
rt_thread_mdelay(500);
*/
}
#endif
}
This will couple the LED to the status of the user switch (SW5): If its pressed, the LED will turn on, if its not pressed, the LED will stay off. Just save, re-compile and re-download.
Bugs
As seen there are some bugs already found:
RT-Thread Studio error upon trying to import a project
RT-Thread Studio failing to choose the correct debugger even though it was selected on creation/import of the project
pyocd error upon download of firmware to the NXP MCU due to old pyocd version shipped with RT-Thread Studio
Integration of the menuconfig tooling as "RT-Thread Settings" within RT-Thread Studio - but it just does not have any effect on the project
I hope that these issues get solved soon - but with the infos above you should be able to get started. I will see you in the next post - probably going through the project I made :).
I remarked that the hardware was great, however the software support and update capability of the system was severly lagging behind for an "industrial floor, always on" type of machine. Luckily, thats exactly what balena has been created for.
Even better, their environment already support Nvidia Jetson devices - also Nvidia Jetson Xavier NX modules. With the AIR-020X being a really nice carrierboard (and housing) for this module, I went to work.
Spoiler Alert - it works!
Installing balenaOS on the AIR-020X
1.) I setup an Ubuntu 20.04 LTS machine, installed npm and setup jetson-flash
2.) I went to https://www.balena.io/os and downloaded the latest NVIDIA JETSON XAVIER NX DEVKIT EMMC image (2.107.10) in the development version.
3.) Unzip the file after setting up jetson-flash and getting your AIR-020X into recovery mode. This means opening the bottom of the case by unscrewing the 4 philipps head screws, connecting the Micro USB port of the AIR-020X with your Ubuntu host computer, applying power to the AIR-020X, but do not yet press the power switch.
4.) There is foil/recovery switch next to the Micro USB connector and LAN port. You need to press and hold this switch and at the same time press the power on button of the unit for about 4 seconds.
5.) On Ubuntu, run lsusb | grep Nvidia - this should return a similar line to this
Bus 003 Device 005: ID 0955:7023 NVIDIA Corp. APX
Import is the ending "APX", which means it is in recovery mode.
The .img value points to the unzipped image file, the -m tells the jetson-flash tool that we are running a Xavier NX system and want to install balenaOS on the internal eMMC module.
7.) This will now start the process which will take some minutes and also ask you for your sudo password. At the end you should see something like this:
[ 255.8670 ] Flashing completed
[ 255.8670 ] Coldbooting the device
[ 255.8696 ] tegrarcm_v2 --ismb2
[ 255.9454 ]
[ 255.9502 ] tegradevflash_v2 --reboot coldboot
[ 255.9530 ] Bootloader version 01.00.0000
[ 255.9984 ]
*** The target t186ref has been flashed successfully. ***
Reset the board to boot from internal eMMC.
8.) As soon as you reboot the device, you will be greeted with the balenaOS logo and can use it as any other balenaOS device.
Adding the AIR-020X to a fleet
If you want to use it e.g. in a fleet, I would recommend creating a new one with the device type Nvidia Jetson Xavier. This is important to allow sample projects to correctly work, as its basically the same thing as the more specialized version "jetson-xavier-nx-devkit-emmc" - but most demo projects just implement the former one :).
To now join the installed device onto your new fleet, download and install balenaCLI - login to your balena Cloud account and do a balena scan using balenaCLI to find your AIR-020X on the network.
.\balena join 192.168.178.112
? Select fleet <yourFleetNameToSelect>
? Check for updates every X minutes 10
[Success] Device successfully joined balena-cloud.com!
... and voila, its online!
What does work?
Testing GPIO pins with a multimeter
The AIR-020X has a lot of custom GPIO chips, 2x RS485/RS232 interface, 1x CANbus interface, a second network interface and even a NVMe. Luckily, everything just works out of the box.
- HDMI works
- USB works
- onboard network card (dmesg + dhcp test, gets ip / works)
[ 29.231807] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control rx/tx
- 2nd network card (dmesg + dhcp test, get ip / works)
[ 104.307175] igb 0004:05:00.0 enP4p5s0: igb: enP4p5s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
- NVMe is recognized (lsblk)
nvme0n1 259:0 0 119.2G 0 disk
|-nvme0n1p1 259:1 0 96G 0 part
|-nvme0n1p2 259:2 0 64M 0 part
|-nvme0n1p3 259:3 0 64M 0 part
|-nvme0n1p4 259:4 0 448K 0 part
|-nvme0n1p5 259:5 0 448K 0 part
|-nvme0n1p6 259:6 0 63M 0 part
|-nvme0n1p7 259:7 0 512K 0 part
|-nvme0n1p8 259:8 0 256K 0 part
|-nvme0n1p9 259:9 0 256K 0 part
|-nvme0n1p10 259:10 0 300M 0 part
`-nvme0n1p11 259:11 0 22.8G 0 part
- can bus interface is auto loaded on boot (see ifconfig -a)
can0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:16 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:63
- gpio/dio, works, but bit3 does sadly not work
( more info: http://ess-wiki.advantech.com.tw/view/File:AIR-020-nVidia_GPIO.docx )
Pin Number AIR-020X AIR-020T AIR-020N
GPIO bit1 393 269 38
GPIO bit2 421 425 149
GPIO bit3 265 411 65
GPIO bit4 424 264 168
GPIO bit5 418 476 202
GPIO bit6 436 396 246
GPIO bit7 417 337 169
GPIO bit8 268 338 194
# set bit 1 as GPIO pin
echo 393 > /sys/class/gpio/export
# get value 0=low, 1=high
cat /sys/class/gpio/gpio393/value
# set direction out or in
echo out > /sys/class/gpio/gpio393/direction
# get direction
cat /sys/class/gpio/gpio393/direction
out
# set value on out pin
echo 1 > /sys/class/gpio/gpio393/value
test:
# 265, bit3 did not work on export
echo 393 > /sys/class/gpio/export
echo 421 > /sys/class/gpio/export
echo 265 > /sys/class/gpio/export
echo 424 > /sys/class/gpio/export
echo 418 > /sys/class/gpio/export
echo 436 > /sys/class/gpio/export
echo 417 > /sys/class/gpio/export
echo 268 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio393/direction
echo out > /sys/class/gpio/gpio421/direction
echo out > /sys/class/gpio/gpio265/direction
echo out > /sys/class/gpio/gpio424/direction
echo out > /sys/class/gpio/gpio418/direction
echo out > /sys/class/gpio/gpio436/direction
echo out > /sys/class/gpio/gpio417/direction
echo out > /sys/class/gpio/gpio268/direction
echo 1 > /sys/class/gpio/gpio393/value
echo 1 > /sys/class/gpio/gpio421/value
echo 1 > /sys/class/gpio/gpio265/value
echo 1 > /sys/class/gpio/gpio424/value
echo 1 > /sys/class/gpio/gpio418/value
echo 1 > /sys/class/gpio/gpio436/value
echo 1 > /sys/class/gpio/gpio417/value
echo 1 > /sys/class/gpio/gpio268/value
- com ports, running as RS-232 or RS-485 (not tested, but recognized)
( more info: http://ess-wiki.advantech.com.tw/view/AIR-020-RS-485 )
root@56e8bf3:/# ls /dev/ | grep ttyTH
ttyTHS0 <- COM1
ttyTHS1 <- COM2
ttyTHS4
More info to the hardware can be found in the Advantech Wiki.
GPU Demos
Last but not least I want to point you towards the nice balena Jetson tutorial which can be found here.
It will help you getting started with Jetson samples that are hosted here.
In the end I was able to also get CUDA acceleration to work and see this smoke demo:
Nothing like some GPU accelerated smoke
With that I am closing this post. It was surprisingly easy to get this device to work - the only thing left would be to get it to boot and to work from its internal NVMe storage, but other than that its a nice tool for working with GPU workloads like Edge Impulse.
Normally, I am not getting review units. This is due to the fact that I am only hosting this small weblog, along some conference talks - and most companies would probably be better off to send their units along someone with a reach of Linus Tech Tips, or similar.
On the other hand - when I get the possibility to do a review, it can be a bit worrisome for the companies as well, as I am a very honest person. I have been working in tech for some time now and had the honor to build stuff which went to space - and came back to tell the tale. I know what I want in a unit - and what could be a problem.
With this out of the way, I was one lucky winner of the Advantech Edge AI Challenge 2022 and got an AIR-020X-S9A1 unit at no charge to be able to realize my labSentinel 2 project. By doing this project I learned a bit about the box and thought it would not be a bad idea to share my ideas with the readers of my blog - and also Advantech, so that they can improve upon their product. This review is not paid for, reflects my own thoughts and I got the mentioned unit for my project - the review was not a part of that deal. With that out of the way, lets get started.
The hardware
The AIR-020X comes very well packaged - having its own foam jacket which will save it from all but the most horrible abuse from postal services. Not that it would matter: The roughly 14 cm x 12 cm x 4,5 cm compact unit weighs in at nearly 850 gr and is built sturdy and robust - like a tank:
The most obvious part of the unit is its heatsink, which it does put to good use - but more on that topic later. Along with the computer itself comes a chinese printed starting guide and a short USB A to Micro B cable, which will be needed to factory reset and reflash the unit.
All in all, the AIR-020X is an impressive unit, including an Nvidia Jetson Xavier NX module with 8 GB RAM, 16 GB onboard eMMC, 128 GB M.2 Flash, 2x RS232/422/485, 1x CANbus, 1xDIO ("GPIO"), 2x 1 Gbit ethernet, 1x Fullsize mPCIe with nano SIM holder, 1x 4k HDMI Output, 2x USB 3.0 Type A, 1x USB Type C. The unit is powered by a 12-24 V DC power supply, which is an optional accessory.
Being an industrial unit, it uses an industrial type connector for power, which is an HT5.08 2 pole type:
As this connector is also not part of the base package and the USB C connector does not accept power delivery (and neither works in Display Port Mode) - it becomes a bit harder to power up the unit after receiving it. Finding a usable power supply within the sizable voltage range of 12 - 24 V (e.g. from an old Laptop) is fairly easy, but without the connector - it becomes a dead end until the next delivery is there. It would be useful to at least include one connector with the base unit. The usb cable is a nice addition, but could be left out (even though its very high quality) - along with the chinese manual. This could be replaced with a small card with direct links to the english and chinese PDF versions of the manual.
Opening up the unit reveals the internals - but not without a fight:
The used screws are perfectly fixed to the structure by using blue loctite - a touch I cannot recommend enough for the vibration resistance of the overall unit - but the screws themselves are made from extremely soft metal, so that - using the correct screwdriver - I stripped nearly all screws and had really issues removing all of them. Somehow this problem seems to exist for all the external black screws, the internal silver ones were of a lot higher quality. In my case I fixed the issue by replacing the screws with new ones and never had an issue anymore with them.
The internal structure is very well laid out, raising the M.2 drive onto a pole to keep it a bit further from the heat source / Xavier NX module which is just sitting on the other side of the PCB and directly sandwiches with the big heatsink.
Very welcome are also the addition of the two Raspberry Pi Style Camera connectors, although they are a bit hidden by the serial console cables. I understand that the unit should be as closed as possible for the use in factories, but I would have loved to see two small slits (possibly even with some IP/EMC gaskets to allow for protective shielding of those entry points) so that cameras on the outside of the case can be easily attached.
The mPCIe slot gives the system an additional expansion slot for e.G. UMTS or LoRaWAN modules and also the internal CR2032 cell for the RTC is a small but valuable detail.
The AIR-020X has some mounting points available on both system sides for additional wall mounting rails. Looking at the mounting points and the obvious use of the AIR-020 series in lab and factory settings, the inclusion of a DIN rail mount as available accessory could prove very useful to directly mount this small computer into an electrical cabinet.
The software
Booting up the system greats one with a very familiar picture: Ubuntu 18.04 is running on the machine in form of a tailored version of Nvidia Jetpack. This version by Advantech is only using the eMMC of the Xavier NX module to start the bootloader, but the actual data is kept on the M.2. This is a great idea for the longevity of the eMMC on the (currently hard to find) Xavier NX module - but comes with the drawback of additional needed customization other than "only" the PCB, included hardware, drivers and other changes made by Advantech in comparision to an Nvidia Developerboard for the same module.
This is a problem I also learned the hard way: I realized that the board was delivered with L4T 32.5.2 - not the current 32.7.x (JetPack 4.6.1) - so I updated this by hand. Just to have the board bootloop. This was the moment I took a closer look to the online presence of Advantech and the manual - just to learn that the recovery process was neither described, nor was the download of the image available. I got the needed recovery file as well as the documentation (which also included vital information on how to use the DIO (GPIO), RS422 and CANbus interface) and as able to restore the board to working order. Obviously there were multiple problems with this: First, the online available manual should contain all needed information regardings settings, ports, recovery, etc - secondly, the current (and maybe even last) images also need to be available online on their website - with checksums to be able to deploy these images safetly.
I also voiced my concerns regarding the high impact security issues / CVEs found in 32.5.2 - which would make the use of AIR-020 series an absolute liability in a production environment. I am glad to report that Advantech reacted to these concerns with providing a beta version of a new JetPack 4.6.1 Image. A short time afterwards, Advantech did add some information to their wiki:
On the download page you can find the AIR020A2AIM20UIV00004 entry for the Jetson NX JetPack 4.6.1 from 2022-07-20. This links to a Dropbox folder containing a the latest image (AIR020A2AIM20UIV00004_194.tar.gz / 2022-09-16).
With this latest image I was able to upgrade the AIR-020X to JetPack 4.6.1 and even do and apt upgrade to upgrade to L4T 32.7.2, at the time the latest L4T. However, this did not go as planed: After doing the upgrade and rebooting the device, it got caught in a bootloop. This bootloop kept on repeating for about 10 minutes until the device mysteriously started then working and came back on without issues. Obviously this would not be a graceful upgrade and did instill some concerns why this was a reproducible issue.
I am glad to report that Advantech has provided the latest image - which will eliminate several security issues. However, the changes needed in the manual as well as the provision of the recovery images (now via Dropbox?) and the secure provision of security updates to the unit remain. Maybe Advantech would think about starting to use balena.io to handle these issues?
Verdict
The Advantech AIR-020X is an extremely capable unit in a small form factor, sturdy built and highly reliable. Even with the latest JetPack 4.6.1 and abuse of the formerly not available 20 Watt mode I could not get this unit to heat up too much in my testing with labSentinel 2. There is still enough headroom available to use it in any kind of environment, which makes it a perfect choice for labs and factories - if Advantech can tackle the presented issues. Especially the ones regarding timely and secure availability of security patches and software updates. This also means availability of these images, fast adaption after release of official Nvidia updates and all needed documentation in one manual for public download. With these exceptions and some small kinks, Advantech is so close to building the perfect unit for their envisioned use case. I really hope they can close that last (security/software/manual) gap to an otherwise nearly perfect hardware - and with that create an recommendable product.
The best way to power a Jetson Nano 4 GB dev board is by using a center positive, 5 V and at least 4 A barrel connector type power adapter. However, these are often bulky and not the best travel companion - while USB C power bricks are becoming more common and the relevant USB C sockets are getting build into nearly every device (maybe yours too, Apple?).
So I set out to build a USB C power adapter for the Jetson board.
The trick is setting the USB C trigger to request 20 V and using the 5 V converters in parallel to step-down the 20 V to 5 V - and then feeding the resulting voltage again in parallel to the barrel plug, like so.
For the curios among you now asking why I did not just set the trigger to 5 V and used it all alone: I tried this first, but it did not work. It was not able to provide enough current to support the operation of the Jetson at "MAXN mode" - it was constantly coming up with Overcurrent protection messages if pushed too hard.
I am happy with the result and shortend the wires after testing, putting everything into a neat small form factor.
With this change I can finally replace my old Jetson Nano power supply with something smaller than this chunky unit which I was gifted back in the day by the awesome Morlac :).
Loading Comments...
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.Ok
