For those with quadriplegia, electric wheelchairs with joystick controls aren’t much help. Typically, sip/puff controllers or eye-tracking solutions are used, but commercial versions can be expensive. [Dhruv Batra] has been experimenting with a DIY eye-tracking solution that can be readily integrated with conventional electric wheelchairs.
The system uses a regular webcam aimed at the user’s face. A Python script uses OpenCV and a homebrewed image segmentation algorithm to analyze the user’s eye position. The system is configured to stop the wheelchair when the user looks forward or up. Looking down commands the chair forward. Glancing left and right steers the chair in the given direction.
The Python script then sends the requisite commands via a TCP connection to an ESP32, which controls a bunch of servos to move the wheelchair’s joystick in the desired manner. This allows retrofitting the device on a wheelchair without having to modify it in an invasive manner.
It’s a neat idea, though it could likely benefit from some further development. A reverse feature would be particularly important, after all. However, it’s a great project that has likely taught [Dhruv] many important lessons about human-machine interfaces, particularly those beyond the ones we use every day.
This project has a good lineage as well — a similar project, EyeDriveOMatic won the Hackaday prize back in 2015.
There’s a strange synchronicity in the projects we see here at Hackaday, where different people come up with strikingly similar stuff at nearly the same time. We’re not sure why this is, but it’s easily observable, with this vintage altimeter teardown and repair by our good friend [CuriousMarc] as the latest example.
The altimeter that [Marc] dissects in the video below was made by Kollsman, which is what prompted us to recall this recent project that turned a jet engine tachometer into a CPU utilization gauge. That instrument was also manufactured by Kollsman, but was electrically driven. [Marc]’s project required an all-mechanical altimeter, so he ordered a couple from eBay.
Unfortunately, thanks to rough handling in transit they arrived in less than working condition, necessitating the look inside. For which we’re thankful, of course, because the guts of these aneroid altimeters are quite impressive. The mechanism is all mechanical, with parts that look like something [Click Spring] would make for a fine timepiece. [Marc]’s inspection revealed the problem: a broken pivot screw keeping the expansion and contraction of the aneroid diaphragms from transmitting force to the gear train that moves the needles. The repair was a little improvisational, with 0.5-mm steel balls used to stand in for the borked piece. It may not be flight ready, but it worked well enough to get the instrument back in action.
[Shahriar] of The Signal Path is back with another fascinating video teardown and analysis for your viewing pleasure. (Embedded below.) This time the target is an Agilent E5052A 7 GHz signal Source/Analyser which is an expensive piece of kit not many of us are fortunate enough to have on the bench. This particular unit is reported as faulty, with a signal power measurement that is completely off-the-rails wrong, which leads one to not trust anything the instrument reports.
After digging into the service manual of the related E5052B unit, [Shahriar] notes that the phase noise measurement part of the instrument is totally separate from the power measurement, only connected via some internal resistive power splitters, and this simplifies debugging a lot. But first, a short segue into that first measurement subsystem, because it’s really neat.
Cross-correlating time-gated FFT (TG-FFT) subsystem at the top, dodgy power detector at the bottom
A traditional swept-mode instrument works by mixing the input signal with a locally-sourced low-noise oscillator, which when low-pass filtered, is fed into a power meter or digitizer. This simply put, down-converts the signal to something easy to measure. It then presents power or noise as a function of the local oscillator (LO) frequency, giving us the spectral view we require. All good, but this scheme has a big flaw. The noise of the LO is essentially added to that of the signal, producing a spectral noise floor below which signals cannot be resolved.
The E5052 instrument uses a cunning cross-correlation technique enabling it to measure phase noise levels below that of its own internal signal source. The instrument houses an Oven-Compensated Crystal Oscillator (OCXO) for high stability, in fact, two from two different vendors, one for each LO, and mounted perpendicular to each other. The technique splits the input signal in half with a power splitter, then feeds both halves into identical (apart from the LOs) down-converters, the outputs of which are fed into a DSP via a pair of ADCs. Having identical input signals, but different LOs (with different phase noise spectra) turns the two signals from a correlated pair to an uncorrelated pair, with the effects of chassis vibration and gravity effects also rolled in.
The DSP subtracts the uncorrelated signal from the correlated signal, therefore removing the effect of the individual LO’s effect on the phase noise spectrum. This clever technique results in a phase noise spectrum below that of the LOs themselves, and a good representation of the input signal being measured.
This is what a DC-7GHz resistive power divider looks like. Notice the inductive matching section before each resistor branch.
Handily for [Shahriar] this complex subsystem is totally separate from the dodgy power measurement. This second system is much simpler, being fed with another copy of the input signal, via the main resistive power splitter. This second feed is then split again with a custom power divider, which upon visual inspection of the input SMA connector was clearly defective. It should not wobble. The root cause of the issue was a cold solder joint of a single SMA footprint, which worked loose over time. A little reflow and reassembly and the unit was fit for recalibration, and back into service.
If you’re willing to spend $200 USD on nothing more than 100 grams of plastic, there are a few trendy sunglasses brands that are ready to take your money before you have time to think twice. Sure, you can get a pair of sunglasses for an order of magnitude less money that do the exact same job, but the real value is in the brand stamped into the plastic and not necessarily the sunglasses themselves. Not so with this pair of Ray-Bans, though. Unlike most of their offerings, these contain a little bit more than a few bits of stylish plastic and [Becky Stern] is here to show us what’s hidden inside.
At first glance, the glasses don’t seem to be anything other than a normal pair of sunglasses, if a bit bulky But on closer inspection they hide a pair of cameras and a few other bits of electronics similar to the Google Glass, but much more subtle. The teardown demonstrates that these are not intended to be user-repairable devices, and might not be repairable at all, as even removing the hinges broke the flexible PCBs behind them. A rotary tool was needed to remove the circuit boards from the ear pieces, and a bench vice to remove the camera modules from the front frame. We can presume these glasses will not be put back together after this process.
Hidden away inside is a pair of cameras, a Snapdragon quad-core processor, capacitive touch sensors, an amplifier for a set of speakers. Mostly this is to support the recording of video and playback of audio, and not any sort of augmented reality system like Google Glass attempted to create. There are some concerning ties with Facebook associated with this product as well which will be a red flag for plenty of us around here, but besides the privacy issues, lack of repairability, and lack of features, we’d describe it as marginally less useful as an entry-level smartwatch. Of course, Google Glass had its own set of privacy-related issues too, which we saw some clever projects solve in unique ways.
There’s a problem with Opera. No, not that kind of opera. The Oracle kind. Oracle OPERA is a Property Management Solution (PMS) that is in use in a bunch of big-name hotels around the world. The PMS is the system that handles reservations and check-ins, talks to the phone system to put room extensions in the proper state, and generally runs the back-end of the property. It’s old code, and handles a bunch of tasks. And researchers at Assetnote found a serious vulnerability. CVE-2023-21932 is an arbitrary file upload issue, and rates at least a 7.2 CVSS.
It’s a tricky one, where the code does all the right things, but gets the steps out of order. Two parameters, jndiname and username are encrypted for transport, and the sanitization step happens before decryption. The username parameter receives no further sanitization, and is vulnerable to path traversal injection. There are two restrictions to exploitation. The string encryption has to be valid, and the request has to include a valid Java Naming and Directory Interface (JNDI) name. It looks like these are the issues leading Oracle to consider this flaw “difficult to exploit vulnerability allows high privileged attacker…”.
The only problem is that the encryption key is global and static. It was pretty straightforward to reverse engineer the encryption routine. And JDNI strings can be fetched anonymously from a trio of endpoints. This lead Assetnote to conclude that Oracle’s understanding of the flaw is faulty, and a much higher CVSS score is appropriate. Particularly with this Proof of Concept code, it is relatively straightforward to upload a web shell to an Opera system.
The one caveat there is that an attacker has to get network access to that install. These aren’t systems intended to be exposed to the internet, and my experience is that they are always on a dedicated network connection, not connected to the rest of the office network. Even the interconnect between the PMS and phone system is done via a serial connection, making this network flaw particularly hard to get to. Continue reading “This Week In Security: Oracle Opera, Passkeys, And AirTag RFC”→
Once upon a time, a radio controlled plane was a hefty and complex thing. They required small nitro engines, support equipment, and relatively heavy RC electronics. Times have changed since then, as this lightweight RC build from [Ravi Butani] demonstrates.
The body of the plane is lightweight foam, and can be assembled in two ways. There’s a relatively conventional layout, using a main wing, tailplane, and rudder, or a pusher model with the main wing at the rear and a canard up front. The open hardware electronics package, which [Ravi] calls VIMANA, consists of an ESP12 module with a pair of MOSFETs to act as two independent motor drivers — allowing the plane to be flown and steered with differential thrust.
For more advanced flight control, it can also command a pair of servos to control ailerons, a rudder, canards, or elevons, depending on configuration. There’s also potential to install an IMU to set the plane up with flight stabilization routines.
Thanks to the low-cost of the VIMANA board, [Ravi] hopes it can be used in STEM education programs. He notes that it’s not limited just to aircraft, and could be used for other motorized projects such as boats and cars. We’ve featured an early version of his work before, but the project has come a long way since then.
Long time readers will know that occasionally we mix up our usual subject matter with a dash of farm equipment. Usually the yellow and green variants that come from John Deere, as the agricultural manufacturer has become the poster child for all that is wrong in the fight for the right to repair. An old Deere is worth more than a nearly new one in many places, because for several years now their models have had all their parts locked down by DRM technologies such that only their own fitters can replace them. Now after a long legal fight involving many parties, the repair and parts company iFixit sound justifiably pleased as they announce the world’s first agricultural right to repair law being passed in the US state of Colorado. (Nitter)
This may sound like a small victory, and it will no doubt be followed by further rearguard actions from the industry as similar laws are tabled in other states. But in fact as we read it, with this law in place the game is de facto up for the tractor makers. Once they are required to release any access codes for the Coloradans those same codes will by extension be available to any other farmers, and though we’re guessing they won’t do this, they would be best advised to give up on the whole DRM idea and concentrate instead on making better tractors to fix their by-now-damaged brands.
It’s exciting news for everybody as it proves that right-to-repair legislation is possible, however since this applies only to agricultural machinery the battle is by no means over. Only when all machines and devices have the same protection can we truly be said to have achieved the right to repair.
