Open Jamos1988 opened 3 years ago
What are the addresses of your other i2c devices in use? PiJuice uses 0x14 and 0x68 (unless you changed them).
These are the other addresses:
I have a bme280 which is 0x68 so that would indeed be a conflict. But, the appearing and disappearing of 0x14 I don't understand.
Oh wait, no, correction 0x77 is my bme280 so there shouldn't be a conflict.
Could it be that the hat is only detected when in a certain mode? Does it need to be on? It is powered, so it just should be detected right?
Ah, there is an i2c conflict indeed. mpu9250 for gyro runs on 0x68. Could this also explain the 0x14 problem?
Anyway, I need to change the i2c address first to make any other further assumptions. And test without the MPU.
0x68 is the (simulated) ds1339 in the PiJuice mcu. So I guess the PiJuice gets confused by the mpu and v.v. Let us know what happens without the mpu. You can change the 0x68 address of the RTC, but you need the gui/cli with access to 0x14 for that.
Ok! Glad I don't need to solder anything. We plan to stock up this hat for our main product. We have big experience with Sixfab and Joy-IT and decided for PiJuice in the end. Seems more like a plug&play solution, other vendors work through serial connections, or have more complex API's. So far from the documentation the PiJuice including the software seems perfect. Just need to solve the i2c address I hope, and we have found our preferred product. :)
You know you can change the mpu9250 i2c address to 0x69 by pulling pin AD0 high? See the datasheet.
Yes, but in our assembly line every solder we can do less would be best. We are trying to select our devices that don't conflict by default. I am now thinking of how we will do this when mass producing. Either solder the MPU's or do something with the software of every PiJuice at first boot of the OS.
Quick question: Just fill it in here and reboot right?
Yes, but the COMMUNICATION ERRORs are not good. PiJuice not connected? Do you need the RTC in your product?
I'm not sure if I need the real time clock, the product has a 4G connection all the time and synchronizes the time through there. I might misunderstand, would there be another benefit from RTC? Is there a way to disable it?
The Pi is connected properly, but so is the MPU still. I'm working remotely so I don't have physical access to it yet. Just wanted to make the screenshot to know if I will do it right when I'll be there.
If you have an internet connection then you do not need the RTC. Except if you need features like the periodic wakeup. Even if you change the RTC address away from 0x68 you can still use the RTC alarm functions via the PiJuice API.
Thanks, then I know the added value. Is it possible though to disable the RTC by the way?
Not explicitly. The firmware will respond to the I2C address you specify for the RTC. Just use an address that is not used by you and avoid 0x68, since this is a common address for i2c based RTCs (and conflicts with your mpu9250)
Also another thing to mention is, when I do sudo i2cdetect -y 1 it will run through the first lines very slow, when it passes the first one or two lines, it will instantly show the other addresses. It seems the pijuice slows the first part of the sudo i2cdetect -y 1 process. I still need to test without the MPU however, will report on that. I just hope that will be it.
Board is detected OK now now the IMU is disconnected. Tried to change the RTC address to 69 or 70 but the changes are not applied instantly. Do I also need to reboot? In the GUI I read that the changes should be applied instantly.
Also worth mentioning, the battery charge stays 0% although the plastic cover has been removed, the battery tab detects the battery and the dip switch has been set properly. (Which it wasn't before, factory default) But, let's first just focus on the i2c address that I cannot change. Hope you can support me in this :)
A screenshot from my setup:
I am only connected by GPIO, so the PiJuice should be charging through that. Looking at the documentation my battery status is:
NORMAL - Battery is present but not charging
It is 0% but still not charging, so I'm trying to figure out why this is.
Can you check on the General tab of the HAT configuration window if charging is enabled? On your screenshot GPIO power input is NOT_PRESENT. Probably 'GPIO input enabled' is not checked on the same General tab (resulting also in no charging) See screenshot below.
I got it! There was not enough voltage for the charging to initiate apparently. 4.83v is not enough it seems, but 4.93 is enough:
this is caused by our custom PCB there was a few miliamps voltage drop due to the lane being not wide enough. We will widen the line/lane so the voltage drop is compensated. Our power supply is rated 3a continuously, so it should be a problem. We've tested it again by just soldering a thicker jumper wire as an extra very close to the PSU, and voila it is now charging!
...which leads me to the following question, at what voltage is charging initiated? ...is this something firmware defined? software defined, or hardware defined?
So, if in the future we have for example a bad power supply, we might have an alternative solution to just tweak the software a bit so it will charge by override?
So, for my other question, changing the i2c, this is not working for me. Any idea's on that?
Can you try to run this python script (and see if you get any errors):
!/usr/bin/python3
from pijuice import PiJuice
import time
pj=PiJuice(1,0x14)
rtcaddr = pj.config.GetAddress(2)
print ('RTC addr = ',rtcaddr)
print ("Setting RTC address to 0x6F")
ret = pj.config.SetAddress(2,'6F')
print('SetAddress return = ', ret)
time.sleep(0.1)
rtcaddr = pj.config.GetAddress(2)
print ('RTC addr = ',rtcaddr)
Here is my output when starting with RTC at 0x68:
pi@rpi-pj-mch:~ $ python3 rtcaddr.py
RTC addr = {'data': '68', 'error': 'NO_ERROR'}
Setting RTC address to 0x6F
SetAddress return = {'error': 'NO_ERROR'}
RTC addr = {'data': '6f', 'error': 'NO_ERROR'}
Hmm, when I try to run that script I get:
File "rtcaddr.py", line 1
!/usr/bin/python3
^
SyntaxError: invalid syntax
Ah, I needed a # right before the !/usr/ line. It now says:
RTC addr = {'data': '68', 'error': 'NO_ERROR'}
Setting RTC address to 0x6F
SetAddress return = {'error': 'NO_ERROR'}
RTC addr = {'data': '6f', 'error': 'NO_ERROR'}
Apologies for the missing initial #
.
So the RTC address change is working.
Can you check in the gui that it now also says 6f?
One thing: in the gui when you changed the rtc address field you should press return/enter. A popup then appears: Are you sure you want to change the address?
Yes, it is also visible in the GUI now. And, the ENTER part I totally did not realize! That's a rookie mistake hahaha. Well, that's now clear at least.
By the way, do you have any specifics on what voltage/milivolts are needed for charging to happen?
The upcoming 1.7 packages has firmware 1.5. Form the changelog for the 1.5 firmware:
- Fixed issue with wrongly marking GPIO input power as BAD when the power supply
voltage is close to the threshold. DPM voltage is changed from 4.76V to 4.68V.
This is related to your issue. This is the threshold for the voltage from the RPi to the PiJuice. If you want to try the 1.7 packages you can get them from https://github.com/PiSupply/PiJuice/tree/v1.7/Software/Install
That sound great! For producing larger amounts it would be great if they come with that newer firmware, is that something I can contact someone for? Or will 1.4 always be the standard. Another question, how can I manually install 1.7 software with 1.5 firmware?
I have just connected the Pijuice hat with default battery. After installation of the software (using the GUI) it showed "communication error"
At first I noticed that the i2c address was not showing with i2cdetect. However, after a reboot it did. But, after starting the GUI software it disappears again.
I am not sure which firmware I have, but I do know for sure the hardware connection is good. i2c bus is stable for all my other devices, just not the pijuice hat.
I use a compute module 3 (cm3 16GB) but it should be the same as the 3b+ (e.g. the gpio pins are mapped exactly the same) I'll try to do a firmware upgrade, but the showing / not showing of the i2c address is really strange to me.
Hope someone can assist me.