3D Printering: Adding A Web Interface Where There Was None Before

[Renzo Mischianti] got himself a Chinese 3D printer, specifically a FlyingBear Ghost 5. (Cracking name, huh?) He was more than a little irritated with the fact that whilst the controller, an MKS Robin Nano, did have a integrated Wi-FI module, it provided no browser-based interface for monitoring and control purposes. This seemed a bit short-sighted in this day and age, to say the least. Not being at all happy with that situation, [Renzo] proceeded to write dedicated Wi-Fi firmware using websockets, but not without fully documenting his journey in a detailed series of the blog posts.

The resulting BeePrint web interface supports all the usual functions you would expect when managing a printer, everything from monitoring warm-up at the prep stage, to keeping tabs on the potential spaghetti monster via the connected IP camera. All good stuff. [Renzo] used an ESP32-cam, which is a low-cost 2 MP unit from our friends at Olimex, but we suspect it wouldn’t vastly difficult to add your own IP camera into the mix.

[Renzo] has a YT channel detailing quite a few other projects, which is definitely worth some viewing time in our opinion.

We’ve been covering 3D printer hacking since the dinosaurs were roaming. This is the oldest, and still one of the strangest, posts that we could find in a quick search. Anyone care to find something older?

Continue reading “3D Printering: Adding A Web Interface Where There Was None Before”

Customisable Micro-Coded Controller Helps With In-Circuit Debugging

Over on Hackaday.io, [Zoltan Pekic] has been busy building a stack of tools for assisting with verifying and debugging retro computing applications. He presents his take on using Intel hex files for customised in-circuit testing, which is based upon simple microcoded sequencers, which are generated automatically from a high level description.

The idea is that it is very useful to be able to use an FPGA development board to emulate the memory bus component of the CPU, allowing direct memory access for design validation purposes. This approach will also allow the production of a test rig to perform board level verification. The microcode compiler (MCC) generates all the VHDL, and support files needed to target a Xilinx FPGA based dev board, but is generic enough to enable targeting other platforms with a little adaptation.

Another interesting use case enables in-circuit tracing of buggy memory accesses, with the microcode sequencer decoding the accesses and dumping the relevant information out to either a serial port, or even direct to an embedded VGA controller, hardware allowing.

This automated approach to generating customisable microcoded hardware is a very nice trick to have in your bag, and even if it only helps in certain circumstances, [Zoltan] notes that it at least serves as an interesting example of the architecture of computers from history, if not much else.

Source for the example 8085 project can be found on the project GitHub, and the toolchain source can found here also.

For an interesting practical use of microding to implement emulations of historical hardware, checkout this neat switchable reproduction calculator project.

Quantum Atomic Interferometer For Precision Motion Sensing

The current state of the art of embedded motion sensing is based around micro-electromechanical systems (MEMS) devices. These miracles of microfabrication use tiny silicon structures, configured to detect acceleration and rotational velocity in three dimensions. Accumulate these accelerations and rotations, and you’ve got a device that can find its orientation and track movement without any external waypoints. This is the basis of the technique of dead reckoning.

Why do we care about dead reckoning anyway? Surely GPS and related positioning systems are good enough? Above ground GPS is usually good enough, but underwater and underground this simply won’t work. Even heading indoors has a dramatic effect on the GPS signal strength, so yes, we need another way for some applications.

Right now, the current state of the art in portable sensors are MEMS devices, and you can get them for the cost of a hamburger. But if you want the ultimate in accuracy, you’ll want a quantum atomic interferometer. What that is, and how it will be possible to make one small enough to be useful, is half of the story. But first, let’s talk MEMS.

Continue reading “Quantum Atomic Interferometer For Precision Motion Sensing”

Tiny Switch Ornament Plays GIFs With An ESP32

It constantly amazes us what we hackers can build these days, (electronics shortages aside) we have access to an incredible array of parts, with specifications that only a few years ago would be bank-breaking and longer ago just fantasy. It’s nice to see people building one-offs just for fun, in spite of the current difficulties getting parts to actually be delivered. For example, check out this miniaturized Nintendo Switch created by [scottbez1] that plays animated GIFs from an SD card on tiny 1.14″ LCD display.

Obviously such a diminutive hack requires a custom PCB, which was a job for KiCAD. Armed with a 3D model of the LCD, the casing and PCB outline were drawn using Fusion 360. The PCB hosts a LilyGo ESP32 module for all the heavy lifting, with the WiFi adding some fun future capabilities not yet explored. The design is about as tight as it can get without pushing the limits of the PCB process too far, including a neat trick of sneaking passives inside the body of the SD card! That’s another space-saving idea we’ll be banking.

All-in-all a neat little hack, showing some good modelling and construction techniques and a good looking end result. Code for your reference may be found on the project GitHub, but as of writing the hardware design is not available.

Whilst this project shrinks the Switch, here’s one that goes the other way and super-sizes it, and if you have a switch lite but crave a little modern charging magic, then look no further than this Qi wireless charging hack.

Continue reading “Tiny Switch Ornament Plays GIFs With An ESP32”

OpenDog Version 3 Is Ready To Go Walkies

We’ve been following [James Bruton]’s open dog project for a little while now, and with his considerable pace of work – pandemic or no pandemic – development has been incredibly rapid. The latest milestone is the public release of version 3 (Video, embedded below.) This upgrade to the system adds 3D printed cycloidal gearboxes, removing the previous belt drives. [James] had immense fun tuning the motor controller parameters for these and admits they’re not completely dialed in yet. He notes that the wider gearbox body means that the robots geometry needed to change a little, and the previous belt-drive version may have a bit of an edge, but he’s confident he can make it work (and given his incredible previous robotics builds, we totally believe he’ll nail it!)

Silicone overmolding around a 3D printed former, using a 3D printed mould

Older versions struggled with slippery plastic feet; the advantage of a predictably smooth contact shape of a rounded foot is somewhat offset by the limited contact patch size, and that means not so much grip on some surfaces. [James] solution was obvious enough – just learn how to make 3D printed silicone moulds and cast a nice rubber foot around a plastic former, and problem solved! Unfortunately he neglected to add some recesses for a lever to get in between the mould halves, so it was a bit of a struggle to separate after curing. A beginner’s mistake that won’t be repeated, we’re sure.

Full source for openDogV3 is now available on the GitHub page. Here’s the playlist for the whole project, as well as direct links for the cycloidal drive development (part1, part2, part3.) But before you all go diving in to start 3D printing your own pooch, [James] tells us that the total cost would be around $2000 all in, with the bulk of that being the motors and ODrive units, so this one for the serious builder only!

We’ve covered robot dogs a fair bit, a particularly nice example is The Dizzy Wolf, and if you’re wondering just why on earth you’d want a robot dog, then Ask Hackaday has you covered as well.

Continue reading “OpenDog Version 3 Is Ready To Go Walkies”

ESP8266 Based WiFi Game Boy Cartridge Browses WikiPedia

[Sebastian Staacks] came across his old Game Boy and was wondering (as you do) what happened to recent attempts at getting a WiFi interface wedged into a standard cartridge. After a while the conclusion was that people had been scuppered by approaching the problem in a way that made it too hard. Obviously that meant it was necessary to follow through and build something, which is precisely what he did with his WiFi Game Boy Cartridge.

A trend lately has been to hook up a fast microcontroller to a bus, then move the whole interfacing shenanigans into software. This works fine in some circumstances, but for the GB interface, it’s not so easy. The GB is powered by the Sharp LR35902, running at a smidge over 4 MHz, but its machine cycle takes four clocks giving an instruction rate of only 1 MHz. The cartridge interface presents the raw CPU bus directly. This is both good and bad. It’s good, because it enables all kinds of expansion modules, like cameras, printers, and other custom peripherals, but it’s bad because the burden of interfacing with the CPU, at its full speed, lies squarely in the cartridge’s remit.

Rather than trying to hook this bus directly to a fast microcontroller, [Staacks] has taken a different approach; by decoding the address bus with discrete logic, it was easy to derive chip selects for an embedded ESP8266 as well as a socketed EEPROM. The clock for the former was also gated and sent into the ESP8266, generating an interrupt to wake it up. The EEPROM stores a simple application whose job is to present an OSD keyboard and send requests to Wikipedia, via the ESP8266 WiFi stack. The resulting text is then displayed on the 160×144 dot matrix display. The interrupt latency of the ESP8266 was mitigated by the application simply discarding the first data byte sent to it, and retrying the access. This way the ESP8266 could spend the majority of its time dealing with wireless duties, only pausing to swap a byte now-and-then with the application. A simple solution which appears to actually work! If you’re up for building one of these and writing your own applications, you can wander over to GitHub, clone yourself a copy and crack on!

We’ve seen a few attempts at doing this before, [davedarko] tried with this project, and if you search hackaday.io you’ll get loads of GB hacks to browse. Finally a recent twitter thread also points to another effort to do something similar with Wi-Fi, but development is still ongoing. We’ll check back later!

Continue reading “ESP8266 Based WiFi Game Boy Cartridge Browses WikiPedia”

A Well Documented BreadBoard Computer Shows Dedication

These pages have not been exactly devoid of home-built computers, with those constructed on solderless breadboard less frequent, but still not rarities. But what is more of a rarity is this ground-up 8-bit 74xx logic-based computer (video, embedded below) with full source, an emulator, assembler and test suite. [JDH] spent a solid couple of weeks working late into the night to build this, and the results show for themselves.

The new JDH-8 is now a figment of reality.

The architecture is a traditional 8-bit load/store microcoded processor with the microcode stored in easily programmable AT28C64 EEPROMs for ease of tweaking.  The address bus is 16-bits, which is quite ample for this, and puts it in line with (admittedly more sophisticated) 8-bit micros of old such as the 6502. There is also a hardware stack, and a discrete-logic ALU as well! Finally, since that wasn’t enough work already, he added in his own discrete logic video controller.

Wise people simulate before prototyping something like this

There are sixteen instructions covering memory access, ALU operations and I/O operations. One of the great things about this project is that [JDH] readily admits the mistakes made along the way, and how the architecture didn’t need to be this complex. One example is that hardware stack wasn’t really necessary as it could just have been implemented in software. Also, due to the implementation, memory accesses were so fast compared with the achievable cycle time, that there really was no point to using load/store architecture at all! Still, [JDH] had fun building and programming it!

It was interesting to see the use of LogiSim-Evolution to debug first a high level model of the architecture and then the translation into TTL chips. This scribe wasn’t aware of that tool (the shame!) but is going to try this out real soon.

All code for the software side of things can be found on the project GitHub. Perhaps the hardware design will appear there as well, be at the time of writing we couldn’t seem to find it.

Can’t get enough breadboard computers? (We can’t) check this out from last year. Stuck for a suitable enclosure for your latest bread breadboard computer? How about a bread bin.

Continue reading “A Well Documented BreadBoard Computer Shows Dedication”