Electronics – Triple Cities Makerspace, Inc.

Project Profile: Magic Wheelchair Costume

Members of the Triple Cities Makerspace recently completed the largest group project undertaken at the Space in quite some time, in collaboration with the Magic Wheelchair organization and an independent artist in Cortland, NY named Crystal Lyon. This project was the creation of a Halloween costume for a child afflicted with cerebral palsy, who lives with his family in Cortland. The child, Jacob Eldred, has never been able to take part in any Halloween festivities due to his condition, although he has always wanted to. His family contacted Magic Wheelchair, an organization which works with local artist, makerspaces, and families of children like Jacob around the United States to create costumes for disabled children according to the children’s preferences and interests, to see what could be done for Jacob. In turn, a Magic Wheelchair representative named David Vogel spoke with Crystal Lyon (as a prominent Cortland artist interested in such activities) and Erik Leonard (as the president of the nearest makerspace to Cortland) regarding the creation of a costume for Jacob; as Erik was then preoccupied with other TCMS affairs, he turned over the matter to long-time TCMS friend Amanda Truin, who acted as project lead and as a liaison between Jacob’s family, Crystal L., David V., and a variety of TCMS members who agreed to work with Amanda to create a costume for Jacob.

Following perusal of the costume-creation process documentation and personal profile of Jacob passed on by Magic Wheelchair, Amanda, Crystal, and Cliff Burger (TCMS vice-president) conducted a more in-depth interview with Jacob and his family regarding Jacob’s interests and likes/dislikes. As one of Jacob’s favorite TV shows is “SpongeBob SquarePants,” Amanda was inspired with the idea of creating a costume combining two iconic objects from the show (SpongeBob’s pineapple home and boatmobile), as it would be a visually striking costume that had not been done by any other Magic Wheelchair team project. This costume idea would incorporate sound clips from the show, LED lights, and feature colorful paintings and decorations evocative of the TV show. After Jacob and his family indicated their approval of this design idea, Cliff obtained measurements of Jacob’s wheelchair, including points where the costume could be attached to the wheelchair, and set about creating a CAD model of a basic structure for the costume.

Following this meeting and the creation of design models and sketches by Cliff and Amanda, they sat down with other TCMS members – including Erik and Ethan Bexley – to decide upon a timeline for construction of the costume and assign design or construction tasks to specific people. Ethan took the time to create a project in Asana (a work-management software
platform) to coordinate task assignments and management among the team members, as well as to facilitate the sharing of files pertinent to this project; this made organizing the initial stages of the project much easier than otherwise, especially when the initial timeline was shortened with the goal of completing the costume by the time of the annual Cortland Halloween parade.

The heart of the costume is its structure; this was a somewhat improvised affair based on Cliff’s design models, constructed with the goal of being strong yet lightweight and made from inexpensive and easily-obtainable materials. The structure of both the pineapple and boat portions of the costume is largely made of PVC pipe, lightweight foam sheets cut to size, and chicken wire, all held together with various adhesives, zip-ties, and screws. The pineapple even has an unexpected element in the use of a hula hoop to help form its rounded shape! Two major challenges encountered during the structural construction process were the organic shapes of the pineapple and boat, being non-conducive to construction with building materials intended for rectangular objects, and incorporating the mounting points assemblies of and access to the wheelchair into the structure in such a way that the costume could be attached / detached to and from the wheelchair with relative ease. These challenges were overcome using innovative construction techniques including bending PVC pipes into permanent curved shapes using a heat gun and sand dispersed inside the pipes to prevent excessive heat buildup in any one place, which would result in structural weaknesses, and making use of chicken wire as a structural element for the pineapple (as a pineapple is a very unconventionally-shaped structure). The makers even 3D printed fittings for the PVC pipes when conventional sizes would not work for what was needed. Many long hours were spent acquiring materials, assembling, and reworking the structure during this phase of the costume’s construction.

Preliminary boat structure (before additional bracing was added)

Both structures temporarily connected for fitment purposes

Pineapple structure being covered with foam

While the structure was being assembled, Adam Biener worked autonomously to devise the electronic circuitry and software used to provide LED lighting and sound effects for the costume. He created, tested, debugged, and reworked the circuits, controls, and software until it was fully functional, tailoring the sound effects used to Jacob’s specific preferences and creating a special control handle which Jacob could manipulate to activate the lights and sound effects. The electronics assemblies were mounted in the rear of the boat’s structure, and the LED lights were attached to the pineapple structure, with final wiring being done once the two structures were connected to one another. Enormous credit is due to Adam here for successfully undertaking almost the entirety of this portion of the project on his own, with some additional help from John Sheak.

Once the structures were largely complete, Amanda began decorating the pineapple and boat with help from several other TCMS members (credited at the bottom of this blog post). The pineapple and boat structures, each covered with foam, were sanded and painted with several layers of primer and paint, with the pineapple’s foam having been scored with knives to have the texture of an actual pineapple. Special painted highlights in lighter colors were added to various portions of the pineapple, and the scored foam was shaded to give it the appearance of depth and realistic coloring. Foam leaves were cut, shaped, and painted before being attached to the top of the pineapple, and plastic decorative vegetation resembling seaweed was
strewn around the leaves and top of the pineapple to give it the appearance of having been underwater for some time. Amanda painted the interior of the pineapple extensively with various floral and other TV show-appropriate decorations so that Jacob would have cool things to look at when inside the costume, and feel like he was inside SpongeBob’s “real” pineapple! Amanda and Crystal added a final painting element to the boat following the first fitting with Jacob’s family, as Crystal had been assigned the autonomous task of carving the logo for the show out of foam and painting it for the purpose of having an additional visual element on the sides of the boat as well as having some color to liven up the boat.

The pineapple structure, being scored and decorated

More decorating of the pineapple structure, and fitting the LED strips to the structure’s openings

Completion of the costume by the revised timeline was achieved after many long evenings and weekends by everyone involved. Amanda coordinated test-fitting of the costume to the wheelchair with the family and with help from Erik and Cliff; the costume was introduced to Jacob on the day of the parade, and it was attached to the wheelchair with Jacob inside the costume
before he and the family took part in the parade, accompanied by Amanda and Crystal. The costume won first place in the family costume category for the parade, which meant an enormous amount to the family as it was Jacob’s first time participating! The costume remained with the family afterwards; the pineapple was mounted over Jacob’s bed, and his favorite bean bag was put inside the boat as a place for him to watch episodes of “SpongeBob” in! Jacob and his family felt very cared for and happy as a result of all of this, which was the main overall goal of this project and of the Magic Wheelchair organization as a whole.

Assembling the costume supports on Jacob’s wheelchair

Securing the boat portion of the costume to the wheelchair

….and the costume has been assembled on the wheelchair!

Crystal and Amanda with Jacob in the finished costume, in the parade!

All in all, this was a very special project that ended up coming off very well for everyone involved despite the logistical, construction, and timeline challenges encountered along the way, and the lack of familiarity by various project participants with the kinds of design and construction tasks required of them. Special thanks to Amanda Truin for her mature and cool-headed project coordination and for the many long hours spent with every phase of the project, especially the painting and decorating portion; Cliff Burger for making accurate structural models and contributing to the costume’s structural construction, Ethan Bexley for organizing the project
efforts via Asana and for his invaluable contributions to the structure’s construction; and Erik Leonard for helping with every phase of the costume’s construction and handling logistics of costume transportation and setup. As well as these project members, the following members also helped out with ideas, construction, painting, logistics, and/or other work to make this project a success (sorted in descending alphabetic order of last name):

Eric Adler
Adam Biener
Zach Brown
Gary Alan Dewey
Bill Dikeakos
Leslie-Morgan Frederick
John Sheak
Stephen P. Welte

Photos supplied throughout this blog post are the property of and have been supplied by the various TCMS members and friends credited throughout the blog post. Please contact the TCMS board before using any of the photos here for any purpose outside of this blog post.

Project Profile: Access Control System (ACS)

Introduction

Access Control Systems (ACSs) are used by many organizations, whether commercial or non-profit, as a means of providing scalable access to facilities or systems with finer degrees of control and fewer physical management problems than keys. When Triple Cities Makerspace (TCMS) moved into the old Spool Manufacturing building in Johnson City, NY back in 2013, the board wanted to provide members with 24/7 access to the new facilities using RFID tags and a computerized tag management system, as opposed to making use of physical keys which are easy to lose and hard to track.

The first attempt at a homegrown access control project started with a single Arduino Atmega 2560 microcontroller board, a numeric keypad with a built-in RFID reader, and a circuit board of relays for controlling an electronic door lock. TCMS had all of this hardware at hand already, but no software to make the system actually work, and off-the-shelf systems weren’t really an option with the minimal budget available. Two then-new TCMS members, Adam Biener (a software developer / consultant) and Evil Jim Ulrich (an expert in, among many other things, Arduino and analog electronics), volunteered their skillsets to the board to make a fully-functioning access control system from the hardware just described and software created by Adam.

The first step in developing the ACS software was to figure out what TCMS really needed regarding access control capabilities. After thinking for a while and getting feedback from the TCMS board, it was decided that the ACS needed to have:

An easy way to add, remove, and edit the info of TCMS members
An easy to way to assign and re-assign RFID tags to a member
An easy way to enable or disable building access based on membership status, with membership status determined by whether or not the member in question has actually paid their dues
The ability to restrict access to certain tools that required basic usage and safety training, such as table saws and other large power tools; a member will get access to said tools when they complete the training

Phase 1: Initial Implementation with Door Access

Adam developed a PHP and MySQL-based web app to implement the requirements listed above which, in supplemented form, is still in use by TCMS to the present day. This app allows users to be added to the ACS, integrates with the TCMS billing system, and includes a way for Evil Jim’s Arduino code to query the user database and control the door lock based on the user-specific information retrieved from this database. The basic architecture of this system is shown in the diagram below:

At the center of this system is the MySQL database which maintains the user list, access rules, and some other settings. The web app allows a TCMS administrator (typically board members) to maintain and update this information. There is also a REST API layer that allows other devices (doors, tools) to authenticate users and enable other types of machine-to-machine communications; since tool access was part of the long term plan for the TCMS facilities, the ACS was designed to accommodate this functionality. A TCMS administrator can define a selection of “devices”, which may include a door or a tool, with each device having a different set of access rules that determines user-specific accessibility. Access to the TCMS main entrance requires a PIN and the scanned RFID tag, but tools only require use of the RFID tag. Finally, automated offsite backups of the ACS data were implemented to allow recovery from catastrophic failure, like a bad hard drive.

Implementing ACS functionality to the TCMS facilities’ main entrance was the highest priority in terms of system deployment, so Adam and Evil Jim started with that; following the usual round of hardware and software testing, the system was implemented on the TCMS front door, and has been in use ever since. Adam performed occasional software updates to make the system more reliable and the web app easier to use, especially on a smartphone, but the core functionality remains unchanged since this first deployment. When TCMS moved to its present facilities at 326 State St in Binghamton in 2015, the ACS proved easy to transplant; the server was physically moved, and the wiring and door lock were installed in the new main entrance. Once installation was completed and the server was powered up, the ACS software booted and worked without any problems.

Phase 2: Tool Access

Once other building renovations on 362 State St. had been completed, the TCMS board – which now included Adam as secretary – started discussing implementation of the ACS’ tool access functionality for several of the larger, more complex, and/or potentially physically dangerous tools in the TCMS facilities. As there are some security and user interaction considerations for tools which are not applicable to the door, a series of discussions were held to determine requirements for this system. The final requirements are as follows:

As the tool’s user has already entered their PIN on the main entrance keypad, there shall be no need to enter it again; the tool’s local access hardware is activated by scanning the user’s RFID tag
The system must check that the user is authorized to make use of the tool by accessing the user’s training information in the ACS via the scanned RFID tag; if the user is authorized, the tool may be turned on
When the user has finished making use of the tool, they must either press a “reset” button to lock the tool again or it must automatically reset and lock itself again after a period of inactivity; reducing the amount of effort needed to make use of the tool and the tool access hardware is crucial to having both items work well

ACS Implementation, Phase 2, with tool access

These requirements, in turn, raised additional questions:

How can these rules be enforced by the hardware as well as the software?
How is “inactivity” determined for a given tool?
How many tools should be secured this way?
Is there an off-the-shelf set of hardware that could be used? If so, would it work with the current door access control system?

Informal discussions with other Makerspaces were held by Adam to get outside perspective on design principles and implementations as part of this process. As with the original ACS, it was decided in the end to make use of off-the-shelf hardware for the physical component of the tool access functionality for reasons of budget, easy maintenance, and the ability to specifically design a system to fit the somewhat unique needs of a Makerspace. A short list of tools to be controlled with the tool access functionality was decided upon, and as all of these tools had been semi-permanently placed throughout the new TCMS facilities by this point, it was also decided to install the tool access hardware for each tool on the closest wall to the tool for the sake of maximizing space efficiency without resulting in potential usage hazards.

It was also decided during the design process for the tool access hardware to have screens on each hardware box, to display the status of the ACS with respect to the tool attached to that box. The amount of information displayed on the screen was deliberately kept minimal, for the sake of reducing user distraction while the tool is active. Built-in diagnostics for the tool access hardware is accessible only by specific users designated by the TCMS board, and includes general systems status and debugging info such as current draw (which is used to determine system inactivity).

The core of the tool access hardware is a Raspberry Pi Zero W, chosen because it offers the hardware resources necessary to implement the ACS functionality with respect to I/O ports and processing power at a price and power consumption level affordable by the Makerspace. The rest of the hardware was sourced as off-the-shelf components from suppliers such as AliExpress, Amazon, and DigiKey: LCD screens, RFID readers, Meanwell AC-to-DC power supplies to supply power to the tool access hardware, solid state relays and current clamps to control power to the associated tools, and some miscellaneous small electronics components.

Tool access electronics first working on protoboard

The tool access hardware was designed to remove power from the associated tool(s) altogether when the tool was inactive, to prevent any potential attempts at bypassing the ACS software to access the tool(s). Adam built a custom circuit to read the analog current value from the clamp and convert that current value to a voltage, before digitizing it to a value within a range of 2¹⁰ and feeding that value to the Pi via an SPI connection. The software implemented on the Pi checks that digitized current draw value against a predefined, tool-specific threshold, and if that value drops below the given threshold, the software disables AC power to the associated tool after a timed delay to ensure that the tool has entered an appropriate state of inactivity. The solid state relays are used to enable AC power to the associated tool once the ACS has verified that the user has had training with that particular tool.

Adam enlisted the help of two other TCMS members in the tool access system’s design process: San Nguyen to design and oversee the manufacturing of the PCBs for the tool access hardware’s custom circuitry, and Cliff Burger to design and fabricate the physical enclosures for the tool access hardware. San has worked in different capacities as a software and electrical engineer, but his background is in PCB design and fabrication, so designing and instigating the manufacturing of a relatively simple PCB layout based on Adam’s circuits and incorporating the Pi and other hardware listed above was easy for him. As is usual for such projects, it took a couple of design revisions following initial debugging to settle on a layout that worked well for the project, but the end product works well! The final PCB has the LCD screen in its center, with other components (the Pi, two LEDs, a reset button, the current-clamp circuitry, etc.) mounted on the PCB with a combination of through-hole and surface-mount techniques.

San used the PCB layout software PADS to create the PCB design on a 2-layer board, as he had experience with that software and could create the design quickly and easily with it. He chose PCBgogo.com to fabricate the boards, as they are able to produce PCBs of reasonable quality inexpensively and with a relatively quick shipping time of ~1 week. A couple of “build parties” were held at the Makerspace to assemble all of the PCBs with their components once the final revisions of the PCBs had arrived; Adam, San, Cliff, and several other board members (Erik Leonard, Samantha Cameron, and John Flinn) all participated in the assembly of these boards.

Front and back of the custom tool access circuit board

A fully populated board mounted in the first prototype. Still a few more connections to make…

Cliff’s contribution to this project as an experienced machinist and mechanical modeler was to create physical enclosures for the tool access hardware, which he did using a 3D CAD model he’d created in SolidWorks. Like the PCBs, the initial enclosure design required a couple of revisions to finalize following initial testing with the system’s electrical components, but these revisions were minor in nature and followed changes made to the PCB. Cliff chose ABS as the material for the enclosures for reasons of cost, electrical isolation, ease of machining, and ready availability. All of the hardware for the enclosures were chosen from off-the-shelf components readily available from suppliers like McMasterCarr or Fastenal.

SolidWorks model of tool access enclosure interior (sans wiring)

SolidWorks model of tool access enclosure exterior

Once all of the tool access hardware systems had been fully assembled and had Adam’s software downloaded to the Pis, the systems were wired in with their associated tools, mounted to the walls, and integrated via the Makerspace WiFi network with the ACS. Final testing of the installed systems has proven that they work reliably as intended with minimal intrusion to usage of their associated tools. The total cost per unit of the tool access hardware is estimated to be under $150.

Phases 3 & 4: Dust Collector Integration and Future System Upgrades

Following the installation of a dust collection system in the TCMS wood shop, Adam decided to integrate it into the ACS / tool access system. He designed and assembled a custom, one-off circuit which is attached to the relay outputs of all ACS boxes associated with specific wood shop tools. When the relay on one of these tools is activated by a user with the appropriate training logged in the ACS, this new circuit sends a signal to a second relay box connected to the dust collector’s power circuitry; the relay box then powers up the dust collector to remove the wood dust from the tool being used. This second relay box powers down the dust collector when the tool being used is deactivated through use of the reset button or when the tool access hardware’s inactivity timer times out.

Dust collection relay box, with inputs from the tool access units attached to various wood shop tools

Phase 4 of this project is intended to facilitate fine-tuning of the ACS and tool access system. One goal is to collect and analyze energy usage reports from each of the tools, via logs of which tools are used and for how long. The end goal here is to create a predictive failure analysis report via pattern analysis of the logged data for each tool, so that the TCMS board can plan for maintenance or replacement of tools or components therein. Cliff is also in the process of designing and fabricating custom silicone buttons be installed over the existing reset buttons in the tool access hardware units, to make the buttons easier to use and look more aesthetically pleasing. The PCB may be revised at some point to add a fuse between the power circuitry and the rest of the electrical components, to prevent power surges from burning out the test access hardware.

Overall this project has been an enormous success in terms of accomplishing the goals laid out by the TCMS board throughout its various stages of implementation and expansion! It is also a highlight in terms of collaboration by multiple TCMS members with various areas of expertise, and should serve the needs of the Makerspace for many years to come.

All photos, models, and diagrams courtesy of and property of Adam Biener, Cliff Burger, and Stephen P. Welte, and are used here with their permission.

APRS: More Cool Things You Can Do With Radio

I’ve recently acquired my amateur radio license (technical level) and joined the Binghamton Amateur Radio Association (BARA). BARA is based out of the Kopernik Observatory and Science Center, and among their fairly extensive collection of equipment is a 2 Meter Band Yaesu radio connected to a computer with a Terminal Node Controller (TNC), which performs digital repeating for their instance of APRS (Automatic Packet Reporting System). I worked on a project to migrate their current setup to a Raspberry Pi and tnc-pi based system , which meant that I got to learn about APRS!

APRS is a means of communicating real-time data using radio, such as weather information from weather stations, station/radio tracking via GPS (Global Positioning System) satellites, text messages, and more. The radio transmits a series of tones (which sound like a modem) to one or more digital repeaters, known as digipeaters, that take a radio signal broadcast from another station and re-transmit it to other stations. Some of these digipeaters may also be connected to the Internet to relay packets containing these signals over TCP/IP; such stations are called I-gates. You can see these stations and their positions on the website https://aprs.fi.

Stations can choose what icon is used to represent them on this website – e.g. a blue ‘wx’ icon indicates a weather station. Clicking on the station brings up current local information such as reported temperature, humidity, wind speed, etc. – all reported with radio!

A green star with a “D” in the center and a callsign usually indicates a digipeater station – i.e., a station that listens for packets and retransmits them to other stations. Clicking on the star brings up other information such as equipment used, comments, last active date/time, packet path, etc. If it is an I-gate, it may receive packets from the internet and retransmit them over radio, or vice-versa.

Some stations may use “cars/trucks/phone” as their icon to indicate mobile operation, where vehicles transmit GPS data indicating their current location to allow aprs.fi to track them. This method can also be used in high altitude weather balloons to aid in tracking them for recovery once they’ve landed! Sometimes mobile amateur radio operators give comments about what frequencies they are monitoring or talking on, to allow other operators to easily communicate with them.

There is a lot of other information on this website as well, including messages and raw packet data. Since these packets are relayed between repeaters without encryption, it is important to note that any messages/data transmitted in this fashion are not private; and, if the receiving station is not “online” (on the air), they will not receive the message.

So, what uses are there for APRS besides weather, position tracking, and finding other amateur radio operators to talk with? Turns out that there are a few interesting use scenarios. If an operator sends a message to the call sign “SMSGTE”, they can send a text message to any cell phone user! Or, if an operator sends a message to “EMAIL-2”, they can send an email to anyone! This means an amateur radio operator can send text messages and email without having cell phone service! There are even a few digipeaters on satellites and on the International Space Station (although as of this writing the ISS digipeater is not currently operational)!

I’m still learning a lot about radio and APRS, and all of the cool things you can do with them. If you’d like to learn more about APRS, please check out http://www.aprs.org/

Contact from the International Space Station! (aka “Selfies from Space”, part 2)

To celebrate Cosmonautics Day on April 12th, the International Space Station began transmitting slow scan tv images related to the Interkosmos project from April 11th-14th, using a Kenwood TM-D710 transceiver located in the Russian ISS Service module which broadcasted on the frequency 145.800 MHz. I found out about this event from an amateur satellite radio organization called amsat; and with my new interest in radio image reception, I planned to attempt to make contact with the ISS and decode some of these images.

I purchased a Baofeng UV-5R handheld radio capable of receiving radio transmissions on the specified frequency (which my SDR / antenna combo from part 1 of “Selfies from Space” could also receive, but was more unwieldy to use), and used a Sony voice recorder to record the transmissions. I could then play back and decode the transmissions with a program on my PC called mmstv, or an app on my phone called Robot36. While it is possible to decode the recorded transmissions in realtime, I preferred to record the transmission and then try different programs/settings to decode the recording. I also used a website called satview to look up times when the International Space Station would be overhead, as these intervals would be short in duration (around 6-8 minutes) and the transmission equipment on the ISS required a minute or two of rest time between sending images. This meant that I might have only captured part of one image and then the whole of another image, or the whole of one image then part of another one, depending on timing. Finally, I also struggled with radio interference, which resulted in some of the images I captured being fuzzy.

Below are some examples of images I decoded from the ISS during this radio event:

Finally, here is a video demonstrating decoding of one of these image transmissions using the App Robot36 on my phone (Note: you may want to turn your sound down if you are sensitive to certain noises).

I look forward to future events like this, and – if I set up a radio transmitter – maybe even getting the chance to talk to an astronaut!

Picture credits:

All photos provided and owned by Gary Dewey.

Project Profile: Selfies from Space

I’ve always been a space geek, interested in astronomy and cosmic travel. Recently I’ve become obsessed with a new space-related hobby – downloading images of the Earth as signals from weather satellites! I call this hobby “selfies from space” because the images are created in real-time; if the images’ resolution were greater and you had the ability to zoom in sufficiently, then you could see me standing outside with my antenna capturing the images.

I first became interested in this hobby because I had purchased a $20 RTL-SDR (Software Defined Radio) on a whim many months ago, and decided to finally make some use of it. I did some research online and found that it was possible to capture satellite downlink data using my radio with an antenna tuned to receive the correct radio frequency. This means that the legs or poles of the antenna must have a specific length in order to resonate or vibrate at the desired radio frequency. The principle behind this resonance is similar to the phenomena of a tuning fork: when a vibrating tuning fork is placed near a stationary fork, the stationary fork begins to vibrate at the same frequency as the vibrating fork. A simple antenna design I found online which would work for this purpose is called a V-dipole antenna (https://www.rtl-sdr.com/simple-noaameteor-weather-satellite-antenna-137-mhz-v-dipole/).

This antenna is a half wavelength design, which means each pole is as long as the quarter wavelength of the desired frequency. If we take the speed of light (300,000,000 meters/sec) and divide by the desired frequency (137,000,000 hertz), we get 2.1898 meters as the wavelength and .54 meters / 54 centimeters as the quarter wavelength. I bought some aluminum rods at the local Home Depot and cut them to the quarter wavelength in the TCMS metal shop; I couldn’t find a “Choc block” at Home Depot to tie the rods together, but I did find some aluminum grounding bars which worked as an acceptable substitute. I then mounted the grounding bars to a 2″x4″ piece of wood with 120º angle between each bar, inserted the cut rods into the bars, and attached a stripped piece of 50Ω coaxial cable between the grounding bars and my radio.

Finished Antenna:

The software which I use to control the radio and record the signals is called SDR#. You can download SDR# here as one package, complete with many useful plugins; you will also need to install drivers for the radio, using the installation guide linked here.

Most of the weather satellites that are available in our geographic region are sun-synchronous or polar orbiting, which means that the satellites “pass by” our location from horizon to horizon. There are also some geosynchronous weather satellites (synced with Earth’s rotation to seem stationary), but most of these are located near the equator and are out of range of my antenna. There is a very limited time to download signals from sun-synchronous satellites, as they are moving very quickly and are very far away – about 8-15 minutes per pass, and at an altitude of 520 miles above sea level. Therefore, we need to be able to predict when satellites will pass by our location so that we can be prepared to capture data from them ahead of time. There are several websites with satellite time/location data, as well as a program called Orbitron which has a few other useful features, such as frequency correction for the Doppler effect caused by the satellites moving across the sky relative to me as I receive data from it.

I have used this antenna and radio to download images from the following satellites: NOAA-15 (@ 137.620 Mhz), NOAA-18 (@ 137.9125 Mhz), NOAA-19 (@ 137.100 Mhz), and Russia’s Meteor M2 (@ 137.900 Mhz). The NOAA satellites use an AM (amplitude modulation)-based system called APT (Automated Picture Transmission) to encode its data transmissions. If you were to attach a speaker to my radio, you could hear beeping and clicking as the transmissions are received, similar to the way in which fax machines sound/work. APT data can be decoded with many programs, including APT decoder and WXtoIMG. These programs convert the APT data into line by line pictures, and also have various enhancement / filtering tools which can be used to manipulate or add additional data to the newly-generated APT photos, such as map overlays. These photos have 2 channels, one with an data from an infrared camera or filter, and another with data from a regular spectrum camera; they also contain telemetry data on the sides of each picture.

Here are a sampling of APT photos taken by the NOAA satellites whose transmissions I captured:

The Russian Meteor M2 satellite uses the LRPT (Low Rate Picture Transmission) method of data transmission. LRPT is modulated with something called quadrature phase shift keying (QPSK), which uses differences of phases in the carrier wave (0º, 90º, 180º, or 270º) in order to send 2 bits of data at a time. It can transmit photo data with higher resolution than can be accomplished with APT, but it also requires a larger frequency bandwidth and generates larger raw files. The signal doesn’t sound like anything intelligible, just a bunch of static. Nevertheless, when demodulated with a plugin for SDR# (which generates a .s file) and then decoded with an LRPT offline decoder, a higher resolution photo is created – as seen in the photos below. You’ll note that I get images only of geographic locations that have radio contact with the satellite (realtime scanning), and that there appears to be some black lines from missing data; some these are from signal loss, but some are caused by transmitter malfunctions from the satellite.

The satellite’s path indicated by a blue line (above), and the resulting image from that pass (below).

The meteor M2 photos are from 3 channels which, when combined, create a color photo (red, green, blue); but during night time passes, only black and white photos can be rendered (probably due to the lack of sunlight).

This project has been a fun way for me to learn more about space, satellites, weather, and radio. I was given the opportunity to give a speech at Rutger’s University for their Space Technology Association at Rutgers Club, which can be viewed at https://youtu.be/qZ1JNfDFjqo. At the end of the speech, I gave the club 2 antennas, 2 USB software-defined radios, and DVDs containing the software they’ll need to record and decode images on their own.

I’ve also started working on a related project: using a Raspberry Pi with an SDR, antenna, and some scripts to automate the data recording process so that I can capture and create satellite images while I’m at work or sleeping. I’m also researching methods of uploading the images to Twitter automatically – because capturing and creating images is cool, but doing that while getting sleep is awesome! 🙂

Picture credits:

All photos provided and owned by Gary Dewey, except for “Adam’s v-dipole.” Admin. RTL-SDR.com. 1 March 2017. Web. 18 April 2018.

Hacking Myself

Electronics and computer-based technologies are integrating into our society at an ever-increasing rate, and – despite the potential for them to be abused – I find myself excited at the possibilities of what can be achieved with the latest developments in those areas. I am especially fascinated with wireless technology. Unseen energy being utilized to accomplish various tasks using WiFi, Bluetooth, RFID and NFC. It’s like magic to me!

Our Makerspace uses RFID tags to control access to the building. To enter, you scan your tag, enter a PIN (personal identification number) which is verified against the list of access credentials on TCMS’ server, and upon verification a relay is energised to unlock the door. This system benefits the Makerspace in terms of both cost and administration, as RFID tags are cheaper than making keys for everyone and as their use gives the TCMS board the ability to track and monitor the level of activity at the Space. One day I accidentally locked my keys inside the building, and needed to wait to be “rescued” by another member of the Makerspace. I vowed that this would never happen again, and remembered that one of our other members had taken what some would say extreme measures to have an RFID chip implanted into his hand! I had been fascinated by the potential applications of this procedure, which include access controls like normal RFID tags. The RFID chip used is about the size of a grain of rice, and is sealed inside a glass enclosure.

I decided to take this idea a step further – I would get an RFID tag implanted in one hand, and an NFC tag implanted in the other hand.

The RFID chip was cheap (~ $10) and non-programmable; it contains a unique PIN, which I had entered into the TCMS access credentials system. I use this chip to gain access to the Makerspace now. It is in my right hand, so I “scan” my right hand at the door, enter the chip’s PIN, and voila – the Makerspace door opens. No more losing tags or keys!

The chip in my left hand is an NFC, or Near Field Communications, chip. This chip cost around $99 from DangerousThings (https://dangerousthings.com/shop/xnti/), and is programmable with my phone using the DangerousThings app (available through the Android apps store at https://play.google.com/store/apps/details?id=com.dangerousthings.nfc&hl=en); I have also found the NFC Tools app to be useful. I used this app to scan and program my chip to protect it against accidental locking, which would make it non programmable.

I have added my chip to the lists of access credentials on various trusted devices so that I can, for example, unlock my phone by scanning my tag (tapping my phone to the back of my hand). I have also used the NFC tools app to program my chip to carry my ‘vcard’, or virtual business contact card, which allows me to transfer my contact information (name, phone number, email address, etc. ) to someone else’s phone by tapping their phone on my hand! Unfortunately this will not work on iPhones, as Apple has restricted NFC functionality to be used exclusively with their iPay app; but Android phones permit it so long as their NFC functionality is enabled.

Building further on these basic applications, I’ve loaded a profile (script and data) onto my chip with a link to my resume, so that if you scan my tag it prompts you to download my resume from my website! So cool – I’d hire me! 😀 Finally, I’ve created and loaded another profile to save my personal emergency information (name, allergies, blood type, emergency contact info), which can be transferred to someone else’s phone in a similar way. I am considering getting some sort of tattoo to indicate the implant’s presence to emergency personnel; if anyone reading this has any ideas about how I should go about doing this, please let me know!

I feel like a spy with this kind of technology literally embedded inside of me! I am excited to see the future of implantable technology development and applications, and cannot wait for the day when I can pay for things by scanning my hand!

Picture References:

All pictures and videos provided and owned by Gary Alan Dewey, except for “Quarter and Transponder”. Dangerous Things. Dangerous Things. 4 March 2018. Web. 4 March 2018.