The thing uno and gps neo 6m serial problem/conflict?

Hello,

I’ve got a problem with softwareserial or altsoftserial.
I’m trying to use gps neo 6m with the thing uno (which is supposed to be a leonardo). When I use a script with only access to gps, it works, another script with only ttn access it works too.

When I mix the 2 scripts in one it says “NO GPS DETECTED” (after lora join). As ttn uno and gps use serial, I think it’s a serial problem. I tried different I/O pins for the gps and different library for serial.

I can’t handle it … Need help. Thanks in advance for your time !

Here is my script :

#include <TheThingsNetwork.h>
#include <TinyGPS++.h>
#include <AltSoftSerial.h>

const char *appEui = “xxxxxxxxxx”;
const char *appKey = “yyyyyyyyyyyyyyyyyyyyyyyy”;
int RXPin = 13;
int TXPin = 1;
int GPSBaud = 9600;
TinyGPSPlus gps;
AltSoftSerial gpsSerial(RXPin, TXPin);
#define loraSerial Serial1
#define freqPlan TTN_FP_EU868
TheThingsNetwork ttn(loraSerial,Serial, freqPlan);

void setup()
{
loraSerial.begin(57600);
Serial.begin(9600);
while (!Serial){
;
}
gpsSerial.begin(GPSBaud);
delay(500);
Serial.println(“-- STATUS”);
ttn.showStatus();
Serial.println(“-- JOIN”);
ttn.join(appEui, appKey);
// delay(5000);
}

void loop()
{
//Serial.println(“-- LOOP”);
while (gpsSerial.available() > 0) {
if (gps.encode(gpsSerial.read()))
displayInfo();
if (millis() > 5000 && gps.charsProcessed() < 10)
{
Serial.println(“No GPS detected”);
while(true);
}

}

byte payload[1];
payload[0] = (digitalRead(LED_BUILTIN) == HIGH) ? 1 : 0;
ttn.sendBytes(payload, sizeof(payload));
delay(50000);
}

void displayInfo()
{
if (gps.location.isValid())
{
Serial.print("Latitude: ");
Serial.println(gps.location.lat(), 6);
Serial.print("Longitude: ");
Serial.println(gps.location.lng(), 6);
}
else
{
Serial.println(“Location: Not Available”);
}
delay(1000);
}

If you want to check, in the first 5000mS of the board running, that the GPS is working, then put the check in startup().

Hello, thank for your answer,
I know my gps works, as I said when I use it without ttn It works…
I really think it’s a serial conflict…
Thanks anyway

Its just as well the GPS does not work, and yes it probably is a conflict, the sketch needs a re-write.

If the GPS were working you would be sending a packet into TTN once every 51 seconds, for an average working GPS.

If your using a GPS as a sensor then a more reasonable transmit gap, and to comply with the TTN fair use policy, is to send the GPS location about once an hour, forget once a minute.

Maybe the neo 6M doesn’t output NMEA anymore, the problem is discribed here: GitHub - eriktheV-king/TTGO_T-beam_GPS-reset: Reset U-blox NEO GPS devices on TTGO T-beam T22- V1.0 and 1.1 back to factory settings

If you have been explicitly sending config commands to a GPS, then its possible its now setup not to put out NMEA sentences, but that would not happen by accident.

Most likely there is a pin conflict, check the Things UNO schematic for details.

The character count method that the TinyGPSPlus library uses to check if a GPS is connected does nothing to tell you if the GPS is working and readable. The GPS can be ‘connected’ and putting out ‘characters’ but for various reasons will never produce a fix.

Far better as a diagnostic is to print a few seconds of the GPS output to the Serial monitor at startup, you can tell a lot from that output.

hello,
Ok for once an hour.
Anyway now it doesn’t send anything. Not even read anything !

Hello,
neo gps is working well when used without lora …That’s the conflict/problem.

Check the pins being used for the GPS !!!

Put this code in setup();

//display GPS output characters for 5000ms
  Serial.println(F("Startup GPS check"));
  uint32_t startmS;
  startmS = millis();
  while ( (uint32_t) (millis() - startmS) < 5000)       //allows for millis() overflow
  {
    if (gpsSerial.available() > 0)
    {
      Serial.write(gpsSerial.read());
    }
  }
  Serial.println(F("Check finished"));
  Serial.flush();

This, this and this.

Plus the interrupts and the ability of multiple pins to play nicely, so you need to look at the 32U data sheet to see if you are trying to achieve the impossible.

At least you know it’s the pins you are using for the GPS vs the LoRa serial port.

Yep .

Hello,
Thank for your answer. I’m gone check Things UNO schematic. When used alone (whithout Lora it works well and log correctly to serial monitor).
Regards

Thanks you,

Your script produce some good output in serial monitor.

When used alone the GPS works fine (aka log in serial monitor correctly).
The conflict seems to come from delay().
In fact, when using delay() in the loop, the gps won’t return anything valid. Without delay() it works.
Now I’ve got to find a way to NOT send gps data every second to TTN !
Than you.

Very great care is needed when software serial is used to read a GPS, if there is other stuff happening at the same time, such as other Serial.print() activity, then characters can be missed from the GPS, miss a character and a sentance is lost.

If you want reliable operation with software serial then you need to be sure all other stuff running in the background has been stopped, or use an Arduino with a spare hardware serial port.

In addition the use of if gps.encode(gpsSerial.read()) means that for every sentence the GPS produces, you go off and do stuff, but as standard there is only location data in 2 of the maybe 8 sentences the GPS is putting out.

In addition the use of if gps.location.isValid() means that you will still be putting out location data when the GPS may have stopped working.

Assuming the device isn’t moving too fast, you could just read the GPS for a few seconds, send the results and then sleep/delay for the appropriate amount to time.

Otherwise it will be all about tracking elapsed time in the main loop and once the appropriate amount of time has passed, then doing a send - a fairly standard technique.

Thank you for your answer.
In fact, I now use millis() instead of delay() and it works fine.
Regards

That being exactly what I suggested …

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.