Home
Only a few test scripts are currently within repo - actual CAR code is held back and not made public.
- WiFi
- Bluetooth
- LTE
- GPS
- 18560 Battery Holder
- Solar Charge Development Board
- HDOP, VDOP and PDOP
- How GPS Receivers Work
- GPS Selective Availability
- Error Analysis
- Dilution Of Precision
- SIM7000G has a CEP of 2.5m
- A DOP of 3 would mean 50% of positions would be 2.5 * 3 within 7.5m accuracy
- Aiming for fixes within 5m would require a DOP of <2 (ideal or excellent)
- A Paper compared mobile phone GPS units under / near tree cover related to CEP and discusses differential systems and correction - interesting
| DOP Value | Rating | Description |
|---|---|---|
| <1 | Ideal | Highest possible confidence level to be used for applications demanding the highest possible precision at all times. |
| 1-2 | Excellent | At this confidence level, positional measurements are considered accurate enough to meet all but the most sensitive applications. |
| 2-5 | Good | Represents a level that marks the minimum appropriate for making accurate decisions. Positional measurements could be used to make reliable in-route navigation suggestions to the user. |
| 5-10 | Moderate | Positional measurements could be used for calculations, but the fix quality could still be improved. A more open view of the sky is recommended. |
| 10-20 | Fair | Represents a low confidence level. Positional measurements should be discarded or used only to indicate a very rough estimate of the current location. |
| >20 | Poor | At this level, measurements are inaccurate by as much as 300 meters with a 6-meter accurate device (50 DOP × 6 meters) and should be discarded. |
The initial code used example code to test for a GPS fix such as:
# Get positioning data
raw = gsm.atcmd('AT+CGNSINF', printable=True)
string = raw.split(',')
if (int(string[1]) == 1):
# Then GPS connected and values recieved
yy=string[2][:4]
mm=string[2][4:6]
dd=string[2][6:8]
h=string[2][8:10]
m=string[2][10:12]
s=string[2][12:]
lat=string[3]
lon=string[4]
...which relies upon the AT+CGNSINF command returning something sensible and that it also returns the expected number of parameters and in addition to this it also expects Python to be able to cast the string into an integer. This code failed intermittently.
It has been replaced by returning a dictionary of parsed values gpsD = gpsToDict(raw) and testing for errors, quality and whether the SIM7000G thinks there is a fix within a loop.
This method tests for the GNSS_RUN_STATUS, FIX_STATUS, UTC_DATE_TIME for correctness, as well as DOP quality. It is also possible to check for C/N0 (carrier-to-noise density). UTC_DATE_TIME correctness is checked when the raw data is parsed within the gpsFormat.py module and could easily be updated to double check yyyy/mm/dd/hh with current time set in the RTC via NTP each day.
# Get positioning data
fixed = False
while not fixed:
time.sleep(1)
raw = gsm.atcmd('AT+CGNSINF', printable=True)
gpsD = gpsToDict(raw)
fix = gpsD['FIX_STATUS']
gnss = gpsD['GNSS_RUN_STATUS']
pDOP = gpsD['PDOP_RATING']
quality = pDOP in ACCEPTED_DOPS
satFix = gnss == "1" and fix == "1"
error = gpsD['ERROR']
fixed = quality and satFix and not error
# We have a good fix on position
lat = gpsD['LATITUDE']
lon = gpsD['LONGITUDE']
yy = gpsD['YEAR']
mm = gpsD['MONTH']
...
- Flashing of the LEDs is not correct - toggling happens with intermittent on/off lengths - think this is caused by blocking functions (like
time.sleep). Sleep can be replaced by a custom pause function that compares time start with time start + delay. [edit: that is not the way to go. It is better though. More thought required.] - Only call_robot state is sent - no GPS data - code is commented out
The latitude degrees has been changed for privacy
As can be seen, with a poor signal, initialising the modem to registered with a mobile operator can take several tries. Here it was 4 but Sometimes up to 20.
IN MAIN
INIT HARDWARE
INIT STATE MACHINE
INIT MODEM
Waiting for AT command response...
RETRY 0
RETRY 1
RETRY 2
RETRY 3
RETRY 4
Once registered a list of available operators can be retrieved
COPS= ..+COPS: (2,"O2 - UK","O2 - UK","23410",0),(3,"vodafone UK","voda UK","23415",0),(3,"EE","EE","23430",0),,(0,1,2,3,4),(0,1,2)....OK..
The (2,"O2 - UK","O2 - UK","23410",0) first 2 before O2 means we can connect to this operator. The 3 in front of Vodafone means we can not.
The internet connection is idle, because it hasn't connected (in this example connection wasn't asked for as the signal strength is too low). That is why there is no IP Address. CSQ is the signal strength, 31 means -53dBm or greater, which isn't useful, however the 99 means Not Known or Not Detectable - The signal is too poor. COPS? shows we are registered to O2, using a SIMCOM Ltd modem.
Got AT: (89, 'Idle')
IP: 0.0.0.0
CSQ ..+CSQ: 31,99....OK..
CGNAPN ..+CGNAPN: 0,""....OK..
COPS? ..+COPS: 0,0,"O2 - UK",0....OK..
CGMI ..SIMCOM_Ltd....OK..
BAT ..+CBC: 0,65,3848....OK..
SIM7000G INIT DONE
STATUS: (89, 'Idle')
Next is the attempt to obtain a GPS fix, and check the battery voltage (64% and 3840mV)
INIT GPS
Attempting to establish GPS signal.
..+CBC: 0,64,3840....OK..
(2022, 2, 15, 17, 17, 46, 3, 46) 3840
The first GPS attempt uses the GNSS (Global navigation satellite system) but is unable to get a fix.
0 GNSS: 1 Fix: 0 Latitude: Long: PDOP: n/a HDOP: n/a VDOP: n/a meanDOP n/a
Attempts are made once per second
36 Attempts later a fix was obtained, however this fix was very poor, although HDOP was excellent, PDOP and VDOP were not available (and hence no mean DOP value) 1.
Attempt 37 did manage a good positional fix (mean DOP is excellent).
35 GNSS: 1 Fix: 0 Latitude: Long: PDOP: n/a HDOP: n/a VDOP: n/a meanDOP n/a
36 GNSS: 1 Fix: 1 Latitude: 55.229571 Long: -0.555412 PDOP: n/a HDOP: excellent VDOP: n/a meanDOP n/a
37 GNSS: 1 Fix: 1 Latitude: 55.229582 Long: -0.555397 PDOP: good HDOP: excellent VDOP: excellent meanDOP excellent
38 GNSS: 1 Fix: 1 Latitude: 55.229583 Long: -0.555403 PDOP: good HDOP: excellent VDOP: excellent meanDOP excellent
39 GNSS: 1 Fix: 1 Latitude: 55.229600 Long: -0.555386 PDOP: good HDOP: excellent VDOP: excellent meanDOP excellent
40 GNSS: 1 Fix: 1 Latitude: 55.229643 Long: -0.555352 PDOP: good HDOP: excellent VDOP: excellent meanDOP excellent
41 GNSS: 1 Fix: 1 Latitude: 55.229638 Long: -0.555364 PDOP: good HDOP: excellent VDOP: excellent meanDOP excellent
Later on, the quality of the position was not quite as good.
57 GNSS: 1 Fix: 1 Latitude: 55.229492 Long: -0.555464 PDOP: good HDOP: good VDOP: ideal meanDOP good
The numbers on the left are seconds. Starts at 0 secs and runs for 10 minutes. Signal varies and the position varies. The device was left on a window sill with someone walking around the room on a cloudy day. The longitude has changed by almost 30m and latitude by 15m
0 GNSS: 1 Fix: 1 Latitude: 55.229354 Long: -0.555471 PDOP: good HDOP: good VDOP: ideal meanDOP good
169 GNSS: 1 Fix: 1 Latitude: 55.229348 Long: -0.555474 PDOP: good HDOP: good VDOP: ideal meanDOP excellent
260 GNSS: 1 Fix: 1 Latitude: 55.229345 Long: -0.555474 PDOP: good HDOP: good VDOP: ideal meanDOP excellent
355 GNSS: 1 Fix: 1 Latitude: 55.229297 Long: -0.555525 PDOP: good HDOP: excellent VDOP: ideal meanDOP excellent
480 GNSS: 1 Fix: 1 Latitude: 55.229298 Long: -0.555526 PDOP: excellent HDOP: excellent VDOP: ideal meanDOP excellent
560 GNSS: 1 Fix: 1 Latitude: 55.229297 Long: -0.555529 PDOP: excellent HDOP: ideal VDOP: ideal meanDOP ideal
623 GNSS: 1 Fix: 1 Latitude: 55.229206 Long: -0.555767 PDOP: excellent HDOP: excellent VDOP: ideal meanDOP excellent
The best reading should be 560 as HDOP and VDOP are classed as ideal although this reading is still 5m out if plotting the co-ords onto Google Maps satellite view, but the road map view and satellite view also disagree by 3 to 5 metres in this area. PDOP of excellent (a multiplier of 2) suggests the 2.5m CEP probability of the device is likely to mean the fix is accurate to within 5m (CEP * DOP = 2.5 * 2 = 5m).
The first reading, 0, has a PDOP of good (5) so CEP of 2.5m * 5 makes this reading have a 50% probability of being accurate within 12.5m