I couldn’t help but think of a quote by Horst Lichter (from the German talk show Riverboat) that hits the nail on the head:

“You have irretrievably stolen 20 minutes from my finite life that I could not spend in a self-determined way. That really stuck with me for the rest of my life, so that no matter when, no matter where, I’m always early, because I can determine my own time, but I don’t want to steal other people’s.”

To finally end this madness in everyday working life, I’ve come up with a few personal rules. Starting with what is often called “Japanese punctuality” – a philosophy we should urgently adopt:

My Rules for Better Conference Calls

Rule 1: 10:00 means 10:00 – not “I’m starting to look for the link now”

If a meeting is scheduled for 10:00, it means in Japan (and in my ideal world) that the actual content work starts at exactly 10:00. This requires that you don’t start looking for the dial-in link at 10:00 and 30 seconds, only to find that the headset isn’t connected or that Teams wants to install a critical update.

Punctuality means being ready when the clock strikes. It’s a form of professionalism to do the tech check and the dial-in early enough to be present at the start. Anyone who clicks the link at 10:00 sharp is actually already late – because they are stealing the time from everyone else who has to wait for their personal “setup time.”

Rule 2: Greet first, then silence (and mute)

As soon as you’ve dialed in, a brief “hello” introduction is naturally good manners – provided the framework and group size allow it. But immediately after that, the first move should be to the mute button.

There’s hardly anything more disruptive in a conference call than the rhythmic clattering of a mechanical keyboard, heavy breathing directly into the microphone, or the siren of an ambulance passing by the home office. Discipline in the conference also means acoustic discipline. Anyone who only opens their microphone when they really have something to contribute shows respect for the concentration of all other participants. Background noise is not just annoying; it’s an avoidable disruptive factor that undermines the efficiency of the entire meeting.

Rule 3: Video with care – bandwidth is a precious resource

Another point that is often underestimated: the webcam. In times of “video-first” cultures, it may sound old-fashioned, but I plead for an economical use of the camera. It makes the most sense if primarily the person currently speaking transmits their video.

This has nothing to do with being camera-shy, but simply with technical respect. Every video signal consumes bandwidth – for all participants. No matter how “thick” your own line at home or in the office is, you never know under what conditions your colleagues are participating (perhaps via an unstable mobile hotspot on a train or in a region with poor network coverage). By limiting the flood of video, we ensure that the audio quality remains stable and the conference runs smoothly for everyone. This is also a form of appreciation: not unnecessarily straining the technical resources of the person opposite.

Rule 4: Audio quality is not a luxury, but empathy

Anyone who regularly takes part in digital meetings should invest in decent hardware. A good microphone is not just a technical gimmick, but a sign of respect and empathy towards the listeners.

There’s little more exhausting than listening to a tinny, choppy, or noisy voice for 60 minutes that sounds like it’s coming from a tin can in a tunnel. Every “Excuse me?”, “Can you repeat that?” or “What did you say?” not only costs time but also robs all participants of a massive amount of concentration. Anyone who ensures that they can be understood clearly and distinctly minimizes the cognitive load on their colleagues. You save them the energy they would otherwise have to spend laboriously filtering the words out of the noise. Good audio hardware is an investment in the time and nerves of all participants.

Rule 5: Visual calm – backgrounds and profile pictures

Not only the acoustics but also the visuals play a role in concentration. Anyone using their webcam should ensure a calm, non-distracting background. Blurred motifs or simple, professional backgrounds are the best choice here. A cluttered shelf in the background or family members walking through the picture automatically draw attention away from what is being said.

The same applies to profile pictures: these should have a scope barely larger than a classic passport photo. A clear, calm portrait helps the other participants to assign the voice to a face without being distracted by too many details or restless surroundings in the small preview image. This is also an aspect of “visual discipline”: we reduce unnecessary input for our colleagues to the essentials.

Rule 6: The “Raise Hand” function – discipline in large groups

Especially in larger groups or during heated discussions, the “raise hand” function is not a nice extra but should be an absolute requirement. Anyone who just starts talking risks not only interrupting others but often creates an acoustic chaos in which nobody is understood in the end.

Waiting patiently until called upon by the moderator or the speaking person is a sign of professionalism. It ensures a structured conversation culture in which every contribution gets the space it deserves – without degenerating into a digital “whoever screams the loudest is heard.” This also saves time in the end because fewer sentences have to be said twice or at the same time.

Rule 7: Mandatory Agenda – No goal without a roadmap

A point concerning preparation: in my view, a clear agenda is an absolute requirement for every conference call. This starts with the title: a meaningful subject line helps all participants to mentally prepare for the topic.

Receiving an appointment that only contains a cryptic short title and the dial-in data is, in my opinion, simply unacceptable. All participants should know in advance which points will be discussed so that they can prepare. There is also a duty to cooperate here: anyone who has additions or changes to the agenda should report them promptly – and the creator must incorporate them.

Even in small 1:1 rounds, a short roadmap is helpful to avoid getting sidetracked. Without an agenda, a meeting quickly turns into a coffee klatch at the expense of working time. Only those who know the goal can take the direct route there.

Conclusion: Time is Life

At the end of the day, all these rules are not about mere etiquette or pedantic order. It’s about respect. When we are on time, have our technology under control, and approach meetings in a structured way, we signal to our colleagues: “I value your time. I know that you have other tasks and a life outside of this screen.”

The quote from Horst Lichter may sound harsh at first, but it hits the heart of the matter. Every minute we spend silently in a waiting loop or lose through technical inadequacies is irretrievably gone. It’s time we can’t use for productive work and that we might miss at the end of the day to finish on time.

Let’s stop viewing other people’s time as an infinite resource that we can dispose of freely. Punctuality and digital discipline are the simplest ways to show appreciation in everyday working life. Let’s just start tomorrow – preferably five minutes before the actual appointment.

It is amazing what you can see when you look at the data over several years (2022 to present). We are again a bit nerdy on the terminal, using Python and Matplotlib for the visualization.

Here are the comparative evaluations of daily maximum and minimum temperatures for each month. The colors represent the different years:

• 2022: Purple (Data from November)
• 2023: Green
• 2024: Cyan
• 2025: Pink
• 2026: Yellow/Orange (Data until April)

Yearly Overviews (Smoothed)

To provide a better overview of the trends, this summary shows the progression over the entire year. The data has been smoothed by dividing each month into 5 segments (approx. 6-day intervals). This removes the daily “spikes” and makes the seasonal trend visible.

My database contains some interesting extremes: The hottest day so far was July 2nd, 2025, with a solid 36.2 °C. On the other hand, January 11th, 2026, holds the cold record with a frosty -17.7 °C.

Looking at the average temperatures, it is clear that 2024, with an average of approx. 11.5 °C, was slightly warmer than 2023 (11.2 °C).

Rainfall Comparison

Besides temperature, rainfall is one of the most important parameters. December 2023 stands out, being the wettest month in my records with a total of 122.4 mm of precipitation.

The diagrams show the total monthly amount and the number of days it rained (at least 0.1 mm). It is quite visible that 2024 was generally a “wet” year compared to the others.

Sunshine Comparison

How many hours does the sun shine? For this analysis, I count every period where the light intensity at the station reached at least 20 klux as a “sunshine hour”. This is a good indicator for direct sunlight or at least a very bright sky.

The sunniest year so far was 2024 with a total of 1,421 sunshine hours. The diagram below shows the smoothed daily averages per month.

Monthly Detailed Views

For those who want to know more, you can find the raw daily values in direct comparison across the years here. You can also see the gaps in the data where the station didn’t feel like logging or the server had a hiccup.

January

February

March

April

May

June

July

August

September

October

November

December

In this post, I want to look back at my experiences and highlights of the event.

Friday, March 27th

My journey to this year’s Linux-Tage began on Friday afternoon. I set off from Grimma at exactly 3:00 PM. The drive took me along country roads via Colditz, Geithain, and Narsdorf before finally hitting the A72 motorway toward Chemnitz.

My first stop in Chemnitz was the TU’s main lecture hall building (Hörsaalgebäude). As soon as I arrived, I picked up my event badge – the official starting signal for a long and eventful weekend as a volunteer and exhibitor.

After that, I checked into my hotel. As soon as I got to my room, I set up the most essential equipment first: my D-Star hotspot and my radio. This meant I was immediately back “QRV” in Chemnitz and ready for some exchanges over the air.

However, I didn’t stay in my room for long, as the traditional pre-event at Turmbrauhaus started at 6:30 PM. As in previous years, the upper floor was packed. With great food (luckily the menu has everything from meat to vegan), it was the perfect time for those first deep conversations with other attendees who had also arrived on Friday. It’s the ideal way to get into the right mindset for the upcoming two days.

A big thank you to Silke for the great post to set the mood:

Silke @freiefunken@mastodon.social

Mastodon Post von User Silke (@freiefunken@mastodon.social)

mastodon@mastodon.social:~$ cat toot.txt

Du kommst zu den Chemnitzer Linuxtagen und reist auch schon am Freitag an?
Komm doch zum Abendessen ins Turmbrauhaus!

Wir sind in der oberen Etage im vorderen, den Fenstern zugewandten Bereich (nicht in der Mälzerstube).

Zeit: Freitag, dem 27. März 2026 ab 18:30 Uhr
Ort: Turmbrauhaus, Neumarkt 2, 09111 Chemnitz
https://www.openstreetmap.org/way/1014038458
Speisekarte (alles von Fleisch bis vegan): https://turmbrauhaus.de/wp-content/uploads/2025/11/2025_11_internet_karte.pdf

Gerne boosten und weitersagen!

#CLT2026 #chemnitz #linux #freesoftware #turmbrauhaus

12:21 PM • March 8, 2026 (UTC)

Another interesting find of the evening was a flyer for the 3. Open Source Hardware Conference (OSHap), taking place from September 23rd to 24th, 2026, in Halle (Saale). Under the motto “Think open. Build open.”, they are currently calling for participation (Call for Participation). Since the topic of Open Source Hardware aligns perfectly with my interests (like the Sharp PC-E500S or RISC-V), I’m seriously considering attending the event in Halle this September. More information is available at www.oshop-network.de.

Saturday, March 28th

The first full day of the event was particularly busy but also very exciting for me. This year, I was active as a volunteer in the VOC team (Video Operation Center).

My main task was live-editing the streams of the talks. This involves switching between different camera angles and the speakers’ slides to ensure that online viewers can follow the presentations as smoothly as possible.

My first assignment of the day started at 11:00 AM in Room V6. On the schedule was a highly topical subject: “The Cryptocalypse: Post-Quantum Cryptography and Open Source”. This 60-minute session by Stefan Schumacher covered the massive challenges that quantum computers pose to our current encryption methods.

Here’s a quick summary of the key takeaways:

• The Problem: Algorithms like Shor (breaking RSA and ECC) and Grover (halving the security of symmetric methods like AES) mean that quantum computers threaten the foundations of our digital security.
• The Solution (PQC): The NIST standardization process has already announced the first winners. These include ML-KEM (Kyber) for key encapsulation, and ML-DSA (Dilithium) and SLH-DSA (Sphincs+) for digital signatures.
• Open Source Pioneers: Projects like Open Quantum Safe (OQS) are playing a vital role. With the oqsprovider for OpenSSL, hybrid methods combining classic and post-quantum cryptography can already be used today.
• Recommendations: We should focus on crypto-agility, implement hybrid schemes, and create a “crypto inventory” to know where encryption is being used across our systems.

It was technically demanding, which made it an exciting challenge for my first live edit of the day.

In the afternoon, at 2:00 PM in Room V5, we moved on to a practical topic for network enthusiasts: “Containerlab – Simulating Datacenter Networks in the Lab”. Robert Sander (Heinlein Consulting) provided a deep dive into this project, which started at Nokia five years ago and has since built a strong community.

What’s particularly fascinating about Containerlab is the ability to map complex data center structures using resource-efficient Linux containers. Since modern router hardware often uses the Linux kernel, many vendors provide their firmware as container images. For anything that doesn’t run natively on Linux, traditional VMs can also be integrated. Sitting at the video switcher, it was interesting to see how quickly and efficiently entire topologies can be spun up and down without needing a rack full of hardware.

The conclusion of my VOC shift that day was at 3:00 PM (also in Room V5) with the talk “bindzwirn: Linux Port Permissions via eBPF” by Pluto.

In self-hosting scenarios, whether at home or on a VPS, isolating services through separate Unix accounts (e.g., using rootless Podman containers) is best practice. The issue is that Linux lacks native permissions for IP ports. Pluto presented bindzwirn, a modern eBPF-based drop-in replacement for the aging authbind. Thanks to eBPF, access to specific ports can be restricted to specific accounts, effectively preventing attacks from compromised services. A very exciting project that demonstrates how powerful eBPF is for elegantly extending kernel functionality. (And I secretly wondered: is Pluto actually a fan of Neil deGrasse Tyson? 😉)

Relaxed Evening: “Chemnitzer Catering-Tage”

Following Saturday’s official program, there was a wonderful evening event for all volunteers, speakers, exhibitors, and sponsors. As is tradition, it was jokingly referred to as “Chemnitzer Catering-Tage” (Chemnitz Catering Days) – the food was excellent once again and provided the perfect setting for some relaxed networking away from the exhibition floor’s hustle and bustle.

A Special Highlight: Overnight Hardware Rescue

In between the event days, I had a very personal success story. I had brought along my old Sharp PC-E500S Pocket Computer, which unfortunately had lost its display contrast and showed ugly black bars – a typical aging issue with the capacitors.

As I didn’t trust myself with the delicate repair job, I sought help at the soldering workshop. An incredibly helpful participant (whose name I unfortunately forgot in all the excitement) offered to take a look at it overnight.

And it worked: He replaced the two faulty 3.3μF SMD electrolytic capacitors (16V and 25V) with robust tantalum ones. The next day, I was greeted by a flawless, clear display! I’m absolutely thrilled, as I plan to use this classic device as a Ham Logbook for amateur radio later. A huge thank you to my unknown rescuer!

Sunday, March 29th

On Sunday, I switched perspectives: from the VOC team’s video switcher to the stage. At 11:00 AM in Room K2, I hosted the Keysigning Party I had organized.

It’s always impressive to see how many people are passionate about digital sovereignty and encryption. My goal was to strengthen the Web of Trust. The process is as analog as it is effective:

1. Hash Sum Verification: First, we ensured that every participant had the same, up-to-date key list.
2. Identity Verification: In a long line, participants compared fingerprints and verified identities using official photo IDs.
3. Building Trust: This face-to-face interaction is the foundation for later signing other participants’ keys at home with a clear conscience.

As the organizer, my job was to lead through the process, answer GnuPG-related questions, and ensure everything ran smoothly. Despite the technical nature of the topic, the focus was on human interaction.

CTF Challenge with a Handicap

The CTF-Challenge by secunet Security Networks AG also kept me busy on Sunday. As it is every year, it was a major highlight for me, even though the challenge was twofold this time: I had to deal with massive firmware issues with my laptop’s WiFi chip (which unfortunately are still ongoing). Despite this technical handicap, I managed to solve several levels, even if I couldn’t complete the entire challenge this time around.

Here’s a glimpse into the technical puzzles I had to crack:

• Getting Started & Hashing: After the initial simple steps, it was all about extracting passwords from text files or calculating them using deprecated hash algorithms like MD5 from binary data.
• Archive Gymnastics: One level involved analyzing a bzip2 archive that, once decompressed, turned into a massive, mostly empty file. The solution was hidden in scattered ASCII characters buried at specific offsets.
• Socket Voodoo: Particularly exciting was accessing a Wireguard Unix socket (/var/run/wireguard/wg0.sock). By sending specific commands using socat, I was able to extract the private key needed for the next level.
• Metadata Forensics: In a higher level, I had to inspect 64 directories for their timestamps. Only by meticulously comparing Modify vs. Change times could the correct puzzle pieces for the next password be assembled.
• SSH Tricks: Finally, it came down to manipulating SSH environment variables (SendEnv) to bypass shell restrictions.

It’s the spirit of the competition that counts, and even with the handicap, it was a blast once again!

After the party, I stayed until the official end of the event. At 6:00 PM sharp, as the doors were closed, I headed home with many new impressions.

Conclusion

It was great to be back in Chemnitz! In addition to all the local experiences, there was also a major technical change to this website during the weekend: All graphics and images have moved from GitHub to Cloudflare R2 storage. This step was necessary as the Git repository was becoming too large due to the many images. While they have found their new home there, I’m not yet entirely sure if everything is working exactly as I’d like regarding caching and S3. I’ll likely need to do some fine-tuning over the next few days.

[frank@do3eet-terminal ~]$ cat /etc/privacy/offlinetags.conf
# Consent Communication Protocol v2.0
# STATUS: ALL 6 TAGS ACTIVE

If you spend a lot of time at barcamps, hackathons, or amateur radio meetings, you know the problem: Am I allowed to post this photo? Who is that in the background? And how do I signal myself what should happen with pictures of me?

This is exactly where Offlinetags come in. They are a social signal for humans – and at the same time, machine-readable markers for algorithms. Since I submitted a Pull Request today to expand the set to 6 symbols, here is the guide for all photographers and tag-wearers (including the new proposals).

1. Tag Me (Green)

The "all-round carefree package" for digital utilization.

• May: Take photos, publish, tag, and apply facial recognition procedures.
• Should ask: In very sensitive contexts, briefly check if a specific platform (e.g., Facebook vs. Mastodon) is okay.
• Do not: Actually nothing – the wish for digital visibility is clearly formulated here.

2. Upload Me (Yellow)

Publication yes, tracking no.

• May: Take the photo and post it publicly on the web.
• Should ask: If you still want to mention the person by name (credits), you should check briefly.
• Do not: Manual tagging in social networks or enriching with metadata for facial recognition.

3. Blur Me (Blue)

Presence yes, identity no.

• May: Photograph the person, provided they are made unrecognizable before publication.
• Should ask: Whether simple pixelation is enough or if the face should be completely "covered."
• Do not: Publish the original image without editing. Facial recognition algorithms must not run over this under any circumstances.

4. No Photos (Red)

The clear boundary.

• May: Point the camera in another direction.
• Should ask: Nothing. The wish for privacy is absolute.
• Do not: Any recording of the person. Also no "back views" or "you can only see a little bit" – respect for the wish comes first.

New (Proposed via Pull Request):

5. Name Me (Purple)

Visibility for credits.

• May: Photograph and publish.
• Should ask: Exactly how the naming should be done (real name, callsign, or nickname?).
• Do not: Publication without clear identification of the author or person depicted. Here's the "deal": photo for fame!

6. Blur Screen (Teal)

The new standard for tech events.

• May: Photograph the foreground (people, hardware).
• Should ask: If you are unsure whether a screen in the background shows critical data (code, passwords, emails).
• Do not: Publish uncensored screen content in the background. Before the image goes online, every monitor in the image area must be made unrecognizable.

It is particularly worth noting that the entire project has been consistently published under CC0 1.0 (Public Domain). I think it’s excellent that these symbols and the underlying idea are truly available to everyone without condition – no legal hurdles, entirely in the spirit of the public good.

[frank@do3eet-terminal ~]$ systemctl status privacy-awareness
● privacy-awareness.service - Respect for Human Signals
   Active: active (running) since Mon 2026-03-23 13:37:00 CET

Offlinetags are a powerful tool to bring the discussion about digital privacy from theory into practice. Which tag will you wear at the next event?

Get typing (or radio me)!

By the way, I will definitely be wearing the Name Me and Blur Screen tags myself as soon as I find a good way to produce them as high-quality pins or buttons.

And honestly: I actually need a seventh tag: “Can’t handle praise”… ;)

📝 Call for Participation: Scientific Survey

Fittingly, there is currently an exciting online survey as part of a collaboration between the University of Salzburg and TU Chemnitz. It deals with the communication of photo preferences at public events.

• Goal: Understanding attitudes towards taking photos/being photographed and the communication of personal preferences.
• Time required: approx. 5 minutes.
• Anonymity: The survey is completely anonymous.
• Deadline: Participation is possible until March 28, 2026.

If you would like to support the research project, you can find the link here:
👉 To the Survey (Limesurvey)

Thank you for your support!

[frank@do3eet-terminal ~]$ logout

Initial State: IPBASE and Missing Cryptography

After the first boot via console cable, show version revealed: Cisco IOS Software, C3750 Software (C3750-IPBASE-M), Version 12.2(44)SE6

The acronym IPBASE is the core problem here. It’s Cisco’s entry-level feature set. Worse yet, without “K9” in the name, all cryptographic functions are missing. This means no SSH for the console and no HTTPS for the web interface. In a modern network, this is an absolute no-go. An attempt to activate HTTPS was promptly met with an error:

3750g(config)#ip http secure-server
                        ^
% Invalid input detected at '^' marker.

The Update Marathon

My goal was version 15.0(2)SE10, the last available version for this hardware series. Since jumping directly from 12.2 IPBASE to 15.0 is often problematic and I needed the K9 features, I took an intermediate step.

Step 1: Laying the Foundation with 12.2(55) IPSERVICESK9

First, I installed an image from the 12.2 branch with the IPSERVICESK9 feature set. This set unlocks Layer 3 features (routing) and, crucially, SSH/HTTPS. Since the image was available as a .bin file, a simple copy from my local HTTP server was sufficient:

3750g#copy http://192.168.254.11:8080/c3750-ipservicesk9-mz.122-55.SE12.bin flash:

Step 2: The Battle for Every Megabyte (Flash Limit)

The Cisco 3750G (non-E/X models) has a hard limit of 32 MB flash memory. This is extremely tight for modern IOS images. The .tar file for IOS 15.0, which contains both the image and the HTTP files for the web interface, almost exceeds this limit if another image is still on the flash.

Before I could risk the final update, I had to delete the just-installed 12.2 image to make room:

3750g#dir flash:
# ... shows approx. 21 MB free, not enough for the 15.0 TAR (approx. 22 MB) ...

3750g#delete flash:/c3750-ipservicesk9-mz.122-55.SE12.bin

Step 3: Jumping to IOS 15.0 with archive

With the flash cleared, I could now use the archive command. This is preferable to a simple copy because it extracts the .tar file, installs all support files, and correctly sets the boot variable (boot system):

3750g#archive download-sw /overwrite /reload http://192.168.254.11:8080/c3750-ipservicesk9-tar.150-2.SE10.tar

After an automatic reload, the switch greeted me with the new system: Cisco IOS Software, C3750 Software (C3750-IPSERVICESK9-M), Version 15.0(2)SE10

Cleanup: Corporate VLANs and Legacy Baggage

The switch came from a large corporate environment. A show vlan brief displayed a long list of VLANs (e.g., VLAN_10_PROD, OFFICE_NETWORK, etc.). Since this information is stored in the vlan.dat file in flash, it survives a standard erase startup-config.

To truly start from scratch, I manually deleted the VLAN database:

3750g#delete flash:vlan.dat
3750g#reload

Management Configuration for the Homelab

Once the switch was “clean” and up to date, the standard settings followed:

1. Management IP: Assigned an IP in Vlan1 for access.
2. SNMP: Configured for monitoring (e.g., with LibreNMS). Important: Only allow access via an ACL!

   3750g(config)#access-list 10 permit 192.168.254.0 0.0.0.255
   3750g(config)#snmp-server community secret RW 10
   

3. EnergyWise: Since the switch draws about 94 watts at idle, I configured EnergyWise to put unused ports into a lower power level.

Pro-Tips for the Homelab

When setting up a Cisco switch for your own lab, there are three often-overlooked points that can decide between frustration and success (and security).

1. Enabling 3rd-Party SFPs

Cisco is known for accepting only its own SFP modules. If you insert a cheap third-party module (e.g., from FS.com), the port is often shut down with an error message (“err-disable”). With two magic commands, this restriction can be lifted:

3750g(config)#service unsupported-transceiver
3750g(config)#no errdisable detect cause gbic-invalid

Note: Cisco will issue a warning that no support is provided for non-Cisco hardware – in a homelab, however, this is usually of secondary importance.

2. Closing a Security Gap: Disabling Smart Install

Older IOS versions often have the “Smart Install” feature enabled. This has been noted over the years for critical security vulnerabilities (e.g., CVE-2018-0171) through which attackers can gain full control of the switch. Since this feature is not needed in a homelab anyway, it should absolutely be disabled:

3750g(config)#no vstack

3. Enabling IPv6 Support (SDM Templates)

An often-overlooked aspect of older Catalyst models is SDM (Switch Database Management). Since hardware memory (TCAM) is limited, you must tell the switch what to prioritize it for. By default, the 3750G often doesn’t support IPv6.

To make the switch future-proof, you need to change the SDM template:

3750g(config)#sdm prefer dual-ipv4-and-ipv6 default

Important: This change only takes effect after a restart (reload)! After the reboot, you can verify the success with show sdm prefer and by enabling IPv6 on an interface:

3750g#show sdm prefer
 The current template is "desktop IPv4 and IPv6 default" template.

3750g(config)#interface vlan 1
3750g(config-if)#ipv6 enable

3750g#show ipv6 interface brief
Vlan1                      [up/up]
    FE80::213:7FFF:FE59:E240  <-- Link-local address is present!

4. Speeding Up the Boot Process (Stack Priority)

Since the 3750G is a stackable switch, it waits for a certain amount of time during boot for the “Stack Master Election” (Waiting for Stack Master Election...). Since usually only one switch is running in a homelab, you can speed up this process by setting the priority to the maximum value:

3750g(config)#switch 1 priority 15
Changing the Switch Priority of Switch Number 1 to 15
Do you want to continue?[confirm]
New Priority has been set successfully

5. SSH and the Key Issue

For SSH to work, the switch needs an RSA key. Usually, you generate this manually with crypto key generate rsa. In my configuration, however, a self-signed trustpoint was already present:

crypto pki trustpoint TP-self-signed-<ID>
 enrollment selfsigned
 rsakeypair TP-self-signed-<ID>

If SSH does not start directly for you, even though transport input ssh is set, this command usually helps (after a hostname and a domain name have been set):

3750g(config)#crypto key generate rsa

A key length of at least 2048 bits is recommended here to satisfy modern SSH clients (like current OpenSSH versions).

6. Solving SSH Connection Issues (Legacy Cryptography)

Anyone trying to connect to the switch via SSH from a modern Linux or macOS system will often be greeted with error messages like no matching key exchange method found or no matching host key type found. This is because the IOS 15.0 SSH stack uses methods that are considered outdated (insecure) today and are disabled by default by modern clients.

To get in anyway, you must explicitly allow the SSH client to use these old methods:

ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 \
    -oHostKeyAlgorithms=+ssh-rsa \
    -oCiphers=+aes256-cbc \
    root@192.168.254.1

Alternatively, you can create an entry in your local ~/.ssh/config for the switch so you don’t have to type these parameters every time:

Host 192.168.254.1
    KexAlgorithms +diffie-hellman-group14-sha1
    HostkeyAlgorithms +ssh-rsa
    Ciphers +aes256-cbc

7. The “Antenna Analyzer” for Network Cables (TDR)

As a ham radio operator (DO3EET), I love measurement tools. Did you know that the 3750G has a built-in TDR (Time Domain Reflectometry) meter? It can send electrical pulses through the cable to measure its length or find cable breaks with centimeter precision – even while the computer is still connected!

Here are two examples from my test run:

Example 1: A working 1m patch cable (Port 1)

3750g#show cable-diagnostics tdr interface gigabitEthernet 1/0/1
Interface Speed Local pair Pair length        Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi1/0/1   1000M Pair A     0    +/- 4  meters Pair A      Normal              
                Pair B     0    +/- 4  meters Pair B      Normal              
                Pair C     0    +/- 4  meters Pair C      Normal              
                Pair D     1    +/- 4  meters Pair D      Normal              

Example 2: An open, approx. 24m long installation cable (Port 3)

3750g#show cable-diagnostics tdr interface gigabitEthernet 1/0/3
Interface Speed Local pair Pair length        Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi1/0/3   auto  Pair A     23   +/- 4  meters N/A         Open                
                Pair B     24   +/- 4  meters N/A         Open                
                Pair C     24   +/- 4  meters N/A         Open                
                Pair D     24   +/- 4  meters N/A         Open                

Interpreting the results:

• Pair status “Normal”: Everything is fine. The cable is connected to an active device.
• Pair status “Open”: The cable has no termination at the end (unplugged).
• Pair length: The “1” in the first example indicates a very short cable (~1m). Since the hardware has a measurement tolerance of +/- 4 meters, values close to zero are often displayed as 0 or 1. In the second example, we see an approx. 24-meter cable that ends “open” somewhere in the house.
• Remote pair: In a working connection (Normal), the switch indicates whether the wire pairs arrive correctly on the opposite side. Pair A -> Pair A means: No twists in the cable!

The result confirms: My clean-lab is fully under control measurement-wise!

Nerd Overkill: The Antenna Calculator on the Switch (TCL)

As a ham radio operator, I’m always looking for ways to combine my hobbies. Since modern Go binaries don’t run on classic IOS, I used an old “backdoor”: TCL (Tool Command Language).

I ported my Python calculator for the Comet HFJ-350M antenna to TCL and uploaded it to the switch’s flash. Now I can calculate my antenna settings directly on the switch console – perfect when I’m working on the rack!

3750g#tclsh flash:hfj350.tcl
=== Comet HFJ-350M Calculator (Cisco Edition) ===
Band (e.g. 40m) or Freq (MHz): 7.1

--- Configuration for 40m ---
Coil:   Base (No additional coil)
Jumper: None
Std Len (7.0 MHz): 960 mm
Calc Len (7.1 MHz): 920 mm

IT infrastructure meets ham radio – it doesn’t get more “homelab” than this! Maybe this is even the foundation for a HAM-Net on the 10m band? 📡🌐🛰️

For those who want to rebuild it, here is the full TCL code:

# Comet HFJ-350M Antenna Calculator for Cisco IOS
# Author: DO3EET

set antenna_data {
    {band "160m" low 1.8 high 2.0 std 1.8 coil "Base + 3.5 coil + 1.8 coil" jumper "None" len 1170 change 7}
    {band "80m"  low 3.5 high 3.8 std 3.5 coil "Base + 3.5 coil" jumper "None" len 910 change 20}
    {band "40m"  low 7.0 high 7.2 std 7.0 coil "Base (No additional coil)" jumper "None" len 960 change 25}
    {band "30m"  low 10.1 high 10.15 std 10.1 coil "Base" jumper "Terminal 1" len 990 change 40}
    {band "20m"  low 14.0 high 14.35 std 14.0 coil "Base" jumper "Terminal 2" len 800 change 60}
    {band "17m"  low 18.068 high 18.168 std 18.0 coil "Base" jumper "Terminal 3 (or 2)" len 1070 change 50}
    {band "15m"  low 21.0 high 21.45 std 21.0 coil "Base" jumper "Terminal 3" len 750 change 80}
    {band "12m"  low 24.89 high 24.99 std 24.9 coil "Base" jumper "Terminal 3" len 530 change 100}
    {band "10m"  low 28.0 high 29.7 std 28.5 coil "Base" jumper "Terminal 4" len 1000 change 120}
    {band "6m"   low 50.0 high 52.0 std 51.0 coil "Base" jumper "Terminal 5" len 950 change 100}
}

puts "=== Comet HFJ-350M Calculator (Cisco Edition) ==="
puts "Type 'exit' to quit."

while {1} {
    puts -nonewline "Band (e.g. 40m) or Freq (MHz): "
    flush stdout
    set input [string trim [gets stdin]]
    if {$input == "exit" || $input == "q"} break
    if {$input == ""} continue
    
    set found 0
    foreach item $antenna_data {
        array set d $item
        set clean_band [string map {m ""} $d(band)]
        set is_freq [string is double -strict $input]
        
        if {$input == $d(band) || $input == $clean_band || ($is_freq && $input >= $d(low) && $input <= $d(high))} {
            puts "\n--- Configuration for $d(band) ---"
            puts "Coil:   $d(coil)"
            puts "Jumper: $d(jumper)"
            puts "Std Len ($d(std) MHz): $d(len) mm"
            
            if {$is_freq && $input != $d(std)} {
                set diff_khz [expr {($input - $d(std)) * 1000.0}]
                set calc_len [expr {round($d(len) - (($diff_khz / $d(change)) * 10.0))}]
                puts "Calc Len ($input MHz): $calc_len mm"
            }
            puts ""
            set found 1
            break
        }
    }
    if {!$found} { puts "No data found for '$input'\n" }
}

The Final Touch: A Login Banner

To round off the setup and give the switch a personal touch, I configured a login banner (Message of the Day). This not only looks professional but is often legally required in corporate environments.

3750g(config)#banner motd #
**************************************************************************
*                                                                        *
*   DO3EET Clean-Lab | Cisco 3750G                                       *
*                                                                        *
*   Authorized Access Only!                                              *
*                                                                        *
**************************************************************************
#

Hardware Check: Is the Device Healthy?

After all the software work, I wanted to know about the physical health of the used switch. A look at show tech-support (or specific show commands) provided reassuring values:

• Temperature: At 34°C (System Temperature State: GREEN), the device stays pleasantly cool at idle.
• Fans: A brief FAN is OK in the log confirms that the cooling is working properly – often a critical point with used enterprise gear (think bearing damage).
• The Heart: Inside, a PowerPC 405 processor is at work. Almost ancient by today’s standards, but still perfectly adequate for Layer 3 switching in hardware.
• Self-Test: All POST (Power-On Self-Test) routines, including the PortASIC memory, reported a clean Passed.

The Final running-config

Here is an excerpt of the current configuration (passwords and secrets have been masked). It shows all the discussed settings working together:

Current configuration : 6798 bytes
!
version 15.0
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service unsupported-transceiver
!
hostname 3750g
!
enable secret 5 <ENCRYPTED>
enable password <PASSWORD>
!
username root privilege 15 secret 5 <ENCRYPTED>
vtp domain clean-lab
vtp mode transparent
sdm prefer dual-ipv4-and-ipv6 default
ip domain-name do3eet-clab.internal
!
ip dhcp excluded-address 192.168.254.1 192.168.254.10
!
ip dhcp pool MGMT_POOL
 network 192.168.254.0 255.255.255.0
 default-router 192.168.254.1 
 dns-server 8.8.8.8 1.1.1.1 
!
energywise domain MyLab security shared-secret 0 <PASSWORD>
!
crypto pki trustpoint TP-self-signed-<ID>
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-<ID>
 rsakeypair TP-self-signed-<ID>
!
crypto pki certificate chain TP-self-signed-<ID>
 certificate self-signed 01
  <CERTIFICATE_DATA_MASKED>
quit
!
no errdisable detect cause gbic-invalid
spanning-tree mode pvst
spanning-tree extend system-id
!
interface GigabitEthernet1/0/1
 description MANAGEMENT_PORT
 switchport mode access
 spanning-tree portfast
!
interface GigabitEthernet1/0/2
 description DISABLED_FOR_SECURITY
 shutdown
 energywise level 0
!
! ... Interfaces 3 to 27 configured similarly ...
!
interface GigabitEthernet1/0/28
 description DISABLED_FOR_SECURITY
 shutdown
 energywise level 0
!
interface Vlan1
 ip address 192.168.254.1 255.255.255.0
 no ip route-cache
 ipv6 enable
!
ip http server
ip http authentication local
ip http secure-server
!
access-list 10 permit 192.168.254.0 0.0.0.255
!
snmp-server community <SECRET>
snmp-server location 3750g
snmp-server contact DO3EET
!
no vstack
banner motd ^C
**************************************************************************
*                                                                        *
*   DO3EET Clean-Lab | Cisco 3750G                                       *
*                                                                        *
*   Authorized Access Only!                                              *
*                                                                        *
**************************************************************************
^C
!
line con 0
line vty 0 15
 login local
 transport input ssh
!
end

Conclusion

Despite its age, the Cisco 3750G is an excellent device for a homelab if you want to get Layer 3 features on the cheap. However, you must plan the firmware path carefully, as the limited flash memory is very unforgiving. With SSH and IOS 15, the device is now ready for modern network tasks.

Over the past few weeks, I’ve been working intensively on a series of AddOns and documentation to transform OpenHAMClock into a true command center for the ham shack.

My Contributions at a Glance

All my contributions are based on the concept of Userscripts (e.g., for Tampermonkey). This allows for integrating features directly into the web interface without having to modify the clock’s core code.

1. APRS Auto-Position

For portable operators (SOTA/POTA) or mobile stations, this AddOn is a game-changer. It tracks a specific SSID via the aprs.fi API and automatically updates the clock’s position.

• Smart Updates: The position only refreshes if you’ve moved more than 50 meters.
• Seamless Integration: As soon as the location changes, the clock recalculates all paths and map views instantly.

2. APRS Newsfeed (Inbox)

Who wouldn’t want to be notified about new APRS messages without constantly checking their handheld radio?

• Displays the 10 most recent messages directly in the UI.
• A subtle red badge signals new incoming messages.
• Supports English, German, and Japanese.

3. HFJ-350M Antenna Calculator: From Terminal to Web

The Comet HFJ-350M is a fantastic multi-band portable antenna, but matching the telescopic length using manual charts can be tedious in the field.

The inspiration for this AddOn came from my standalone Python tool Comet-HFJ-350M-Toy-Box. Originally conceived as a CLI (Command Line Interface) utility, it already allowed me to quickly calculate the correct settings for any frequency right from the terminal. Since I use OpenHAMClock as my primary shack display, the next logical step was porting this logic into a graphical AddOn.

My web-based calculator now handles the heavy lifting:

• Precision: Calculates the exact length in millimeters for any frequency from 160m to 6m.
• Visualization: Displays the required coil combinations and jumper settings directly on the dashboard.
• Fine-tuning: Includes sensitivity data (kHz/cm) to help you hit the perfect SWR with minimal effort.

Infrastructure for the Community

Beyond functional tools, it was important to me that other developers could easily implement their own ideas. That’s why I authored two foundational guides:

• AddOn Development Guide: A standard for integrating community tools. I implemented an “AddOn Drawer” logic (🧩 icon) so that multiple AddOns can coexist cleanly without cluttering the native design.
• Self-Hosting Guide: A guide for those running OpenHAMClock (and the AddOns) on private hardware like a Raspberry Pi or in Docker. I place special emphasis on security best practices for handling API keys.

Conclusion

Open Source thrives on participation. What started as a small Python experiment for the terminal has now become a permanent part of my shack dashboard. Through the AddOn interface, OpenHAMClock has become significantly more flexible. I’m excited to see what ideas the community implements next!

Feel free to check out the code on GitHub: frankenstein91/openhamclock

73 de DO3EET

[frank@do3eet-terminal ~]$ git checkout redesign
[frank@do3eet-terminal ~]$ git merge master
[frank@do3eet-terminal ~]$ deploy --force-coolness

If you briefly wondered while loading the page whether you accidentally landed on a 90s mainframe via SSH: Don’t worry, it’s completely intentional!

I’ve spent the last few days giving my digital home a complete makeover. Moving away from “standard website” towards a design that reflects my passions: Linux, technology, and a healthy dose of science fiction.

What’s New in the Terminal?

1. The Matrix Has You (and Your Browser)

The new design goes all-in on Matrix Green on Tokyo Night Blue. There are now subtle scanlines, a blinking cursor, and a layout that feels like a directory tree (tree).

A special technical treat: Take a look at the header of the terminal window. It displays a dynamic prompt that recognizes which browser you’re using (e.g., [Firefox@do3eet.pages.dev /var/www]#). A small client-side JavaScript makes it possible – completely local and without data storage, of course.

2. The Great Inventory (Tag Cleanup)

I must admit: my keywords (tags) had become a bit… messy over time. I’ve cleaned up!

• Many granular tags have been consolidated (e.g., everything related to messengers, networking, or culinary topics).
• The new “Hobby” category is now packed with my DIY projects – from USB-C soldering on a Christmas star to my keyboard’s QMK firmware adventure.

3. Digital Treasures and Easter Eggs

I couldn’t resist building in a few small surprises:

• Achievement Unlocked: If you leave the page open for more than 5 minutes (perhaps while cozily reading a Japan report?), you’ll receive a small homage to old CRT monitors. No, your screen isn’t breaking; it’s just a “simulated burn-in”.
• The Ark of Truth: Stargate fans should scroll all the way to the bottom… but be careful, Origin is the source of truth.

Why All This?

As an IT professional and ham radio operator, I spend a lot of time in terminals. So why should my blog look any different? The new look is faster, more focused, and still offers plenty of space for my travel photos from Hokkaido or Tokyo.

How do you like the new look? Leave me a comment (or radio me) – I’m looking forward to your feedback!

[frank@do3eet-terminal ~]$ exit
logout
Connection to do3eet.pages.dev closed.

Preparation: The First Steps into the Unknown

As a newcomer to the QMK world, I first stuck to the official documentation. Setting it up on my Arch Linux system went surprisingly smoothly, thanks to the AUR and pikaur.

# 1. Clone firmware from Keychron
git clone https://github.com/Keychron/qmk_firmware.git
# 2. Install all necessary dependencies
pikaur -S python-platformdirs python-argcomplete python-colorama python-milc python-dotty-dict python-jsonschema git avr-gcc arm-none-eabi-gcc avr-libc arm-none-eabi-binutils arm-none-eabi-newlib avr-binutils dfu-programmer dfu-util avrdude python-hjson python-pygments python-pyusb python-pyserial python-pillow gcc libffi libusb-compat clang zip wget diffutils
# 3. Set up QMK environment
qmk setup --home /path/to/qmk_firmware

Up to this point, everything went according to plan. I felt ready to write the code for my lighting idea. But QMK had other plans.

Hurdle 1: The Directory That Didn’t Exist…

Every guide I found followed a clear pattern: find your keyboard’s directory, copy the default keymap, and start customizing. Full of motivation, I typed: cd keyboards/keychron/v5_max/iso/

The terminal’s response was sobering: No such file or directory. A quick check with ls revealed the first problem: there was no v5_max directory. A small setback, but no reason to worry. Or so I thought.

Hurdle 2: The Right Train on the Wrong Track…

Even though the title sounds like a railway reference, we’re still talking about the Universal Serial Bus…

After trying to work with the v5 files, it quickly became clear that something was fundamentally wrong. The keyboard wasn’t recognized correctly, flashing failed, and at one point, it stopped responding entirely – the first “brick.” A scary feeling, but fortunately, almost always fixable by re-flashing in DFU mode (unplug the USB cable, hold the button under the spacebar, plug the cable back in).

The crucial clue came after intensive research: Keychron often maintains new or wireless models in separate Git branches. My V5 Max wasn’t in the main branch but was hiding in the wls_2025q1 branch. a clean restart was necessary:

rm -rf /path/to/qmk_firmware
git clone https://github.com/Keychron/qmk_firmware.git
cd qmk_firmware
git checkout wls_2025q1
qmk setup --home /path/to/qmk_firmware

Finally! The v5_max directory was there. But the joy was short-lived. The directory structure was completely different than expected. There was no simple keymaps/default directory. Instead, the ISO-DE version was hidden in a subfolder called iso_encoder. The treasure map was getting more and more complex.

The Core Problem: Hunting for Phantom LEDs

After I finally found the right files, I added the code for my lighting. I compiled, flashed – and the wrong keys lit up. A chaotic jumble from the 5, t, g, b row glowed green, while my number pad remained dark.

This is where the real detective work began. My assumption that the LED numbers would follow a logical sequence was not entirely wrong… but also not correct enough. A look into the JSON configuration files didn’t help either, as they only describe the key matrix, not the LED wiring.

The Breakthrough: A Brilliant Idea

After countless failed attempts to guess the correct LED numbers, I had an idea that changed everything. Instead of flashing a new firmware for every single test, I built a “diagnostic firmware.” The idea:

1. A global counter variable (led_index) is set to 0.
2. Every time the Num key is pressed, this variable is incremented by 1.
3. The lighting function turns off all LEDs except for the one whose number is stored in led_index.

This way, I could “click” my way through the entire LED matrix, key by key, and create an exact map of my keyboard. After a few initial implementation hiccups, it worked!

Key by key, I pressed Num and noted which LED lit up… or so I thought…

• ESC was 0.
• F1 was 1.
• Num Lock was 30.
• Caps Lock was 51.
• The 0 on the numpad was 96.
• The . on the numpad was 97.

The Final Hurdle: Logic Instead of Counting

But even with this method, errors occurred. One miscount and the whole list was shifted. The 0 and . keys wouldn’t light up, but Ctrl and Shift did instead. The counting method was too error-prone. We needed a new strategy: logic and targeted tests.

Instead of testing individual LEDs, we tested entire rows of the numpad at once. A decisive test was the 4, 5, 6, + row. From an earlier test, I knew that LED 65 was under the 5 key. So I tested the logical group 64, 65, 66, 67. The test was a success! These four keys lit up as expected. This single successful test confirmed the block structure of the LED matrix and allowed me to deduce the remaining numbers with high confidence and verify them in larger groups. This saved countless flashing operations and finally led me to the correct and complete LED map.

The Reward for the Effort: The Final Code

With the complete and verified list of LED numbers, the rest was a piece of cake. I extended the code with another feature: the Caps Lock key should light up red when activated. As a final adjustment, I mapped the Print Screen key, which my keyboard lacks, to the combination Fn + P.

Here is the final code, the result of our long journey:

#include QMK_KEYBOARD_H
#include "keychron_common.h"

enum layers {
    MAC_BASE,
    MAC_FN,
    WIN_BASE,
    WIN_FN,
};

const uint8_t numpad_leds[] = {
    30, 31, 32, 33, // Num, /, *, -
    48, 49, 50,     // 7, 8, 9
    64, 65, 66, 67, // 4, 5, 6, +
    82, 83, 84, 85, // 1, 2, 3, Enter
    96, 97          // 0, .
};

// Die LED-Nummer für die Caps-Lock-Taste
#define CAPS_LOCK_LED 51

// clang-format off
const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
 [MAC_BASE] = LAYOUT_iso_99(
        KC_ESC,             KC_BRID,  KC_BRIU,  KC_MCTRL, KC_LNPAD, RGB_VAD,  RGB_VAI,  KC_MPRV,  KC_MPLY,  KC_MNXT,  KC_MUTE,    KC_VOLD,  KC_VOLU,            KC_DEL,   KC_HOME,  KC_END,     KC_MUTE,
        KC_GRV,   KC_1,     KC_2,     KC_3,     KC_4,     KC_5,     KC_6,     KC_7,     KC_8,     KC_9,     KC_0,     KC_MINS,    KC_EQL,   KC_BSPC,            KC_NUM,   KC_PSLS,  KC_PAST,    KC_PMNS,
        KC_TAB,   KC_Q,     KC_W,     KC_E,     KC_R,     KC_T,     KC_Y,     KC_U,     KC_I,     KC_O,     KC_P,     KC_LBRC,    KC_RBRC,                      KC_P7,    KC_P8,    KC_P9,      KC_PPLS,
        KC_CAPS,  KC_A,     KC_S,     KC_D,     KC_F,     KC_G,     KC_H,     KC_J,     KC_K,     KC_L,     KC_SCLN,  KC_QUOT,    KC_NUHS,  KC_ENT,             KC_P4,    KC_P5,    KC_P6,
        KC_LSFT,  KC_NUBS,  KC_Z,     KC_X,     KC_C,     KC_V,     KC_B,     KC_N,     KC_M,     KC_COMM,  KC_DOT,   KC_SLSH,              KC_RSFT,  KC_UP,    KC_P1,    KC_P2,    KC_P3,      KC_PENT,
        KC_LCTL,  KC_LOPTN, KC_LCMMD,                               KC_SPC,                                 KC_RCMMD, MO(MAC_FN), KC_RCTL,  KC_LEFT,  KC_DOWN,  KC_RGHT,  KC_P0,    KC_PDOT               ),

    [MAC_FN] = LAYOUT_iso_99(
        _______,            KC_F1,    KC_F2,    KC_F3,    KC_F4,    KC_F5,    KC_F6,    KC_F7,    KC_F8,    KC_F9,    KC_F10,     KC_F11,   KC_F12,             _______,  _______,  _______,    RGB_TOG,
        _______,  BT_HST1,  BT_HST2,  BT_HST3,  P2P4G,    _______,  _______,  _______,  _______,  _______,  _______,  _______,    _______,  _______,            _______,  _______,  _______,    _______,
        RGB_TOG,  RGB_MOD,  RGB_VAI,  RGB_HUI,  RGB_SAI,  RGB_SPI,  _______,  _______,  _______,  _______,  KC_PSCR,  _______,    _______,                      _______,  _______,  _______,    _______, // <-- HIER: P = Print Screen
        _______,  RGB_RMOD, RGB_VAD,  RGB_HUD,  RGB_SAD,  RGB_SPD,  _______,  _______,  _______,  _______,  _______,  _______,    _______,  _______,            _______,  _______,  _______,
        _______,  _______,  _______,  _______,  _______,  _______,  BAT_LVL,  NK_TOGG,  _______,  _______,  _______,  _______,              _______,  _______,  _______,  _______,  _______,    _______,
        _______,  _______,  _______,                                _______,                                _______,  _______,    _______,  _______,  _______,  _______,  _______,  _______            ),

    [WIN_BASE] = LAYOUT_iso_99(
        KC_ESC,             KC_F1,    KC_F2,    KC_F3,    KC_F4,    KC_F5,    KC_F6,    KC_F7,    KC_F8,    KC_F9,    KC_F10,     KC_F11,   KC_F12,             KC_DEL,   KC_HOME,  KC_END,     KC_MUTE,
        KC_GRV,   KC_1,     KC_2,     KC_3,     KC_4,     KC_5,     KC_6,     KC_7,     KC_8,     KC_9,     KC_0,     KC_MINS,    KC_EQL,   KC_BSPC,            KC_NUM,   KC_PSLS,  KC_PAST,    KC_PMNS,
        KC_TAB,   KC_Q,     KC_W,     KC_E,     KC_R,     KC_T,     KC_Y,     KC_U,     KC_I,     KC_O,     KC_P,     KC_LBRC,    KC_RBRC,                      KC_P7,    KC_P8,    KC_P9,      KC_PPLS,
        KC_CAPS,  KC_A,     KC_S,     KC_D,     KC_F,     KC_G,     KC_H,     KC_J,     KC_K,     KC_L,     KC_SCLN,  KC_QUOT,    KC_NUHS,  KC_ENT,             KC_P4,    KC_P5,    KC_P6,
        KC_LSFT,  KC_NUBS,  KC_Z,     KC_X,     KC_C,     KC_V,     KC_B,     KC_N,     KC_M,     KC_COMM,  KC_DOT,   KC_SLSH,              KC_RSFT,  KC_UP,    KC_P1,    KC_P2,    KC_P3,      KC_PENT,
        KC_LCTL,  KC_LWIN,  KC_LALT,                                KC_SPC,                                 KC_RALT,  MO(WIN_FN), KC_RCTL,  KC_LEFT,  KC_DOWN,  KC_RGHT,  KC_P0,    KC_PDOT            ),

    [WIN_FN] = LAYOUT_iso_99(
        _______,            KC_BRID,  KC_BRIU,  KC_TASK,  KC_FILE,  RGB_VAD,  RGB_VAI,  KC_MPRV,  KC_MPLY,  KC_MNXT,  KC_MUTE,    KC_VOLD,  KC_VOLU,            _______,  _______,  _______,    RGB_TOG,
        _______,  BT_HST1,  BT_HST2,  BT_HST3,  P2P4G,    _______,  _______,  _______,  _______,  _______,  _______,  _______,    _______,  _______,            _______,  _______,  _______,    _______,
        RGB_TOG,  RGB_MOD,  RGB_VAI,  RGB_HUI,  RGB_SAI,  RGB_SPI,  _______,  _______,  _______,  _______,  KC_PSCR,  _______,    _______,                      _______,  _______,  _______,    _______, // <-- HIER: P = Print Screen
        _______,  RGB_RMOD, RGB_VAD,  RGB_HUD,  RGB_SAD,  RGB_SPD,  _______,  _______,  _______,  _______,  _______,  _______,    _______,  _______,            _______,  _______,  _______,
        _______,  _______,  _______,  _______,  _______,  _______,  BAT_LVL,  NK_TOGG,  _______,  _______,  _______,  _______,              _______,  _______,  _______,  _______,  _______,    _______,
        _______,  _______,  _______,                                _______,                                _______,  _______,    _______,  _______,  _______,  _______,  _______,  _______            ),
 };

#if defined(ENCODER_MAP_ENABLE)
const uint16_t PROGMEM encoder_map[][NUM_ENCODERS][2] = {
    [MAC_BASE] = {ENCODER_CCW_CW(KC_VOLD, KC_VOLU)},
    [MAC_FN]   = {ENCODER_CCW_CW(RGB_VAD, RGB_VAI)},
    [WIN_BASE] = {ENCODER_CCW_CW(KC_VOLD, KC_VOLU)},
    [WIN_FN]   = {ENCODER_CCW_CW(RGB_VAD, RGB_VAI)},
};
#endif // ENCODER_MAP_ENABLE

// clang-format on
bool process_record_user(uint16_t keycode, keyrecord_t *record) {
    if (!process_record_keychron_common(keycode, record)) {
        return false;
    }
    return true;
}

bool rgb_matrix_indicators_user(void) {
    // Num-Lock-Anzeige
    if (host_keyboard_led_state().num_lock) {
        for (uint8_t i = 0; i < sizeof(numpad_leds); i++) {
            rgb_matrix_set_color(numpad_leds[i], 0, 255, 0); // Grün
        }
    }

    // Caps-Lock-Anzeige
    if (host_keyboard_led_state().caps_lock) {
        rgb_matrix_set_color(CAPS_LOCK_LED, 255, 0, 0); // Rot
    }

    return false;
}

Conclusion and One Last Mystery

This journey was a rollercoaster. It showed me how powerful, but also how unforgiving, QMK can be. The documentation is a good start, but with manufacturer-specific deviations, you are quickly on your own and have to become a detective. However, the feeling of finally having a firmware that does exactly what you want is priceless.

One small mystery remains unsolved, though: The key combination to display the battery level (Fn + B) no longer seems to work with my custom firmware. Unfortunately, I don’t know why. Perhaps that’s an adventure for another time.

To everyone facing a similar challenge: Don’t give up! The solution is out there, sometimes you just have to work hard to find it. And if anyone has any ideas, please let me know.

SSTV stands for “Slow Scan Television” and is an operating mode in amateur radio used for transmitting still images. In the context of the International Space Station (ISS), this means that the ISS transmits images via radio at specific times, which can be received by radio amateurs on Earth. This capability is mostly used for specific events. ARISS (Amateur Radio on the International Space Station) usually announces these events in advance.

And I was there live for exactly two such cosmic photo sessions – practically as a paparazzo for interstellar snapshots! So, you sit there with pricked ears (and antennas) and listen to the ether, while a multi-ton high-tech laboratory with astronauts on board rushes past you at an altitude of 400 km and… well… sends little pictures. Sounds unspectacular at first? Not at all! Imagine this: there’s this characteristic beeping and chirping coming from the loudspeaker – the secret language of images from space. You hope that your own receiver and software will cooperate and that your neighbor doesn’t decide to start the lawnmower right then, or that a cosmic cow doesn’t interfere with the transmission. Every successfully decoded pixel is a small victory!

A Cheer for the Space Pioneers

The first award I “fished” for in this way was on the occasion of the International Day of Human Space Flight. And who could be more fitting for that than the first man in space, Yuri Gagarin? His likeness, together with his Vostok-1 capsule, now adorns this award. The transmitted images showed various milestones of human spaceflight.

Peace Message from Orbit

Shortly thereafter, or rather, on the next major occasion, the second award arrived. This time, it addressed a more serious, but all the more important topic: the 80th anniversary of the end of World War II. The ISS itself, a symbol of international cooperation and friendship, adorned this special award. A strong signal sent from above, which could be captured down here with a bit of patience and technology. That’s when you realize that amateur radio is more than just “Hello here, hello there.”

It’s a pretty cool feeling to receive these little works of art directly from the space station. Each time it’s a little thrill wondering if the transmission will work and the image will come through cleanly, especially since the ISS always seems to change images right when it’s over my location. And in the end, you’re not just holding a piece of paper, but confirmation that you’re part of a worldwide community of radio enthusiasts listening to LEO.

Now the awards are almost on the wall, reminding me that even slow pictures can travel incredibly fast when they come from the ISS. Let’s see which cosmic event will be immortalized via SSTV next – my receiver is ready! I hope I don’t miss the announcement.

Time is also relevant to me on vacation. On the one hand, to avoid missing the train, but also as a fundamental component of GPS for navigating in large cities.

And in my professional life, NTP time is important for server administration. Here, it is a constant requirement that the servers are in sync with a central time server, ensuring that their times are consistent.

Why is NTP so important?

Well, servers perform countless tasks: they log every step in log files, save data in databases, and communicate with each other. If the time on these systems doesn’t match, it creates utter chaos. Timestamps in log files become inconsistent, which turns troubleshooting into a guessing game. Imagine an error occurs, and you’re trying to figure out what happened from the logs. Conflicting timestamps make it impossible to trace the sequence of events.
Accurate time is also crucial for the smooth operation of your applications. Many processes, such as database replication or file synchronization, rely on a consistent time base. Time discrepancies here can lead to data loss or malfunctions. When it comes to security, accurate time is even more critical. The analysis of security incidents, the validity of certificates, and the synchronization of security tokens—all of these depend on precise timekeeping.

Why is accurate time important for GPS?

We use GPS (Global Positioning System) almost daily—whether in our cars, on our smartphones, or on our smartwatches. At its core, GPS is based on a simple physical principle: Distance = Speed × Time. The GPS system consists of a network of satellites orbiting the Earth. Each of these satellites continuously transmits signals. These signals contain information about the satellite’s position and, crucially, the exact time at which the signal was sent.
Your GPS receiver reads these signals from multiple satellites simultaneously. It compares the transmission time encoded in the signal with the time it receives the signal. From this difference, it can calculate how long the signal was traveling. Since we are talking about the speed of light, these time differences are minuscule.

Precise positioning with GPS is therefore inextricably linked with extremely accurate time measurement. It is the ability to measure and process time intervals in the nanosecond range that allows us to determine our location so precisely.

What Kinds of Attacks Are There?

GPS

Precisely because accurate time is so fundamental to GPS, it’s also an attractive target for attackers. The disruption or manipulation of these time signals can have significant consequences.

Jamming… This is the simplest and probably most common form of interference. An attacker uses a transmitter to broadcast strong noise or disruptive signals on GPS frequencies. The receiver loses satellite contact and can no longer determine its position or the accurate time. This constitutes a Denial of Service (DoS) attack.

GPS Spoofing, however, is particularly nasty… This is a much more sophisticated method of attack on the GPS signal. Instead of just blocking the signals, the attacker broadcasts counterfeit GPS signals. These signals imitate real satellite signals but contain false information—specifically, an incorrect time and/or incorrect satellite positions. The receiver then calculates a wrong position and/or an incorrect time without realizing it. The system believes it is somewhere else or that it is a different time. This can cause ships and aircraft to go off course, lead to drones being misdirected into incorrect areas, or disrupt time-critical systems.

NTP

As with any IT system, Denial of Service attacks are commonplace for NTP servers and are nothing new. Therefore, systems usually use multiple servers or even entire server pools to determine the current time. What’s particularly insidious about NTP servers is that, if misconfigured, they can also be exploited for DDoS amplification attacks.

But just as with GPS, there are also attackers who intercept NTP packets and alter the timestamps within them. The client then calculates an incorrect time based on this manipulated data.

My Attempt to Detect Attacks…

My idea is to detect a potential attack on one of these signals by monitoring its drift relative to the other signal. Of course, this requires a lot of data to differentiate the normal drift fluctuations for a specific location and internet connection from an actual attack. But I’ve already made a start, and I don’t want to hide it.

GUI

At the very top, the current time is displayed, sourced directly from a GPS receiver. Below that, the tool lists the times it has received from various NTP (Network Time Protocol) servers. Further down, the difference between the GPS time and the time from each individual NTP server is calculated and displayed in milliseconds (ms). A small amount of drift is normal and is caused by network latency and system processing speeds.

<!DOCTYPE html>
<html lang="de">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>GPS/NTP Drift Monitor</title>
    <script src="https://cdn.tailwindcss.com"></script>
    <link rel="preconnect" href="https://fonts.googleapis.com">
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
    <link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700&display=swap" rel="stylesheet">
    <style>
        body {
            font-family: 'Inter', sans-serif;
            background-color: #1a202c; /* Dunkler Hintergrund */
            color: #e2e8f0; /* Helle Schriftfarbe */
        }
        .bg-dark {
            background-color: #2d3748; /* Dunklere Hintergrundfarbe für Container */
        }
        .text-light {
            color: #e2e8f0; /* Helle Schriftfarbe */
        }
        .text-accent {
            color: #63b3ed; /* Akzentfarbe für Titel */
        }
        .logo {
            max-width: 100px; /* Maximale Breite des Logos */
            margin: 0 auto; /* Zentrieren */
            display: block;
        }
    </style>
    <script>
        tailwind.config = {
            theme: {
                extend: {
                    fontFamily: {
                        'inter': ['Inter', 'sans-serif'],
                    },
                },
            },
        }
    </script>
</head>
<body class="p-6">
    <div class="container max-w-2xl mx-auto bg-dark shadow-md rounded-lg p-8">
        <!-- Logo hinzufügen -->
        <img src="{{ url_for('static', filename='cuteGPS.webp') }}" alt="GPS Logo" class="logo mb-4">
        <h1 class="text-3xl font-semibold text-accent text-center mb-6">GPS/NTP Drift Monitor</h1>
        <div class="mb-6">
            <h2 class="text-xl font-semibold text-light mb-3">GPS Zeit:</h2>
            <div id="gps-time" class="text-lg text-light p-4 bg-gray-700 rounded-md">Lädt...</div>
        </div>
        <div class="mb-6">
            <h2 class="text-xl font-semibold text-light mb-3">NTP Zeiten:</h2>
            <div id="ntp-times" class="space-y-2">
                <!-- NTP Zeiten werden hier dynamisch eingefügt -->
            </div>
        </div>
        <div class="mb-6">
            <h2 class="text-xl font-semibold text-light mb-3">Drift (GPS - NTP):</h2>
            <div id="drifts" class="space-y-4">
                <!-- Drift-Werte werden hier dynamisch eingefügt -->
            </div>
        </div>
        <div class="text-center mt-8">
            <p class="text-gray-400 text-sm">Daten werden alle 5 Sekunden aktualisiert.</p>
        </div>
    </div>

    <script>
        const gpsTimeElement = document.getElementById('gps-time');
        const ntpTimesElement = document.getElementById('ntp-times');
        const driftsElement = document.getElementById('drifts');

        function updateData() {
            fetch('/data')
                .then(response => response.json())
                .then(data => {
                    // GPS Zeit aktualisieren
                    gpsTimeElement.textContent = data.gps_time ? new Date(data.gps_time).toLocaleString() : 'Keine Daten';

                    // NTP Zeiten aktualisieren
                    ntpTimesElement.innerHTML = ''; // Vorherige Inhalte löschen
                    if (data.ntp_times) {
                        for (const server in data.ntp_times) {
                            const ntpTime = data.ntp_times[server] ? new Date(data.ntp_times[server]).toLocaleString() : 'Keine Daten';
                            const ntpDiv = document.createElement('div');
                            ntpDiv.className = 'p-2 bg-gray-700 rounded-md text-light';
                            ntpDiv.textContent = `${server}: ${ntpTime}`;
                            ntpTimesElement.appendChild(ntpDiv);
                        }
                    }

                    // Drifts aktualisieren
                    driftsElement.innerHTML = ''; // Vorherige Inhalte löschen
                    if (data.drifts) {
                        for (const server in data.drifts) {
                            const driftValue = data.drifts[server] !== null ? data.drifts[server].toFixed(2) + ' ms' : 'Keine Daten';

                            const driftDiv = document.createElement('div');
                            driftDiv.className = 'p-2 bg-gray-700 rounded-md text-light';
                            driftDiv.textContent = `${server}: ${driftValue}`;
                            driftsElement.appendChild(driftDiv);
                        }
                    }
                })
                .catch(error => {
                    console.error('Fehler beim Abrufen der Daten:', error);
                    gpsTimeElement.textContent = 'Fehler beim Abrufen der Daten';
                    ntpTimesElement.innerHTML = 'Fehler beim Abrufen der Daten';
                    driftsElement.innerHTML = 'Fehler beim Abrufen der Daten';
                });
        }

        updateData(); // Initiales Update
        setInterval(updateData, 5000); // Aktualisierung alle 5 Sekunden
    </script>
</body>
</html>

This code talks to the flask backend.

Backend

My backend is written in Python. It’s my favorite for just about everything, though I can imagine there might be better languages for this specific project. Normally, I would have used Python’s argparse module to handle configuration. For this blog post, however, I decided against it for the sake of clarity and to make the code easier to follow. This is also my first script using asyncio.

import asyncio
import re
import time
from datetime import datetime, timedelta, timezone
import logging
import ntplib
import serial
from flask import Flask, jsonify, render_template  # Importiere Flask
from tinyflux import Point, TinyFlux  # Importiere TinyFlux und Point
from tinyflux.queries import (FieldQuery, Query, TagQuery,  # Importiere Query
                              TimeQuery)

# Konfiguration der seriellen Schnittstelle für die GPS-Maus
serial_port = "/dev/ttyACM0"
baud_rate = 9600
timeout = 1

# NTP-Server Liste
ntp_servers = ["1.europe.pool.ntp.org", "0.europe.pool.ntp.org"]

# Globale Variablen
latest_gps_time = None
latest_ntp_times = {}
latest_drifts = {}
gps_serial = None

# TinyFlux Datenbank initialisieren
db = TinyFlux("time_data.json")  # Verwende eine Datei zum Speichern der Daten
tag_query = TagQuery()
time_query = TimeQuery()

# Flask App initialisieren
app = Flask(__name__)


# Funktion zur Extraktion der Zeit vom GPS
def get_gps_time():
    """
    Liest Daten von der seriellen Schnittstelle, extrahiert die Zeit aus dem GPRMC-Satz
    und konvertiert sie in ein datetime-Objekt.
    """
    global latest_gps_time, gps_serial
    if gps_serial is None:
        try:
            gps_serial = serial.Serial(serial_port, baud_rate, timeout=timeout)
            logging.info(f"Serielle Verbindung zu {serial_port} hergestellt.")
        except serial.SerialException as e:
            logging.error(f"Fehler beim Öffnen der seriellen Schnittstelle {serial_port}: {e}")
            return None
    try:
        line = gps_serial.readline().decode("utf-8", errors="ignore").strip()
        if line.startswith("$GPRMC"):
            parts = line.split(",")
            if parts[2] == "A":
                try:
                    time_str = parts[1]
                    date_str = parts[9]
                    day = int(date_str[0:2])
                    month = int(date_str[2:4])
                    year = 2000 + int(date_str[4:6])
                    hour = int(time_str[0:2])
                    minute = int(time_str[2:4])
                    second = int(time_str[4:6])
                    microsecond = (
                        int(float(time_str[7:]) * 1000) if len(time_str) > 6 else 0
                    )
                    latest_gps_time = datetime(
                        year,
                        month,
                        day,
                        hour,
                        minute,
                        second,
                        microsecond,
                        tzinfo=timezone.utc,
                    )
                    logging.info(f"GPS Zeit (parsed): {latest_gps_time}")
                    return latest_gps_time
                except ValueError as e:
                    logging.error(f"Error beim Parsen der GPS-Zeit: {e}, Zeile: {line}")
                    latest_gps_time = None
                    return None
            else:
                logging.error("GPS Zeit ungültig (V)")
                latest_gps_time = None
                return None
    except serial.SerialException as e:
        logging.error(f"Fehler beim Lesen von der seriellen Schnittstelle: {e}")
        latest_gps_time = None
        try:
            gps_serial.close()
            gps_serial = serial.Serial(serial_port, baud_rate, timeout=timeout)
            logging.info("Serielle Verbindung wiederhergestellt.")
        except serial.SerialException as e:
            logging.error(f"Fehler beim Wiederherstellen der seriellen Verbindung: {e}")
        return None
    except UnicodeDecodeError as e:
        logging.error(f"Fehler beim Dekodieren der seriellen Daten: {e}, Zeile: {line}")
        latest_gps_time = None
        return None
    except Exception as e:
        logging.error(f"Ein unerwarteter Fehler ist aufgetreten: {e}")
        latest_gps_time = None
        return None


# Funktion zum Abrufen der NTP-Zeit
def get_ntp_time(server):
    """
    Ruft die Zeit von einem NTP-Server ab.
    """
    global latest_ntp_times
    try:
        ntp_time = ntplib.NTPClient().request(server, version=3).tx_time
        ntp_time_datetime = datetime.fromtimestamp(ntp_time, tz=timezone.utc)
        latest_ntp_times[server] = ntp_time_datetime
        logging.info(f"NTP Zeit von {server}: {ntp_time_datetime}")
        return latest_ntp_times[server]
    except Exception as e:
        logging.error(f"Fehler beim Abrufen der NTP-Zeit von {server}: {e}")
        latest_ntp_times[server] = None
        return None


# Funktion zur Berechnung der Zeitabweichung
def calculate_drift(gps_time, ntp_time):
    """
    Berechnet die Zeitabweichung zwischen GPS- und NTP-Zeit in Millisekunden.
    """
    if gps_time is None or ntp_time is None:
        return None
    return (ntp_time - gps_time).total_seconds() * 1000


# Funktion zum Aktualisieren der Daten (wird von Flask aufgerufen)
def update_data():
    """
    Ruft GPS- und NTP-Zeit ab und speichert sie in der Datenbank.
    Berücksichtigt die Zeitverzögerung bei der Drift-Berechnung.
    """
    global latest_gps_time, latest_ntp_times, latest_drifts
    gps_time = get_gps_time()
    if gps_time:
        for server in ntp_servers:
            # Messen der Zeit vor dem Abrufen der NTP-Zeit
            start_time = datetime.now(timezone.utc)
            ntp_time = get_ntp_time(server)
            # Messen der Zeit nach dem Abrufen der NTP-Zeit
            end_time = datetime.now(timezone.utc)

            if ntp_time:
                # Berechnung der mittleren Verzögerung
                processing_delay = (end_time - start_time).total_seconds() / 2
                # Anpassung der NTP-Zeit
                adjusted_ntp_time = ntp_time - timedelta(seconds=processing_delay)

                drift = calculate_drift(gps_time, adjusted_ntp_time)
                if drift is not None:
                    latest_drifts[server] = drift
                    # Speichere die Daten in der TinyFlux Datenbank
                    db.insert(
                        Point(
                            measurement="time_data",
                            tags={"source": "GPS"},
                            fields={
                                "time": gps_time.timestamp()
                            },  # Als Unix-Zeitstempel speichern
                        )
                    )
                    db.insert(
                        Point(
                            measurement="time_data",
                            tags={"source": f"NTP-{server}"},
                            fields={
                                "time": adjusted_ntp_time.timestamp()
                            },  # Als Unix-Zeitstempel speichern
                        )
                    )
                    db.insert(
                        Point(
                            measurement="drift_data",
                            tags={"server": server},
                            fields={"drift": drift},
                            time=datetime.now(
                                timezone.utc
                            ),  # Zeitstempel für den Drift
                        )
                    )
                else:
                    latest_drifts[server] = None
            else:
                latest_drifts[server] = None
    else:
        for server in ntp_servers:
            latest_drifts[server] = None
    return True


@app.route("/")
def index():
    """
    Rendert die Hauptseite der Webanwendung.
    """
    return render_template("index.html")


@app.route("/data")
def get_data():
    """
    Gibt die aktuellen GPS-Zeit, NTP-Zeiten und Abweichungen im JSON-Format zurück.
    """
    global latest_gps_time, latest_ntp_times, latest_drifts
    update_data()
    # Lese die neuesten Daten aus der TinyFlux Datenbank
    gps_data = db.search(tag_query.source == "GPS")
    latest_gps_data = (
        datetime.fromtimestamp(gps_data[-1].fields["time"], tz=timezone.utc)
        if gps_data
        else None
    )

    drift_data_list = db.search(tag_query.server.exists())
    latest_drifts_data = {}
    if drift_data_list:
        for entry in drift_data_list:
            if "drift" in entry.fields:  # Überprüfen, ob 'drift' existiert
                latest_drifts_data[entry.tags["server"]] = entry.fields["drift"]
            else:
                logging.warning(f"Warnung: Eintrag ohne 'drift'-Feld gefunden: {entry}")
    else:
        latest_drifts_data = {}

    latest_ntp_times_data = {}
    for server in ntp_servers:
        ntp_data = db.search(tag_query.source == f"NTP-{server}")
        latest_ntp_times_data[server] = (
            datetime.fromtimestamp(ntp_data[-1].fields["time"], tz=timezone.utc)
            if ntp_data
            else None
        )

    return jsonify(
        {
            "gps_time": latest_gps_data.isoformat() if latest_gps_data else None,
            "ntp_times": {
                server: time.isoformat() if time else None
                for server, time in latest_ntp_times_data.items()
            },
            "drifts": latest_drifts_data,
            "ntp_servers": ntp_servers,
        }
    )


def start_background_task():
    """
    Startet eine Hintergrundaufgabe, um die Daten regelmäßig zu aktualisieren.
    """
    loop = asyncio.new_event_loop()
    asyncio.set_event_loop(loop)
    while True:
        update_data()
        time.sleep(5)
    loop.close()


import threading

if __name__ == "__main__":
    logging.basicConfig(
    level=logging.DEBUG,  # Log-Level (z. B. DEBUG, INFO, WARNING, ERROR, CRITICAL)
    format="%(asctime)s - %(levelname)s - %(message)s",  # Log-Format
    )
    # Starte den Hintergrund-Thread
    background_thread = threading.Thread(target=start_background_task)
    background_thread.daemon = True
    background_thread.start()
    # Starte die Flask-App
    app.run(debug=True, host="0.0.0.0")

Reading GPS Data

The get_gps_time function reads data from a serial port, extracts time information from a GPS data sentence in NMEA format, and converts it into a datetime object. It is designed to work with GPS modules that transmit data via serial communication. The function uses global variables like latest_gps_time and gps_serial to manage the most recently captured timestamp and the serial connection.

Initially, the function checks if the serial connection (gps_serial) is already initialized. If not, it attempts to establish a connection using the parameters defined in the serial_port, baud_rate, and timeout variables. If an error occurs during initialization, an error message is logged, and the function returns None.

The function then reads a line from the serial port, decodes it as UTF-8, and strips any unwanted whitespace. If the line starts with $GPRMC, it is split into its components. The third part of the data sentence (parts[2]) indicates whether the GPS data is valid. Only if this value is A is the time and date information processed further. The time (parts[1]) and the date (parts[9]) are extracted and broken down into their respective components (hour, minute, second, day, month, year). If the time string includes milliseconds, these are also taken into account. With this information, a datetime object using the UTC timezone is created and stored in the global latest_gps_time variable.

If an error occurs during processing, such as an invalid time format (ValueError), an error message is logged, and the function returns None. Similar error-handling mechanisms exist for problems reading from the serial port (serial.SerialException), decoding errors (UnicodeDecodeError), and other unexpected exceptions. In case of a connection error, the function attempts to re-initialize the serial connection.

Also very important: this function will not work if gpsd is running. This tool changes the output of the GPS receiver to a different format, which this script is not designed to parse.

Fetching NTP Time

The get_ntp_time function is built to communicate with NTP servers using the appropriate Python libraries. For my tool, I didn’t want to rely on the system time and system configuration; I hope that wasn’t a mistake. Since ready-made libraries for NTP already exist, this section of the code is naturally much shorter than the GPS section.

Database

TinyFlux is an open-source database library designed specifically for storing and querying time-series data in Python. You can think of it as a greatly simplified, file-based alternative to larger time-series databases like InfluxDB. Instead of a complex server, TinyFlux stores its data in a single file, typically in JSON format. This significantly simplifies setup and management, especially for smaller projects or local applications.

Future Ideas…

I would like to network this script… By that, I mean creating a central database for the time drift. Perhaps it would also be possible in the future to integrate this tool into the honeypot from Deutsche Telekom Security GmbH. This attack monitoring solution is already openly available on GitHub.

Another idea for such a solution would be a distributed database, similar to the Yacy search engine or other P2P services.

Supporting multiple GPS receivers also sounds tempting, but I currently lack the necessary hardware for it.

My final future idea is to make this available for mobile phones. Old phones are often just lying around, but they offer a large number of interfaces and sensors. This usually includes a very good GPS receiver, which would be great for this project.

You know the drill. As the year winds down, that familiar beast slouches into view for countless team leads (or, let’s be honest, usually their deputies): the dreaded on-call duty roster planning. What sounds like a straightforward task is, in reality, a minefield. We’re talking about navigating the treacherous waters of works council notification deadlines on one hand, and keeping your actual team members clued in without mass confusion on the other.

Believe me, I’ve been there. I’ve witnessed firsthand the classic standoff between the official demands of the works council and what employees actually find clear and usable. I’ve personally ridden the rollercoaster from trusty old Excel to a sleek online team calendar… and right back to Excel, all because the tool’s export format didn’t quite get the works council’s seal of approval, or some other similar bureaucratic joy. It’s a recurring headache, and this time, I want to explore it further.

Just picture the annual slog: manually constructing a new Excel calendar from scratch, then meticulously wrestling the details for around 20 users across 12 separate worksheets. Let’s be honest, it’s not just mind-numbingly inefficient; it’s an approach that feels beneath anyone who’s spent time in the IT field. But here’s where a bit of ingenuity can shine: with a touch of Python, you can at least automate the entire, tedious creation of that table structure. And if you’re willing to invest a little more effort, you could even get Python to take on the initial heavy lifting of distributing those on-call duties.

#!/usr/bin/env python3
import calendar
import argparse
from datetime import date, timedelta
import xlsxwriter


def numToDayShort(num):
    weekdays_short = ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"]
    return weekdays_short[num]


def numToMonth(num):
    months = [
        "January",
        "February",
        "March",
        "April",
        "May",
        "June",
        "July",
        "August",
        "September",
        "October",
        "November",
        "December",
    ]
    return months[num - 1]


def main():
    workerNames = ["Frank Tornack", "Meister Kollege", "Walter Hugo", "Dr. Der Da"]
    workbook = xlsxwriter.Workbook("TestRB.xlsx")
    centerformat = workbook.add_format()
    centerformat.set_align("center")
    centerformat.set_bold()
    centerformat.set_font_name("Courier New")
    wecenterformat = workbook.add_format()
    wecenterformat.set_align("center")
    wecenterformat.set_bold()
    wecenterformat.set_font_color("#FF0000")
    wecenterformat.set_font_name("Courier New")
    boldonlyformat = workbook.add_format()
    boldonlyformat.set_bold()
    calyear = date.today().year
    calyear += 1
    Calobj = calendar.Calendar()
    currentWorker = -1
    daysFromLast = {}
    for month in range(1, 12 + 1):
        col = 0
        namerowcounter = 2
        worksheet = workbook.add_worksheet(numToMonth(month))

        for workerName in workerNames:
            worksheet.write(namerowcounter, col, workerName, boldonlyformat)
            if not workerName in daysFromLast:
                daysFromLast[workerName] = 0
            namerowcounter += 1
        worksheet.autofit()
        for day in Calobj.itermonthdays4(calyear, month):
            col += 1
            if month == day[1]:
                if currentWorker == -1:
                    currentWorker = 0
                elif day[3] == 0:
                    print("Monday")
                    currentWorker += 1
                    if currentWorker >= len(workerNames):
                        print("back to first")
                        currentWorker = 0
            for key in daysFromLast:
                if key == workerNames[currentWorker]:
                    daysFromLast[key] = 0
                else:
                    daysFromLast[key] += 1
            worksheet.write(2 + currentWorker, col, "RB")
            print(day)
            print(daysFromLast)
            worksheet.set_column(col, col, 4)
            if day[3] <= 4:
                worksheet.write(0, col, day[2], centerformat)
                worksheet.write(1, col, numToDayShort(day[3]), centerformat)
            else:
                worksheet.write(0, col, day[2], wecenterformat)
                worksheet.write(1, col, numToDayShort(day[3]), wecenterformat)

    workbook.close()


if __name__ == "__main__":
    main()

So, what’s my little Python script capable of right now? Well, it’s still a fledgling, but it already rolls up its digital sleeves to:

• Whip up a fully Microsoft-compatible XLSX file right from scratch.
• It then gets to work populating it, smartly creating a dedicated tab for each month. And here’s a neat touch: it accurately includes those often-overlooked overlapping days from the previous and next months, so you always get the complete picture.
• Plus, it neatly lays out all employee names in the first column of every sheet.

Now, for a bit of real talk: in its current incarnation, the script isn’t yet sophisticated enough to handle command-line arguments. This means that for the time being, you’ll need to take a quick peek into the source code to adjust the workerNames array directly. The output filename follows the same story – it’s just a line below in the code, ready for your customization.

But wait, there’s more under the hood! The script has a budding superpower: it already keeps a running tally of the days since each person last faced an on-call shift (though, for now, this vital intel is just displayed on the console). The grand vision, however, is to turbocharge this. I’m aiming to weave in dynamic logic that can intelligently juggle vacation schedules, those notoriously tricky public holidays that vary by region (yes, all you German Bundesländer, I see you!), and even birthdays.
Once that piece of the puzzle is in place, it becomes an absolute must: the system has to leverage these ’time-since-last-duty’ metrics to forge genuine fairness into the schedule, ensuring no one is inadvertently skipped or unfairly burdened. And you can absolutely bet that if I crack this code, I’ll be heralding it from the digital rooftops in a brand-new article!

So, over to you! What other brilliant strokes of genius or essential features do you think this on-call scheduling sidekick is desperately missing? Don’t hold back – unleash your thoughts in the comments below!