Posts in Hardware (20 found)
Daniel Mangum 2 days ago

JLink JTAG Access on the Pinecil

It has been more than two years since I bought a Pinecil soldering iron and wrote about soldering the breakout board and accessing the UART. I’ve been doing more work with the Pinecil as of late following the addition of upstream support for the Bouffalo Lab BL706 MCU in Zephyr (big shout out to @VynDragon, @will-tm, @josuah, and everyone else who has been contributing to the upstream Bouffalo Lab efforts!).

0 views
Jeff Geerling 3 days ago

It's hard to justify buying a Framework 12

My nephew just graduated high school, and wants a laptop. When he decides what computer to buy, price (or more precisely, value ) is the most important attribute. Apple's MacBook Neo upended the 'value laptop' equation—Apple's not supposed to be both the cheapest option and the best value... but it seems like that's squarely where the Neo landed for the good-but-cheap laptop category. My nephew is also my godson, and to kick off his computing journey, I thought I'd let him choose from a Framework 12 I bought to test, or the MacBook Neo I bought a couple months ago to use around the studio.

0 views
マリウス 4 days ago

80Retros x HMX Monochrome

After spending a fair amount of time with the KTT x 80Retros GAME 1989 Orange , I figured it was about time to take a closer look at the HMX -side of the 80Retros catalogue. The 80Retros x HMX Monochrome have been with me for a while, ever since I picked them up back in Seoul. The switches stand out from the rest of the 80Retros lineup as they don’t ship in a film canister, and they have a fairly boring black and white colorway. The 80Retros x HMX collaboration comprises of a handful of linear switches, amongst others the KD200 (a Kodak -yellow homage), the FJ400 (a Fujifilm -green homage), the GAME 1989 Classic (a Game Boy DMG-grey homage with pink stems), the Joker (a green/white/purple character homage), and the Monochrome , which arrived as one of the later releases. While most other 80Retros switches ship in oversized film-canister packaging, which is probably half the reason people bought into the lineup in the first place, the Monochrome , however, break that pattern, as they come in a plain sealed pack. 80Retros have framed this as a practical decision, since a sealed bag preserves the factory lube better than a (non-airtight) film canister. The Monochrome have a white top housing, a black stem, and a black bottom housing. There’s no nostalgia, just basically a clean, modern industrial look. It’s probably one of the few switches in the lineup that would feel at home on a build that’s trying to look new rather than old. The interesting thing here is that the Monochrome seem to be materially identical to the KD200 , at least from the information I was able to dig up on them. It seems like they use the same PA12 top housing, same LY stem, same 13.55mm stem length, and the same HMX P2 bottom housing. The only spec that appears to be different on paper is the spring, that is a 42g on the Monochrome versus a 45g on the KD200 . The Monochrome seem to basically be a KD200 in different clothes with a lighter spring. Therefor it seems like most of the KD200 -flavoured tendencies show up here too. The first thing you notice is just how light they are. 42g is on the gentle end of the linear spectrum these days, and even coming from the GAME 1989 Orange at 40g actuation, the Monochrome feels softer, probably because the PA12 top, HMX P2 bottom, and LY stem combo doesn’t have the same dry, gritty character the KT2 stem gives the Orange . There’s no audible texture in the travel here. It’s just smooth from top to bottom. Stock smoothness is very good. HMX ’s factory lube is well applied, with visible coverage on the stem sides and along the spring contact points. Slow-pressing a single switch at ear level reveals nothing worth complaining about, as there’s no scratch, no spring ping, and no leaf chatter. This means you can just install them and stop thinking about them, which, for a stock switch, is probably what most people would want. Wobble seems to be in line with the rest of HMX ’s newer-mold output. There’s a touch of north-south play and a touch of east-west, neither of which are distracting in normal typing. The Monochrome has a sound profile that’s noticeably soft, light, and, for lack of a better word, swooshier . The Korean reviewer who teardown-photographed the whole 80Retros x HMX lineup described it as a “wave-like” sound. There’s still a clean tonk on the bottom-out, but it sits lower in the mix and the upper harmonics that make for a louder pop are largely absent. Volume-wise, the Monochrome is on the quieter side. Not silent, not Volume 0 -quiet, but noticeably more restrained than e.g. the GAME 1989 Orange . On softer builds (gasket-mount, Poron -foamed, that sort of thing), it leans firmly into muted thock territory. On more rigid aluminium builds I’d expect it to open up slightly, but my own testing has been on softer cases, so take that with a grain of salt. In short, where the Orange has audible character, the Monochrome is doing something quieter and a little more uniform. If you enjoy the Orange ’s pop you’re probably be slightly disappointed with the Monochrome . As for the factory lubing, it is competently done. I peeked into a few switches and the application is consistent enough that I didn’t feel any particular urge to retune them. If you’re someone who lubes everything regardless, maybe be sparing here, as otherwise you’ll smother what little articulation the switch already has. The switches accept films, like everything else in the lineup, and films do their usual job of tightening housing tolerances and compressing the sound profile slightly. Given how restrained the Monochrome already sounds, I’d hesitate to film them unless the build absolutely needs it. You’d mostly be removing what little air is left in the sound. The 80Retros x HMX Monochrome are soft and gently-weighted linears with very few rough edges and they are relatively quiet in volume. Whether that’s the switch you want depends entirely on what you’re trying to build. If you want acoustic complexity, the GAME 1989 Orange is definitely more interesting. If, however, you want a low-effort and low-noise linear that disappears into the build, the Monochrome fit that role pretty well. I wouldn’t call it an exciting switch, but I would, however, call it a sort of grown-up switch. Disclaimer: I’m not a switch scientist. I don’t own a force curve rig, I can’t tell you the exact durometer of the KT2 blend, and my ears are probably not calibrated to the standards of someone like ThereminGoat . This review is based on my personal experience typing on these switches across a few different boards and ultimately actively using them on my primary keyboard . Your mileage may vary based on your plate material, case, keycaps, and other factors. Take everything here as one person’s experience and use it as a starting point for your own.

0 views
Andre Garzia 5 days ago

We need to own our computing experience

Originally when I talked about owning our own platform is this blog, I meant owning the stack that powers and serves the blog. Moving to your own VPS or servers or static pages in which you didn't depend on some *Blog As A Service* company such as Wordpress.com. Eventually, I [started talking about owning the workflow that empowered your blog experience](https://andregarzia.com/2026/02/building-your-own-blogging-tools-is-a-fun-journey.html) not only your posting experience but your reading experience. To that effect, I showed how I created my own blog reader and integrated that into Firefox and also my own blog editor. Recently, I think that we need to move further into owning more and more of our computing experience. The avalanche of LLM/AI based slop solutions being force fed into our lives is radicalising me towards a very specific path in which owning my own platform now needs to mean controlling my own computing experience. I been an Apple user for a very long time and have [spoken previously about my recent desire to leave the platform](https://andregarzia.com/2026/03/apple-just-lost-me.html) because of a recent decrease in quality of macOS, change in priority for Apple in regards to being an independent developer in their ecosystem, and a general feeling that I must move away from big tech. In that post, I outlined my desire to move to an [MNT Pocket Reform](https://mntre.com), [Fairphone Gen 6 with potentially Murena /e/OS](https://fairphone.com) and maybe a NAS. I already purchased the Pocket Reform and am waiting for assembly and shipment, but I changed my approach for the next two items in that list. Instead of buying a NAS, I decided first to experiment with self-hosting and homelabbing by converting an old x86 MacBook Pro into a server using [Yunohost](https://yunohost.org). That server is going surprisingly well for me and I am moving more and more of my computing to inside the house. I will eventually get a proper NAS or build one, but at the moment that server is all I need. I am even hosting my [fediverse account](https://social.soapdog.org/@soapdog) in it using [GoToSocial](https://gotosocial.org). I reckon that I will spend close to 500 pounds to get the Fairphone with /e/OS. I don't have that budget right now and am afraid of doing it blind cause I been checking the forums and it seems like WhatsApp stopped working in the last update and not all features of Halifax UK bank app are working. I don't want a switch to a deGoogled OS to prevent me from talking to my friends or using my bank. I know that sucks, but those are not easily solvable problems. Like my original plan with the NAS, I think I might be able to test the waters of e/OS/ by buying an old second-hand smartphone and installing it and seeing for myself how well it works. That will cost me much less and then if I like it enough, I can make the move to a Fairphone. So now the issue is figuring out what phone to buy on a budget of 150 pounds or less. Moving back to Linux on open hardware and to Android but deGoogled is my slow journey towards computing autonomy. Google was never worth trust, but the recent move to prevent side-loading on Android and stop showing links on their search result page, becoming a de facto slop as service engine, is something I can't really abide. Apple hypermaniacal need to control the experience of their users and milk both developers and users as much as possible reached a tiping point for me. My Macbook Air doesn't feel like mine since there are piling frictions when trying to run software that is not coming from the App Store. I'm done with that. What is left then? We need to return to a human-focused FOSS community. Not the fast turnaround LLM/AI commits into every single repo cause whoever is sponsoring this project needs it to move FAST. The best thing about the free and open source community has never been the code, but the ethos. Made by humans, to be understandable by humans, to be modifiable by humans. This crazy trend towards LLM assisted coding is removing the understandable part. Lots of commits are being generated by machine and reviewed by machines without a single person actually having read the whole thing. That will erode skills and also lead to code that is impossible to maintain cause no one has ever fully understood it. Hence why I am starting to also build my own tools. There are of course tools I depend on that are too large for me to build from scratch, goddess forbid trying to build a web browser, in those cases it is okay to use a FOSS solution like Firefox. But things that are dear to me like blogging, well I can build my own tools for that. Or epub manipulation tools, or small decentralisation apps. The more I build, the more I can be sure I can maintain it in the long run. I don't want a Web where all we do as creators is feed training models so that gigantic greedy corporations can get it all wrong and regurgitate shit to users. FAANG erected a wall inside the internet and creators are now on the outside. Fighting back is not done by creating local models, or ethical AI companies, fighting back is done by walking away and playing a different game. We can't win over Google and Apple at their own game. It is rigged. But we can play a different game in which they don't matter. For me that game is building offline-first, local-first, decentralised tools and apps for my friends and whoever else can benefit from them. Create for those around you, for those that matter. Forget web scale, think in terms of a village. Get back to Linux, deGoogle yourself if you're able to. Create FOSS and also use the tools you create. Use repairable tech if you can afford it and make sure to step out of this consumption and slop cycle the digital world has become.

0 views
Maurycy 5 days ago

Notes on optimizing battery life:

Ok, so you have something with a battery, and you want it to run for a long time. I'll be using the classic CR2023 non-rechargeable lithium "coin cell" as an example, but everything here applies to other types of battery. (except the exact voltage and capacity numbers) First off, it helps to measure power draw in current and charge in well, charge. It is tempting to convert everything into power and energy, but don't. Most circuit's power draw is much closer to constant current than constant power: a single clock cycle on a microcontroller involves charging or discharging some number of MOSFET gates. That requires some number of coulombs, not some number of joules. Linear regulators turn any circuit into a perfect current sink: no matter what potential is supplied, the device sees a constant voltage and will always draw the same current. Even if you don't use any, most chips will use a few to generate internal voltages. This is the "typical" current draw of an AVR32DD32 microcontroller over voltage from the datasheet : Black: 25 °C. Yellow: 125 °C. Also, battery capacity is nearly-universally specified as charge, usually in milliamp hours: a 100 mAh battery can support 1 mA of current for 100 hours before it's "dead". (more on what this means later) Non-ideal batteries : This battery has 3 volts stamped right on it... but that's kinda of a lie: Measuring the battery with a meter, the voltage is actually 3.3 volts. However, checking the datasheet, getting the manufacturer's claimed 235 mAh capacity requires operating down to 2 volts: From the datasheet (yes, these have one) With these "CR" Li/MnO 2 cells, the discharge curve is fairly flat: a device that only works down to 85% of nominal (2.6 volts) can still use a good 90% of the capacity. However, an "Alkaline" Zn/MnO 2 1.5 volt cell falls below 80% of nominal with a quarter of it's charge remaining. The manufacturer considers them dead at 0.8 volts — around half the original voltage. In a typical circuit, two batteries will be connected in series to produce a 3 V-ish supply. To get the advertised capacity, the device must be able to run down to 1.6 volts: the same as a (fresh) single cell! Think of supply voltage like a budget : If your battery will drop down to 2 volts and the MCU needs 1.8 V, any other components involved in supplying power must not drop more than 200 mV. It's not that the same MCU won't work on two AA batteries, but it won't be able to use the last 10% or so of capacity because it requires at least 1.8 / 2 = 0.9 volt per cell. Ok, so design for half the nominal supply voltage ? Batteries have non-trivial internal resistance, which causes a voltage drop when any current is drawn: a coin cell is usually around 10 ohms, while large AA cells sit around 0.1 ohms. To understand what causes this, let's look at how a coin cell works: On the negative electrode, a piece of lithium metal looses it's electron and dissolves into the electrolyte. Li → Li + + e - The resulting ions travel over to positive electrode and steal oxygen from the manganese dioxide: 2 MnO 2 + 2 Li + + e - → Li 2 O + Mn 2 O 3 This reaction releases a lot of energy because lithium is an alkali metal the manganese doesn't really care. That released energy is actually what powers the connected circuit. Crucially, the whole thing depends on positive lithium ions reaching and reacting with the positive electrode: moving against the electric field produced by the battery. The open circuit voltage, 3.3 volts, is enough to completly stop the reaction. This is why batteries only discharge once a circuit drains some of the accumulated electrons... but for the reaction to proceed at a reasonable rate, the voltage must drop quite a bit below the measured open-circuit voltage. If you've done any chemistry, it should come as no surprise that this is affected by temperature : As a rule-of-thumb, to operate down to -40 C, plan for ten times the internal resistance at room temp. If you see the voltage rail dropping by 50 mV at 20 C, make sure there's still enough voltage to go around if it drops 500 mV. Another thing that impacts reaction rate is the amount of reagents present , or in other words, the charge left in the battery: resistance increases as the battery is drained. As a test, I discharged an Alkaline battery at 400 mA: Orange: open circuit, blue: under load With a fresh cell, pulling almost half an amp only results in 100 mV of drop, or 0.25 ohms. By the time the battery is half empty, the resistance doubled to around half an ohm. At 60% discharge, the under-load voltage has dropped below the 0.8 V "dead" threshold. Reducing the voltage requirement won't help here: shortly afterwards, the resistance increased so much my test rig needed to supply power to force those 400 mA through. The smaller CR2032 cells start at around 10 ohms, and reach several hundred ohms by the time the open-circuit voltage falls to 2 V. It follows that any circuit that draws a lot of current can not use the full rated capacity. For pulsed loads, large capacitors can help, but they have their own problems which I'll discuss later. Also, batteries get worse as they age . Electrolytes can evaporate/leak and side-reactions can form layers that impede current. There's a good chance you've experienced this: a battery that tests fine on a meter but refuses to actually power anything. What's happened is that it developed a huge internal resistance (many killohms). In series with a high-impedance multimeter, it doesn't create any noticeable voltage drop. When connected to an actual device, the voltage drops to almost nothing. This is why you should be skeptical of any claims of 20 year, 30 year, 50 year battery life. Sure, that might be what you get by dividing nominal capacity by average current draw, but there's no telling how well the battery will work after all that time: I doubt even the manufacture really knows what happens past a decade or two. There's also self discharge , where leakage currents drain the battery, even when it's sitting on a shelf: This is usually given by the manufacturer as percent of capacity per year. Because the cell's voltage doesn't change all that much during discharge, — and the current is quite small — it's a fraction of the original capacity, not of what's remaining. This alone is enough to kill a AA battery in only 5 years depending on temperature (hotter is worse)... but again, this is not the only mechanism at play: Just because self-discharge might suggest a hundred year shelf-life, doesn't mean it will actually work in a hundred years. Another "fun" effect is voltage droop : Drawing current can deplete the chemicals around the electrode, causing a temporary increase in resistance. Applying a 400 mA current pulse to a half-empty ZnMnO 2 500 mAh cell caused the internal resistance to triple over the course 40 seconds: Yellow: cell voltage. Blue: Current Eventually, the battery does recover, but it took a good minute or so: Actually a trace of a different pulse, so the starting voltage is higher. What's interesting is that even though no current is being drawn, the battery circuit voltage is still not back to where it should be. This is where the "resistance" model starts to break down. It's more accurate to say that the pulse temporarily pushed the cell down it's discharge curve: increasing the resistance and decreasing the open circuit voltage. This gets worse when the battery is nearly empty: I applied a similar 10 second pulse to an 80% drained cell, it took around 5 minutes minutes to for it's open circuit voltage rise back above 0.8 volts. This effect highly variable depending on temperature (colder is worse) and state of charge, so it's good to include a wide voltage margin when designing a circuit that will draw sustained current. In short , internal resistance increases when... ... it's cold ... the battery is close to being empty ... the battery is used ... you do nothing at all Plan for a much worse voltage drop than what you see on your workbench: it's possible to loose as much as a volt per each mA drawn with a mostly empty coin cell on a cold night. With that in mind , it's time to look at those capacity numbers. As already discussed, aiming for longer than a decade or so is largely pointless because of battery aging. These CR2023 batters have quoted shelf life of 10 years, so it's going to be my target: From a CR2032 (~230 mAh), a device can draw an average of 2.6 uA if it runs down to 2 volts. From a AA (~3000 mAh) AA battery, a device can draw 34 uA if it runs down to 0.8 volts per cell. ... so we have a voltage budget and a target current. Keep in mind that internal resistance will cut into the voltage if when draw pulses in excess of a few microamps. Measurement techniques: These small currents present a problem: most multimeters don't really do well below a microamp. Benchtop models that can measure down to the nanoamps exist but are quite expensive. On paper, measuring current is easy: Insert a known resistor into the circuit and measure the voltage drop across it... except this either requires adding a large resistance or measuring a tiny voltage. A better way is to use an op-amp to hide the voltage drop from the device under test: The amplifier tries to keep its two inputs at the same voltage, which requires it to exactly match the device's current through the feedback resistor. This results in exactly the same voltage as if it was used as a shunt, except with zero burden voltage. Since most chips have two opamps, I use the other to create a VDD/2 supply rail which is used as the ground. This allows the chip to have access to voltages both above and below it. Most modern chips are "rail-to-rail", meaning they are designed to operate close to one of the supply rails... but this doesn't work too well: Consider what happens when the input current drops to zero. The amplifier has to pull the output (with a non-trivial amount of capacitance) down to zero. If the best the amplifier could do is connect the output to the negative rail, the voltage would exponentially decay, approaching zero but never reaching it. Would this be a huge problem? Probably not. Is it a good idea to make the chip's job as easy as possible? Yes. As a bonus, this allows the device to measure currents in both directions. Using the 100 pA/mV range, the circuit has an offset of ~10 pA, so it's not quite a picoammeter, but it's close. This makes it good for testing the leakage of MOSFETs, diodes, capacitors and the such. However, this design has one huge snag: It's zero burden voltage up to a fairly modest point. Once the output maxes out (100 nA - 100 uA depending on the range), the device will can see the full shunt resistance. This is a non-issue for testing component leakage, but it becomes a problem when measuring the current drawn by a microcontroller. For measuring sleep current, it's best to build a firmware image that never wakes up, and short the meter's input or connect a second power source during startup. Another option is to use a tiny feedback resistor: connecting a 1 kohm resistor between the input and output yields a 1 uA/mV range with a maximum of 1 mA. Once the microcontroller boots, the resistor can be removed to measure it's sleep current. (and if you are drawing more than this, you probably shouldn't) This is also a good trick to avoid crashing MCUs when switching ranges, which can cause a momentary disconnection depending on the geometry of your selector switch. Shielding is not optional : 100 picoamps is a kind of current that floats around on the air. It's best to put the whole setup inside a metal box connected to the meter's ground. Running coax to a scope or meter is fine because the wire's sheath is connected to the rest of the shield: this isn't RF stuff. If you don't have a box, wrapping the whole thing in aluminum foil works almost as well. (make sure it's not touching anything!) Also, it's a little silly to carefully screen out interference only to reintroduce it with a power supply, so it's best to run everything with batteries: Two 1.5 volt alkaline cells provides 3 volts and four is close enough to 5 volts. Also, be careful with what's touching the meter or part under test: a post-it note can easily conduct a whole nanoamp at 5 volts. Wood and fabric are similarly problematic. If in doubt as to if something is a problem, test it. When measuring capacitors, there's a really annoying property to be aware of : The dielectric material can slowly absorb or release charge over multiple hours. This effect is mostly known for recharging high-voltage capacitors after they've been removed from circuit — with unpleasant results — but it can also result in a deceptively high leakage current that goes away if the capacitor is used in a real circuit. Unless you have fancy polypropylene capacitors, you'll have to leave them in the test rig for several hours before taking a reading. Circuit testing : Of course, it's not enough to test individual components. The whole system has to work correctly with an imperfect power supply: A device running on a coin cell should be able to tolerate the full 1k with a two volt supply. ... also, it's a good idea to simulate a dead battery: an empty battery shouldn't result in hardware damage or data loss. Temperature can greatly effect leakage currents. If you expect the components to get up to 80 C, grab a heat gun and see how it performs at those temperatures. Practical advice: Before considering any components, does to circuit board itself consume any power? There's lots of people on forums saying you shouldn't use a soldermask, or that flux on the board causes leakage... For testing, I used a nothing special JLCPCB, green, FR4, 2-layer board. It had two quarter millimeter traces 30 mm long and separated by 2.7 mm. For the measurements, I used a 9 volt bias, which should represent worst case results: Clean : Testing the board as it came from the factory Humid : Breathing on it for a few seconds (99% RH, no visible condensation) Fingers : Touching it to get skin oils on the board Rosin : Spread some RMA flux and burned it with a soldering iron. Board condition and soldermask Current Soldermask, clean < 5 pA Soldermask, fingers < 5 pA Soldermask, humid < 5 pA Soldermask, rosin < 5 pA No soldermask, clean < 5 pA No soldermask, fingers 10 pA No soldermask, humid 30,000 pA No soldermask, rosin 20 pA The main troublemaker is humidity. If you are designing a circuit that needs to work outside, underwater or underground, it would be a good idea to include some desiccants: most plastic will allow water vapor to permeate inside. The soldermask prevented any significant leakage between traces, but problems could still happen between component pins. Conformal coatings will protect against short exposures, but will suffer from the permation problem. Soldering residue or skin oils aren't a problem unless you are doing picoamp metrology. Capacitors : Electrolytic or tantalum capacitors can leak multiple microamps at just a few volts: A jellybean 100 uF 16V electrolytic pulled 26 uA at nine volts, which is ten times the entire current budget for a CR2032! That cap alone could discharge the battery just a year or two. Ceramic capacitors a lot better: I grabbed a random 1 uF capacitor from my parts bin initially pulled several hundred nanoamps, but it dropped down to 920 pA @9 volts after two hours. Even a hundred of these would only draw 92 nA, which is only 3% of the budget. TLDR ; Don't use electrolytic or tantalums. Ceramic capacitors are fine in reasonable quantities and when run well below their rated voltage. Diodes are very commonly used for reverse polarity protection, but there are two possible configurations: A series diode uses a forward biased diode to prevent reverse current from getting to the device. A parallel diode adds a reverse biased diode to clamp the reverse voltage before the device is damaged. In the series configuration, voltage drop is very important : Real diodes are quite different from the idealized model. The voltage drop of a 1N4148 is only 0.6 V at 1 mA of draw and at 25 C. The relationship between current and voltage drop is roughly exponential: For a silicon PN diode, passing 10 times the current requires an extra 100 mV. This also works in the other direction: A circuit that only needs 10 uA (peak) will only see around 0.4 volts of drop across that diode. Temperature affects this: The threshold will rise ~2 mV for each degree the diode is cooled. At -40, expect 130 mV of extra voltage drop compared at room temperature. A Schottky diode has a much lower threshold voltage: 1 mA of current only needs 0.25 V. This can be a huge improvement to your voltage budget, although it's still a non-trivial amount. In the parallel configuration, reverse leakage matters . Because it's highly dependent on voltage, I measured a few diodes at 5 volts, which is closer to normal operating conditions: 2N4148 [PN] @5V: 2.3 nA BAT46 [Schottky] @5V: 2.4 uA In this test, the schottky doesn't do so well: It's three orders of magnitude worse than a similar PN diode. So, use a PN diode right? Well, if the battery can supply 50 mA into a short (fresh coin cell), there might be around a volt across the device. That can be enough to cause damage. So, what's a good reverse polarity protection circuit? An n-channel low-side switching version is also possible A MOSFET can act as a near ideal diode: If the gate (connected to the negative rail) is in fact, the lowest voltage, it's switched on. If the battery is inserted backwards, the gate now has the highest voltage in the circuit and the transistor stays off. However, it's still important to consult the datasheet or conduct experiments: the battery voltage might not be enough to fully turn on the FET, and even a properly "on" MOSFET still has a voltage drop. The final option is nothing: Battery clips that physically prevent a user from inserting a battery backward exist. These have no electrical penalties except for the contact resistance (which is negligible when compared to the battery's). Schottky leakage also poses a problem for dual power supply circuits. A microamp of backfeed into the backup battery can actually be enough to damage it. In these cases, you may be forced to use a PN diode or use a variation of the MOSFET trick: connect the gate to the primary supply rail. This will, at a minimum, perform as well as a silicon diode because of the transistor's intrinsic body diode. Once the power rail drops down to zero, the MOSFET's gate will be negative and it will turn on. However, it's performance won't be perfect if the main rail takes more than a millisecond or so to loose voltage. It's best to plan for a PN diode drop and consider any extra voltage as be a nice bonus. Computers : In theory, CMOS logic doesn't draw any power when sitting idle. In practice, it absolutely does. An 8-bit AVR128DD28 microcontroller draws 1.5 uA during sleep mode. Connecting a 32KHz crystal and using the integrated RTC to provide wake ups bring it up to 1.8 uA. This leaves just 700 uA of average current to work with. Ok, but at some point, the processor has to do something. Each clock cycle has a fixed cost: For the AVR, I measured it at ~0.28 nanoamp seconds, meaning that the battery has enough power for 3,000 billion cycles. Individual clock cycles on an AVR128DA28 running at 32 kHz. However, it's almost always a good idea to use a slow clock: The chip will draw an extra 277 uA of current draw per MHz. At the default four MHz clock speed, that's just over a milliamp. There's no guarantee the battery will be able to supply that kind of power. Decoupling caps aren't going to save you here: 1 mA is enough to drain a rather big 1 uF capacitor at 1 volt per millisecond. (remember, no electrolytics allowed.) Since the MCU has a minimum voltage of 1.8 volts, and the batteries can go as low as two, it's only safe to run like this for 200 microseconds / 800 cycles! However, running at 32 kHz only draws an average of 10 microamps. There are still current pulses from each clock cycle, but there are small enough to that they only drop a 1 uF capacitor by 0.27 millivolts. The processor does draw more a bit more quiescent current while running then in sleep mode. This is why some people suggest you should run at the maximum clock speed to save power... but while it is more efficient on paper, it simply doesn't work with real batteries. This also lets us calculate how long it can run for: 10 microamps is 14 times the remaining 700 nanoamp budget, so the processor can be running 7% of the time. Also, on this particular MCU, wakeups cause a big current pulse: Because of stray capacitance, applying power to the processor costs a whole 2.62 nanoamp seconds. With a 1 uF capacitor, this would drain it by 2.62 mV. However, with smaller caps like 6.8 nF, it could would discharge them a whole 385 mV. Stuff like this is why I'd recommend using around a microfarad: A decent 1 uF (MLCC) ceramic rated at a few times the supply voltage will leak almost nothing. To be fair, the datasheet does recommend this value, but plenty of people are in the habit of using smaller ones: When you have a 5 volt supply, loosing a third of a volt is not a big deal. Using a 3-but-actually-2 volt battery, it's enough to drop below the chip's minimum operating voltage. Some parts claim a much lower sleep current (in the nanoamps), but that's without retaining memory: Most applications can't use these modes. Consider a data-logger. Because flash consumes the same amount of power when writing a few bytes or a kilobyte, being able to buffer readings actually saves power. ... although there are some applications where a feature like this does make sense: This is something you have to consider before taking sleep current specs at face value. ... it's cold ... the battery is close to being empty ... the battery is used ... you do nothing at all Clean : Testing the board as it came from the factory Humid : Breathing on it for a few seconds (99% RH, no visible condensation) Fingers : Touching it to get skin oils on the board Rosin : Spread some RMA flux and burned it with a soldering iron. https://ww1.microchip.com/downloads/en/DeviceDoc/AVR128DA28-32-48-64-DataSheet-DS40002183B.pdf : The discussed microcontroller. https://data.energizer.com/pdfs/cr2032.pdf : Example battery datasheet https://lcamtuf.substack.com/p/real-mlccs-and-inductors-have-curves : Another footgun with capacitors

0 views
./techtipsy 1 weeks ago

You can run Forza Horizon 6 on an unsupported AMD RX 400/500 series GPU on SteamOS

This post serves as a personal bookmark and a mirror of this fantastic guide by Ok-Pace-1900 on /r/linux_gaming to ensure that this information does not get lost. I learned the hard way that the GPU I have in a DIY Steam Machine PC, the AMD RX 480, is strictly unsupported by Forza Horizon 6. Forza Horizon 6 will not work for AMD users with GPUs based on the Polaris or Vega architectures and older (for example Radeon 400 and 500 series players). These architectures are below our minimum supported specification. I knew that asking for a refund on Steam would be the easy way out. Deciding against it, I did a quick search for the FH201 error code and stumbled on the Reddit post mentioned above. My CPU is good enough for Forza Horizon 6 (Intel i5-10500), so the additional launch options command that worked for me is the following: Simple fix, but the context around this is actually kind of funny. The way a lot of Windows-only games work on SteamOS is via a translation layer referred to as Proton. With this trick, you can pretend that your GPU has some DirectX features that it actually does not have, but it doesn’t matter since it can be successfully emulated via translation to Vulkan, which the GPU supports well! As a result, I can play Forza Horizon 6 on a hacky SteamOS build, with 1080p low or medium settings. Low settings is a 60 FPS experience, with medium settings some areas like Tokyo can struggle a bit and drop below it to ~40 FPS. Now all I need to do is to get rid of the urge to splurge on a great GPU, which would also require a case and PSU upgrade… Slightly off-topic, but can you monitor your gaming PC via Prometheus Node Exporter and visualize it in Grafana? :)

0 views
Susam Pal 1 weeks ago

Childhood Computing

I recently stumbled upon a nice blog post titled Childhood Computing . It made me think about my own childhood computing experience. I am much older than the author of the aforementioned post but like them, I love computers too. I have for most of my life. When I was about eight years old, my parents decided to transfer me to a new school because of its curriculum. They did not know it then, and it probably did not even matter to them, but this new school had a computer lab. That was quite remarkable for its time. I grew up in a very tiny industrial town. The computers in the lab were hand-me-downs from the silica factory around which the town was built. We got only about two hours of time per month in the computer lab but the little time I got there opened up a whole new world for me. Before entering the lab, we had to leave our shoes at the door. 'These are expensive machines. We must keep them free of dust', our teacher would say. It was a ritual. The computers were very old IBM PC compatible machines, mostly with monochrome cathode-ray tube (CRT) monitors. They had no hard disks at all. They had a few hundred kilobytes of RAM. Every time, we performed the same ritual. Insert a 5¼-inch floppy disk to load MS-DOS into memory. Then insert another disk to load LOGO. Then write small LOGO programs and watch the turtle move. I have written more about that early LOGO programming experience here: FD 100 . Further, since there were no hard disks and storage was at a premium, nothing was ever saved. The moment you turned off the computer, all your work vanished. So saving a program meant literally writing the program down in a physical notebook. Since I got so little time with an actual computer, most of my Logo programming happened with pen and paper at home. I would 'test' my programs by tracing the results on graph paper. Eventually, I would get about thirty minutes of actual computer time in the lab to run them for real. One particular Logo program I still remember very well drew a house with animated dashed lines, where the dashes moved around the outline of the house. Everyone around me loved it, copied it and tweaked it to change the colours, alter the details and add their own little touches. That must have been my first 'free and open source software'. The 'licence' was 'do whatever you want but show me if you make any interesting modifications'. Occasionally, when we successfully completed the Logo programming exercises our teacher set us as challenges, he would let us play computer games too. The first computer game I ever played was Moon Bugs. Space Invaders, Bricks, Dangerous Dave and others were some of my other favourites. Space Invaders inspired me to write my own game but the little GW-BASIC programming I knew back then and the very limited access to computers I had then were insufficient to write anything more sophisticated than simple text-based input/output programs. But eventually, as an adult, I did manage to write an invaders-like game, which you can find here: Andromeda Invaders . Writing this game fulfilled a childhood dream! One of my buddies liked the game called Digger developed by Windmill Software. It soon became my favourite as well. The game came in a self-booting disk, so we did not have to go through the elaborate ritual of first inserting a floppy disk to load DOS. We could insert the Digger floppy disk directly and the computer would boot and start the game immediately. Another computer game I remember fondly was Grand Prix Circuit by Accolade. I really loved typing the command to launch the game, knowing that in a moment I will be greeted with its excellent opening music. Grand Prix Circuit blew my mind. As a child who only knew how to draw basic two-dimensional geometrical shapes with Logo and GW-BASIC, I found it astounding that a computer program could create a projection of a three-dimensional fictional world that you could navigate with keyboard inputs. How was it even possible, I wondered. It has been over 30 years since then, but the memories and the feelings still remain fresh in my mind. There are times when I can close my eyes and recall the buzzing sound of the dozen or so computers running in the lab, the beeps from the power-on self-tests (POST) and the distinctive, strangely pleasant smell of the closed, air-conditioned room. For some reason, that smell is one of the strongest memories I have from those days. I have never been able to describe it well, but once in a while I encounter it in very unexpected places, like a corridor somewhere, or a store, and it takes me right back to those early days of childhood computing. Those childhood computing experiences form some of my strongest and most vivid memories. They were such magical experiences, full of wonder and exploration. Read on website | #miscellaneous

0 views
@hannahilea 1 weeks ago

Text of the wild: Receive notifications from your BirdNET-Pi via ntfy

Tutorial for configuring a BirdNET-Pi with ntfy to send push notifications whenever a rare-to-you bird starts yelling

0 views
Kev Quirk 1 weeks ago

Using Fountain Pens for Note Writing

My note taking process has evolved a lot over the years. Originally I used my iPad with the Apple pencil, but having to charge it every few days was a pain. Then I switched to the Remarkable 2 , which was great and I didn't need to charge the pen. But as I produced more and more notes, it became awkward to search for them. Unfortunately, handwriting to text, and handwriting search both require a monthly subscription. Screw that. So I switched to the Supernote Nomad , which (in my opinion) has better tooling for finding notes than the Remarkable. I mentioned this in my how do you take notes post. I created a new system for taking notes, and it worked well. It still had it's frustrations, but I could generally find what I was looking for on the Nomad. Then I started writing the occasional journal entry, and for that I decided I needed a physical book and fountain pen. I don't know why, it just felt more personal and more permanent doing it that way. Being left-handed, fountain pens can be difficult, so I got myself a Lamy Safari with a left-handed nib. It writes lovely, especially for the ~£25 ($30) price. So I got myself another one and put red ink in so I can "highlight" certain notes in my journal. It is a really nice experience, and as my journal entries mount up, I can easily flip between pages. And then it dawned on me...it's not the technology that I'm using for notes that's the problem. It's the fact that I'm using technology in the first place! As a test, I dug out an old notebook that we got a freebie from work (it's a really nice one - I figured nice paper would help) and started using my Lamy for note taking in work too. Using a slightly adapted version of my note taking system, it's been glorious! Flipping back through physical pages and easily finding my notes for a particular day has been very refreshing. Everything is in my notebook now, and I rarely use OneNote as a result. I decided to go all in, I sold my Nomad back in January and haven't looked back since. The Lamy is a nice pen, but I wanted something a bit more substantial (and made of metal) as the pen gets a lot of punishment being bashed around in my bag all day. I was happy to spend more money, but didn't want to go crazy, so I ended up buying a Kaweco AL Sport in a lovely stonewashed blue colour. Unfortunately Kaweco don't offer a specific left-handed nib, but I've found it to be nicer to write with than the Lamy anyway. It doesn't scratch as much - not that the Lamy is particularly scratchy, but the Kaweco is soooo smooth. I realised that my main frustration with both the Nomad and the Remarkable is that there's a 1-2 second delay on every screen change, so if I need to flip back 10 pages, that's like half a minute of pissing about. Half a minute doesn't sound like a lot, but I can flip back 10, or even a hundred pages in my notebook in a second. It just feels smoother. My note taking system now surrounds the specific paper I have in this fancy notebook from work (wide ruled lines, and a side margin) and I can't find anything else that's the same. Everything I find is either shitty quality paper, narrower lines, or no margin. Luckily for me, I've been able to find some spares hang around the office, so I have a cache of half a dozen or so, which should last me a few years. I'm totally converted to analogue note taking at this point, and I really enjoy the process of writing with the fountain pens. I just need to force myself not succumb to my constant desire to start collecting things - as I don't need 50 fountain pens, just like I don't need 50 watches... but I have them ! This post kinda went all over the place, sorry about that. 🤷🏻‍♂️ Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️ You can reply to this post by email , or leave a comment .

0 views
Jeff Geerling 1 weeks ago

News about Raspberry Pi 6 and Microcontroller Development

On Thursday, three of the lead Raspberry Pi engineers hosted an AMA on the r/engineering subreddit . One of the most interesting tidbits was on the Pi 6. Looking back at previous launches: Following that cycle, one would expect a Pi 6 3-4 years after the Pi 5, which would put it in 2026 or 2027. 2012: Raspberry Pi 2015: Raspberry Pi 2 (+3 years) 2016: Raspberry Pi 3 (+1 year) 2019: Raspberry Pi 4 (+3 years) 2023: Raspberry Pi 5 (+4 years)

0 views
Circus Scientist 1 weeks ago

Installing SmartPoi D1 Mini version with Arduino IDE V2

4. Go to Tools -> Boards -> Boards Manager and select esp8266 to install (may need to re-start Arduino IDE before it shows up) 5. Install the ESP8266 LittleFS Uploader program in Arduino: Step 1: Download the Plugin You need to put this file in a specific directory. If the folder doesn’t exist yet, you will need to create it. The workflow to actually upload files is identical to the old version: The console at the bottom will compile your file system image and push it straight to the flash memory! 5. Get SmartPoi from the SmartPoi Firmware Downloader website 6. Select options in Arduino IDE 2.0: 7. Compile and Upload 8. Do the LittleFS Filesystem Upload mentioned above (step 5.4) The post Installing SmartPoi D1 Mini version with Arduino IDE V2 appeared first on Circus Scientist . Download and install Arduino IDE V2 Go to Tools -> Manage Libraries and install FastLED 3.7.5 (ESP8266 version of SmartPoi will not work with the latest FastLED!) Go to File -> Preferences and input the following in “Additional boards manager URLs” (adding ESP8266 boards support) : http://arduino.esp8266.com/stable/package_esp8266com_index.json Open your web browser and go to the official GitHub releases page for the tool: GitHub: arduino-littlefs-upload Download the latest version ending in (for example: ). Windows: 1. Navigate to: 2. Look for a hidden folder named (note the dot at the front).3. Inside , create a new folder named .4. Move the file into that folder. macOS / Linux: Open Finder/File Manager and go to your home directory: (You may need to hit on Mac to see hidden folders). Create a folder named inside it. Drop the file into that folder. Restart Arduino IDE 2. In IDE 1.8, the tool lived in the Tools menu. In IDE 2, it lives in the Command Palette . Open the Command Palette by pressing: Windows/Linux: + + macOS: + + Type into the prompt. You should see the option: Upload LittleFS to Pico/ESP8266/ESP32 . Open your Arduino sketch. Go to Sketch > Show Sketch Folder . Create a folder named exactly alongside your file. Place whatever HTML, TXT, or config files you want inside it. Important: Select your D1 Mini board and port, and close the Serial Monitor (if open, it blocks the upload). Open the Command Palette ( ) and click Upload LittleFS to Pico/ESP8266/ESP32 . CPU Frequency: 160mhz Board: LOLIN(WEMOS) D1 R2 & Mini Flash Size: “4MB (FS:3MB OTA: ~512KB)” Debug Port: Serial (if you want to see serial ouput – optional) Select your port (COM1, USB0 …) Leave everything else on default settings

0 views
Unsung 1 weeks ago

“Some say it sounds like an alto saxophone.”

I witnessed this Siemens locomotive depart yesterday and for a second I thought I was losing my mind. Then, I smiled so hard: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/some-say-it-sounds-like-an-alto-saxophone/yt1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/some-say-it-sounds-like-an-alto-saxophone/yt1.1600w.avif" type="image/avif"> Turns out, the startup melody was intentional in this particular model. The power converters have to adapt the current from the overhead line to convert it to the three-phase motors of the locomotive, and that generates a rising tone. The engineers decided to change the logic to increment the tone in precise few steps resembling a musical scale, rather than allowing it to rise continuously. I debated whether to include this on Unsung. I guess it is software, even if it’s attached to the hardest of hardware. And sure, it’s “just” delightful, but it is still kind of nice to see someone go extra, adding a human touch atop a technical process that had to happen anyway. But then, it reminded me of something. No, not the poor CSIRAC trying (and similarly struggling) to become a musician. Rather, a “musical road” built in Lancaster, California, where the engineers messed up the execution, creating a truly unpleasant, atonal melody. David Simmons-Duffin wrote a fun essay in 2008 analyzing the “bug” thoroughly, including useful visuals, and even replicating the problem. Subsequently, Tom Scott visited the road and made a video about it ten years later. It won’t surprise you that the cause of the bug was bad hand-off between designers and engineers, but there can be no software patch for grooves you cut in asphalt – and so at least as of last year , the embarrassingly sounding road was still there. I think I prefer my out-of-tune musical scale performed by a train. Given it’s easy to find compilation videos of Siemens locomotives booting up , it seems I’m not alone. #bugs #real world #sound design #youtube

0 views
Unsung 1 weeks ago

Shallow breathing

Turns out that the breathing light survives, sort of, not really, in an Apple product today: The AirPods Pro case does this when charging – right at the start, or when you tap it later. But it disappears after a while, the pace is now 28 breaths a second (over twice as fast as the original iteration), and the light is orange. Is it still the same thing, reflecting on how smaller organisms breathe faster? Or is it mostly an unrelated idea, with the light fading in and out indicating activity rather than lack of it? My money is on the latter – the light turns white when pairing, too, and it cycles even faster then – but it was nice to imagine the return of the old feature for a second or two… or 2.1, to be precise. #apple #details #hardware #motion design

0 views
Jeff Geerling 1 weeks ago

Wi-Wi Is Wireless Time Sync at 1 nanosecond

At NAB, I found a demo of Wi-Wi STAMP , a wireless time synchronization protocol that came out of Japan's NICT . Wi-Wi stands for Wireless 2Way interferometry, and it uses the 900 MHz band for picosecond-level time sync, and mm-level distance accuracy, in a tiny box, currently the size of a smartphone. The system is still in development, but existing prototypes have 20ps of phase synchronization jitter, and time synchronization down to 30ns. The next generation will have time down to 5ns in real-world use.

0 views

SG-IOV: Socket-Granular I/O Virtualization for SmartNIC-Based Container Networks

SG-IOV: Socket-Granular I/O Virtualization for SmartNIC-Based Container Networks Chenxingyu Zhao, Hongtao Zhang, Jaehong Min, Shengkai Lin, Wei Zhang, Kaiyuan Zhang, Ming Liu, and Arvind Krishnamurthy ASPLOS'26 SR-IOV is a PCIe feature that enables a single device to expose multiple virtual functions, each of which appears as a separate device. This can be used to securely share one hardware device among multiple virtual machines. For containerized workloads, one would think that SR-IOV could be used to expose a virtual NIC to each container. This would save CPU cycles as network virtualization would be handled by the NIC rather than software. The trouble is that SR-IOV doesn’t scale to high container counts (they top out on the order of 100 of virtual functions per physical NIC). This paper introduces Socket-Granular I/O Virtualization (SG-IOV) which enables NIC virtualization at the socket level . The authors have an implementation working on NVIDIA BlueField-3. The key assumption that SG-IOV makes is that container networking uses stream sockets (e.g., TCP) rather than datagram sockets (e.g., UDP). In other words, software running inside a container wants to reliably send a stream of bytes rather than a stream of packets. Streams are transmitted through Warp Pipes , which are simply ring buffers (comprising a base address, head and tail pointers). Warp Pipes can be stored in host memory or NIC local memory. A socket is associated with one or more dedicated Warp Pipes. A server can have thousands of Warp Pipes, because the low-level NIC hardware (which may have scalability limits) doesn’t directly interact with Warp Pipes. Updates to head and tail pointers are not performed directly via memory writes, instead they are communicated through a Cross-FIFO . A single message in a cross-FIFO contains three fields: Ring buffer ID (which Warp Pipe to update) Which pointer to update (head or tail) The new value of the head or tail pointer There are multiple implementations of the Cross-FIFO interface. For example, the authors use a PCIe-based implementation for host→NIC communication, and a RDMA based implementation for NIC→NIC communication. Each cross-FIFO uses limited NIC resources; therefore many sockets share a single cross-FIFO, which is OK because the messages they contain are coarse-grain (e.g., increment tail pointer by 16KiB). Say an application in container A on host 1 wants to send 8KiB of data to an application in container B on host 2. The flow looks like this: Host CPU (host 1): The application calls the standard socket API The payload is copied into the Warp Pipe associated with the socket A message is enqueued into a PCIe cross-FIFO, indicating that the head pointer should be incremented by 8KiB ARM CPU running on the NIC (host 1): Dequeue the message from the cross-FIFO, update the head pointer Enqueue task descriptors to the low-level NIC hardware to read the payload data (i.e., local DMA) from the Warp Pipe and store it in the correct Warp Pipe on host 2 (i.e., RDMA); note that these task descriptors can configure the NIC to perform appropriate network virtualization After the data has been transmitted, enqueue a message to the NIC on host 2 (via a RDMA-based cross-FIFO) to update the head pointer for the Warp Pipe on host 2 ARM CPU running on the NIC (host 2): Dequeue the message from the cross-FIFO Update the local head pointer Enqueue a message to the host CPU (host 2) via a PCIe-based cross-FIFO, indicating that the head pointer should be incremented Host CPU (host 2): Dequeue the message from the PCIe-based cross-FIFO Send data to the application when it calls And a similar sequence would update tail pointers. The key design principles of SG-IOV are: All state is tracked by software running on the host CPU and ARM CPUs running on the NIC All low-level NIC hardware is used in a stateless manner, and is multiplexed across many sockets A benefit of this design is that it is flexible enough to handle the loopback case efficiently. Section 8 of the paper shows that SG-IOV enables the use of hardware-accelerated network virtualization (saving host CPU cycles) while offering latency and bandwidth that is competitive with other container-based network virtualization systems. Figs. 17 and 18 show latency and bandwidth numbers for a few benchmarks: Source: https://dl.acm.org/doi/10.1145/3779212.3790218 Dangling Pointers It seems like one downside of this system is excessive memory usage. If each socket has dedicated large ring buffers, then DDIO may not be effective (see here , here , and here for other papers that discuss this problem). Subscribe now Ring buffer ID (which Warp Pipe to update) Which pointer to update (head or tail) The new value of the head or tail pointer The application calls the standard socket API The payload is copied into the Warp Pipe associated with the socket A message is enqueued into a PCIe cross-FIFO, indicating that the head pointer should be incremented by 8KiB Dequeue the message from the cross-FIFO, update the head pointer Enqueue task descriptors to the low-level NIC hardware to read the payload data (i.e., local DMA) from the Warp Pipe and store it in the correct Warp Pipe on host 2 (i.e., RDMA); note that these task descriptors can configure the NIC to perform appropriate network virtualization After the data has been transmitted, enqueue a message to the NIC on host 2 (via a RDMA-based cross-FIFO) to update the head pointer for the Warp Pipe on host 2 Dequeue the message from the cross-FIFO Update the local head pointer Enqueue a message to the host CPU (host 2) via a PCIe-based cross-FIFO, indicating that the head pointer should be incremented Dequeue the message from the PCIe-based cross-FIFO Send data to the application when it calls All state is tracked by software running on the host CPU and ARM CPUs running on the NIC All low-level NIC hardware is used in a stateless manner, and is multiplexed across many sockets

0 views
Unsung 1 weeks ago

“If you just ignore those pesky impossible details, the demo looks deceptively simple.”

This DOS demo called Wake Up! is astonishingly small – only 16 bytes: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/if-you-just-ignore-those-pesky-impossible-details-the-demo-looks-deceptively-simple/yt1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/if-you-just-ignore-those-pesky-impossible-details-the-demo-looks-deceptively-simple/yt1.1600w.avif" type="image/avif"> The demo doesn’t just make QUOD feel gargantuan. Output this one solitary emoji, “Woman Technologist with Light Skin Tone” – 👩🏻‍💻 – and you spent all your 16 bytes, too. ( Proof !) The creator’s write-up is a bit hard to follow, but there are some interesting aspects to it: “stealing” the beauty from math itself, the reliance on the environment being set up properly (to avoid wasting precious bytes on initialization), and the tight connection between the hardware, the visuals, and the sound. Oh yeah, in case you haven’t noticed, this has sound! Two out of 16 bytes are devoted to its production, using an existing BIOS function that slots nicely into the existing graphics routine. This is another recent demo that caught my attention: NINE , from about a year ago: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/if-you-just-ignore-those-pesky-impossible-details-the-demo-looks-deceptively-simple/yt2.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/if-you-just-ignore-those-pesky-impossible-details-the-demo-looks-deceptively-simple/yt2.1600w.avif" type="image/avif"> The platform here is a computer of a similar vintage as the early DOS machines, Commodore 64. C64, like many other home microcomputers, supported special graphical entities called “ sprites ,” which were used for gaming since the rest of the graphics couldn’t move very fast. (Today, your mouse pointer is conceptually similar to a sprite, being imbued with special powers unavailable to anything else.) C64 could output up to 8 such sprites. The demo inexplicably has… nine. The NINE demo didn’t focus on absolute minimalism, but instead employed a barrage of ghostly (and ghastly!) trickery to achieve something that was thought impossible. This time around, the explainer from the author – a 22-minute YouTube video – is filled with great storytelling, and absolutely worth a watch: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/if-you-just-ignore-those-pesky-impossible-details-the-demo-looks-deceptively-simple/yt3.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/if-you-just-ignore-those-pesky-impossible-details-the-demo-looks-deceptively-simple/yt3.1600w.avif" type="image/avif"> I think both of these showcase two things that I appreciate and that translate to great UX design as well. The first demo shows tight integration between design and the capabilities of software and hardware. Let’s pick the sound routine that needed just 2 bytes. If there wasn’t a way to output sound within this extremely tight budget, the author likely wouldn’t fight to their death to get sound… they would instead focus on what else was possible within two bytes. This is getting as close to full understanding of the medium you’re working in as possible. The second demo highlights how sometimes you can use absolutely horrid sleights of hand to achieve something beautiful – and how you can perhaps find beauty in those sleights of hand, too. It reminds me of the quote attributed to Teller (of Penn & Teller): Sometimes magic is just someone spending more time on something than anyone else might reasonably expect. Penn & Teller talk a lot about how there are only two keys to their success: going further than others would think, and not worrying about employing inelegant tricks in service of something that would appear to be of utmost elegance. Today’s computing limitations are different than the ones from the 1980s. But a lot of this attitude can still be helpful, even four decades in, and even if your work seems as far away from the demoscene as you can imagine. #graphics #hacks #youtube

0 views
Giles's blog 1 weeks ago

10Gb/s Ethernet: using mini-heatsinks with a 10GBASE-T SFP+ module

In my last post I showed the somewhat-scary temperatures I was getting on the MikroTik 10GBASE-T SFP+ module I have plugged into , the 10Gb/s switch I have in my study. As I mentioned then, the plan was to try using some of the mini-heatsinks that people use on Raspberry Pis, to see if that would help. Here's how it went. I bought a 40-piece set of heatsinks made by the improbably-named VooGenzek on Amazon for €8 , and attached two of them like this -- see the bottom module, with the yellow cable: That was 24 hours ago, and here's a chart of temperatures from that module showing the 24 hours before and after: You can see the big drop-off in the middle of the chart; it even overshot a bit (I'm guessing because the heatsinks absorbed a bunch of heat initially when I put them on). The difference looks more dramatic than it is! See where the Y-axis starts. But given that the weather has been pretty much the same today as it was yesterday, that looks like a 3.5°C improvement. Not great, but not nothing either. In the copious discussion about the last post on Hacker News , one of the most popular comments -- from -- was that there are two generations of SFP+ modules for this kind of thing; an older one, using a Marvell chip, and the newer one using one from Broadcom. on the ServeTheHome forums made the same point. They both mentioned that a good indicator of which type a module is using is that the older ones tend to be rated up to 30 metres, while the newer ones are rated up to 100. This one is a MikroTik S+RJ10 , which definitely is one of the older ones -- the specific chip is mentioned in the docs . I'm not sure which chip the Protectli modules in my router are -- they're these modules -- but they say they're rated up to 30 metres, so I guess they're probably the older type too. Looking into switching those out might be a good next step! I probably won't do that in the short term, though, unless I start getting issues as we move into summer.

0 views
Kev Quirk 2 weeks ago

Replacing my ISP router with a UniFi Cloud Gateway Max

So I recently upgraded my home internet to full fibre, after which I also decided to upgrade my router as there were some things I wanted to do with my network that my ISP-provided router wasn't capable of. I replaced my mesh system with a UniFi one a couple years ago, so it made sense to stick with the UniFi brand and go with one of their routers, so £250 later, I had a Cloud Gateway Max on its way to me. I figured this would be a straightforward process, but my god was I wrong! So I took a backup of my Cloud Key 1 config and figured I could unplug that, plug in the Cloud Gateway, restore the config and be done. I assumed there would be a couple things I needed to tweak, but for the most part, it would be a simple 10 minute job. You see, dear reader, in order to configure the Cloud Gateway you need an internet connection. No internet connection, no configuration. So by unplugging my ISP router -thus killing the internet to my entire house - I couldn't even get to the point where I could enter my ISP credentials, let alone configure the bloody thing. Without the internet connection all I could configure was the IP and MAC of the router. Absolutely pointless! There may be a way of doing this without an internet connection, but I couldn't find it and it certainly wasn't obvious. So I had to reconnect my old rig - the ISP router, the Cloud Key, and access points. Then I hung the Cloud Gateway off the ISP router so it could get an internet connection. Luckily this worked and I was finally able to configure the thing. After which I disconnected the Cloud Key, assuming the access points would all fail over to the Cloud Gateway when I restored the config backup from the Cloud Key. You see, the config back from the Cloud Key is a completely different file format ( ) to what the Cloud Gateway was expecting ( ). What the actual fuck! Soooooo back online went the Cloud Key, and I had to remove all 4 access points from there, just so I could "adopt" them with the Cloud Gateway. Then I had to manually setup my SSIDs and DHCP so it all matched the old rig. But finally, after 3 hours of fucking around, a job that I thought would take 10 minutes was done. UniFi is really good kit and has lots of features, but I don't understand why it has to be so difficult to set up. It feels like UniFi is the Apple of the networking world - they do everything they can to keep you in their ecosystem and up sell. Want our wifi? You're gonna need one of our routers, or this arbitrary piece of hardware for that. Oh you want to move an AP to a new management device? Yeah, you can't just move it - you need to do these 5 steps instead. Had I not already spent over a thousand pound on this UniFi kit, I would have chucked it all on eBay and gone with something else, but alas WiFi Apple has me in their walled garden! Anyway, it was a painful process, but it's working. And to be fair to UniFi, once it is all setup, it's rock solid and feature rich. I won't be upgrading again any time soon though, that's for sure! Now I just need to familiarise myself with all the nifty features the Cloud Gateway offers, so I can improve my network. Fun times! A Cloud Key is a stupid piece of hardware that is needed in lieu of a UniFi router. It controls the wireless access points.  ↩ Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️ You can reply to this post by email , or leave a comment . A Cloud Key is a stupid piece of hardware that is needed in lieu of a UniFi router. It controls the wireless access points.  ↩

0 views
Unsung 2 weeks ago

“This is where your mouse becomes a cryptographic instrument.”

A fascinating 9-minute video from PawelCodeStuff about randomness in the context of computing: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/this-is-where-your-mouse-becomes-a-cryptographic-instrument/yt1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/this-is-where-your-mouse-becomes-a-cryptographic-instrument/yt1.1600w.avif" type="image/avif"> It explains those weird moments where sometimes the computer asks you to wiggle your mouse – to generate unpredictable numbers – although the specifics of what exactly was random in my wiggling was a surprise to me. There is something poetic about computers yearning for that one thing they can never get – complete unpredictability – and collecting it in a little pool like you would something very precious. Also fascinating that in modern CPUs, there now exist hardware components that gather truly random data from the real world. While I have never needed true randomness in my design career, knowing how to control pseudorandomness (specifically, how to replay it) has been helpful. Here’s an example. In my essay about Gorton , there is this interactive bit where you can drag a slider for “messiness.” With regular pseudorandomness, the experience is wiggly and gross: But when you always restart the prng from the same seed (“the Groundhog Day maneuver”), it feels much better: #details #motion design #security #youtube

0 views
Sean Goedecke 2 weeks ago

AI datacenters in space do not have a cooling problem

This year Elon Musk has started banging the drum about building AI datacenters in space. As the only person who owns a successful space company and a (moderately) successful AI company, this is a sensible way to boost his profile and net worth. Is it a sensible way to build datacenters? The first comment underneath most discussions of this always goes along these lines: “you obviously can’t build AI datacenters in space, because heat dissipation is really hard in space, and AI datacenters generate a lot of heat”. In general I am distrustful of snappy answers like these. It reminds me of the “AI datacenters obviously don’t use a lot of water, because cooling fluid circulates in a closed-loop system” argument: if it were true, there wouldn’t be a debate at all, just one side who understand the obvious point and another side who are stupid. Some arguments are like this! However, more often there’s a complicating factor that makes the snappy answer incorrect. In the water-use case, it’s that the closed-loop system has to itself be cooled by an open-loop evaporative chiller. What about the space datacenter case? First, let’s give the argument a fair shake. Although space is itself very cold, cooling is tricky because everything you’d want to cool is surrounded by vacuum. Heat transfer works in three ways: Vacuum is an excellent insulator because it defeats the first two methods of heat transfer. If there are no (or very few) atoms surrounding an object, those atoms can’t move around or collide. That’s why vacuum is used as an insulator in thermoses, travel mugs, and so on. So how can space datacenters get rid of their heat? By doubling down on the third method of heat transfer. Although it’s much harder to do heat transfer via moving atoms around in space, it’s actually easier to do heat transfer via emitting radiation. Any good emitter is also a good absorber. A perfectly black object is the most efficient emitter, but it’s also the most efficient way to absorb photons from external sources, which is why black objects get hotter in the sun 1 . In space, the sun’s light is much easier to avoid, because there aren’t objects everywhere for it to bounce off. A shaded radiator can dump quite a lot of heat. It would still require putting more radiators in space than we’ve ever done before. There are plenty of writeups out there if you want to read through the numbers. This is a recent one that estimates ~2500 square metres of radiation area would be needed to serve 1MW of datacenter energy (much less than what it’d need in solar panels) 2 . A serious AI datacenter is around 100MW 3 , so we’d need 250,000 square metres of radiation area. The largest current radiator in space is probably the ISS, at around a thousand square metres. Is scaling that up by 250x a lot? Yes, but it’s not necessarily ridiculous . We currently have zero industrial operations happening in space, so there’s been no need to push the boundaries here. In the grand scheme of things, 250,000 square metres is not that big. By my very rough estimates, that’s between 100-500 Starship launches: a couple of years at SpaceX’s current launch cadence, or a few months at their (very optimistic) estimate of future launch cadence. Of course, you don’t just need radiators to put a datacenter in space. You need a similar quantity of solar panels, the GPUs themselves, and all kinds of other supporting equipment. If a GPU dies in an Earth datacenter, you can go in and swap it out; if it dies in space, you just have to leave it dead and keep going with less capacity. It’s still wildly impractical to build AI datacenters in space. But it’s not impossible , and it’s certainly not impossible because of the cooling, which is a relatively minor component of the total mass that would have to be launched into space. In theory, black clothing would keep you slightly colder at night. Nobody ever talks about how impossible it would be to power space datacenters, despite the fact that you’d need to launch over triple the solar panel area into space than radiation area. I guess because people know solar panels exist and that the sun shines in space. The first gigawatt AI data centers are coming online this year, but 100MW is a fair estimate for a current pretty-large-but-not-enormous AI datacenter. Hot (i.e. fast-moving) atoms bump into other atoms, making them move and thus heating them up Hot atoms physically move from one location to another (e.g. in a fluid or gas), staying hot and thus making their new location hotter Hot objects emit photons (electromagnetic radiation), cooling themselves down and heating up other objects those photons collide with In theory, black clothing would keep you slightly colder at night. ↩ Nobody ever talks about how impossible it would be to power space datacenters, despite the fact that you’d need to launch over triple the solar panel area into space than radiation area. I guess because people know solar panels exist and that the sun shines in space. ↩ The first gigawatt AI data centers are coming online this year, but 100MW is a fair estimate for a current pretty-large-but-not-enormous AI datacenter. ↩

0 views