I'm still hopeful that some day I will get an answer to my questions!
I've emailed support and also not received an answer but I'm going to keep checking every day!
Thank you for running that test! I thought that's how it worked but didnt have time to get around testing it. The idea I had was to integrate either the time on or approx consumption and store it using the "preferences" library. The library saves whatever to the non-volatile memory so you wouldnt need the SD card. There was a write up of the libaray on the forums here:
So the two ideas:
track how long the device has been on, update a preference with the time, subtract time on from the 5 hours 40 mins to get time remaining. It wont always be accurate, but probably close enough for most uses.
Calculate the current consumption based on screen/wifi/bluetooth/etc being on, integrate all that and compare to total mah of the battery. (This would have a lot of factors, but could probably get you closer if you figured all them out.)
I think the first one is the "easiest", do you have any thoughts?
I dont have this unit, but if you look at the following github where I believe the library is used from there are calibration instructions there:
I'd start with that and see what happens.
I posted this under the core2 product page, but will post here also since this chip exists in more than just the Core2. Specifically:
Why doesnt the Invensense website even list this chip? Is it custom made for M5Stack?
Has anyone figured out how to properly set the offsets? I found a library that measures them and then applies them externally but not actually setting them on the chip. (For example, register 19&20)
I was trying to find the chip on the website to determine if there were any further application notes or suggestions. Other Chips like the MPU-6050 have a DMP (Digital Motion Processor) component that would be great for gesture offloading. It doesn't appear this chip has this based on the datasheet listed on the M5 website)
Any Tips on calibrating these? Mine has a lot of noise when laying on a flat surface which I'm trying to reduce.
While reviewing the datasheet, it appears that the XA_OFFSET registers are 15bit signed ints not 16. It appears that most of the popular libraries written for the 6050, 9250 have this mapping incorrect.
Just to close the loop for anyone from the future...
Here's the steps I took to resolve this:
Dont touch the mac system python installs located at:
But in the end, from what I could find Mojave doesn't include pip by default, and easy_install is depreciated so we had to go to step 2.
brew install pythonToday in Dec 2020 this will install 3.9.0. ((Python 2.7 has been long depreciated))[Also note pip is currently installed with this version of python]
python --versionyou will still get:
ln -s /usr/local/bin/python3 /usr/local/bin/python
ln -s /usr/local/bin/pip3 /usr/local/bin/pipwhich cleaned up any remaining issues making pip work. (Biggest issue being me forgetting to type pip3)
python --versionI now get:
Which I believe is what is forcing the ardunio IDE to use the default MacOS python version. (See note in #1 about this being the protected default python that we shouldnt touch.)
Once I reopened Ardunio, this worked and verified without any issues.
sudo pip3 install --target /Library/Python/2.7/site-packages pyserial
This installed the required serial module and fixed the remaining issues.
I'm not sure I like the solution, but it is the only thing that has made it work. The "correct" fix would be to have esp-tool.py use the installed default python version instead of the specific one installed at /usr/bin.
Finally, as with all things in life, there is already an xkcd for this: https://xkcd.com/1987/
Maybe I'll open an issue with the esp-tool or Ardunio IDE and see what happens, but I dont believe this has anything to do with M5stack tools. Thanks for all who helped! (@Zontex & @lydericc )
When I run that command I get:
python --version Python 2.7.16
And when I try to import serial, I get the same error as with the esptool script:
Python 2.7.16 (default, Jan 27 2020, 04:46:15) [GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import serial Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named serial
So it appears that "pip" is symlinked to my python3 install, but "python" is still linked to the v2.7.16 default mac install.
Thanks again for your help, will wait for an update!
When I did that I got the following message:
pip install pyserial Requirement already satisfied: pyserial in /usr/local/lib/python3.8/site-packages (3.5)
So it appears that my system is using 3.8 already?
I appreciate your help in trying to figure this out!
So I tried your recommendations as suggested:
'pip3 install pyserial Collecting pyserial Using cached pyserial-3.5-py2.py3-none-any.whl (90 kB) Installing collected packages: pyserial Successfully installed pyserial-3.5
Traceback (most recent call last): File "/Users/User1/Library/Arduino15/packages/m5stack/tools/esptool_py/3.0.0/esptool.py", line 39, in <module> import serial ImportError: No module named serial
It appears that the v1.0.6 version of the board manager is not working. I believe its related to switching to esptool 3.00. The specific issue I'm running into is a compile error on line 39 of the esptool.py that is installed by the v1.0.6 board version, saying "can't import serial"
I tried to look deeper into the issue, it appears to be quite the ordeal with the esptool.py (quite a few issues listed in the script...) but it appeared the fix was to update the install to use pyserial.
I am using the latest version of Arduino 1.8.13 on Mac OS 10.14.6 . When I downgrade to 1.0.5 (v2.6 of esptool...) all of my issues disappear. I would open an issue on github but there didnt seem to be an appropriate place. Thank you!
Hello Friends! First time posting, so I wanted to introduce myself. What better way than to tell a tale of curiosity that almost killed the cat... or in this case my brand new Core2.
It all started as I was reviewing the documentation and the schematic. I noticed that the M5Stack Documentation site lists the ATECC608A, which I cant for the life of me find on the schematic. (https://docs.m5stack.com/#/en/core/core2) So my curiosity got the best of me and I decided the best course of action would be to take the Core2 apart to try and find the chip! I mean there are a couple screws on the back, it cant be that bad, right?!
Well, part 1 of my assumption was true. I took the 4 screws on the back off and carefully separated the back from the front. This part was relatively straight forward. The only surprise being to make sure that you catch the EXT board when you separate the parts because it'll come off quick. I sat and marveled at the board. Very clean and very well done. With the help of my cellphone camera, I was able to zoom in close enough to identify all the IC's on the board and the schematic. I should have stopped here, but I didn’t find what I was looking for. It was about then I noticed there were 2 additional screws at the bottom of the board.
If you decided to follow along on my journey. STOP. TURN BACK. DO NOT PASS GO. This is where things start getting sketchy. You should know, I'm no special anyone, I have no tools or expertise that would help on this journey. Just curiosity and sausage fingers. Undoing the 2 screws was pretty simple, but then trying to figure out how to release the main board became problematic. I finally figured out that you have to remove the speaker and the vib motor in order to slide the board back enough to allow it to clear the notch. Once that happened, I figured, "I'm in the clear" so I opened it carefully, but just a little too far. It's then I discovered that the LCD and touch ribbons are now disconnected from the two tiny ribbon connectors. In case you were wondering, the ATECC608A isn’t on the backside of the main board. Besides those connectors were some test pads and the button battery. (It's soldered in, and looked like a MS614).
After a LOT of time very carefully getting the ribbons put back in... which I somehow was able to do (again, see the part about having sausage fingers...) It came time to reassemble. All was going well, thought I had everything back. Reattached the battery, ran though the Factory Test Program and everything worked BUT the vib motor. Shoot. So after disassembling the 2nd time, I found that I hadn’t routed the wires properly and managed to knock the positive side of the motor off of the main board. Thankfully, the only tool I did have handy was a soldering iron with a needle tip. After some creative use of a cellphone zoom and a helping extra hand, I managed to get everything reconnected, reassembled and everything passed the factory test program on the next boot. YAY!
Moral of the story... don't take your Core2 all the way apart (or probably apart at all...)
Addendum: After reading the datasheet for the ATECC608A it very clearly calls out that "the part mark for all crypto devices is intentionally vague." So going back though the pictures I took, there appears to be a chip that matches the description just to the side of the USB-C port. I'm not sure, but the pad count is correct and its the right size so ** shoulder shrug emoji here ** ?
If anyone has any information about where this shown on the schematic or if you can use the chip at all from code, please let me know!
Nice to meet you! Thank you and enjoy your Core2!