High speed acceelro/gyro data

[baldursigurds]

Hello,

I have been trying to get a consistent higher data rate from the LSM6DS3TR-C on the Puck.js. Getting data points one by one using the high level interface works well at lower rates, but at higher rates it is trickier. The chip should be able to do high speeds like 1.66khz, or thereabout?

The question is: Has anybody implemented the fifo on this chip, and then piped the contents into memory in bursts? I'm going through the manual for the chip, and there should be a magic combination, but I'm certainly missing some subtleties. Any code examples would be welcome.

[baldursigurds]

I have looked through the manual for the LSM6DS3TR-C, and set up a program which initiates the fifo on the puck, starting at 12.5hz to keep things easy, and then empties the fifo every second by reading the registers. This process takes about 200ms, which is not good, if we want to increase the frequency. Certainly, 208hz whould be out of the question with this method, and even at 108hz, we would be running out of headrom pretty fast.

So I can be a bit more specific: is there some way of pulling all available bytes from the fifo in one go, rather than using the for loop towards the end of the code? We know how many pairs of bytes there are, thanks to the fifo status registers, this is the variable n. I'm sure I'm missing something, since I have no experience working with I2C.

const FIFO_CTRL1   = 0x06;
const FIFO_CTRL2   = 0x07;
const FIFO_CTRL3   = 0x08;
const FIFO_CTRL4   = 0x09;
const FIFO_CTRL5   = 0x0A;
const CTRL1_XL     = 0x10;
const CTRL2_G      = 0x11;
const FIFO_STATUS1 = 0x3A;
const FIFO_STATUS2 = 0x3B;
const FIFO_STATUS3 = 0x3C;
const FIFO_STATUS4 = 0x3D;

const FIFO_DATA_OUT_L = 0x3E;
const FIFO_DATA_OUT_H = 0x3F;

const FIFO_CTRL1_VAL = 0b00001000; // fifo threshold level = 8
const FIFO_CTRL2_VAL = 0b00000000; // other options disabled
const FIFO_CTRL3_VAL = 0b00001001; // acc and gyro no decimation
const FIFO_CTRL4_VAL = 0b00000000; // no third or fourth data set
const FIFO_CTRL5_CONTINUOUS = 0b00001110; // 12.5hz continuous mode
const FIFO_CTRL5_BYPASS     = 0b00001000; // 12.5hz bypass mode
const FIFO_CTRL5_FIFO       = 0b00001001; // 12.5hz fifo mode
const CTRL1_XL_VAL   = 0x00010100; // 12.5hz, \pm 16g
const CTRL2_G_VAL    = 0x00011100; // 12.5hz, 2000dps

Puck.accelOn();

Puck.accelWr(FIFO_CTRL1, FIFO_CTRL1_VAL);
Puck.accelWr(FIFO_CTRL2, FIFO_CTRL2_VAL);
Puck.accelWr(FIFO_CTRL3, FIFO_CTRL3_VAL);
Puck.accelWr(FIFO_CTRL4, FIFO_CTRL4_VAL);
Puck.accelWr(FIFO_CTRL5, FIFO_CTRL5_CONTINUOUS);

setInterval(() => {
  let fs1 = Puck.accelRd(FIFO_STATUS1);
  let fs2 = Puck.accelRd(FIFO_STATUS2);
//  let fs3 = Puck.accelRd(FIFO_STATUS3);
//  let fs4 = Puck.accelRd(FIFO_STATUS4);
  let n = ((fs2<<8) | fs1) & 0b0000011111111111;
  console.log("Number in FIFO: ", n);
  console.log("WaterM: ", (fs2 & 0x80) >> 7);
  console.log("OVER_RUN: ", (fs2 & 0x40) >> 6);
  console.log("FIFO_FULL_SMART: ", (fs2 & 0x20) >> 5);
  let start = Date.now();
  for(i=0; i<n; i++) { // *************************     <- This loop is pretty slow
    let l = Puck.accelRd(FIFO_DATA_OUT_L);
    let h = Puck.accelRd(FIFO_DATA_OUT_H);
  }
  let stop = Date.now();
  let diff = (stop - start);
  console.log("Time: ", stop-start.toFixed(0));
  console.log("");
}, 1000);

[gfwilliams]

Hi - yes, the reading individually from the FIFO isn't great - usually you could do a single large I2C read of n*2 bytes and that'd be ok, but the Puck.accelRd function was only really for convenience and doesn't handle this.

Instead, since the Puck uses software I2C anyway, you should be able to set up your own I2C instance and use that. Something like this should work:

let i2c  = new I2C();
i2c.setup({sda:D14, scl:D15, bitrate:10000000 });
//..
let data = i2c.readReg(106, FIFO_DATA_OUT_L, 2*n);
let i16 = new Int16Array(data.buffer); // convert 16 bits to something readable

I could extend Puck.accelRd to allow you to read more data, but that'd require you to install a new firmware.

[gfwilliams]

is there typically a limit on how many bytes you can get over I2C

I don't believe so - you just keep reading - but the limit comes from the device you're reading from.

6.66kHz. Is it simply completely unfeasable to work with such a firehose of data?

I think in theory you may be able to read it in, but it's what you do with it that's then the issue. You were going to stream it over Bluetooth?

I haven't experimented with increasing the bitrate on the I2C on the Puck.js, I assume that this will increase performance

Well, we use software I2C for the Puck, and we already run that as fast as we can. Realistically even if you moved to hardware I don't think you could get substantially faster. You're going to start being more limited by the JS execution speed (but you can work around that somewhat with JIT in Espruino)

Normally I2C links are slower than SPI, but I don't think that's the case on this chip. Once you're transferring data you're transferring one bit of data per clock cycle - it doesn't matter whether that's over SPI or I2C.

[baldursigurds]

I don't believe so - you just keep reading - but the limit comes from the device you're reading from.

I guess the LSM6DS3TR-C.pdf is limited to 64 bytes per read, we'll see if I can confirm this number on the Puck.js.

You were going to stream it over Bluetooth?

There are two roles for the stream. Firstly, for gathering of data. It would be great to be able to stream over bluetooth, and save a file on a phone or somewhere. Otherwise, saving the data onboard, and then recovering it later would be great for this purpose, but this is constrained by the size of the flash chip (my dream board would have acc/gyro/mag and a 64-128mb flash storage). That being said, smaller files can certainly be used.

The second role would be to perform onboard calculations such as AHRS and integration. Then, stream the result over bluetooth, most likely a single number per second or so. Here, the constraint would be speed of reading the stream into memory, and the analysis (add to the dream board a powerful processor, we'll see how the Puck.js does once the data stream is up and running).

In either case, I'm sure that 6.66kHz would be total overkill, but I believe that getting up to 208-416hz would allow for better analysis, if the processor can handle it. I'm also just curious about how fast it can really go.

Another possibility for analysis would be running a neural network. As opposed to the AHRS version, in order to train such a model, we need lots of data, hence the storage option on my dream board. I am actually streaming accelerometer data from a Polar H10 during my runs at 200Hz onto an adafruit with an sdcard, so bluetooth actually has some bandwidth. This data goes into training a neural network, which I hope to run on the Bangle.js 2 to infer running speed. This means that the running speed project has two possible solutions in the pipeline :)

You're going to start being more limited by the JS execution speed (but you can work around that somewhat with JIT in Espruino)

This is very interesting, I didn't know about JIT. Hopefully I'll have some execution times ready soon, and we'll see if they can be improved.

[baldursigurds]

This is great! I'm running the following code fifo.js and getting pretty much a consistent rate of about 7500 bytes per second (if the division is being done correctly). It seems to be running quite stably at 208Hz and even 416Hz. At 833Hz it seems to be having hickups, but it keeps running, somehow. I don't know what this means, but I will now have to see what kind of computation can be done with this data :D

[gfwilliams]

That's great news! If you add the keyword "ram" right at the start of your function, like setInterval(() => {"ram"; then that'll allow Espruino to store the function in a minified form (without comments/whitespace) which might give you a little bit of a speed boost too (although you only run it every 500ms so it's not really going to be a big deal).

If you're planning on pushing that data over Bluetooth maybe just try using Bluetooth.write to push it over in a binary form - when converted to text it's going to be quite a few more bytes, which could hurt your transfer speed.

I've just added the accelRd multiple byte functionality to Puck.js, so if you install a cutting edge build you can now do:

  let fs = Puck.accelRd(FIFO_STATUS1,2);
  let n = ((fs[1]<<8) | fs[0]) & 0b0000011111111111;
  let data = Puck.accelRd(FIFO_DATA_OUT_L, 2*n);

[baldursigurds]

This is great, hopefully I'll have some time this week to try this out, thanks!