Center-Pivot System Modified To Mow Lawn

When flying over the United States, Australia, and a few other vast and relatively empty parts of the world, strange circular formations can be spotted. These are typically center-pivot irrigation systems, an effective way to irrigate crops if efficient use of space is not too big of a priority. Keeping these massive machines in a straight line is an interesting engineering problem, though, and [rctestflight] built a miniature version of his that works on the same principle but mows his lawn instead.

These systems work as semi-independent sections that are flexibly coupled at either end. The control scheme initially used here was to drive the outermost set of wheels at a constant speed, and then use limit switches at each coupling inside of that to drive inner sets of wheels once the outer set passes a setpoint. Eventually a potentiometer-based proportional controller was installed in place of the limit switches. With some other drivetrain issues sorted out it was on to building the mower attachment. This uses a pair of pivoting precision knives mounted to motors that ride along a carriage attached to any one of the linkages of the center-pivot system. Limit switches keep the carriage riding back and forth cutting the lawn as it traverses the grass.

With the system in place, [rctestflight] set out to optimize it mostly out of a desire to tinker with a thing that he had built. The challenge for him is that his location in the Pacific Northwest is generally very damp, so in addition to corrosion and other water damage on various parts, there were also issues of mud complicating the way the wheels navigated the terrain, as well as the plant growth being fairly rapid and often impeding the process of the robot as well. One of the perks, though, was that the circular area was already largely carved out thanks to some of his earlier projects testing the durability of RC cars.

Continue reading “Center-Pivot System Modified To Mow Lawn” →

Going On A Tangent With The Intel 8087’s Hybrid CORDIC Algorithm

Continuing their reverse-engineering of Intel’s 8087 FPU, [Ken Shirriff] and friends took a look at one of the trigonometric functions, specifically FPTAN.  The most exciting part with such reverse-engineering is probably figuring out which algorithm was used in the implementation, while trying to determine the reasoning behind the final hardware design.

If you’re running a simple MCU or MPU like the 6502 or Z80 without hardware functions you’d likely use an algorithm such as CORDIC or similar, as this requires only basic hardware features like addition, subtraction, bitshift, and look-up tables. One can also use polynomial approximation if there’s hardware support for a potential speed-up, or as is the case in the 8087, create a hybrid approach that targets speed and accuracy.

In the article the exact implementation to get to 64 bits of accuracy is detailed, starting with the 16 bits calculated using CORDIC before switching to the Padé approximant technique involving the ratio of two polynomials. Since after calculating the brunt of the final value with CORDIC the remainder is a fairly small value this polynomial approximation not just very accurate but also fast.

This approach allows the FPTAN and similar trigonometric functions in this FPU to hit a very high level of accuracy and not require the look-up table sizes and additional time required to work through the remaining bits with CORDIC. For those who want to see the full algorithm Intel’s engineers used, [Ken] has the full microcode listing with comments in the article as well.

As for the exact speed-up from this approach, [Ken] calculates for one value that FPTAN would spend 33% on CORDIC pseudo-division, 47% on CORDIC pseudo-multiplication and a mere 15% on the polynomial approximation along with about 5% overhead.

With the Pentium series of CPUs Intel moved completely away from CORDIC, as it’s clear that as accurate as it may be, it’s hard to scale to a significant number of bits without incurring significant time penalties. With the introduction of SIMD instructions the x87 ISA has further seen its functionality reduced, but this analysis shows once again why the 8087 made such an impact when it was released.

A digital map is shown with a series of red waypoints making a roughly C-shaped curve. A smaller group of green waypoints stays stationary near one of the corners of the map.

Defeating Satellite Spoofing With Galileo’s Encryption

Considering how important it is for everything from navigation to keeping clocks in sync, satellite navigation systems are surprisingly vulnerable to a variety of attacks, ranging from simple jamming to more sophisticated spoofing attacks. This may be changing, though, as Galileo, Europe’s GNSS, recently demonstrated its first cryptographically-secured position fix under spoofing conditions.

Most GNSS systems, including GPS, have no verification measures to keep an adversary from transmitting a false signal at a higher power and hijacking a receiver; since GNSS signals are extremely weak by the time they reach the ground, this presents no great difficulty to a moderately well-equipped attacker.

Galileo’s Signal Authentication System (SAS) aims to fix this. The Galileo ground station pre-selects signal spreading codes, which it then encrypts with a regularly-changing secret key and publishes. A receiver which anticipates needing a verified signal can then download these encrypted codes ahead of time and store them. Galileo satellites then transmit on the E6-C pilot signal, and the receiver records the signal. After transmitting a message block, it then transmits the decryption key on a separate signal, which the receiver uses to recover the spreading codes. The receiver then correlates these spreading codes with the recorded signal to find the satellite’s pseudorange.

It’s a rather complicated system, but it works: earlier this month in Andøya, Norway, the annual Jammertest GNSS testing event took place. For one week, a wide range of organizations tested the resilience of their GNSS systems against various attacks, including jamming, delayed retransmission, and spoofing. Using five Galileo satellites, the European Space Agency was able to obtain a stable lock on their receiver even during spoofing.

In principle, this method could be extended to other GNSS systems. There’s certainly motivation to do so; very large-scale attacks have been demonstrated recently.

Ways To Empirically Identify A Magnet’s Polarity

Every magnet has a north and a south pole, but which is which? Sometimes it matters. If a product one builds features a magnetic closure or other part, the polarity of those magnets should be consistent in assembly. So how does one ensure they never glue a magnet wrong again? [Clough42] shows several ways to identify a magnet’s north and south poles using things many of us probably have ready at hand, and goes into a bit of theory while he’s at it.

Probably the easiest way is to use a known-good and clearly labeled reference magnet. Same poles repel, and opposites attract. But if that’s not available, a simple magnetic compass can help. Because opposite poles attract, a compass’s north point will be attracted toward a magnet’s south pole, and vice versa.

A Hall effect sensor, or an electromagnet — the winding and current flow determine the polarity — are other ways to measure a magnet’s poles. And here’s where [Clough42] dives into some details of how magnetic fields actually act, because it explains some seemingly strange behavior.

For example, at around 4:08 he demonstrates a Hall effect sensor board that is documented as lighting an LED when the south pole of a magnet is held to its front. It does that, but it also lights the LED when the north end of the magnet is held to the sensor’s back. That’s because the sensor isn’t actually directly sensing the magnet’s pole, it’s sensing the orientation of a magnetic field. The lesson is clear: make sure you’re measuring what you think you’re measuring. Near the end of the video he demonstrates a similar experience with a handy mobile phone app that senses magnetic fields by reading the device’s internal magnetic compass; by waving a strong magnet around, the detected polarity flips back and forth even though the magnet’s orientation isn’t changed.

So what does one do after positively identifying a magnet’s north and south poles? Label it clearly for use as a known-good reference magnet in the future is our suggestion. Watch the whole video below, then take a few minutes to dive into the nitty-gritty of what magnets actually are and how they work.

Continue reading “Ways To Empirically Identify A Magnet’s Polarity” →

Enormous Fluid Simulation On Flip Dots Is Also Enormous Amount Of Work

Flip dot displays are cool, and more people realize that after [mitxela]’s fluid simulation on flip dots installation was on display at EMF 2026. As glorious as the result is, it was also an amazing amount of work!

Not only did [mitxela] need to source a large number of flip dots, he also needed to find a solution for driving them that didn’t end up more trouble than it was worth. Just about everything about the surplus flip dots — from electrical requirements to mounting — was a pain to work with in one way or another. Even his optimized method of integrating a custom backpack-style driver board into the existing PCB involved a staggering amount of soldering. This project was a long time coming, and the work never really let up.

The payoff, however, is exquisite. Check it out in the video (embedded below) which really shows it off. Flip dots are like nothing else, and the subtle rippling of sound that accompanies their physical movement is oddly soothing.

The installation at EMF 2026 had a GRAVITY CONTROL joystick that allowed folks to interactively shift the display, but [mitxela] also has an accelerometer mounted so that the display physically reacts to being moved. It’s a fantastic spectacle, even more impressive in light of the work it involved.

Unsure how, exactly, flip dots work? We’ve covered all the details about how these devices function. And while a large number would be prohibitively expensive for most projects, if your project can get away with only one dot you’re probably in luck.

Continue reading “Enormous Fluid Simulation On Flip Dots Is Also Enormous Amount Of Work” →

Reverse Engineering Apple’s Mikey Chip

On the old iPods, generally referred to here in the future as iPod Classic, there lives a tiny, undocumented chip called Mikey. It sits at the headphone output and performs only two functions: powering the Apple wired headset microphone and handling button presses from the three buttons. Despite these headphones and iPods having existed for nearly two decades, no one in the open source community has figured out the protocol Apple used for these buttons until now.

As [Hemant] discovered after finding a single archived blog post from 16 years ago about it, the chip is relatively simple by modern standards. Besides handling microphone bias, it sits on an I2C bus and monitors presses from the three buttons on the headset. Each button has its own resistive load, so a press from any of them drops the voltage on the line to a certain amount which the chip can read. The more involved part is a “chirp” that’s a sort of handshake between headset and iPod, which took a bit of work with a debugger that [Hemant] built into a custom Rockbox firmware.

With the chirp sorted out, [Hemant] built the feature into an existing version of Rockbox, and submitted the update to the Rockbox team for integration in future official builds. It’s a long overdue feature for those still using wired headphones and iPods from the turn of the century, but welcome. Some of those iPods are still working to this day, but only conditionally if they’re very cold.

When The Debugger Lies With Stale Cache Values

In a recent blog post by [Daniel Mangum] he goes over a scenario observed while debugging the Cortex-M33-based nRF54LM20, reading and writing values while running through a few scenarios. After initially it seemed to go seemingly without any issues, suddenly the GDB debugger would happily return values that suggested that a previous operation had not succeeded. Or, as the case turned out to be, stale cached values were being returned.

What follows is a very technical and low-level breakdown of how this MCU functions inside, especially its cryptographic features and Key Management Unit, which is used for storing sensitive information. The most amusing part is probably you can bypass the cached data by explicitly specifying the access port and memory address along with other parameters.

This ReadMemAP command supported by the JLinkGDBServer used here showed the right value, whereas the normal GDB read command using x kept returning the cached values. This raised the question of which cache was doing this. The direct read from the AHB-AP access port worked fine, so the suspicion is that the J-Link software’s own caching, with a run without the J-Link caching indeed working fine.

J-Link has had some hardware-related issues too, with this new issue pointing to an awkward software bug that could be table-flip-and-rage-quit worthy depending on how much time it wastes during a debug session. Fortunately [Daniel] seems to have caught this one quickly and had an easy way to bypass it, but we aren’t all that lucky.