Amazon seemed really worried about the batteries falling out, since the battery door is held shut with both a plastic tab and one Phillips #1 screw. Underneath one of the two AAA batteries is a row of exposed test points. Four other Phillips #1 screws are hidden beneath the device’s rubber feet; removing these allows the device to be opened.¹

Once opened, there are two parts—a top half with the large button, and a bottom half with the PCB and batteries.

The top half consists of three plastic parts, three button contacts, and four springs.

The bottom half consists of one plastic piece, with the battery compartment, and the PCB, secured with two more Phillips screws.

The device can be easily disassembled and reassembled with standard tools and without damaging it.

The PCB is fairly spartan, consisting of a combined microcontroller / Bluetooth Low Energy SoC, three RGB LEDs,² a trace antenna, and supporting components. For easy hackability, there’s a Tag-Connect SWD footprint, as well as a U.FL antenna connector and numerous cuttable traces / solder jumpers. The SoC is a Cypress CYW20735 “single-chip Bluetooth transceiver for wireless input devices.” There appear to be freely available development tools for it.

The bottom of the PCB includes a set of test points, some of which are accessible from within the battery compartment. In particular, the SWD header is accessible via these test points with the following mapping:

 TMF2: SWDIO
 TMF9: SWCLK
TMF10: GND
TMF11: RESET
TMF12: VCC
TMF22: SWO

As far as software goes, the device broadcasts as a Bluetooth Low Energy gamepad with ID EchoBtn2V8.³ I was able to successfully pair it to a computer, but I have not yet tried to use it as an input device. I have also not yet tried to connect a debugger to the SoC.

1. There’s no glue or ultrasonic welding. ↩

2. There’s also a fourth, unpopulated footprint. ↩

3. The last three characters might be specific to my device. ↩

The box contains the device itself, two alkaline AAA batteries, and a plastic hook with an adhesive mounting pad. The new wand is a fair amount smaller than the original. The separate buttons for speaking to the device and using the barcode scanner have also been combined into a single multifunction button, now with a fancy LED light ring.

The black portion of the device can be easily pulled apart from the white part of the device, revealing the battery compartment.

Like both versions of the Dash Button, and unlike the original wand, the main device case is ultrasonic welded shut and doesn’t have any screws. Prying it open required a bit of work, and permanently damaged the case.

Inside are a circuit board and a barcode scanner module, as well as a pair of magnets for attaching the device to a refrigerator or other ferromagnetic surface.

Attached to the outside of the barcode scanner module using some sort of double-sided tape is the device’s speaker.

Opening the barcode scanner module reveals a linear image sensor and a pair of LEDs on a flexible circuit board and optics for both the image sensor and the LEDs. Unlike the original wand, which used a barcode scanner module with a built-in processor provided by an outside company, the image sensor is connected directly to the microcontroller on the main logic board.

Compared to the original wand, this new wand has a much simpler design with fewer parts, so it is undoubtedly cheaper to produce. The device is built around an Atmel ATSAMG55J19A-MU ARM Cortex-M4 microcontroller, U20; an Atmel ATWINC1500B wireless chip, U30; and a Cypress CYBL10563-68FNXI Bluetooth Low Energy chip, U40—these parts are identical to the second generation Dash Button. The flash memory, Micron N25Q128A / U21, is quadruple the size of that in the Dash Button—128 Mb instead of 32 Mb. Like the Dash Button, there is also a microphone and a single push-button switch. The one major addition, besides beefier power electronics, is a Wolfram Microelectronics WM8904 audio chip for powering the speaker.² The barcode scanner module is labeled with PALMFCSCAM as well as with what appears to be a serial number. The image sensor die is labeled LI163-7.

As one might expect, the software appears to share a code base with the second generation Dash Button. Like the Button, its primary configuration interface is Bluetooth Low Energy. The web page accessible by connecting to the Amazon ConfigureMe Wi-Fi network is also very similar but has the addition of displaying the device’s battery voltage. I’ve found two audio clips that the device plays—a setup message and an error message. Before the device is configured with the Amazon App, the setup message is played when the device’s button is pressed. Afterwards, pressing the button allows one to either scan a UPC barcode or speak an item—the error message is played if this is unsuccessful. The audio recordings made when speaking to the device are stored by Amazon and are accessible through the Amazon website.

As with the Dash Button, this new model Dash appears to be an incremental optimization aimed at reducing manufacturing costs.

1. As an aside, the original wand, FCC ID 2ABD7-5363, was a “Wireless Scanner” from “Violet L.L.C.” while the new wand, FCC ID 2AETI-0610, is a “Wireless Barcode Reader” from “Midnight Dawn LLC”. ↩

2. It also supports microphone input, but I’m the guessing the microphone is directly connected to the microcontroller as with the Dash Button. ↩

The main logic board consists of an ST STM32F205 ARM Cortex-M3 microcontroller in an LQFP package,¹ a Broadcom BCM43362 Wi-Fi module, a Winbond W25Q32BV 32Mbit Flash memory module,² an InvenSense INMP441 microphone, a 26 MHz crystal, an LED, and various passive components. These core components are almost identical to the original Dash Button. The board also contains contacts for two buttons, one for activating the barcode scanner and one for activating the microphone. The power regulation has been moved to a separate board, however, most likely due to the increased power usage due to the barcode scanner.

The final module is the barcode scanner, which is built using four PCBs and a piece of plastic. It was designed by a third-party, CipherLab, and manufactured by PLOTECH. The Decode_Board consists of an ST STM32F103 ARM Cortex-M3 microcontroller in an WLCSP package and various passives; the CCD board V1.0 consists of a linear CCD image sensor and various passives; and the two LED_V1.0 boards each contain an LED for illuminating the barcode. The four PCBs are soldered together.

The device was non-functional when I received it, so I can’t comment on the firmware. See the post the device’s original owner wrote for more information.

1. The original Dash Button used a WLCSP package.  ↩

2. The original Dash Button used a 16Mbit module.  ↩

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.  ↩

Components on the PCB include an ARM9 processor (TI AM1808B) with 512Mbit of DDR2 SDRAM (Winbond W9751G6KB25I) and 128Mbit of flash memory (Winbond W25Q128FV), an Invictus 2 ASIC with 512Mbit of DDR2 SDRAM (Winbond W9751G6KB25I), a pair of RF transceivers (Analog Devices AD9361BBCZ), a pair of 5GHz WLAN power amplifiers (Anadigics AWL5910), and a GPS receiver (u-blox AMY-6M). For the data Ethernet port there is an Atheros AR8035 gigabit Ethernet transceiver and M-TEK G24103SKG magnetics, while for the management Ethernet port there is an Atheros AR8032 fast Ethernet transceiver and Pulse HX1188NL magnetics.