Bruce 1.11 and 1.11.1 CYD-2432S028 after 1.10.2 still waiting for GPS

[LOCOSP]

Describe the bug: Since version 1.11 when entering Wardriving or GPS Tracker got info Waiting GPS:

Steps To Reproduce:

• Device used: CYD-2432S028

Expected behavior: GPS is present just waitin for FIX and than shoud show GPS data

Actual behavior: Waiting GPS: [time counting]

Additional context / logs: GPS connected via bottom UART, all was working fine till version 1.10.2

[LOCOSP]

Ok I've solved it, just use new option GPS>Config>GPS Pins and change RX=1 , TX=3

[bmorcelli]

Have you tried different Baudrate values?

If none of them work, change the pin order on GPS>Config>GPS Pins menu and try again all the baudrates

[LOCOSP]

My joy was premature. I changed the GPS pins and I no longer get the message that it’s waiting for GPS, but after a 20-minute walk it still didn’t get a fix. As soon as I reprogrammed it to 1.10.2, the fix was acquired instantly. I haven’t checked the baudrates yet.

[F3nr1r404]

Im getting the same thing. Device c1101+ with at6668, baudrate:115200 rx:44 tx43.

[bl4k7en]

Ok I've solved it, just use new option GPS>Config>GPS Pins and change RX=1 , TX=3

oh thank you very much. works perfect now. :)

CYD 2432S028R Micro USB + USB C // Neo-6M GPS on TX (3) RX (1). Latest Version of bmorcelli Launcher + Bruce 1.11.1.

[pminervini]

This makes GPS work again on Bruce beta (and I guess 1.11) on a C1011 Plus -- the GPS module sits on 44/43 for RX/TX and this was messing with that:

boards/lilygo-t-embed-cc1101/interface.cpp (+2 -2)
    54      digitalWrite(SDCARD_CS, HIGH);
    55 -    pinMode(44, OUTPUT); // NRF24 on Plus
    56 -    digitalWrite(44, HIGH);
    55 +    // pinMode(44, OUTPUT); // NRF24 on Plus
    56 +    // digitalWrite(44, HIGH);

Not sure what's the best way to deal with this -- maybe an additional flag in the config file? @bmorcelli

@F3nr1r404 FYI

[bmorcelli]

I believe it is better check why the UART isn't initializing to communicate with the GPS then changing the device initialization.. because it will break the T-Embed Plus..

Maybe checking the gps code to disable this pin and restart the UART is a better approach.

[bmorcelli]

And be aware the CC1101 plus might break the TFT and SD communication when you start the GPS reading... Because you are constantly enabling/disabling the NRF24 SPI communication, "jamming" the SPI bus and jamming the 2.4Ghz at some point

I do not recommend using t-Embed cc1101 plus with GPS.

[pminervini]

@bmorcelli what about moving GPS RX to 43 and TX to -1?

[bmorcelli]

I don't know if it will work because UART needs rx/tx.. needs a lot of testing..

[pminervini]

@bmorcelli I was toying with a couple of GPS modules on a 8266 yesterday and just connecting the RX pin was enough to receive GPS data! that might do the trick -- can test and let you know, but what you proposed in https://github.com/pr3y/Bruce/issues/1702#issuecomment-3448698556 seems like the proper way to go at it

[F3nr1r404]

@bmorcelli I was toying with a couple of GPS modules on a 8266 yesterday and just connecting the RX pin was enough to receive GPS data! that might do the trick -- can test and let you know, but what you proposed in https://github.com/pr3y/Bruce/issues/1702#issuecomment-3448698556 seems like the proper way to go at it

I actually got it working so far no issues or slow downs in the software. Using the module i mentioned had to swap rx snd tx connection on the module. Set pins to 44 & 43 and plugged it in works every time. Tried it after a few days might have just been user error but works seamless now with the m5 stack module.