Func get module info

[mayopan]

Refer to #103

0. Added getModuleInfo function on library (Same as add func getModuleInfo and example #103)
1. Rewrote example8_1 to fit ATmega328p.
   2.Added example20_1 (You can use getModuleInfo function without merging this PR to library)

First, PR works well on both arduino nano and arduino pro mini that uses ATmega328p.
@PaulZC concerns about RAM usage, but there is a room yet shown below.

Processing nanoatmega328 (platform: atmelavr; board: nanoatmega328; framework: arduino)

---

Verbose mode can be enabled via -v, --verbose option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelavr/nanoatmega328.html
PLATFORM: Atmel AVR 2.0.0 > Arduino Nano ATmega328
HARDWARE: ATMEGA328P 16MHz, 2KB RAM, 30KB Flash
PACKAGES:

• framework-arduino-avr 5.0.0
• tool-avrdude 1.60300.190628 (6.3.0)
• toolchain-atmelavr 1.50400.190710 (5.4.0)
  Converting Example8_1_GetModuleInfoOnUART.ino
  LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
  LDF Modes: Finder ~ chain, Compatibility ~ soft
  Found 10 compatible libraries
  Scanning dependencies...
  Dependency Graph
  |-- <SPARKFUN_UBLOX_ARDUINO_LIBRARY_H>
  | |-- 1.0
  |-- 1.0
  Building in release mode
  Compiling .pio/build/nanoatmega328/src/Example8_1_GetModuleInfoOnUART.ino.cpp.o
  Linking .pio/build/nanoatmega328/firmware.elf
  Checking size .pio/build/nanoatmega328/firmware.elf
  Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
  RAM: [========= ] 88.7% (used 1817 bytes from 2048 bytes)
  Flash: [====== ] 56.2% (used 17252 bytes from 30720 bytes)

The SoftwareSerial is slow compared with (hardware) Serial, so 19200 or lower baud rate should be used. And if the AutoPVT is enabled in high rate, it's better to be disabled before polling module info.

Second, I made a example that enable this function using SendCustomCommand without library change, followed by @PaulZC advice.

It works nearly good, but something wrong.
A part of the received payload is overwritten(?).
example8_1 works good, but example20_1 doesn't.
Is there any advice?

The result of example20_1 is shown below.

SparkFun Ublox Example
Connecting GPS at 9600 baud... is failed.
Connecting GPS at 19200 baud is success!
Polling module info
Sending: CLS:MON ID:0x4 Len: 0x0 Payload:
sendCommand: Waiting for No ACK response
Incoming: Size: 250 Received: CLS:MON ID:0x4 Len: 0xFA Payload: 45 58 54 20 43 4F 52 45 20 33 2E 30 31 20 28 31 30 37 39 30 30 29 0 0 0 0 0 0 0 0 0 53 42 41 53 3B 49 4D 45 53 3B 51 5A 53 53 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 58 0 0 0 47 50 53 3B 47 4C 4F 3B 47 41 4C 3B 42 44 53 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 50 52 4F 54 56 45 52 3D 31 38 2E 30 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4D 4F 44 3D 4E 45 4F 2D 4D 38 4E 2D 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 46 49 53 3D 30 78 45 46 34 30 31 35 20 28 31 30 30 31 31 31 29 0 0 0 0 0 0 0 0 0 47 50 53 3B 47 4C 4F 3B 47 41 4C 3B 42 44 53 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 53 42 41 53 3B 49 4D 45 53 3B 51 5A 53 53 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
packetCfg now valid
packetCfg classAndIDmatch
processUBX: counter hit MAX_PAYLOAD_SIZE
waitForNoACKResponse: valid data with CLS/ID match after 3239837908 msec

Module Info :
Soft version: EXT CORE 3.01 (107900)
Hard version:
Extensions:7
;QZSS
LO;GAL;BDS
PROTVER=18.00
MOD=NEO-M8N-0
FIS=0xEF4015 (100111)
GPS;GLO;GAL;BDS
SBAS;IMES;QZSS

Done!

The result of example8_1 is shown below.

SparkFun Ublox Example
Connecting GPS at 9600 baud... is failed.
Connecting GPS at 19200 baud is success!
Polling module info
Sending: CLS:MON ID:0x4 Len: 0x0 Payload:
sendCommand: Waiting for No ACK response
Incoming: Size: 250 Received: CLS:MON ID:0x4 Len: 0xFA Payload: 45 58 54 20 43 4F 52 45 20 33 2E 30 31 20 28 31 30 37 39 30 30 29 0 0 0 0 0 0 0 0 30 30 30 38 30 30 30 30 0 0 52 4F 4D 20 42 41 53 45 20 33 2E 30 31 20 28 31 30 37 38 38 38 29 0 0 0 0 0 0 0 0 46 57 56 45 52 3D 53 50 47 20 33 2E 30 31 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 50 52 4F 54 56 45 52 3D 31 38 2E 30 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4D 4F 44 3D 4E 45 4F 2D 4D 38 4E 2D 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 46 49 53 3D 30 78 45 46 34 30 31 35 20 28 31 30 30 31 31 31 29 0 0 0 0 0 0 0 0 0 47 50 53 3B 47 4C 4F 3B 47 41 4C 3B 42 44 53 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 53 42 41 53 3B 49 4D 45 53 3B 51 5A 53 53 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
packetCfg now valid
packetCfg classAndIDmatch
processUBX: counter hit MAX_PAYLOAD_SIZE
waitForNoACKResponse: valid data with CLS/ID match after 210 msec

Module Info :
Soft version: EXT CORE 3.01 (107900)
Hard version: 00080000
Extensions:
ROM BASE 3.01 (107888)
FWVER=SPG 3.01
PROTVER=18.00
MOD=NEO-M8N-0
FIS=0xEF4015 (100111)
GPS;GLO;GAL;BDS
SBAS;IMES;QZSS

Done!

[PaulZC]

Hi @mayopan ,
Thank you for this PR!
Something that you need to know is that: even if the compiler says your code does not use all of the RAM, problems can still happen.
The ATmega328P has 2K Bytes of RAM. If we allocate another 340 bytes for your module info function in the library, bad things could happen.
The compiler gives you a warning:

Sketch uses 16670 bytes (51%) of program storage space. Maximum is 32256 bytes.
Global variables use 1743 bytes (85%) of dynamic memory, leaving 305 bytes for local variables. Maximum is 2048 bytes.
Low memory available, stability problems may occur.

The Low memory available, stability problems may occur. warning is very important. When the code in your .ino calls a function, it will push information onto the stack which uses even more RAM. Even with 305 bytes available, bad things can still happen. The stack use is not included in the dynamic memory calculation from the compiler.
Also, if a user wants to include another library, in addition to the u-blox library, then even more memory is used.
So, I am sorry, we cannot merge this new PR because it takes too much RAM.

Something that can help is: where you use (e.g.):

Serial.println("Module Info : ");

always use this way instead:

Serial.println(F("Module Info : "));

The first way stores the "Module Info : " in RAM. The second way stores it in program memory.
Now the compiler says:

Sketch uses 16678 bytes (51%) of program storage space. Maximum is 32256 bytes.
Global variables use 1603 bytes (78%) of dynamic memory, leaving 445 bytes for local variables. Maximum is 2048 bytes.
Low memory available, stability problems may occur.

It is better, but bad things could still happen.

Now, your example 20_1 is really nice!
The reason it isn't working properly is that you forgot to

#define MAX_PAYLOAD_SIZE 384

before the

#include "SparkFun_Ublox_Arduino_Library.h"

If the #define MAX_PAYLOAD_SIZE 384 is missing, only 256 bytes are allocated for the payload. The module information exceeds that.
Your example 8_1 only works beacuse of luck! The code is lucky that the bytes that go beyond 256 do not get overwritten (e.g. by the stack) before you read them.

Please try this example. It is the same as yours but is written for I2C (which most u-blox users use).

https://github.com/sparkfun/SparkFun_Ublox_Arduino_Library/tree/testing_mayopan_module_info

https://github.com/sparkfun/SparkFun_Ublox_Arduino_Library/blob/testing_mayopan_module_info/examples/Example21_ModuleInfo/Example21_ModuleInfo.ino

Here is the output from a ZED-F9K:

SparkFun Ublox Example
Polling module info

Module Info : 
Soft version: EXT CORE 1.00 (344bdb)
Hard version: 00190000
Extensions:6
  ROM BASE 0x118B2060
  FWVER=LAP 1.01
  PROTVER=30.00
  MOD=ZED-F9K
  GPS;GLO;GAL;BDS
  QZSS

Done!

If you take this example and submit it as a new PR on the master branch, then I will merge it for you.
You have worked hard on this and you deserve the credit!
Very best wishes,
Paul

[mayopan]

Hi, @PaulZC

Thank you very much for your kind and very useful advice!!!

The Low memory available, stability problems may occur.

Yes! I notice it on this issue now.
And I 100% agree with the rejection of adding getModuleInfo function on library.

According to your new example, I modified again to fit UART connection (because I don't have any GPS modules with I2C output), and it works perfectly!

The critical point of mine is that it uses too much RAM, as you say.
I deleted the section of searching baud rate of UART, and applied F("text") method.
It reduces RAM usage about 10%, and it works.

On the other hand, the change of MAX_PAYLOAD_SIZE makes no difference on "processUBX: counter hit MAX_PAYLOAD_SIZE" warning. (Of course RAM usage is increased.)
The module info payload size should be 30 + 10 + 30 X extentions (ZED-F9K: 6, M8N: 7) =
220 bytes(ZED-F9K)
250 bytes(M8N)
I think the default MAX_PAYLOAD_SIZE (256) is enough for both. Why does the warning apear?
Anyway, the gotten info is correct, and stable on many times, so it's not a big matter.

Now, I'm glad to hear my name is on credit in the example you cleaned up!

you take this example and submit it as a new PR on the master branch

OK, I'll do in short time.
I'm a beginner of github, so is my understanding shown below correct?

1. I have SparkFun_Ublox_Arduino_Library master branch in my repo already.
2. Add example21_ModuleInfo folder and put the example21_ModuleInfo.ino
   not to func_get_module_info branch but to master branch
3. Submit a new PR from it
4. Close this draft PR

Best regards,
mayopan

[mayopan]

I think I did it!
Should I delete the branch?

[PaulZC]

Hi @mayopan,
PR #106 has been merged so, yes, you can safely delete your branch. Thank you.
Looking at your example 8_1, it looks like you still have the NMEA messages enabled? Maybe that is what you expect, or need. When the extra bytes are read by the library, they can cause the maximum payload size to be exceeded (even though they are not a UBX message). In the I2C examples, we prevent this by calling:

myGPS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise)

This turns off all of the NMEA messages, leaving only UBX.
For Serial / UART1, you can do the same thing by calling:

myGPS.setUART1Output(COM_TYPE_UBX); //Set the UART1 port to output UBX only (turn off NMEA noise)

Or, if you need to leave some NMEA messages enabled, you can selectively turn off individual NMEA messages with (e.g.):

myGPS.disableNMEAMessage(UBX_NMEA_RMC, COM_PORT_UART1); // Disable the NMEA RMC message on UART1

Have fun!
Paul

[mayopan]

Hi, @PaulZC
Thank you for the merge of PR #106!
Staying home makes me step up the programming skill!

Actually, I'm using M8N GPS module that has the RAM for saving the configurations.
And also I have M8Q GPS module with no RAM, that always starts from the default setting (9600baud, 1Hz NMEA enabled, ...).
The saved configuration in M8N is that the NMEA output is disabled, AutoPVT with 5Hz is anabled.
So I do nothing on the former, but disable the latter in example8_1.

M8Q module has just 2 extensions of module information. There is no "counter hit" warning without disabling NMEA.

I don't understand very much about such difference now, but I'll post if I find something.

Best regards,
mayopan