~derf
dark mode

You have reached the personal homepage of an on-line entity known as derf / derfnull. Hi! 👋

About

I enjoy doing things and post some of them on this website. Things may include taking photos, poking at public transit APIs, or putting caffeine into chocolate. Blinkenlights and embedded development are nice, too, though I don't really get around to that anymore.

At work, I research performance modeling and performance-aware configuration methods for software and hardware product lines. Please refer to my professional website for details.

Resources

Contact

You can reach me by E-Mail (d​erf@fina​lr​ewind.org) and on IRC (derf0 @ oftc, hackint). My PGP key for E-Mail encryption is 781BB707 1C6BF648 EAEB08A1 100D5BFB 5166E005. I occasionally post stuff on the Fediverse (@derf@social.skyshaper.org). Outside of the internet, there is a good chance of finding me at the Chaosdorf Häkelspace hackspace.

The remainder of this page duplicates a curated sub-set of projects and the latest blog entries.

Projects

Travel::Routing::DE::VRR v2.20
Interface to EFA-based itinerary services
> efa Essen Martinstr Düsseldorf Hbf
14:34 ab  Essen Martinstr.: Bstg. 1      Straßenbahn 108      Essen Altenessen Bf Schleife
14:38 an  Essen Hauptbahnhof: Bstg. 1

14:47 ab  Essen Hauptbahnhof: 2          R-Bahn RE11 (RRX)    Düsseldorf Hbf
15:24 an  Düsseldorf Hbf: 10
Travel::Status::DE::HAFAS v4.07
Interface to HAFAS-based arrival/departure monitors
> hafas-m 'Hamburg Dammtor'
14:43  +45  ICE 2922  Hamburg-Altona
15:10       U 1       Ohlstedt, Hamburg
15:10  +4   Bus 112   Osterbrookplatz, Hamburg
15:10       NBE RB61  Itzehoe
> db-iris 'Dortmund Hbf'
14:38 +16  IC 2027     Passau Hbf            11
14:39      ABR RE11    Kassel-Wilhelmshöhe   8
14:41      RE 57       Winterberg(Westf)     2
└────      RE 57       Brilon Wald           2
14:41      S 5         Hagen Hbf             5
14:42      S 2         Dortmund Hbf          6
14:45 +1   RE 1        Aachen Hbf            16
zlib-deflate-nostdlib
embedded decompression library
TODO!

News

Travel-Status-DE-DeutscheBahn-4.07.tar.gz (signature)

  • hafas-m: Fix uninitialized value warnings in "--list" output
  • Improve support for non-DB HAFAS instances
  • Fix day change handling in departure board mode. Previously, journeys arriving / departing after midnight had wrong timestamps in some cases.

Travel-Status-DE-DeutscheBahn-4.06.tar.gz (signature)

  • HAFAS->station: rename "uic" to "eva"; add "names" and "evas" keys
  • Rename Journey->station_uic to Journey->station_eva

Travel-Status-DE-DeutscheBahn-4.05.tar.gz (signature)

  • StopFinder: add new_p constructor for async requests via promises

Travel-Status-DE-DeutscheBahn-4.04.tar.gz (signature)

  • Journey->is_cancelled: correctly report cancellations in station board mode

Travel-Status-DE-DeutscheBahn-4.03.tar.gz (signature)

  • HAFAS: Add "station" accessor
  • Journey: Add station, station_uic and line_no accessors
  • Journey->line now returns journey type as well as line number
  • Journey->line_no provides the old Journey->line behaviour
  • Journey: Add route_interesting accessor

Travel-Status-DE-DBWagenreihung-0.07.tar.gz (signature)

  • Add ICE 3neo (model 408)
  • DBWagenreihung: Rename train_powertype to wagongroup_powertype
  • DBWagenreihung: Rename train_desc to wagongroup_description
  • DBWagenreihung: Rename train_model to wagongroup_model
  • DBWagenreihung: Rename train_subtype to wagongroup_subtype

I have a growing collection of mostly cheap buck/boost converters and am kinda curious about their efficiency and output voltage stability. Measuring that typically entails varying input voltage and output current while logging input voltage (V_i), input current (I_i), output voltage (V_o), and output current (I_o). For each reading, efficiency is then defined as (V_o · I_o) / (V_i · I_i) · 100%.

+-------------+
|             |
|    Input    |
|             |
+---+-----+---+
    |     |
    |     +-+
    |      I_i
    |     +-+
    +-V_i-+
    |     |
+---+-----+---+
|             |
|  Converter  |
|    under    |
|    Test     |
|             |
+---+-----+---+
    |     |
    +-V_o-+
    |     +-+
    |      I_o
    |     +-+
    |     |
+---+-----+---+
|             |
|    Output   |
|             |
+-------------+

The professional method of obtaining these values would probably involve a Source/Measure Unit (SMU) with 4-wire sensing and remote control to automatically vary input voltage / output current while logging voltage and current readings to a database. I do not have such a device here -- first, they tend to cost €€€€ or even €€€€€, and second, many of those are more at home in the single-digit Watt range. I do, however, have a lab PSU with remote control and access to output voltage and current readings, a cheap electronic load (without remote control), an ADS1115 16-Bit ADC for voltage measurements, and an ATMega328 for data logging. This allows me to manually set a constant output current I_o and then automatically vary the input voltage while logging V_i, I_i, and V_o.

There is just one catch: The ADS1115 cannot measure voltages that exceed its input voltage (VCC, in this case 5V provided via USB). A voltage divider solves this, at the cost of causing a small current to flow through the divider rather than the buck/boost converter under test. In my case, I only had 10kΩ 1% resistors at hand, and used them to build an 8:1 divider for both differential ADS1115 input channels. This way, I can measure up to 40V, with up to 500µA flowing through the voltage divider. Compared to the 100 mA to several Amperes I intend to use this setup with, that is negligible.

V_i + ----+                  VCC  GND           VCC  GND
         70k                   |  |               |  |
          +--+ +------------+  |  | +-----------+ |  |
         10k +-+A0          +--+  | |           +-+  |
V_i - ----+-+  |            |     | |           |    |
            +--+A1          +-----+ |           +----+
V_o + ----+    |  ADS1115   |       | ATMega328 |
         70k+--+A2       SCL+-------+SCL      TX+--------to USB-Serial converter
          +-+  |            |       |           |
         10k +-+A3       SDA+-------+SDA        |
V_o - ----+--+ +------------+       +-----------+

Of course, this whole contraption is far from certifiably accurate or ppm-safe, and even less so when looking at the real-world setup on my desk.

I did however find it to be accurate within ±10mV after some calibration, so it is sufficient to determine whether a converter is in the 80% or 90% efficiency neighbourhood and whether it actually outputs the configured 5.2V or decides to go up to 5.5V under certain load conditions. Luckily, that is all I need.

The bottom line here is: If you have sufficiently simple / low-accuracy requirements, cheap components that may already be lying around in some forgotten project drawer can be quite useful. Also, I really like how easy working with the ADS1115 chip is :)

I'm running a Home Assistant instance at home to have a nice graphical sensor overview and home control interface for the various more or less DIY-ish devices I use. Since I like to monitor the hell out of everything, I also operate an InfluxDB for longer-term storage and fancy plots of sensor readings.

Most of my ESP8266 and Raspberry Pi-based DIY sensors report both to MQTT (→ Home Asisstant) and InfluxDB. For Zigbee devices I'm using a small script that parses MQTT messages (intended for Zigbee2MQTT ↔ Home Assistant integration) and passes them on to InfluxDB. However, there are also devices that are neither DIY nor using Zigbee, such as the storage and battery readings logged by the Home Asisstant app on my smartphone.

Luckily, Home Assistant has a Rest API that can be used to query device states (including sensor readings) with token-based authentication. So, all a Home Assistant to InfluxDB gateway needs to is query the REST API periodically and write the state of all relevant sensors to InfluxDB. For binary sensors (e.g. switch states), this is really all there is to it.

For numeric sensors (e.g. battery charge), especially with an irregular update schedule, the script should take its last update into account. This way, InfluxDB can properly interpolate between data points, producing (IMHO) much prettier graphs than Home Assistant does. If you also want to extend your Home Assistant setup with InfluxDB, c hass to influxdb may be a helpful starting point.

Travel-Status-DE-IRIS-1.79.tar.gz (signature)

  • Stations: Further geoocordinate fixes for Dutch stations.

Travel-Status-DE-IRIS-1.80.tar.gz (signature)

  • Update stations list
  • Fix MANIFEST (broken in 1.79)

Travel-Status-DE-IRIS-1.78.tar.gz (signature)

  • Stations: Fix geocoordinates for a variety of Dutch stations. In some cases, they were off by several hundred kilometers.

Travel-Status-DE-IRIS-1.77.tar.gz (signature)

  • Handle "Betriebsstelle nicht bekannt" in routes.
  • Update station list

Travel-Status-DE-IRIS-1.76.tar.gz (signature)

  • Improve handling of stations that are not yet present in IRIS ("Betriebsstelle nicht bekannt 1234567")
  • Update station list

Travel-Status-DE-IRIS-1.75.tar.gz (signature)

  • Update station list
  • Note that station names are no longer considered unique. get_stations() and the get_station_by_… set of functions may return multiple entries with the same name, but different DS100 and EVA IDs. For now, get_station_by_name() retains its behaviour of only returning a single match if the name matches exactly – for multiple stations with the same name, it returns the one with the lowest EVA number. get_station_by_name() return value and semantics may change in a future major release.