Building your own sprinkler system controller isn’t that difficult on the face of it, but what happens when your system starts to grow, adding more distant areas? To tackle this, [Vinnie] leveraged the tried-and-true RS-485 differential pairs to communicate reliably with ever-more-spread-out valves on his farm’s irrigation system.
The system uses a Raspberry Pi to control when each valve turns on and for how long. It does this via a custom RS-485 valve master board, whose code and design files are on GitHub. The master board communicates with the Pi over I2C and issues RS-485 commands while controlling the 12V line to the valves. Toggling the 12V supply is a smart move it lets [Vinnie] save power by not keeping the valves energized when idle.
At the valves themselves lives a valve node board (also on the GitHub repo). Each node has a unique address so it knows when its name is called to open or close a valve. The valves are latching solenoids, ideal because they don’t require constant current during the watering cycle. The Valve Nodes also support their own protocol to report state, firmware version, and allow in-situ configuration.
Be sure to head over to [Vinnie]’s project page and check out all the work that went into this great DIY irrigation control system, along with the thoughtful boards and tools he made to help others set it up. This is a welcome addition to the sprinkler-related projects we’ve seen.
If you want to maximize the life of your lithium-ion batteries, proper storage voltage is critical. That is, don’t store them empty, and don’t store them completely full either. “Almost fully charged” is a sweet spot for occasional-use devices. Sadly, this is easier said than done. While many devices use integrated rechargeable batteries these days, most provide no method of limiting charge level. That’s where [DaverDavid]’s ChargeCap comes in.
By sampling charge current and disconnecting when it drops to 50 percent of peak, charging is reliably stopped when the target device is 80 to 90 percent charged, regardless of cell count or capacity.
ChargeCap sits between a USB charger and target device, disconnecting when it detects that recharging is 80 to 90 percent complete. This is particularly useful for maximizing the cell life of devices that see only intermittent use.
The way ChargeCap does this is clever, and relies on the fact that all lithium-ion charging curves look the same regardless of cell capacity or cell count. Charge current remains at pretty much the same level for most of the charging process, but tapers off quickly (and in a linear fashion) as cells approach their maximum capacity. That’s because charging a battery is a lot like blowing up a balloon: the first breaths are easy, but once the balloon fills out, every breath needs to push harder than the last.
ChargeCap works by sampling the peak charge current at the beginning of the charge cycle, then detecting when it drops below 50 percent of peak, at which point charging is stopped. The result is a device that reliably charges to 80 to 90 percent of capacity, and no more. ChargeCap uses an ESP32-C3 and a small OLED display that, as a nice touch, inverts colors to signal charge completion. Design files and code are at the GitHub repository.
The HP-41C analog on my phone gives the right answer.
Three resistors in parallel: 4.7 k,Ω 22 kΩ, and 3.3 kΩ. Quick! What’s the equivalent value? You can estimate it, of course, but if you want the actual 1.8 kΩ (approximately) answer, you probably reached for some kind of calculating aid. I have two slide rules on my desk, and plenty more a few steps away, but I don’t use them much, honestly. I have a very old HP-41C — arguably the best calculator ever made — but I am usually afraid to use it as it is almost 50 years old and difficult to repair. I also have an HP-28S on my desk, a replica HP-41C, and a few others in desk drawers. There are also dozens of calculators on my desktop computer, my phone –including the official HP Prime app — and the web browser.
I often see newer calculators from HP, like the Prime G2, or “new” HP-like calculators like the ones from SwissMicros, and think I should pick one up. Well, technically, HP licensed their calculators to Moravia, so even a “real” HP calculator isn’t from HP anymore. But, in the end, I always realize that my need for a physical calculator is so diminished that I can’t justify buying anything new, and I can barely even spring for a $10 one at the thrift store unless it is a real collectible.
Mind you, I’m not talking about RPN versus algebraic. I could say the same thing for TI, Casio, or Sharp calculators. I just don’t know why I need one anymore, even though I still, for some strange reason, want them.
The Prime seems impressive, if I could ever find time to finish reading the manual.
For the record, I did use an HP-41C to check the resistor math, but it was in the form of an app on my phone, not a real calculator. On the same computer I’m writing this on, I have HP-41C emulators, the Prime emulator, and a bunch of other calculators. Yet I still pick up my phone and use the familiar key layout of the HP-41C. I don’t know why. The replica 41C, unfortunately, has a landscape-oriented keyboard, so while I like it, it doesn’t satisfy my finger’s muscle memory.
Which leads to this Ask Hackaday. Do you use a calculator? Why? If you don’t, do you use a fake calculator on your phone or computer? Or do you just send your math to Google or Wolfram? I suspect some of the answer will be generational. I was in high school before calculators started showing up in schools, but they took over quickly.
There is something satisfying about having a purpose-built device to do your math. No long boot sequence. No switching apps. No messages coming in while you are typing in numbers. For the ultimate convenience, you could wear it on your wrist. The Apollo mission that docked with a Russian spacecraft carried an HP-65, and nine early Space Shuttle missions used an HP-41C. But even astronauts now don’t have a standard-issue calculator. Pilots sometimes use electronic E6Bs, but many still use the mechanical version.
Of course, I do collect slide rules, so maybe I just need to accept that calculators are yet another tech relic to collect. But someone is still buying them. I’d like to be one of them.
Most people love window shades, but many dislike the tedium of having to open and close them over the course of each day. While there are automation options here, if you’re in a rental place like [Rooster Robotics], then you’d prefer something less intrusive, as well as less cloud-bound. This is basically why he opted to build his own solution from scratch to open and close roller shades via Home Assistant.
The comments to the video helpfully point out that technically his point about there not being commercial options with a forced remote account ‘feature’ is false, as the Aqara Roller Shade Driver E1 for example is just a regular Zigbee device which can be used with a wide range of home automation ecosystems. That said, it’s always nice to have your own device that you fully control.
Of course, these devices are deceptively simple, as you still have to somehow know how far open the curtain is, which is also useful if you just want to open the curtain a certain amount. The other issue is the need to have the motor parallel with the wall unless you enjoy having a big wart sticking out from the wall.
Solving the first issue was attempted with a Hall effect sensor, and the second with angled gearing. With some refinements this led to a functioning design, allowing the development of a custom PCB with an ESP32-S3 module for WiFi control. In the final design the Hall effect sensor and magnets were replaced with an AS5600 magnetic rotatory position sensor that requires just one magnet and offers a much higher resolution.
Currently the design files are not available, but [Rooster Robotics] has indicated that they are looking at open sourcing the files in the future.
If you own a modern smartphone, there’s an excellent chance that its battery has run dangerously low on you at least a few times. Murphy’s Law dictates that this will naturally occur at the worst possible moment, say when you need to make an important phone call or when you’re lost and need to navigate home.
With this in mind, it’s not hard to see how a product like the ChargeTab would have a certain appeal. A small $10 USD device that you can keep in the car or pack in a bag that’s always available to charge your phone in an emergency.
Because it’s not meant to be used regularly — indeed it may never get used at all — it’s not completely unreasonable that such a device would only be good for one or two charges before its spent and must be replaced. It’s a bit like keeping a road flare in the car; it’s unlikely you’ll ever use the thing, but if you do, it only needs to work once.
But then what? According to ChargeTab, once the gadget has depleted its internal ~3,000 mAh battery it cannot be recharged and is no longer usable. Now to be fair, they specifically tell you to not throw it in the trash. They’ll send you a free return label to ship it back to them, at which point it will be refurbished and put back into circulation. The company argues that this recycling program, combined with the fact that the batteries inside the ChargeTabs were supposedly diverted from landfills in the first place, makes their entire operation eco-friendly.
Yet here we have a pair of ChargeTabs that were thrown in the regular garbage and would have taken a one-way trip to the local landfill if it wasn’t for the fact that I habitually dig through garbage cans like a raccoon. So let’s take a look at what’s inside one of these emergency phone chargers and if the idea is as green as the company claims.
The world of open source — and in particular open source licenses — is something we cover regularly here at Hackaday with respect to hardware and software, but it’s not so often we find open source data stories. Today’s case of the open British address data then is a bit of an outlier, but it may have implications for open source data further than British counties.
UK government data is released under the Open Government Licence, which is why we Brits can peer into all sorts of datasets our taxes paid for. This includes data from local government, so English counties release data sets of local addresses as part of their auditing of council taxes under the licence.
This is a picture of Barbra Streisand, the patron saint of unintended consequences.
[Owen Boswarva] has been collating these databases in order to produce a national open source address database, but has found himself at the receiving end of a legal threat from the Ordnance Survey, the UK mapping agency. They claim the data is theirs, not open.
British address data is in a sense open to all, in that there’s nothing to stop anyone walking down Acacia Avenue and noting the position of Number 1, Number 2, Number 3, and so on. This is what happened with OpenStreetMap worldwide, as people with GPS devices contributed their data and mapped the UK and everywhere else. The Ordnance Survey used to have a nice little earner charging top dollar for UK geospatial data which has been slashed by the arrival of OpenStreetMap, and we’re guessing that the prospect of losing another income stream to an open source equivalent has them worried.
The question of whether the councils should have released the data is one which will no doubt be settled at some point by the courts, and [Owen] goes into some detail on the subject in his analysis. There’s a good case to be made that the mapping agency are pushing it a little, but whatever the outcome it could set a dangerous precedent for open source data. We’ll keep you posted if there’s more on this story.
[Mellow_Labs] picked up a few LiDAR matrix sensors and found them very exciting. While a normal time-of-flight sensor can accurately determine a range, the matrix sensor is like an array of 64 sensors that can build a 2D map of distances from 2 cm to 3.5 m. [Mellow] wanted to add the sensor to his robot to help it see what was in front of it. You can see how it worked out in the video below.
The robot in question is Zippy, a 3D printed tank-like robot with an ESP32. By default, the robot requires control inputs, but using the sensor will enable autonomous operation. For good or ill, the sensor mounted to Zippy was seeing the floor with about half of the rows. That means about 50% of the data went to waste. However, we think having a robot be able to see the floor in front of it might be a good thing.
[Mellow] used an LLM to write most of the code, so there were a number of iterations required to get things working. This required decimating even more of the data from the sensor. Still, pretty impressive.
