Ruu-v6

• 

  The challenge

• 

  Hardware setup

• 

  Running CoAP on the RuuviTags

• 

  This is were Nordic is hiding its alternative operating modes

Inspiration

MCU vendors tend force, or at least encourage, the use of their vendor libraries for their (network) hardware, leading to things like vendor lock-in, close-source firmware and driver blobs, and preventing free use of their silicon. One way to avoid this situation is the usage of free software stacks and operation systems (like RIOT), that provide hardware drivers written from scratch, in combination with free and open-source network stacks.

RuuviLab posted a challenge to bring native IPv6 support to the RuuviTag. This could be done through Nordic's 'SoftDevice' using IPv6-over-BLE, which would however mean that the IPv6 support is based on a binary blob provided by Nordic...

So why not provide the RuuviTag with IPv6 support in an alternative approach, utilizing RIOT and an alternative radio mode provided by the hardware? Easy :-)

What it does

The project demonstrates the usage of RIOT on the RuuviTag, utilizing RIOTs network capabilities and driver infrastructure. The project is based on an alternative driver for the nRF52's radio, called nrfmin.

On a high-level, we demonstrate two RuuviTag nodes that provide a CoAP server. A third RuuviTag is connected to a host PC via a serial debug interface (JLink RTT). This third node acts as a simplified user interface allowing interaction with the other RuuviTags using RIOT's shell.

This setup allows reading both available sensors from each remote RuuviTag, acquiring the accelerometer as well as temperature, humidity, and air pressure data.

What does nrfmin mean?

"nrfmin" is a very simple link layer protocol and implementation for NRF5x chips. If ieee802154 is too hard to implement, use nrfmin!

It features:

• fixed header size!
• little endian!
• no encryption!
• no bullshit!

 byte0 | byte1 - byte2 | byte3 - byte4 | byte5 | byte7 - byteN
 ------ | ------------- | ------------- | ----- | -------------
 length |   src_addr    |   dst_addr    | proto |   payload...

Contributions during the hackathon

The RIOT port for the RuuviTag was already provided by us before the hackathon,

During the hackthon we implemented and merged support for the RuuviTag's sensors, the lis2dh12 accelerometer and the bme280 environmental sensor. While the lis2dh12 sensor driver was written from scratch, the bme280 was already part of RIOT, but in such a bad state that the fixes came close to a complete re-write...

State:

• the lis2dh12 driver is merged into RIOT's master (see #8381)
• the bme280 driver is PRed and currently under review (see #8383)

Challenges we ran into

We did not manage to get 6LoWPAN working. Apparently the 6LoWPAN neighbor discovery is faulty when used in conjunction with the nrfmin driver. As fall-back we are simply using plain IPv6 over nrfmin.

Also, after unsuccessfully debugging the sensor drivers for a while, we were happy to find out that the particular RuuviTag we had not soldered on any sensors, so the quietness on the SPI bus could be nicely explained :-)

Accomplishments that we're proud of

Nothing went up in smoke. We now fully support the roundest board in RIOT.

What we learned

RIOT's 6LoWPAN NDP is always good for surprises.

What's next for Ruu-v6

Fix 6LoWPAN (NDP) in RIOT to get a border router working.

Built With

• c
• coap
• gnrc
• ipv6
• jlink
• nrfmin
• riot
• ruuvitag