Open Source Calculator Teaches Us About Quality Documentation

May 18, 2018 by Kerry Scharfglass 80 Comments

Graphing calculators are one of those funny markets that never seem to change. Standardized testing has created a primordial stew of regulatory capture in which ancient technology thrives at modern retail prices while changing little. The NumWorks calculator certainly isn’t the first competitor to challenge the Texas Instruments dynasty with a more modern interface (and a design from this decade), but behind it’s subtle color pops and elegant lines lies the real gem; a fantastically well documented piece of open source hardware. The last time we wrote about the NumWorks, it was to demonstrate a pretty wild hack that embedded an entire Pi Zero but it’s worth drawing attention to the calculator itself.

Hackaday readers traveling to the NumWorks website might spy the section at the bottom of the page titled “Developers” with tantalizing links like “Hardware,” “Software,” and “GitHub.” These lead to a wealth of knowledge about how the product is put together and sources to build the enclosure and firmware yourself (the PCB schematic and layout sources seem to be missing, though there is this handy gerber viewer). However merely posting sources is a low bar NumWorks far exceeds.

How is the firmware put together? Here’s a handy architecture guide! Why did they choose C++ and what tradeoffs were made to fit everything in a resource constrained embedded system? Here’s a design guide! How exactly does the math engine take in text, comprehend the expression contained therein, and evaluate it? There’s a document for it! There’s even a multi-platform SDK setup guide.

Firmware documentation is old hat; we’ve come to expect (or at least hope!) for it. For us the most interesting documentation is actually for the mechanical and electrical systems. The EE guides start with part selection (with datasheet links) then move on to walkthroughs of major areas of the schematic. At this point is should be no surprise that the board has pads for a completely standard 10 pin ARM debug connector and documented test points for UART, SPI, and an SD card.

The mechanical pages read like a quick primer on design for injection molding and tricks to reduce assembly errors (called “poka-yoke“). Ever wondered what that funny frame plastic models come in is called? The NumWorks calculator’s buttons are made in one, and it’s called a “sprue”. There are pages describing each piece of the housing one at a time.

Treat yourself to a reading of NumWorks’ excellent documentation. And if you need a new calculator, maybe consider the open source option.

Continue reading “Open Source Calculator Teaches Us About Quality Documentation” →

Five Steps To TensorFlow On The Raspberry Pi

May 18, 2018 by Al Williams 26 Comments

If you have about 10 hours to kill, you can use [Edje Electronics’s] instructions to install TensorFlow on a Raspberry Pi 3. In all fairness, the amount of time you’ll have to babysit is about an hour. The rest of the time is spent building things and you don’t need to watch it going. You can see a video on the steps required below.

You need the Pi with at least a 16 GB SD card and a USB drive with at least 1 GB of free space. This not only holds the software, but allows you to create a swap file so the Pi will have enough virtual memory to build everything required.

Continue reading “Five Steps To TensorFlow On The Raspberry Pi” →

Automatic MtG Card Sorter Separates Rags From Riches

May 17, 2018 by Kristina Panos 4 Comments

Like many of us, [Michael Portera] was an avid trading card collector as a kid. Also like many of us, life got in the way, and the collections sat ignored in boxes until our mothers threatened to get rid of them (or skipped the threat altogether and sold them at a garage sale for next to nothing).

[Michael] was recently reunited with his collection of Magic cards, which vary in value as much as baseball or any other kind of collectible card. Now that his Friday nights are otherwise occupied, he decided to sell them off. But first, he had to know how much they’re worth.

Manually sorting and pricing hundreds of cards would take longer than he’d like, so he built a sorter to automate the process. It takes a stack of MtG cards and uses servos and little tires to move them, one by one, into position. A short Python script runs the servos, tells a Raspi 3 camera take a picture of each one, and uploads it to Amazon AWS. Once the pictures are there, [Michael] uses a second script to grab the card title text from the picture and fetch the value through TCGPlayer’s pricing API.

This machine probably isn’t for purists or people with a bunch of originals and re-issues of the same card. We probably should have mentioned that he took out all the Black Lotuses and other obviously valuable cards first. Someone still has to assess the condition of each card, but at two seconds per card, it’s quite the time ~~twister~~ saver. Time Walk past the break to see it in action.

Tired of using dice or scratch paper for your life counter? Summon some Nixie tubes and make a cooler one.

Continue reading “Automatic MtG Card Sorter Separates Rags From Riches” →

DIY SSR For Mains Switching

May 17, 2018 by Anool Mahidharia 35 Comments

Typical power strips have their sockets tightly spaced. This makes it cumbersome to connect devices whose wall warts or power bricks are bulky — you end up losing an adjoining socket or two. And if the strip has a single power switch, you cannot turn off individual devices without unplugging them.

Planning to tackle both problems together, [Travis Hein] built himself some custom Dual SSR Controlled Socket Outlets for his workbench. He also decided to add remote switching ability so he could turn off individual sockets via a controller, Raspberry Pi, smartphone app or most ideally, a nice control panel on his desk consisting of a bank of switches.

The easiest solution for his problem would have been to just buy some off-the-shelf SSR or relay modules and wire them up inside his sockets. But he couldn’t find any with the features he wanted, and SSR’s were a little bit on the expensive side. Also, we wouldn’t have a project to write about – sometimes even the simple ones can show us a thing or two.

For starters, he walks us through a quick and simplified primer on figuring out thermal dissipation for the triacs which will be used on his boards. This is tricky since the devices are connected directly to utility voltage so he needs to take care of track clearances, mechanical separation as well as safety. However, for his first board prototypes, he did not add any heat sinking for the triacs, thereby limiting their use to low current loads. Since the SSR also needs to have a wide control voltage range, he describes how the two transistor constant-current input block works to limit opto-triac LED current over a range of 2 V to 30 V.

Before he moves on to his next prototype, [Travis] is looking for feedback to improve his design, make it safer, and figure out if it can pass safety protocols. Let him know via comments below.

Suitcase Computer Reborn With Raspberry Pi Inside

May 17, 2018 by Dan Maloney 48 Comments

Fun fact, the Osborne 1 debuted with a price tag equivalent to about $5,000 in today’s value. With a gigantic 9″ screen and twin floppy drives (for making mix tapes, right?) the real miracle of the machine was its portability, something unheard of at the time. The retrocomputing trend is to lovingly and carefully restore these old machines to their former glory, regardless of how clunky or underpowered they are by modern standards. But sometimes they can’t be saved yet it’s still possible to gut and rebuild the machine with modern hardware, like with this Raspberry Pi used to revive an Osborne 1.

Purists will turn their nose up at this one, and we admit that this one feels a little like “restoring” radios from the 30s by chucking out the original chassis and throwing in a streaming player. But [koff1979] went to a lot of effort to keep the original Osborne look and feel in the final product. We imagine that with the original guts replaced by a Pi and a small LCD display taking the place of the 80 character by 24 line CRT, the machine is less strain on the shoulder when carrying it around. (We hear the original Osborne 1 was portable in the same way that an anvil is technically portable.) The Pi runs an emulator to get the original CP/M experience; it even runs Wordstar. The tricky part about this build was making the original keyboard talk to the Pi, which was accomplished with an Arduino that translates key presses to USB.

As an aside, if reading this has given you a twinge of nostalgia and you’re on the Eastern seaboard you may want to check out more vintage gear at the VCF East this weekend. If you hail from Europe, get your hack on with CP/M and a retrocomputing badge at Hackaday Belgrade one wee from now.

We’ve seen the Raspberry Pi pressed into retrocomputing duty before, of course. Here’s one used to emulate a Commodore 1541 disk drive, and another in the laptop Clive Sinclair never built.

Continue reading “Suitcase Computer Reborn With Raspberry Pi Inside” →

No-Battery HD Video Streaming Does It With Backscatter

May 17, 2018 by Steven Dufresne 49 Comments

What if Google Glass didn’t have a battery? That’s not too far fetched. This battery-free HD video streaming camera could be built into a pair of eyeglass frames to stream HD video to a nearby phone or other receiver using no bulky batteries or external power source. Researchers at the University of Washington are using backscatter to pull this off.

The problem is that a camera which streams HD video wirelessly to a receiver consumes over 1 watt due to the need for a digital processor and transmitter. The researchers have separated the processing hardware into the receiving unit. They then send the analog pixels from the camera sensor directly to backscatter hardware. Backscatter involves reflecting received waves back to where they came from. By adding the video signal to those reflected waves, they eliminated the need for the power-hungry transmitter. The full details are in their paper (PDF), but here are the highlights.

On the camera side, the pixel voltages (CAM Out) are an analog signal which is fed into a comparator along with a triangular waveform. Wherever the triangle wave’s voltage is lower than the pixel voltage, the comparator outputs a 0, otherwise, it outputs a 1. In this way, the pixel voltage is converted to different pulse widths. The triangular waveform’s minimum and maximum voltages are selected such that they cover the full possible range of the camera voltages.

The sub-carrier modulation with the XOR gate in the diagram is there to address the problem of self-interference. This is unwanted interference from the transmitter of the same frequency as the carrier. And so the PWM output is converted to a different frequency using a sub-carrier. The receiver can then filter out the interference. The XOR gate is actually part of an FPGA which also inserts frame and line synchronization patterns.

They tested two different implementations with this circuit design, a 112 x 112 grayscale one at up to 13 frames per second (fps) and an HD one. Unfortunately, no HD camera on the market gives access to the raw analog pixel outputs so they took HD video from a laptop using USB and ran that through a DAC and then into their PWM converter. The USB limited it to 10 fps.

The result is that video streaming at 720p and 10 fps uses as low as 250 μW and can be backscattered up to sixteen feet. They also simulated an ASIC which achieved 720p and 1080p at 60 fps using 321 μW and 806 μW respectively. See the video below for an animated explanation and a demonstration. The resulting video is quite impressive for passive power only.

If the University of Washington seems familiar in the context of backscatter, that’s because we’ve previously covered their battery-free (almost) cell phone. Though they’re not the only ones experimenting with it. Here’s where backscatter is being used for a soil network. All of this involves power harvesting, and now’s a great time to start brushing up on these concepts and building your own prototypes. The Hackaday Prize includes a Power Harvesting Challenge this year.

Continue reading “No-Battery HD Video Streaming Does It With Backscatter” →

The Solid State Weather Station

May 17, 2018 by Anool Mahidharia 60 Comments

Building personal weather stations has become easier now than ever before, thanks to all the improvements in sensors, electronics, and prototyping techniques. The availability of cheap networking modules allows us to make sure these IoT devices can transmit their information to public databases, thereby providing local communities with relevant weather data about their immediate surroundings.

[Manolis Nikiforakis] is attempting to build the Weather Pyramid — a completely solid-state, maintenance free, energy and communications autonomous weather sensing device, designed for mass scale deployment. Typically, a weather station has sensors for measuring temperature, pressure, humidity, wind speed and rainfall. While most of these parameters can be measured using solid-state sensors, getting wind speed, wind direction and rainfall numbers usually require some form of electro-mechanical devices.

The construction of such sensors is tricky and non-trivial. When planning to deploy in large numbers, you also need to ensure they are low-cost, easy to install and don’t require frequent maintenance. Eliminating all of these problems could result in more reliable, low-cost weather stations to be built, which can then be installed in large numbers at remote locations.

[Manolis] has some ideas on how he can solve these problems. For wind speed and direction, he plans to obtain readings from the accelerometer, gyroscope, and compass in an inertial sensor (IMU), possibly the MPU-9150. The plan is to track the motion of the IMU sensor as it swings freely from a tether like a pendulum. He has done some paper-napkin calculations and he seems confident that it will provide the desired results when he tests his prototype. Rainfall measurement will be done via capacitive sensing, using either a dedicated sensor such as the MPR121 or the built-in touch capability in the ESP32. The design and arrangement of the electrode tracks will be important to measure the rainfall correctly by sensing the drops. The size, shape and weight distribution of the enclosure where the sensors will be installed is going to be critical too since it will impact the range, resolution, and accuracy of the instrument. [Manolis] is working on several design ideas that he intends to try out before deciding if the whole weather station will be inside the swinging enclosure, or just the sensors.

If you have any feedback to offer before he proceeds further, let him know via the comments below.