After unboxing the new Button, the first change¹ is visible, albeit minor—the design of the mounting adhesive on the back of the Button changed.

Removing the front label reveals another change, the removal of the three screws that were under the label. It turns out that they weren’t actually removed, just moved inside. The screws only hold the PCB to the case; they never held the case together. The new Button, like the old Button, needs to be pried open, which reveals the battery. The case is closed using ultrasonic welding.²

The original Dash Button contained a lithium battery that was tab-welded in place and thus rather permanent. The new button includes an alkaline battery in a holder; it’s still not really replaceable as one has to pry open and damage the case to get at it, but the holder is an improvement. Removing the three Torx T5 screws, the ones that used to be under the front label, allows one to remove the plastic around the battery and remove the PCB from the case.

This now allows us to inspect the PCB, which has the obvious change of blue solder mask instead of green solder mask like the original Button.

Instead of Broadcom chips, the new Button features an Atmel ATSAMG55J19A-MU ARM microcontroller, U1, and an Atmel ATWINC1500B wireless chip, U19. As a new addition, it also has a Cypress CYBL10563-68FNXI Bluetooth Low Energy chip, U22. The flash memory, U15, has been moved to the back of the PCB and doubled in size to 32 Mbit; it appears to be a Micron N25Q032 chip. The microphone was also swapped out, although I was unable to identify the new part. Finally, the microcontroller’s programming header is no longer populated, although it appears to be the same footprint, so it should be able to be populated with a Panasonic AXE510127 header. The new Button is likely easier to reprogram, since Atmel is much more forthcoming with documentation than Broadcom.

Since the new Button uses a lower capacity alkaline battery when compared to the original Button’s lithium battery, I analyzed the power usage of both Buttons. While in sleep mode, the new Button uses ~2.0 μA, down from the original Button’s ~2.3 μA. More interesting is the power usage when activated. The new Button uses slightly more power when on but uses less energy per button press, since it stays on for a much shorter period of time. The original Button shows the peculiar behavior of staying on for a long time after the LED turns off before going back into sleep mode,³ which accounts for the increased energy usage; it’s unclear to me whether this is due to the hardware design or due to the firmware. As I was having issues with my multimeter’s internal resistance causing a brown-out when the Button was pressed due to the current surge of the Button powering on, which would cause the Button to reset,⁴ there’s the chance the extended “on” time was due to my measurement setup, although I think this is unlikely. An example power usage graph for each Button is below. The triangle wave signal in the graphs is from the Button’s LED pulsating while the transaction is happening. There are mostly likely brief power usage spikes during RF transmission that aren’t visible in the graphs.

Using a sample size of five for each Button, I measured the new Dash Button’s energy usage to be 4.3±2.2 J per activation and the original Button’s energy usage to be 16.4±0.1 J per activation. According to the batteries’ corresponding datasheets, the new Button’s alkaline battery contains ~2 kJ, while the original Button’s lithium battery contains ~4.3 kJ. This corresponds to ~500 presses for the new Button and ~250 presses for the old Button. It turns out that the new Button should last longer despite having a cheaper, lower capacity battery.

Moving on to the software and firmware, Bluetooth is now the primary means of configuring the Button; when placed in configuration mode, the Button is discoverable as a Bluetooth Low Energy device with name DashButton and a random MAC. The previous configuration mechanisms, Wi-Fi for Android and ultrasound for iOS, serve as fallbacks. The device’s web page, which can be accessed by connecting to the Amazon ConfigureMe network has changed. It no longer contains a form for entering network configuration information and instead lists the Button’s serial number, MAC address, and firmware version (it now uses CSS styling, too). Sniffing the setup sequence revealed some information on how the setup protocol works. The Android app first issues a GET request for http://192.168.0.1/, which is presumably to determine the model number and firmware version. It then issues the same request but with the Content-Type: application/json header set; the Button now returns a JSON file than contains the Button’s serial number, MAC address, and a list of visible Wi-Fi networks and their signal levels. This is an improvement as the app now shows the networks the Button can see instead of those the mobile device can see. The app then issues a GET request along the lines of http://192.168.0.1/token?value=o%26vD, where the four-byte value changes every time; I don’t know where it comes from. Next, another GET request is made for http://192.168.0.1/. Finally, the Button is configured using a GET request for http://192.168.0.1/?amzn_ssid=SPECIFIED_SSID&amzn_pw=SPECIFIED_PASSWORD, where SPECIFIED_SSID and SPECIFIED_PASSWORD correspond to the SSID and password entered into the app. Unfortunately, the new Button can’t easily be set up using a laptop like the old button could.

Overall, the new Dash Button appears to be a revision designed to reduce production cost, centered around a reduction in energy usage, which allows for use of a considerably cheaper, alkaline battery.

1. Besides the new product number.  ↩

2. This is mentioned in one of the FCC filings (by Butte L.L.C.).  ↩

3. I didn’t notice this last year.  ↩

4. I mitigated the problem by placing a 10mF capacitor in parallel with the Dash Button.  ↩

The first victim is the Cottonelle Dash Button. The outside of the Dash Button consists of a button, a microphone hole, a loop for tying to, and adhesive on the back. The different brands of Dash Buttons have the same model number, JK76PL, differing only in the label.

Peeling back the label reveals three Torx T5 screws.

However, the two halves of the case are also glued together and must be pried apart once the screws are removed.

Opening the case reveals a small printed circuit board with an Energizer Ultimate Lithium AAA battery. Although the cost of the Dash Button is less than that of the battery alone, tabs are spot welded to the battery making reuse difficult; Amazon also limits customers to one of each brand of Dash Button.

Next are high-resolution images of the front and back of the PCB, both with components still on and with them removed. Here are full resolution copies: front with components, front without components, back with components, and back without components.

The circuit board is at least three layers and contains blind vias. The design seems based on the Broadcom BCM943362WCD4 WICED module reference design, with a Broadcom BCM43362 Wi-Fi module, U9, and an ST STM32F205 microcontroller in a WLCSP (instead of a LQFP), U5. This is similar to, but not the same as, the chip that is used in the Particle Photon. The Photon uses a USI chip that combines the Wi-Fi module and microcontroller into the same package but is otherwise the same. Other components on the Dash Button include an InvenSense INMP441 microphone, MP1; a Micron M25P16 16Mbit serial Flash memory module in a UFDFPN8 package, U6; an RGB LED, DS1; and a 26 MHz crystal, Y1. I transcribed the markings from the other integrated circuits but was not able to identify them.

Also included is a 0.40mm pitch 5×2 pin board-to-board connector (Molex 503548-1020 Panasonic AXE510127¹ ) and a number of test points. This header contains a JTAG interface to the microcontroller as well as what I think is a serial interface to the microcontroller. The pinout, labeled in the same order as the photo above, is:

GND     NRST
PC6     PA14
PC7     PA13
PB3     PA15
PB4     3.3V

which corresponds to

GND             NRST
USART6_TX       JTCK-SWCLK
USART6_RX       JTMS-SWDIO
JTDO/TRACESWO   JTDI
NJTRST          3.3V

as likely pin functions. Except for NRST, these pins are also accessible from test points, with TMF25->USART6_TX, TMF26->USART6_RX, TMF23->JD0/TRACESWO, and TMF24->NJTRST. The column to the left of the previous test points, from top to bottom, corresponds to JTCK, JTMS, JTDI. I have not yet tried to connect to either the JTAG or the USART. The other test points I was able to identify were TX7->PB11, TX3->PA2, TX9->PC0, and TX8->PB13. All identifications are based off of a combination of visual inspection and continuity testing of the PCB once all components were removed via hot air.

The Dash Button operates at 3.3 V boosted from the battery’s nominal 1.5 V, drawing 200–300 mA from the battery when on and 2.3 μA when in sleep. This means the ~1200 mAh battery should be able to power the device for at least four hours while on and decades while in sleep. Since the button is only on for a few seconds when activated, it can probably be used close to 1000 times before the battery dies. Thus, the button should become obsolete long before the battery is depleted.

Moving on to software, the Dash Button is configured using the Amazon mobile app using ultrasound² to configure the button in the case of iOS and Wi-Fi in the case of Android. I have not reverse engineered the audio protocol, but the data seems to be transmitted using audio frequency-shiftamplitude-shift keying around 18–19 kHz. The app transmits this message 20 times before giving up. Although not mentioned in the documentation, the Dash Button creates a Wi-Fi hotspot when placed in configuration mode, Amazon ConfigureMe, which is used by the Android version of the Amazon Shopping app. Once connected to this hotspot, a web page is accessible at 192.168.0.1 via HTTP, which allows for configuring the Button’s Wi-Fi connection settings. However, the Amazon App is still required to finish setting up the Button. When connecting via HTTPS, a certificate signed by the Amazon.com Internal Root Certificate Authority and issued to Amazon.com Infosec CA G2 is presented, which expires 2016-06-22. However, I was not able to successfully connect even after bypassing the certificate error, so it might be using a different protocol over TLS. The Button’s firmware version, v0.9.119, can be gleaned from the source of this page. By monitoring the Button’s network traffic, I was able to determine that the Button communicates with parker-gateway-na.amazon.com via TLS.³ Additionally, it always uses 8.8.8.8 for DNS. Due to the use of ultrasound instead of Wi-Fi in the iOS version, I assume iOS doesn’t allow Amazon access to the Wi-Fi settings they want. The MAC address vendor prefix is 74-75-48 for my Tide Button when triggered; it is 6C-0B-84 when in configuration mode.

I still have a fully intact Tide Dash Button. Now that I know the pinout, I might disassemble it as well and try to connect to its microcontroller via JTAG and serial.

Edit (2015-08-01): An eagle-eyed reader pointed out that U1 is probably a TI TPS61201 boost converter; the footprint, package markings, and pinout seem to fit.

Edit (2015-08-05): As mentioned in the comments, the Button uses a different MAC address, with a different vendor prefix, when in configuration mode versus when pressed; I updated the post to reflect this. Additionally, Buttons with different branding appear to have different MAC address vendor prefixes.

Edit (2015-08-06): I just tried configuring the Button using Android instead of iOS as I had originally done and discovered that Amazon’s Android app configures the Button using Wi-Fi instead of ultrasound like the iOS version does. I updated the post to reflect this.

Edit (2015-08-10): Ted Benson wrote an interesting article on how to repurpose the Button by watching for ARP probes.

Edit (2015-08-12): Adafruit now has a guide for reprogramming the Button. There’s also an interesting project on GitHub that has a firmware dump and other firmware and reprogramming information.

Edit (2016-01-01): Jay Greco did some fascinating work reverse engineering the iOS audio configuration protocol. It turns out Amazon is using amplitude-shift keying, not frequency-shift keying; I updated the post to reflect this.

Edit (2016-03-07): Paul Bilke pointed out in the comments that my guess as to the part number of the board-to-board connector is incorrect; I struck this out in the post.

Edit (2016-06-02): Paul Bilke noted in the comments that Nathaniel Quillin figured out the part number of the board-to-board connector; I updated the post to contain the correct part number.

Edit (2016-07-12): I just finished a teardown of the new version of the Dash Button.

1. The mating connector is a Panasonic AXE610124. ↩

2. It’s only sort of ultrasound; I can still hear it. ↩

3. It also does at least basic checking on the TLS certificate. When I hijacked the DNS lookup and pointed it at the server hosting this blog, it never progressed past the TLS handshake. I didn’t try anything more sophisticated. ↩