Amazon updated the Dash Button’s hardware to revision two earlier this year, so I decided it was time for a new teardown (here’s last year’s teardown). The new product number is
JK29LP; the old product number is
JK76PL. While the form factor and case remained much the same, the internals changed substantially. The major highlights are a switch from Broadcom to Atmel chips, a switch from an Energizer lithium battery to a Duracell alkaline battery, and the addition of Bluetooth Low Energy.
After unboxing the new Button, the first change1 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.2
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,3 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,4 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
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.