Did you know you can get a “smart bed” that tracks your sleep, breathing, heart rate, and even regulates the temperature of the mattress? No? Well, you can get root access to one, too, as [Dillan] shows, and if you’re lucky, find a phone-home backdoor-like connection. The backstory to this hack is pretty interesting, too!

You see, a Sleep Number bed requires a network connection for its smart features, with no local option offered. Not to worry — [Dillan] wrote a Homebridge plugin that’d talk the cloud API, so you could at least meaningfully work with the bed data. However, the plugin got popular, Sleep Number didn’t expect the API to be that popular. When they discovered the plugin, they asked that it be shut down. Tech-inclined customers are not to be discouraged, of course.

Taking a closer look at the hardware, [Dillan] found a UART connection and dumped the flash, then wrote an extensive tutorial on how to tap into your bed’s controller, which runs Linux, and add a service you can use locally to query bed data and control the bed – just like it should have been from the beginning. Aside from that, he’s found a way to connect this hub to a network without using Sleep Number’s tools, enabling fully featured third-party use – something that the company doesn’t seem to like. Another thing he’s found is a reverse SSH tunnel back into the Sleep Number network.

Now, it can be reasonable to have a phone-home tunnel, but that doesn’t mean you want it in your personal network, and it does expose a threat surface that might be exploited in the future, which is why you might want to know about it. Perhaps you’d like to use Bluetooth instead of WiFi. Having this local option is good for several reasons. For example, having your smart devices rely on the manufacturer’s server is a practice that regularly results in perma-bricked smart devices, though we’ve been seeing some examples of dedicated hackers bringing devices back to life. Thanks to this hack, once Sleep Number shutters, is bought out, or just wants to move on, their customers won’t be left with a suddenly dumbed-down bed they can no longer control.

[Header image courtesy of Sleep Number]

If you’re pairing a tiny Linux computer to a few peripherals — perhaps you’re building a reasonably custom Pi-powered device — it’s rightfully tempting to use something like an STM32 for all your low-level tasks, from power management to reading keyboard events.

Now, in case you were wondering how to tie the two together, consider HID over I2C, it’s a standardized protocol with wide software and peripheral support, easily implementable and low-power. What’s more, [benedekkupper] gives you an example STM32 project with a detailed explanation on how you too can benefit from the protocol.

There are several cool things about this project. For a start, its code is generic enough that it will port across the entire STM32 lineup nicely. Just change the pin definitions as needed, compile it, flash it onto your devboard and experiment away. Need to change the descriptors? The hid-rdf library used lets you define a custom descriptor super easily, none of that building a descriptor from scratch stuff, and it even does compile-time verification of the descriptor!

The project has been tested with a Raspberry Pi 400, and [benedekkupper] links a tutorial on quickly adding your I2C-HID device on an Linux platform; all you need is DeviceTree support. Wondering what’s possible with HID? We’ve seen hackers play with HID aplenty here, and hacking on the HID standard isn’t just for building keyboards. It can let you automate your smartphone, reuse a laptop touchpad or even a sizeable Wacom input surface, liberate extra buttons on gamepads, or build your own touchscreen display.

Summer has settled upon the northern hemisphere, which means that it’s time for sweet, sweet strawberries to be cheap and plentiful. But would you believe they taste even better in freeze-dried format? I wouldn’t have ever known until I happened to get on a health kick and was looking for new things to eat. I’m not sure I could have picked a more expensive snack, but that’s why we’re here — I wanted to start freeze-drying my own strawberries.

While I could have just dropped a couple grand and bought some kind of freeze-drying contraption, I just don’t have that kind of money. And besides, no good Hackaday article would have come out of that. So I started looking for alternative ways of getting the job done.

Dry Ice Is Nice

Early on in my web crawling on the topic, I came across this Valley Food Storage blog entry that seems to have just about all the information I could possibly want about the various methods of freeze-drying food. The one that caught my eye was the dry ice method, mostly because it’s only supposed to take 24 hours.

Here’s what you do, in a nutshell: wash, hull, and slice the strawberries, then put them in a resealable bag. Leave the bag open so the moisture can evaporate. Put these bags in the bottom of a large Styrofoam cooler, and lay the dry ice on top. Loosely affix the lid and wait 24 hours for the magic to happen.

I still had some questions. Does all the moisture simply evaporate? Or will there be a puddle at the bottom of the cooler that could threaten my tangy, crispy strawberries? One important question: should I break up the dry ice? My local grocer sells it in five-pound blocks, according to their site. The freeze-drying blog suggests doing a pound-for-pound match-up of fruit and dry ice, so I guess I’m freeze-drying five entire pounds of strawberries. Hopefully, this works out and I have tasty treats for a couple of weeks or months.

Preparation

In order to make this go as smoothly as possible, I bought both a strawberry huller and a combination fruit and egg slicer. Five pounds of strawberries is kind of a lot, eh? I’m thinking maybe I will break up the ice and try doing fewer strawberries in case it’s a complete failure.

I must have gotten rid of all our Styrofoam coolers, so I called the grocery store to make sure they have them. Unfortunately, my regular store doesn’t also have dry ice, but that’s okay — I kind of want to be ready with my cooler when I get the dry ice and not have to negotiate buying both while also handling the ice.

So my plan is to go out and get the cooler and the strawberries, then come back and wash the berries. Then I’ll go back out and get the dry ice and then hull and slice all the berries. In the meantime, I bought some food-safe desiccant packets that absorb moisture and change color. If this experiment works, I don’t want my crispy strawberries ruined by Midwestern humidity.

Actually Doing the Thing

So I went and bought the cooler and the strawberries. They were $2.99 for a 2 lb. box, so I bought two boxes, thinking that a little more poundage in dry ice than berries would be a good thing. I went back out to the other grocery store for the dry ice, and the person in the meat department told me they sell it in pellets now, in 3- and 6-lb. bags. So I asked for the latter. All that worrying about breaking it up for nothing!

Then it was go time. I got out my cutting board and resigned myself to hulling and slicing around 75 strawberries. But you know, it really didn’t take that long, especially once I got a rhythm going. I had no idea what the volume would be like, so I started throwing the slices into a gallon-sized bag. But then it seemed like too much mass, so I ended up with them spread across five quart-sized bags. I laid them in the bottom of the cooler in layers, and poured the dry ice pellets on top. Then I took the cooler down to the basement and made note of the time.

Since I ended up with six pounds of dry ice and only four pounds of strawberries, my intent is to check on things after 18 hours, even though it’s supposed to take 24. My concern is that the strawberries will get done drying out earlier than the 24-hour mark, and then start absorbing moisture from the air.

Fruits of Labor

I decided to check the strawberries a little early. There was no way the ice was going to last 24 hours, and I think it’s because I purposely put the lid on upside down to make it extra loose. The strawberries are almost frozen and are quite tasty, but they are nowhere near depleted of moisture. So I decided to get more ice and keep going with the experiment.

I went out and got another 6 lb. of pellets. This time, I layered everything, starting with ice in the bottom and ending with ice on top. This time, I put the lid on the right way, just loosely.

Totally Not Dry, But Tasty

Well, I checked them a few hours before the 24-hour mark, and the result looks much the same as the previous morning. Very cold berries that appear to have lost no moisture at all. They taste great, though, so I put them in the freezer to use in smoothies.

All in all, I would say that this was a good experiment. Considering I didn’t have anything I needed when I started out, I would say it was fairly cost-effective as well. Here’s how the pricing breaks down:

• 28-quart Styrofoam cooler: $4.99
• 4 lbs. of strawberries: $5.99
• 12 lbs. of dry ice at $1.99/lb.: $24
• a couple of resealable bags: $1

Total: $36, which is a little more than I paid for a big canister of freeze-dried strawberries on Amazon that lasted maybe a week. If this had worked, it would have been pretty cost-effective compared with buying them.

So, can you freeze-dry strawberries without a machine? Signs still point to yes, but I’m going to go ahead and blame the Midwestern humidity on this one. You can bet I’ll be trying this again in the winter, probably with fewer berries and smaller cooler. By the way, there was a small puddle underneath the cooler when it was all said and done.

Have you ever tried freeze-drying anything with dry ice? If so, how did it go? Do you have any tips? Let us know in the comments.

 

Main and thumbnail images via Unsplash

If you own an Intel motherboard with a Z170 or Z270 chipset, you might believe that it only supports CPUs up to Intel’s 7th generation, known as Kaby Lake. Even the CPU socket’s pinout is different in the next generation — we are told, it will fit the same socket, but it won’t boot. So if you want a newer CPU, you’ll have to buy a new motherboard while you’re at it. Or do you?

Turns out, the difference in the socket is just a few pins here and there, and you can make a 8th or 9th generation Coffee Lake CPU work on your Z170/270 board if you apply a few Kapton tape fixes and mod your BIOS, in a process you can find as “Coffee Mod”. You can even preserve compatibility with the 6th/7th generation CPUs after doing this mod, should you ever need to go back to an older chip. Contrasting this to AMD’s high degree of CPU support on even old Ryzen motherboards, it’s as if Intel introduced this incompatibility intentionally.

There’s been a number of posts on various PC forums and YouTube videos, going through the process and showing off the tools used to modify the BIOS. Some mods are exceptionally easy to apply. For example, if you have the Asus Maximus VIII Ranger motherboard, a single jumper wire between two pads next to the EC will enable support without Kapton tape, a mod that likely could be figured out for other similar motherboards as well. There’s a few aspects to keep in mind, like making sure your board’s VRMs are good enough for the new chip, and a little more patching might be needed for hyper-threading, but nothing too involved.

Between money-grab features like this that hamper even the simplest of upgrades and increase e-waste, fun vulnerabilities, and inability to sort out problems like stability power consumption issues, it’s reassuring to see users take back control over their platforms wherever possible, and brings us back to the days of modding Xeon CPUs to fit into 775 sockets.

Don’t get too excited though, as projects like Intel BootGuard are bound to hamper mods like this on newer generations by introducing digital signing for BIOS images, flying under the banner of user security yet again. Alas, it appears way more likely that Intel’s financial security is the culprit.

We thank [Lexi] for sharing this with us!

Even though not all of us will do it, many of us are interested in the art of casting metal. It remains a process that’s not out of reach, though, especially for metals such as aluminium whose melting points are reachable with a gas flame. The video below the break takes us through the aluminium casting process by showing us the lost-foam casting of a cylinder head for a BSA Bantam motorcycle.

The foam pattern is CNC milled to shape, and the leftover foam swarf is removed with a hot wire. The pattern is coated with a refractory coating of gypsum slurry, and the whole is set up in a tub packed with sand. We get the impression that the escaping gasses make this a tricky pour without an extra sprue, and indeed, they rate it as not perfect. The cooling fins on the final head are a little ragged, so it won’t be the part that goes on a bike, but we can see with a bit of refining, this process could deliver very good results.

For this pour, they use a gas furnace, but we’ve seen it done with a microwave oven. Usually, you are losing wax, not foam, but the idea is the same.

Most of the Hackaday community would never wire a power supply to a circuit without knowing the expected voltage and the required current. But our mechanical design is often more bodged. We meet folks who carefully budget power to their microcontroller, sensors, and so on, but never measure the forces involved in their mechanical designs. Then they’re surprised when the motor they chose isn’t big enough for the weight of their robot.

An obstacle to being more numbers oriented is lack of basic data about the system. So, here are some simple tools for measuring dynamic properties of small mechanisms; distances, forces, velocities, accelerations, torques, and other things you haven’t thought about since college physics. If you don’t have these in your toolkit, how do you measure?

Distance

For longer distances the usual homeowner’s tools work fine. The mechatronics tinkerer benefits from two tools on the small end. A dial or electronic caliper for measuring small things, and a thickness gauge (or leaf gauge) for measuring small slots.

A thickness gauge is just metal leaves in different thicknesses, bolted together at one end. Find a combination of leaves that just fits in the space.

Force

Here’s four force measuring tools we use to cover different magnitudes of force: a postage scale, a push stick, a spring scale, and a letter scale. The postage scale is best purchased. For big things, the bathroom scale works.

A push stick is a force measurement device that you can make yourself. We first saw one of these used to tune slot cars, but they’re universally useful. It’s a simple pen shaped device made with a barrel from any small transparent parts tube, a spring, and a plunger with a protruding pin. Grasp the barrel and push the gizmo with the pin, and you can read the force off the tube.

If you need it to be calibrated, remember that you just bought a postage scale. Push it into the scale and mark off reasonable increments. Make several, in different sizes. A Z or L shaped plunger is useful for hard to reach places.

The conventional spring tension scale is useful, but most commercial ones are terribly made and inaccurate. You can make yourself a better one. They are useful for measuring the spring constant of springs, for learning the tractive effort needed to move a robot, finding the center of gravity of a robot arm, and a hundred other ‘how much oomph’ things. Again, it’s just a matter of connecting a hook to a spring, and measuring its deflection.

For yet lighter weights, you could buy a letter scale, at least in the old days. Today you might have to make your own.  It can be as simple as a piece of spring steel fixed to a sheet of calibrated cardboard.

Torque

Torque measurements are good not only for sizing actuators, but for measuring efficiency.

How you do torque measurements depend on the speed you want to make them at. For static loads, just put a lever of known length on the shaft and measure the force. Torque = distance * force. For fast rotating systems, you can run the system at a known speed and measure the electrical energy used.

If you just want to apply a varying known torque to measure efficiency, your life is much easier. Mount a broad wheel of some sort on the shaft — RC airplane tires work well. Drape a piece of ribbon over the tire. Anchor it at the “out” end and hang a small weight at the “in” end. This is a Prony Brake, and it’s a useful device to know about. The force on the outside of the wheel is just enough to lift the weight – after that the ribbon slips. The measured torque is then the weight times the wheel radius.

You may also want to measure speeds and accelerations. Here, the ubiquity of cell phone cameras is your friend. Suppose you’re animating a crane on your model railroad. Record yourself on video moving the crane with your hands against a protractor to get a feel for speed and acceleration. In video editing software check the positions for various frames, and you now have position changes. The number of frames and distance can help you calculate the speed, and the change in speed vs time is acceleration.

If your mechanism is moving too fast for video, use a fast phototransistor or hall effect device and an oscilloscope, or gear down by holding a toy wheel against the shaft and measure the more slowly rotating wheel.

In the crane example, the torque you need to supply is the frictional torque plus the acceleration torque, and to calculate the acceleration torque you need the moment of inertia. For refresher: angular acceleration = torque / moment of inertia (ω = τ / I) and moment of inertia = mass * radius² (I = m * r² ) for point mass.

You can drive the crane with a repeatable torque, say using a pulley and weight or a motor, and get the acceleration ω₁ from the still frames on your video. If you repeat this with a known mass m a known distance r from the shaft axis, like a lump of putty on the end of the crane arm, you can get a second value: ω_2. 

Write the ω = τ / I equations, ω₁ = τ / I_crane and ω₂ = τ / (I_crane + r ² * m). Combining and isolating I_crane and holding our tongues just right, I_crane = r² * m / (ω₁ / ω₂ – 1).

Be careful to subtract the moment of inertia of your measuring apparatus, and add in the moment of inertia of the final drive if needed. Now you can size your servo with some confidence. Believe me, once you’ve done this a couple times, you’ll never go back to winging it.

Power

The easiest way to get a ballpark feel for power is to simply measure the system’s consumed power by measuring the electrical power at the motor, but this ignores losses in the drive train. And losses are one of the really interesting things to measure. Bad performance is usually friction, and efficiency is a goal for other reasons than just motor sizing or battery life. It’s a measure of how janky your setup is.

Does your model train or robot run poorly? Set it to climb a steep grade on a test track. Calculate the work it does: mass * height change. Measure the input electrical power and the time, Energy = V*I*T. You now have an idea of how much the actual power consumption differs from the maximally efficient system. Any power that went in but didn’t appear as potential energy in the choo-choo’s new position is frictional loss. Now you can experiment with loosening and tightening screws, changing gear mesh, and such, and have some idea if you’re making things better or worse.

Conclusion

None of the above was rocket science, and you don’t need to do some complex FEM analysis to make the average hacker project. But a bit of real engineering can go a long way towards more reliable mechanisms, and that starts with knowing the numbers you’re dealing with. Taking the required measurements can be simple if you know how to build the tools you need,  and your life will be easier with some numbers to guide you.

Technical work — including problem-solving — is creative work. In addition, creativity is more than a vague and nebulous attribute that either is or isn’t present when it’s needed. A short article by [Anthony D. Fredericks] gives some practical and useful tips on energizing and exercising one’s creativity.

Why would creative thinking be meaningful to a technical person? The author shares an anonymous observation that as children we’re taught to stay inside the lines, while as adults we are often expected to think outside the box. Certainly when it comes to technical tasks, our focus is more on logical thinking. But problem solving benefits as much from creative thinking as it does from more logical approaches.

How can one cultivate creative thinking? The main idea is that creativity is best flexed and exercised by actively looking for connections and similarities between highly dissimilar elements, rather than focusing on their differences. Some thought exercises are provided to help with this process. Like with any exercise, the more one does it, the better one becomes.

Practicing more creative thinking can help jolt new ideas and approaches to a tough problem, so give it a shot. It’s also worth keeping in mind that we all need a feeling of progress, especially during extended times of applying effort to something, so do yourself a favor and give yourself an occasional win.

The Apple II was launched in 1977, a full 47 years ago. The Apple IIe came out six years later, with a higher level of integration and a raft of new useful features. Apple eventually ended production of the whole Apple II line in 1993, but that wasn’t the end. People like [James Lewis] are still riffing on the platform to this day. Even better, he came to Supercon 2023 to tell us all about his efforts!

[James]’s talk covers the construction of the Mega IIe, a portable machine of his own design. As the name suggests, the project was based on the Mega II chip, an ASIC for which he had little documentation. He wasn’t about to let a little detail like that stop him, though.

The journey of building the Mega IIe wasn’t supposed to be long or arduous; the initial plan was to “just wire this chip up” as [James] puts it. Things are rarely so simple, but he persevered nonetheless—and learned all about the Apple II architecture along the way.

Simply Mega

For the unfamiliar, the Mega II contained most of Apple IIe, but condensed down to fit on to one single 84-pin ASIC. It first appeared in 1986, and was used in the Apple IIGS. The Mega II chip doesn’t contain a CPU, but does contain a lot of the supporting hardware that makes the Apple IIe what it is. The IOU, MMU, video and keyboard ROMs, and keyboard and mouse controller are all there.

In theory, you could wire it up with a CPU, some RAM, and a ROM, and you’d have an Apple II. That sounded about right to [James], but as he would soon find out, the reality is more complicated. Had real documentation been available, he might have learned this sooner, but he was flying blind and stuck at it anyway.

[James]’s talk starts by dispelling some myths. The first is that the Mega II is a single-chip Apple II. His own build makes it obvious that’s not the case. Beyond that, he also notes that the Apple IIGS didn’t use the Mega II for backwards compatibility. It was instead used as a memory controller and for working with classic Apple II video modes and the expansion slots. He also states that the “Gemini” chip from the Macintosh LC Apple II card is not a Mega II, based on significant differences in registers and general design. He wanted to check on a rumor, too, that the chip was never finished, hence why it was just used as a basic controller in the Apple IIGS. To figure that out, he wanted to prove that you could build a functional Apple II using the Mega II chip salvaged from the IIGS.

Early work went well. After spinning up a basic board with the Mega II and the necessary hardware, [James] was able to get a text video mode working. It spat out a lot of gibberish, but it was evidence that something was going on. The string “Apple ][” even appeared in the output!

It wasn’t smooth sailing from there, though. Months of debugging ensued, with a logic analyzer showing the “computer” he’d built was making seemingly random jumps all over the place rather than going through a normal boot process. He suspected it was because the chip wasn’t finished, but that wasn’t the case. Eventually, a friend suggested he check if one of the data bus lines was stuck. It turned out a stuck wire fragment on a solder pad was causing all of his problems. With that fixed, he made a huge leap forward. He saw the message appear—”KERNEL OK”. Success!

However, he still wasn’t at a prompt. He was stuck in a test routine, and didn’t have a fully fledged computer. Nonetheless, he knew this meant he was on the right path. If the test routine was behaving appropriately, it suggested the Mega II really did have most of an Apple II living inside it.

From there, the talk goes through the arduous work required to get this thing fully operational. He faced crash after crash as he tried to get a full boot to happen. Once he got that far, he had to try and go from a rat’s nest of wires and breadboards to something that wouldn’t fall apart every time he breathed on it. His final design has some neat features—like the way he built his own motherboard with a connector that let him plug his logic analyzer right in with a single connector.

By revision 2, he had the thing built up on a bunch of PCBs with header connectors, and it was even booting from floppy disks. The amount of work it took to get even this far was phenomenal. [James] didn’t just have to whip up a motherboard, he had to do all kinds of work to give the thing a working keyboard interface and the ability to read floppy disks. By this point, he’d realized that the supposed single chip solution that was the Mega II anything but. Beyond RAM, ROM, and a CPU, it also needed another custom ASIC called SlotMaker, and a keyboard controller. This chip is for handling expansion slots, but it also handles one important signal for the keyboard that makes it essential to the computer’s proper functioning. Frustrating stuff indeed. Other work involved producing video output over VGA and creating a working sound board.

His third revision involved consolidating his multi-PCB solution into a working computer on a single PCB. A few mistakes cropped up in the board design, but it wasn’t enough to stop [James]. With a little creative bodging, he got the thing operational. He’d managed to build a working computer based around the Mega II ASIC.

He may not have been the first to build a Mega II into a working computer; [James] admits that the prototype of the Tiger Learning Computer from Tiger Electronics does serve as an existing example that the Mega II was usable as a fully-fledged machine. But he did manage to do it without any support or documentation from Apple at all. That’s no mean feat.

Watching the talk, it’s easy to understand why the project took [James] several years to complete. It’s always neat to see someone set themself a difficult goal and follow through to completion. It’s also rad that [James] was able to teach us so much more about the Mega II that we never knew before. That’s worthy of celebration!

Selling your hardware hacks is a great way to multiply your project’s impact, get your creations into others’ hands, and contribute to your hacking-related budget while at it. If you’re good at it, your store begins to grow. From receiving a couple orders a year, to getting one almost every day – if you don’t optimize the process of mailing orders out, it might just start taking a toll on you.

That is not to say that you should worry – it’s merely a matter of optimization, and, now you have a veritable resource to refer to. At Supercon 2023, [MakeItHackin]/[Andrew] has graced us with his extensive experience scaling up your sales and making your shipping process as seamless as it could be. His experience is multifaceted, and he’s working with entire four platforms – Tindie, Lektronz, Etsy and Shopify, which makes his talk all that more valuable.

[MakeItHackin] tells us how he started out selling hardware, how his stores grew, and what pushed him to automate the shipping process to a formidable extent. Not just that – he’s developed a codebase for making the shipping experience as smooth as possible, and he’s sharing it all with us.

His research was initially prompted by Tindie, specifically, striving to make the shipping process seamless. If you go the straightforward way and use the Web UI to copy-paste the shipping data in your postal system, it’s going to take you a good few minutes, and it’s an error-prone process. This is fine for a couple orders a year, but when you’re processing dozens of orders at a time, it starts to add up. Plus, there’s a few issues – for instance, the invoices Tindie prints out, are not customizeable. As for Etsy, it is less than equipped for handling shipping at all, and you are expected to have your own system.

There are APIs, however – which is where automation can begin. The goal is simple – spending as little time as possible on shipping, and as much time as possible on designing hardware. He shows us a video with a simple demo – cutting down the shipping label creation time from a couple minutes, down to fourteen seconds. That alone is a veritable result, and, there’s more.

On the way there, he’s had to reverse-engineer a couple APIs. In the talk, you get a primer about APIs – how they work, differences between external and internal APIs, ways to tap into internal APIs and make them work your magic. APIs are one of the keys to having the shipping process run smoothly and quickly, and [MakeItHackin] teaches you everything, from managing cookies to using browser inspect element tools and Selenium.

Another key is having fun. [MakeItHackin] gives us another demo – an automated system that stays in your workshop, powered by a Raspberry Pi and assisted by an Arduino, which does the entire process from start to finish without human input, save for actually putting things into envelopes and taking them to the post office. Of course, the system is also equipped with flashing lights and sirens – there’s no chance you will miss an order arriving.

Then, he goes into customs and inventory management. Customs forms might require special information added to the label, which is all that much easier to do in an automated process completely under your control. As for inventory management, the API situation is a bit dire, but he’s looking into a centralized inventory synchronization system for all four platforms too.

The last part is about working with your customers as people. Prompt and personalized communication helps – some might be tempted to use “AI” chatbots, and [MakeItHackin] has tried, showing you that there are specific limitations. Also, careful with the temptation to have part of your shipping process be cloud-managed – that also means you’re susceptible to personal data storage-related risks, so it might be best to stay away from it.

In the end, we get a list of things to watch out for. For instance, don’t use your personal details on the envelope, whether it’s the “From” address or the phone number, getting substitute ones is well worth it to protect your privacy. On the practical side, using a label printer might turn out to be significantly cheaper than using an inkjet printer – remember, ink costs money, and, there’s a dozen more pieces of advice that any up-and-coming seller ought to know.

Of course, all this is but a sliver of the wealth of information that [MakeItHackin] shares in his talk, and we are overjoyed to have hosted it. If you’re looking to start selling your hardware, or perhaps you’re well on your way, find 45 minutes for this talk – it’s worth its metaphorical weight in gold.

A good amount of hacks can be done with off-the-shelf hardware – what’s more, it’s usually available all over the world, which means your hacks are easier to build for others, too. Say, you’ve built something around a commonly available portable router, through the magic of open-source software. How do you make the fruits of your labour easy to install for your friends and blog readers? Well, you might want to learn a thing or two from [Albert], who shows us a portable DLNA server built around a GL-MT300N-V2 pocket router.

[Albert]’s blog post is a tutorial on setting it up, with a pre-compiled binary image you can flash onto your router. Flash it, prepare a flash drive with your media files, connect to the WiFi network created by the router, run the VLC player app, and your media library is with you wherever you go.

Now, a binary image is good, but are you wondering how it was made, and how you could achieve similar levels of user-friendliness in your project? Of course, here’s the GitHub repository with OpenWRT configuration files used to build this image, and build instructions are right there in the README. If you ever needed a reference on how to make commonly available OpenWRT devices do your bidding automagically, this is it.

This is an elegant solution to build an portable DLNA server that’s always with you on long rides, and, think of it, it handily beats a typical commercialized alternative, at a lower cost. Want software upgrades? Minor improvements and fixes? Security patches? Everything is under your control, and thanks to the open-source nature of this project, you have a template to follow. There won’t always be a perfectly suited piece of hardware on the market, of course, as this elegant dual-drive Pi-based NAS build will attest.

Sometimes, you will want to power a device in a way it wasn’t designed for, and you might find that the device in question is way too tailored to the original power source. Today, [Oleg Kutkov] is here to give us a master class on excising unnecessary power conversion out of your devices, with the Starlink terminal as an example. This device can only be officially powered from 48V PoE, but can technically work from about 12V – and, turns out, many people want to mount a Starlink terminal to their cars.

[Oleg] shows us the power circuit of the Starlink terminal, explaining which component is responsible for what, and gives us a block diagram. Then, he shows you the 12V rail that all internal components actually draw power from, and where to feed power into it. Plus, he warns you about possible caveats, like having to disable the builtin 12V regulator to prevent it from backfeeding-induced damage. If you’re looking to modify a similar device, this tutorial gives you heaps of insight on what you might need on your foray.

Thinking to modify your own Starlink terminal, perhaps, and wondering about the power consumption? [Oleg] has current consumption graphs for you, collected with a data logger for Uni-T UT800 of his own design, providing detailed figures on just how much energy you ought to supply to power the terminal from 12V, and where to (not) get it. After all, even a seemingly suitable power supply might not do.