TechyMagThings

As part of his quest to find the best affordable generator for his DIY hydroelectric power system, [FarmCraft101] is trying out a range of off-the-shelf and DIY solutions, with in his most recent video trying his hands at the very relaxing activity of rewiring the stator of an alternator.

Normally car alternators output 12VDC after internal rectification, but due to the hundreds of meters from the turbine to the shed, he’d like a higher voltage to curb transmission losses. The easiest way to get a higher voltage out of a car alternator is to change up the wiring on the stator, which is definitely one of those highly educational tasks.

Disassembling an alternator is easy enough, but removing the copper windings from the stator is quite an ordeal, as they were not designed to ever move even a fraction of a millimeter after assembly.

With that arduous task finished, the rewinding was done using 22 AWG copper enamel wire, compared to the original 16 AWG wire, and increasing the loops per coil from 8 to 30. This rewinding isn’t too complicated if you know what you’re doing, with each coil on each of the three windings placed in an alternating fashion, matching the alternating South/North poles on the rotor.

Each phase’s winding is offset by two slots, leaving space for the other two phases, which then correspondingly are 90° out of phase when running, creating the three-phase AC output. This is further detailed in the video.

To make sure the windings do not short out on the stator, each slot has a bit of Nomex insulating paper placed into it, and a PETG 3D printed slot holder makes sure that none of the windings sneak out of their slot after installation.

The phases were connected in a Wye configuration, which gives it the maximum possible voltage rather than optimizing it for current as in a Delta configuration.

With the rewinding done, the alternator was reassembled, and the three-phase output of the new stator tested. After some trial and error it was able to do 200 VDC after passing it through an external rectifier, for a total of 700 Watt.

While not an unmitigated success, it seems quite possible to use this alternator as a higher-voltage generator with the hydro setup, especially after the upcoming replacement of the rotor’s electromagnet with neodymium magnets to further simplify it. As a bonus, if he ever needs to rebuild a broken alternator from scratch, rewinding a stator is now child’s play.

Part of traveling the world as an Anglophone involves the uncomfortable realization that everyone else is better at learning your language than people like you are at learning theirs. It’s particularly obvious in the world of programming languages, where English-derived language and syntax rules the roost.

It’s always IF foo THEN bar, and  never SI foo ALORS bar. It is now possible to do something akin to OS foo YNA bar though, because [Richard Hainsworth] has created y Ddraig (the Dragon), a programming language using Welsh language as syntax. (The Welsh double D, “Dd” is pronounced something like an English soft “th” as in “their”)

Under the hood it’s not an entirely new language, instead it’s a Welsh localisation of the Raku language. A localisation file is created, that can as we understand it handle bidirectional transcription between languages. The write-up goes into detail about the process.

There will inevitably be people asking what the point of a programming language for a spoken language with under a million native speakers is, so it’s worth taking a look at that head on. It’s important for Welsh education and the Welsh tech sector because a a geeky kid in a Welsh-medium school Pwllheli deserves to code just as much as an English kid in a school near Oxford, but it goes far beyond Welsh alone. There are many languages and cultures across the world where English is not widely spoken, and every single one of them has those kids like us who pick up a computer and run with it. The more of them that can learn to code, and thrive without having the extra burden of knowing English, the better. Perhaps in a couple of decades we’ll be using code from people who learned this way, without our ever knowing it.

As your scribe, this needs to be added: Mae’n ddrwg gyda fi ffrendiau Cymraeg, mae Cymraeg i yn wael iawn. Dwi’n dôd o’r Rhydychen, ni Pwllheli.

Header image: Jeff Buck, CC BY-SA 2.0.

The KDE desktop’s new login manager (PLM) in the upcoming Plasma 6.6 will mark the first time that KDE requires that the underlying OS uses systemd, if one wishes for the full KDE experience. This has especially the FreeBSD community upset, but will also affect Linux distros that do not use systemd. The focus of the KDE team is clear, as stated in the referenced Reddit thread, where a KDE developer replies that the goal is to rely on systemd for more tasks in the future. This means that PLM is just the first step.

In the eyes of KDE it seems that OSes that do not use systemd are ‘niche’ and not worth supporting, with said niche Linux distros that would be cut out including everything from Gentoo to Alpine Linux and Slackware. Regardless of your stance on systemd’s merits or lack thereof, it would seem to be quite drastic for one of the major desktop environments across Linux and BSD to suddenly make this decision.

It also raises the question of in how far this is related to the push towards a distroless and similarly more integrated, singular version of Linux as an operating system. Although there are still many other DEs that will happily run for the foreseeable future on your flavor of GNU/Linux or BSD – regardless of whether you’re more about about a System V or OpenRC init-style environment – this might be one of the most controversial divides since systemd was first introduced.

Top image: KDE Plasma 6.4.5. (Credit: Michio.kawaii, Wikimedia)

[XYZAiden]’s concept for a flexible robotic gripper might be a few years old, but if anything it’s even more accessible now than when he first prototyped it. It uses only a single motor and requires no complex mechanical assembly, and nowadays 3D printing with flexible filament has only gotten easier and more reliable.

The four-armed gripper you see here prints as a single piece, and is cable-driven with a single metal-geared servo powering the assembly. Each arm has a nylon string threaded through it so when the servo turns, it pulls each string which in turn makes each arm curl inward, closing the grip. Because of the way the gripper is made, releasing only requires relaxing the cables; an arm’s natural state is to fall open.

The main downside is that the servo and cables are working at a mechanical disadvantage, so the grip won’t be particularly strong. But for lightweight, irregular objects, this could be a feature rather than a bug.

The biggest advantage is that it’s extremely low-cost, and simple to both build and use. If one has access to a 3D printer and can make a servo rotate, raiding a junk bin could probably yield everything else.

DIY robotic gripper designs come in all sorts of variations. For example, this “jamming” bean-bag style gripper does an amazing, high-strength job of latching onto irregular objects without squashing them in the process. And here’s one built around grippy measuring tape, capable of surprising dexterity.

Hackers have been building their own basic oscilloscopes out of inexpensive MCUs and cheap LCD screens for some years now, but microcontrollers have recently become fast enough to actually make such ‘scopes useful. [NJJ], for example, used a pair of Raspberry Pi Picos to build Picotronix, an extensible combined oscilloscope and logic analyzer.

This isn’t an open-source project, but it is quite well-documented, and the general design logic and workings of the device are freely available. The main board holds two Picos, one for data sampling and one to handle control, display, and external communication. The control unit is made out of stacked PCBs surrounded by a 3D-printed housing; the pinout diagrams printed on the back panel are a helpful touch. One interesting technique was to use a trimmed length of clear 3D printer filament as a light pipe for an indicator LED.

Even the protocol used to communicate between the Picos is documented; the datagrams are rather reminiscent of Ethernet frames, and can originate either from one of the Picos or from a host computer. This lets the control board operate as an automatic testing station reporting data over a wireless or USB-connected network. The display module is therefore optional hardware, and a variety of other boards (called picoPods) can be connected to the Picotronix control board. These include a faster ADC, adapters for various analog input spans, a differential analog input probe, a 12-bit logic state analyzer, and a DAC for signal generation.

If this project inspired you to make your own, we’ve also seen other Pico-based oscilloscopes before, including one that used a phone for the display.

[Dave] over at Usagi Electric has a mystery on his hands in the form of a computer. He picked up a Motorola 68000 based machine at a local swap meet.  A few boards, a backplane, and a power supply. The only information provided is the machines original purpose: gas station pump control.

The computer in question is an embedded system. It uses a VME backplane, and all the cards are of the 3u variaety. The 68k and associated support chips are on one card.  Memory is on another.  A third card contains four serial ports. The software lives across three different EPROM chips. Time for a bit of reverse engineering!

[Dave] quickly dumped the ROMs and looked for strings. Since the 68k is a big endian machine, some byte swapping was required to get things human readable. Once byte swapped, huge tables of human readable strings revealed themselves, including an OS version. The computer runs pSOS, an older 68k based real time operating system – exactly what one would expect a machine from the 80’s to run.

The next step was to give it some power and see if the gas station computer would pump once again.  The LEDs lit up, and a repeating signal showed up from one of the serial ports. The serial connections on this machine are RS-485.  Not common for home computers, but used quite a bit in industrial embedded systems.  Unfortunately, the machine wouldn’t respond to commands sent from a terminal. The communication protocol remained a mystery.

Since this video has gone up though, several people have provided a wealth of information at the vintage-micros channel over on [Dave’s] Usagi Electric Discord.

Gas pumps are a bit of a departure from [Dave’s] usual minicomputer work. We’re no strangers to embedded systems here though.

Horoscopes are a great way to pass a boring lunchbreak, and an excellent excuse for ending a ill-considered relationship. They’re also a hilarious way to handle CPU scheduling under Linux, thanks to the work of [Lucas Zampieri].

The project is called scx_horoscope, and it’s a sched_Ext scheduler that makes its CPU scheduling choices based on what the heavens are doing in real time. Different tasks are handled based on different astronomical objects. For example, the Sun represents life force, and thus grants boons to key system processes. The Moon, an emotive influence, rules over interactive processes like shells and terminals. Mercury, as the god of communication, handles network and IO tasks, and so it goes from there. It’s not just a surface level thing, either—[Lucas] has implemented the influences of the elements of fire, air, earth, and water, and there are negative timeslice penalties on associated tasks when a given planet lands in retrograde.

You can argue whether or not the broader motions of the heavens have any impact on our lives based on the time and circumstances of our birth. But you can’t argue that scx_horoscope really will influence how your computer runs based on the dance of the planets in the sky. Mostly, though, we concern ourselves with astronomy rather than astrology around these parts!

[Thanks to Benjamin for the tip!]