Have you ever found yourself in the need of a nine channel scope, when all you had was an FPGA evaluation board? Do not despair, [Miguel Angel] has you covered. While trying to make sense of the inner workings of a RAM controller core, he realized that he needed to capture a lot of signals in parallel and whipped up this 9-channel digital oscilloscope.
Continue reading “A DIY Nine Channel Digital Scope”
For this year’s Hackaday Prize, [will.stevens] is growing his own produce and now looks for a way to shield his endeavors from the perils of the British winter. To achieve this, he decided to grow vegetables in sealed containers. Inspired by prior art and backed up by research, his approach is a wild mix of applied laziness on one hand and reckless over-engineering on the other. The sealed containers in this project are PET bottles, chosen for their availability and the produce are carrots, mainly because they can be harvested through the bottle’s mouth. Carrots also feature a high energy density and can provide fibers for plant-based construction materials so [will] deems them ideal space colonist food.
The project is currently in its fourth attempt and somewhere along the road from carrot seeds, dirt and some water in a soda bottle to the current state, the setup sprouted artificial lighting and a CO2 sensor. Fully aware that sealed greenhouses are a proven concept, [will.stevens] provides links to literature one should read before attempting something like this, alongside regular updates on his progress.
With a sensor and LEDs already in place, it is just a matter of time until a raspi will be added. Or we might see the demise of the soil in favor of a hydroponic setup.
Outdoor navigation is a problem that can be considered solved for decades or maybe even centuries, depending on the levels of accuracy, speed and accessibility required. Indoor navigation and location, on the other hand, is a relatively new field and we are still figuring it out. Currently there are at least four competing technologies pushed by different manufacturers. One is ultra wide band radio and [Marco van Nieuwenhoven] shows us what a beacon using this technology is made of.
In his thorough tear down of an Estimote location beacon, he comes up with a complete parts list and schematics for each of the four PCB layers. The beacons are controlled by a Cortex M4 and feature Bluetooth radio in addition to the UWB part. They also come with a three-axis accelerometer, temperature, ambient light and pressure sensors and NFC capability. These boards combine a lot of functionality in a compact package and [Marco]’s stated intent is to create an open source firmware for them.
Hacking proprietary hardware, especially when doing so in public may get you in legal trouble, but in this case [Marco] has contacted the manufacturer, and the relationship seems to be friendly so far. Let’s hope it stays that way; these things look like a promising platform and may become a lower cost alternative to the evaluation kit running the same UWB radio we featured earlier. Alternatively you could ditch the UWB and use WiFi for indoor location.
Writing your own drivers is a special discipline. Drivers on the one hand work closely with external hardware and at the same time are deeply ingrained into the operating system. That’s two kinds of specialization in one problem. In recent years a lot of dedicated networking hardware is being replaced by software. [Paul Emmerich] is a researcher who works on improving the performance of these systems.
Making software act like network hardware requires drivers that can swiftly handle a lot of small packets, something that the standard APIs where not designed for. In his talk at this year’s Chaos Commnication Congress [Paul] dissects the different approaches to writing this special flavor of drivers and explains the shortcomings of each.
Continue reading “34C3: Roll Your Own Network Driver In Four Simple Steps”
Despite the presence of human drivers, modern cars are controlled by computers. In his talk at the Chaos Communication Congress [Guillaume Heilles] and [P1kachu] demonstrate the potential of taking control of a car’s computer. This of course leads to the natural conclusion of emulate an Xbox controller and using the car to play computer games.
His research was limited by the fact that the only cars they had access to were the daily drivers of different members of [P1kachu]’s family, which meant that all tinkering had to be strictly non-destructive. Despite this, they achieved impressive results and deliver a great introduction into reverse engineering.
[P1kachu] used a RasPi and an OBD-II adapter to access the car’s CAN bus and begins the presentation with a quick overview of the protocol. He then briefly touches on security measures that he ran into, which are optional and their implementation varies widely between manufacturers. His first attempt to access the CAN bus was successfully blocked by a challenge-response algorithm doing its work. His mother’s convertible however provided no such obstacles and gaining access allowed him to map the position of the steering wheel and pedals to a game controller, using the car to play video games.
After this, [Guillaume] steps in and walks us through the teardown of a gadget that plugs into the OBD-II port and claims to do amazing things for your car’s mileage by reprogramming the ECU. The device was not brand specific and after having seen the variations in the ways different manufacturers implement the protocol, [Guillaume] and [P1kachu] doubted that the gadget was capable of even holding the information required to modify every known implementation out there. Listening to the output of the device, along with a quick analysis of the circuit followed by decapping the single chip they found, showed that their doubt was justified. The lecture closes with an extended Q&A that adds more information on car hacking. Those that don’t have access to a car can instead tear down hot glue guns, doppler modules or antique calculators.
Continue reading “34C3: Using Your Car As Video Game Controller”
The feature of being easier to write than assembly is often seen as the biggest advantage of high-level programming languages. The other benefit that comes with them is portability. With high-level languages, algorithms can be developed independently from the underlying hardware. This allows software to live on once the hardware becomes obsolete.
The compiler was a concept that was met with resistance when it was first introduced. This was at a time when computers were custom-built machines bearing individual names like ENIAC, UNIVAC and Mark I. A time when the global demand for computers was estimated to be around five units by the CEO of IBM. In this scenario, it took a visionary to foresee a future where the number of computers would outgrow the number of programmers and hardware would evolve so much faster than software that a compiler would make sense. One visionary was [Grace Hopper].
Continue reading “Disrupting The Computer Industry Before it Existed: Rear Admiral Grace Hopper”
Linux audio may be confusing for the uninitiated. As a system that has evolved and spawned at least two independent branches over time it tends to produce results that surprise or irritate the user. On the other hand it is open source software and thus can be fixed if you know what you do.
Over at reddit [rener2] was annoyed by the fact that listening to music on his laptop was a significantly worse experience under Linux than under Windows. Running Windows the output of the headphone jack covered the whole spectrum while his Linux set up cut off the low end resulting in a tinny sound. The culprit in this is the sound card: it has two different output paths for the internal speakers and the headphone jack. The signal for the internal speakers is routed through a high pass filter to spare them the embarrassment of failure to reproduce low frequencies.
When headphones are plugged in, the sound card driver is supposed to make the sound card bypass the filter and deliver the full spectrum. The authors of the Windows driver knew this and had it taken care of. In his video [rener2] runs us through the process of patching the ALSA driver while referencing the documentation of a sound card that he deems ‘similar enough’ to his Realtek ALC288.
Continue reading “Fixing Linux Audio One Chipset at a Time”