Collecting LIS3DH data outside of RRF

pfn

A while back, someone planted the seed of an idea in my mind: I want to collect accelerometer data, but I don't want to open up my printer case to wire it up; how about an arduino?

I thought about how to accomplish this with a bare arduino, but stumbled into some difficulty like how would I retrieve the data? Serial isn't a very good solution, reading/writing it is relatively painful, and slow/blocking.

Luckily, I had some Wemos D1 minis on hand. Wifi check. So I put together this prototype that:

connects the LIS3DH to the Wemos D1 mini
uses a common wiring harness (so I can plug it into my exposed Duet3, or use the ESP8266 to drive the LIS3DH)
Collects data from the LIS3DH on-demand using curl http://lis3dh.local/data

Code to interface with the LIS3DH was ported directly from RRF, so the behavior should be fairly identical. Formatting of the output data is relatively similar to how RRF stores it into .csv files. Except for the lack of a final footer line and the addition of 2 columns (to support post-processing into the footer line).

Example:

 $ curl http://lis3dh.local/data
Sample,X,Y,Z,Overflows,DataRate
0,0.176,0.508,0.816,0,0
1,0.176,0.508,0.824,0,0
2,0.180,0.508,0.820,0,0
[... snip ...]
1344,0.176,0.504,0.820,0,1355
1345,0.180,0.504,0.816,0,1355
1346,0.176,0.508,0.816,0,1355
[ ... ]

I went through several iterations to end up at a final stable solution that can be extended into something really useful. The first attempt was polling the interrupt pin directly during the /data request and processing/forwarding it to the HTTP client immediately. This was successful for about 20-40 samples of data before overflowing the FIFO on the LIS3DH. A later attempt tried bumping the clock rate to 160MHz on the ESP8266, this extended the runtime by another handful of samples before overflows. Etc. etc.

Finally, I landed on a solution hinted to me by @Falcounet : why not keep another buffer on the ESP8266 that's filled up by an interrupt on the INT pin? In 160MHz mode, this method easily runs for 15+ minutes without overflowing any buffers (80MHz keels over after about 30 seconds).

Anyhow, that's the extent of what I've tried so far. This would be useful for collecting data to tune up input shaping without having to open up a printer case to wire up an accelerometer (it'll certainly be useful on one of my printers for which this is the situation).

TODOs (maybe I'll do it, or maybe someone else might want to take up the baton):

Better wifi configuration (currently managed by editing the source)
Parse parameters out of the /data request to set accelerometer orientation
Perhaps specify collection interval so that post-processing is unnecessary
Perhaps collect data and stream it directly into RRF via file upload.

Prototype ESP8266 + LIS3DH source gist

This is what my setup looks like while testing out this project.
LIS3DH and Wemos D1 mini

T3P3Tony

@pfn cool, have you tested the csv outputs with the input shaping analysis plugin yet?

PCR

@t3p3tony

btw orderd a development board for this

jay_s_uk

@t3p3tony you can't use previously collected data with the input shaper plugin

pfn

@t3p3tony the output isn't directly usable yet (needs post processing to add the ending footer to be the same as how rrf outputs). However @mfs12 has given some insight how we could integrate pretty seamlessly

PCR

@pfn Prototype Boards are Here

@mfs12 do you need one too?

pfn

@pcr This board is so sexy

dc42

@jay_s_uk said in Collecting LIS3DH data outside of RRF:

@t3p3tony you can't use previously collected data with the input shaper plugin

...although you could use it with the accelerometer plugin by uploading the .csv file to the sys/accelerometer folder.