version without qwiic switch for GauteH

[jerabaul29]

@gauteh which firmware version do you use? :) Do you usually use a turn key binary from https://github.com/jerabaul29/OpenMetBuoy-v2021a/tree/main/legacy_firmware/binaries (if so, which one? I guess one of the steval ones? :) ), or do you recompile? :)

I will adapt the corresponding firmware to use without qwiic switch, with pin D43 to provide power to the IMU :) .

[jerabaul29]

another note to myself: there will be no more connection with the qwiic cable, so I will have to set up another I2C port for the IMU that is available on header pins, and the jumper wires will have to connect to these.

[jerabaul29]

@trygvesovik :)

[jerabaul29]

( @trygvesovik which firmware do you flash on the AGT? - so I know which firmware to modify :) )

[trygvesovik]

We use the steval_gps_waves_drifter.bin file.

[jerabaul29]

Perfect! I have to go home now, but I will look into pushing a version without qwiic tonight, I keep you updated :) .

[trygvesovik]

Thanks!

[gauteh]

We need to know which pins to connect to sda,scl. Since the qwiic cable is necessary, there is no use in just wiring across the switch-footprint.

[jerabaul29]

Yes, I thought about this too after we had the discussion :) .

---

(a bit of digression)

This is a bit messy since I do not have the original schematics / there have been several PCB versions one after the other that may differ a bit, but I did a bit of investigation and I think that:

• the reason to use the qwiic cable is so that there was no need to distribute different versions of the firmware (back when I wanted to keep the number of firmware versions limited ^^ ) with different I2C ports - so since the qwiic port is the only way to access I2C port 4, using a cable allows to use the same firmware version.
• BUT (as a note) the PCB has default open pads between the I2C port 1 of the AGT and the qwiic switch (the SB 1, 2, 5, 7 pads, that are default open). Soldering these 4 connects the I2C port 1 to the in side of the qwiic switch. But since we are not going to use a qwiic switch anyway, no reason to solder these + add a jumper - it is simpler to add a jumper directly :) .

---

what I think is the best solution for you:

• I am going to update the firmware to both
  • replace I2C port 4 (the qwiic port) by I2C port 1 (the one already used by the GPS) for talking to the IMU
  • set up pin D43 to power the IMU

This way you can just connect (all AGT pins are broken out on the PCB, see the headers with through holes; all IMU pins are available as the corresponding through holes on the qwiic switch out side):

• GND AGT <-> GND IMU (i.e GND on the qwiic switch "out" side)
• D43 AGT <-> Vin IMU (i.e. 3.3V on the qwiic switch "out" side)
• SDA AGT <-> SDA IMU (i.e. SDA on the qwiic switch "out" side)
• SCL AGT <-> SCL IMU (i.e. SCL on the qwiic swith "out" side)

Does that make sense / is this clear? :)

I let you know when I have pushed the firmware (I will do my best but I do not have the hardware to debug just now, may need to iterate with you tomorrow :) ).

[gauteh]

Yes, that's perfect. We will try it out (using headers @trygvesovik so that we don't loose any AGT's).

[jerabaul29]

I have pushed:

• the firmware: https://github.com/jerabaul29/OpenMetBuoy-v2021a/tree/main/legacy_firmware/firmware/steval_gps_waves_drifter_noqwiicswitch (in case you find bugs, we can look at comparing the serial output to the firmware to pinpoint it :) )
• the binary: https://github.com/jerabaul29/OpenMetBuoy-v2021a/blob/main/legacy_firmware/binaries/steval_gps_waves_drifter_noqwiicswitch.bin

Then we should be all set :) . This is very similar (the code is actually nearly identical) to #97 , so we can share experience testing these across both groups :) .

So to summarize:

• the wiring is described above, let me know if anything is unclear
• the first time you run it, do it with serial output, so we can track down any possible but
• once things seem to work well with serial output enabled, it would be great if you could do:
  • a power consumption test
  • a "longer test" outside (typically a couple of days outside just to check there is no weird "time developing" bug :) ).

[trygvesovik]

Hello, when testing the new circuit board without qwiic switch, we received the error message "failed to start GNSS reboot". It was working until we connected the wires between SCL and SDA, so it seems like the problem is related to this. It also seemed to work with the qwiic switch, when using the old firmware, so all the components should be fine.

[gauteh]

I was wondering if there could be some I2C port collision? Or maybe the IMU is not turned properly off and thus causing trouble for the GPS?

[jerabaul29]

Right, now that you mention it, I think I remember needing to help @tnn77 a few years back with this same point when adapting their firmware version to use the same I2C port for both GPS and IMU. I look into this tomorrow :) .

[jerabaul29]

I will discuss this with @tnn77 to refresh my memory and get a copy of the fix I had done (I think I fixed this in some custom version for @tnn77 a few years back, but I do not remember the details).

I see 2 solutions:

• getting this to work with the shared port, or
• using the same I2C port as before, i.e. the one from the qwiic switch, by i) taking a qwiic cable, ii) cutting one connector off, iii) connecting the connector to the port on the AGT, and soldering the SCL / SDA wires directly to the PCB (color code: https://www.sparkfun.com/products/15081 ).

Maybe you can try the "cut and soldered cable" first (that should work out of the box, just changing back the IMU I2C port number), while I look in the "firmware fix" option? :)

[tnn77]

Hi, @jerabaul29.

I searched back to when you helped us to be able to use the PCBs instead of the Qwiic cables (you can follow the below link to see the fix you did).
Hope this helps.

https://github.com/jerabaul29/tracker_and_waves_instrument/issues/116#issuecomment-944190199

[jerabaul29]

Many thanks @tnn77 ! :) Btw I added one more fix to be able to use without qwiic switch - it may be needed to use it on your version too, I will hear back from the tests of @gauteh and @trygvesovik , if it is needed on your versoin too I let you know in your issue and I push a new firmware version for you too :) .

[trygvesovik]

@askbreivik

[tnn77]

Great, thank you so much, @jerabaul29

[jerabaul29]

notes from discussions on chat channels:

• with the newest firmware fix, this works fine now :)
• we need to check the power consumption - if it is too high, we need to investigate how to make sure all pins that should float are actually floating :) .