RS485 is a communication standard that should be part of the advanced hardware hacker’s arsenal; it’s not commonly encountered, but powerful exactly when you need it. It’s a physical layer interface for wired communications that uses a single differential pair for noise immunity, has good long-distance properties, and allows many connections to a single bus. Because of that, you will encounter it in security systems and even cameras, wired sensor networks, DMX512 lighting and all sorts of industrial electronics. For our hobbyist goals, you can absolutely use RS485 to build your home (or room) automation system, or a relatively large robot – without all those worries that wireless brings.
The name might remind you of RS232, and that’s because both RS232 and RS485 are standards that come from EIA (Electronics Industries Alliance). It also might remind you of RS422, if you’ve ever seen this name mentioned online – RS422 and RS485 are closely intertwined, sharing most of the physical layer, and I’ll show how exactly they relate. Continue reading “Hacker Dictionary: RS-485 Will Go The Distance”→
[kmatch98] shares a quick hack with us over at Hackaday.io – a 3D-printed socket for Adafruit Stemma QT-based I2C modules. Since Adafruit has standardized the dimensions for their Stemma QT boards, it’s possible to make a socket that would fit many different sensors at once, where the board just slides in.
This reminds us of sci-fi datadisks, or, thinking of something more grounded in reality, game console cartridges – except that here, the fun you’re having is from exploring all the different devices you can get to speak I2C. To make such a socket, you only need to 3D-print two plastic parts, put a JST-SH plug between them, and screw them together – if you want to modify these to your liking, .f3d sources are available. Now you no longer have to use fingernails or tin snips to take the JST-SH plug out of your modules!
Today, we shall talk about how [Adam Bäckström] took a DS3225 servo and rebuilt it to improve its accuracy, then built a high-precision robot arm with those modified servos to show just how much of an improvement he’s got – up to 36 times better positional accuracy. If this brings a déjà vu feeling, that’s because we’ve covered his servo modifications before, but now, there’s more. In a year’s time since the last video came out, [Adam] has taken it to the next level, showing us how the modification is made, and how we ourselves can do it, in a newly released video embedded below.
After ordering replacement controller PCBs designed by [Adam] (assembled by your PCBA service of choice), you disassemble the servo, carefully setting the gearbox aside for now. Gutting the stock control board is the obvious next step, but from there, you don’t just drop the new PCB in – there’s more to getting a perfect servo than this, you have to add extra sensing, too. First, you have to print a spacer and a cover for the control board, as well as a new base for the motor. You also have to print (or perhaps, laser-cut) two flat encoder disks, one black and one white, the white one being eccentric. It only escalates from here!
TshWatch is a project by [Ivan / @pikot] that he’s been working on for the past two years. [Ivan] explains that he aims to create a tool meant to help you understand your body’s state. Noticing when you’re stressed, when you haven’t moved for too long, when your body’s temperature is elevated compared to average values – and later, processing patterns in yourself that you might not be consciously aware of. These are far-reaching goals that commercial products only strive towards.
At a glance it might look like a fitness tracker-like watch, but it’s a sensor-packed logging and measurement wearable – with a beautiful E-Ink screen and a nice orange wristband, equipped with the specific features he needs, capturing the data he’d like to have captured and sending it to a server he owns, and teaching him a whole new world of hardware – the lessons that he shares with us. He takes us through the design process over these two years – now on the fifth revision, with first three revisions breadboarded, the fourth getting its own PCBs and E-Ink along with a, and the fifth now in the works, having received some CAD assistance for battery placement planning. At our request, he has shared some pictures of the recent PCBs, too!
One day, [mitxela] got bored and decided to build his own HDMI monitor – the unconventional way. HDMI has a few high-speed differential pairs, but it also has an I2C interface used for detecting the monitor’s resolution and issuing commands like brightness control. In fact, I2C is the backbone for a lot of side channels like these – it’s also one of our preferred interfaces for connecting to cool sensors, and in this case, an OLED display!
[mitxela] describes his journey from start to end, with all the pitfalls and detours. Going through the pinout with a broken hence sacrificial HDMI cable in hand, he figured out how to probe the I2C lines with Linux command-line tools and used those to verify that the display was recognized on the HDMI-exposed I2C bus. Then, he turned to Python and wrote a short library for the display using the smbus bindings – and, after stumbling upon an FPS limitation caused by SMBus standard restrictions, rewrote his code to directly talk to the I2C device node, raising FPS from 2 to 5-10.
From there, question arose – what’s the best software route to take? He tried making a custom X modeline on the HDMI port the display was technically attached to, but that didn’t work out. In the end, he successfully employed the Linux capability called “virtual monitors”, and found out about an interesting peculiarity – there was no mouse cursor to be seen. Turns out, they’re typically hardware-accelerated and overlaid by our GPUs, but in [mitxela]’s case, the GPU was not involved, so he added cursor support to the picture forwarding code, too.
With partial refresh, the display could be redrawn even faster, but that’s where [mitxela] decided he’s reached a satisfactory conclusion to this journey. The write-up is a great read, and if videos are more your forte, he also made a video about it all – embedded below.
We first covered the ability to get I2C from display ports 14 years ago, and every now and then, this fun under-explored opportunity has been popping up in hackers’ projects. We’ve even seen ready-to-go breakouts for getting I2C out of VGA ports quickly. And if you go a bit further, with your I2C hacking skills, you can even strip HDCP!
We thank [sellicott] and [leo60228] for sharing this with us!
[Oleg Kutkov] decided to build a wideband SDR – for satellite communication research and monitoring, you know, the usual. He decided on a battery of HackRF boards – entire eight of them, in fact. Two 1×4 and one 1×2 RF splitters and an LNA on their combined RF input made for a good start to the project, and from there, it only got more complex.
HackRF boards can be synchronized with a separate clock source, but you can’t just pull a single clock line to all of them in a star configuration. Thus, he’s built a clock distribution and amplifier board, with 4 ns propagation delay at 1 PPS, and only 10 ns delay at 10 MHz. Then, he integrated that board with the HackRF setup, adding a case, wiring up a purpose-built cable and dealing with the reflections that occurred.
HackRF boards are USB 2.0 and able to generate a stream of data up to 320 MB/s, and there’d be no viable way to aggregate eight 2.0 links into one. To solve that, he’s used eight separate PCI-E to USB 3.0 cards, each of them with one HackRF plugged in, all connected to an AMD Ryzen 9-powered PC through PCI-E risers we typically see used for mining purposes. To tie it all together, he created a gnuradio flowgraph and patched the osmocom source block to enable the external clock synchronization mechanisms he decided to use.
Each HackRF is connected to its own PCIe USB card.
In the end, [Oleg] shows us some promising results – two DVB-S transceivers visible on the waterfall display of the spectrum capture. The work is not over here, to be clear – he’s ran into a few roadblocks. The gnuradio flowgraph doesn’t lend itself well to multi-threading, even on a Ryzen 9 machine, and [Oleg] pledged to rewrite the capture mechanisms in C++ which can be nicely allocated to separate physical CPU cores, something gnuradio is apparently not quite good at.
More importantly, the spectrum captured is not continuous, and [Oleg] questions whether it can be demodulated properly. He had to resort to frequency overlaps due to upsampling, and he’s not quite sure how to compensate for that. Overall frequency stability is also in question. However, from here, seems like most of the work towards building a wideband receiver is done!
[Oleg] is typically seen on Twitter, lately doing some heavy tinkering with Starlink – as Kyiv, the city he’s currently in, is under bombardment of Russian Armed Forces. We can only respect and appreciate the dedication. In January, we’ve covered his work on an USA-imported Tesla LTE modem replacement to fix LTE band incompatibilities in Ukraine, and his blog is a treasure trove of experiments that we are yet to properly comb through, from astrophysics and satellite work to RS485 networks and Linux driver writing.
Today’s Diminutive Device is a small castellated System-On-Module (Twitter link, nitter proxy) from [MangoPi] called M-Core, with a quad-core A53 CPU and 1 GB of RAM. As such, it’s very capable of running Linux, and even sports an HDMI output! Taking a closer look at the devboard picture, we can spot traces for three USB 2.0 ports, what seems to be two SDIO interfaces for MicroSD or WiFi cards, and an Ethernet MagJack with its termination network. This is a decent set of interfaces, rivaling what we’d expect out of a Pi Zero!
More importantly, this module is as small as an SD card itself – or as an OLED display that we hobbyists sprinkle onto our projects. Having power of Linux in such a small footprint is certainly something to behold! The back of the module is mostly flat, save for a few decoupling capacitors on the other side of the CPU – it seems, an Allwinner H616. On top of it, we can see the CPU itself, a small buck regulator and a DDR3 RAM chip, as well as tightly-packed passives. There’s even an unpopulated footprint for a DFN8 QSPI flash chip – with a lightweight enough OS build, you could perhaps dedicate your MicroSD card to storage only.
The devboard for uses the “FlexyPins”-like connectivity technique we’ve covered recently, and [MangoPi] say they bought those pins on TaoBao. We can’t help but be a bit amused at the thought of putting HDMI through such connections, but it seems to work well enough! Castellated modules like these are relatively easy to work with, so it shouldn’t be hard to literally pop this module out of the devboard and figuratively pop it onto your PCB. Next step is, reportedly, porting Armbian to this board, likely solving quite a few software support hurdles.
MangoPi have been posting updates on their Twitter page over the last few weeks, and, as it comes with the format, a lot of questions are left unanswered. Why does the devboard only show a single linear regulator of the kind we typically expect to deliver 1 A at most? Will we get higher-RAM versions? What’s the price going to look like? Will this module ever get to market? We can only hope, but if it does indeed, we are sure to see a few projects with these, whether it’s smart glasses, smart displays, phones, handhelds or malicious wall chargers. As usual, community makes or breaks an SBC, and we shall watch this one closely.
We thank [WifiCable] and [DjBiohazard] for sharing this with us!
