@m5stack said in SH200Q vs. MPU6886 vs. IMU scaling:

@mdevel1 The minimum acceleration measurement range of SH200Q is ± 4g. For details, you can refer to this datasheet.

Thanks, I've read the datasheet, but there is no general way to set the 4G scale through the IMU class. The only way is to detect the hardware, and duplicate the functionality of the IMU class for both chips (and inherit one from SH200Q class). I would like to use a general method, but since I only own MPU6886 versions, my code will be specific to this. If others have interest, this might change, so this is the reason behind my original question. I don't want to invest time to create more divergent code as my other two pull requests remained unanswered yet.

Hi,

I'm using the integrated IMU and found that the default accelerometer scale of 8G is too big, 4G or even 2G would be better. There is no support in the IMU class for setting the scale, and the current SH200Q and MPU6886 classes are incompatible: MPU6886 has AFS_2G as the first item in the enum, but SH200Q doesn't have a placeholder, and begins with AFS_4G (besides the former one having it public while the latter is protected). I understand the different hardware capabilities, but it seems to be too much effort to extend the IMU class to handle this well.
What is your opinion? Is anybody interested in a general solution, or the number of SH200Q devices is so small, I can safely go with the MPU6886 class matching my hardware?

For the record: the coulomb counter data is fixed, but still undocumented in the newest version of the library (not released yet, only on Github).
There was another issue with the newest version, with a fix that is not yet merged, and available only as a pull request.

There is a new case: 2019.10 Upgrade the bottom and add copper nuts. PCB is unknown in this version.

Image from Lang-Ship and M5Stack on Twitter

@maxrom

Hi, can you post pictures of the yellow PCB to the Different board versions topic? I'm going to copy the pics of @world101 there.

@mdevel1 said in Different board versions:

I will leave it alone for a day to verify (it can't power on now without attaching USB power, but continues with correct time measured from the power on after the upload)

I can confirm it now, if the battery voltage dops below a certain level, the RTC forgets the time, and it restarts counting from 2000-00-00 00:00:00 when external power is connected to the black PCB version (without the button battery).

@skink
Can you test with https://github.com/mdevel1/M5StickC_Battery_Monitor? The best would be logging the data via a serial port and uploading it to a file sharing site (with a complete charge/discharge cycle). I plan on adding some graphing (first on desktop, then on device) to the project in my (not enough) free time.

@maxrom said in Different board versions:

No blue wire. I have to say, it sounds like your black PCB could be a copy. Have you tested the RTC to see if it keeps time after the main battery has died? Without the button battery, I don't think it would work properly.

No blue wire in my second stick. It has a red wire in the same position. :)
I think if the main battery dies, my least concern would be the RTC time.
I uploaded the RTC example code (with the SetTime and SetData calls commented out) to my second stick now, which had its battery drained somehow (would not power on before plugging in to USB), and it started counting from 2000-00-00 00:00:00. This seems to be a strange new kind of Y2K bug, but it could confirm your theory. Since I did not upload any RTC code AFAIK to this stick, I will leave it alone for a day to verify (it can't power on now without attaching USB power, but continues with correct time measured from the power on after the upload)

@nsfilho
I'm sorry, I did not know that the code fails earlier, I just had to exclude the possibility that it can fail in a way which results the strange output from the AXP chip I was seeing when my screen was not working. This also means that my problem was different.
In this case I don't have any more ideas, except taking apart the stick completely very carefully (see the photos how it can break, and then desolder the LiPo battery (or just cut the cables separately, very close to the PCB). I don't know if your stick has the button battery (mine does not), and what is it connected to, but it's possible that it must be disconnected somehow too. When you don't have any batteries or power sources connected, you might try to discharge any capacitors nearby, which should definitely put the AXP chip in a known stable state without the risk of shorting and damaging any battery. I would then inspect the AXP chip, the PCB traces and the components nearby for shorts, cuts, corrosion or any anomaly. If nothing found, then try to power from USB (preferably with a current meter) and see what happens.
I'm not aware of others having the exact same problem, so yours might be unique.

@nsfilho Have you tried to upload my AXP data query code? I added the possibility to dump the results to USB as well as an external serial port, so no other device is needed for running it.