Jake’s Blog

Mainboard RGB Fan Control with OpenRGB

2022-03-19T00:00:00+00:00

Finally following up on my previous post about the coolmoon controller mod, this post shows how to connect it with a mainboard header and do cool (pun intended) animations with OpenRGB.

Hardware Setup

First of all a mainboard is required that has at least one header for 5V addressable RGB LEDs. I upgraded to an Gigabyte B550 Aorus Pro V2 and that what I am using for this project, it can provide up to 5A and control 1000 LEDs. As case I have a Fractal Design Meshify C Dark.

Mainboard Connection

The header connector cable to the previously made fan hub is really simple:

For the mainboard side I cut a 4 pin piece from a standard 0.1 in (2.54 mm) pitch header bar. Actually only 3 pins are used, they use a wider header and don’t equip one pin to make wrong connections impossible, as wrong polarity would most certainly destroy the fans.

Then it goes to the 3 pin input directly:

Nr.	MainBoard Pin	LED Pin
1	v (5V)	+5V
2	Data	Data in
3	No Pin	-
4	GND	GND

I wrapped some tape around the hub, so the exposed solder joints can’t touch anything, which could otherwise cause a short circut with other parts in the case.

You can also see the cable in the output port, this is for the following part.

3D printed sign

In addition to the normal fan I though it would be nice to have an custom sign with some letters from my name. Idea was to use compatible WS2812B strip part to illuminate it. Overall there are 17 LEDs (6+5+6) in the so called 5050 format, meaning 5 x 5 mm LEDs.

Then I printed it in transparent PETG, cut 3 pieces of the LED strip, joined then with some 3 pin cables and secured everything to the sign with a bit of hot glue:

To my surprise the first revision already fitted well to LEDs. This is mainly because I could put in high tolerances, especially on the “J” bend part, after the strip is put on the holes are not visible anyway.

OpenRGB configuration

Now to the software part. OpenRGB is very powerful open source control program, that supports not only the RGB header, but also for example the popular Trident Z RGB RAM and AMD CPU cooler.

Plugins

We need 2 plugins for the following setup. Installation is done through settings - plugins - install plugin (button) - select the downloaded package:

Successfully installed plugins show up as additional tabs on the top.

Visual Map

Adds an interface to organize the LEDs in a virtual space, like they are physically installed. Really crucial to to get a proper picture with these fans that wrap sequentially addressed LED strips around circles. https://gitlab.com/OpenRGBDevelopers/OpenRGBVisualMapPlugin

Effects

This adds various animation, vanilla openRGB has only manual control. https://gitlab.com/OpenRGBDevelopers/OpenRGBEffectsPlugin

Fans + sign

The mainboard header get’s auto detected on startup. Only thing to do is to tell the software how many LEDs are connected, with a click on resize: Each coolmoon fan has 16 LEDs, so for me it is 4*16 = 64 plus the sign, makes it overall 81 LEDs. As mentioned above manual control can be done on this page, it is useful for testing if the hardware works correctly.

WLED

External lights can be also hooked up, here I connect my ESP32 installation with WLED firmware, control data is sent over the WiFi home network.

The DMX protocol also has to be enabled in WLEDs interface, like this:

Then it shows up as device and can be controlled as usual. I am using it only as ambient backlight, not for effects.

Positional mapping

Now to the visual map plugin configuration. It provides a virtual space of custom size to map out the various LED devices and control it as one. To build a new map first select the devices on the left side with the + buttons. Then they show up in the mid section, can be selected and dragged around. Make sure there is enough virtual space for your creation with the width/height setting on the right. Also it is advisable to give the mapping a name in the top tab section and save the work regularly (button on the right).

Newly added devices will come in as a line, for more complex shapes like fan click on “edit shape” on the left, this brings up an editor window: Here each individual LED can be dragged around. Some convenient functions are on the right, select multiple LEDs to use them. Dragging work also for selection and whole groups can be moved around. It will take some time to arrange all 81 LEDs initially, but trust me - it is worth it.

After everything is positioned like the hardware, make sure “register controller” is ticked on, so the large virtual device actually appears and can be tested. “Toggle LED View” enabled the visual grid:

Effects

Animations make it even more interesting. First select+add an builtin effect on the left side. It is normal that nothing happens first, each effect has to be started with the bottom right button. Required is also to enable a controller on the right. Then the effect should be visible, check the live preview either here or in the device or map view. Effect settings can be saved/loaded with the top tight buttons.

Conclusion and Video

Overall I am very pleased with result. I like especially the music visualization effects (VU meter), but see for yourself:

BLE Serial 2.0 Update

2021-04-22T00:00:00+00:00

This is a detailed description of the major 2.0.0 release of BLE Serial. It is a tool to connect Bluetooth low energy 4. and 5.x (BLE) UART modules to virtual serial ports on Linux and now also COM ports on Windows.

Backend Change

In the first BLE Serial versions (1.0 up to 1.3) it used bluepy as bluetooth backend library. Problem with it was an open issue that required the manual installation of a fork, like described in the previous post about it. Now over the course of 2020 some PRs got merged, but unfortunately there are many open issues and the version on PyPI is still more than 2 years old.

Also the recommended interface to use BlueZ on Linux is D-Bus, while bluepy uses a custom bluepy-helper written in C, that required additional permissions for some actions.

So as discussed in this issue a backend change was needed. The descision was made to switch to bleak which is pure Python and uses D-Bus on Linux. In addition it has support for Windows and macOS.

Installation is simply done with one command now:

$ pip install ble-serial

Windows Support

As already mentioned BLE Serial has now cross platform support. Following is the Windows setup described (excerpt from README).

Windows does not have a builtin feature to create virtual serial ports (like Linux does), so it is required to install a additional driver. I decided to use the open source com0com Null-modem emulator, downloaded from here as signed version. This is required because unsigned drivers can not be installed anymore. Note that on latest Windows 10 you likely still have to disable secure boot for it to work.

ble-serial includes the ble-com-setup script to make the com0com configuration easier:

> ble-com-setup.exe -h
usage: ble-com-setup [-h] [--install-path INSTALL_PATH]

Setup required COM port pair

optional arguments:
  -h, --help            show this help message and exit
  --install-path INSTALL_PATH
                        Installation directory of the null modem emulator (default: C:/Program Files (x86)/com0com/)

It will request administrator privileges (if it does not already have it) and setup the port in another CMD window:

Changing into C:/Program Files (x86)/com0com/

> Checking port list for BLE
       CNCA0 PortName=-
       CNCB0 PortName=-

BLE port does not exist

> Checking port list for COM9
       CNCA0 PortName=-
       CNCB0 PortName=-

> Trying to create port pair
       CNCA1 PortName=COM9
       CNCB1 PortName=BLE
ComDB: COM9 - logged as "in use"

Setup done!

Hit any key to close

As you can see it created the BLE<->COM9 pair. ble-serial will internally connect to BLE, users can then send/receive the data on COM9.

Otherwise there exist multiple proprietary serial port emulators, these should work too. Just manually create a pair that includes a port named BLE.

Performance

To test the performance and compare it with the older implementation I added automated transfer tests in the repo tests directory. The idea is to connect a USB <-> serial adapter to the BLE module. Then run ble-serial on the same host, pass data between the adapter and virtual port and check if it is still the same, to identify configurations with packet loss and other issues.

My test setup consists of a HM-10 module and CP2102 based USB/UART adapter. The scripts uses AT commands to automatically switch through the baud rates, for example AT+BAUD0 for 9600 bit/s. Then it sends packets with different intervall/delays to either the BLE or UART side, while checking (reading) on the other side and comparing how much was actually received.

Note that I have also tested different packet sizes (which has the same effect as changing the --mtu option), but did not find a significant difference between the 4, 16 and 64 bytes, so I am not including it in the graphs here. The following was all tested with 32 bytes packets. You can see the raw CSV data in the results/ subdirectory, if you are interested anyway.

I have grouped the results in graphs by the transmission direction. First writing to the virtual BLE port and receiving on hardware UART:

As you can see it is getting better with higher baud rates, which makes sense, because the BLE chip is receiving data at a constant rate. The module will just drop data, if the configured UART is too slow to keep up with outputting it.

The maximum real throughput is at at about 21 kbit/s, this explain what we saw above: 19200 is not enough, but 57600+ can receive 100%.

Now to the tests in the opposite direction, writing to hardware UART:

Losses show the opposite behavior here, 9600 is completely fine, higher ones only if some delay is used. From 19200 only about 80% is received.

Apparently the maximum throughput is lower in this direction with about 17 kbit/s, this explains why 19200 shows already some loss.

An always safe option is to use 1 ms delay per byte (= max. 10000 baud). Note that that I calculate 10 bit per byte, because UART uses 8-N-1 encoding, so: 1 start + 8 data + 1 stop = 10 bits.

Compared with v1.3

Here it tested with 0 delay, so writing as fast as possible, because this shows differences most clearly.

In the case of writing to UART both implementations are almost equal, but there is a massive difference when writing to the virtual BLE serial port. This is not throttled, so you can multiple MB/s to it, of course bluetooth and UART are not that fast. 1.3 dropped about 98% in that case, it only worked reliably if the application wrote small amounts of data continuously.

On 2.0 this is buffered, that makes writing continuously into BLE safe. There is still the hardware limitation though, the UART output baud rate should be above ~20000, for example it can receive all data with 57600 baudrate.

Colored Logs

Another improvement in this release are that log levels are now indicated also by colors: This should make it easier to spot important infos, even with the noisy verbose (-v) log level.

I hope this update is helpful, let me know how it works.

I2C Communication Protocol of a Smartphone Battery

2021-03-25T00:00:00+00:00

In this post I investigate how a typical Oneplus smartphone battery communicates the current voltage, state of charge etc. to the main device. This can be also useful for repurposing these batteries on a Raspberry or Orange Pi, to power portable projects.

Hardware Dismantling

I had the battery already removed from the Oneplus One (and replaced with a new third party part). First the outer wrap has to be removed, I need to see the bare cell and protection PCB. It reveals another (paper?) wrap at the top and a small temperature probe sticking out:

After removing that as well the board is finally visible. Between the big battery taps is most likely a shunt resistor to measure the current. On the mid to left are some ICs (more on them later) and on the right four large solder pads, marked with SCL, SDA, P+ and P-. The flat flex cable is simply soldered to these pads and the connector has the same markings.

P stands probably for power and these +/- pads are indeed connected to the battery and carry the about 4V, I have checked it with a multimeter. SCL/SDA is really interesting, because this suggests that there is some digital I2C communication with the smartphone going on.

Not much on the back side, looks like a few SMD resistors are below some black potting compound.

Chip Investigation

Now I got curious what exactly this board does. Unfortunately I could not read chip markings, because they are extremely small, no chance without a microscope…

Instead I tried to find something on the internet, the search for “oneplus battery i2c site:forums.oneplus.com” brought up a boot/kernel log. Then searching for “battery” in the log found these messages:

[    4.792738] bq27541-battery 1-0055: DEVICE_TYPE is 0x541, FIRMWARE_VERSION is 0x200
[    4.792950] bq27541-battery 1-0055: Complete bq27541 configuration 0x601B

This is a kernel driver for “bq27541”, so I searched for that and got indeed a datasheet from Texas Instruments. The description fits well, it is a “Single Cell Li-Ion Battery Fuel Gauge” and “provides information such as remaining battery capacity(mAh), state-of-charge (%), run-time to empty (min.), battery voltage (mV), and temperature (°C)” over an I2C interface.

The protocol description is detailed, important information for the start is on page 32:

device address 01010101 = 0x55
support for normal I2C read or incremental read (multi byte)

Abd a excerpt from the standard 2 byte registers/commands (page 9):

TEMP (temperature) 0x06 + 0x07
VOLT (voltage) 0x08 + 0x09
SOC (state of charge) 0x2c + 0x2d

To confirm that it speaks this protocol I hooked up my DSLogic Plus, connected the battery back to the phone and rebooted it, the capture looks like this: The 7 bit long address is 0x55 as expected, after that comes 1 bit indicating a read/write, then ACK (A) or NOT ACK (N) and finally the packet data. It is the register 0x08 = voltage in this case. The request is always a write, but it is not actually writing, just specifies the register.

I2C is a bus designed with a master (here: phone) and slave (here: battery). The master controls the bus, it sends again the first start with device address, but now with read bit appended. Now the bus gets released from the master, indicating that the slave 0x55 is allowed to send now. It responds shortly after with the actual data: First comes the low byte, high byte is second (practically little endian), that means 0x0e95 = 3733 mV.

Orange Pi Setup

As already noted in the introduction this is also useful for usage with other Linux computers. I had a Orange Pi PC2 with Armbian laying around, so I used that, it has many GPIOs: Most importantly, support for I2C. Bus 0 is on PA11 and PA12, highlighted in light blue. On modern kernels the so called device trees (DT) are used to define the hardware. For Armbian the configuration file which gets read by the bootloader is /boot/armbianEnv.txt. To enable I2C bus 0 is must contain overlays=i2c0.

After a reboot a new I2C bus should show up, this can be checked with i2cdetect -l.

So I connected both the battery and the logic analyzer to it: The red and black crocodile clips are coming from a lab power supply, simply providing 5V to power the Orange Pi, battery ground is also connected to the common ground.

It is also possible to scan for devices with i2cdetect, here with -y to disable interactive confirmation and on bus 0:

orangepipc2:~:# i2cdetect -y 0
1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
         -- -- -- -- -- -- -- -- -- -- -- -- -- 
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
-- -- -- -- -- 55 -- -- -- -- -- -- -- -- -- -- 
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
-- -- -- -- -- -- -- --                         

It indeed detects the battery with address 0x55, very nice!

Command Line Readout

With the included i2cdump and i2cget tools it is possible to read data out from a shell. The dump reads a range of bytes, here again with -y to disable interactive confirmation, range 0x02-0x2d for the standard registers, bus 0 and address 0x55. W for 16 bit words, because the chip returns directly 2 bytes, no need to send request for every single address.

orangepipc2:~:# i2cdump -y -r 0x02-0x2d 0 0x55 W
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00:       00 00 ff ff 71 0b 66 0f 80 01 13 06 27 09      ....q?f???????
10: 02 05 16 08 00 00 ff ff ff ff ff ff ff ff 8a f8    ????..........??
20: 28 00 46 12 00 00 ff ff 6f 0b c0 03 3e 00          (.F?....o???>.  

orangepipc2:~:# i2cget -y 0 0x55 0x08 w
0x0f66

orangepipc2:~:# i2cget -y 0 0x55 0x2c w
0x003e

If you want only a single value then the get is the right tool, after specifying bus and address there is a single register and word to read 2 bytes. Here I read out voltage 0x0f66 = 3942 mV and 0x3e = 62 % state of charge (soc).

Python Readout

Another good option to get the data programmatically is Python. A popular library exists for SMBus, which is based on the I2C protocol. It provides also the low level methods required here. On my Ubuntu 20.04 based Armbian it can be simply installed through apt:

orangepipc2:~:# apt search smbus
...
python3-smbus/focal 4.1-2build2 arm64
  Python 3 bindings for Linux SMBus access through i2c-dev

orangepipc2:~:# apt install python3-smbus
...

Otherwise pip works as also as usual.

For testing I use a interactive python prompt. SMBus() receives a argument for the bus number, 0 in this case:

orangepipc2:~:# python3
Python 3.8.5 (default, Jan 27 2021, 15:41:15) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> import smbus
>>> b = smbus.SMBus(0)
>>> b.read_word_data(0x55, 0x8)
3942
>>> b.read_word_data(0x55, 0x2c)
62
>>> b.read_word_data(0x55, 0x6) / 10 - 273.1
19.69999999999999

Again reading words (2 byte) here, in addition to the voltage and soc now also 0x06 = temperature. The result is in 1/10 Kelvin, so it needs the 273.1 offset to get degrees celsius.

Kernel Driver

Okay, enough of the manual playing around. From the the previous look at the Android log it clear that there exists full kernel drivers already. Actually they are in the mainline kernel! This makes installation easier, but just loading the kernel module does not do it. Trust me, I have tried it.

Device Tree Overlays

Like on the basic I2C setup a device tree entry is required, but there is no ready-made overlay included for this driver, so it is necessary to make it yourself. Armbian has documentation and examples that helps to do this.

A more detailed description of the syntax is available at elinux.org (embedded Linux wiki).

Last but not least in the kernel repo is documentation on how to write overlays for the current version. The Armbian sunxi examples are bit outdated, now it is not needed (or recommended) anymore to wrap the definition with fragment@0,__overlay__, etc. Also I have read the battery node and TI BQ27xxx driver documentation.

It includes a example DT snippet, I adjusted and saved it in i2c-bq27541.dts (.dts = DT source), that is the result:

/dts-v1/;
/plugin/;

&i2c0 {
    #address-cells = <1>;
    #size-cells = <0>;
    bat: battery {
        compatible = "simple-battery";
        voltage-min-design-microvolt = <3200000>;
        energy-full-design-microwatt-hours = <11400000>;
        charge-full-design-microamp-hours = <3100000>;
    };

    bq27541: fuel-gauge@55 {
        compatible = "ti,bq27541";
        reg = <0x55>;
        monitored-battery = <&bat>;
    };
};

Installation was done with armbian-add-overlay, which is just a shell script. It calls dtc (Device Tree Compiler) first and then copies the result to /boot/overlay-user/i2c-bq27541.dtbo (.dtbo = DT binary/blob overlay) and enables it in /boot/armbianEnv.txt. This is pretty convenient, but can be also done manually of course.

Now armbianEnv.txt should contain another line with user_overlays=i2c-bq27541. A reboot is required to actually load it.

Readout

Now if everything worked, the data can be easily read from sysfs power_supply class. I found out that the uevent provides a nice human readable overview:

orangepipc2:jk:# cat /sys/class/power_supply/bq27541-0/uevent 
POWER_SUPPLY_NAME=bq27541-0
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_VOLTAGE_NOW=3942000
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_CAPACITY=63
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_TEMP=188
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CHARGE_FULL=2058000
POWER_SUPPLY_CHARGE_NOW=1553000
POWER_SUPPLY_CHARGE_FULL_DESIGN=3000000
POWER_SUPPLY_CYCLE_COUNT=960
POWER_SUPPLY_POWER_AVG=0
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_MANUFACTURER=Texas Instruments

Especially interesting is the cycle count of 960 and degraded capacity to just 2058 mAh from over 3000 mAh of a new battery, that info was not accessible through standard Android APIs.

Of course it is also possible to get single values through the other files in this directory, for example just voltage:

orangepipc2:jk:# cat /sys/class/power_supply/bq27541-0/voltage_now                 
3942000

Note that this is in μV, usually the standard units are the smallest common denominator so there is enough resolution for all drivers and applications.

Further Ideas

It could be used with a lithium battery step up module to power the Orange Pi (or other SBCs with Linux). There are many choices for a few bucks from China that provide 5V output from the single cell input. I have also seen adjustable output (4.3 - 27V) versions, these even include USB charging. Maybe add a display to build a clunky hackable smartphone?

UT61E Toolkit: Update 1.4 with Temperature Measurement

2021-03-12T00:00:00+00:00

This is another app release that adds new data conversion features. This time: temperature measurement!

I got the idea after watching Dave’s EEVBlog about the new UT61E+, he criticized the unnecessary hFE mode and missing temperature option. He also said that this would be probably just a software change. So I thought: True! This should be even possible with the older UT61E and so I have implemented it in my app.

Sensor Types

From my research I found 3 general measurement principles and popular sensor types. Each of them has different advantages (more on what to choose later) and needs different parameters. They are now configurable in the settings “data processing” category:

All of them include some standard values, that should fit the typical sensors already.

Note that multiple options can be enabled at the same time. The app then uses the first in the list that fits to the selected range and just applies that calculation. For example if everything is enabled, but the multimeter returns mV values it automatically uses the thermocouple conversion, because it is the only that produces a voltage. Thermistor and RTD are both measured as resistors, so you have to disable thermistors if you want to connect a RTD instead.

The next sections give a quick introduction how the supported sensor types work.

Thermocouple

A very popular sensor, this is usually the only option on meters that already include temperature measurement.

The sensor consists of 2 wires from different metals. They are connected at on end in the measurement junction and on the other side usually to copper and connected to a voltmeter. The connection to copper forms a reference junction, also called cold junction, but it does not need to be actually colder than the measurement junction. A voltage is generated depending on the temperature difference between the junctions, it is practically linear. Polarity can change, depending on which junction is hotter/colder.

Multimeter banana jacks are typically placed 19 mm apart, so probes made for other devices fit nicely without modification:

Note: Voltage is almost 0 here, because both junctions are at ambient temperature.

To calculate the temperature we need to know how much the voltage increases per degree C. Preset is 0.039 mV/K (I am using Kelvin for temperature differences here, but it is of course 1:1 with °C). This is the value for a standardized type K sensor.

In addition we need the temperature of the reference junction. There are multiple options, as you can see in the following app screenshots:

If you have a stable ambient temperature you can select “constant” and manually put in a temperature (default = 20 °C), this is the most reliable option.

Otherwise it is possible to use sensors from the connected smartphone for this. Most devices include temperature sensors for CPU/GPU, battery, etc… in my case 81 sensors! Not all report a valid measurement though, some are deep in the negative or always 0.0. Select one that looks valid, here battery related ones are pretty good. Obvious potential issue is the self heating of the smartphone, it will probably report a bit more than ambient. But the advantage is that it continuously updates, it should not be distorted too much if you don’t touch or otherwise use the phone while measuring.

The multimeter should be in the 220 mV range and provide 0.01 mV resolution, combined with 0.039 mV/K this gives a resolution of about 1/4 = 0.25 K. Other ranges are not necessary as 220 mV / 0.039 = ± 5600 K is much more then these sensors can withstand anyway.

Thermistor

The name is a combination of thermal and resistor, this already explains what it is: a simple resistor. Typically NTCs (negative temperature coefficient) are used as sensors, so the resistance gets lower if the temperature increases.

Calculation of the temperature from the resistance is non-linear, which makes it more complex. For example a bit of python code to get the resistance from temperature:

r0 = 100_000 # Ohm
t0 = 25 + 273.15 # absolute temperature for r0
beta = 3950 # change rate coefficient

def resistance(c):
    k = c + 273.15
    return r0 * exp(beta * (1/k - 1/t0))

It contains the exponential exp() function (based on e = 2.71828...) and this causes massive changes in resistance, which makes it a challenge to measure over large temperature ranges. For example a NTC with 100 kΩ @ 25°C has 200 kΩ @ 10°C (with 10 kΩ/K change rate) and 3.59 kΩ @ 125°C (with 0.09 kΩ/K change rate).

With the usual fixed voltage dividers this reduces the resolution, but with the UT61E it is quite a bit different, I made a graph to make this better visible:

The blue line shows the thermistor resistance from -100 °C up to 250°C , it is logarithmically scaled on the right Y axis, otherwise it would be impossible to see. On the low end it goes over 1e9 Ω = 1 GΩ while at the high temperatures it is just a few hundred Ohms. Nominal resistance is again 1e5 Ω = 100 kΩ. Then the green line is the max. value of the range the multimeter will be in, this must be always at least as much as the actual resistance, to be able to measure it. Note that below -85 °C this does not work anymore, because it can’t measure > 220 MΩ.

Now the red line shows the resolution, as you can see the autoranging is really helpful here. The resolution is naturally getting worse with increasing temperature, but switching to a lower resistance range counteracts this. Worst case is 0.02 K and best case < 0.001 K, which is extremely fine.

At 20 °C is also a good area with about 0.002 K, in my tests this even detects the heat radiation from my body, could be made into some sort of distance sensor.

Here is how it looks in the app, again showing the resolution:

Resistance Temperature Detector (RTD)

RTDs are also resistors, but with a positive temperature coefficient and made out of wire or thin film of a pure metal. This makes them practically linear and gives them good accuracy and repeatability (low drift). Typical material is platinum with the PT100, PT500 and PT1000. The number specifies the nominal resistance at 0 °C, this should be configured in the app settings.

Otherwise there is a the alpha, similar to the thermocouple this just specifies how much the resistance changes per degree. The default of 0.00385 Ω/(Ω·°C) is standardized and should fit almost anything.

It looks like this in the app:

Resolution on the UT61E with PT100 and PT1000 is equal:
0.00385 * 100 Ω = 0.385 Ω/K in 220 Ω range with 0.01 resolution = 1/38 = 0.026 K
0.00385 * 1000 Ω = 3.85 Ω/K in 2.2 kΩ range with 0.1 resolution = 1/38 = 0.026 K
It will just switch to the better matching range. Other ranges are not required up to (220-100) Ω / 0.385 = +312 °C after that it will switch up (factor 10) and reduce the resolution to 0.26 K.

Sensor Selection

After all you might ask: What sensor should I choose? For that I have made an short overview:

Type	Sensor	Max. T	Resolution	Accuracy	Cost incl. wire
Thermocouple	Type K	1200 °C	0.25 K	2 K (0.75%)	~ 1 $
Thermistor	NTC 100k	300 °C	0.001-0.02 K	3-15 K (5%)	~ 0.5 $
RTD	PT1000	600 °C	0.026 K	< 0.5 K	~ 3 $

Thermocouples are good for very high temperatures, but resolution and accuracy is not the best. Thermistors on the other hand provide insanely high resolutions, but only at relatively low temperatures and the accuracy is pretty bad, because of the non linearity. RTDs are the most accurate (and expensive), with acceptable resolution and max. temperature.

As always: there is no clear winner, it really depends on the application.

UT61E Toolkit: Update 1.3

2021-03-11T00:00:00+00:00

After almost 2 years I began working on my app for the UT61E (and others from the UT61 series) again. This release includes only small visible changes, a lot of work went into updating the Android API, especially the new security features required changes.

UI Improvements

First let’s look at the user interface changes. I have adjusted the background and colors for the categories, this should make it easier to read (better contrast):

Also I noticed that the scan results include a RSSI (Received Signal Strength Indication) value, this now gets showed as bar in list as well. It helps to find the correct device if there are many detected, the nearest device/multimeter should show the highest RSSI.

Bugfixes

There was a bug with other bluetooth modules. It was reported on GitHub from someone who used JDY-10 module, which worked with other apps, but here it did not return any data. The module needs a explicit write into a configuration register to enable notifications. This fix is included in 1.3 as well.

SDK Platform

As already mentioned I haven’t touched the codebase for a while, it still targeted SDK 27 (Android 8.1), so I had to jump 3 levels to SDK 30 (Android 11).

In previous versions there was a setting called “Log folder” in the app. You could put in a string with a name or path, then the app would internally create this folder and put all CSV logs into it. Now this is not possible anymore in the normal internal storage. Android 10 introduced scoped storage and Android 11 enforces it. Apps only get access to their app-specific directory.

Otherwise the user can select a folder or file with the system file browser and grant permission. This is implemented now, instead of a string input the app show the file explorer. It think this is nicer anyway to select it like this, instead of error prone manually typing the path. After it got scoped access to a directory the actual log files can still be created automatically.

DIY GoTo Telescope Mount [3] = Electronics for first Stepper Test

2020-11-02T00:00:00+00:00

This is the next part in my telescope series, look at the other posts for more details. In this post I describe how I set up a basic controller to test the mechanical setup.

Electrical Prototype

As already mentioned I want to make it as silent as so possible, so I decided to go for TMC2208 in StealthChop mode. First I thought about using breadboard and jumper cables, it is not too complex and the pinout/schematics of my driver breakout modules is available in the BigTreeTech GitHub repo. But because I had a spare RAMPS 1.4 shield from a 3D printer it was easier to just use that.

These TMC drivers are pin compatible to the older/cheaper A4988 or DRV8825. Only noticeable setup difference that is has only 2 instead of 3 pins (or jumper options) for the microstepping, with this layout:

MS1	MS2	Microstepping
V_IO	V_IO	16
GND	GND	8
GND	V_IO	4
V_IO	GND	2

Where V_IO means pullup to the IO Voltage, +5V from USB in this case. GND is a pulldown (default).

For now I run it with 8x microstepping, no jumpers plugged in, I might change that later. Then I simply inserted the drivers and connected the motors and USB to the Arduino Mega underneath:

To supply the motors I used a adjustable DC/DC converter (B3603) and laptop PSU set to 24V.

In theory it is also possible to run it on 5V only (section 3.3 in Trinamics datasheet), but it would be less efficient and provide way lower torque/speed.

Overview

Here is everything in one picture:

Arduino Code

Controlling the stepper drivers is really simple, no library required. Basically there is a DIR pin, which must be pulled high or low depending on the direction. Then just switch the STEP pin to execute a (micro)step, with some delays. I made this function to do one full rotation, taking the 8x microstepping into account:

// microsecond timing
int pulse = 1;
int pause = 50;

int microsteps = 8;
long steps_per_rev = microsteps*200;

void rotate(bool clockwise) {
  digitalWrite(directionPin, clockwise? HIGH : LOW);
  
  for(int n = 0; n < steps_per_rev; n++) {
    digitalWrite(stepPin, HIGH);
    delayMicroseconds(pulse);
    digitalWrite(stepPin, LOW);
   
    delayMicroseconds(pause);
   
    digitalWrite(ledPin, !digitalRead(ledPin));
  }
}

Note: steps_per_rev is declared as long, because I experienced overflows when doing math with int here. On 8 bit Arduino (Atmel AVR) int defaults to 16 bit, that is only about +/- 32000. long is 32 bit. Another (probably even better) solution would be to specifically use uint32_t.

This above code works well if there is no load, but with the inertia af the mount (about 10 kg mass) it would only allow very low speeds, otherwise it loses steps when starting a movement.

The solution is to limit the acceleration and slowly increase the speed. I used the AccelStepper library for this. Basic setup code looks like that:

AccelStepper stepper(1, stepPin, directionPin);

void setup() {
  stepper.setEnablePin(enablePin);
  stepper.setPinsInverted(false, false, true);
  stepper.enableOutputs();

  stepper.setAcceleration(steps_per_rev * 0.2);
  stepper.setMaxSpeed(steps_per_rev * 2.0); // Rotation/second
}

It is important to set the enablePin to inverted = true, otherwise it will not run.

Finally to rotate back/forth use stepper.move(steps) or go to a absolute position with stepper.moveTo(stepPos). Constantly call stepper.run() in a loop to actually execute it.

You can download the whole code here. In addition the AccelStepper library must be installed and pins.h with the RAMPS pin definitions added, available at the RepRap wiki.

Further it could be improved utilizing the UART interface on these drivers, it allows to configure the current, microstepping, etc. through software, like in this TMCStepper example. But for now it legacy (also called standalone) is fine for testing.

Video Demo

DIY GoTo Telescope Mount [2] = Azimuth Axis

2020-09-21T00:00:00+00:00

This post shows the build of the azimuth (horizontal) axis for my GOTO telescope mount.

Large Pulley Profile

CAD Design

First I tried to copy the tooth profile from the altitude axis pulley model (previous post), but it did not work, because it is not strictly defined, so I made a new new drawing, based on the parameters:

Now fully constrained, with the exact measurements. Still with some tolerance for the 3D printing, implemented through a variable #fine_tol that intentionally makes the teeth a bit wider, here set to 0.05 mm.

Similar to the previous approach the tooth gets repeated with a curve pattern and cut into the part. But now (as already noted in the “learnings” section) I put a valley on the edge, this gives it a less sharp edge and is therefore easier to print.

Important is to add one to the teeth count calculation, because half of the tooth is protruding on each end, so effectively one full tooth is lost.

To make it fit on my printer build area I had to cut it again in segments. It is about 400 mm diameter = 1200 mm circumference. Making 7 parts would have worked, but I decided on 8 because it results in round numbers. So each part covers 45 degrees and is about 150 mm wide:

It fits in a circle as virtual assembly from all 8 segments: Imagine this ring around the static base plate of my existing telescope mount.

Print

All segments were printed with PLA and 0.3 mm layer height (two different color because of what I had left). The edges came out much better this time, did not require any postprocessing:

Motor Mount

The motor should be connected to top plate of the base. So the shaft points downwards to sit at the same height as the belt, which goes around the bottom base plate.

CAD design

The design is not too complicated, I added again some space to slide the motor, which allows adjustment of the belt tension. It has a slightly curved wall, where it touches the round base plate.

Print and Assembly

I drilled again four 2 mm holes and screwed it onto the plate. The printed profile is currently only attached by some double side tape. This is enough, because the belt clamps it as well, but I will nevertheless replace it with a more solid glue soon.

Download

As already mentioned I used the online CAD tool Onshape, so if you want to print it yourself you can download it here (see the tabs on the bottom for all other parts).

They support export as STL and many other CAD formats. It should be also possible to copy the project there (needs an account) and adjust all the variables, like diameter, belt size, sections, tolerances… or make other modifications.

Outlook

In the next post I will finally show it in action! With the basic electronics and controller code that I have so far, to test the mechanical setup.

DIY GoTo Telescope Mount [1] = Altitude Axis

2020-08-02T00:00:00+00:00

This post is the first real part of my self made GoTo mount series.

It explains the CAD design, 3D print and assembly of the motorized drive on the altitude (vertical) axis.

Main Pulley

CAD Design

I used Onshape to create a custom 3D model of the pulley. First I measured the length, hole spacing, diameter etc… of the existing tubus mounting rail and saved the values in variables. Then a sketch was built based on them: Because of the slightly smaller than 200x200 mm effective build area from my old Prusa i3 printer it was not possible to make the whole pulley in one piece, so I split it into four pieces and added holes to join them with screws afterwards.

The rail length is only 200 mm, but to allow the edges to fit into the circle, it has of course a bigger diameter. I need the diameter to calculate the correct teeth spacing to fit the GT2 belt, which has 2 mm pitch, so I installed a FeatureScript plugin that can measure parts and create variables. From that the tooth angle and count are calculated for the next sketch. To get a close to integer count (of 86 teeth per quarter circle) I adjusted the base width to 203 mm.

I made the profile loosely based on the GT2 belt definition, adding 0.1 mm tolerance where I saw fit: Notable here is that it looks like the one side is not on the circle outline, I checked the constraints and it is actually on the line, but Onshape renders the large circle in a low resolution, making it look like a straight line. This is only a optical issue, the exported model is fine.

After a circular remove pattern this is the resulting belt profile:

Tests and Fixes

In Onshapes assembly tool the whole pulley seemed to fit fine:

So I proceeded to actually printing the parts. It needed a few tests and adjustments to get the tolerances right, especially where it interfaces the rail, after 4 iterations I was quite happy with the result:

Following I began to tighten the screws for the first time on the rail and noticed that the pulley gets crooked.

This is because the rail bottom is also slightly skewed inside: It is about 1 mm deeper on the sides, measured from the flat top. I did not want to print all parts again, so I quickly made some wedge shaped spacers, that are also secured through the screw:

Assembly

After closer inspection I saw some things that required cleanup. The Teeth on seams are cut in half, so there is a quite fine an sharp edge and this resulted in some edge bulging, which I had to scrape off to produce a good belt fit: In addition I sanded the surfaces that touch other parts a bit.

After all it fits nicely on the mounting rail:

Small pulley

Motor Mount

Mounting the motor is done with a pretty simple bracket on the base plate. In CAD:

It has long slots, which allows different positions for the motor, so it can be used to produce an adequate belt tension. Printed and assembled it looks like that: As small pulley I use a standard 20 teeth aluminum part. Combined with the large custom 430 teeth pulley it creates a tranmission ration of 21.5.

Final Assembly

In the end I put the tubus back on the original wooden base: Then cut of a piece of belt and connected the end with a cable tie (just like on 3d printers).

I pre drilled four holes with a 2 mm drill (3.5 mm screws) for the motor mount:

And secured it with wood screws. Now it is possible to put tension on the belt:

Download

As already mentioned I used the online CAD tool Onshape, so if you want to print it yourself you can download it here (see the tabs on the bottom for all other parts).

Learnings

After all I want to shortly write about things that I learned and will do differently in the future projects.

Model everything in CAD first

It would have saved a lot of time and also some material, if I would have taken the time to model the whole telescope (including this mounting rail) in CAD first and then assembled it virtually. Without a full model I overlooked some pieces that would collide and had to edit the pulley geometry again.

Support tolerances

The Z axis height for parts on the print bed is very accurate and usually doesn’t need any tolerance. But on supports some tolerance is absolutely required (at least with PrusaSlicer support), 0.5 mm would have been suitable in this case.

Avoid thin and sharp edges

Under normal circumstances this 3D printer does not cause noticeable corner bulging. But with very fine and sharp edges it is a problem. This could have been prevented already in the design, with placing a “valley” on the profile edge, instead of a (half) tooth.

DIY GoTo Telescope Mount [0] = Introduction and Concept

2020-07-09T00:00:00+00:00

This is the introduction to a multi part series about building a GoTo system for a Dobson style telescope mount. It should be computer controlled and be able to move to a selected target and also automatically track it. I want to use popular and inexpensive parts known from 3D printing for the mechanical setup, mostly leftovers from upgrade of my Prusa i3 printer.

Links to other Parts

Starting Point

My telescope for this project is a Bresser Messier DOB 150/750, this is a Newtonian reflector with a 150 mm (6 inch) parabolic mirror and 750 mm focal length: It includes a simple alt-azimuth “Dobson” mount, made out of wood. For the azimuth (horizontal) axis are two circular sheets of wood stacked in the base one above the other, separated with some sliding pads that allows the whole top to rotate.

The altitude (vertical) axis is also simply a rotatable mounting point, where the optical tube is attached. After loosening the screw the tube can separated from the mount base: This is a standard GP prism rail piece. Especially the four additional threaded holes are interesting, they contained M5 screws, which are not necessary for stability of the mount, so this is a good place to attach parts for the motorization.

Mechanical Concept

The idea is to keep the whole existing structure and just add motors with minimal additional material. I have seen other selfmade GoTo projects, where the whole mount was replaced with a custom structure. This is really impressive, but also very complex and I don’t have a suitable shop for serious wood working or even CNC machining metal.

I decided to use Nema 17 steppers as drive for the system. To get a suitable reduction ratio a GT2 belt will be used, with an small aluminum pulley on the motor an a large pulley connected to the telescope. All parts (like mounting brackets) should be also 3D printed.

Altitude Axis

Planned here is to construct a pulley around the prism rail, this gives about 200 mm of diameter and allows robust mounting with the M5 holes mentioned above. The stepper motor should be placed on the base plate directly below the rail/pulley and connected through a long belt loop.

Azimuth Axis

Because the base is already a large (about 400 mm diameter) circle I want to directly use it as pulley, only adding a thin profile to get solid grip with the belt. First idea was to simply glue a belt onto it with tooths facing outside. But I noticed quickly that this only works on flat surfaces, if the two layers of belt are bent around a circle the inner circumference would have to be shorter of course and the tooths with the same pitch don’t line up anymore. Only solution is to again print a custom profile taking that into account. The motor has to be protruding above the edge of the circle here.

Electronics and Software

To control the motors I want to use the quiet TMC2208 drivers, connected to an Arduino or ESP32 as main controller. First I thought about developing my own software, but then I found OnStep which looks like exactly what I need.

For usage in the field I need a battery power option. Planned is to reuse 4 cell LiPo battery packs that I already have, they provide 14.8 - 16.8 V. Anything from 12 to 36 V should be fine for the drivers and steppers though. In addition a step down to 3.3 V is required to supply the logic I/O.

As interface I want to use a laptop or phone. Stellarium is a good open source planetarium, that also supports telescope control through builtin plugins.

NAS with Autosuspend, WakeOnLAN and SSHFS Automount

2020-05-30T00:00:00+00:00

This post describes the setup of some convenient features that I deployed for the NAS, to automatically save power, make it wake up and mount it on the client only when needed.

Autosuspend

Autosuspend is a nice tool to let a server suspend if it is idle (with configurable conditions). For Fedora there is no official package available, so I installed it from source:

git clone https://github.com/languitar/autosuspend.git; cd autosuspend
python3 setup.py install --prefix=/usr
mv /usr/local/lib/python3.7/site-packages/autosuspend-3.0.0.dev0-py3.7.egg/etc/* /etc
mv /usr/local/lib/python3.7/site-packages/autosuspend-3.0.0.dev0-py3.7.egg/lib/systemd/system/* /usr/local/lib/systemd/system/

Starting with usual git clone and python module install, unfortunately the setup does not install the config and service files, so I had to move them manually afterwards.

Based on the default config this is resulting the /etc/autosuspend.conf:

[general]
interval = 30
idle_time = 900
suspend_cmd = /usr/bin/systemctl suspend
wakeup_cmd = sh -c 'echo 0 > /sys/class/rtc/rtc0/wakealarm && echo {timestamp:.0f} > /sys/class/rtc/rtc0/wakealarm'
woke_up_file = /var/run/autosuspend-just-woke-up
lock_file = /var/lock/autosuspend.lock
lock_timeout = 30

# This will use the Users check with the custom name RemoteUsers.
# Custom names are necessary in case a check class is used multiple times.
# Custom names can also be used for clarification.
[check.RemoteUsers]
class = Users
enabled = true
name = .*
terminal = .*
host = [0-9].*

# Custom
[check.SSH]
class = ActiveConnection
ports = 22
enabled = true

[check.NetworkBandwidth]
enabled = true
interfaces = eno1
threshold_send = 200
threshold_receive = 400

Three checks are enabled here, RemoteUser checks is someone is currently logged in over ssh, the ActiveConnection check on port 22 will reliably detect SSHFS connections. Also if there are other services causing some bandwidth usage it will detect it and not suspend with the last check.

After starting/enabling with systemctl enable --now autosuspend.service it should look like this in systemctl status autosuspend.service:

● autosuspend.service - A daemon to suspend your server in case of inactivity
   Loaded: loaded (/etc/systemd/system/autosuspend.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2020-05-15 12:23:19 CEST; 8h ago
     Docs: https://autosuspend.readthedocs.io/en/latest/systemd_integration.html
 Main PID: 1348 (autosuspend)
    Tasks: 1 (limit: 4536)
   Memory: 15.4M
   CGroup: /system.slice/autosuspend.service
           └─1348 /usr/bin/python3 /usr/bin/autosuspend -l /etc/autosuspend-logging.conf daemon

May 15 20:50:50 nas-server autosuspend[1348]: 2020-05-15 20:50:50,740 - autosuspend.Processor - INFO - Starting new check iteration
May 15 20:50:50 nas-server autosuspend[1348]: 2020-05-15 20:50:50,752 - autosuspend.Processor - INFO - Check SSH matched. Reason: Ports [22] are connected
May 15 20:50:50 nas-server autosuspend[1348]: 2020-05-15 20:50:50,753 - autosuspend.Processor - INFO - System is active. Resetting state

Here we see that it currently detects the SSH connection and does not suspend when I am logged in.

Wake On LAN

First make sure WOL is set up on the server and works from the client with wol xx:xx:xx:xx:xx:xx using the MAC address of the server. This usually has to be enabled in the BIOS and might also need some software, read more here.

Now we want the client to wake up the server automatically. I searched for some guidance and found this blog post, he used a custom socket that triggers WOL on connection. It works, but I observed reduced performance with this approach: instead of >900 Mbit/s it delivered only about 300 Mbit/s, because all data must go through netcat and the local socket.

So I came up with a solution where the data does not get intercepted and therefore does not impact the performance. For that an extra systemd service is running to check if the server is already up and if not sends the WOL packet. For example on ArchLinux custom services should be placed into /etc/systemd/system, I created there a nas-online.service:

[Unit]
Description=Continuously check if the host is up, otherwise try WOL on start
After=network.target network-online.target
PartOf=mnt.mount

[Service]
Environment=HOST=nas-server
Environment=PORT=22
Environment=MAC=xx:xx:xx:xx:xx:xx

ExecStartPre=/bin/sh -c 'for n in `seq 1 6`; do nc -z ${HOST} ${PORT} && break || wol $MAC && sleep 10; done'
ExecStart=/bin/sh -c 'while :; do (nc -z -w 1s ${HOST} ${PORT} && echo "Host is up!" && sleep 30) || break; done'

In the [Unit] section it is defined as PartOf mnt.mount (which we will create in the next section), this makes systemd propagate start/stop commands from the mount to this unit. The [Service] contains 2 small shell scripts. Pre start runs a maximum of 6 times a loop where it checks with nc -z (netcat zero IO) if the target is up, otherwise it sends the WOL packet and waits 10 secs. Then the main script just check every 30 secs if the target is still online and logs it. Per default this runs indefinitely, but as described above it does get stopped if mnt.mount gets inactive.

Test it with systemctl start nas-online.service, systemctl stop nas-online.service and systemctl status nas-online.service:

* nas-online.service - Continuously check if host is up, otherwise try WOL on start
     Loaded: loaded (/etc/systemd/system/nas-online.service; static; vendor preset: disabled)
     Active: inactive (dead) since Sat 2020-05-30 16:06:16 CEST; 4min 3s ago
    Process: 3589 ExecStartPre=/bin/sh -c for n in `seq 1 6`; do nc -z ${HOST} ${PORT} && break || wol $MAC && sleep 10; done (code=exited, status=0/SUCCESS)
    Process: 3768 ExecStart=/bin/sh -c while :; do (nc -z -w 1s ${HOST} ${PORT} && echo "Host is up!" && sleep 30) || break; done (code=killed, signal=TERM)
   Main PID: 3768 (code=killed, signal=TERM)

May 30 16:05:01 pc-arch systemd[1]: Starting Continuously check if host is up, otherwise try WOL on start...
May 30 16:05:04 pc-arch sh[3617]: Waking up xx:xx:xx:xx:xx:xx...
May 30 16:05:14 pc-arch systemd[1]: Started Continuously check if host is up, otherwise try WOL on start.
May 30 16:05:14 pc-arch sh[3774]: Host is up!
May 30 16:05:44 pc-arch sh[4140]: Host is up!
May 30 16:06:15 pc-arch sh[4198]: Host is up!
May 30 16:06:16 pc-arch systemd[1]: Stopping Continuously check if host is up, otherwise try WOL on start...
May 30 16:06:16 pc-arch systemd[1]: nas-online.service: Succeeded.
May 30 16:06:16 pc-arch systemd[1]: Stopped Continuously check if host is up, otherwise try WOL on start.

Automount

The Systemd automount feature can automatically mount it when an access to the mountpoint is detected and unmount if it was idle for a specified time.

First it is important to login as root with SSH and accept the fingerprint for the server, otherwise it will not work because it is not in the known hosts list (like describe here):

sudo -i
ssh -p 2222 jk@nas-server

Also it is of course not possible to enter a password, so make sure pubkey authentication is properly configured on the server.

Then an mount entry in /etc/fstab can be added:

jk@nas-server:/mnt   /mnt    fuse.sshfs  noauto,x-systemd.requires=nas-online.service,identityfile=/home/jk/.ssh/nas_ed25519,user,allow_other,default_permissions  0 0

Here we need a few options:

noauto: Disable direct mount on boot
x-systemd.requires=: Require online check/WOL to start
identityfile=: Specify the SSH keys, it will run as root and does not read the user ssh config
user: Allow user to mount/unmount
allow_other: Allow other users (than root) to access
default_permissions: Use permissions from the server

The systemd-fstab-generator will automatically produce an unit for the mountpoint, in this case mnt.mount.

Now we need another unit: mnt.automount with the simple content:

[Automount]
Where=/mnt
TimeoutIdleSec=60

Where just specifies the mountpoint, also the filename must match the mount unit filename, which is based on the path. TimeoutIdleSec enables the automatic unmount, if it was idle for at least 60 secs in this case, you might want to set this higher.

Note: With the x-systemd.automount fstab option the generator could also create the automount.service, but then the requires is applied to the automount and that would wake up the NAS always at the boot. We want to have it on the mount, because that wakes up the NAS only if it is actually mounted/used.

Finally start and enable it with systemctl enable --now mnt.automount. On any access to /mnt the automount will trigger the mount.

You can see if it triggered with systemctl status mnt.automount:

● mnt.automount
     Loaded: loaded (/etc/fstab; generated)
     Active: active (running) since Fri 2020-05-15 19:49:22 CEST; 28min ago
   Triggers: ● mnt.mount
      Where: /mnt
       Docs: man:fstab(5)
             man:systemd-fstab-generator(8)

Mai 15 19:49:22 pc-arch systemd[1]: Set up automount mnt.automount.
Mai 15 19:49:27 pc-arch systemd[1]: mnt.automount: Got automount request for /mnt, triggered by 55768 (dolphin)
Mai 15 20:02:14 pc-arch systemd[1]: mnt.automount: Got automount request for /mnt, triggered by 59368 (nvim)

and systemctl status mnt.mount:

● mnt.mount - /mnt
     Loaded: loaded (/etc/fstab; generated)
     Active: active (mounted) since Fri 2020-05-15 20:30:41 CEST; 9min ago
TriggeredBy: ● mnt.automount
      Where: /mnt
       What: jk@localhost:/mnt
       Docs: man:fstab(5)
             man:systemd-fstab-generator(8)
      Tasks: 7 (limit: 19042)
     Memory: 2.3M
     CGroup: /system.slice/mnt.mount
             ├─61440 ssh -x -a -oClearAllForwardings=yes -oport=2222 -oidentityfile=/home/jk/.ssh/nas_ed25519 -2 jk@localhost -s sftp
             └─61448 /usr/bin/mount.fuse.sshfs jk@localhost:/mnt /mnt -o rw,noexec,nosuid,nodev,port=2222,identityfile=/home/jk/.ssh/nas_ed25519,allow_other,default_permissions,user

Mai 15 20:30:40 pc-arch systemd[1]: Mounting /mnt...
Mai 15 20:30:41 pc-arch systemd[1]: Mounted /mnt.

I hope it was helpful, let me know if it worked in the comments!