I recently ordered a GPS+Glonass module from Quectel and designed an evaluation board for STM32 Nucleo64. The module itself is provided with a patch on top "POT" antenna and doesn't require more hardware than an UART port and some IO's to be operated.
The evaluation board is as simple as a two-sided PCB that is stackable with arduino connectors of the STM32L152RE board. It is possible to select the operating voltage from either regulated 3.3V or external 5V with a 2.54mm jumper (the board is provided with a low dropout LDO). The schematic is outstandingly simple and only 5 signals are available to the MCU ie. Rx/Tx for serial communication and 3 others IO's as show below:
Here's a 3d view of the shield:
An archive containing gerber files and BOM is available for download here.
Communication with the module must meet the MTK NMEA 0183 specification and every communication must be terminated with a 8-bit checksum. This windows form application simplify the communication with L86 module by computing the checksum and proving information about module's responses. As the L86 has an embedded non-volatile memory and support the LOCUS feature, it is also possible to clear or dump this memory from this application.
I developped an evaluation project with the L86 and a STM32L152RE Nucleo64. It has been written with Keil but the driver is adaptive and I guess it can be easily usable on others IDE. The purpose of this project is to acquire positionning data at regular interval of time and to store them in the MCU's embedded EEPROM memory. Data will be converted afterward into a KML file and visualized in Google Earth.
The MCU is constantly analysing data frames returned by the GNSS module and seeks for GNRMC frames. They provide information on date, time, lattitude, longitude and speed over ground. When this type of frame is detected, the MCU convert information in a storage efficient way (refer to LOCUS feature) made of 16 bytes. These 16 bytes are then written to the MCU's EEPROM.
After dumping data from EEPROM, we have a txt file looking like this:
57D81A66 0042401E 9640BF00 650000E3 57D81A6C 0042401E BB40BEFC E00000BC 57D81A72 0042401E C940BEF6 940000AE 57D81A78 0042401E E840BEEE 71000078
Each row corresponds to a position fix and a single row is arranged in that way:
- Bytes 0 to 3: Unix time (timestamp)
- Byte 4: Not implemented here
- Bytes 5 to 8: Latitude in decimal degrees (IEEE754 format)
- Bytes 9 to 12: Longitude in decimal degrees (IEEE754 format)
- Bytes 13 to 14: Not implemented here, can be used to save speed or altitude
- Byte 15: XOR checksum on all previous bytes
This text file is then converted into a KML file (see LocusParser) that can be opened in Google Earth. Here is a snapshot of a 2-mile sample (1 fix every 6 seconds):
Another try over 8 miles (1 fix per second):
The Keil project + STM32CubeMX for STM32L152RE Nucleo is available here.