Discussion about adding new ICM support and FIFO support #195
Comments
|
Hi, Thanks for reaching out. I welcome any improvements for the software. So far I have been focused on supporting the original iSpindel hardware but If there are ways to improve the hardware and improve on battery life lets try it out. Adding additional gyro hardware is not a big issue, but there should be an easy way for users to build the hardware, i.e easy access to components, PCB and container they can use (of course it should be open source). Currently I'm using another open source library for the MPU interaction (same as iSpindel) but I have not dug into the details on the FIFO feature and if that is used, I just base the gyro interaction on the examples. I would expect that having the gyro running that would draw more power but also make the built in temp sensor unusable since that would not have time to cool down. I'm planning to release the 2.0 version this week so if you use the dev branch as the base for your tests that should be a good start. its hard to put some expectation on how to develop the features since I dont really see how much code it will be and how much that would differ from the current code. Start with making them work and we can discuss how to best refactor the code to make it easy to merge and also maintain / test it. |
|
Ok will do :) You are right, using FIFO would give the temp sensor an offset, but not more than you already have now, either way is the temp sensor of the MPU not really that good, i see a few degrees offset even with accel and gyro disabled. The gyro is bad for battery life but it gets duty cycled in fifo mode, so i will test how much impact it really has very soon. Ill use the dev branch and keep you updated. |
|
On the gyro temp sensor, i did quite a lot of tests before adding that feature and I agree that the accuracy is not that good, but comparable to having a DS18 on low resolution and you read it as soon as the chip started. After a while it will continue to increase and be way off and it requires at least 10 minutes to cool down again.... But do your own tests and we can compare notes later. |
|
From what I could find out reading the data sheet a MPU6050 (only chip) would draw 3.5 mA which would run on an 18650 battery for 38 days. But to extend that one could change the the sleep behaviour and allow the FIFO to work in intervals. For instance of there i a sleep interval of 15 minutes
This would extend the battery life quite a lot but still allow for better readings if I understand the fifo function. So I wondering how long should it run for accurate readings in the background ? Does i need to run all the time or is interval an good apporach? |
|
So the MPU uses 3.5mA while measuring and enabled, when using fifo you actually normally slow down the measurements and put the gyro in a mode that will only enable it while taking a fifo sample, this should lower the power usage alot. The higher the data rate the more it uses over time. I will try to get some accurate current measurements soon about this. Theoretically you can slow down the measurements of the mpu to +-4Hz. Meaning only 4 times/s the gyro will wake and be used. With a 4kB memory and 14B per reading that means you can store 285 samples or 71 seconds maximum without data loss, however the fifo replaces old data when full so you just always have the last minute of data at your disposal when waking after that time. This is not alot, and its one of the reasons im going to add ICM-42670-P support. For the ICM: My next actions: |
|
I agree that the ICM options is much more interesting to look into, seams like a much better chip. Where to you buy the chips from? I would want to get a few so I can create a test setup. One thing I lack with the standard iSpindle hardware is the missing interrupt pin connection, that could help to reduce the power consumption since one could start the measurement and then let the esp do the networking stuff. Having to manually check for status consumes a lot of unnecessary battery (i think the read takes almost 800 ms) which is quite a lot of wasted time. |
The chips you can buy from any IC seller, Mouser is really good and has large stocks, but if you want to save some bucks you can buy them from china as well, however make sure to check the whoami register on receiving them, they can be fakes or different chips. Make sure you have the needed tools to solder these tiny smd chips though, its harder that it looks. 😉 Since i do this alot for me its no issue. If everything goes well and the PCB/tests work i have no issue sending you a sample board.
Yes i have also seen the same, atm the I2c readout without any processing is taking 930ms. I have also seen the setup also takes a fair chunk of this time which can be improved without changing any functionality. But ill come back to that in a later stage. The interrupt won't really improve that i believe since the time between the readings will still be the same. You could use the fifo at a high rate and then read them at once maybe before putting the chip to sleep? But you would still need to check the fifo byte count i guess. FYI just the fifo reading takes 0.56ms/sample so +-28ms for 50samples. I did some more testing and apparently i need to rectify smth, i said earlier the gyro consumption would be less due to the cycling, apparently the mpu6050 doesn't support that yet so it will continuously use 3.82mA sadly. So i don't think continuous fifo will ever be viable for the mpu without a loss in battery lifetime. 😞 |
|
So for temporary reference measurements i will be using (on average): So next week when my boards arrive i can do a proper comparison with those values. |
|
It was a long time since i did any measurements but i use this to calculate battery life on an esp8266: 15 mA / day (sleep) and 160 mA per hour when active (this include temp and gyro). My last fermentation had an average runtime of 4.2 seconds |
|
Okay so the boards arrived, are soldered and are working. So good so far. I'm now adding multi IMU support to the code, however while doing so i noticed you are not using default VScode/c++ formatting, could you please share your settings so i can format the code in the same way? :) I'd hate to mess up your formatting. |
|
I use precommit for formatting, there is a config in the root ditectory. I have usually run the command before check-in. So it does not matter what settings are used |
|
Sadly i could not get the precommit to work, I'll sort that out later. On the bright side i got classic angle measurements working today, so i can do some 1on1 comparison with the mpu tomorrow. The ICM seems to have way less jitter and inaccuracies so if the current really is lower even without using the FIFO i see that as a win/upgrade already ;) Sadly i did make a mistake on the pcb and missed a mandatory resistor i now soldered externally. So most likely ill have to make a new pcb first before others can use it. |
|
It wont work on windows, you need linux or macos. I use wsl on my windows machine Great that you are making progress, looking forward to the results |
|
Ah that explains alot 😆 Okay so the bare minimum power consumptions are in, to make these tests as fair as possible i eliminated all delays the firmware introduces due to wifi connection and reading json etc by just loading an empty sketch with the exact code from the imu handling. The ICM needs a longer setup delay (45ms) to smooth out the gyro according to the datasheet, so the setup time is longer than the MPU, i think the MPU might technically also need this, but since that is never done i left the code as is. So even though the ICM uses the extra delay and is more stable, due to the higher data rate the reading is shorter and it overall uses less power. So overall even without using different techniques like the fifo the ICM42670-p uses only 19.1% of the power the MPU uses. I am planning on improving this more by optimising some calls, and afterwards ill try to compare to the fifo method with the ICM. PS: due to the lower power consumption the temperature also has a smaller offset 👍 😉
|
|
Good work, that is positive for the power consumption even though is quite small compared to the consumption of the esp. But in combination with ble transmission is should have an bigger effect on battery life would be interresting to see the accuracy as well, how much that could be improved. |
|
It is indeed small compared to the esp, but the shorter readout (10x shorter) will also be seen in the total consumption since the esp can go sleep sooner, which is the next measurements i will do. Plus this might make it a candidate to use the fifo which could make for much better accuracy over time. Regarding accuracy i have no way of measuring that in numbers, although the ICM sensor is more accurate by default, unless i spend a week pulling statistics i have no way of comparing them. What i might do is put an mpu and an icm in the same fermenter next time to compare the results? But that will not be for a few weeks. |
|
Yes, the shorter read time will probably have a bigger impact on the total consumption. Wifi is till the biggest battery killer according to my previous testing. Would be interresting to get comparable values from the same device. It should be possible to have both sensors attached to a device and send data from, which then could be compared |
|
Yes my current setup is without an actual soldered ISpindel, just an ESP8266 (the same one with the same firmware) where i swap the IMU just by plugging a new one in 😉 In that setup i now get the following results with the adjusted firmware for multi IMU support (that doesn't change anything to the MPU in theory) and without an external temp sensor:
As you can see the +- 1s time gain means about 14% of energy gain per cycle. PS: i don't know why but once attached to the ESP the MPU sleep usage is now higher, i think it was originally leaching off the I2C voltage somehow which didn't get measured, now i measured the entire circuit so the only power source was my measurement device. This should be more accurate. So even in sleep the ICM seems to use less now which corresponds to the datasheets. |
|
Preliminary results for fifo mode with ICM suggest it uses 1/5th the power of the mpu in fifo mode. but that would still be twice as much overall compared to a normal cycle. However since there is no setup (the gyro is already on) i need to verify how much is recuperated due to the shorter esp cycle. But imo this comes close to actually being possible to use. In this mode there is a (very accurate) sample stored in fifo every 10s, compared to 50 samples (in 1s) every 15mins this should give an accuracy that is worlds apart. tldr; ICM in fifo uses 665µA and ill test more next week after i added FIFO mode in the gravitymon code. |
|
Sounds promising, i managed to find a breakout board on aliexpress that i ordered so i can run the code. Should be here in 2 weeks |
|
I don't know where you live but i can send one of mine if you don't mind the external resistor/shipping 😉 The aliexpress board isn't ispindel layout compatible btw, so don't forget to switch the pins around. (clk should be the third pin from VCC for ispindel layout) |
I saw it had a different pinout but that s not a problem, will wire it to my dev board |
|
You can email me on [email protected] instead. I forgot i removed the mailservice for that domain. |
|
Sorry i didn't get back sooner, I was busy with implementing and further testing FIFO with the ICM. Regarding temperature: The ICM with its lower power consumption seems to have less issues with heating in FIFO mode, i tested the temperature and compared it to room temp and it consistently stays within <2°C from room temp, now i might just be lucky with my chip, but i like to think that isn't the case here. The stability is also reversed to the MPU, temp becomes stable the longer it has been since the setup/startup, since that phase uses more power. Regarding power consumption:
The relative usage is sitting at +-200% so we are looking at half battery life compared to normal (measured on ESP8266, this will be better on ESP32). This is however close enough to consider adding at least as a compiler option for people who know what they are doing 😉 I'm also looking at the even newer ICM chips that can improve even further on this, but they are sitting at a 4€ per chip, which seems a bit much just to save some battery... Either way except for some cleaning up i believe my current code has all the main features, how do you want to proceed on this? I expect to have a real life test this week if everything goes right and ill throw in some different boards (MPU, ICM and ICM fifo) to compare accuracy. |
|
The current FIFO mode works as follows:
So far it seems very stable and accurate but the remaining issue is after changing the sleeptime the imu needs to be reset, and that is not easily possible atm, any ideas? |
|
Great news, I'm still waiting for my chip from china so I cannot do any testing/running the code until i receive that so please do some accuracy testing as well that would be very interesting to see. On the sleep cycle, there is some logic in the code that changes the sleep cycle, especially if there is an error with WIFI connection, the device will go into sleep for 60 seconds and then retry again. I think i will need to dig into the code and interface for the IMU to get a better understanding on how that works. Feel free to open a PR when you think your code is ready. I will let you know when my board has arrived. |
|
Sorry ive been busy the last week. Currently i would like to address a few issues first before I'd consider a PR:
FiFo only issues (a PR for just supporting the new IMU would not need these fixed):
I can implement these solutions but they will need time to work out. I have some leave coming up so i should be able to work on them soon 😄 |
|
You can always configure the IMU based on the startup mode, so in gravity it used the sleep timeout and when in config mode a constant read mode is used ? Then you should not need to do a power cycle if sleep timeout is changed. Error handling is key to detect when there is no valid data or some of the logic will be way off... I finally got my sample board from china last week so when you do a PR I can also do some testing (or at least run the code). |
Hi,
So i wanted to contact you about features i'd like to contribute and maybe discuss this in advance so its clear on how you might want these added. I have quite alot of experience with these IMU's over the years and since i started making my ispindels noticed some improvements that could be made.
First of all i'd like to add support for the ICM-42670-P chip, this is another recent invensense IMU that is very low power and has great accuracy and has some nice features that could really augment my readings while saving power. To do this i suggest I create an interface to abstract the IMU, and change the IMU field to be a pointer assigned on detection. If this is fine with you of course. If you want me to do it in some other way i'm all ears.
For the FIFO i'm surprised it isn't used yet. It would leave the IMU on and collecting data while the main IC sleeps and then when the ESP wakes up all the samples are already there, collected over the entire time it was sleeping thus being more accurate over time and shortening the time the esp is online. I've already ran some tests on this and it seems very promising for this scenario. With MPU6050 i get a very consistent 0.01° accuracy using FIFO. On the MPU6050 however it might use more power than sleeping (i will measure exactly how much soon). But maybe adding it as an alternative option could be beneficial? I can fork/change the code and add the option but i don't know how you make your front-end and might need some help on that side. But first i will do the power/accuracy measurement on both the new and old imu's so you can see the difference.
Regarding the accuracy/power consumption comparison i will do, do i just test the default settings (every 15m push), or is there other data you are interested in to know if you want to add it? Basically how longer the sleep time, the more fifo will use compared to all sleeping, but the larger the accuracy difference as well.
If you don't like these features and rather not have them pulled into the main, i can always maintain my own fork, thats fine for me too. ;)
Thank you for the already amazing project and hope to hear from you soon.
Levi
The text was updated successfully, but these errors were encountered: