Expected at least MoPi firmware version 3.05, got 138.10 instead.

[Afterglow]

Any ideas on the error below?

Sep 15 22:47:18 raspberrypi pi: simbamon: starting...
Sep 15 22:47:18 raspberrypi pi: /usr/sbin/simbamon: version 4.0 running at Sep-15-2014-22:47:18
Sep 15 22:47:18 raspberrypi pi: simbamon: monitor frequency is 2 seconds
Sep 15 22:47:19 raspberrypi logger: simbamon: MOPI_STATUS is mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead.
Sep 15 22:47:19 raspberrypi logger: simbamon: invalid MOPI_STATUS (mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead.): will pause/retry...

When I run mopicli -e I variably get either full output showing firmware version 138.10, an error telling me I have 138.10 or the real version

pi@raspberrypi ~ $ sudo mopicli -e
Firmware version: 138.10
Serial number: 107
Status word: 20485
Verbose status:
  Source #1 active
  Source full (blue led)
  Source #1 good
  Source #2 low/not present
  User configured
Current source voltage: 48188
Source #1 voltage: 48188
Source #2 voltage: 0
Combined conf:
  Source type: PSU / DC adapter
  Maximum voltage: 14000 mV
  Good voltage: 14000 mV
  Low voltage: 14000 mV
  Critical voltage: 14000 mV
Source #1 conf: matching, see above
Source #2 conf: matching, see above
Power on delay: 0 seconds
Shutdown delay: 0 seconds
pi@raspberrypi ~ $ sudo mopicli -e
mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead.
pi@raspberrypi ~ $ sudo mopicli -e
Firmware version: 3.10
Serial number: 107
Status word: 50437
Verbose status:
  Source #1 active
  Source full (blue led)
  Power on delay set
  Shutdown delay set
  Source #1 low/not present
  Source #2 low/not present
  User configured
Current source voltage: 13884
Source #1 voltage: 13884
Source #2 voltage: 0
Combined conf:
  Source type: PSU / DC adapter
  Maximum voltage: 14000 mV
  Good voltage: 14000 mV
  Low voltage: 14000 mV
  Critical voltage: 14000 mV
Source #1 conf: matching, see above
Source #2 conf: matching, see above
Power on delay: 0 seconds
Shutdown delay: 0 seconds

I initially encountered the problem trying to configure the mopi for my 14v PSU, it seems like some values write fine but some won't write at all and then these errors start occurring randomly. I'm not really sure if its a hardware or a software issue.

[LuboBonchev]

Hi, Sorry for troubles you have with our product. The reports you are sending looks very strange for me ... The correct firmware version is 3.10, the serial number 107 is exported with it. Written in production records. Looks that the I2C bus is unstable, but why I can't say right now. Few questions, not only to you, to the people of the team also:

1. Which Pi model are you using? A/B/B+?
2. Fred, is that the right message if simbamond find not the 3.10 version of the firmware? Is version 4.0 the actual simabmond version?
3. If take MoPi out and run Pi from mains (+5V wall adapter) and send "sudo i2cdetect -y 1" what is the response? Please send the screen shot. Repeat the same with MoPi and PSU connected to it. No mains. The I2C bus is adding info (bits) to the correct information ... I have never seen that so far .... Awaiting replays. Cheers :-) Lubo

[guruthree]

I also think this is some form of I2C instability that we have not seen before. Version 4.0 is the correct simbamon version. mopicli will not run at all on anything other than firmware major version 3, even though the message says "expected at least". (This can and probably should be changed, but for the moment is leftover from much earlier versions of the code and firmware when we were still debugging everything.)

[Afterglow]

I appear to get the same behaviour on both my model B and my brand new model B+ delivered last week. i2c output is below taken from the B+. Also for reference i'm running this kernel

pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.12.28+ #712 PREEMPT Tue Sep 16 15:49:13 BST 2014 armv6l GNU/Linux

With mopi connected and power running through it

pi@raspberrypi ~ $ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- 0b -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Without mopi attached

pi@raspberrypi ~ $ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

[LuboBonchev]

Hi Paul, Once again, sorry for the troubles and thank you for cooperation to fix what is happening. I am trying to duplicate the case here without success so far. '0b' on the first screen shot is MoPi. 'UU' at address 3b on both screenshots is usual for most of the systems. Linux kernel has installed some driver at this address without device to be phisically connected. 'UU' at address 1b however I am seeing it for the first time and can't duplicate it here ... More strange is that you are getting it on two different PIs ... Hamis, would you send another MoPi to Paul to try it? Paul, to avoid mistakes: your MoPi, serial number 107, is stackable version, is that correct?

[Afterglow]

It is a stackable. I'll try and find a spare SD card and retest this with my model b and a fresh install. I get the same behaviour on both Pi's but I haven't tried the i2cdetect command on the b yet only the b+.

[LuboBonchev]

OK Paul. We will wait for the results of your tests, then will decide the next step.

[Afterglow]

I reinstalled a blank card with the newer 09-09 wheezy image from the raspberry pi website. I don't appear to have an i2c-1 anymore but if I run against /dev/i2c-0 with the mopi connected and powered I get...

pi@raspberrypi ~ $ sudo i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- 0b -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

I still appear to have some instability in the responses from the mopi though

pi@raspberrypi ~ $ for i in {1..25}; do sudo mopicli -e | grep version; done
Firmware version: 3.10
Firmware version: 3.10
mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead.
mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead.
mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead.
Firmware version: 3.10
Firmware version: 3.10
Firmware version: 138.10
mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead.
Firmware version: 3.10
Firmware version: 3.10
mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead.
Firmware version: 138.10
Firmware version: 3.10
Firmware version: 3.10
Firmware version: 138.10
mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead.
Firmware version: 3.10
Firmware version: 3.10
Firmware version: 3.10
mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead.
Firmware version: 3.10
mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead.
mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead.
Firmware version: 3.10

For reference this was taken on my model b, the previous one was on my b+

pi@raspberrypi ~ $ uname -a
Linux raspberrypi 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l GNU/Linux

pi@raspberrypi ~ $ apt-cache policy simbamond
simbamond:
  Installed: 4.0
  Candidate: 4.0
  Version table:
 *** 4.0 0
        500 http://archive.raspberrypi.org/debian/ wheezy/main armhf Packages
        100 /var/lib/dpkg/status

[hamishcunningham]

thanks paul; mail me your address again and I'll send another unit? best h

On 30 September 2014 15:36, Paul Thomas notifications@github.com wrote:

I reinstalled a blank card with the newer 09-09 wheezy image from the raspberry pi website. I don't appear to have an i2c-1 anymore but if I run against /dev/i2c-0 with the mopi connected and powered I get...

pi@raspberrypi ~ $ sudo i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 0b -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --

I still appear to have some instability in the responses from the mopi though

pi@raspberrypi ~ $ for i in {1..25}; do sudo mopicli -e | grep version; done Firmware version: 3.10 Firmware version: 3.10 mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead. mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead. mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead. Firmware version: 3.10 Firmware version: 3.10 Firmware version: 138.10 mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead. Firmware version: 3.10 Firmware version: 3.10 mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead. Firmware version: 138.10 Firmware version: 3.10 Firmware version: 3.10 Firmware version: 138.10 mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead. Firmware version: 3.10 Firmware version: 3.10 Firmware version: 3.10 mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead. Firmware version: 3.10 mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead. mopicli. Expected at least MoPi firmware version 3.05, got 138.10 instead. Firmware version: 3.10

For reference this was taken on my model b, the previous one was on my b+

pi@raspberrypi ~ $ uname -a Linux raspberrypi 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l GNU/Linux

pi@raspberrypi ~ $ apt-cache policy simbamond simbamond: Installed: 4.0 Candidate: 4.0 Version table: *\ 4.0 0 500 http://archive.raspberrypi.org/debian/ wheezy/main armhf Packages 100 /var/lib/dpkg/status

— Reply to this email directly or view it on GitHub https://github.com/hamishcunningham/pi-tronics/issues/20#issuecomment-57323422 .

Hamish Cunningham Professor of Computer Science, University of Sheffield, UK +44 7920 765 455 http://twitter.com/@HCunningham hamish@gate.ac.uk http://pi.gate.ac.uk http://hamish.gate.ac.uk http://gate.ac.uk

[Afterglow]

I've emailed you at your gate.ac.uk email with my address didn't want to put it here :)

[hamishcunningham]

New one in the post; let us know how it goes!

[Afterglow]

Got the replacement but have barely been home since, will try and give it a go this weekend

[hamishcunningham]

I'm hoping this worked for you! Let me know if not...

[Matioupi]

Hello, I just received a brand new Mopi from pimoroni and I am facing very similar issue with same firmware 138.10 version reported. I am using a raspberry pi 2

[hamishcunningham]

mopi --version?

and does it repeat?

tnx h

On 24 March 2015 at 12:49, Matioupi notifications@github.com wrote:

Hello, I just received a brand new Mopi from pimoroni and I am facing very similar issue with same firmware 138.10 version reported. I am using a raspberry pi 2

— Reply to this email directly or view it on GitHub https://github.com/hamishcunningham/pi-tronics/issues/20#issuecomment-85483195 .

Hamish Cunningham Professor of Computer Science, University of Sheffield, UK +44 7920 765 455 http://twitter.com/@HCunningham hamish@gate.ac.uk http://pi.gate.ac.uk http://hamish.gate.ac.uk http://gate.ac.uk

[Matioupi]

mopi -version /usr/sbin/mopi is at version 4.1

yes, it is repeatable. I've been trying to configure the inputs it is even halting my pi a few seconds after boot

[Matioupi]

I bought 3 of those, and the same issue is there with all 3 devices, so it looks like more like a software or pi2 related issue...

[LuboBonchev]

All devices sent the last week to Pimoroni passed production tests including data exchange with the Pi (firmware version, serial number, status, etc.). Nevertheless I can double check the production records, just in case. Which are the device serial numbers? Thanks.

[Matioupi]

Le 24/03/2015 15:11, Lubo Bonchev a écrit :

All devices sent the last week to Pimoroni passed production tests including data exchange with the Pi (firmware version, serial number, status, etc.). Nevertheless I can double check the production records, just in case. Which are the device serial numbers? Thanks.

— Reply to this email directly or view it on GitHub https://github.com/hamishcunningham/pi-tronics/issues/20#issuecomment-85510996.

Hello,

devices are 1233 1169 and 1179

from http://www.raspberrypi.org/forums/viewtopic.php?t=97314

it seems that i2c got some changed on the pi recently. Could it be related ?

it strange that sometimes, I can start "sudo mopi" without any error and then when going to choice status, the correct firmware version is reported. This can be the case for 5/6 times in a row and then other values appears and usually the system do halt on it's own.

I've been trying another power suply in case :

with a 12V wall supply, I got a blue LED, with the 8V li-ion battery pack, the led is green, but with both power supply, symptoms are the same.

Regards,

Mathieu

tel : +33 (0)6 87 30 83 59

[hamishcunningham]

from http://www.raspberrypi.org/forums/viewtopic.php?t=97314
it seems that i2c got some changed on the pi recently. Could it be related ?

I think this is the device tree change that we fixed with the 4.1 release.

As there is a working i2c connection some of the time, this should not be the same issue (as that one resulted in the i2c module not being loaded by the kernel).

Do you have any other i2c devices working with that Pi, or any other way of testing the i2c bus?

Thanks

Hamish

[LuboBonchev]

Production records for all 3 devices are OK. I am also looking to i2c bus. We do not have terminating resistors at MoPi end. Relay on those soldered on the Pi/Pi2, as is the suggestion from raspberrypi.org. If one of these resistors does not exists, similar things can happen on the bus.

[Matioupi]

There is no other i2c devices working at the same time : only pi with the mopis

I've just stopped my weather station running a "old" B pi (not B+) and tryied with it after upgrading raspbian (full update/upgrade/dist-update/rpi-update) : I got the very same symptoms where the correct firmware version can be read only once out of several times, and the pi halt on it's on rather randomly and rather quickly

logical induction seems to say... it's not only pi2 related...

As for testing i2c bus, you'll have to give hint. I have a DSO-2090 USB oscilloscope but no clues on i2c internals...

Le 24/03/2015 15:36, Hamish Cunningham a écrit :

from http://www.raspberrypi.org/forums/viewtopic.php?t=97314 it seems that i2c got some changed on the pi recently. Could it be related ?

I think this is the device tree change that we fixed with the 4.1 release.

As there is a working i2c connection some of the time, this should not be the same issue (as that one resulted in the i2c module not being loaded by the kernel).

Do you have any other i2c devices working with that Pi, or any other way of testing the i2c bus?

Thanks

Hamish

— Reply to this email directly or view it on GitHub https://github.com/hamishcunningham/pi-tronics/issues/20#issuecomment-85528820.

tel : +33 (0)6 87 30 83 59

[hamishcunningham]

Do you have anything else connected to GPIO, or any other external wiring that might be interfering?

Did I understand correctly that the problem occurs when there are two supplies connected, but not when either is connected on its own?

I can't reproduce it at present; I've connected 2 supplies, a Pi 2 and a MoPi (though not one of the most recent batch).

[Afterglow]

Sorry I never got back on this it slipped my mind. When you guys sent out a replacement mopi to me it didn't help my issue so now I have two mopi units and 2 or 3 different raspberry pi's that show the same symptoms at least as I recall I haven't had time to check into it for months. If there was something specific you needed me to run to dump the i2c bus or whatever then let me know and I will have a look tonight.

(Also if you want the other mopi back let me know where to send it)

[Matioupi]

The setup is :

Raspberry Pi (I've been trying one version 2 and one version B, both updated to latest raspian and latest firmware) and Mopi and nothing else at all

• no main supply through micro USB
• nothing else than Mopi on any other GPIO pins

I've been trying 2 different power supplies (but not both at the same time, only one at a time, and always on source #1) :

• one wall 12V 4A. This supply gives a blue LED on Mopi
• one fully charged CGA-D54S battery (Li-Ion) : 8.2V at 0 load with the multimeter. This supply gives a green LED on Mopi

the symptoms are the same in both cases : random but very frequent wrong firmware readings, leading to unwanted pi halts

I'm currently setting up a fresh new raspian install to recheck from there... I'll let you know soon.

Could there be an option in the monitoring daemon to force preventing/forbid halts ? This is really annoying when trying to investigate !

Regards,

Mathieu

Le 24/03/2015 16:05, Hamish Cunningham a écrit :

Do you have anything else connected to GPIO, or any other external wiring that might be interfering?

Did I understand correctly that the problem occurs when there are two supplies connected, but not when either is connected on its own?

I can't reproduce it at present; I've connected 2 supplies, a Pi 2 and a MoPi (though not one of the most recent batch).

— Reply to this email directly or view it on GitHub https://github.com/hamishcunningham/pi-tronics/issues/20#issuecomment-85543155.

tel : +33 (0)6 87 30 83 59

[LuboBonchev]

The green LED is because the Li-Ion battery is not a default. It has to be programmed in the SimBaMonD. MoPi can force Pi to halt in 2 cases:

1. The power source is low. The MoPi's LED is flashing red and the Pi will shutdown in 30 seconds.
2. The MoPi receives the delayed shutdown command from the Pi (or accept another command as delayed shutdown due to i2c bus instability). Then after the programmed time delay it will shut off the Pi. Above is from the hardware point of view.

Lubo

[hamishcunningham]

Could there be an option in the monitoring daemon to force
preventing/forbid halts ? This is really annoying when trying to
investigate !

sudo service simbamond restart -d

should stop it rebooting IIRR; if you put that in /etc/rc.local it should never reboot

[Matioupi]

Le 24/03/2015 16:21, Lubo Bonchev a écrit :

The green LED is because the Li-Ion battery is not a default. It has to be programmed in the SimBaMonD. MoPi can force Pi to halt in 2 cases:

1. The power source is low. The MoPi's LED is flashing red and the Pi will shutdown in 30 seconds.
2. The MoPi receives the delayed shutdown command from the Pi (or accept another command as delayed shutdown due to i2c bus instability). Then after the programmed time delay it will shut off the Pi. Above is from the hardware point of view.

Lubo

— Reply to this email directly or view it on GitHub https://github.com/hamishcunningham/pi-tronics/issues/20#issuecomment-85549964.

I can never see red flashing led. after i see the "halt messages" on the pi, the mopi itself remains powered with led on (while pi is off)

[LuboBonchev]

This is telling me that probably SimBaMonD is reading wrongly the MoPi status.

[LuboBonchev]

if you run sudo i2cdetect -y -1 how many i2c devices are you seeing? Have to be only one: MoPi at address 0x0B.

[Matioupi]

with the fresh raspbian install everything works... and the difference was... overclocking

it seems that i2c bus get fooled with overclocking (especially the pi2 option)

I found this thread : https://github.com/raspberrypi/firmware/issues/212

about i2c issues related to overclocking. I'll try to see if manually setting the clock as explained would allow mopi + pi2 overclocking option

[hamishcunningham]

Great -- thanks for figuring that out! Best Hamish

On 24 March 2015 at 15:56, Matioupi notifications@github.com wrote:

with the fresh raspbian install everything works... and the difference was... overclocking

it seems that i2c bus get fooled with overclocking (especially the pi2 option)

I found this thread : raspberrypi/firmware#212 https://github.com/raspberrypi/firmware/issues/212

about i2c issues related to overclocking. I'll try to see if manually setting the clock as explained would allow mopi + pi2 overclocking option

— Reply to this email directly or view it on GitHub https://github.com/hamishcunningham/pi-tronics/issues/20#issuecomment-85572941 .

Hamish Cunningham Professor of Computer Science, University of Sheffield, UK +44 7920 765 455 http://twitter.com/@HCunningham hamish@gate.ac.uk http://pi.gate.ac.uk http://hamish.gate.ac.uk http://gate.ac.uk

[Afterglow]

This might explain my problems as well I think I was just turning it on by default in the raspbian first boot configuration menu thing. I will try and check later.

[LuboBonchev]

Congratulations Matioupi! Great work! Best, Lubo

[Matioupi]

Thanks.

on the pi2, i reenabled the pi2 overclocking setting and changed the i2c clock to 50000 instead of 100000 (as far as I understood in the above thread about i2c clock and overclocking, core_freq goes from 250 to 500 when overclocking with pi2 setting and you have to artificially compensate at i2c clock level). After a lot of tries, it seems that the correct way to do that is to modify the /boot/config.txt file for the line : dtparam=i2c=on and replace it by : dtparam=i2c=on,i2c_baudrate=50000

(all other ways of passing the baudrate option to the module upon boot seems to fail e.g. /etc/modules file or /etc/modprobe.d option files)

With that setting, Mopi seems stable with overclocking to setting pi2 on raspi-config. Altough I must say I've not been running that configuration for a long time yet and must still say "seems stable"

Anyway, maybe this "issue" showed a little lack of robustness in the protocol between mopi and raspberry pi. Could it be than some checks are done before sending the halt command (some kind of checksum or double readings ? forcing the firmware version to a given value before accepting any reading and doing actions)

I would be happy to put hands on for that. Do you have some kind of developper documentation or advice for a place to start ?

Aside that, I'm a little surprise by the voltage delivered on the 5V rail. With a 7.8V battery (under full load with raspberry pi on), there is only 4.65V (calibrated multimeter) on the 5V rail, and the little rainbow square telling that the pi is a little underpowered keeps displaying. No special devices are attached (only a Rii miniture wireless + mouse keyboard)

This is true even when overclocking is Off (setting None). I've not tried with higher voltage battery yet.

[hamishcunningham]

Anyway, maybe this "issue" showed a little lack of robustness in the protocol between mopi and raspberry pi. Could it be than some checks are done before sending the halt command (some kind of checksum or double readings ? forcing the firmware version to a given value before accepting any reading and doing actions)

I would be happy to put hands on for that. Do you have some kind of developper documentation or advice for a place to start ?

The i2c communication was quite difficult to get working properly -- see mopiapi.py for the current approach; IIRR it already does "averaging" over several calls. You're very welcome to try to improve it and get overclocking to work!

Good luck and thanks for your input.

Best

h

[LuboBonchev]

Re the 5V power: MoPi is using switching power supply and the output voltage is not depending on the input voltage, until the input is higher than 6V. Yes, MoPi is supplying a little less than 5V to be able to sense when the Pi is supplied locally, by the micro USB adapter. This does not give issues so far.

Re the I2C reliability: we will take this story into account and will evaluate the issue further. If you like to join - welcome! Seems the "averaging" only is not enough. Maybe one CRC byte will help, but I am afraid of 2 points:

1. The MoPi firmware need to be changed also, which is difficult when have so many units on the filed. To re-program the MoPi the users will need a special programmer, which is not obvious.
2. If the "averaging" does not help, means that there are too many wrong readings. Well, CRC can reject all of them, but then how many will remain and how SimBaMonD will work? Presently we are working on the next MoPi version, which has to implement HAT requirements. Having the overclocking issue into account we will consider how to facilitate firmware upgrade at the user place. Shall try to increase the speed of the I2C bus, much higher than 100KHz, because as far as I understand the overclokcing affects the clock frequency directly.

Of cource you are welcome to join to all further developments, if you like. Thanks for your great work and help to understand and fix the issue.

Best, Lubo