I’m building a little solution that comprises of a Pi 4B, PiJuice HAT, 5" TFT from DF Robot and some PiicoDev elements (915MHz transceiver + button). I’ve removed the PiJuice HAT from the equation for the moment but I think it might compound the issue I’m seeing, which I largely think is down to the 5" TFT from DF Robot.
With the Pi 4B and 915MHz PiicoDev transceiver attached, I can run some simple python script which simply waits until a data packet or message is received. This works fine, ie. i can leave it for 20 minutes and there are no warnings or anything untoward.
When I introduce the 5" TFT attached to the Pi 4B via an FPC cable into the equation I get warnings/errors sporadically (could be 5 minutes after starting the python script) saying
PiicoDev could not communicate with module at address 0x1A, check wiring. I have tried setting the ID for the PiicoDev transceiver to many different IDs but I still get the same sporadic issue. I sense the 5" TFT is somehow using the I2C bus and causing a conflict. When I do introduce other piicodev elements (ie. buttons / sensors) the PiicoDev could not communicate with module at address xxxx is more frequent and can cause my script to hang.
I note that in the DF Robot documentation it says to ground the surface mount nut - however there is no instruction anywhere that I can find to suggest which nut it’s talking about - i’m not sure if this will make a difference but it might do given it is written down twice in the
Last point - I have tried 3 separate Pi 4B’s, 2 separate 5" TFTs, 3 separate PiicoDev adapters + 915MHz transceivers - and each time the 5" TFT is attached I get the warnings / error above…
Any ideas on the ‘ground nut’ and / or any ID/addresses that might stop a clash between the 5" TFT and PiicoDev ?
A quick google found this: DFRobot 5" touchscreen - DFR0550 - Raspberry Pi Forums
so you might be able to get alternative drivers that will make it work.
The touch interface is using I2C, you can see that if you check the schematic on the DFRobot website, and its doesn’t appear to work correctly with the kernel driver.
This is just from a quick read, so its just some extra info to help you debug the issue.
Many Thanks Stephen, I will try that. I have made some progress too although now there’s an added complication…
I found that if I set the PiicoDev 915MHz transceiver to 0,0,1,1 and the PiicoDev button to 1,1,1,0 then I do not appear to experience the PiicoDev communication warning messages. However, when I introduce the PiJuice - it all fails… seems like PiJuice uses I2C as well… I’ll keep testing and I’ll take a good look at your link/feedback too. Thank You.
I think this might be my next cause of action to try and resolve the PiJuice clash… need help on how to change default I2C address of RTC · Issue #166 · PiSupply/PiJuice · GitHub . I’ll let you know how it goes…
One thing I will add is the 5" TFT from DF Robot is a lovely screen and seems to work well with the Pi 4B and Bullseye… (when there aren’t I2C clashes with PiicoDev that is)… PiJuice - don’t get me started on that, on the face of it it looks like a good product however I had the joys of trying to get the GUI to work and manual fixes on Bullseye, there appears to be no battery config for a 20,000mah battery, and even the standard BP7X battery shipped doesn’t have a config in the GUI and defaults to a PiJuice 12,000mah battery… and then there’s the silly plastic screws and crappy plastic spacers… but apart from that - it does the job, it’s ‘ok’… but hopefully I can resolve the I2C issue…
Thanks for linking that GitHub thread! If you run into any specific problems going down the address-change path, let us know and we’ll see what we can do
Sorry to hear the PiJuice hasn’t brought you joy, it’s definitely the most polished option for a Pi UPS.