MadDokK
Posts: 7
Joined: Thu Feb 22, 2024 5:21 pm

Commanding SIM7600 GPS Hat for Specific NMEA Data

Fri Feb 23, 2024 12:58 am

Background: (Everything in bold are the clifnotes) I had a hard time figuring out what board on this forum to post my question. While I wouldn't consider this advanced, it ends up being a good place given the number of different topics my project spans. My project is called "Doom" and is an early warning system for any kind of major national disaster. I'm doing this mostly as an exercise to get more experience - I'm not a hardcore preper with a bunker, though I admit I like to be prepared for the more common sense scenarios. To accomplish my task, I'm gathering many indicators using a Python program that will be running on a Raspberry Pi 3. It as many advantages being low power, doesn't need cooling, can remain on constantly with the ability to interact with peripherals. So far the device can query multiple electric companies from every power grid to find the number of outages and it can ping IP's in most states to check the health of the internet (any better suggestions on this would be appreciated).

Goal: What I'm stuck on now is checking how many GPS-type satellites are working. The HAT I'm using supports GPS, GLONASS, GALILEO and BEIDOU. Getting information from as many of those systems as possible is preferred. The easiest way I can figure is to get the number of satellites in range.

Method: I have a Waveshare SIM7600A-H GNSS HAT attached to my Raspberry Pi 3b and am sending commands and parsing the data using Python 3.9. The relevant documentation for the HAT is linked above and is the reference I've been using in my attempts. I used the Python example code provided to make a console so I could poke the HAT with commands.

Problem: I seem to have found the right place, but am having problems with the specifics. Page 375 and 376 in the documentation seems to have the answer. AT+CGPSNMEA=<nmea> is the command and there's a "Defined Values" section saying the <nmea> range is from 0 to 262143, but then it only has a legend for 17 bits. So what is the 0 to 262143 about? Bits 2,3,610,17 appear to have the information I'm looking for. I just need to access it. If you happen to have one of these HATs and would like to test to get the data, the code I modified to send commands to the HAT is below. Please don't judge - I was trying to accomplish a task quickly, not have a polished end product.

Thank you for your time.

Code: Select all

#!/usr/bin/python
# -*- coding:utf-8 -*-
import RPi.GPIO as GPIO
import serial
import time

ser = serial.Serial('/dev/ttyS0',115200)
ser.flushInput()

power_key = 6
rec_buff = ''
rec_buff2 = ''
time_count = 0


class color:
    HEADER = '\033[95m'
    OKBLUE = '\033[94m'
    OKCYAN = '\033[96m'
    OKGREEN = '\033[92m'
    WARNING = '\033[93m'
    FAIL = '\033[91m'
    ENDC = '\033[0m'
    BOLD = '\033[1m'
    UNDERLINE = '\033[4m'


def power_on(power_key):
    print('SIM7600X is starting:')
    GPIO.setmode(GPIO.BCM)
    GPIO.setwarnings(False)
    GPIO.setup(power_key,GPIO.OUT)
    time.sleep(0.1)
    GPIO.output(power_key,GPIO.HIGH)
    time.sleep(2)
    GPIO.output(power_key,GPIO.LOW)
    time.sleep(20)
    ser.flushInput()
    print('SIM7600X is ready\n')


def power_down(power_key):
    print('SIM7600X is loging off:')
    GPIO.output(power_key,GPIO.HIGH)
    time.sleep(3)
    GPIO.output(power_key,GPIO.LOW)
    time.sleep(18)
    print('Good bye')


def shutdown():
    if ser is not None:
        ser.close()
    power_down(power_key)
    GPIO.cleanup()
    exit()


def send(command, timeout):
    buffer_read = ''
    ser.write((command + '\r\n').encode())
    time.sleep(1)
    try:
        time.sleep(timeout)
    except KeyboardInterrupt:
        shutdown()
    if ser.inWaiting():
        time.sleep(0.01)
        buffer_read = ser.read(ser.inWaiting())
    if buffer_read != '':
        return buffer_read.decode()
    else:
        print('GPS is not ready')
        return 0


def console():
    repeat = ''
    print(f'{color.HEADER}{color.UNDERLINE}Console Commands{color.ENDC}\n'
          f'Read - reads from buffer.\n'
          f'Exit - exits loop and ends program.\n'
          f'Repeat - repeats previous command.\n'
          f'Exec: <command> - Executes Python command.\n'
          f'Eval: <command> - Executes Python command and prints result.\n'
          f'All other commands are sent to SIM7600 GPS/LTE HAT.\n\n')
    while True:
        cli = input('Command: ')
        if cli.lower() == 'repeat':
            cli = repeat
        if "exit" in cli.lower():
            print('Exiting loop.')
            break
        elif "read" in cli.lower():
            print('Reading from buffer.')
            buffer_read = ser.read(ser.inWaiting())
            buffer = buffer_read.decode()
            print(f'Buffer: {buffer}')
        elif 'eval:' in cli.lower():
            command = cli[5:]
            print(f'Executing Python eval command.\neval("{command}")')
            result = eval(f"{command}")
            print(f'Result: {result}')
        elif 'exec:' in cli.lower():
            command = cli[5:]
            print(f'Executing Python exec command.\nexec("{command}")')
            exec(f"{command}")
            print(f'Result: {result}')
        else:
            print('Sending command to HAT.')
            result = send(cli, 1)
            print(str(result))
        repeat = cli


power_on(power_key)
console()
shutdown()

MadDokK
Posts: 7
Joined: Thu Feb 22, 2024 5:21 pm

Re: Commanding SIM7600 GPS Hat for Specific NMEA Data

Sat Feb 24, 2024 1:47 am

I've been tooling around with the commands trying to get a better idea of how this works. There are a few things I've figured out.

AT+CGPS=1 will turn on the GPS.

From there, AT+CGPSINFO will print the location data. If I do AT+CGPSINFO=<1-255>, the HAT will send the location data to the buffer once every x seconds depending on the number. If I don't read the buffer, more lines will continue to stack. If I send another command, the HAT will execute that command but will also dump all of the data in the buffer to a print command. This was pretty confusing until I figured it out.

The AT+CGPSNMEA command documentation (Page 375-376) shows the data I'm looking to get to and there's also an AT+CGPSINFOCFG command with the same NMEA bit legend (page 382-383). As I've been writing this I've been reading more and poking some more and I think I found an important clue.

Page 384 has the AT+CGPSMD command, but more importantly the documentation has a similar bit legend as the NMEA command. At the bottom there's a line of text that says "Example, support standalone, UP MS-based and UP MS-assisted, set Binary value 0000 0111, is 7."

I wasn't thinking in Binary because the numbers were either much larger than the octets I'm used to and the examples were reduced by one. Thinking in binary, I wrote out the sequence (in reverse, obviously)

1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072, 262144

The range for the NMEA command is 0 to 262143. This is one below the 262144 which likely means the binary sequence would be 0's with 18 1's at the end. The number of 0's would depend on whatever the bit length is. Probably 64 bits. One of their "example" lines is "AT+CGPSNMEA=200191" which doesn't really fit unless that sequence activates multiple bits at once.


Still poking, but if anyone has experience with this I would greatly appreciate the input.

ame
Posts: 8921
Joined: Sat Aug 18, 2012 1:21 am
Location: New Zealand

Re: Commanding SIM7600 GPS Hat for Specific NMEA Data

Sat Feb 24, 2024 1:59 am

It looks like the commands are setting or clearing a bunch of bits, but that the argument is decimal. If you want to be a l33t hAxoRz then you need to understand binary.

Here's a conversion tool, with a good explanation:

https://www.binaryhexconverter.com/deci ... -converter

But since you are doing all this on a computer then you don't need to worry. Internally the numbers will be stored as binary, it's just the representation of the number that changes.

Your parameter 200191 in decimal is 0011 0000 1101 1111 1111 in binary. You can see which bits are on and off, and the documentation will tell you what these bits do.

Similarly, if you want to turn things on and off then figure out the binary number and convert to decimal. You'll do it the hard way until it clicks with you then it will be effortless.
Oh no, not again.

MadDokK
Posts: 7
Joined: Thu Feb 22, 2024 5:21 pm

Re: Commanding SIM7600 GPS Hat for Specific NMEA Data

Sat Feb 24, 2024 3:16 pm

ame wrote:
Sat Feb 24, 2024 1:59 am
It looks like the commands are setting or clearing a bunch of bits, but that the argument is decimal. If you want to be a l33t hAxoRz then you need to understand binary.
One of the frustrating things about this was my email to simcom. I explained what I was trying to do, pointed out what they said in their documentation, what they left out that I needed, and why I was confused. They replied in an email with the documentation I just said was inadequate. I've seen this behavior crop up more frequently with people replying with something that shows they didn't fully read the situation. Unfortunately I've also been guilty of this. Thank you for spending some time on this problem. I hope to have it cracked soon.
MadDokK wrote:
Sat Feb 24, 2024 1:47 am
I wasn't thinking in Binary because the numbers were either much larger than the octets I'm used to and the examples were reduced by one. Thinking in binary, I wrote out the sequence (in reverse, obviously)

1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072, 262144

The range for the NMEA command is 0 to 262143. This is one below the 262144 which likely means the binary sequence would be 0's with 18 1's at the end. The number of 0's would depend on whatever the bit length is. Probably 64 bits. One of their "example" lines is "AT+CGPSNMEA=200191" which doesn't really fit unless that sequence activates multiple bits at once.
I believe I demonstrated that I fully understand binary. I'm used to converting binary octets for sub-netting which is why I missed 262143 being an important clue as it's much larger than the 1,2,4,8,16,32,64,128 values I'm used to. I said that 200191 doesn't really fit unless that sequence activates multiple bits at once, a point you reiterated. I don't believe this to be the case.

Page 376 has the NMEA bit legend and at the bottom includes an important note. "Set the desired NMEA sentence bit(s). If multiple NMEA sentence formats are desired, "OR" the desired bits together."

I'm going to disregard that part of the documentation and follow my initial assumption where the "sequence activates multiple bits at once."

I've never dived into the raw GPS data before, but typing this I made a connection I missed. Each bit has a five character string of letters that corresponds with it. I've seen some of these in the buffer, but the data didn't seem to correspond with what I was looking for so I missed the connection. One of my major problems was also that in my trials I used ten seconds as the rate to fill the buffer with the data. It takes at least 30 seconds for all of the data to be sent so I set it for one minute which yielded better results.

Okay. I want bits 2, 6, 10, and 17.

1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072, 262144

Those numbers would be reversed if I was constructing the actual binary sequence, but I'm just looking for the decimal number.

65536+512+32+2=66082

I'll try this out, play around some more and get back.

MadDokK
Posts: 7
Joined: Thu Feb 22, 2024 5:21 pm

Re: Commanding SIM7600 GPS Hat for Specific NMEA Data

Sat Feb 24, 2024 6:22 pm

AT+CGPSINFOCFG=10,31 in the documentation responds with four GPGSV lines, one GPGGA and one GPVTG, but 31 would be the first five bits flipped on, so why only three different NMEA sentences?

66082 gave me PQXFI and another sentence which were one bit less than what I was aiming for. I'm going to try and shift the bits over by one to see what change I get.


1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072, 262144

132164 is the new number to try.

I'm also confused with the AT+CGPSNMEA and AT+CGPSINFOCFG commands which aside from the time component in the latter, appear to do the same thing according to the documentation. Unfortunately the documentation says an AT+CGPSDEL command should be sent during every shutdown. This means every time I have to reboot the module it has to do a GPS cold start which takes more than ten minutes. I adjusted my code to allow for a hot shutdown of the script when I just need to alter some of the code. The AT+CGPSNMEA documentation says a reboot needs to happen for any changes there so some of this time can't be recovered. I'm using this as a bit of a notepad to jot down my thoughts as I try and figure this out.

Okay, I'm getting somewhere.

I set AT+CGPSNMEA and AT+CGPSINFOCFG to 132164. For whatever reason I'm no longer getting a positional fix using AT+CGPSINFO, but the buffer is filling with at least some of what I'm looking for.
$GPGSV,4,1,16,...
$GPGSV,4,2,16,...
$GPGSV,4,3,16...
$GPGSV,4,4,16,...

$GLGSV,3,1,09,...
$GLGSV,3,2,09,...
$GLGSV,3,3,09,...
GPGSV lists the GPS satellites in view. I found some NMEA documentation here which helps me to decode it. The first number is the total number of sentences being sent with the second number corresponding to the index number of that particular sentence. The third number is some of what I've been looking for - the number of GPS satellites in view.

Likewise, GLGSV lists the number of GLONASS satellites in view and it looks like it has the same format. This data shows there were 16 GPS satellites in range and 9 GLONASS satellites in range. So I've received the data corresponding to bits 2 and 6, but am still missing 10 and 17. I suppose I could just call this good enough, but I want to learn how this works. Why am I no longer able to get a coordinate fix with CGPSINFO? Why can't I get the NMEA sentences for the other bits?

There's another change that I've noticed and I don't know if it correlates with anything. There's an LED below the PWR LED and it's labeled NET. It used to be off until the code turned the SIM7600 module on. Likewise it would turn off when the program sent the shutdown sequence. Now it's just on all of the time. Even if I shut everything down and inplug the pi, the second I plug it back in both LED's turn on. I'm wondering if there's a way to reset the HAT to the factory default.

MadDokK
Posts: 7
Joined: Thu Feb 22, 2024 5:21 pm

Re: Commanding SIM7600 GPS Hat for Specific NMEA Data

Sat Feb 24, 2024 6:59 pm

Figured some more out. I had both CGPSNMEA and CGPSINFOCFG set to 132164. I changed CPGSNMEA to the max and after this it was able to get a positional lock with AT+CGPSINFO. I think because I had it set to just the GSV data it wasn't getting the coordinate info to get the fix.

I then decided to set CGPSINFOCFG to the max to get all of the data and see what appears. When I first did this I had no idea what I was looking at, so I'm able to understand it much better now. I get the following lines:

$GPGSV - Bit 2
$GPGSV - Bit 2
$GPGSV - Bit 2
$GPGSV - Bit 2
$GPGGA - Bit 0
$GPVTG - Bit 4
$GPRMC - Bit 1
$GPGSA - Bit 3
$PQXFI - Bit 5
$GNGNS - Bit 8
$GNGSA - Bit 7
$GNGSA - Bit 7
$GLGSV - Bit 6

Below is the bit legend. I emboldened the lines that I was able to get.

Bit 0 – GPGGA (global positioning system fix data)
Bit 1 – GPRMC (recommended minimum specific GPS/TRANSIT data)
Bit 2 – GPGSV (GPS satellites in view)
Bit 3 – GPGSA (GPS DOP and active satellites)
Bit 4 – GPVTG (track made good and ground speed)
Bit 5 – PQXFI (Global Positioning System Extended Fix Data.)
Bit 6 – GLGSV (GLONASS satellites in view GLONASS fixes only)
Bit 7 – GNGSA (1. GPS/2. Glonass/3. GALILE DOP and Active Satellites.)
Bit 8 – GNGNS (fix data for GNSS receivers; output for GPS, GLONASS, GALILEO)
Bit 9 – Reserved
Bit 10 – GAGSV (GALILEO satellites in view)
Bit 11 – Reserved
Bit 12 – Reserved
Bit 13 – Reserved
Bit 14 – Reserved
Bit 15 – Reserved,
Bit 16 – BDGSA/PQGSA (BEIDOU/QZSS DOP and active
satellites)
Bit 17 – BDGSV/PQGSV (BEIDOUQZSS satellites in view)

It's a little suspicious that I can get exactly the first 8 with nothing missing, yet all of the bits after aren't there.

I did realize why I had to shift the bits over. If you look at the range, 262143 is the highest number and is the decimal equivalent of having 18 bits on. For whatever reason I wasn't thinking of bit 6 being the 6th bit, not the 7th. Oops.

Getting closer. I saw somewhere a setting that switches between some of the GPS-like systems. I may not be able to receive them all at once at might need to change the configuration to see the others.

ame
Posts: 8921
Joined: Sat Aug 18, 2012 1:21 am
Location: New Zealand

Re: Commanding SIM7600 GPS Hat for Specific NMEA Data

Sat Feb 24, 2024 8:26 pm

So, now that you fully understand binary, case closed?
Oh no, not again.

Return to “Advanced users”