market research (pset 1)

@carboxyl: this page is available on my blog if you're interested in following any of the hyperlinks: https://blog.npry.dev/class/smallmfg/market-research.

The goal of this problem set is to help refine your ideas, and to give you experience doing preliminary market research.

Select at least 2 "next best option" products in your market, and research their sale price, features, reviews, and estimated quantities sold per year. Use either graphs or charts (as shown in class) to compare these options to your idea(s), and create a functional requirements list, approximate price and sales quantity, that place you in a unique position in the market.

Please turn in a hard copy in class of your research, describing your idea(s), the comparison products, your charts and graphs, functional requirement list, and a brief description of how you chose that particular set.

SNIFFA (bus sniffer)

SNIFFA is a WiFi-enabled bus sniffer designed as a tool for debugging embedded electronics. It is modeled after the Bus Pirate.

functional requirements

• Bus support

  • SPI

  • I2C

  • UART

  • Nice-to-haves:

    • CAN
    • Automatic bus detection / scanning

• Connectivity

  • WiFi
  • USB

• Host-side control interfaces

  • Programmatic control (client libraries -- Rust, Python)
    • Protocol specification (protobuf, msgpack?)
  • Textual console (like BusPirate)
  • Nice-to-haves:
    • GUI (don't consider this critical, design is meant for engineers)

• Regulated power output

  • +3V3
  • +5V
  • Design intent: not meant to power high-current devices (~100mA)

• Battery lifetime >= 8h

  • Figure mean current draw of 250mA @ 3V3 powering a DUT and the probe on WiFI -> 4000mAh LiPo battery supports > 8h of runtime

• Small (< 100mm x 100mm), light (< 100g), easily portable

justification

I came up with this list based on my personal knowledge of the technical requirements for using a device like this, and by comparing features with the Bus Pirate and Flipper Zero. Bus support matches the competition — the design intent isn't to do everything but provide targeted utility (this can always be fixed in firmware later). WiFi is intended to be a differentiator, and USB is just necessary for a device like this, for DFU, tethered operation, charging. I give some justification in the Bus Pirate section for why good programmatic control from a host computer is important. Size isn't critical — it just needs to be on-par. I went with the same supply voltages as the Flipper — we could add more or an adjustable supply, but I think that's more trouble than it's worth. Battery lifespan is meant to get you through a working day.

I notably didn't include SWD support because I have a feeling this would take a substantial amount of dedicated engineering time to get right. Without looking into this further, I could definitely be wrong, but I'm not putting it in the featureset for a first revision for this reason. The competition does have this, so it's a tradeoff. However, this can probably be fixed in firmware, depending on which microcontroller I select.

existing products

bus pirate ($62 for v5XL)

Inspiration for this project. The Bus Pirate is a multi-IO debugging board that you can connect to buses and GPIOs and control from a host computer over USB serial. It provides a console-based interface with a custom command-set, and lets you both passively listen to bus traffic and inject your own.

It has several scripting interfaces, including a Python one, but my experience is that they are very flaky (commands fail, are timing-sensitive, etc.). I get the sense that the console UI and user-facing commandset were designed first, and then scripting capabilities were grafted on top. Automating bus interactions is one of the primary reasons for me to want a device like this, but it was bad enough on the Bus Pirate to cause me to give up and stop using it.

Reviews:

• Seeing a lot of how-tos and product summaries (e.g.), but not many actual reviews.
• Some from the Bus Pirate 3 era (early 2010s):
  • skywired
    • some complaints about features (no level shifting, gripes with host software)
    • likes the brekout cables
    • overall likes the device, thinks it's better than a plain MCU with custom firmware or an expensive analyzer
  • big mess o wires
    • loves it for multifunctionality (bus support, jtag support)

I couldn't find data on quantities for this specific project — the websites don't have published counters.

flipper zero ($170, $200 with WiFi shield)

Electronic hacking multitool built on STM32WB. Has a display, 2100mAh battery, 20+ GPIOs, bus interfacing capabilities, bluetooth, audio, Dallas 1-wire, two SDRs at different bands, an infrared transciever, an LCD screen, and a bunch of open-source support with a desktop application. Love the thing.

But:

• It's somewhat expensive — I think I can beat the price by a factor of 2
• I pretty specifically want to be on WiFi — it's important to me that you can be out of Bluetooth range and maintain a fast link
• I'm aiming to support a usage mode where you leave the sniffa integrated with your embedded project for potentially days or weeks. It seems silly, but I think this is emotionally harder to do for something marketed like the Flipper.

Some reviews (first few on google):

• https://www.reddit.com/r/flipperzero/comments/136kzd5/flipper_review_for_some_on_the_fence/
  • Beginner, likes it enough to replace it if it breaks, bought the WiFi devboard
• https://medium.com/@papathought/flipper-zero-an-honest-review-612118a6ba77
  • Dumb-consumer mindset, wants a turnkey hack-everything device and somewhat disappointed that it isn't that, uses it for RFID/NFC key storage
• Was really looking for a review from someone who writes their own software/firmware or really gets into the device, but didn't find it quickly. Suggests that there may be a lot of people who bought it for the "hacking Tomagotchi" experience it markets as without necessarily a deep embedded background.

kickstarter: 37k backers, raised ~$4.9M. Total device tally: 41,195. Hard to estimate their current sales volume, as they're selling through multiple distributors.

USB logic analyzers

These are somewhat orthogonal — they're not WiFi-enabled and are in a much higher price bracket, so I'm not doing as much resarch for them.

analog discovery 3 ($379)

Highly multipurpose: logic analyzer, oscilloscope, function generator. Has a GUI and Python client libraries. Connects over USB.

Couldn't find any location to estimate sales volume.

saleae logic 8 ($500)

Logic analyzer, relatively high sample rate, with ADCs on each channel. Connects over USB. The greatest utility is the desktop application, which is super easy to use and can be modularly extended with specific protocol decoders written in Python.

No idea on sales volume, this isn't published or exposed anywhere I could find. No kickstarters or similar.

hiletgo (saleae-compatible) ($13)

Very cheap logic analyzer that works in Saleae's GUI application. 8 channels, nominally 24MHz. Connects over USB.

No idea on volume, but they're able to sell at a very low pricepoint on Amazon, so probably 10k+ units.

feature comparison chart

Everything on the chart supports USB connectivity and decodes the buses of interest.

The Flipper and the Bus Pirate are the closest competitors. I'd be aiming to beat the Flipper in price and size by specializing in function, and the Bus Pirate by providing wireless functionality and battery power.

pricing (best guess)

Aiming for a bare board to minimize cost.

• PCB w/ one-side assembly: $15 (I think this is high)
• MCU (esp32c6): $2
• Connectors and switches: $5
• Passives: $2
• Power regulation: $5
• Battery (4000 mAh 1S LiPo): $10

Unit cost (low volume): $40

Sale price (@ 1.7x): $68

engineer / design time

I don't consider amortized engineering/design costs because I need this product for myself and would be spending the time to make it anyway.

But to run through this for the sake of the exercise, I expect this would take about a month of engineering time to design and build, so let's round up to 200 hours. Pricing engineer time at $125/hr, that's $25k.

I'm not sure if a typical 1.7x markup as mentioned in class is based on the unit cost (and engineer time is counted as overhead), or if it's common to explicitly amortize any fixed development costs of this kind. For the sake of argument, let's amortize the cost. Say I want to stay at least 25% under the Flipper Zero (with WiFi devboard) in price to remain competitive. For \(x\) units:

\begin{align} \notag 1.7 \cdot \left( 25000 + 40x \right) &= \left( 200 \cdot 0.75 \right) x \\ \notag x &\approx 520 \end{align}

I.e., I would have to sell 520 units to break even at a price point of $150.

But I would really want the price to stay under $100, which would look like:

\begin{align} \notag 1.7 \cdot \left( 25000 + 40x \right) &= 100 x \\ \notag x &\approx 1325 \end{align}

At either of volumes, I would expect the BoM cost to decrease significantly, so I'll rerun these calculations guessing that I could cut down unit cost by a third:

\begin{align} \notag 1.7 \cdot \left( 25000 + \frac{2}{3} \cdot 40 x \right) &= \left( 200 \cdot 0.75 \right) x \\ \notag x &\approx 405 \\ \notag 1.7 \cdot \left( 25000 + \frac{2}{3} \cdot 40 x \right) &= 100 x \\ \notag x &\approx 775 \end{align}

That's a bit better. The up-front capital required to finance a production run would be ~$11k (@ 405) or ~$20k (@ 775).

Pragmatically speaking, those volumes would be large to plan around for my first time doing something like this, so this math suggests the project is impractical.