It’s fair to say that software-defined radio represents the most significant advance in affordable radio equipment that we have seen over the last decade or so. Moving signal processing from purpose-built analogue hardware into the realm of software has opened up so many exciting possibilities in terms of what can be done both with more traditional modes of radio communication and with newer ones made possible only by the new technology.
It’s also fair to say that radio enthusiasts seeking a high-performance SDR would also have to be prepared with a hefty bank balance, as some of the components required to deliver software defined radios have been rather expensive. Thus the budget end of the market has been the preserve of radios using the limited baseband bandwidth of an existing analogue interface such as a computer sound card, or of happy accidents in driver hacking such as the discovery that the cheap and now-ubiquitous RTL2832 chipset digital TV receivers could function as an SDR receiver. Transmitting has been, and still is, more expensive.
A new generation of budget SDRs, as typified by today’s subject the LimeSDR Mini, have brought down the price of transmitting. This is the latest addition to the LimeSDR range of products, an SDR transceiver and FPGA development board in a USB stick format that uses the same Lime Microsystems LMS7002M at its heart as the existing LimeSDR USB, but with a lower specification. Chief among the changes are that there is only one receive and one transmit channel to the USB’s two each, the bandwidth of 30.72 MHz is halved, and the lower-end frequency range jumps from 100 kHz to 10 MHz. The most interesting lower figure associated with the Mini though is its price, with the early birds snapping it up for $99 — half that of its predecessor. (It’s now available on Kickstarter for $139.)
There’s a sinking feeling when a firmware upgrade to a piece of equipment goes wrong. We’ve all likely had this happen and bricked a device or two. If we are lucky we can simply reapply the upgrade or revert to a previous version, and if we’re unlucky we have to dive into a serial debug port to save the device from the junk pile. But what happens when both those routes fail? If you are [Arko], you reverse-engineer the device and write your own bootloader for it.
The offending bricked object was a Monoprice MP Mini Delta 3D printer to which he was foolhardy enough to apply new firmware after seeing a friend’s machine taking it without issue. Finding the relevant debug interface on its main PCB he applied the firmware upgrade again, only to realise that in doing so he had overwritten its bootloader. The machine seemed doomed, but he wasn’t ready to give up.
What follows in his write-up is a detailed examination of the boot mechanism and memory map of an ARM Cortex M0 processor as found in the Monoprice’s STM32F070CB. We learn about vector tables for mapping important addresses of interrupts and execution points, and the mechanics of a bootloader in setting up the application it launches. This section is well worth a read on its own, even for those with no interest in bricked 3D printers.
In the end he had a working bootloader to which he appended the application firmware, but sadly when he powered up the printer there was still no joy. The problem was traced to the serial connection between the ARM doing the printer’s business and the ESP8266 running its display. After a brainstorm suggestion with a friend, a piece of code was found which would set the relevant registers to allow it to run at the correct speed.
So after a lot of work that resulted in this fascinating write-up, there was a working 3D printer. He suggests that mere mortals try asking Monoprice for a replacement model if it happens to their printers, but we’re extremely glad he persevered. Without it we would never have had this fascinating write-up, and would be the poorer without the learning experience.
We shouldn’t laugh, but we know the feeling very well. [Gear Down for What] invented a revolutionary transmission and fabricated it from scrap material when he was 16. Except he later found out the same design was the subject of a patent filed 14 years earlier. Dismayed he destroyed his prototype, but fast forward to today and he’s made a 3D model of a ratcheting continuously variable transmission. You can see a video of him explaining how it works below and put your own spin on the idea by grabbing the model from Thingiverse.
The model is just for demonstration purposes. We doubt it would wear well enough to use in practice but it’s great to get your hands on for a really intuitive understanding of the mechanism. Some modern automobiles use a continuously variable transmissions (CVT) and many recreational vehicles and motorcycles use them. Like any transmission, their job is to match the motor’s rotation to needed output torque and speed by offering different gearing ratios. Whereas a normal transmission provides a few fixed gears, a CVT changes seamlessly through a range of ratios.
Some of the design of the transmission is pretty tricky, like the cam adjustment. The video shows the rationale for how the design works and how it relates to tank steering (tank as in an Army tank; not like a gas tank). The model isn’t just plastic. It uses some screws and BBs, as well. However, if you have a 3D printer and wanted a good classroom demonstration, this is the ticket.
We’ve seen other geared variable transmissions for robots before. The planetary gears in the cam adjustment of this design are well understood. If you want to brush up your planetary knowledge, there’s no time like the present.