This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
I2C and MPU 9250 address change. (To slave - 0x69)
#1
Edit: Subject WAS: I thought I could save someone from i2C cursing... but after a lot of problems.... Well - scroll down - it is solved now! :-D

Yes cursing - not cruising! 
Spent quite some time in trouble shoot mode today. Had my Pi ready for installation in my boat with a pijuice UPS, a industrialberry.com  CAN HAT, as well as an I2C extender. First time everything tested together, but yesterday all but the I2C worked flawlessly at my desk. Some minor tweaking was desired to change the pijuice I2C adress, but that was programmable in the GUI, so no problem at all. 
Hooked it all up, data was coming through from all sources the CAN gave me B&G data, the I2C showed the Barometer card, and the I2C extender was blinking like disco lights. Then I realized - no MPU and pypilot data. Yanked it all out, triple checked connections and did what amateur like me could do. All of a sudden I a cartoonish ping in my head and I remembered the I2C address conflict from yesterday, and surely enough - both the CAN HAT and the MPU9250 are on 0x68. After some googling, the answer was easy. Set the AD0 to high by connecting the pin to 3.3V. That should set the slave address on it to 0x69 and we should be rockin' from there. 
Had my solder iron at home, so I got to prioritize woodwork instead for the rest of the day, but even that Openplotter related. :-D  It is a waveshare 13.3 inch touchscreen, but as the connectors are on the side of the screen, it needed some protection. 
#gettingthere
   
Reply
#2
It was s u p p o s e d to be that easy right...? Well it didn't work. The MPU9250 does not show up as 0x69. So question is - what did I do wrong. I connected AD0 to 3.3V but no action. Anyone with a solution?
Reply
#3
Have you read this http://forum.openmarine.net/showthread.php?tid=1484 ?
Reply
#4
(2020-03-28, 07:56 PM)e-sailing Wrote: Have you read this http://forum.openmarine.net/showthread.php?tid=1484 ?

Nope - thanks! Reading it it sounds like the jury (Sean) is still out about how good of an idea it is though. Strange thing is that the 9250 do not change when settting AD0 to high. More trials today...
Reply
#5
So - checked all my connectors, Used a voltmeter to check that i in fact had 3.3V on the AD0 - nothing. Not a sign of the damned MPU. I COULD remove the Canberry to resolve the conflict. That kind of defeats the purpose though, as I would like to get Compass data TO my N2K instruments.
Reply
#6
*having a dialog with myself here*
Think I might have solved it. Setting the AD0 to high was obviously not the ONLY thing I needed to do. The jumper attached to SJ2 has to be altered. https://cdn.sparkfun.com/assets/learn_tu...ingPCB.jpg
It was there - hidden in plain sight in the hookup guide. https://learn.sparkfun.com/tutorials/mpu...-guide/all

I will check back in and report the result....
#andIwillRTFM
Reply
#7
Here it is - the end of my frustration. The SJ solder now moved from middle-right to middle-left. That, and setting AD0 to high made the MPU 9250 available on I2C address 0x69. Now it is spitting out data and show up in Pypilot. 

*me happy*

Hope this is useful for someone else as well. 
   
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)