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?

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.

[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.

For the longest time, Zener diode regulators have been one of those circuits that have been widely shared and highly misunderstood. First timers have tried to use it to power up their experiments and wondered why things did not go as planned. [James Lewis] has put up a worth tutorial on the subject titled, “Zener Diode makes for a Lousy Regulator” that clarifies the misconceptions behind using the device.

[James Lewis] does an experiment with a regulator circuit with an ESP8266 after a short introduction to Zener diodes themselves. For the uninitiated, the Zener diode can operate in the reverse bias safely and can do so at a particular voltage. This allows for the voltage across the device to be a fixed value.

This, however, depends on the current flowing through the circuit which in turn relies on the load. The circuit will work as expected for loads the draw a small amount of current. This makes it suitable for generating reference voltages for microcontrollers and such.

To make a Zener into a “proper” voltage regulator, you just need to buffer the output with an amplifier of some kind. A single transistor is the bare minimum, but actually can work pretty well. You might also add a capacitor in parallel with the Zener to smooth out some of its noise.

Everyone’s favorite packet sniffing tool, Wireshark, has been around for almost two decades now. It’s one of the most popular network analysis tools available, partially due to it being free and open source. Its popularity guaranteed that it would eventually be paired with the ESP32/8266, the rising star of the wireless hardware world, and [spacehuhn] has finally brought these two tools together to sniff WiFi packets.

The library that [spacehuhn] created uses the ESP chip to save Pcap files (the default Wireshark filetype) onto an SD card or send the data over a serial connection. The program runs once every 30 seconds, creating a new Pcap file each time. There are many example scripts for the various hardware you might be using, and since this is written for the ESP platform it’s also Arduino compatible. [spacehuhn] has written this as a proof-of-concept, so there are some rough edges still, but this looks very promising as a network analysis tool.

[spacehuhn] is no stranger to wireless networks, either. His YouTube channel is full of interesting videos of him exploring various exploits and testing other pieces of hardware. He’s also been featured here before for using an ESP8266 as a WiFi jammer.