Wifi vs BLE vs 6LoWPAN

We should have a corpus of case studies in the case-studies/ folder which we can target Reach's design toward and help derive product requirements.

The easiest task would be to break out relevant case studies from the archives/ folder, which has a lot of old content for Reach.

Additionally, feel free to contribute your own idea you think Reach could help with!

We want the ESP32 demo at firmware-esp32/ to be capable of reading data from an accel-mma84 module over I2C. The MVP would be reading acceleration data and turning on lights when e.g. the board is flipped over. We will later abstract this working accelerometer demo to build our firmware support for I2C.

• Here is example code for talking to the MMA8452q accelerometer over I2C.
• MMA8452Q datasheet and breakout board
• We can test the I2C implementation using a logic analyzer to see that the driver is correct.

We should produce a preliminary API that shows how to connect to Reach devices.

See the rendered view.

For example, given the above interaction spec, a user could do:

var Reach = new Reach([dev-id])
Reach.module.i2c.transfer(new Buffer([0xDD, 0xAA]))
.then((res) => {
  // received bytes
})

TODO:

• How do you detect Reach nodes?
• Can you address the hardware interface directly, or should it be hidden behind an explicit "we will control each transfer" interface?
• Can node modules support a Reach interface the same way as a Tessel interface?
• What is the goal of a command line tool?

We want to design a products specification for Reach that defines its requirements, marketing strategy, and hardware and design tradeoffs.

See the rendered view.

TODO:

• Define hardware tradeoffs.
• ???

• Product opportunity assessment #7
• Spec #8

• What is it
• How to get involved
• What to work on

We have a preliminary schematic in hardware-esp32/ right now for an ESP32 based board. The next steps are:

• Review this schematic & update the BOM
• Produce a board layout that exposes all the features the WG will need in development
• Hold a design review
• Manufacture the board
• Assemble the board in house
• Perform a test sequence on the board to ensure it works

This probably falls into the category of "use what's in the dev kit", but: We should determine what OS the ESP32 needs to run in order to meet Reach's criteria.

In the past (see the SAMD21 running on T2) we've used a self-written firmware that runs directly on the metal to power our hardware applications. We also (in the T1) have integrated with Wifi radio event loops in a bare metal environment. FreeRTOS, which the esp-idf ships with, is higher level than what we've worked with before, and represents a set of trade-offs we should be explicit about. If the alternative is to run a bare-metal firmware, or an alternative RTOS like NuttX, etc. we want to pick the best tool for the job.

TODO:

• Determine if the ESP32 requires the FreeRTOS stack to power its radio stack
• See if bare-metal code examples running on the ESP32 exist
• Create a tradeoffs list for each of our options and select a path forward for A) prototyping and B) production (these may be different)

toolchain setup and hello world by https://medium.com/@DelSquared/hello-world-esp32-firmware-38b604c7a1f1 by @sharmisthasg and @arushi019

This should be straightforward; we have code infirmware-esp32/ and we want an instructions file at firmware-esp32/README.md which describes how to load code onto the device.

This may increase in complexity over time, but for now can mostly replicate the instructions at https://github.com/espressif/esp-idf-template, e.g:

## Getting started

* Plug in your ESP32 Thing.
* Run the makefile.
* Load it onto the device.
* Expect $THIS_THING to happen.

### Troubleshooting

Possible errors with drivers? etc. Follow these instructions: $INSTRUCTIONS_URL

We should have an example "hello world" that can be built directly from this repo. This will allow us to put together a "Getting Started" guide that allows anyone to jump in easily.

Eventually we'd like to evolve this into our Reach firmware.

Enjoy this reading: http://deseng.ryerson.ca/dokuwiki/design:weighted_decision_matrix

Here is a sample table: https://docs.google.com/spreadsheets/d/1XC9n0fivYLNJiW9yH-FTacahAOlxCDQYSHLq87XmeVE/edit?usp=sharing

We need some hard numbers about sporadic BLE and Wifi usage on ESP32, as well as Wifi usage on the ESP8266. Numbers available in the datasheet are a good baseline, but we probably want solid numbers to inform whether these architectures are viable for long-lived sensor networks.

Ideally, we can contrast these with other BLE frameworks as well and make informed choices about the Reach architecture.

Hey, I am trying to use ESP32 and checking out its basic functionality. The tutorial I have referred to is - http://esp-idf.readthedocs.io/en/latest/get-started/ and the driver that I installed for my Mac OSX is - https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers

The toolchain has been setup. However pushing the code into the board is not done. I've attached a screenshot below, against the tutorial code. Any help would be of use :)