Hi-Fi hasn’t changed much in decades. OK, we’ll concede that’s something of a controversial statement to make in that of course your home hi-fi has changed immensely over the years. Where once you might have had a turntable and a cassette deck you probably now have a streaming media player, and a surround sound processor, for example.
But it’s still safe to say that hi-fi reproduction hasn’t changed much in decades. You can still hook up the latest audio source to an amplifier and speakers made decades ago, and you’ll still enjoy great sound.
Not so though, if instead of a traditional amplifier you bought an AV receiver with built-in amplifier and processing. This is a fast-moving corner of the consumer electronics world, and the lifetime of a device before its interfaces and functionality becomes obsolete can often be measured in only a few years.
To [Andrew Bolin], this makes little sense. His solution has some merit, he’s produced a modular open-source AV processor in which the emphasis is on upgradeability to keep up with future developments rather than on presenting a black box to the user which will one day be rendered useless by the passage of time.
His design revolves around a backplane which accepts daughter cards for individual functions, and a Raspberry Pi to do the computational heavy lifting. So far he has made a proof-of-concept which takes in HDMI audio and outputs S/PDIF audio to his DAC, but plans are in hand for further modules. We can see that this could become the hub of a very useful open-source home entertainment system.
The usual way of adding GPS capabilities to a project is grabbing an off-the-shelf GPS module, plugging it into a UART, and reading the stream of NMEA sentences coming out of a serial port. Depending on how much you spend on a GPS module, this is fine: the best modules out there start up quickly, and a lot of them recognize the logical AND in ITAR regulations.
For [Mike], grabbing an off-the-shelf module is out of the question. He’s building his own GPS receiver from the ground up using a bit of hardware and FPGA hacking. Already he’s getting good results, and he doesn’t have to futz around with those messy, ‘don’t build ballistic missiles’ laws.
The hardware for this build includes a Kiwi SDR ‘cape’ for the BeagleBone and a Digilent Nexus-2 FPGA board. The SDR board captures raw 1-bit samples taken at 16.268 MHz, and requires a full minute’s worth of data to be captured. That’s at least 120 Megabytes of data for the FPGA to sort through.
The software for this project first acquires the GPS signal by finding the approximate frequency and phase. The software then locks on to the carrier, figures out the phase, and receives the 50bps ‘NAV’ message that’s required to find a position solution for the antenna’s location. The first version of this software was exceptionally slow, taking over 6 hours to process 200 seconds of data. Now, [Mike] has improved the channel tracking code and made it 300 times faster. That’s real-time processing of GPS data, using commodity off-the-shelf hardware. All the software is available on the Gits, making this a project that can very easily be replicated by anyone. We would expect the US State Department or DOD to pay [Mike] a visit shortly.
It sounds like a challenge from a [Martin Gardner] math puzzle from the Scientific American of days gone by: is it possible to build a three-dimensional wooden box with only two surfaces? It turns out it is, if you bend the rules and bend the wood to make living hinge boxes with a laser cutter.
[Martin Raynsford] clearly wasn’t setting out to probe the limits of topology with these boxes, but they’re a pretty neat trick nonetheless. The key to these boxes is the narrow to non-existent kerf left by a laser cutter that makes interference fits with wood a reality. [Martin]’s design leverages the slot and tab connection we’re used to seeing in laser-cut boxes, but adds a living flex-hinge to curve each piece of plywood into a U-shape. The two pieces are then nested together like those old aluminum hobby enclosures from Radio Shack. His GitHub has OpenSCAD scripts to parametrically create two different styles of two-piece boxes so you can scale it up or (somewhat) down according to your needs. There’s also a more traditional three-piece box, and any of them might be a great choice for a control panel or small Arduino enclosure. And as a bonus, the flex-hinge provides ventilation.
In today’s digital era, we almost take for granted that all our information is saved and backed up, be it on our local drives or in the cloud — whether automatically, manually, or via some other service. For information from decades past, that isn’t always the case, and recovery can be a dicey process. Despite the tricky challenges, the team at [Museo dell’Informatica Funzionante] and [mera400.pl], as well as researchers and scientists from various museums, institutions, and more all came together in the attempt to recover the Polish CROOK operating system believed to be stored on five magnetic tapes.
Originally stored at the Warsaw Museum of Technology, the tapes were ideally preserved, but — despite some preliminary test prep — the museum’s tape reader kept hanging at the 800 BPI NRZI encoded header, even though the rest of the tape was 1600 BPI phase encoding. Some head scratching later, the team decided to crack open their Qualstar 1052 tape reader and attempt to read the data directly off the circuits themselves!!
The Subaru BRZ (also produced for Toyota as the GT86) is a snappy sportster but [megahercas6]’s old US version had many navigation and entertainment system features which weren’t useful or wouldn’t work in his native Lithuania. He could have swapped out the built in screen for a large 4G Android tablet/phone, but there’s limited adventure in that. Instead, he went ahead and built his own homemade Navigation system by designing and integrating a whole bunch of hardware modules resulting in one “hack” of an upgrade.
The system is built around a Lenovo 4G phone-tablet running android and supporting GPS, GLONASS as well as the Chinese BeiDou satellite navigation systems. He removed the original daughter board handling the USB OTG connection on the tablet, and replaced it with his version so he could connect it to his external USB board via a flat ribbon cable. The USB board contains a Cypress 4-port USB hub. One port is used as the USB HID device to allow external buttons for system control — Power, Volume Up/Down, Fwd/Rev, Play/Pause, and Phone Answer/Hangup. The second port is used as a regular USB input to allow connecting external devices such as flash drives. The third one goes to a reversing camera while the fourth port goes to a USB DAC.
The USB DAC is another hardware board by itself and also includes a Bluetooth module which integrates his phone’s audio and control functions with the on-board system. There’s also an audio mixer which allows him to use the phone audio without having to miss out on the navigation prompts from the tablet. Both boards also contain several peripheral circuits such as amplifiers and DC power supplies. Audio to the speakers is routed through six LM3886 based power amplifier boards. And the GPS module receives its own special low-noise amplifier board to ensure extremely strong reception at all times. That’s a total of ten boards custom built for this project. He’s also managed to source all the original harness connectors so his system is literally a snap in replacement. The final assembly looks pretty dashing.
For some strange reason, the Lenovo tablet uses 4.35V as the ‘fully charged” value for its LiPo instead of the more common 4.20V, so even with the whole system connected to a hefty 12V lead acid battery from which he’s deriving the 4.20V charging voltage for the tablet, it still complains about “low battery” — and he’s looking for advice on how he can resolve that issue short of blowing up the LiPo by using the higher charge voltage. Besides that, he’s (obviously a kickass) hardware designer and a little bit rusty on the software and programming side of things, for which he’s looking for inputs from the community. His introductory video is almost 30 minutes long, but the shorter demo video after the break shows the system after installation in his car. He’s posted all of his Altium hardware source files on the project page, but until he shares PDF versions, it would be difficult for most of us to look at his work.
The International Space Station, or ISS, has been in orbit in its various forms now for almost twenty years. During that time many of us will have stood outside on a clear night and seen it pass overhead, as the largest man-made object in space it is clearly visible without a telescope.
Most ISS-watchers will know that the station carries a number of amateur radio payloads. There are voice contacts when for example astronauts talk to schools, there are digital modes, and sometimes as is happening at the moment for passes within range of Moscow (on Feb. 14, 11:25-16:30 UTC) the station transmits slow scan television, or SSTV.
You might think that receiving SSTV would be hard work and require expensive equipment, but given the advent of ubiquitous mobile and tablet computing alongside dirt-cheap RTL-SDRs it is now surprisingly accessible. An Android phone can run the SDRTouch software defined radio app as well as the Robot36 SSTV decoder, and given a suitable antenna the pictures can be received and decoded relatively easily. The radio must receive 145.8MHz wideband FM and the decoder must be set to the PD120 PD180 mode (Thanks [M5AKA] for the update), and here at least the apps are run on separate Android devices. It is possible to receive the signal using extremely basic antennas, but for best results something with a little gain should be used. The antenna of choice here is a handheld [HB9CV] 2-element beam.
You can find when the station is due to pass over you from any of a number of ISS tracker sites, and you can keep up to date with ISS SSTV activity on the ARISS news page. Then all you have to do is stand out in the open with your receiver and computing devices running and ready, and point your antenna at the position of the station as it passes over. If you are lucky you’ll hear the tones of the SSTV transmission and a picture will be decoded, if not you may receive a garbled mess. Fortunately grabs of other people’s received pictures are posted online, so you can take a look at what you missed if you don’t quite succeed.
Even if you don’t live within range of a pass, it’s always worth seeing if a Web SDR somewhere is in range. For example this Russian one for the current transmissions.
In that you are using off-the-shelf hardware and software you might complain there is little in the way of an elite hack about pulling in a picture from the ISS. But wait a minute — you just received a picture from an orbiting space station. Do that in front of a kid, and see their interest in technology come alive!
When you are running a hackspace, network security presents a particular problem. All your users will expect a wireless network, but given the people your space will attract, some of them are inevitably going to be curious enough to push at its edges. Simply plugging in a home WiFi router isn’t going to cut it.
At Santa Barbara Hackerspace they use Unifi access points on their wireless network, and their guest network has a system of single-use codes to grant a user 24-hour access. The system has the ability to print a full sheet of codes that can be cut individually, but it’s inconvenient and messy. So the enterprising hackspace members have used a Raspberry Pi and a receipt printer to deliver a single code on-demand at the press of a button.
The hardware is simple enough, just a pull-up and a button to a GPIO on the Pi. Meanwhile the software side of the equation has a component on both client and server. At the server end is a Python script that accesses the Unifi MongoDB database and extracts a single code, while at the client end is another Python script that reacts to a button press by calling the server script and printing the result. It’s a simple arrangement that was put together in an evening, but it’s an effective solution to their one-time WiFi access needs.
It’s a temptation as a hackspace to view all of your problems as solvable in one go with the One Piece Of Software To Rule Them All, and as a result some spaces spend a lot of time trying to hack another space’s effort to fit their needs or even to write their own. But in reality it is the small things like this one that make things work for members, and in a hackspace that’s important.
Does your space have any quick and simple projects that have automated a hackspace process? Let us know in the comments.