-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expected at least MoPi firmware version 3.05, got 138.10 instead. #20
Comments
Hi,
|
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.) |
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
With mopi connected and power running through it
Without mopi attached
|
Hi Paul, |
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+. |
OK Paul. We will wait for the results of your tests, then will decide the next step. |
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...
I still appear to have some instability in the responses from the mopi though
For reference this was taken on my model b, the previous one was on my b+
|
thanks paul; mail me your address again and I'll send another unit? On 30 September 2014 15:36, Paul Thomas notifications@github.com wrote:
Hamish Cunningham |
I've emailed you at your gate.ac.uk email with my address didn't want to put it here :) |
New one in the post; let us know how it goes! |
Got the replacement but have barely been home since, will try and give it a go this weekend |
I'm hoping this worked for you! Let me know if not... |
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 |
mopi --version? and does it repeat? tnx On 24 March 2015 at 12:49, Matioupi notifications@github.com wrote:
Hamish Cunningham |
mopi -version yes, it is repeatable. I've been trying to configure the inputs |
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... |
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? |
Le 24/03/2015 15:11, Lubo Bonchev a écrit :
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 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 Regards, Mathieu tel : +33 (0)6 87 30 83 59 |
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 |
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. |
There is no other i2c devices working at the same time : only pi with I've just stopped my weather station running a "old" B pi (not B+) and 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 Le 24/03/2015 15:36, Hamish Cunningham a écrit :
tel : +33 (0)6 87 30 83 59 |
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). |
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) |
The setup is : Raspberry Pi (I've been trying one version 2 and one version B, both
I've been trying 2 different power supplies (but not both at the same
the symptoms are the same in both cases : random but very frequent wrong I'm currently setting up a fresh new raspian install to recheck from Could there be an option in the monitoring daemon to force Regards, Mathieu Le 24/03/2015 16:05, Hamish Cunningham a écrit :
tel : +33 (0)6 87 30 83 59 |
The green LED is because the Li-Ion battery is not a default. It has to be programmed in the SimBaMonD.
Lubo |
sudo service simbamond restart -d should stop it rebooting IIRR; if you put that in /etc/rc.local it should never reboot |
Le 24/03/2015 16:21, Lubo Bonchev a écrit :
I can never see red flashing led. |
This is telling me that probably SimBaMonD is reading wrongly the MoPi status. |
if you run |
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 about i2c issues related to overclocking. I'll try to see if manually setting the clock as explained would allow mopi + pi2 overclocking option |
Great -- thanks for figuring that out! On 24 March 2015 at 15:56, Matioupi notifications@github.com wrote:
Hamish Cunningham |
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. |
Congratulations Matioupi! Great work! |
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). (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. |
The i2c communication was quite difficult to get working properly -- see Good luck and thanks for your input. Best h |
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:
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, |
Any ideas on the error below?
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 versionI 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.
The text was updated successfully, but these errors were encountered: