Posts in Electronics (20 found)
Jeff Geerling Yesterday

Formlabs dropped the Raspberry Pi on the way to a $699 SLA printer

Formlabs sent me a Form Studio 1 resin 3D printer to test after years of back-and-forth about their Form 4 printer. Like the Form 4, it's an SLA (stereolithography) printer, but unlike the Form 4 (which starts at $2,600), it's affordable for a hobbyist. It's not cheap , coming in at $699 (or $749 with a flex build platform, which I highly recommend), but it is affordable. I can't say as much about this printer as people who are well-versed in resin printing and use other SLA printers (all my experience until now is with FDM, or Fused Deposition Modeling 1 , printers). But I can convey my first-time experience using this printer and with the entire SLA experience.

0 views
Chris Coyier 2 days ago

Atomic Wall Clocks

Look at this clock . It’s a clock. I bought it once because I needed… a clock. It’s $29, which is totally reasonable for… a clock. Then it was Daylight Saving Time one day, and I went to update it, but… it was already updated. That’s because: The Atomic Time Feature conveniently allows the clock to sync with the WWVB radio transmission from Fort Collins, CO, for accurate time updates. That’s amazing? It listens to a radio signal and adjusts itself to the correct time, even during major time changes. What a kick-ass UX, while seemingly being no more expensive. Also: you can just put one battery in it to work, or you can put 2 batteries in it, and it’ll work longer, or 3 batteries, and it’ll last over 5 years. What the what. Now it just needs to dust itself, and it’ll be the greatest home device ever.

0 views

Some of the most powerful tools a dad can have…

…are a soldering iron and a hot glue gun. Seriously, nothing beats the feeling of handing your kid a previously broken toy that you fixed yourself. Tonight’s surgery involved a light up fan thing that had fallen, breaking the plastic shaft and pulling the wires out. Came out good as new after some glue and solder!

0 views
Jeff Geerling 6 days ago

Radxa's Q8B has 2x the performance and expansion of the Pi 5

There was a time I'd look at a board like the Radxa Dragon Q8B (at left, above) and be like, "there's no way I'd spend $209 on an SBC with 8 gigs of RAM". But we're in 2026, and seeing the 8 gig Raspberry Pi 5 going for almost the same amount, I figured I'd give it a shot. On paper , the Q8B beats the Pi 5 in pretty much every way. A lot of that is thanks to this Snapdragon 8cx Gen 3 chip, which is the same chip I tested on Microsoft's Windows Dev Kit 2023 .

0 views
Stratechery 1 weeks ago

Apple and LG, The House For Everyone Else, Agent Standards and Amazon

Apple is taking a smarter approach to the home than I expected, leaning into integration (with partners); then, what Amazon should do about agents.

0 views
Blargh 1 weeks ago

UniBalun dipole setup

Until now, my HF antennas have mostly been off the shelf. I’ve gone out with an AlexLoop (hmm, alexloop.com seems to be down. I don’t know if that’s permanent), and the Elecraft AX1 . They’ve both been fine, but have some drawbacks. The AX1 is a bit finicky about getting its radial(s) good enough, and the AlexLoop is a bit tricky to set up in a temporary but stable way. I have not have good experience with the half wave G5RV, yet, for some reason. So since all HF antennas are compromises, why not try an inverted V dipole? I had the UniBalun recommended to me, so I went with that. There are some minor things to think about, which is what this blog post is about. To become an antenna, I also needed antenna wire , and a way to put the middle of the dipole high up, with the antenna wire extending straight diagonally down. For a 20m (14MHz) antenna, I cut two 5.2m pieces, expecting to need to either cut or fold them back a bit, for the right resonance. On the UniBalun side I could just crimp an M4 ring to attach the antenna wire, but on the other end of the wire I needed to be more creative. It needed to be able to attach to paracord, and also be fairly easily adjustable in how much should fold back. Even if I were to cut it, I’d probably still want it folded back a bit, to adjust for anything from exact band location to moisture in the ground. I ended up using a butt splice crimp, without crimping it, as a kind of zipper to create the attachment loop. I then used a ziptie to make sure the fold is along the main wire as much as possible. I think an improvement here would be to use a second butt splice crimp instead of the ziptie, and glue the folded tip to it. That way it can move and be adjustable, and also straight. If wind starts moving it, there’s always gaffa tape. I had an extendable window washing pole, so that sorted height. I added a guying collar to secure it with paracord, though a hitch knot appeared to be stable enough too, and is more flexible about how high up you want the guying wire. The guying collar is the same diameter as the pole. Which means while I got it on, it ain’t never coming off. I probably should have bought a slightly bigger guying collar, and secured it with a shelf of tape below it. But it works. My bike’s wheel held the base in place. My antenna analyzer has bluetooth. I thought I’d check that out, to prevent me going back and forth too much. But the Android app is not compatible with the current Android release. And the Linux app didn’t seem to work either. So I told AI to build one: After a few more minor user improvement prompts, I ended up with something pretty usable . Here’s two example sweeps from my testing today: It saves everything from the session, so I can inspect the return loss and other graphs after the fact, too. I’m treating this tool as any official tool I find online; I didn’t look at the code at all. I would not have spent the time to actually build this manually. I would have given up and only used the rigexpert directly. Well, I did use it directly, too. It went well. The UniBalun is rated for 5W in data modes, so that’s what I ran. Not bad at all. Unreasonably effective , in fact. I also dialled in to my BBS over the mercury HF modem . This is my checklist for going out and playing radio. I don’t bring everything, only what I’ll need on the day. But I do go through the list every time because it’s easy to forget something. UniBalun — £9 100m lightweight antenna wire (just over 10m used) — £14 Guying collar — £3 Paracord — less than £1 worth used 2x M4 crimps 2x (or 4x) AWG 16-40 butt splice crimp Tent stakes — £13 USB hub (my Elecraft requires two USB ports to get audio and CAT), and one of my two USB-A ports has a yubikey nano in it. HF radio CAT cable External battery Baofeng + AIOC (convenient modem) Coffee thermos Picnic blanket Set home station frequency & power (if dialing in back home) Headphone cable Arrow antenna AX1 antenna Antenna stand (for AX1 or AlexLoop) Dipole pole Camping stakes Paper towels Lighter (for sealing paracord after cutting)

0 views
Julia Evans 2 weeks ago

Replacing the old battery on rechargeable bike lights

Hello! Recently I needed bike lights for my bike. And I remembered that I already had rechargeable bike lights that I bought ten years ago, that I hadn’t tried in a long time. I tried to recharge them, but after fully charging them, they only worked for maybe 5 minutes before they turned off again. I don’t know much about electronics, but I’ve been curious about whether it’s possible to fix old electronics for a long time, and this seemed like the perfect repair project because I might just need to replace the battery. So I went to the local queer makerspace where I’m a member to use the soldering iron and try to do it! I don’t know much about electronics and this post does not contain any safety advice because I don’t know much about safety. I think it’s nice to do projects in a community space where you can get help. The bike light felt like it was made of silicone, so I cut open the silicone in a haphazard way along something that vaguely looked like a seam. I definitely ripped some silicone in the process and it was pretty messy but I got it open and found the circuit board. I don’t know the model number of the bike lights but there’s a photo of them at the end of the post. There were some screws attaching things together so I removed them so I could get the circuit board out. Mostly I tried to remove as few screws as possible because I was worried about losing them or not being able to put them back after. I probably put the screws in a bag or something. I took out the circuit board. Here’s what it looked like: You can see where the battery is attached, I think it’s left of RI3 and above Q2. Here’s what the battery looked like: I’d never desoldered anything before, so I found the iFixit guide to desoldering and read it. Also I asked my friends Lee and Lauria for advice. Here were the steps I ended up following based on the guide & the advice I got: In the picture of the battery in Step 3, you can see it says something like “3” and “LI???77”. There’s a piece of metal that I think is welded or something to the top of the battery. It seemed impossible and also maybe not smart to try to remove so I wasn’t sure how to find out what an “LI????77” was or how to order another one. I’ve been trying to avoid using LLMs (though I will not get into that because I am exhausted by LLM discourse and I’m sure you are too), but I really had no idea how to figure out what the battery was so I asked an LLM. It gave the response “LIR2477”, which (when I looked it up) looked exactly the same as my battery so I figured that was plausible. I would be interested to learn non-LLM ways to figure this out though. There must be a way. Lauria showed me how to use DigiKey’s search which was very cool though DigiKey didn’t have that part. (edit: someone in the replies told me that this kind of coin cell battery is named according to its dimensions, and you can use plastic calipers to measure the dimensions of the battery. So I guess a non-LLM way would be to measure the battery with calipers and try to match it to something on the List of battery sizes Wikipedia page, though that page only mentions CR 2477 and not LIR 2477. It’s a good example of what’s fun for me about trying to avoid LLMs, this “List of battery sizes” page is super interesting and if I use an LLM I might never find it) I went to AliExpress and ordered: I think the batteries were $3 each and the glue was $8. The parts took maybe 2 weeks to arive, and once they arrived, I went back to the makerspace and: Then after waiting some amount of time for the glue to dry I took it home and waited 24 hours for the glue to cure. Also I took the old batteries to somewhere nearby that accepts old batteries. The lights work! I have used them to bike at night! I still haven’t needed to recharge them (and tragically I had to order a new Mini USB cable because I got rid of all my Mini USB cables, so I’m still waiting for that), so I still don’t know for sure how long the lifetime of the new battery will be. Here’s what the light looks like after re-gluing. You can see that I didn’t glue very carefully. It didn’t really go back together that well but I’m hoping it’ll be good enough. I thought it was really cool that I was able to do this with extremely minimal electronics skills! It cost about $20 CAD to buy the parts, and (whether or not the repair holds up, I’ll try to update this post in the future!), it was fun to try to repair something and learn something new. Use a desoldering pump to remove most of the solder Once most of it is gone, kind of pull them apart to try to separate them Also try to avoid getting the battery too hot in the process by taking breaks to let it cool down. I’m not very good with a soldering iron so it took a while. The battery has an attachment that is welded to the top. For a while I thought I needed to remove this and it seemed impossible, but it turned out the replacement battery comes with that part so actually I was supposed to leave it alone. 2 batteries (I had 2 bike lights and I wanted to fix them both) some silicone glue to glue things back together soldered in the new batteries put the screws back in. The screws were very small and hard to hold, so at this point I dropped some screws on the ground and couldn’t find them because they were too small. So I just used fewer screws and hoped for the best. used the glue to try to put everything back together. Make a somewhat halfhearted attempt to clamp the parts I was gluing together

0 views
マリウス 3 weeks ago

NuPhy Kick75

If you’ve been around the mechanical keyboard scene for a while, NuPhy’s name has probably come up at some point, most likely attached to one of their Air series low-profile boards. Over the past few years they’ve put out keyboards that look better than they have any right to at their price point, with a sound and feel that punches above their weight class and without the pretentiousness that usually comes with enthusiast hardware. The Kick75 is one of their more interesting releases so far, because it’s a hybrid-profile board. It is one PCB and one chassis that take two different switch and keycap ecosystems, using a relatively inexpensive swap kit. This is not the kind of board I’d normally gravitate towards, as my collection is more on the enthusiast side of the hobby, with a RAMA M60-A as my HHKB endgame, a RAMA KARA as its wingman, and the “Kunai” Corne V3 as my ergonomic daily driver. The 75% layout has never quite, erm, clicked for me. :-) Still, the Kick75 is interesting enough that I’ve spent a fair amount of time with it. This is a write-up on my thoughts and opinions on the NuPhy. I’ll admit that when I first saw the board in person at the NuPhy showroom in Seoul I was skeptical. The mechanical keyboard hobby has seen its fair share of exotic ideas and plenty of them exist to solve a problem that nobody really had. Unlike the Air series, which is purely low-profile, or the Halo and Field series, which are standard height, the Kick75 is meant to be both. My question was whether that flexibility works in practice, or whether the result is a compromise that is worse than either option by itself. The hybrid mode is achieved by unifying the pin layout and the stabilizer geometry across NuPhy’s nano (low-profile) and Max (high-profile) switch families. Both are 5-pin, both fit the same plate cutouts, and both work with the same stabilizers, which is a non-trivial engineering exercise. NuPhy markets the two families as sharing a unified 3.5mm travel, but as we can see from the individual spec sheets the reality is not as clear-cut. Only the Red nano and Brown nano are at 3.5mm, the Silver nano and the Red Max, Brown Max and Silver Max are at 3.4mm, the Blush nano is at 3.2mm, and the silent Blush Max is at 3.8mm. However, none of those differences are likely to be noticed by the target audience while typing. Both lines come in the same four variants, where Red is the plain linear at 45g operating force, Brown the tactile at 50g, Silver the speed switch with its pre-travel cut from 1.8mm down to 1.2mm, and Blush the silent version, which uses a silicone insert in the stem instead of pads on the housing. The nano switches are made almost entirely out of POM, with the silent Blush as the exception with a PC top and a PA66 bottom. The Max switches keep the POM top housing but move to PA66 at the bottom, with LY stems on the Red and Brown, a Y3 stem on the Silver, and POM on the Blush. Whichever profile you pick, the board uses the same PCB and the same PCB gasket mount, so the case contributes the same way acoustically in both setups. What makes the tonal difference are the switches and the keycap profile. The board that I got to test came with the default NuPhyIO firmware. NuPhy call the aesthetic of the Kick75 the 8-Bit Odyssey theme, which means a translucent frosted polycarbonate chassis, a faint cartridge-style groove on the underside, four-color accents on a handful of the keys, and a bright red volume knob that looks like it came off a piece of late-80s hardware. There’s some pixel art on the bottom plate as well. The board looks sort of retro and you either like that or you don’t. I personally like the aesthetics. The Kick75 is entirely made of plastic, with the top case, the bottom case, and the plate being all PC. For a board between $109 and $129 that’s neither surprising nor unreasonable, but it does set some expectations. This is not a RAMA (R.I.P.) or Mode, nor is it even a mid-tier aluminum 75% that you can get for around the same money these days. What you’re paying for is the engineering behind the hybrid concept and the sound dampening that goes with it, but definitely not the material. Before this turns into an it’s just plastic dismissal, the RAMA KARA in my own collection is also a plastic board, and with the internal dampener and a decent switch choice it thoccs a lot harder than you’d normally expect an ABS case to. Chassis material matters less than what is done with it, and, to be fair, NuPhy seem to have put a fair amount of work into that part. The dampening is pretty elaborate, with five layers inside the case, namely plate foam, a switch pad, a sound damper, PCB foam, and bottom case foam. The result is a soft, cushioned bottom-out with a bit of bounce to it. The translucent PC case diffuses the south-facing RGB evenly through the chassis. The stock PBT caps are not shine-through, so the light comes out around the keys rather than through the legends. However, the milky diffusion of the PC helps the board avoid the trashy harsh Christmas-tree look that a lot of consumer-tier keyboards normally have. If you care about RGB at all, then you might find that this is a decent implementation. The magnetic kick-out feet give two angles, 6° and 12°, and they hold with enough force that they don’t feel flimsy. The volume knob, depending on your taste, is either the most interesting detail on the keyboard or the most too-much one. It’s bright red, it’s relatively big, and it is set into a recessed corner of the case. I personally think it works quite well, but it obviously adds a lot of playfulness to the overall aesthetics that some might not find particularly appealing. The Kick75 is comfortable to type on for extended periods. The gasket mount takes the edge off the bottom-out without turning the keystroke mushy, and on the low-profile side the 3.5mm travel is noticeably more than you get on most laptop-class keyboards. On the high-profile side the 3.4mm is shorter than the usual 4.0mm, which makes the Max configuration feel a touch snappier than your average gasket-mounted 75%. The tactile Brown switches have a 50g operating force and a 65g bottom-out, which is on the lighter end of modern tactiles, and the bump is gentle without being mushy. The linear Red switches are more predictable at 45g and roughly 60g, while the Silvers are the lightest of the four and actuate 0.6mm earlier. The Blush switches are the silent option, and the silicone in the stem does a good enough job that you can still tell where you are in the stroke. Wobble is in line with what you’d expect from a modern hot-swap implementation. There’s a touch of stem play in either direction, more visible on the Max switches because of their taller stems, but nothing that disrupts normal typing. The stabilizers are plate-mounted and factory-lubed, with no audible rattle out of the box. Acoustically the Kick75 has a decent, thoccy , creamy sound profile, especially on the low-profile side. The double-shot PBT keycaps, nSA on the low-profile and mSA on the high, are chalky-textured and relatively thick. They’re not the deepest-sounding caps I’ve typed on, but they avoid the cheap, hollow clacking of thinner ABS sets. To set some reference points against my own collection, the M60-A is at the deep, heavy, dense end of the spectrum, the KARA is premium-feeling-despite-being-plastic thanks to the internal dampener and the screw-in stabilizers, and the Kunai is clacky-and-busy compared to those, and obviously has a lot less depth than the others. The Kick75 doesn’t get anywhere near the M60-A’s density, and I doubt that anything at this price would, but it ends up somewhere between the KARA’s and the Kunai’s character. For a $109 factory-built board with a polycarbonate chassis that’s not at all a bad result. If you’re thinking “Cool, I can swap between profiles whenever I feel like!” then you might be in for a bit of a disappointment, because switching between the low- and the high-profile is not quick. It’s a full disassembly that takes around an hour if you’ve taken keyboards apart before. You need to unscrew the case, lift the assembly out, swap the plate foam and the switch pad, move the stabilizer buckles over to the other profile, and reseat the gaskets. Then you pull every single switch, install the switches of the other profile, and put all the keycaps back on. Only then can you close everything back up with the other top case and, going from low to high, fit the knob extension. The $29.95 conversion kit covers the top case, the plate foam, the switch pad, the knob extension, and it comes with a screwdriver with the two bits you need. It however does not come with the switches or the keycaps for the other profile, which you have to buy separately. Hence I would argue that for most people the Kick75 is a one-way trip. Once you’ve set it up as either low- or high-profile, swapping to the other profile is enough of a chore that you won’t, unless you genuinely enjoy disassembling the same keyboard over and over. If you do want to switch back and forth regularly, you’re probably better off buying two units, because the kit plus a second set of switches and keycaps gets you pretty much to the price of a second board anyway. I have strong opinions on the low-profile side, as I own the Corne V3 (Choc) variant of my primary keyboard and I do not enjoy typing on it at all . Flat, low-travel keycaps remind me too much of the MacBook keyboard, which I’ve avoided for years. The nSA profile on the Kick75, however, is sculpted and not flat, and the 3.5mm travel on the nano switches is at least 0.5mm more than the Choc ecosystem gives you at 3.0mm. Still, I personally dislike lo-pros with a passion. NuPhy ships the Kick75 in two SKUs. The default $109.95 version runs their proprietary NuPhyIO firmware, configured through a web-based tool that covers remapping, macros, and RGB without the need to install anything locally on your computer. It’s pleasant enough to use, however it talks to the keyboard over WebHID, so it only works in Chromium-based browsers. Firefox and Safari don’t implement the API yet. The $129.95 SKU replaces NuPhyIO with QMK and VIA support, which is the route I’d have taken if I had actually ordered one for myself. Charging $20 extra for QMK/VIA, when it comes free on nearly every other enthusiast-class board on the market, is a weird move from NuPhy here. If you want a solid entry-level board that’s as affordable as possible, the NuPhyIO version is fine, I guess, but in all other cases I’d definitely recommend going for the QMK/VIA one instead. The Kick75 has USB-C, Bluetooth 5.0 for up to four paired devices, and 2.4 GHz through a small dongle that stores magnetically under the case. Wired and 2.4 GHz both run at 1000 Hz, while Bluetooth caps out at 125 Hz, which is fine for typing and acceptable for anything short of competitive gaming. NuPhy rates the 2500 mAh cell at up to 360 hours with the backlight off and roughly 90 hours with it on. I had the board for too short a time to verify either number, so I can’t really speak on whether the Kick75 achieves those. As a hybrid-profile keyboard the Kick75 is an interesting engineering piece that however doesn’t deliver on the casual-swap promise its marketing implies. As a 75% gasket-mounted mechanical keyboard at $109 to $129, however, it’s a good buy, with a sound profile well above its price bracket, a retro aesthetic that I happen to like, and more dampening inside than the price bracket normally gets you. If you’re shopping for your first enthusiast keyboard and you want to keep your options open between low- and high-profile, the Kick75 is a good place to start. If you’re an established enthusiast with a shelf of aluminum boards, a settled layout, and existing investments in keycaps and switches, it isn’t aimed at you and you’ll get more out of a single-profile board built around what you already have. For me personally, the Kick75 is not a board I’d permanently add to my collection , but it’s one I’d recommend to someone curious about the hobby who isn’t ready to spend $500+ on a single-purpose enthusiast build. It does most things well, but the profile swap, which is the entire reason the board exists, is the one thing that it sort of fails to deliver. Note: Unlike most of my other keyboard write-ups this isn’t a long-term hands-on review. The board was borrowed for a limited time and I don’t own it. Take this as a first impression, and use it as a starting point for your own research. Your mileage may vary based on switch choice, build configuration, and what you’re coming from and/or expecting.

0 views
Blargh 3 weeks ago

The magic of OFDM

I’ve been playing a bit with OFDM in software defined radio lately. And after watching a video that wasn’t even close to correct , I thought I’d write down my understanding in a blog post. I wouldn’t call myself an expert, so worst case someone will correct me, and I’m happy to be corrected. In my experiments with OFDM my initial goal is understanding, so e.g. I won’t blindly use some hierarchical GNU Radio block. I think that in order to internalize OFDM, we first need to remind ourselves how a purely “real” wave becomes a complex number, at a high level. The real signal is a value that’s a function of time. Glossing over details, this not feasible for most of our signals, as we would need to provide a new value to the transmitter at a rate twice as high as the highest frequency we care about. For 2.4GHz experiments, we’d need 4.8 billion samples per second. Quadrature sampling allows us to represent a slice of bandwidth at a managable rate. We can then provide the I/Q data to hardware, instructing it to hold that “until further notice”. If we provide one sample per second, for example, we can change the phase or amplitude of a pure sine wave (the carrier) once a second. Between our samples, it continues as-is in that phase and amplitude. “As-is” is here left deliberately vague. I only phrase it this way because it’s a helpful analogy further down. Now some background on QPSK , since that’s the encoding in the subcarriers in my OFDM experiments. This should apply equally to QAM , QAM being a generalization that allows more bits per symbol. At first glance QPSK seems simple. Symbols become . But you can’t really transmit that kind of instant transition without infinite bandwidth. An individual symbol instead gets turned into a “pulse” towards its coordinate. A pulse will spread out, but the pulse shape is designed such that it should have minimal effect where it matters; at the peak of neighboring pulses (symbols). So if the receiver samples at exactly the right point, it’ll get a perfect symbol with no inter-symbol interference. Of course that’s only strictly true in theory (because of multipath and various nonlinearities). But minimizing the symbol interference helps. Turning symbols into pulses is called pulse shaping . GNURadio has a nice guide to QPSK . The explanation of OFDM still makes me feel like it shouldn’t work. It’s too weird of a tool to use. It feels like cheating. The idea is that instead of having one high symbol rate with as many constellation points (and therefore bits per symbol) as you can, you instead split your data into multiple slower carriers of narrower bandwidth. How would you generate all these smaller slower signals? Well, you could create many virtual transmitters and add them up into one spectrum. That’s one way to turn many constellation diagrams (series of complex numbers) into one signal. Then on the receiver side you’d do one band pass filter and translation to baseband per carrier. You know what else takes a complex time domain signal and gives you a set of discrete complex numbers, one per frequency? An FFT. So you just stuff QPSK symbols into (e.g.) 64 FFT bins, and do an inverse FFT? Well, almost (see below). But the fact that the answer is “yes almost!” is what’s magic. This is the thing that blew my mind. A receiver can then just do a 64 bin FFT, and there you have the I and Q for your 64 subcarriers. This means that both transmitter and receiver will process the incoming I/Q in chunks. Chunks that are the size of the FFT. Ok, so “OFDM symbol” doesn’t make so much sense. I mean the collection of symbols being sent at any given point in time across all subcarriers. An OFDM “aggregate symbol” is several input symbols, distributed into the FFT bins / subcarriers. Transmitting turns these sets of symbols into I found it useful to think of OFDM in the time domain within a single “FFT chunk”. The original I/Q samples had a start time and an end time. Between the start time and the end time, the true analog signal was a mix of (for example) 64 fixed tones. The individual tones had a particular individual phase and amplitude. Here’s an example of a four subcarrier OFDM, for three symbol periods: And this is where the “hold this until further notice” analogy is relevant. It doesn’t matter how many cycles a given subcarrier goes through. It just matters for a given subcarrier, what amplitude and phase it was. And yes, this is the same thing as having four independent transmitters. But because the “transmitters” are just the output of an inverse FFT, they are exactly synchronized. We generated this four transmitters by cheating! Taking the illustration above literally, we should not transmit that exactly. The phase and amplitude transitions are too sharp. An input symbol is only part of one FFT, and for the next FFT period we have another input symbol for that FFT bin. So how should we soften that up? Should we pulse shape the subcarrier QPSK before it goes into the inverse FFT? No, because then that means each symbol takes multiple FFT chunks, slowing down the transmission. Do we pulse shape the whole FFT chunk? No, these aren’t pulses but instead multiple frequencies; there isn’t really a “pulse” to shape. Fixing this involves windowed OFDM/WOLA, smoothing out the FFT period transitions, and I’ve not looked into it yet. OFDM is good in the presence of multipath for two reasons: Whereas QPSK needs to lock on based on peaks in the signal, and can therefore easily lock in on small frequency differences between transmitter and receiver, OFDM doesn’t have the same luxury. The pulses are inside the subcarriers, and you can’t extract the subcarriers until you have the frequency. This is usually solved by sacrificing some subcarriers to pilot signals. In my testing I made the center bin a pure sine wave, and used a feedback loop to perform a primitive frequency lock based on quadrature demod. Any residual frequency error will result in cross-subcarrier interference, and frequency offset (quadrature rotation) inside the subcarrier. You can also use a Jacobsen CFO estimator to estimate the frequency error from the pilot signal FFT bin. My GNURadio flowgraph uses that only for diagnostic, not for tuning feedback. On the plus side, because the subcarrier is merely the values of the FFT, if the outer carrier is synchronized, then the inner is too, and you can just pluck the QPSK symbols directly after Symbol Sync, without a Costas loop or other subcarrier frequency lock. In my example graph, the default frequency locking is coarse, trading stability for speed of convergence, and the clocked symbols (under “Clocked”) shows this instability as a subcarrier frequency offset, correctable with a Costas loop. If I change the to a lower value, it becomes stable: (yes, that’s an animation. It’s just very frequency locked) In a better implementation, frequency locking should probably switch to fine locking automatically when the signal is found. While my GNURadio experiment does add the Cyclic Prefix, and removes it, it does not yet actually attempt any timing synchronization. This means that the start and end of an “FFT chunk” can be wrong. I think this is a likely main cause of why it’s very sensitive to other subcarriers being assigned noise: I think this timing synchronization may be best done by having the pilot signal do… something. Maybe the (or one of) the pilot signal should be BPSK triggered by FFT chunk transition? This is how my OFDM test looks over the (virtual) air. A pilot in the middle, silent bins around it, a slow (each symbol repeats 10 times) signal in FFT bin / subcarrier 5, and the rest of the carriers full of noise. This blog post was written when the github repo with my flowgraph was at commit 1e8fbd79d465cf94f6407f4677375ac088158619. The symbols are slow, and the speed of light is fast. The slower a symbol is sent, the less the chance a bounced signal from a different symbol has to interfere. OFDM also encourages adding a “Cyclic Prefix”. Basically extending the transmitted “OFDM chunk” and discarding the initial part, under the assumption that it could be polluted with multipath echoes of the previous symbols.

0 views
Chris Coyier 4 weeks ago

The Avocadinator

I think I bought this thing at some grocery store endcap or something. The magic is that it can do all three advocotasks: Amazing! All in one! My review: I actually kinda like it. I do reach for it when I have this job. But I’ve shown it to several people who have almost viscerally bad reactions. Like, they can’t explain it; they are just: nope. I literally handed it to someone who was about to undertake the job of slicing avocado, and they were like  no thanks, got my knife here. The downsides are: Cut avocado in half (little knife thing) Take out the pit (little indent with teeth thing) Cut avocado halves into slices (grate thing) The avocado has gotta be pretty ripe for it to work nicely (which it should be anyway if you’re about to take on this task). The device is immediately filthy and much harder to clean than a knife/spoon. It just has to go in the dishwasher immediately.

0 views
Jim Nielsen 1 months ago

Don’t Let Anyone Take Away Your Big Box of Cables

Speaking of being on the internet and finding things that make you go, “Hey! It’s not just me!” I scrolled across this skeet from Tyler Gaw : I just dug to the bottom of my Big Box of Cables to find two cables that I needed for something. They've been in the bottom for 10+ years. So, "when are you ever gonna use these?" was today. Don't ever let anyone take your Big Box of Cables away. I laughed. I cried. I felt inspired. So inspired, in fact, that I decided I was gonna do something about it. Something that would make me forever remember the value of that advice. Now every time I pull that box out to add YAC (yet another cable), instead of asking myself, “Why do I keep this box?” I’ll see that skeet and I’ll be reminded why I do what I do. I’ll feel a spark of joy, motivation, and purpose rekindled. (Not to mention the fact that it will serve as a warning to anyone in the family who thinks “I should just throw this away…”) One day my kids will find that box in the attic amongst my other belongings. I hope they will pay heed to the timeless advice lovingly taped on the outside. Reply via: Email · Mastodon · Bluesky I screenshotted that skeet. I printed it (in black and white with the ole’ trusty Brother). I cut it out. I pulled out my big box of cables (the one my wife lovingly labeled “FAMILY TECHNO BOX”). I cut some clear packing tape. And I plastered that thing on the front on my box.

0 views
Jeff Geerling 1 months ago

Rebuilding a 1995 GPS Time Server so I don't get Telstra'd

In June I purchased this TrueTime XL-AK time server , so I could learn more of the history of GPS-based time. I received it on June 22, and just 16 days later a similar GPS time server took down Australia's cell service for 12 hours ! I made a short video about it but put off digging into the TrueTime... until now. Over the past couple weeks, I've 'restomodded' this device with a Raspberry Pi, to build a stratum 1 NTP Time server, which I'd like to eventually add to the NTP Pool . I found a way to drop in a Pi 5 and GNSS HAT, display the time and GPS status on the built-in 16x2 LCD, show the status on the bicolor LED, and make this box useful again.

0 views
Dangling Pointers 1 months ago

Analysis of Area and Power Overhead for a Synthesizable 4-Phase Bundled-Data Asynchronous RISC-V Processor

Analysis of Area and Power Overhead for a Synthesizable 4-Phase Bundled-Data Asynchronous RISC-V Processor Sean Jacobs, Mark Indovina, and Yashaswini Suresha GLVLSI'26 This paper describes the design of an asynchronous (i.e., there is no clock signal) RISC-V processor. The power and area results are impressive. I’ve only vaguely understood how asynchronous designs operate; this paper helped me understand the space a bit better. As far as I understand, there are two primary advantages of asynchronous circuits: Performance is not limited by infrequently used critical path. Power savings due to not having a clock signal #2 can be mitigated in synchronous designs with the use of clock gating. Inter-pipeline stage communication in this processor uses a 4-phase protocol. This protocol is illustrated in Fig. 2: Source: https://dl.acm.org/doi/10.1145/3787109.3815227 The 4 phases of the protocol are: The request signal transitions from low to high, indicating that all upstream stage outputs are ready to be consumed The acknowledge signal transitions from low to high, indicating that all upstream stage outputs have been consumed by the downstream stage The request signal transitions from high to low The acknowledge signal transitions from high to low The key building block that makes the 4-phase protocol implementable is the Muller C-element. A C-element has two inputs ( and ) and one output ( ). The output remains steady until both inputs are equal, at which point the output value is assigned to be equal to the first input (i.e., ). Fig. 3 illustrates how Muller C-elements and inverters can be used to construct a pipeline that uses the 4-phase protocol: Source: https://dl.acm.org/doi/10.1145/3787109.3815227 The triangles with circles on the input side are active-low inverters. Here is a narrative of how this works. Assume that the bottom ( ) input of the leftmost C-element is 0, the top ( ) input is 1, and the output ( ) is 0. When the input Req signal transitions to 1, it will cause the output of the leftmost C-element to transition to 1. This will send an acknowledgment backward to the unpictured upstream stage and send a request to the downstream (middle C-element) stage. The middle C-element will perform similarly (responding with an acknowledgment and propagating the request down the pipeline). When is set to 1, is set to 0, which will cause the left-most C-element output to return to zero when the unpictured upstream stage sets Req=0. The control path described above can be extended to support an arbitrary feed-forward pipeline as illustrated in Fig. 4: Source: https://dl.acm.org/doi/10.1145/3787109.3815227 The storage elements (pipeline registers) are D-latches (no clock inputs). The combinational logic clouds represent the logic that implements each stage of a RISC-V processor. The delay elements connected to each Muller C-element ensure that the control path does not assert the request signal until after the combinational logic has finished its job. An EDA tool is used to compute the worst possible delay through a logic cloud, and the corresponding delay value is set to be at least that long. The astute reader will realize that the delay elements eliminate one of the primary advantages of using an asynchronous design: the delays are set equal to the worst possible delay (i.e., the critical path). The advantage of this approach is that there is no area overhead added to the combinational logic. It is essentially the same logic that would exist in a synchronous design. Table 1 compares area and power numbers for this asynchronous processor (28nm, 4-stage) against a synchronous processor. Area is essentially unchanged; power is significantly lower. I’m not sure how much clock gating there is in the baseline implementation. Source: https://dl.acm.org/doi/10.1145/3787109.3815227 Dangling Pointers The performance numbers above should be taken with a grain of salt. As far as I can tell, the authors only tested the processor in simulation, they did not fabricate a chip in real life. The Muller C-elements are described with synthesizable RTL, not standard cells. Thanks for reading Dangling Pointers! Subscribe for free to receive new posts. Performance is not limited by infrequently used critical path. Power savings due to not having a clock signal The request signal transitions from low to high, indicating that all upstream stage outputs are ready to be consumed The acknowledge signal transitions from low to high, indicating that all upstream stage outputs have been consumed by the downstream stage The request signal transitions from high to low The acknowledge signal transitions from high to low

0 views
Brain Baking 1 months ago

Bring Back The Noise With HDD Synth

The modernisation of some of the vintage components in old computers comes with its own set of challenges. Things break: thirty plus year old hard drives stop spinning, floppy drive components such as a simple elastic rubber to get mechanical things moving disintegrate, and of course plenty of capacitors leak. Sometimes, things break up to the point that I sometimes wonder whether being a retro hardware enthusiast is worth it at all. The solution to these problems is simple and not so simple: de-solder the component from the board and look for a replacement, and throw out that rubber or the drive entirely to find modern replacements such as the SD-to-IDE interface I use to emulate a HDD. Fixed—now the old motherboard still thinks it’s speaking to a genuine vintage hard drive! Not fixed? The distinctive mark of a humming disk is gone: an SD card has little to say except for crack when you jump on it. The true retro enthusiast—the real appreciator of smelly electronic components that go beep —will want to hear that beep . Not just a beep , but a bzzzzzkkrrrttttt tzk tzk tzk BEEP : your classic spin-up sound when these mechanical drives start spinning. Thankfully, some retro enthusiasts are prepared to do more than just accept the fact that the noise is gone. Some go as far as building their own expansion card that fully emulates the sound of yore. This is the story of my friend Peter Bridger’s HDD Synth . Peter was kind enough to send me two prototypes to play with 1 ; his third revision (Mark III) of the idea, as pictured below, currently in the state of an ISA card. The HDD Synth Mark III, with a 3D-printed bracket screwed on. The first thing I thought when I heard the idea was: how is this going to work if your sound card’s drivers are loaded only after the bootup procedure? Peter’s design makes use of another speaker mounted on the card, separate from your sound card or built-in PC Speaker. It leverages the Raspberry Pico to output sampled sound directly to the custom speaker by listening to the ISA port for HDD activity. Earlier models used the HDD LED in pins on the board to detect activity. As I type this, Peter is working on Mark V to reduce the footprint of the card, including getting rid of the requirement of an ISA slot to enable putting this inside older non-IBM PCs as well. One of the coolest aspects of the HDD Synth is its ability to load custom samples as well. The SD card slot is there to hold both firmware & configuration as well as custom sound samples. This allows the card to emulate any kind of vintage hard disk drive, playing just the right sound for you to evoke that instant jolt of nostalgia. Just add four files in a subdir inside : (the rattling when the HDD used to be busy), (power off), (power on), and (general background noise). The configuration file looks to be fairly straightforward: Here, a subdir —in my case a preset one matching my memories quite well—exists on the SD card where the samples live.The only problem I so far encountered was powering off the computer that too quickly discharges all energy resulting in being cut off halfway through. Even though the HDD Synth is still in beta phase, Peter put in a lot of effort to create an experience: the commissioned stickers remind me of the Game Boy’s Play It Loud campaign and the instruction manual was modelled after the original Sound Blaster manuals, detailing every pin and suggesting troubleshooting tips. As the sticker portraying a PC fan emitting a MHDDLA sound states: I’m A Big Fan ! Get it, fan? No? I thought that was a good one. The HDD Synth manual inspired by the original Sound Blaster manuals. The peripheral card currently claims an ISA slot, but as stated, in future versions the card will shrink and the need for a slot will disappear. Apparently, Peter received the request to build something similar that will fit inside a MacBook. Bring Back The Noise, stupid silent MacBook Air I’m typing this on! I’ll be very curious to see how this will pan out. The card’s hardware (and software) design is fully open-sourced so if you’re a capable electronics expert you can order all the components and solder them on yourself. Thank you Peter for letting me try out one of the prototypes. I feel very honoured to be mentioned in the special thanks print on the back of the PCB. Please keep an eye on Peter’s site Strife Streams for more retro goodness and HDD Synth updates. I now own two cards thanks to the Belgian Post and customs service. There is little need in plugging in two HDD Synths in one machine. Or is there? If anyone is interested in checking out the project, let me know and I’ll send you one!  ↩︎ Related topics: / pc hardware / soundblaster / By Wouter Groeneveld on 1 September 2026.  Reply via email . I now own two cards thanks to the Belgian Post and customs service. There is little need in plugging in two HDD Synths in one machine. Or is there? If anyone is interested in checking out the project, let me know and I’ll send you one!  ↩︎

0 views
マリウス 1 months ago

Flipper BUSY Bar

Yes, it is in fact real, I’m holding it in my hands, and after what feels like years of Flipper teasing everyone with this ominous device in various online posts, I can finally confirm that it is real. The BUSY Bar is a 250 gram desk device by Flipper Devices , the company behind the Flipper Zero and the still very much in-development Flipper One . It’s basically a little display that shows various things on a 72x16 RGB LED matrix, and as of writing this it’s main selling point is that can run a Pomodoro-style focus timer , and that it has a ful-blown HTTP API that’s available over USB, over the local network and over the internet, that let’s you control this thing. The BUSY Bar has a five-position selector on the top, that switches between the two focus modes ( BUSY and CUSTOM , which are functionally identical and only differ in their defaults), a OFF position that in reality is more of a sleep mode which turns both screens off, an apps position that currently only holds a clock, and a settings position for, well, the settings. A large mechanical button in the middle starts and pauses a session, a scroll wheel adjusts the timer and doubles as an OK button, and last but not least there’s a back button for when you have to navigate back. Speaking of back, the backside of the device has a 1.54 inch monochrome OLED that shows the timer, the battery percentage and the Wi-Fi, Bluetooth and USB indicators. This way the device remains usable to its own user as well, even when clipped to the top edge of a monitor using its built-in mount, pointing its primary matrix display away from its user. The device measures 168.6 x 55.2 x 40.8mm and weighs 250g/8.82oz. The body is made out of PC/ABS with a PC front and back panel, and the monitor mount padding is TPE. The bar fits monitors up to 21mm thick and I can confirm that it works on curved displays as well. However, if you have a particularly thin monitor (say, one of these portable displays) it won’t be able to sit on top of it. The full specifications, as published in Flipper’s own documentation , are as follows: The 72x16 matrix is driven by the ICND2153 , a 16-channel constant-current PWM sink driver with a 16-bit grayscale shift register, LED open detection and a pre-charge circuit for ghosting reduction, and the ICN2012 8-channel power switch. One thing that is a bit sad in 2026 is the 2.4 GHz limitation for Wi-Fi. In an office environment full of devices and microwaves the bar is on the most congested spectrum available. The USB side is also kept, let’s say lightweight , with its 12 Mbit/s maximum speed, which, however, is certainly enough for a virtual ethernet interface serving a web UI and an HTTP API. On the charging side the documentation asks for an 18 W or higher PD charger for the 2.5 hour figure, while the device itself only appears to use 5V⎓3A (15 W) and 9V⎓1.5A (13.5 W) as its PD modes. There is one discrepancy with regard to the display brightness, where the tech specs page lists no brightness figure at all, the product page currently says 400 nits, and the launch coverage from CNX Software and XDA both quote 800 nits. I don’t have the equipment to measure it, so I can’t really tell which it is, but I can assure you that even in a brightly lit space it’s plenty bright. Flipper published an official disassembly guide on iFixit , which is awesome. Its 21 steps describe a device that’s designed with repairability in mind. The back cover is held by 8 clips and comes off with a plastic card. Below it are 5 Phillips PH1 screws, one on the bottom and four on the back. The battery has a press-latch connector and needs to be disconnected before anything else. The display flex cables use spudger-release latches, the main PCB is held by 3 screws, the control PCB by 5 latches, the front display back cover by 6 latches and the button stabilizer by 3 screws. The monitor mount legs are friction fits. Nothing is glued and the battery is a standard 18650 cell on a 4-pin connector, which means a replacement is easily and cheaply available from most electronics shops. For a 2026 consumer device this is probably something that my fellow Right to Repair advocates will love. The firmware sources are on GitHub as . Most first-party code is GPL, the library is MIT, graphical assets are CC-BY 4.0 and fonts are OFL 1.1, all of which are declared in a REUSE manifest. The build system is FBT , the same SCons-based Flipper Build Tool used for the Flipper Zero , and the dependency list is a usual embedded stack with FreeRTOS underneath Flipper’s own abstraction, lwIP for TCP/IP, TinyUSB for the USB device side, Mongoose as the embedded HTTP and WebSocket server, mbedTLS for TLS and LVGL for the UI. The bar also includes JerryScript in , wired up through and a service. That is the same JavaScript engine the Flipper Zero uses for its scripting apps. With the engine already in the firmware the only thing that still seems missing is the documented way to load your own scripts onto the device. The BUSY Bar runs an HTTP server and speaks the same API over three transports, documented as OpenAPI 3.1 . Plugging the device into a computer over USB brings up a virtual ethernet interface with the device at a fixed , printed on the back of the unit. is the local web interface, is the API reference generated by the firmware currently on the device, and is the base URL for said API. No authentication is used over USB, but it can be used via Wi-Fi and it must be used when going through Flipper’s cloud. This request responds with the current power status. The battery current is in mA, and both battery and USB voltage are in mV, which means that you can graph the device’s own power consumption without any extra hardware. Note: Access over Wi-Fi is disabled by default and has to be turned on from the local web interface over USB first. Once enabled, you can pick a token for authentication, which would go into an header, if you decide to set one: Access over the internet goes through Flipper’s cloud with a bearer token generated at , scoped either to a single device or to the account: Flipper maintains for Python with both a synchronous and an client. It maps method names onto API paths directly, so becomes and becomes . That makes the OpenAPI document usable as the library’s reference documentation: The library also has a module that scales and re-encodes images and audio for the device, an mDNS discovery helper for , and a firmware compatibility check. On top of that there is an official TypeScript library for all the soydevs, and a community-maintained .NET client . And there is also a Zig library, but… more on that in just a moment . :-) The BUSY Bar presents itself to Matter as a single on/off endpoint, an emulated switch with a configurable startup state of , , or . Turning it on starts the BUSY timer and turning it off ends it, making the integration is a trigger. Reporting the state back to Matter requires switching on Settings ➔ Smart home , at which point focus sessions can power automations like dimming lights or locking a door when a timer is turned on. Pairing is done using a QR code on the back screen or in the web interface, and the device can be commissioned into multiple fabrics at once. The Home Assistant integration is done through the HTTP API using the generic REST facilities, which works in both directions, meaning the device as an automation trigger, and the device as an output for anything else in the house. The BUSY Bar comes with mobile apps for your smartphones. I have tested its iOS app and, well, it was okay, I guess. I’m not a huge smartphone app user to begin with, but I’ll give my two cents here. The app basically mirrors the current state of the bar and offers rudimentary control over it. When you start a timer and you have the app set up (via Flipper’s cloud) you’ll see the app pushing a permanent notification that displays the timer on your smartphone’s lock screen. It’s also possible to configure a Do not Disturb mode that prevents other apps from interrupting your focus session whenever a timer is currently running. To me these are gimmicks, but to others these features might be worth something. Having that said, the apps aren’t rated particularly highly and while I didn’t encounter any issues during the few days that I’ve tested the iOS version, the app did leave a somewhat cheap impression by the way it looks and functions. It felt like one of these apps that corporate boomers at large hardware manufacturers would come up with, falsely believing that they are in-line with what today’s generations might want. There are a few things that bother me, however none of them are actual dealbreakers. The Wi-Fi authentication is a single shared numeric key, constrained by the API schema to , sent in a plain header over unencrypted HTTP on the local network. At the four digit minimum that is a 10,000 value keyspace, and I have found no documentation of rate limiting. The access mode enum also includes an value alongside , which means that the API can be opened on the LAN with no key at all. Hence, it’s probably a good idea to use a ten digit key and keep the device off networks you don’t control. Then there’s all the coming soon . Installing user apps, the JS SDK, the Windows application, and the expanded app library, those are all future promises. I don’t doubt the Flipper team that they will eventually arrive, but I could imagine that for a non-technical user it is probably very frustrating to have bought a device that can barely do anything at all at the moment, especially on a Windows machine. The device that arrives today is a focus timer, a clock, and a status display. Lastly, the price. It launched at USD 179 for waiting list members, then USD 199 for the first 3,000 units, with USD 249 quoted as the eventual retail price. At 249 it is a very hard sell, especially in the current software state. If you’re buying this because you’re a technical user and you really want to fiddle with it, it might be worth the Pesos, but as I’ve demonstrated in the past you can build a similar device significantly cheaper yourself, especially if you’re already deep into the tinkering rabbit hole. Flipper built the device I would have expected them to build, which I mean as a sincere compliment. The hardware is over-engineered for a status light in the same way that Flipper hardware always seems to be, with a real mechanical switch, a real encoder, a replaceable 18650, an official teardown guide and no glue anywhere in it. Whether it is worth the money depends entirely on what you intend to do with it. As a device that tells your coworkers to go away, it is way too expensive and not at all effective, because people who interrupt you are not deterred by a sign that tells them not to. Let me put it this way: For roughly $50 below the BUSY Bar ’s retail price you could place one of several Smith and Wesson models on your desk and it would likely be a more effective way to deter co-workers from talking to you. However, as a small, well-built, fully scriptable RGB matrix with an 8 GB filesystem, a WebSocket, and an elaborate priority system, so that several programs can share one screen without overwriting each other, it is the most open and probably best thing in its class, and I expect the community will find uses for it that Flipper hasn’t thought of yet. PS: Turning off the BUSY bar is like quitting Vim, in the sense that it doesn’t offer an obvious way to do so. Yes, the switch on top has an “OFF” position. However, that simply turns off the displays, but it keeps the busy bar running and connected to WiFi. If you want to fully shut down the device so that it won’t consume any battery, you will have to put the switch into the “Settings” position, navigate to System , Power , and Shutdown , and confirm the poweroff with Yes . Only then the device actually turns off. As mentioned before, I have a little bonus that I’d like to share with this review, which is a Zig library that implements the BUSY Bar ’s current OpenAPI specification as closely as possible, and that brings a command line tool that lets you control the device over its HTTP API. The library supports all of Zig’s platform targets as it only uses Zig’s library, and it is fairly lightweight and easy to use. I’m using it with my BUSY Bar and it has been working great for me. The command line tool contains a few quality-of-life features like simple commands for starting and stopping the busy mode, which would otherwise require manually writing JSON payloads. Long story short, if you’re one of the people that have ordered the BUSY Bar and are maybe looking to integrate it into Zig tools, or even just into your desktop environment using your own scripts, I invite you to check out the repository . If you’d only want the CLI tool to play around with your BUSY Bar you can find builds for every supported platform over on the release page on GitHub .

0 views
Jeff Geerling 1 months ago

Hands-on with Raspberry Pi's CM5 Programming Jig

In the before-times, when Raspberry Pi CM5s were (relatively) affordable, I built a number of Pi clusters ( example ), and one of the most annoying parts of the build was flashing Raspberry Pi OS to all the Pis. One, two, or even three Pis isn't a big deal, but once you hit 4+, the process of plugging the Compute Module into a carrier board, plugging that into a computer, managing Raspberry Pi Imager, and trying to match up details like a hostname, MAC address, and the physical Pi itself, gets annoying.

0 views
マリウス 2 months ago

Recovering BIOS Firmware on the Star Labs StarBook

As I described in my latest quarterly update , a perfectly routine firmware update managed to turn my Star Labs StarBook Mk VI (AMD) into an expensive paperweight. I had simply copy-pasted the one-liner from Star Labs ' official documentation , the script did its thing for about half a minute, shut the device down, and from that point on the StarBook refused to boot. Black screen, keyboard backlight on, the power LED lit, and the speakers occasionally producing a clacking sound. Sadly no amount of the usual turn-it-off-and-on-again rituals or battery disconnects brought it back. The only way out of this situation is to re-flash the BIOS chip externally using an SPI programmer. Star Labs do document this , however their guide assumes you’re using their programming kit together with a dedicated debug board and an FPC cable. That kit is significantly more expensive than a generic programmer, doesn’t list any make or model information, and, at the time of writing, has been permanently out of stock on their web shop. Not exactly helpful when you’re stranded somewhere with a dead laptop that happens to be the only computer you have with you. The good news is that you don’t need any of that, at least for this specific model of the StarBook . As Star Labs ’ own Sean pointed out in the GitHub issue I opened while debugging this mess, this specific StarBook uses a SOIC-8 flash chip, which means you can recover it with a cheap, generic CH341A programmer and an ordinary SPI clip, as long as you respect its voltage. Warning: Flashing a BIOS chip externally can permanently destroy your device if you do it wrong. The flash chip on the AMD StarBook runs at 1.8V and you must use a 1.8V adapter. Driving it at the CH341A ’s default 3.3V risks damaging the chip, and won’t read it correctly anyway. Everything below is what worked for me, documented to the best of my knowledge, but you’re doing this entirely at your own risk. The flash chip on my StarBook Mk VI (AMD) , which I could read off the silicon once I had the backplate off, is a Winbond 25R128JWSQ , a SPI NOR flash in a SOIC-8 package. The suffix on Winbond parts apparently denotes the 1.8V variants. The ubiquitous, three-dollar CH341A “black” programmers that you’ll find on AliExpress , Amazon , and pretty much everywhere else operate their SPI lines at 3.3V (and the parallel header at 5V). Clamp one of those directly onto a 1.8V chip and, best case, reads garbage. Worst case, however, you cook the flash or something downstream of it. The fix is a small 1.8V adapter board (essentially a level shifter with a voltage regulator) that sits between the CH341A and your SOIC-8 clip. These are sold as kits, e.g. the KOOBOOK CH341A Programmer + 1.8V Adapter combo that Sean linked in the issue. Make sure whatever you buy explicitly mentions 1.8V. You will need a CH341A programmer with a 1.8V SOIC-8 adapter, a SOIC-8 test clip (the spring-loaded “Pomona-style” clips, or the cheaper ribbon-cable variety, both work), a second computer running Linux (can be via a live medium, e.g. a USB stick) to drive the programmer from, e.g. a department store laptop and a Fedora live USB will do, if you’re eloquent enough to explain to the staff that you’re definitely not building what almost certainly looks to them like a bomb. You will also need the correct firmware image for your model (more on that below), a small Phillips screwdriver and, ideally, a plastic spudger. Power everything off and unplug the charger before you start. Flip the laptop over and remove the backplate by undoing the two long Phillips screws in the top corners first, and then the eight shorter screws around the edges. Lift the plate off carefully. Then, remove the five screws holding the battery in place (one of the screw positions is intentionally left empty) and gently unplug the battery connector. Last but not least, locate the SOIC-8 flash chip on the mainboard. It’s the little eight-legged Winbond chip described above. Note: While I had the StarBook open, I noticed that my (barely two year old) battery had started to visibly bulge, so do take a moment to inspect yours. A swollen lithium battery is a fire hazard and should be replaced. SOIC-8 flash chips have a defined pin 1, and the clip’s pin 1 (usually the wire on the red edge of the ribbon) has to line up with it. Get the orientation wrong and the chip simply won’t show up. For reference, the pinout of the Winbond SOIC-8 flash is: You don’t have to wire any of this up by hand, though, as the clip and the 1.8V adapter carry all eight lines for you. The only thing you need to get right is aligning pin 1 of the clip with pin 1 of the chip. Note: On my chip there is a gray dot painted onto the package, on the corner opposite to pin 1. Pin 1 is instead marked by the small indented (etched) dot, on the exact opposite side from the painted one. I have no idea why the gray dot is there, but if you align to it you’ll have the clip on backwards. Look for the indentation, not for the gray spot if yours has one too. With the clip attached, plug the CH341A into your second machine. A quick look at should confirm it enumerated: Install if you haven’t already: Before writing anything, make sure can actually talk to the flash over your clip: If everything is seated correctly, will identify the Winbond chip (detected as something like ). If instead you get: …then don’t panic. In my experience this is almost always poor clip contact rather than a real problem. I had to wiggle and reseat the clamp a few times before the chip showed up reliably, because those cheap clips are fiddly. Only proceed once the chip is detected consistently across a couple of runs. Even if the firmware is bricked, it’s good practice to take a backup before you overwrite anything. Read the chip twice and compare the dumps to be sure your contact is solid: If the two reads differ, your clip contact is flaky and you should reseat it and try again. As for the firmware image, Star Labs publish their firmware in a public GitHub repository . For external programming you want a full SPI image, not the EFI/ updater files. For my StarBook Mk VI (AMD) (product SKU ) that’s the image. The full-image files also live under the model’s directory . Pick the one that matches your model and rename it to something convenient, e.g. . Note: Star Labs ’ firmware versioning is, to put it mildly, a mess. As of writing, the last AMI (the original “BIOS”) release for the AMD StarBook is , while onwards is Coreboot . Whichever you decide to flash, just make sure it’s a full image for your exact model. Last but not least, write the downloaded image using the command: By default will erase, write, and then verify the chip. Star Labs ' official command appends (i.e. and ) to skip those verification passes, but I’d recommend leaving them off so confirms the write actually stuck. Either way, do not disconnect or disturb the programmer while it’s working. Once it finishes successfully, remove the clip, reconnect the battery, screw the backplate back on, and try to boot. When I powered mine back on, the StarBook came to life again, only to stop at a screen complaining about a missing boot entry, since flashing a fresh image also wipes the EFI boot variables. That’s nothing dramatic and you just need to point the firmware back at your bootloader. You can either use the boot menu and pick your SSD, which usually re-adds the boot entry, or boot a recovery/live system and run (this is what I did), or drop into the EFI shell and launch your bootloader manually: Note: On newer Coreboot releases Star Labs are enabling Rom Armor and anti-rollback. On the AMD board external flashing and downgrading still worked for me on , but this is expected to be locked down from onwards. What frustrates me most about this whole ordeal isn’t that a firmware update can go wrong, because that’s always a risk when you flash something. It’s that Star Labs ’ documented recovery path depends on a proprietary kit that nobody can actually buy, when a generic CH341A with a 1.8V adapter seemingly does the job just fine. However, this info is nowhere to be found in Star Labs ’ official documentation, which is why I decided to publish this write-up to begin with. Hopefully it spares the next person the day (and the stress) it cost me.

0 views
Stratechery 2 months ago

Apple Earnings, More on Amazon’s Earnings

Apple's earnings (and stock) are limited not by memory but rather chip shortages; then, more on Amazon's earnings and Andy Jassy's market analysis.

0 views
マリウス 2 months ago

GL.iNet Mudi 7

tl;dr: After almost seven years my Netgear Nighthawk M2 has started rebooting on its own, reporting nonsensical battery percentages and ignoring most of my presses on its touch buttons, so I spent the past three months replacing it with the GL.iNet Mudi 7 ( GL-E5800 ), a 5G NR Sub-6 travel router with two nano-SIM slots plus an onboard eSIM, Wi-Fi 7, a 2.5 GbE port, two USB-C ports and a removable 5380 mAh battery. It is the most capable mobile router I have owned, its 13.5-hour battery rating is close to what I measure, and the LTE reception alone is a clear upgrade over the M2 . Sadly the Tri-band on the box means two bands at a time, there is no MLO at all, both SIM trays are underneath the battery, the touchscreen still can’t get you through a captive portal, and firmware 4.8.5 has a cellular defect that leaves the device on Connecting… after a carrier deactivates an idle data session. If you came to the Mudi line for blue-merle and IMEI randomization, you might be disappointed to learn that this sadly seems to have ended with the GL-E750 . Earlier this year I reviewed the GL.iNet Slate 7 ( GL-BE3600 ), the Wi-Fi 7 travel router that replaced my long-running Linksys WRT3200 ACM as the router in my travel setup . I mentioned in that post that I was also in the process of replacing my even older Netgear Nighthawk M2 , the LTE-A Cat. 20 hotspot that has handled my mobile data for almost seven years now. The M2 has been a reliable piece of equipment, however, it has started misbehaving so badly that I no longer trust on the road. Random reboots, increasingly nonsensical battery percentages, and touch buttons that no longer register most presses make it a tedious device to use, and with it well past any expectation of longevity, I figured it was time to give its successor a proper, multi-month trial before the M2 gives up entirely in the middle of some airport lounge. The device I settled on is the GL.iNet Mudi 7 ( GL-E5800 ), a 5G NR Sub-6 Tri-band Wi-Fi 7 travel router that GL.iNet unveiled at CES 2026 and started shipping back in April. On paper the device is an upgrade over both the Netgear M2 and the Mudi V2 aka GL-E750V2 , which was still a 4G/LTE Cat. 6 device with a 0.96" OLED. The Mudi 7 packs Qualcomm ’s Dragonwing MBB Gen 3 platform, a Wi-Fi 7 PHY with a 6 GHz radio, two nano-SIM slots plus an onboard eSIM, two USB-C ports, a 2.5 GbE Ethernet port, a 2.8" color touchscreen, and a removable 5380 mAh battery, all in a 157x75x22.8mm, 300g enclosure that runs OpenWrt with GL.iNet ’s firmware layer on top. At $419.99, or roughly €425, it is also the most expensive device GL.iNet sells. Just like the Slate 7 , the Mudi 7 is above most consumer travel routers. It comes with a 5G NR Sub-6 Rel-17 NSA/SA modem with LTE Cat. 20 (DL) / Cat. 18 (UL) fallback, and the exact specifications of the hardware are as follows: Apart from having a modem, the second difference from the Slate 7 is the 6 GHz radio, which the Slate 7 lacks entirely. However, the Tri-band on the box is a bit misleading. The Mudi 7 has radios for all three bands, but the chipset cannot drive 5 GHz and 6 GHz simultaneously, so you configure the device as either 2.4 + 5 GHz or 2.4 + 6 GHz. This also means the Mudi 7 has no Multi-Link Operation at all. On the Slate 7 I complained that GL.iNet ’s MLO documentation advertises a 6 GHz band that the hardware doesn’t have. On the Mudi 7 the 6 GHz band is present and MLO is gone, which is an odd trade for a device that costs nearly three times as much. There are two regional variants, GL-E5800NA for North America and GL-E5800EU for Europe, with different 5G NR and LTE band coverage, which is important to travelers like myself. Both variants cover n5, n7, n26, n38, n41, n77 and n78. Beyond that they diverge, as the EU model adds n1, n3, n8, n20, n28, n40 and n75, while the NA model adds n2, n12, n14, n25, n30, n48, n66 and n71, plus n13, n29 and n70 in SA mode only. LTE splits the same way, with the EU model on FDD B1, B3, B5, B7, B8, B20, B28 and B32 and TDD B38, B40, B41, B42 and B43, and the NA model on FDD B2, B4, B5, B7, B12, B13, B14, B17, B25, B26, B29, B30, B66 and B71 and TDD B38, B41, B42, B43 and B48. For my use case (almost exclusively APAC/LATAM) the EU variant turned out to be the more sensible choice, but anyone moving frequently between North America and the rest of the world should read both band lists carefully before ordering. To be fair, though, the Nighthawk M2 splits even harder. Netgear ships that device as at least five separate SKUs, and the band list for each one is quite short. The box itself contains the Mudi 7 , the battery pack, a relatively big travel pouch, a USB-C cable, and the paper manual. No external antennas and no power adapter, which I appreciate, given the chargers I already lug around. The headline feature is the modem, which uses the Dragonwing platform, Qualcomm ’s rebranded enterprise and mobile-broadband lineup. In practice the 4.67 Gbps peak figure is, as with virtually all hyped peak numbers, marketing material. Real-world throughput depends primarily on the carrier’s network, the SIM plan, the spectrum allocation, the band combination, and the signal conditions at your specific location. In my own testing I have seen sustained downlink figures in the 600–900 Mbps range on a properly-provisioned 5G network, and significantly less (in the 100–250 Mbps range) on a more typical mixed NSA deployment. What’s more important, though, is the LTE fallback. The modem falls back to LTE Cat. 20 (DL) / Cat. 18 (UL) and is significantly more sensitive than the M2 ’s aging Qualcomm baseband. In the same hotel rooms where my M2 used to show a single LTE bar at best, the Mudi 7 can consistently show two or three, often pulling more usable bandwidth on the same SIM and the same carrier. Lastly, the Mudi 7 has two TS-9 external antenna ports for those of us who care to bolt on a pair of paddle or directional antennas in RV/cabin/dead-zone scenarios. I haven’t bothered to test these, as my use case doesn’t involve any of that. However, these days most people might have almost exclusively converted to Starlink anyway, so the external antennas might not be as much of a selling point as they were ten years ago. The Mudi 7 has two Nano-SIM slots and one onboard eSIM. Both Nano-SIMs and the eSIM are managed via the touchscreen and the web UI. However, it’s important to note that the Dual SIM Dual Standby in this context means dual standby with an asterisk. The onboard eSIM and SIM slot 2 are mutually exclusive and cannot be active at the same time. The eSIM is disabled by default, and the moment you enable it, SIM 2 stops functioning. SIM 1 remains operational either way, and the modem can auto-switch (i.e. fail over) between SIM 1 and whichever of SIM 2 / eSIM is currently active, but you do not get to keep three simultaneously hot profiles. For anyone hoping to keep a local SIM, a regional roaming eSIM, and a home-country SIM in standby together, this is a bit of a disappointment. Failover itself has also been more rigid than I expected. The web UI exposes the auto-switch feature, including data-usage thresholds and signal-loss triggers, but the failover decision-making has been slow in practice. A complete loss of signal usually does cause a switchover within a reasonable amount of time, but more nuanced situations (such as one SIM throttling without any indication, or losing data while still showing connected ) often require a manual nudge. GL.iNet ’s documentation describes far more sophisticated multi-WAN coordination than the SIM-side auto-switch logic delivers. Then again, to be fair, Mwan3 on the Linksys has had similar issues and I guess down detection is just a complicated thing to get right. One caveat is that both Nano-SIM trays are underneath the battery , so putting a card in or taking one out means having the device powered down, prying off the back cover, and pulling the battery out. On a product aimed at people who buy a local SIM on arrival, that is a weird design. Then again, in many cases the device is probably already powered off because you arrived by airplane anyway. Switching between profiles that are already provisioned (either physical-to-physical or physical-to-eSIM) is one of the things the touchscreen handles well, and it doesn’t normally require any detours into the admin UI. Speaking of which, just like the Slate 7 , the Mudi 7 comes with a built-in touch display, though here it is a 2.8" color LCD rather than the much smaller panel on the Slate 7 . The screen shows the usual variety of things, like signal strength and current network type, connected client count, real-time data usage, battery percentage, Wi-Fi details with a QR code for quick joining, and the ability to toggle the VPN, the Wi-Fi, and a couple of other features without opening the admin UI. Firmware upgrades also display a progress bar on the screen, which (as I had complained about with the Linksys ) is a small but welcome quality-of-life feature. The notable thing missing from the touchscreen is captive portal handling. The moment the upstream WAN is a hotel or airport Wi-Fi network with a captive portal in the middle, the touchscreen is useless and you have to reach for a phone, tablet, or laptop, attach to the Mudi 7 , open a browser, and go through the portal manually before the router (and everything behind it) can reach the internet. But to be fair, a 2.8" panel is probably a poor place to render an HTML login form and a keyboard to begin with. The lockscreen with a 4-digit PIN that was introduced on the Slate 7 is also present on the Mudi 7 , which I once again appreciate, given the kind of sensitive information (carrier and SIM details, VPN state, hostnames) that this screen displays. One annoying quirk is the battery percentage reporting. Both the LCD and the web UI will, after a full charge, stay at 100% for the first 1–3 hours of unplugged operation before catching up to reality and dropping rapidly to whatever the actual state of charge is. The underlying kernel fuel-gauge driver does report accurate values (you can confirm this via SSH and ), but from what I can see the MCU layer that drives the LCD and the admin UI applies some smoothing to avoid the device displaying 98–99% immediately after charging. I would much rather see the truth on the screen than a smoothed consumer-friendly approximation, especially on a device whose entire purpose is to be unplugged for long stretches. The Mudi 7 shipped with OpenWrt 23.05.4 ( , Kernel ), with GL.iNet ’s firmware layer on top. The device runs Qualcomm ’s proprietary SDK and binary blobs. The same software-openness caveats that apply to the Slate 7 apply here as well. You get full root SSH access, the configuration tree, and the ability to side-load the LuCI UI if you want, but you’re stuck with GL.iNet ’s firmware for anything that touches the cellular or Wi-Fi 7 silicon. The original Mudi ( GL-E750 ) is the device that blue-merle was written for, the SRLabs package that changes the IMEI via AT commands on the device’s modem, wipes the stored client MAC addresses, and randomizes the BSSID and the WAN MAC address across reboots, and it is a large part of why the Mudi line got its reputation as the privacy-focused travel router in the first place. However, blue-merle supports the GL-E750 and nothing else, and with the 5G modem, the firmware base, and the entire platform having changed underneath it, there is no indication that this is going to change. If IMEI randomization is the reason you were looking at a Mudi specifically, the Mudi 7 does not give you that, at least today. To be fair, the firmware layer is also what makes the device usable out of the box. The Multi-WAN , WireGuard , OpenVPN , Tailscale , AdGuard Home , DNScrypt-proxy2 , Tor , and the modem management features are all preinstalled and reachable via a friendly web UI, which (as I had mentioned in the Slate 7 review) is a substantial step up over the bare vanilla OpenWrt experience on an older router like my WRT3200 ACM . The Mudi 7 supports WireGuard with up to 600 Mbps. I have been running my own WireGuard tunnel on the device, routing the entire LAN through it, and it has kept up with whatever the upstream 5G or LTE connection could deliver. As with the Slate 7 , Tailscale is available, with the same caveats. Basic connectivity works, but anything beyond the default configuration (exit nodes with advanced flags, subnet routing, tagged ACLs, etc.) is going to require manual intervention via SSH. The Mudi 7 can, like the Slate 7 , run a Tor node and route LAN traffic over it. The moment Tor is enabled, VPNs , DNS , AdGuard Home and IPv6 will not work properly anymore, because the firmware doesn’t (yet) compose these services the way a hand-rolled OpenWrt setup can. Note: As I had explained in the Slate 7 review , these limitations are 100% a GL.iNet issue and not caused by OpenWrt . The same combinations work fine if you wire them up by hand on top of a vanilla OpenWrt installation, including DNS lookups via Tor through DNScrypt-proxy2 . The UI just isn’t there yet on the GL.iNet side. AdGuard Home is, as on the Slate 7 , part of the default installation and just as plug-’n-play. I still don’t use it personally, but the web UI is identical to the one on the Slate 7 and works fine in the configurations I have tested. The Mudi 7 differentiates itself from most travel routers in the number of uplinks it can hold at once, as the device supports up to five concurrent WAN inputs: The cellular modem, the 2.5 GbE Ethernet port (when configured as WAN), Wi-Fi-as-WAN (i.e. repeater mode), USB-C tethering from a phone or a secondary modem, and USB-C-attached USB Ethernet adapters. The firmware uses Multi-WAN underneath, with a friendly UI on top. Router, access point and extender modes are all supported, WDS is not. The device features dual USB-C, with one of the USB-C ports being power-only. The other USB-C port is a fully-featured 10 Gbps port with USB tethering, and USB OTG support. It’s possible to charge the Mudi 7 on one port while simultaneously tethering on the other. USB tethering itself, just like on the Slate 7 , is a matter of a few clicks in the UI. Plug a phone in, enable tethering on the phone, and the Mudi 7 picks it up as a USB Ethernet WAN. The same applies to a USB-to-Ethernet adapter, should you ever need to add a second wired WAN or to bridge into a hotel’s wired LAN where Wi-Fi is unreliable. I have had the Mudi 7 for roughly three months now, and the tl;dr is that the device is pretty solid overall, with a handful of caveats around firmware quirks and the chunkier footprint. Battery life is a bit of a mixed bag here, because it depends a lot on what features/services are running on the Mudi 7 , on the amount of WiFi clients and how cellular coverage is. Let me therefore put it this way: For the amount of features you get with the Mudi , especially compared to my older M2 , the battery life is decent. Having that said, however, I do believe that the Nighthawk , at least in its earlier days, was able to survive longer on a single charge than the Mudi is able to right now. Obviously I don’t have scientific benchmarks to prove it, but I remember vividly being out and about with the M2 for a full day and going to bed with the device only around halfway drained. This is something that I don’t think is possible with the GL.iNet . While the device easily gets through a regular workday, I probably wouldn’t trust it to survive a full day road trip with four friends through a mountainous region. Ultimately, its battery life can be extended using an external powerbank, but that’s clearly not ideal with a device that already weighs 300g on its own. If we’re being honest here, 300g equals about two Google Pixel 5 or two Motorola Edge 30 phones, which can both provide you with a 5G hotspot and which will probably (combined) outlast the Mudi by at least a few hours. So if the pure 5G hotspotting capability is all you care about, the GL.iNet is definitely not a good option with regard to battery life. If, however, you’re looking at it as the centerpiece of your mobile LAN, that will allow you to leave your Slate 7 at home because it supports pretty much every important feature and offers integrated 5G connectivity on top of that, then its battery life isn’t too bad after all. The chassis warms up noticeably under sustained 5G load (especially with a VPN), but never to the point where I’d be concerned about throttling or comfort. The back gets warm to the touch, but no warmer than a mid-range phone under similar load, and certainly not as warm as my old M2 would get at times. Unlike with the Netgear , I haven’t experienced any heat warnings with the Mudi so far. The build quality is solid. The chassis has a reassuring density to it, the touchscreen is responsive, and the front button doesn’t feel flimsy. The back panel is a bit of a weak point, because it is a plastic snap-fit cover protecting the battery and it creaks under pressure. Given that this cover has to be pried off to swap the battery or a SIM, I’m half-expecting it to wear out relatively quickly. Weight and footprint, as I had anticipated in the travel desk write-up , are clearly worse than the M2 ’s. The Mudi 7 is heavier (300g vs the M2 ’s 240g) and noticeably chunkier in both length and width. In absolute terms this is still a small device, but on a packed desk and in a packed bag, the difference is noticeable. The included travel pouch is also larger than the router needs, because most of the extra volume is set aside for accessories. Most people probably won’t use the travel pouch for travel, but rather for storage at home. Charging behavior has been predictable. The 24W PD fast-charging input gets the 5380 mAh battery from 0% to ~80% in roughly an hour, and to full in about an hour and 45 minutes. The device accepts whatever USB-C PD source there is around, including my UGREEN 100W and the Sharge Pouch Mini P2 power bank. If you’re considering this device as a permanent member (or even a centerpiece) of your LAN, I have some good news for you: The Mudi 7 can be operated via USB-C, without its battery plugged in. I don’t know whether this is officially supported by GL.iNet , because when you connect a charger the display will show a battery icon with an exclamation mark inside of it, but long-pressing the front button will turn the device on nevertheless. I haven’t experienced any peaks in power-consumption that would lead to arbitrary restarts without the battery plugged-in, but your mileage may vary. Reliability has been pretty good, and I haven’t experienced any crashes, random reboots, or other issues. The only firmware-level oddities I have encountered are the battery reporting discussed above and the cellular issue in firmware 4.8.5 mentioned in the tl;dr : After a carrier deactivates an idle data session, the router can remain on Connecting… until I intervene. The Mudi 7 is probably one of the most capable travel-friendly mobile routers I have ever owned, and it has a permanent place in my travel setup . The 5G modem, the dual-SIM-plus-eSIM configuration, the dual USB-C ports, the 2.5 GbE port, the removable 5380 mAh battery, and the Wi-Fi 7 PHY can replace the M2 + Slate 7 combo for me, while also covering scenarios (5G, multi-SIM, multi-WAN, USB-C-tethered secondary modems) that the combo never could. While the 300g weight and the bulkier footprint are a step back compared to the M2 , if I account for the added size and weight of the Slate 7 that I had to lug around alongside the M2 to make the LAN work for me, then it doesn’t look as bad anymore. Then again, with the M2 + Slate 7 combo I had the flexibility to only bring what’s really needed, which, for e.g. a day trip, would end up being only the M2 . Apart from that, there is the Tri-band situation, with the chipset only driving two bands at once and offering no MLO at all, the SIM-failover logic, which doesn’t work as smoothly as one would expect, the SIM 2 vs eSIM mutual-exclusion, that is mildly annoying, and the battery percentage smoothing, that makes me distrust everything else the device reports. However, none of these are deal-breakers but more like minor inconveniences. The proprietary Qualcomm blob situation is the more concerning part for me, and as with the Slate 7 , the Mudi 7 is OpenWrt only in spirit , and its long-term wireless and cellular stack support depends entirely on GL.iNet and Qualcomm continuing to cooperate. If your priority is true software freedom, this device, like virtually every other 5G-capable router on the market today, is not for you. Neither is it for you if you bought into the Mudi name for blue-merle and IMEI randomization. If your priority is a modern, travel-ready, multi-WAN, multi-SIM 5G router with a solid (if proprietary) firmware on top, the Mudi 7 is, at the time of writing, the best option I’m aware of. I will be sticking with the Mudi 7 as my mobile-data device for the foreseeable future, and the Nighthawk M2 has been retired to the bottom of a drawer after seven years of service. PS: Make sure to check future updates if you’re interested in the long-term experience with the Mudi 7 .

0 views
Daniel Mangum 2 months ago

The Simple Elegance of the Integrated Timing Belt Loopback Fastener

I’ve recently been working on a mechatronics project that involves constructing an X-Y cartesian motion system. I opted to use stepper motors to drive each axis, and timing belts and pulleys for translating the rotational torque of the steppers into linear motion. The timing belts need to be anchored to the component that is being actuated, which in this case is the carriage on the linear rails. Though matching toothed clamps exist, it is common, particularly in DIY projects, for timing belts to be fastened using zip ties or custom clips.

0 views