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.
-Instead of that, I wrote a new tool that runs on any local machine that has python2: that would include macOS, Linux and some Windows computers (but untested on macOS and Windows).
