Zephyr On Ruuvi

Hey All,

I have got the latest version of zephyr working on my Ruuvitag :slight_smile:

I will be working on instructions and samples on flashing the board with MCUboot and then two applications that support smp_svr for OTA DFU.

Once done developing on Ruuvi with Zephyr will be much easier.

The board definition can be found at:

And some initial examples can be found at:

2 Likes

Awesome and big thanks :slight_smile:

Have you already power profiled the Zephyr implementation? Last time I tried Zephyr on RuuviTags I had issues with pretty extreme sleep current. I can also run the profiler of your binaries on my end if you don’t have the HW.

Still having issues with getting the bme280 and lis2dh12 working.

Got the lis2dh12 working, still having issue with the BME280 :frowning:

Spoke to soon:

LIS2DH12 readings so far:
#1 @ 12600 ms: x -0.009576 , y -0.009576 , z -0.009576
#2 @ 13901 ms: x -0.009576 , y -0.009576 , z -0.009576
#3 @ 15202 ms: x -0.009576 , y -0.009576 , z -0.009576

So it is finding the device now, but the results are not being read correctly. Same code work on Thingy52 but LIS2DH12 is running on i2c instead of SPI

Last time I looked into sensors on Zephyr, there was issue with the SPI read having extra dummy byte at the start of data. This is caused by SPI being full duplex, so while writing address of register to read to peripheral there is one 0x00 in the received data.

I pushed my work to https://github.com/ojousima/fw-nrfconnect-zephyr/tree/feature_ruuvitag_sensors , if I recall correctly I could read the sensors but power consumption was excessive with nrf_pwr_manager sample.

My solution to extra byte in SPI was https://github.com/ojousima/fw-nrfconnect-zephyr/blob/6f3cff49187ec381e1187499b5d8709e0bf29bad/drivers/sensor/bme280/bme280.c#L47, I give two RX buffers to Zephyr SPI driver. First one gets the extra 0x00 at the start of transaction and second one has the actual data which is given to BME driver

1 Like

Awesome thanks, I will look into it.

@otso I tried adding your changes into the newest driver they have in Zephyr 2.1.99 and the output was:

#64 @ 94568 ms: x 1.072512 , y 0.497952 , z 9.959040
#65 @ 95869 ms: x 1.034208 , y 0.421344 , z 10.188864
#66 @ 97170 ms: x 1.225728 , y 0.574560 , z 9.920736
#67 @ 98472 ms: x 1.034208 , y 0.574560 , z 9.920736
#68 @ 99773 ms: x 1.187424 , y 0.497952 , z 9.997344
#69 @ 101074 ms: x 1.110816 , y 0.536256 , z 9.959040

Looks correct, Zephyr reports acceleration in m/s and that’s pretty close to one gravity.

Awesome, didn’t realise that. Will work on package the data into a ble packet now.

Hey,

Have a basic advertisement application working.

The packet is structured like:

{ 0xff, 0xff, /* random Company ID*/
0x09, /* random mode*/
0x00, 0x00, /* Temperature*/
0x00, 0x00, /* Humidity*/
0x00, 0x00, /* Pressure*/
0x00, 0x00 /* Packets*/};

Will create a second one with a different advertised name then work on the boot loader. Once done I will add acceleration data to the packet as well with battery. Tx power seems to be fixed by zephyr, and still having driver issues with getting the lis2dh interrupts to work.

Got acceleration data in the packet now, it is m/s2.

The packet structure is:
The packet is structured like:

{ 0xff, 0xff, /* random Company ID*/
0x09, /* random mode*/
0x00, 0x00, /* Temperature*/
0x00, 0x00, /* Humidity*/
0x00, 0x00, /* Pressure*/
0x00, 0x00, /* X*/
0x00, 0x00, /* Y*/
0x00, 0x00, /* Z*/
0x00, 0x00 /* Packets*/};

To convert the data:
Type Reading
int16_t temperature/=100 is in degrees celsius
uint16_t humidty/=100 is %
uint32_t pressure+=50000 in Pa
int32_t x/=1000 in m/s/s
int32_t y/=1000 in m/s/s
int32_t z/=1000 in m/s/s
uint32_t packet_counter

1 Like