Nothing profound here. But sometimes the internet collective can still be surprising.
Apparently, you can already cross-compile Zig (at least the basic stuff) for plan9.
Now this is fun!
Also, a note to self more than anything: while zig itself is simple and quick to take in, the built-in build system takes a bit to get used to, but it’s slowly starting to make sense. Especially since discovering you can use it to compile C/C++ code too.
Another month, another file system.
Well, if you can’t fix it in software, fix it in hardware (looking at you, bme680, we’re not done yet). The show must go on, as they say, and I would like my experiments to go on.
So a “new” addition to the environmental sensor family connected to the humble “server”: sgp30.
I say “new” because it was new when it was ordered, but it has since been discontinued. Work with what you have! At least you can still get them, and the new one is not that different.
Now things are getting interesting:
The days are getting shorter, and the nights are getting colder. Winter is coming! Which means groggy and slow mornings. And looking at the quantified air quality data for the first time, it might not be the anecdotal lack of early sunshine or low temperatures.
Additional data is required.
There’s no shame in that. Yes, there is documentation, code to be read, and debuggers to be used. But sometimes you just need to “see” what is happening.
So what warrants this reaction? Well, my project of shoehorning command history into plan9 still has some issues. One of them is not always working over drawterm, which is kind of annoying when working on remote systems. Especially with repetitive tasks like working on a sensor, where the development cycle is compile, run, analyze and repeat. Small commands that are not long enough as to feel like mousing around with a mouse is usefull. And not short enough to just type them in passing.
So let’s sniff what’s actually appearing on the application side. Code proudly referenced from riow program in 9front.
Some context: as understood from a quick glance at the riow code (true, I should research this more, when it’s time), keyboard input is presented as a “train” of characters or runes with a tag at the beginning. Either there is a control (ALT or SHIFT or CTRL or MODE or …) key being pressed (‘K’ character) or released (‘k’ character) OR a regular character is being sent (‘c’ character).
The referenced code looks for a control character to figure out if a modifier key is being pressed, followed by a regular character. In my case (CTRL + UP/DOWN) something is not behaving as expected.
Let’s do some tests and compare the results!
Tests are done by typing command lc followed by ENTER, then pressing the CTRL key and then the UP key.
9front in QEMU - regular character denotes UP:
9front on Raspberry Pi 1 with keyboard & mouse - regular character denotes UP:
9front over drawterm (CONF=linux) on wayland - regular character denotes CTRL:
9front over drawterm (CONF=unix) on wayland - regular character denotes Shift Out:
9front over drawterm (CONF=linux) on x11 - regular character denotes Shift Out:
9front over drawterm on windows - regular character denotes Backspace:
Now this is certanly a wide collection fo results. Whan can we deduce from this?
Bare metal and QEMU are identical, so let’s assume this is how it is read from the physical input device.
- OK as it is.
Windows and Linux on Wayland have the right keys in control (k) block, but not in regular character (c).
- Fixed now in current version of histw by checking only (k) for key combinations.
Unix on X11 or wayland if a wild mix.
- Can’t fix in histw.
Conclusion of this test?
All signs point to how drawterm interprets or sends input information forward. This might be a future mini project to look into that. Might! One step at a time.
For now, let’s take the small win and use the latest and greatest (drawterm on Windows or Linux compiled for wayland) and live with the fix in histw for now.
Before we dive deeper into this rabbit hole, let’s figure out why printing out long commands on the input line stopped working.
More precisely, it is okay to do boring, soul-crushing things.
We all want to do “fancy” and exciting things, most, if not all the time. This very blog is an exercise in posting something neat.
But most of the time, you have to play an adult and do the nitty-gritty things to actually finish something.
Now, this bme680 sensor is becoming a pet peeve of mine.
Thinking that the heating element was burned, not much attention was paid to the actual gas resistance values denoting air quality. Not that there is any reference to good/bad values outside of using the BSEC library to print out an AQI value. And now with a set of working sensors, the results did not get better or comparable with the output from the Arduino install.
To be fair, upon a review, a few of my own bugs were discovered (like, never actually writing proper heating timings to the sensor). Don’t code during heatwaves without an AC; it’s not good for your code.
Nevertheless, something is “missing” from the documentation:
Now this example actually turned out to be a red herring, since all sensors are identified from the documented registers, and you can’t blame the manufacturer for this too much. It might have something to do with internal testing/QA or a set-up for a different sensor in the family. Who knows?
But then there is this doodoo duckery:
This is why we have trust issues. When using the BSEC Arduino library with the binary blobs that can calculate the AIQ from gas resistance, if you check the communication on the bus with a logic analyzer, you can see the library writing values to bits that are marked DO NOT CHANGE in the documentation.
A theory is being developed here: this sensor is great and easy to use for temperature, pressure, and humidity. Start sampling, read the data, convert to preferred units, and that’s it. For air quality, this was never intended to be used without the provided blobs.
Now that we are observing the sensor with the BSEC library, there are some quirks being discovered. From “burn in time” for gas sensor (before giving reliable measurements) not being time since the sensor was powered on but time constantly sampling at least every 3 seconds. To the documentation/library performing “do as I say, not as I do” and changing DO NOT CHANGE BITS.
Now this mistery is far from over. But the process of solving it is tedious. Boring. Filled with wishes for doing something more exciting. And yet, you have to do what you have to do. And that’s okay.
Well, it’s more of a reminder than a lesson.
It is more important what you optimize than how much you optimize.
It turns out, that for all the overclocking and tweaking of the abused first generation Raspberry Pi, the best performance increase you can get:
Is to not read everything all of the time from the SD card:
Some quality of life improvements for YOU three (you know who you are) that have found and use this page.
Firstly, some improvements to RSS functionality of werc. Now, the built-in blagh blog or the additional barf app have a nice feature that generates an RSS feed list by calling index.rss on the content folder. Something that I think would be cool for any folder. Maybe you’re interested in just part of the site or would like an RSS feed update when new content is posted, but is not a blog.
Well, this feature is no longer missing! Introducing the rrsfy werc app, which allows for RSS feed creation on any configured folder through the index.rss “interface”.
This brings the available feeds for this site to:
- blog https://offbeatpursuit.com/blog/index.rss
- paste https://offbeatpursuit.com/paste/index.rss
- notes https://offbeatpursuit.com/notes/index.rss
And while we’re here, since the code for the rssfy is based on the existing apps, a fix for the creation date if posts for barf.
To improve the blog, let’s make an index of tags. More in the web notes
The barf comes with some scripts (some work, some are author specific), and one of them (gt) generates a list of posts and associated tags (which makes clicking on the tag and displaying associated posts work).
Now, let’s add some custom magic to generate a header with clickable links. And there we go.
Secondly, there are also some CSS tweaks to spruce up the look.
How all this affects the look is left as “homework” for the reader to figure out.