Strange output from GPS on NB-IoT shield

Hi! I am running the example code for the GPS and get some weird characters in my output:

>> GPGSV,1,1,00
?? >> $GLGSV,1,1,00*65
?? >> $GNGLL,,,,,,V,N*7A
?? >> $GNRMC,,V,,,,,,,,,,N*4D
?? >> $GNVTG,,,,,,,,,N*2E
?? >> $GNGGA,,,,,,0,00,99.99,,,,,,*56
?? >> $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
?? >> $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E
parseGPGSV
>> GPGSV,1,1,00
?? >> $GLGSV,1,1,00*65
?? >> $GNGLL,,,,,,V,N*7A

I’m using the Crowduino M0 from the bundle and tried with two different boards/shields… Any ideas?

Hi!

This is NMEA data from a GPS module.
It will take a some time before you will get a valid GPS signal.

Go outside and wait for 30-60seconds to get a valid GPS position.
Indoors is will almost always be impossible to get a position.

Best regards,
Jan

Yes, I meant the “??” and the “*2E”'s. I compared to a Lora ONE and there it looks more like this:

>> GPGSV,1,1,00
>> $GLGSV,1,1,00
>> $GNGLL,,,,,,V,N
>> $GNRMC,,V,,,,,,,,,,N
>> $GNVTG,,,,,,,,,N
>> $GNGGA,,,,,,0,00,99.99,,,,,,
>> $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99
>> $GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99
parseGPGSV
>> GPGSV,1,1,00
>> $GLGSV,1,1,00
>> $GNGLL,,,,,,V,N

I sat outside for 10-15 minutes yesterday trying to get a fix, thought this might be related…

Same problem here, I’m using first SODAQ NO-IoT shield with an Arduino Leonardo.
Problem “solved” by using an external GPS receiver module…

Hi, I have the same problem. Tested outside and got 6 sat´s, but no fix in the cold.

I used this example: https://github.com/janvl1234/Sodaq_NBIoT_examples/blob/master/Sensors_NB-IoT/nbIOT_gps/nbIOT_gps.ino

Got this log:

.

GPGSV,2,2,06,24,72,255,47,33,19,210,38
?? >> $GLGSV,1,1,03,46,33,38*6F
parseGPGLL

GNGLL,5951.49135,N,01048.34726,E,205801.00,A,A
parseGPRMC

GNRMC,205802.00,A,5951.49126,N,01048.34742,E,0.031,191117,A
parseGPVTG

GNVTG,T,M,0.031,N,0.057,K,A
parseGPGGA

GNGGA,205802.00,5951.49126,N,01048.34742,E,1,05,4.01,124.4,M,38.4,M,
[scan] num sats = 5
[scan] datetime = 20171119205802
[scan] lat = 59.8581868
[scan] lon = 10.8057902
delay … 300000ms

But no fix…

Any suggestions?

That log appears to be showing a GPS fix.

The Lat & Long values are populated as is the number of satellites and the time epoch.

The $GLGSV NMEA sentence relates to the GLONASS system:
http://www.cypress.bc.ca/documents/Report_Messages/CTM200/msg_127_GLGSV.html

It seems that particular log entry is showing that it has not acquired a GLONASS based fix.

I agree with you Gabriel, so do you have any suggestion for how we modify the GPS example code so that it reports the coordinates when the GPS has a fix, without manually looking at the debug output?

I’m not completely familiar with that sketch, however, looking at the find_fix() method, there doesn’t seem to be any output if a fix is found, only if no fix is achieved.

Ok, thanks Gabriel. Will you please help me with an link to an working example? …or suggest what method to use?

Hi Lars,

You have a fix:

Now there is a 5 minute delay

After 5 minutes the next search a gps position will start. The time between gps searches is different.

uint32_t intervals[] = {

        // Do a few tests with 1 minute delay
        1UL * 60 * 1000,
        1UL * 60 * 1000,
        1UL * 60 * 1000,

        // Try a few longer delays
        2UL * 60 * 1000,
        2UL * 60 * 1000,
        5UL * 60 * 1000,
        5UL * 60 * 1000,

        // Slowly increase the delays
        15UL * 60 * 1000,
        30UL * 60 * 1000,
        1UL * 60 * 60 * 1000,
        3UL * 60 * 60 * 1000,
        4UL * 60 * 60 * 1000,
        8UL * 60 * 60 * 1000,
};

If there would be no fix you get the message “No Fix” also no error when queued for transmitting over NB-IoT.

In the main code only error messages are printed:

        if (!nbiot.sendMessage(message)) {
          DEBUG_STREAM.println("Could not queue message!");
        }
    } else {
        DEBUG_STREAM.println("No Fix");
        if (!nbiot.sendMessage("No Fix")) {
          DEBUG_STREAM.println("Could not queue message!");
        }

You can print the actual message before this block of code.
DEBUG_STREAM.println(message);

Do you have issues with recieving or decoding the nbiot messages?

Best regards,
Jan

Hmm, this seems strange. The lines that start with “[scan]” are printed by the library when debug mode is enabled. According to Lars_Gunnar, the issue is that the call to sodaq_gps.scan() in the example sketch never returns true and the corresponding lines without “[scan]” never get printed. However, in that case “No fix” should also be printed in the output like you pinted out Jan…

Hey Jan, Totally my mistake. I just overlooked the missing pintln for the message. Average time to get a fix is around 30 sec. Thanks!

1 Like

@Lars_Gunnar
I am happy that everything is working :slight_smile:

@albertskog
When you add the line:
DEBUG_STREAM.println(message);
Do you get all the information about the gps fix you want without the debug enabled?

Regards,
Jan

Alright, let’s try to sort this out :smile:

Originally, I was trying to verify my modified version of the example code. I had added a println but did not get a fix, and I was experiencing stray characters in the debug output (compared to LoRa One debug output), which I thought might be stopping the library from parsing the an actual fix correctly.

Then I thought @Lars_Gunnar had the same issue as me, but I did not have time to help him or test for myself recently, which was why I did not realize he was using your original example code and not the one with my added println.

@Lars_Gunnar is getting a fix now, so I assume everything is fine. If not, I will report back again.

Thanks guys, and sorry for my confusion :grin: