Hello @obolland according to the schematic GNSS_TX becomes M5-RXD which is then available (depending on set dip switch) on GPIOs: 3, 13, 16, 34 or 35 which translates to pins 13, 22, 15, 26 or 2 on the M5 Stack bus. BTW: Since you are not stacking the module you can set all dip switches to 'on' at the same time (if you like). Note: I do not have the M5Stack GPS Module v2.1 so I cannot test this myself. Thanks Felix

@colintd I appreciate the follow-up, as I had been meaning to post back here as well. Happily (for me), it's no longer getting in my way since I did ultimately decide to port my project to using STM32Cube HAL API instead of Arduino Wire APIs. After that, I've had zero such issues. I realize that doesn't help folks much who are stuck using Arduino APIs for whatever reasons (or prefer those APIs -- there are some advantages). Your theory is interesting, though. I honestly don't remember how deeply I looked into inter-call delays and/or deeper status checking at the time. I could believe that perhaps the Arduino Wire API implementations on different hardware could also lead to subtle timing differences... and if it is also specific to the M5 PPS device, those docs aren't ultra-specific about what the device actually expects w.r.t. delays, etc. TL;DR: It was an interesting side quest, which I ultimately solved by changing middlewares. ╰(°▽°)╯

Your authentication failed because you are missing the keys for the rfid card. It does work in bruce but it`s really slow. you should notice that it does work when it pops out the uuid. Somehow Bruce seem to have trouble when you have to many custom keys on the key file try to keep it a really short list.

Hi, I encountered a similar issue. When the QR code reader is in auto-scan mode, if the barcode is scanned more than once while the main program is in a delay state (e.g., 5000 ms), the barcode reader stops responding after the delay ends, and the data can no longer be read. I also tried reading the barcode from the image in the previous post, but nothing changed. Additionally, I have confirmed that communication is restored and the device becomes usable again by unplugging and reconnecting the I2C cable. Is it possible to reset the barcode reader programmatically?

@RPI25 said in Is it possible to use the M5GO Bottom 3 with the Tab 5: M5GO Bottom 3 Hi RPI25 (and felmue) I am guessing (as you didn't say) that you want to use the Battery function of the M5GO to power the TAB5? Or is there another reason you wish to add the M5GO to the TAB5? With that said on the M5Stack Store it very specifically states that each "version" of the M5GOs are designed to work with a specific Core ONLY. I included a graphic as well: [image: 1769979322100-m5go.png] I did compare pinouts that were provided by Felix (thanks!) and again I am only guessing is that you are after the battery function? With that said I would simply purchase the battery (which I did do with my TAB5). I am curious about your project? Thanks-Brian

Hello @KAYDE1 maybe checkout this example here? To make it work I had to adapt the GPIO used for the LEDs: // buscfg.pin_data = 26; buscfg.pin_data = 25; I also added a delay(1000); at the end of the loop(). Thanks Felix

@cleatus007 using grove cable and connect to port on side of cardputer

@felmue @mlindholm I recently had the same problem with I2C on an M5STAMP C3U. The appropriate solution seems to be the @mlindholm one, but its sample code was a bit incomplete Here is a working example in the context of a DS3231 RTC A TwoWire structure needs to be inititalised specifically, then referenced by the used I2C library (if any ; RTC library in my case). No need for pullup resistor (in my case) #include <Wire.h> // Declare alternate I2C pins #define I2C_SDA 5 #define I2C_SCL 4 // Setup the TwoWire instance (static memory !) TwoWire I2CM5 = TwoWire(0); void setup () { ... // Initialise the TwoWire instance I2CM5.begin(I2C_SDA, I2C_SCL, 400000); // Ask the library to use this setting // (most I2C libraries accept a TwoWire object as argument of begin) rtc.begin(&I2CM5); ...