Automatically renewing Let’s Encrypt SSL Certificates on PythonAnywhere

Several months ago, I set up a small webapp using PythonAnywhere. It’s a really easy to use service and for small projects is hard to beat since there is so little setup. They even let you use Let’s Encrypt (albeit in a hackish way) for free SSL certificates!

The problem that I’ve run into is that due to the way Let’s Encrypt is set up on PythonAnywhere, there’s no easy way to configure an auto renewal. Usually, one would just set up a cronjob set to run every 3 months. This doesn’t work for two reasons: the first is that there _is no cron_ on PythonAnywhere, and the other is that you must manually email the PythonAnywhere staff when your certificate is actually updated and they do the “installation”. Multiple times now, I’ve forgotten to renew until someone came to me telling me that the site wouldn’t let them do anything because of an expired certificate.

I got sick of feeling dumb and wrote a simple Python script that automatically renews the certificate and sends an email to the PythonAnywhere staff letting them know that it’s ready to be installed.
It’s scheduled using the PythonAnywhere scheduled tasks, and even though it runs every day, the renewal itself only takes place when the certificate is set to expire within 29 days or less.

If this sounds like something that would be helpful, its on my GitHub page.

Apple’s ‘BatteryGate’: iPhone 6 Performance Before & After a Battery Replacement

I have an iPhone 6 (ūü¶ē, I know) and noticed an¬†incredible¬†performance hit when I upgraded to iOS 11. I had never seen such an awful change immediately after installing a software update; when I upgraded the phone to iOS 10, it actually got¬†faster that it was on iOS 9. I knew something had to be wrong but mostly just got used to the degraded performance.

When the Geekbench team discovered that Apple is clocking down older iPhones due to aging batteries, I immediately bought an OEM Apple battery to replace my old one. It was $14 on eBay. Politics aside (I’m not going to rant about whether or not it was right and just of Apple to reduce the performance without telling customers, since there are plenty of other hot takes on the issue itself), I would have happily bought a new battery if I had known that it was going to keep my phone running fast.

I promptly purchased Geekbench 4 and took an initial benchmark to compare with once I replaced the battery. For reference, my battery had just over 600 (!) cycles on it, 100 over Apple’s lifetime recommendation. Geekbench scored the phone at 1059 single-core and 1794 multi-core.


After replacing the battery I took another Geekbench benchmark.

In almost perfect agreement with Geekbench’s findings, my iPhone 6 performance increased by nearly 45% single-core, and just over 46% multi-core. Looking at it differently, the phone that I had been using was almost¬†fifty percent less¬†powerful (worse?) than the day it was bought. Unsurprisingly, it feels like a new phone and is very noticeably faster, especially when replying to iMessages or notifications on the lock screen.

Regardless of ¬†your opinion regarding Apple’s throttling of older phones, these results give users a serious reason to spring for a battery replacement.

Update: Apple has responded to this issue and is now providing $29 battery replacements for iPhone 6, 6s, and 7.

Liquid Cooling an ASUS GTX1070 with Using NZXT G12 GPU Cooler & Corsair H75

My buddy recently decided he wanted to watercool his Asus GTX1070. There’s only two real choices: the NZXT G12 bracket (which replace the stock cooler) and the Corsair HG10 N980. The HG10 isn’t actually made for the 10 series, but is apparently easily modified to clear the VRM caps using some power tools. The G12 claims full compatibility with 1070 series cards, so he went with that. He also picked up a Corsair H75 which is fully compatible with the G12 bracket.

After taking the stock cooler off, it was immediately clear that the VRM caps were going to interfere with the curved standoffs the G12 uses to mount to the card.

Nothing a little grinding can’t fix! With a file, some thin washers, and about 15 minutes, it’s easy to modify the G12 to fit this specific card. The main issue here is the flanged lip visible on the bracket below. It hits the top of the VRM caps.

We started by grinding the lip off using a metal file. This only took about 3 minutes; the brackets are relatively soft.

A bit of black sharpie afterward covered it up well enough (these two brackets aren’t visible once the cover is in place).

We also added some very thin washers between the bracket and the topside of the PCB to add the slight extra bit of offset needed to clear the caps. They’re no more than 0.5mm thick.

After making these two changes, everything fit just like it should. We added a thin ring of foam between the white bracket and the H75 to make up for the width the thin washers add, but I think you could get away without doing this.

That’s it! Note that when you’re putting this bracket on, with or without this mod, you should only tighten the thumbscrews until you see the card flex ever so slightly. Once you see this, back each thumbscrew off by about 1 full turn. The cooler¬†does not need to be pressed tightly against the die; over-tightening the cooler will put unnecessary strain on the PCB and components and can lead to premature failure of the card due to thermal cycling. It’s also possible to crack or damage the GPU die.

A few more pictures of the final product:

Downloading & Saving a Nest Cam Live Stream Using a Raspberry Pi + Debian Linux

Tonight, I stumbled on an interesting post on Reddit. It linked to two Nest Cams livestreaming the landfall of hurricane Irma from a Miami condo. I popped the streams open on my phone (the hurricane had not hit yet, and the sky was mostly clear) and thought about the fact that I was probably going to fall asleep before the power went out and killed the stream.

Being an incredibly good-looking and overconfident dweeb, I then thought about the fact that there’s got to be a good way to rip and save a Nest Cam livestream so that I could watch it tomorrow, maybe post a time-lapse, and gain all of the Karma. After all, its already been done with tons of other streams from various sites. It seemed like a decent Friday night hackathon in the making, and would at least solve the problem of me falling asleep lest I fail.

I decided I wanted something that was (1) automatic, and (2) running in the background so that I didn’t need to stay up all night or keep my computer on. I ran through the list of options in my head:

  1. Just stream them in a browser window and use screen capture (lame and fails both #1 and #2),
  2. Use one of the millions of Chrome or Firefox plugins that allows for saving of streams (extra lame and still fails #2),
  3. Use some sort of stream-ripping software built for Linux so I could load it on my always-running Pi (not lame, but impossible for me to find something that worked after looking for an hour or so), or
  4. Hack it and do it myself.

If you haven’t guessed already, I went with #4. I’m going to show you how I figured it out and how to do it yourself. This assumes some basic knowledge of Linux command line and shell scripting.

First thing first, I loaded one of the Nest Cam streams using the links provided on Reddit. The video livestream itself sits inside a Nest-branded HTML page that does this really annoying thing where it auto-pauses and pops over a Nest advertisement every once in a while. If I wasn’t going to rip it out already, I would have been sufficiently annoyed by this to figure out how to get to the base stream.

I poked around inside the page source using the Safari dev tools to see if I could find any obvious stream container or link, but didn’t see anything. I did find a more minimal stream that is formatted for Twitter but it still does the popover thing. Boo.¬†I also poked around in the javascript (warning: there’s a lot) to see if the stream was being lazy-fetched from any obvious source. Again, nothing. Boo.

I decided to use the Timelines tool to see what’s being loaded on the network. I recorded for a few seconds and saw what was clearly a periodic fetch taking place. There’s an XHR request going out approximately every 4 seconds. It’s loading a media_xxxxxxxx_123.ts file and a chunklist_xxxxxxxx.m3u8 file after each request. This is definitely an MPEG-2 stream, with the chunklist serving as a manifest for the media.ts file.¬†Bingo!

.m3u8 files are commonly used to define video streams, and so I knew I was on the right track. Right-clicking on the m3u8 file and choosing “Copy Link Address” and pasting it into the Safari address bar yielded a base-level video stream with no extra junk (*cough*) on top of it. It looks like Nest streams their livestream content from¬†or from (Both are currently using¬†Wowza Streaming Engine 4 Subscription Edition 4.7.1 build20635)

The next step was saving the stream using this URL. Time to break out the Pi! I figured I could use ffmpeg to do this, and after a quick google search, my assumptions were confirmed. This StackOverflow question gave me what I needed, except I wanted to ensure that the ffmpeg command was always running (in the event the stream broke up and was restarted, a network issue occurred, etc).

For those of you who just want to save a Nest Cam stream to disk using Raspbian/Raspberry Pi/Debian/Other Linux, this is the command that will do it for you (you need ffmpeg installed in order to use this): ffmpeg -i http://your_stream_chunklist_link.m3u8 -c copy -bsf:a aac_adtstoasc /path/to/output/file.mp4. For example, this is the command I used to save the stream I was watching to my home directory: ffmpeg -i -c copy -bsf:a aac_adtstoasc Stream.mp4

In order to make sure that ffmpeg was always restarted in case of any issues, I whipped up the following shell script (named to be run as a cronjob:

#make sure a process is always running.

now=$(date +%Y%m%d%H%M%S)
makerun="ffmpeg -i -c copy -bsf:a aac_adtstoasc /media/HDD/Stream_$now.mp4"

if ps ax | grep -v grep | grep $process > /dev/null
 $makerun &


The script checks to see if the ffmpeg command is running using ps ax¬†and grep. If it is, there is no need to start it, so it exits. If it isn’t, the script is started using the makerun¬†shell command. Note the $now¬†variable at the end of the filename: it automatically appends a puncuation-less timestamp to each video file, so that the previous file is not lost when ffmpeg is automatically restarted.

The last thing to do was to make the script executable using chmod +x¬†and add it to the crontab using crontab -e. I set it to run every minute (can’t miss any of the action!) using the following crontab:

# m h  dom mon dow   command
* * * * * /home/pi/

After saving the changes and waiting a minute, I saw the first video file pop up. After running for a few hours, the auto-restart was a great idea, because it’s kicked in several times (likely due to haphazard internet because there a HURRICANE).

Stay safe out there, Florida. It’s going to get crazy.

DIY LED Lighting for Fishtank/Aquarium Setups

I’ve got an older Marineland Eclipse 3 tank that needed a new CFL bulb (the old one was barely igniting, and the spectrum was all sorts of off). After looking into the cost for a new bulb from Mainland, I decided I would rather do a simple DIY LED upgrade than pay for the same underwhelming fluorescent bulb.

I purchased a 5M string of cool white LEDs from Amazon. They’re the 3528 size, 60 LED/meter. The important thing is that they’re the resin-coated waterproof variety. I went with the cool white for two reasons: the spectrum is better for underwater plants*, and as the resin heats and ages, it yellows slightly, making the light a bit more yellow, or warm.

I also had some of the double-sided reflective foam lying around from a previous project. Although you could do this upgrade without it, it makes for an even more light-efficient setup, as light reflected off of the water or bottom of the tank is reflected back into the tank.

The first step is to remove the previous lighting setup. The Marineland CFL bulb is held inside the hood with a few screws, so it’s easy to remove. Next, I sized out the reflective foam and glued it inside the hood using hot glue. ¬†It’s important to make cutouts for any hinged openings!

Next, I glued the LED strip in a “folded” pattern. This isn’t as clean as actually cutting the strip and taping them truly parallel, but it keeps the waterproofing intact and really reduced the amount of work needed. Soldering this waterproof strip takes a lot more work than you would think, so don’t do it unless you really need to. I used hot glue in addition to the adhesive backing on the LEDs since the adhesive isn’t super strong.

Finally (not pictured), I covered the LEDs with a few passes of packing tape and made sure everything was stuck down nicely. This isn’t required, but is a nice bit of peace of mind for when it’s all powered on. The LED strips are supposed to be waterproof, but an extra layer of protection keeping it away from the water in case the glue fails can’t hurt.

And that’s it! It looks great when it’s powered on, emits¬†way¬†less heat, and uses less energy than my expensive Marineland bulbs did. Not to mention that I can reduce the hours it’s on for, since the lighting is more efficient for plant growth.

*Tech-overload sidenote: Cool white LEDs are actually¬†not¬† emitting white light. They work by using a blue-emitting diode coated with a yellow/red coating (usually phosphorous-based) which, combined with the blue, looks white. Because of this, the spectrum of a “white” LED actually peaks highly in the blue (~450nm) with a broader peak in the red (~550-700 nm). It just so happens that the most important frequency for Chlorophyl A is right around 450nm, with a secondary peak around 700nm.

Analyzing the Performance of Acorns Investment Portfolios using Quantopian

I’ve been using Acorns, the app to “help anyone invest” for a little over a year, mainly as a curiosity. One common theme I’ve seen amongst Acorns users is the disappointment with the lack of returns throughout their usage. Simply searching “Acorns Returns” online brings up hundreds of posts (many of them,¬†uncoincidentally, occurring on r/investing*). While many chalk down to unrealistic users irritated¬†they haven’t seen their¬†investment quadrupling in value overnight, reading these posts¬†did¬†make me question: what historical data in regards to returns is available for the different Acorns portfolios?

Digging around, I quickly realized the answer was: not much.¬†Acorns itself publishes no info on the rate of returns of its various portfolios, which isn’t unexpected or surprising. Reading the accounts of other users doesn’t cut it for me,¬†since many of them bail after getting antsy or taking their first 2% loss. There’s another camp of users who claim they’ve seen some absurd rate of return (Bro, I’ve seen 65% since May!). What about portfolio statistics? Dreaming of reading¬†about portfolio volatility? Keep dreaming. Point being, tangible data is hard to come by.

Coincidentally, I’ve been playing around with Quantopian, an absolutely awesome python-based algorithmic investing framework and simulation/backtesting platform. Quantopian has access to stock metrics, such as price, volume, dividend/split info, etc, since January 3rd, 2002; Quantopian¬†allows users to backtest stocks and trading algorithms¬†using this data, in order to examine performance of various trading strategies. Somewhere along the line, I had the thought: “Why not just create each of¬†the Acorns portfolios and backtest them to analyze their performance?”. The data provided by these backtests¬†is generally so close to true performance for simple cases that any error is excusable.

Acorns allows users to choose a portfolio based on their risk tolerance and investing goals, all¬†ranging from “Conservative” to “Aggressive”. The five portfolios are really just different target allocations¬†in six ETFs: VOO, VB, VWO, VNQ, LQD, and SHY. The first four¬†funds are Vanguard ETFs and the last two are iShares bond ETFs. The portfolio distributions are shown below, with the Aggressive portfolio being shown on top and the Conservative portfolio on the bottom.


This is basically all the info required to build these portfolios within Quantopian. Each security in the portfolios is added to the trading list, and  a rebalance function is scheduled to run every day 1 hour after the market opens. In reality, the Acorns portfolio rely on new round-ups and contributions to keep allocations at the right percentages, but this method of simulation seems close enough. I also set the backtest to only hold long positions, and made sure the trading commissions were zero (so as to only focus on the portfolio performance, and not the Acorns fee breakdown). The entire algorithm is shown below.

Attempts to model the Acorns Agressive Portfolio for performance modeling.
Backtesting is limited to September 10, 2010 (first trade day of $VOO).
Acorns keeps allocations exact by purchasing fractional shares. Since this isn't generally possible, a larger initial capital must be used (>$10K).

def initialize(context):
 Called once at the start of the algorithm.
 # Each security in the ETF along with the target percentage
 context.voo = (sid(40107), 0.14) 
 context.vb  = (sid(25899), 0.25) 
 context.vwo = (sid(27102), 0.20) 
 context.vnq = (sid(26669), 0.30) 
 context.shy = (sid(23911), 0.05) 
 context.lqd = (sid(23881), 0.06) 
 context.security_list = [context.voo, context.vb, context.vwo, context.vnq, context.shy, context.lqd]
 # Rebalance every day, 1 hour after market open.
 # In reality, the Acorns app banks on additional buys 
 # To keep the allocations correct.
 schedule_function(rebalance, date_rules.every_day(), time_rules.market_open(hours=1))
 # Fees are zero, if you're on the "student plan". 
 set_commission(commission.PerShare(cost=0, min_trade_cost=0))
def rebalance(context,data):
 Execute orders according to our schedule_function() timing. 
 for security in context.security_list:
   #rebalance to target percentage
   if data.can_trade(security[0]):"Rebalancing %s to %s percent" % (str(security[0]), str(security[1])))
     order_target_percent(security[0], security[1])

The only thing that changes between each of the Acorns portfolios is the target percentages. Everything else remains constant, which makes backtesting and examining the different portfolios incredibly easy. Three backtest start dates were chosen: September 10th, 2010, September 10th 2014, and October 8th 2015. Each backtest ended on the same date: October 7th 2016. The returns (%) for each backtesting window are summarized below.


Upon first look, it appears that the returns are reasonable and on par for each portfolio description, and I can confirm that the returns are very close to the actual returns I’ve experienced during my usage of the app over the last year. Returns diminish fairly monotonically from aggressive to moderate as one would expect.

There’s a catch though: I didn’t include the S&P500 benchmark performance in the results.


In all the backtest windows, the S&P500¬†destroys the Acorns portfolios. Suddenly, the 10.57% short term return doesn’t seem so great after realizing the S&P500 did almost 13 percent in the same year. Take a look at the Quantopian backtest results for the¬†aggressive portfolio, the best-performing one of the bunch, over the last year.


The portfolio almost exclusively underperforms the S&P500 in terms of returns. It’s also worth nothing that the drawdown during the January-Feburary time period of 2016 is worse than that of the S&P500 as well.

At this point, the logical thought is “Of course the drawdown sucks, because this is the¬†Aggressive portfolio.” And you’d be partially right. Take a look at the results for the conservative portfolio during the same time period:


The drawdown during the same period is¬†hardly better¬†than the S&P500, which fell over 3% from the starting point in the beginning of October 2015. Rather disappointing, given that the portfolio is billed as a “safer bet” option for investors. The backtest results over the last year of¬†all five portfolios are given below, for anyone interested.

screen-shot-2016-10-09-at-1-16-59-am screen-shot-2016-10-09-at-1-40-41-am




My final thoughts? It’s not that these portfolios are¬†bad. They’re decent portfolios, especially for beginning investors who are looking to stash away a few pennies here and there with minimal effort and a simple fee structure. Is a 6-10% return better than holding onto a pile of cash and losing out to inflation? Absolutely!¬†An Acorns portfolio serves as an excellent “baby’s first investment”. I just can’t help but shake the disappointment that all five¬†portfolios have underperformed the market in most, if not all, previous financial circumstances. For anyone beyond the novice saver/pocket-change investor, it makes more sense to¬†invest wisely in a few basic¬†ETFs (i.e.¬†NOBL/UPRO)¬†and call it a day. A true zero-fee investment experience can be had by using Robinhood, potentially saving the $1 per month fee. Smart savers who appreciate the auto round-up¬†feature of Acorns can enjoy Wealthfront‘s auto-deposit feature with the added benefit of Tax-Loss harvesting.

Do you have thoughts on my analysis of these portfolios or my backtesting strategy? Let me know in the comments. I appreciate reader input.

*r/investing deserves a post of its own. Similar to r/fitness, the¬†“beginners pretending to be experts” culture leads to an unsurprising amount of¬†awful advice. Trust the internet at your own risk. Trust the internet with investment guidance at your bank account’s risk.

Adding a buzzer beeper to the Illuminati32/Tarot Naze 32 Flight Controller

My buddy just bought an Illuminati32 FC board from Hobbyking for his new ZMR180 miniquad. The board is pretty sweet: Naze32, MWOSD, 35x35mm form factor, and only 20 bucks (on sale). It was really easy to set up, especially with the ZMR180 PDB that Diatone is shipping.¬†The biggest problem is that¬†there’s no buzzer output! A buzzer driver is one basic necessity every flight controller should come with. Low battery, lost models, and mode change beeps are pretty crucial to the operation of these miniquads. Luckily, it’s relatively simple and very cheap to add one onto this board. You’ll need:

  • High gauge (>30) wire
  • Fine solder and a fine-tipped soldering iron
  • An NPN BJT (2N3904, BC557, etc)
  • A 100ő© resistor
  • Heatshrink tubing or tape

The built-in Naze32 (rev5 or greater) buzzer driver is a NPN¬†transistor used in an open-collector configuration. There is a base resistor on the order of 100ő© used to set the drive current. PA12, or Pin 33 of the STM32 is used to drive¬†the BJT.


It’s possible to do this BEAM style, with¬†SMT components and a small piece of protoboard, or even a with small PCB (perhaps from OSHPark). We chose to do it with a little PCB that’s also got an ATTiny84 on it which controls some RGB led strip.


The hardest part of this is soldering onto the STM32, since PA12 isn’t broken out or used for anything else. See the below image to find the pin you need to solder to. Note that the text on the STM32 isn’t guaranteed to be upright, so look for¬†the pin 1 marker!!!


You’ll need some fine gauge wire (30 gauge wire wrap wire worked well), a fine-tipped soldering iron, and a steady hand.


Once the solder connection is made, don’t hesitate to dump some hot glue onto the connection to keep it from being broken loose. Once you’ve got the connection to PA12, solder one end of the¬†100ő© resistor to the PA12 wire, and the other to the base of the BJT. Solder the positive lead of your buzzer to the flight controller’s 5V input, and the negative lead of the buzzer to the collector of the BJT. Finally, solder the emitter of the BJT to ground. Be sure to wrap everything in heatshrink or tape so that you don’t accidentally short anything out.

That’s all there is to it! Just plug in a battery without turning on the transmitter and the FC should issue the “no connection” beep if everything worked.

Eachine H8 Quadcopter Custom Firmware Rates/Settings

I recently flashed my new Eachine H8 with some custom firmware (Silver13’s CFW, to be particular) and I spent some time tuning it to be flyable in acro mode with the stock remote. Overall, I think this firmware is super cool and really strokes my roots as a hardware engineer and reverse engineer. Not to mention, it flies as good or better than the stock firmware and is tons of fun to tinker with! Here’s my config.h file, for those who might be interested in a good place to start:

//config.h, edited by jaygreco

#include "defines.h"

// rate pids in pid.c
// angle pids in apid.h ( they control the rate pids)
// yaw is the same for both modes

// not including the "f" after float numbers will give a warning
// it will still work

// rate in deg/sec
// for low rates ( acro mode)
#define MAX_RATE 180.0f
#define MAX_RATEYAW 200.0f

// multiplier for high rates
// devo/module uses high rates only
#define HIRATEMULTI 3.0f

// max angle for level mode (in degrees)
// low and high rates(angle?)
#define MAX_ANGLE_LO 35.0f
#define MAX_ANGLE_HI 55.0f

// max rate for rate pid in level mode
// this should usually not change unless faster / slower response is desired.
#define LEVEL_MAX_RATE_LO 360.0f
#define LEVEL_MAX_RATE_HI 360.0f

// disable inbuilt expo functions
//#define DISABLE_EXPO

// use if your tx has no expo function
// also comment out DISABLE_EXPO to use
// -1 to 1 , 0 = no exp
// positive = less sensitive near center 
#define EXPO_XY 0.6f
#define EXPO_YAW 0.25f

// Hardware gyro LPF filter frequency
// gyro filter 0 = 260hz
// gyro filter 1 = 184hz
// gyro filter 2 = 94hz
// gyro filter 3 = 42hz
// 4 , 5, 6

// software gyro lpf ( iir )
// set only one below
//#define SOFT_LPF_1ST_023HZ
//#define SOFT_LPF_1ST_043HZ
//#define SOFT_LPF_1ST_100HZ
//#define SOFT_LPF_2ND_043HZ
//#define SOFT_LPF_2ND_088HZ
//#define SOFT_LPF_4TH_088HZ
//#define SOFT_LPF_4TH_160HZ
//#define SOFT_LPF_4TH_250HZ

// this works only on newer boards (non mpu-6050)
// on older boards the hw gyro setting controls the acc as well

// Headless mode
// Only in acro mode
// 0 - flip 
// 1 - expert
// 2 - headfree
// 3 - headingreturn
// 4 - AUX1 ( gestures <<v and >>v)
// 5 - AUX2+ ( none )
// 6 - Pitch trims
// 7 - Roll trims
// 8 - Throttle trims
// 9 - Yaw trims
// 10 - on always
// 11 - off always

// rates / expert mode
// 0 - flip 
// 1 - expert
// 2 - headfree
// 3 - headingreturn
// 4 - AUX1 ( gestures <<v and >>v)
// 5 - AUX2+ ( none )
// 6 - Pitch trims
// 7 - Roll trims
// 8 - Throttle trims
// 9 - Yaw trims
// 10 - on always
// 11 - off always
#define RATES 1

// level / acro mode switch
// CH_AUX1 = gestures
// 0 - flip 
// 1 - expert
// 2 - headfree
// 3 - headingreturn
// 4 - AUX1 ( gestures <<v and >>v)
// 5 - AUX2+ ( none )
// 6 - Pitch trims
// 7 - Roll trims
// 8 - Throttle trims
// 9 - Yaw trims
// 10 - on always
// 11 - off always

// channel to initiate automatic flip

// aux1 channel starts on if this is defined, otherwise off.
#define AUX1_START_ON

// use yaw/pitch instead of roll/pitch for gestures

// comment out if not using ( disables trim as channels, will still work with stock tx except that feature )
#define USE_STOCK_TX

// automatically remove center bias ( needs throttle off for 1 second )

// throttle angle compensation in level mode
// comment out to disable

// enable auto throttle in acro mode if enabled above
// should be used if no flipping is performed
// 0 / 1 ( off / on )

// enable auto lower throttle near max throttle to keep control
// comment out to disable

// options for mix throttle lowering if enabled
// 0 - 100 range ( 100 = full reduction / 0 = no reduction )
// lpf (exponential) shape if on, othewise linear

// battery saver ( only at powerup )
// does not start software if battery is too low
// flashes 2 times repeatedly at startup

// under this voltage the software will not start 
// if STOP_LOWBATTERY is defined above

// voltage too start warning
// volts
#define VBATTLOW 3.5f

// compensation for battery voltage vs throttle drop
// increase if battery low comes on at max throttle
// decrease if battery low warning goes away at high throttle
// in volts
#define VDROP_FACTOR 0.60f

// voltage hysteresys
// in volts
#define HYST 0.10f

// enable motor filter
// hanning 3 sample fir filter

// clip feedforward attempts to resolve issues that occur near full throttle
//#define CLIP_FF

// motor transient correction applied to throttle stick

// motor curve to use
// the pwm frequency has to be set independently
//#define MOTOR_CURVE_6MM_490HZ
//#define MOTOR_CURVE_85MM_8KHZ
//#define MOTOR_CURVE_85MM_32KHZ

// pwm frequency for motor control
// a higher frequency makes the motors more linear
//#define PWM_490HZ
//#define PWM_8KHZ
#define PWM_16KHZ
//#define PWM_24KHZ
//#define PWM_32KHZ

// failsafe time in uS
#define FAILSAFETIME 1000000 // one second

// level mode "manual" trims ( in degrees)
// pitch positive forward
// roll positive right
#define TRIM_PITCH 0.0f
#define TRIM_ROLL 1.0f

// ########################################
// things that are experimental / old / etc
// do not change things below

// invert yaw pid for hubsan motors
//#define INVERT_YAW_PID

//some debug stuff
//#define DEBUG

// disable motors for testing
//#define NOMOTORS

// enable serial out on back-left LED
//#define SERIAL

// enable motors if pitch / roll controls off center (at zero throttle)
// possible values: 0 / 1
#define ENABLESTIX 0

// only for compilers other than gcc
#ifndef __GNUC__

#pragma diag_warning 1035 , 177 , 4017

#pragma diag_error 260

// --fpmode=fast ON

Eagle Keyboard Commands for Showing and Hiding Layers

Here’s a short post but one that I think a few people might find useful: CadSoft EAGLE keyboard commands/shortcuts (strangely found under the “Assign” menu in Eagle) to show and hide the Top and Bottom layers independently. I’ve also got one to show all layers, top and bottom. Note that you can change any¬†key a command is bound to when you set up the “assignment” in Eagle.

To set a shortcut in Eagle, choose¬†Options¬†‚Üí Assign…. and press the¬†New button.

Screen Shot 2016-04-05 at 8.54.04 PM +  Screen Shot 2016-04-05 at 8.56.32 PM

Once in the menu, choose the key you want the assignment to bind to, along with any modifier keys (Alt, Shift, etc). I chose Alt+0 for showing the bottom layer only, Alt+1 for the top layer only, and F12 for all top and bottom layers.

Screen Shot 2016-04-05 at 8.55.16 PM

Here’s the three Eagle commands for Top, Bottom, and All layers:

  • Top only:¬†display none; display 1 17 18 19 20 21 23 25 27 29 39 41 45 51;
  • Bottom only:¬†display none; display 16 17 18 19 20 22 24 26 28 30 40 42 45 52;
  • All (Top and Bottom):¬†display none; display 1 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 39 40 41 42 45 51 52;

A bit time consuming to implement, but they’ll save you tons of time once you’re actually doing a layout.

Reverse Engineering the Amazon Dash Button’s Wireless Audio Configuration

Update: I’ve learned a bit more and as such, see the bottom of the post for an update. I’ve been slow to update this but now that it’s seeming to be gaining a lot of traffic (leading up to 33c3…hmmmm ;)), I want the info to be accurate and fresh.

During the great Amazon Dash Button Hype of 2015, I saw a few of the early teardowns and blog posts and decided to order a few¬†dash buttons of my own to play around with and reverse engineer. Since the hype has burned off, there hasn’t been much in the way of new information about the inner workings of the button.

Photo credit: Matthew Petroff

The Amazon Dash button is a neat little IOT device which contains an STM32F205 ARM Cortex M3 microcontroller, a Broadcom BCM43362 Wi-Fi module, a permanently attached (boo!) Energizer Lithium AAA battery, an Invensense I2S digital microphone, some serial flash, and assorted LEDs and SMPS power supplies. For the $5 price tag, the Dash Button packs some serious punch! Just the components are worth a considerable amount more than $5.

Playing around with the button, the setup process on iOS quickly caught my attention. It (apparently*) differs from the Android setup process considerably due to differences in the inner workings of iOS. The Android setup involves connecting to the button via a network called “Amazon ConfigureMe”, while the iOS app appears¬†to use ultrasound-esque audio to transfer information to the button for the initial setup.

*I don’t actually have an Android device on hand to test this with, hence the “apparently”.

Without even opening the button, I put together a basic theory¬†on how the button was setup from the iOS app: The app sends a carefully crafted “audio” packet using the iOS CoreAudio Framework, which is then picked up by the Dash Button’s onboard mic and parsed for Wi-Fi config info. If the Wi-Fi credentials are correct, the button phones home to the Amazon configuration servers and the setup continues, but with further config info being sent directly to the button over the Wi-Fi.

I immediately ripped apart the button in search of a way to piggyback on the ADMP441 digital microphone’s I2S bus. I figured it would be trivial to toss a logic analyzer on the bus and decode what I2S data was being sent to the STM32. Since I2S is a very commonly used and extremely well documented audio protocol, I¬†counted on this being a relatively quick task.

While I was impressed with the density of the design, I was most definitely not impressed with¬†the lack of a visible testpoint on the board for the digital¬†microphone’s data line. The EN (enable), SCK (clock), and WS (word select) lines are easily available, but the SD (data) line is¬†nowhere to be found. I poked around for a bit but didn’t see anything that looked promising. I quickly came to the realization that I was probably going to have¬†to analyze the audio protocol as it came out of my iPhone rather than sniff it on the board. This was about the same time that¬†I also realized this was not going to be the quick and dirty analysis I was expecting…

Armed with my¬†R√ėDE shotgun mic, I took¬†a new approach. Using ¬†Electroacoustics Toolbox, I performed some basic audio analysis on the packets coming from the Amazon iOS app.¬†Based on Matthew Petroff’s Dash Button Teardown, I initially expected some sort of Frequency-Shift Encoded (FSK) modulation scheme. Using the Spectrogram tool, I could see that the configuration data was definitely coming in bursts of 20 packets in a try-retry scheme. It also looked like the frequency of the audio was spread out between 18kHz and 20kHz, which is on par¬†for an audio FSK implementation.

Screen Shot 2015-12-23 at 1.21.00 PM
Spectrogram capture of an entire configuration transmission.

Things got interesting, however, when I took an FFT of an entire transmission. The FFT showed¬†an obvious frequency spread near 19kHz, but lacked the characteristic¬†“double peak” indicating frequency occurrences¬†at¬†both the mark and space frequencies.

FFT of entire configuration transmission.
FFT of entire configuration transmission.
FFT of FSK modulation. Note the very obvious "double peak".
FFT of FSK modulated data. Note the very obvious “double peak” at the mark and space frequencies.

As I examined the FFT, it became clearer and clearer that the configuration data was not being transmitted with an FSK modulation scheme. At this point, I switched to the basic audio oscilloscope tool to try to figure out what was going on. After the first capture, it was pretty obvious that the data was being Amplitude (AM) modulated, with a carrier frequency of 19kHz.

Screen Shot 2015-12-23 at 2.14.16 PM

The data was so clearly AM modulated that I wished I had just popped open the scope to begin with (note to future self)! Here’s a scope capture¬†with a few repeated packets coming through.

Screen Shot 2015-12-23 at 4.01.07 PM

After “configuring” a few different dash buttons and examining the transmitted¬†data, I was getting confused as to why there was so much variation in the peak levels of the packets. I checked for ground loops and background noise before transmitting, and confirmed that the noise floor of my microphone setup was far below the variations in peak amplitude I was seeing. After staring at a few captures, I started to notice that the “variations” were consistent in their amplitudes. Looking some more, I realized that it wasn’t noise at all: the data was intentionally being sent with four distinct amplitude levels!

0000_0000 2 copy

Clever, clever Amazon is using Amplitude-Shift Keying (ASK) modulation with 4-level binary to send the data across to the Dash Button.

The big¬†benefit to this modulation scheme is that it’s got a 2-to-1 compression ratio, so the packet length is theoretically half of the length of an FSK packet. The downside, however, is that the Signal-to-Noise Ratio is halved. This isn’t really a problem, since the data is sent 20 times, and the transmitter (iOS device) can be closely physically located to the receiver (Dash Button).

After these discoveries, I came to a few conclusions:

  • The data is being sent from the iOS app using an¬†ASK modulation scheme, with a carrier frequency of 19kHz. It’s resent 20 times before moving on.
  • Each “bit” (really, two bits) has a nominal bit time of 4ms. There are four levels of bit amplitude and there is no true zero. Every¬†bit level, including 00, has some amplitude associated with it.
  • The first chunk of data is always the same. It looks like a simple calibration sequence, allowing the button to set the decoding thresholds for later down the road.
  • There appears to be both a start and stop glitch on all of the packets. This could be a byproduct of how Amazon is building their ASK packets in-app, or the hardware codec starting and stopping on the iPhone. This glitch isn’t harmful, because the transmission is stable by the time any meaningful data is coming through.
  • The packets are not of a fixed length. Entering a longer SSID or passphrase results in a longer packet.

Now that I had a rough idea of how data was transmitted, I wanted to give decoding some known data a shot. This is where things got really interesting for me, because I’ve got basically no¬†experience in¬†data transmission or communications theory. Luckily, I have a decent eye for patterns, which helped considerably in figuring out what data was represented where in each transmitted packet. I began by choosing an SSID and passphrase that were fairly easy to recognize. I ended¬†up using 7’s and *’s¬†in various combinations and orders. I quickly started¬†to recognize the waveforms of each coming through in the data, but it wasn’t immediately clear how the characters were being translated from their ASCII representation.

7_* (3) copy
Packet containing both 7 and *.

I was getting nervous that some type of encryption was being used on the characters to prevent bored nerds like me from easily snooping on the packets.

In an effort to bruteforce whatever translation was taking place, I sent the characters 1 through 9 in¬†the password field. I assigned¬†amplitude level “1” on the received data as binary 00, level “2” as 01, level “3” as 10, and level “4” as 11. I recorded the ASK levels of each character, and busted out a table of what the received binary data looked like in comparison to the known ASCII value of each character. The first thing that was clear was that the binary representation of each character definitely related to the next, which was good news. This ruled out any sort of¬†encryption or lookup-table based character set. The next observation was that the binary data was decrementing, rather than incrementing as the transmitted ASCII characters¬†should be. It was also evident that it was somehow scrambled or flipped from the known¬†representation.

After a bit of bit order manipulation, I arrived at three conclusions:

  • The levels I picked (level “4” as 11, and level “1” as 00) were incorrect. Flipping these levels yields non-inverted bits, which then results in upwards-counting binary¬†data.
  • Each 8-bit ASCII representation of a character was actually being transmitted “backwards” from how I expected, with the first 2-bits transmitted representing the LSB end of the ASCII character. Characters themselves are transmitted in the order they are entered.
  • Each block is 4 pulses long, which represents a total of 8 bits of data.

Armed with the encoding¬†info, my final task was to write a¬†piece of software which would listen to the audio sent by the iOS app and decode it into various representations. Doing it by hand was fun for a bit, but got¬†tedious quickly. I rather arbitrarily settled on MATLAB, mostly because it’s easy to interface with audio components, manipulate WAV data, and filter and analyze datasets. I also figured it would be a good way to sharpen up my MATLAB since it’s been a bit since I’ve fired it up.

With a few hours of coding, I’ve got a script that can listen via my external mic, trim the acquired data to a single packet (albeit semi-manually), and separate and decode each block into it’s¬†decimal, hexadecimal, and ASCII representations. It then saves this as a CSV file.

To to this, the MATLAB utilizes the built-in MATLAB AudioRecorder function. It then waits for user input in regards to the bounds of a single packet. With these, it trims the data and performs some simple filtering and peak detection. The peak detection is done using a Hilbert Transform (a very common and useful digital peak detection method). It then finds each subsequent peak and indexes them based on their amplitude to find the corresponding binary data.

Captured and trimmed audio data displayed in MATLAB.
Captured and trimmed audio data displayed in MATLAB.
The same packet after filtering and peak detection. Each level of peak is indicated with a different colored symbol.
The same packet after filtering and peak detection. Each level of peak is indicated with a different colored symbol.

I also (for no good reason) wrote a tool that goes in the reverse: punch in an array of 4 levels (1/2/3/4), and out comes a psudeo-ASK representation of it.

Because why not?
Because why not?

Using these software tools and a several packets, I discovered a few things:

  • The first two blocks of hypothesized “calibration sequence” is definitely that.¬†They’re 10 bits each, which doesn’t match the rest of the packet. I’ve looked at hundreds of packets and they all start the same way. My MATLAB code actually uses these to find out where to start looking for real data. Handy!
  • Block 3 (Decimal rep) is the total length of the data which will come after it, in “number of blocks”.
  • Blocks 4-9 in every packet appear to be some sort of UDID/CRC. I’ll come back to this¬†later.
  • Block 10 (Decimal rep) is the length of the SSID, in blocks.
  • Block 11 (ASCII rep) is the first char of the SSID. In this example, it’s only one character long.
  • Block 12 (Decimal rep) is the length of the passphrase. This isn’t always block 12, it’s dependent on whatever the length of the SSID is. It’s also always present immediately after the SSID, regardless if there’s a passphrase or not. If there isn’t, it’s just decimal 0, indicating that there is no passphrase.
  • Block 13 (ASCII rep) is the first char of the passphrase, if it exists. It’s also only one char long in this case.
Various blocks numbered by order of occurrence.
Various blocks numbered by order of occurrence.
Hypothesized purpose of each block of data.
Hypothesized purpose of each block of data.

The last real question remaining is: what are blocks 4-9? In every packet I sent, they were different. I immediately thought some sort of CRC but the packet changed at times when I didn’t change the SSID or the passphrase, so it’s hard for me to tell. I’m leaning toward a on-demand Unique Device identifier (UDID) generated in the iOS app, potentially in combination with a CRC. With 48 bits to spare, a 32 bit UDID along with a 16 bit CRC seems more than reasonable.

With this scheme, device setup would look something like this:


  • User logs into their Amazon account from the app. This takes place every time a Dash Button is configured. Amazon then generates a “short” (<=48 bits) UDID for the Dash Button which associates it with an Amazon Account. They also store this¬†somewhere on their servers.
  • The SSID and passphrase for the Wi-Fi connection are sent via audio packet to the Dash Button, along with the UDID that was just generated.
  • The Dash Button parses the data and attempts to connect to the Wi-Fi network. If it’s successful, it phones home to the Amazon servers with the supplied UDID. The Amazon servers “register” the button as active and tell the iOS app to continue setup.
  • From here, any further configuration data is sent to the button over the network, including what account is registered to the button (likely with more sophisticated verification than I’m alluding to*), what product the button is ordering, and shipping preferences.

*Just looking at the string dumps from the Dash Button firmware show that there is more sophisticated authentication taking place, it’s just hard to say when. I’m tempted to decompile the¬†firmware just for fun, but I’ve already spent enough time looking at this damn $5 button…

And of course, here’s the final outcome of my efforts:


I’ve attached my MATLAB code in the off chance anyone wants to try this at home. It’ll probably take some tweaking for your specific setup.

Here’s the MATLAB code on GitHub.

That’s all I’ve got so far. I’m still curious in figuring out the six mystery blocks: if you’ve got any thoughts on it feel free to let me know. I might make another followup post taking a look at the firmware using IDA or something in the future, we’ll see. And of course if any Amazon employees want to get ahold of me and tell me how far off I was, I’d be okay with that too ūüôā

Thanks to Matthew Petroff, GitHub user dekuNukem, and anyone else whom I may have forgotten to credit.

EDIT: It’s been pointed out to me by a few looking deeper into the button’s internals that the modulation scheme actually IS FSK with four carriers at 18130, 18620, 19910, and 19600Hz. I believe the reason why it so strongly resembled ASK when I observed the audio packets is because of the awful frequency response at the higher end of my phone, my mic, or both. A linear attenuation right at the top of the audible spectrum would explain the highest frequency being measured as lower amplitude.¬†That being said, all encoding and modulation schemes still apply, with the highest frequency encoding representing binary 11.

In addition, there is in fact a CRC16 attached to each packet. It’s the first two bytes after the packet length declaration. Also, that length byte includes the length of the two bytes of CRC. That leaves 32 bits for the UDID, which is POSTed to the Amazon servers at where XX us US for the United States, DE for Germany, etc. ¬†This jives quite strongly with my initial guess of button registration. Thanks to Benedikt Heinz (@EIZnuh) for sharing some of his research into the button’s firmware!