However, the number of readily available GTFS schedules (so called feeds) that we are not using yet is starting to become quite small. As evident when comparing with Google Transit, there are still a number of feeds that are only privately shared with Google. This is not great from a standpoint of preventing monopolies and also a major problem for free and open-source projects which don’t have the resources to discuss with each operator individually or to even buy access to the data from them. Beyond that case, there is still a suprisingly large number of places in the world that do not publish any schedules in a standardized format, and that is something that we can fix.

Source data comes in many shapes and forms, but the ingredients we’ll definitely need are:

• the lines
• stop times
• stop locations
• and service dates

Sometimes you can find a provider specific API that returns the needed information, or there is open data in a non-standard format. In the worst case, it might be necessary to scrape data out of the HTML of the website.

Some examples:

a stop time from the API of ŽPCG (Railway in Montenegro):

Example 1:

{
    "ArrivalTime" : "15:49:16",
    "DepartureTime" : "15:51:16",
    "stop" : {
        "Latitude" : 42.511829,
        "Longitude" : 19.203468,
        "Name_en" : "Spuž",
        "external_country_id" : 62,
        "external_stop_id" : 31111,
        "local" : 1,
    }
}

It is immediately visible that we get the stop times, in for some reason extreme precision. We also get coordinates for the location, which makes conversion to GTFS much easier. Unfortunately the coordinates from this dataset are not exactly great, and can easily be off by multiple kilometers, but they nevertheless provide a rough estimate that we can improve on by matching them to OpenStreetMap.

The railway-data enthusiasts will also notice that we get a UIC country code and a stop code, which we can concatinate to get a full UIC stop identifier. We can make use of that for OSM matching later on.

Example 2:

<ElementTrasa Ajustari="0" CodStaDest="27888" CodStaOrigine="23428" DenStaDestinatie="Ram. Budieni"
    DenStaOrigine="Târgu Jiu" Km="1207" Lungime="250" OraP="45180" OraS="45300" Rci="R" Rco="R" Restrictie="0"
    Secventa="1" StationareSecunde="0" TipOprire="N" Tonaj="500" VitezaLivret="80"/>

This example is from open data for railways in Romania. Unfortunately this one does not give us coordinates, and the fact that the fields are in abbreviated Romanian doesn’t make it too easy to understand for someone like me who does not speak any vaguely related language. However looking at the numbers, we can figure out that OraP and OraS are seconds and provide the departure and arrival times. However here, the data does not model the times at stops, but the transitions between the stops, so some more reshuffling is necessary.

Example 3:

{
    "ArrivalTimes" : "12:35, 13:37, 14:02, 14:21, 14:52, 14:27, 15:04, 15:50, 16:14, 16:39, 17:08, 17:36, 18:55, 19:03, 19:12, 20:05, 20:33, 21:12, 21:47",
    "Classes" : "2",
    "DepartureTimes" : "12:35, 13:38, 14:03, 14:22, 15:12, 14:42, 15:29, 15:51, 16:15, 16:40, 17:33, 17:37, 18:57, 19:08, 19:13, 20:06, 20:34, 21:13, 21:47",
    "Route" : "Vilnius-Krokuva",
    "RouteStops" : "Vilnius, Kaunas, Kazlų Rūda, Marijampolė, Mockava, Trakiškė/Trakiszki, Suvalkai/Suwałki, Augustavas/Augustów, Dambrava/Dąbrowa Białostocka, Sokulka/Sokółka, Balstogė/Białystok, Balstogė (Žaliakalnio stotis) / Białystok Zielone Wzgórza, Varšuva (Rytinė stotis)/ Warszawa Wschodnia, Varšuva (Centrinė stotis)/ Warszawa Centralna, Varšuva (Vakarinė stotis)/ Warszawa Zachodnia, Opočnas (Pietinė stotis)/Opoczno Południe, Vloščova (Šiaurinė stotis)/Włoszczowa Północ, Mechuvas/Miechów, Krokuva (Pagrindinė stotis)/ Kraków Główny",
    "RunWeekdays" : "1,2,3,4,5,6,7",
    "Spaces" : "WHEELCHAIR, BICYCLE",
    "TrainNumber" : "33/141"
}

This example is from the, to my knowledge, only source of semi-machine-readable information on railway timetables in Lithuania. While json is straightforward to parse, this one for some reason does not use json arrays, but comma-separated lists. We can still work with this of course, until a stop appears whose name contains a comma. Oh well. Once again, no coordinates are provided. While it is tempting to think this should be easier to convert than xml in Romanian, this format has some more hidden fun. If you have been to the area the line from the example operates in, you might already have noticed that the time zone changes between Lithuania and Poland. Unfortunately, there is no notice of that in the data, just a randomly backwards-jumping arrival and departure time.

To work with this, we first need to match the stop names to coordinates, then figure out the time zones from that, and then convert the stop times.

Matching stations to locations

OpenStreetMap is the obvious choice for this. It is fairly easy to query the station locations, but matching the strings to the node in OSM is not trivial. There are often variations in spelling, particularly if the data covers neighbouring countries with different languages. The data may also have latinized names, while the country usually uses a different script and so on.

Since this problem comes up repeatedly, I am slowly improving my rust library (gtfs-generator) for this, so it can hopefully handle most of these cases automatically at some point. It aims to be very customizable, so the matching criteria needs to be supplied by the library user. The following example matches a stop if it has a matching uic_ref tag, which is a strong identifier. If no node has such a matching tag, all nodes in the radius of 20km are considered if their name is either a direct match, an abbreviation of the other spelling, similar enough or has matching words. The matching radius can be overridden in each query, so if nothing is known yet, the first guess can be the middle of the country with a large enough radius. As soon as one station is known, the ones appearing on the same route must be fairly close. The matching quality strongly depends on making a good guess of the distance from the previous stop, as it greatly reduces the risk of similarly named stations being mismatched.

Since OpenStreetMap provides different multi-lingual name tags, the order that these should be considered in needs to be set as well.

The code for matching will look something like this:

let mut matcher = osm::StationMatcherBuilder::new()
    .match_on(osm::MatchRule::FirstMatch(vec![
        osm::MatchRule::CustomTag {
            name: "uic_ref".to_string(),
        },
        osm::MatchRule::Both(
            Box::from(osm::MatchRule::Position {
                max_distance_m_default: 20000,
            }),
            Box::from(osm::MatchRule::FirstMatch(vec![
                osm::MatchRule::Name,
                osm::MatchRule::NameAbbreviation,
                osm::MatchRule::NameSimilar {
                    min_similarity: 0.8,
                },
                osm::MatchRule::NameSubstring,
            ])),
        ),
    ]))
    .name_tag_precedence(
        [
            "name",
            "name:ro",
            "short_name",
            "name:en",
            "alt_name",
            "alt_name:ro",
            "int_name",
        ]
        .into_iter()
        .map(ToString::to_string)
        .collect(),
    )
    .transliteration_lang(TransliterationLanguage::Bg)
    .download_stations(&["RO", "HU", "BG", "MD"])
    .unwrap();
    
    // Parse input

    let station = matcher.find_matching_station(&osm::StationFacts {
        name: Some(name),
        pos: Some(previous_coordinates.unwrap_or((46.13, 24.81))), // If we know nothing yet, bias to the middle of Romania, so we at least don't end up in the wrong country
        max_distance_m: match (previous_coordinates, previous_time, atime) {
            // We have previous coordinates, but nothing for this station. Base limit on max reachable distance at reasonable speed
            (Some(_prev_coords), Some(departure), Some(arrival)) => {
                let travel_seconds = arrival - departure;
                Some(travel_seconds * 70) // m/s
            }
            // No previous location known
            _ => Some(800000),
        },
        values: HashMap::from_iter([("uic_ref".to_string(), uic_ref.clone())]),
    });

For now, until I’m somewhat certain about the API, you’ll need to use the git repository directly to use the OSM matching feature.

Finally writing the GTFS file

After all the ingredients are collected, the actual GTFS conversion should be fairly easy. We now need to sort the data we collected into the main categories of objects represented by GTFS, routes, trips, stops, and stop_times.

Every trip needs to have a corresponding route. The exact distinction between different routes depends on the specific transit system. In the simplest case, if multiple buses operate with the same line number on the same day, they would belong to the same route. Each time the bus operates per day, a new GTFS trip starts.

If the system does not have the concept of routes, every trip simply is its own route. This is for example what Deutsche Bahn does for ICE trains, where each journey has it’s own train number.

The code for building the GTFS data looks somewhat like this:

    let mut gtfs = GtfsGenerator::new();

    // parse input

    gtfs.add_stop(gtfs_structures::Stop {
        id: stop_time.station_code.to_string(),
        name: Some(stop_time.station_name.to_string()),
        latitude: coordinates.as_ref().map(|(lat, _)| *lat),
        longitude: coordinates.as_ref().map(|(_, lon)| *lon),
        ..Default::default()
    })
    .unwrap();

    gtfs.add_stop_time(gtfs_structures::RawStopTime {
        trip_id: trip_id.clone(),
        arrival_time: Some(atime.unwrap_or(dtime)),
        departure_time: Some(dtime),
        stop_id: stop_time.station_code.to_string(),
        stop_sequence: stop_time.sequence,
        ..Default::default()
    })
    .unwrap();
    
    gtfs.write_to("out.gtfs.zip").unwrap();

Validating the result

A new GTFS feed is rarely perfect on the first try. I recommend running it through gtfsclean first. After all obvious issues are fixed (missing fields, broken references), you can use the validator of the French government and the canonical GTFS validator. It is worth using both, as they check for slightly different issues.

Once all critical errors reported by the validators are fixed, you can finally test the result in MOTIS. You can get a precompiled static binary from GitHub Releases. Afterwards create a minimal config file using ./motis config out.gtfs.zip. The API on it’s own is not too useful for testing, so add

server:
  web_folder: /path/to/ui/directory

to the top of the file to make the web interface available.

Make sure to also enable the geocoding option, so you can search for stops.

Now all that’s needed is loading the data and starting the server:

./motis import
./motis server

You should now be able to search for your stops and find routes:

Publishing

Once it is ready, the GTFS feed needs to be uploaded to a location that provides a stable url even if the feed is updated. The webserver should also support the Last-Modified-header, so the feed can be downloaded only when needed. A simple webserver serving a directory like nginx or apache works well here, but something like Nextcloud works equally well if you already have access to an instance of it.

Since the converted dataset needs to be regularly updated, I recommend setting up a CI pipeline for that purpose. The free CI offered by gitlab.com and GitHub is usually good enough for that. I recommend setting up pfaedle in the pipeline, to automatically add the exact path the vehicles take based on routing on OpenStreetMap data.

Once you have a URL, you can add it to Transitous and places where other developers can find it, like the Mobility Database

If you are interested in some examples of datasets generated this way, check out the Mobility Database entries for LTG Link and ŽPCG. You can find a list with some examples of feeds I generate here, including the generator source code based on the gtfs-generator crate.

You can always ask in the Transitous Matrix channel in case you hit any roadblocks with your own GTFS-converter projects.

I attended the yearly 39th Chaos Communication Congress (39C3), together with a number of KDE people and my local hackerspace Spline.

This year I wanted to attend a few more talks live and in person, which worked somewhat well. I’ll include a list of talks in the end, in case you are looking for some ideas for talks to watch on media.ccc.de.

Just like last year, I spend a large amount of time at the KDE assembly. Once again, we were part of the Bits & Bäume Habitat. My initial worries about our new location being being in a fairly dark hall instead of the bright and very visible area near the central stairs turned out to be unjustified. We received tons of great feedback and had many nice and motivating conversations with other developers and users.

Victoria started a Konqi hotline service on the Congress phone network, which was in high demand.

The most important activity for me at Congress was meeting some Transitous contributors I had not yet talked to in person. It was great to meet you all.

There were also multiple opportunities to connect with GNOME developers and designers. We identified some low-level components that we might be able to share. We exchanged our ideas for making contributing as easy as possible for new contributors, a topic which GNOME is doing fairly well at as far as I can tell.

Projects

Later on, the KDE assembly turned into a (very small) mini-KDE-Sprint. We shipped much improved maps in KDE Itinerary, based on the MapLibre project. This allows us to render vector-based tiles, which means they can be displayed at any size without visible pixels. Zooming in and out should also be much smoother. This should also fix the pixelated rendering at certain zoom level that sometimes showed with the previously used map. Another advantage is, that the map now shows labels in the local language as well as English. This makes the map much more useful in case you cannot read a locally used script. In the future, we might even be able to use map tiles that can display labels in your preferred language. A big Thanks to Volker, Carl and Tobias who helped with bundling and testing MapLibre for Android.

Afterwards, we looked into options for making a more general KDE maps application, but this will take a bit more work. However, we already have a number of great components, which should make this much easier, such as the code for accessing public transport data known from KDE Itinerary, KPublicTransport, the library for reading opening hours (KOpeningHours) and our library for accessing weather forecasts, KWeatherCore. That leaves this as mostly a matter of tying together all of these components in a nice UI. However, the Qt bindings for MapLibre don’t currently expose enough details for us to do that, so some preparation is required.

I also managed to work on a few long-standing tasks in Transitous. It is now possible to add manual configuration options to public transport feeds in France, which used to be overwritten by a script. Additionally, it is now possible to automatically add all feeds for a country from the Mobility Database, which should make adding new countries a lot easier.

Sessions

• Railway-bubble Meetup Meetup of people interested in a diverse list of railway-adjacent topics. I joined the subgroup interested in crowd-sourcing GPS positions of trains, where I presented the minimal prototype I built for Transitous.
• Transitous Meetup We met with some users of the Transitous API and apps, and exchanged ideas for future improvements. A major topic was support for accessibility features, like considering elevator status in routing. We also discussed possible ways to improve the accuracy and details of data in Germany, where schedules go through a long pipeline that loses details and introduces long delays in the delivery of changes. Thanks to Julius for organizing and moderating this.

Talks

• Zentrum für Politische Schönheit: Ein Jahr Adenauer SRP+ und der Walter Lübcke Memorial Park - A quite fun and hopeful talk, considering the broader topics covered, about the work of a political art collective in Germany.
• All my Deutschlandtickets gone: Fraud at an industrial scale Investigation into different kinds of fraud patterns based on Deutschlandtickets.
• Human microservices at the Dutch Railways: modern architecture, ancient hardware? - Insights into the operations of Dutch Railways
• Infrastructure Review - Interesting statistics on the huge scale of infrastructure involved in the Congress

As you can see, I still left a lot to watch online over the following few days.

Accepting the same terms and conditions every time gets annoying pretty quickly, so a few years ago I decided to automate this. The project that came out of that is freewifid.

It continously scans for Wi-Fi networks it knows, and sends you a notification when it found one it can automatically connect to. You can then allow it to connect to that network automatically in the future.

Adding support for new captive portals

Adding support for a new kind of captive portal is pretty easy. You just need to implement a small rust trait that includes a function that sends the specific request for the captive portal. Often this is very simple and looks like this:

pub struct LtgLinkProvider {}

impl LtgLinkProvider {
    pub fn new() -> LtgLinkProvider { LtgLinkProvider {} }
}

impl CaptivePortal for LtgLinkProvider {
    fn can_handle(&self, ssid: &str) -> bool {
        ["Link WIFI"].contains(&ssid)
    }

    fn login(&self, http_client: &ureq::Agent) -> anyhow::Result<()> {
        // Store any cookies the landing page might send
        common::follow_automatic_redirect(http_client)?;

        http_client
            .post("http://192.168.1.100:8880/guest/s/default/login")
            .send_form([
                ("checkbox", "on"),
                ("landing_url", crate::GENERIC_CHECK_URL),
                ("accept", "PRISIJUNGTI"),
            ])?;

        Ok(())
    }
}

For finding out what needs to be sent, you can use your favoute browser’s inspection tools.

For testing, Plasma’s feature for assigning a random MAC-address comes very handy.

Integration with Plasma

It could be interesting to write a KCM for freewifid, so you can graphically remove networks again. Support for ignoring public networks in the presence of a given SSID is also already implemented, but currently needs to be enabled by editing the config file. Writing a KCM is not high on my list of priorities right now, but if this sounds like something you’d like to do, I’d happily help with with the freewifid interfacing parts.

Project

The project is hosted on Codeberg. I’ll happily accept merge requests for additional captive portals there.

There are some prebuilt release binaries, but I’m not too certain they’ll work on every distribution. With a rust compiler installed, the project is very simple to build (cargo build). A systemd unit is provided in the repository, which you can use to run freewifid as a user unit.

Freewifid also supports running as a system service non-interactively for use in embedded projects.

Since these naturally are hard to find, I want to present each one here briefly. Maybe you’ll find some of them useful.

MatePay

MatePay is a small payment system developed for the student hackerspace I’m part of, Spline.

It has a small built-in shop that we have been mostly using for the beverages that we provide in the space. However it also features an API that applications can use to process payments with. We use that to run public printers in the University.

MatePay is based on a simple SQLite database, it only makes sense to use when trusting the party hosting it.

Mateprint

Mateprint is a printing web interface with a payment feature. It can also print multiple copies and double-sided pages.

It is just a simple static executable written in Rust. All the hard work is done by CUPS.

Rawqueued

Originally the public printers were all connected over the network, using HP network add-on cards. Unfortunately just like the printers these are becoming really old (~30 years), and started dying regularly lately.

Since for some reason these cards are expensive I instead decided to replace them with Raspberry Pis. I wrote a small IPP server that just forwards the payload it receives to the printer, which is pretty much what the network cards did as well.

This setup is a bit simpler than maintaining cups filters on multiple devices, so the more complicated parts can all run on a central virtual machine.

You can find the repository here.

Wasfaehrt

In the University we have a departure board in one of the student managed rooms. It is powered by the same code that also powers KDE Itinerary (KPublicTransport).

You can find it on Codeberg.

SpaceAPI

For the Spline room, we of course needed a SpaceAPI endpoint. There is a small server that provides the SpaceAPI endpoint and an API to update whether the door is open or not. The updates are sent by a daemon running on a Raspberry Pi.

We also have a little web interface running at transitous.org.

We are building this service based on great existing software, in particularly MOTIS.

Now, to make this really useful, we need data on more regions. Luckily, for most regions and countries that is fairly easy. Most transport agencies and countries make GTFS feeds available, that we can just use.

Adding an additional feed doesn’t take long and doesn’t need programming experience. It’s pretty much just creating a small text file that explains how and where to download the data from.

Those links don’t necessarily stay the same forever, so we would be happy if lots of people take care of their region, and update the link every few years. It is really little work if split up, but can’t all be handled by a small team.

To make it even easier, we can already use the Transitland Atlas feed collection, for which you just need to choose the feed to use. The url will then automatically be looked up.

You can find out how to add a feed here. Please let us know if the documentation is unclear anywhere.

If you are interested in using this service in your own application, it is probably a bit too early for production, but it makes sense to already implement support for the MOTIS API that we use. You can find an early version of our API documentation here.

If there is anything else you are interested in helping with, for example improving our ansible playbook, creating a website, improving MOTIS or working on integrating OpenStreetMap routing, you can find our open tasks here. We appreciate any help on those issues, and it of course speeds up the development of the project.

Caused by a small discussion about how it is difficult to get from Berlin to Riga by train, and in direct consequence a quick look at how the official app for trains in Latvia finds its connections, I added support for it in KDE Itinerary. KDE Itinerary is KDE’s travel planning app.

After I understood how it works, adding support for new data sources seemed pretty doable, so I directly moved on to do the same for trains in Lithuania as well.

As a result of this, it is now possible to travel from Berlin to Riga with Itinerary and continue further with the local trains there:

The connection is still far from good, but fear I can’t fix that in software.

What still does not work, is directly searching from Berlin to Riga, as that depends on having a single data source that has data on the entire route to find it. So it is necessary to split the route and search for the parts yourself.

Why you can’t always find a route even though there is one

The main data source for Itinerary in Europe is the API of the “Deutsche Bahn”, the main railway operator in Germany. Its API also has data for neighbouring countries, and even beyond that. According to Jon Worth their data comes from UIC Merits, which is a common system that railway operators can submit their routes to. However that probably comes with high costs, so many smaller operators like the ones in Latvia and Lithuania don’t do that. For that reason there is no such single data source that can route for example from Berlin to Riga.

What most of the operators in Europe do however, is publish schedule data in a common format (GTFS). What is missing so far, is a single service that can route on all of the available data and has an API that we can use. Setting something like this up would require a bit of community and hosting resources, but I am hopeful that we can have something like this in the future.

In the meantime, it already helps to fill in the missing countries one by one, so at least local users can already find their routes in Itinerary, and for Interrail and other cross border travel, people can at least patch routes together.

More countries

The next country I worked on was Montenegro. The reason for that is that it is close to the area that the DB API can still give results for, and also still has useful train services. Getting their API to work well was a bit more difficult though, as it doesn’t provide some of the information that Itinerary usually depends on. For example coordinates for stations. Those are needed to select where to search for trains going from a station. Luckily, exporting the list of stations and their coordinates from OpenStreetMap was relatively easy and provided me with all the data I needed.

Thanks to that Itinerary can now even show the route on a map properly.

Now only the API for Serbia is missing to actually connect to the part of the network DB knows about.

The new backends are not yet included in any release, but you can already find them in the nightly builds. Be aware that the nightly builds have switched to Qt6 and KF6 faily recently, which means there are still a few rough edges and small bugs in the UI.

On Linux, you can use the nightly flatpak:

flatpak install https://cdn.kde.org/flatpak/itinerary-nightly/org.kde.itinerary.flatpakref

On Android, the usual KDE Nightly F-Droid repository has up to date builds.

Since I run lots of stuff on small arm boards (for example this website), I need my CI jobs to create arm executables. The easiest way to get that done is to just compile on arm devices, so I was happy to see that Hetzner is now offering arm nodes in their cloud offering.

To make that as cheap as possible, the CI should ideally create a VM before running its job, and remove it again afterwards. Unfortunately Woodpecker does not seem to support that out of the box at this point.

My solution to that was to build a docker proxy, that creates VMs using docker-machine, and then proxies the incoming requests to the remote VM. That works really well now, so maybe you will find it useful.

Setting that up is reasonably simple:

• Install docker-machine. I recommend using the fork by GitLab
• Install the backend for your cloud provider. For Hetzner I use this one
• Grab a binary release of docker-proxy (if you need arm executables), or compile it yourself.
• Create a systemd unit to start the service on boot in /etc/systemd/system/docker-proxy.service. This particular one just runs it on the woodpecker-agent user that you may already have if you use Woodpecker CI.

[Unit]
Description=Docker CI proxy
After=network.target

[Service]
User=woodpecker-agent
Group=nogroup
Restart=always
ExecStart=/usr/local/bin/docker-proxy

[Install]
WantedBy=multi-user.target

• Fill in /etc/docker-proxy/config.toml This example works for Hetzner, but everything that has a docker-machine provider should work. You just need to supply the arguments for the correct backend.

[docker_machine]
driver="hetzner"
args=[
    "--hetzner-api-token=<token>",
    "--hetzner-server-type=cax11",
    "--hetzner-image-id=103907373",
]

[general]
timeout=300
port=8000

• Finally, make woodpecker-agent use the new docker proxy, by setting DOCKER_HOST=http://localhost:8000 in its environment.

I hope this may be useful for you as well :)

It also features a migration system and automatic result deserialization.

For examples, please have a look at the README.

You can fetch the release from KDE’s download server. It is signed with my PGP key C3D7CAFBF442353F95F69F4AA81E075ABEC80A7E, which you can fetch from keys.openpgp.org.

Please let me know if you find any issues.

Notable new features

Library

AudioTube now has a library, in which you can see your favourite, most often and recently played songs.

Filtering through previous searches

This allows searching through locally known songs and previous search terms, without even sending a request to youtube.

Lyrics

While playing a song, you can now see the lyrics of the song in a separate tab.

User Interface improvements

Finally, AudioTube displays album covers everywhere. Devin Lin has redesigned and improved the actual audio player. Mathis Brüchert has done several design improvements across the board, like rounded album covers, improved spacing.

The support for wider screens has also been improved, and the queue list will now only expand up too 900 virtual pixels.

Fixes

Fetching thumbnails is now much faster, since in most cases the thumbnail ID can be reliably predicted, without querying yt-dlp. In the few remaining cases, querying yt-dlp is still the fallback

Install

If you want to try AudioTube, you can get the latest stable version from flathub. If you want the latest improvements, which are usually already reasonably stable, you can grab a nightly build from the KDE Nightly flatpak repository.

Code improvements

While developing the library feature, a small new library was developed. I called it FutureSQL, after the QFuture type it uses for most parts of its API. FutureSQL provides an asynchronous API for QtSql, by running the database queries on a separate thread. It also provides convinient template functions for passing parameters to SQL queries.

Possibly the most interesting feature is automatically deserialize the resulting data from an SQL query into a struct. This works thanks to C++ templates.

In the simplest cases, nothing but

struct Song {
	using ColumnTypes = std::tuple<QString, QString, QString, QString>;

	QString videoId;
	QString title;
	QString album;
	QString artist
}

is required.

The library version of this code does not yet have a stable release, however you can already try the API if you build the library from the repository.

This is about a SIGMA SM 8200i typewriter, which my parents gave to me for entertainment purposes when I was a child. Now that I’m older, the entertainment has shifted more towards the technical internals.

When we talked about teletype technology at my local university hackerspace, Spline, I remembered the typewriter had a 26-pin connector. After some research, I learned that the machine is basically an Erika S3004, one of the most popular typewriters of the GDR, in a different case. With this new knowledge, I was able to find a table of commands which can be sent and received from the device.

The 26-pin connector is a port used in the GDR, which speaks a faily standard rs232 protocol, with a baud-rate of 1200. In fact, the USB TTL adapter I usually use for routers, worked on it after some creative wiring.

The commands that can be sent and received over the serial interface can be separated into two groups: control codes and character codes. Unfortunately the typewriter does not support unicode … or ASCII. So the first step was encoding and decoding the “gdrascii” codec, like the Chaostreff Potsdam people like to call it. Luckily, I could just do a pretty-much 1:1 translation of the python code from Chaostreff Potsdam into rust.

For those interested in rust: The new gdrascii_codec crate exposes mostly const API, which allows to write strings in unicode in the source code for readability, but already translating them into gdrascii at compile time.

After also implementing the control codes from the table, plus some glue code for opening the serial connection with the correct parameters, I could do the first prints.

The second feature I wanted to support was keyboard input, since the typewriter supports a mode in which it sends keyboard input over the serial connection instead of printing it. This was quite easily possible using the linux kernel uinput API. The only complication was, that the typewriter already sends ready made character codes, but the linux kernel expects to receive raw keypresses.

For the character “L”, the Linux kernel expects “(Left Shift or Right Shift) + L”, so this could just be translated back.

Once that was all done, I ordered a proper connector so that I could easily put everything back together after putting it in the drawer.

As always, the source code is open source. This time I published it on Codeberg, together with some documentation on how to wire the device to a serial adapter.

And for those wondering what this project was useful for: probably nothing 😁. It’s just cool that technology from such different times still works together so well.