Putting on a headset and using virtual monitors in VR instead of physical ones is a use case that pops up, but is it really something feasible? [Karl Guttag], who has long experience and a deep understanding of the technical challenges that face such devices, doesn’t seem to think so.

In his writeup [Karl] often focuses on the recently-unveiled high resolution Apple Vision Pro, but the issues he discusses transcend any particular product. His article is worth the read for anyone with an interest in these issues, but we’ll summarize some main points here.

A primary job of a monitor is to display text. Text is so important, in fact, that it gets handled as a special case. Font hinting is the process (and art) by which the fine details and lines inherent to text are translated to a pixel grid for best appearances in all circumstances. This grid fitting — specialized mapping of characters to fit a rasterized grid of pixels — has been a major part of computers for over forty years, and almost all font rendering relies on it. It’s an especially important part of making text look good on lower resolution displays.

But normal grid fitting cannot be applied to a virtual monitor because one cannot rely on content being rendered in any particular orientation. Between a monitor and a virtual display of equal resolution, virtual text will always look worse because the usual grid fitting tricks don’t work. Giving a virtual monitor higher resolution is one way to fix this, but at least so far, virtual monitors are going to have fewer pixels to work with, not more. Physical monitors do not have to share their pixels with anything else, but the little screens inside VR headsets do.

Making virtual monitors bigger is another way to give them more pixels, but as virtual monitors get bigger they get less comfortable to use. As soon as one begins to have to move one’s head to read the whole screen, things get very tiresome very quickly. For serious desktop computer work, movie theatre-sized virtual monitors are not ideal.

[Karl] seems to have good reasons to believe VR headsets will continue to make poor monitor replacements, but there are other efforts from people and organizations trying to make it work. The SimulaVR folks, for example, aim to make an open-source Linux headset that functions primarily as a monitor replacement, and their proposed solution to boost resolution is a lens that squashes pixels towards the center of the field of view. Another direction is from a company unsatisfied with existing headsets’ ability to render virtual monitors, so they announced their own. Neither of those are finished products one can actually buy at the moment, but clearly [Karl] isn’t the only one thinking about these problems.

Would you use a VR headset to replace your monitor? Either way, such a headset would probably make a good basis for a cyberdeck build.

The first computer to ever beat a reigning chess world champion didn’t do so until 1996 when a supercomputer built by IBM beat Garry Kasparov. But anyone who wasn’t a chess Grandmaster could have been getting beaten by chess programs as early as 1979 when Atari released one of the first ever commercially-available chess video games for the Atari 2600. The game was called Video Chess and despite some quirky gameplay it is quite impressive that it was able to run on the limited Atari hardware at all as [Oscar] demonstrates.

The first steps of getting under the hood of this program involved looking into the mapping of the pieces and the board positions in memory. After analyzing some more of the gameplay, [Oscar] discovered that the game does not use trees and nodes to make decisions, likely due to the memory limitations, but rather simulates the entire game and then analyzes it to determine the next step. When the game detects that there are not many pieces left on the board it can actually increase the amount of analysis it does in order to corner the opposing king, and has some unique algorithms in place to handle things like castling, finishing the game, and determining valid movements.

Originally it was thought that this engine couldn’t fit in the 4K of ROM or work within the 128 bytes of system memory, and that it was optimized for the system after first developing a game with some expanded capabilities. The game also has a reputation for making illegal moves in the higher difficulty settings although [Oscar] couldn’t reproduce these bugs. He also didn’t get into any of the tricks the game employed just to display all of the pieces on the screen. The AI in the Atari game was a feat for its time, but in the modern world the Stockfish open-source chess engine allows for a much more expanded gameplay experience.

How worn are your nozzles? It’s a legitimate question, so [Stefan] set out to find out just how bad 3D-printer nozzle wear can get. The answer, as always, is “It depends,” but exploring the issue turns out to be an interesting trip.

Reasoning that the best place to start is knowing what nozzle wear looks like, [Stefan] began by printing a series of Benchies with brand-new brass nozzles of increasing diameter, to simulate wear. He found that stringing artifacts, interlayer holes, and softening of overhanging edges and details all worsened with increasing nozzle size. Armed with this information, [Stefan] began a torture test of some cheap nozzles with both carbon-fiber filament and a glow-in-the-dark filament, both of which have been reported as nozzle eaters. [Stefan] found that to be the case for at least the carbon-fiber filament, which wore the nozzle to a nub after extruding only 360 grams of material.

Finally, [Stefan] did some destructive testing by cutting used nozzles in half on the mill and looking at them in cross-section. The wear on the nozzle used for carbon-fiber is dramatic, as is the difference between brand-new cheap nozzles and the high-quality parts. Check out the video below and please sound off in the comments if you know how that peculiar spiral profile was machined into the cheap nozzles.

Hats off to [Stefan] for taking the time to explore nozzle wear and sharing his results. He certainly has an eye for analysis; we’ve covered his technique for breaking down 3D-printing costs in [Donald Papp]’s  “Life on Contract” series.

So you just got something like an Arduino or Raspberry Pi kit with a few sensors. Setting up temperature or motion sensors is easy enough. But what are you going to do with all that data? It’s going to need storage, analysis, and summarization before it’s actually useful to anyone. You need a dashboard!

But even before displaying the data, you’re going to need to store it somewhere, and that means a database. You could just send all of your data off into the cloud and hope that the company that provides you the service has a good business model behind it, but frankly the track records of even the companies with the deepest pockets and best intentions don’t look so good. And you won’t learn anything useful by taking the easiest way out anyway.

Instead, let’s take the second-easiest way out. Here’s a short tutorial to get you up and running with a database backend on a Raspberry Pi and a slick dashboard on your laptop or cellphone. We’ll be using scripts and Docker to automate as many things as possible. Even so, along the way you’ll learn a little bit about Python and Docker, but more importantly you’ll have a system of your own for expansion, customization, or simply experimenting with at home. After all, if the “cloud” won’t let you play around with their database, how much fun can it be, really?

InfluxDB and Grafana wrapped up in Docker

Let’s get our parts together, starting with the database. InfluxDB is an open-source time series database that’s fast and intended for storing data that varies over time, like your sensor data.  It processes this data using an SQL-like language. Writing SQL is nobody’s idea of fun, but it’s standard.

Grafana is an analytics platform that lets you visualize data and do stuff like generate alerts. It supports plugins which means that it allows integration with other software. It will be used to talk to our InfluxDB and then do some awesome stuff.

Docker is a containerization program which basically means that it allows us to put together our application, it’s dependencies, libraries and components together in a box so that it becomes easier for us to maintain and move things. Most importantly, it allows us to use containers that others have already prepared to make our lives easier.

Setup Docker

Now I am doing things in Linux, because I intend to migrate this to a Raspberry Pi once I’m done experimenting. That said, typing a couple of sentences into the command line is as easy as navigating drop-down menus anyway. The first step is to install docker and docker-compose:

 
sudo apt-get update && sudo apt-get install docker docker-compose

Not much else to it at this point. Restart you machine just in case. The documentation for the community edition can help answer a number of question that you might have.

We said already that docker images are readily available for use and so we need a docker image for InfluxDB as well as another one for Grafana. To get things up and running quickly, clone my repository from GitHub .

git clone https://github.com/inderpreet/py_docker_grafana_influxdb_dashboard.git
docker-compose up -d
chmod +x add_datasource.sh && ./add_datasource.sh
cd pyclient && chmod +x setup_env.sh && ./setup_env.sh
python test.py

To test if things work, do a docker ps -a in a new terminal. This should return a list of containers running on your system. Copy the container ID from the list and run docker exec -it 1772a6e6387c influx
replacing the container ID for your machine. You should get an influxDB shell and can run commands such as:

show users
show databases
create database hackaday

We need to create a database to store our sensor readings so go ahead and do that. I have used “hackaday” as the name though it can be anything.

Quickly, testing things:

use hackaday
insert dummySensor v=123
insert dummySensor v=567
insert dummySensor v=000
select * from dummySensor

After typing the above in manually, you should be able to see the data in a time series.

The time stamp is in nano seconds and there can be more than one data value for a particular series — maybe one from each sensor. Given some better names, you can look at any given sensor’s data using the following SQL query: select livingRoom from temperatureSensors. Note: If you’re populating a test database by hand, do no put spaces between the comma and next value field.

The Python script I have included will generate a sensor data in an exponential form and will reset the value to 1.1 once it hits 100.0 . This should allow us to plot a dummy curve in Grafana.

Set Up Grafana

Grafana is already up and running thanks to the docker and can be accessed at http://localhost:3000 Once you enter the URL in the browser, Grafana should greet you will a login prompt. You can then login with username/password admin/admin. (You might want to change this pretty soon!)

Next, check to see that your InfluxDB is recognized by Grafana, using “Add Sources” if not. Click Save and Test and to confirm. Make sure the default checkbox at the top is ticked.

Next we should create a dashboard. From the left menu bar, select Dashboard>home and new dashboard. This should spit out an empty canvas with a few icons.

Select Graph and then click on the little title called Panel Title or simply press “e” on your keyboard. Then set it up so that:

– DataSource is set to InfluxDB
– selectMeasurement is set to sensorData
– fill is set to fill(previous)

And at the top, the refresh is set to 5 seconds and display for the last 15 minutes.

Reading Temperature

The reason that I have left the Python script outside of the Docker container is so that life will be easier when we make needed changes to read sensor data. For now, let’s take data in from a locally connected sensor attached to a microcontroller that can speak serial to your computer, to be read by a Python routine.

import serial

# replace with serial port name
ser = serial.Serial('/dev/ttyACM0')
ser.flushInput()

while True:
try:
temp_str = ser.readline()
temp = float(temp_str)
print(temp)
except:
print("Keyboard Interrupt")
break

As long as you can get your Arduino or equivalent to spit out numbers as a string, this script will receive them and translate them into floating point numbers. I leave the part about pushing the data into the InfluxDB as an exercise for the reader. (Hint: you can copy and paste code from/into the test.py I have provided.)

Raspberry Pi and the Sense Hat

The next stage would be moving to a Raspberry Pi. Got one for Christmas? You are in luck. Clone my repository from GitHub and do the same steps as before. Instead of the test.py, I have a sense_hat_temperature.py that can be executed. With this, you should be able to add sensorData and temperature and humidity values to the database.

Customization And Conclusion

The Docker system is configured using the docker-compose.yml file. In particular, there is a volumes variable that create a local folder influxdb_data which is where the data is written. You could configure it to write to say an external drive or even a network drive.

In case of the Raspberry Pi, this can be extremely useful. I wanted a way to be able to display sensor data easily while getting a few Python and Docker experiments going. This is just the beginning, though, since there is a lot more that can be done.

So far, our sensor device is an Arduino tied to the computer by a serial cable. If we want to take this wireless, we’ll need to think about getting the data from the sensor to the database. You could do worse than using MQTT and WiFi on an ESP8266. For power-sensitive applications, consider Bluetooth LE.

For now, get this system up and running and play around with local data. That way, when you build out the rest of your home sensing and automation network, the back end will be ready for you.

The electricity on the power grid wherever you live in the world will now universally come to you as AC. That is to say that it will oscillate between positive and negative polarity many times every second. The frequency of 50 or 60Hz just happens to be within the frequency range for human hearing. There’s a lot more than this fundamental frequency in the spectrum on the power lines though, and to hear those additional frequencies better you’ll have to do a little bit of signal processing.

We first featured this build back when it was still in its prototyping phase, but since then it’s been completed and used successfully to find a number of anomalies on the local power grid. It takes inputs from the line, isolates them, and feeds them into MATLAB via a sound card where they can be analyzed for frequency content. It’s been completed, including a case, and there are now waterfall diagrams of “mystery” switching harmonics found with the device, plus plots of waveform variation over time. There’s also a video below that has these harmonics converted to audio so you can hear the electricity.

Since we featured it last, [David] also took some feedback from the comments on the first article and improved isolation distances on his PCB, as well as making further PCB enhancements before making the final version. If you’ve ever been curious as to what you might find on the power lines, be sure to take a look at the updates on the project’s page.

[Calango] is a railway technician, and for a school final project created the Rail Wear Surveillance Trolley (RWST) which is a delightfully designed device made mainly from PVC conduit with one job: travel down a segment of train track while shining a green laser onto the rail, and capture camera images. The trolley holds both the laser and the camera at just the right angles for the camera to capture a profile of the rail’s curved surface. The images are sent via Bluetooth to a smartphone for later analysis. Rail wear can be judged by checking how well the profile of the rail conforms to the ideal profile of an unworn segment. The trolley is manually pushed by an operator, but [Calango] says that ideally, it would be self-propelled and able to inspect a length of the track then return on its own.

The project was made on a tight budget, which led to some clever solutions like using a rotary encoder attached to a wheel as a makeshift distance sensor. If things get desperate enough, it’s even possible to roll your own rotary encoder with a 3D printer and two microswitches.

Here’s a really interesting writeup by [Mike] that has two parts. He shows that not only is it possible to load wooden dice by placing them in a dish of water, but that when using these dice to get an unfair advantage in Settlers of Catan, observation of dice rolls within the game is insufficient to prove that the cheating is taking place.

[Mike] first proves that his pair of loaded dice do indeed result in a higher chance of totals above seven being rolled. He then shows how this knowledge can be exploited by a Settlers of Catan player to gain an average 5-15 additional resource cards in a typical game by taking actions that target the skewed distribution of the loaded dice.

The second part highlights shortcomings and common misunderstandings in current statistical analysis. While it’s possible to prove that the loaded dice do have a skewed distribution by rolling them an arbitrary number of times, as [Mike] and his wife do, it is not possible to detect this cheating in a game. How’s that? There are simply not enough die rolls in a game of Settlers to provide enough significant data to prove that dice distribution is skewed.

Our staff of statistics Ph.D.s would claim that [Mike] overstates his claims about shorcomings in the classical hypothesis testing framework, but the point remains that it’s possible to pass through any given statistical testing process by making the effect just small enough. And we still think it’s neat that he can cheat at Settlers by soaking wooden dice in water overnight.

This isn’t the first time we’ve seen Settlers of Catan at the center of some creative work. There’s this deluxe, hand-crafted reboot, and don’t forget the electroshock-enabled version.

[via Reddit; images from official Catan site]