EM7455B GNSS: 11 satellites with SNR 34–35, antenna bias enabled, but never obtains a GPS fix
Hello,
I am troubleshooting GNSS on a Getac V110 G5 equipped with a Sierra Wireless EM7455B.
At this point I have done extensive testing under both Windows 11 and Ubuntu Live. The GNSS receiver can see satellites and the active antenna is definitely being powered, but the modem never obtains a position fix.
I would appreciate help from somebody familiar with the EM7455 GNSS implementation, especially with firmware/PRI configuration.
Hardware
- Laptop: Getac V110 G5
- WWAN modem: Sierra Wireless EM7455B
- Firmware:
SWI9X30C_02.24.03.00
r6978 CARMD-EV-FRMWR2
2017/03/02 13:36:45
The modem reports:
Manufacturer: Sierra Wireless, Incorporated
Model: EM7455B
Revision: SWI9X30C_02.24.03.00 r6978 CARMD-EV-FRMWR2 2017/03/02 13:36:45
The installed carrier/PRI configuration is:
!IMPREF:
preferred fw version: 02.24.03.00
preferred carrier name: VODAFONE
preferred config name: VODAFONE_001.001_002
current fw version: 02.24.03.00
current carrier name: VODAFONE
current config name: VODAFONE_001.001_002
The GNSS antenna is an active antenna connected to the dedicated GNSS connector on the EM7455.
Initial problem under Windows 11
My original objective is simply to have a working GPS position in Windows applications such as Google Maps, not necessarily to make Getac Manager itself display GPS.
Google Maps reported:
No precise location could be found.
Windows cellular data worked correctly through the EM7455 SIM connection.
Windows serial ports
Initially Windows reported:
COM1
COM2
COM3
COM4
COM5
The relevant Sierra interfaces were:
Sierra Wireless Snapdragon™ X7 LTE-A DM Port (COM3)
Sierra Wireless Snapdragon™ X7 LTE-A NMEA Port (COM5)
Sierra Wireless Snapdragon™ X7 LTE-A WWAN Modem
There was no AT Port exposed by Windows.
Getac GPS driver
The Getac GPS Location Driver was installed correctly.
The device appeared as:
Getac GPS Location Device
ROOT\SENSOR\0000
with:
Status : OK
Problem : CM_PROB_NONE
ConfigManagerErrorCode : CM_PROB_NONE
Present : True
Service : WUDFRd
Driver information:
gpslocationdriver.inf
Driver version: 1.0.2.13
Driver date: 24/06/2020
Manufacturer: Getac Technology Corporation
The Getac registry configuration was:
HKEY_LOCAL_MACHINE\SOFTWARE\Getac\GPSLocationDriver
DefaultComPort REG_DWORD 0x5
DefaultBaudRate REG_DWORD 0x1c200
SSN REG_SZ RM603V1502
Therefore:
DefaultComPort = COM5
DefaultBaudRate = 115200
Windows Location was also enabled:
lfsvc = Running
Location consent = Allow
The Windows Sensor services were:
SensorService Running
SensrSvc Running
SensorDataService Stopped / Manual
The Getac GPS device itself was nevertheless reported by Windows as completely healthy.
NMEA data under Windows
COM5 was found to be the actual NMEA interface.
Reading COM5 manually produced continuous NMEA sentences such as:
$GPGGA,0,*66
$GPRMC,V,N*53
$GPGSV,4,1,16,…
$GPGSV,4,2,16,…
$GPGSV,4,3,16,…
$GPGSV,4,4,16,…
$GPVTG,T,M,N,K,N*2C
$GPGSA,A,1,*1E
The important part was:
GPGSA,A,1
= no fix.
And:
GPGGA,…,0,…
= no fix.
And:
GPRMC,…,V,…
= invalid navigation data.
However, GPGSV showed satellites in view.
An example showed approximately 16 satellites visible, but many of the SNR fields were empty.
Google Maps therefore could not obtain a useful location.
Important discovery: GNSS antenna bias was disabled
At this point I booted Ubuntu Live to get direct access to the EM7455 AT interface.
Linux exposed:
/dev/ttyUSB0
/dev/ttyUSB1
/dev/ttyUSB2
The interfaces were identified as:
ttyUSB0 = USB interface 00
ttyUSB1 = USB interface 02
ttyUSB2 = USB interface 03
The USB driver was qcserial.
Testing ATI showed that ttyUSB2 is the AT port:
Manufacturer: Sierra Wireless, Incorporated
Model: EM7455B
Revision: SWI9X30C_02.24.03.00 r6978 CARMD-EV-FRMWR2 2017/03/02 13:36:45
The other two ports did not respond to AT.
The NMEA interface was confirmed as:
ttyUSB1 = USB interface 02
AT+WANT?
The most important discovery was:
AT+WANT?
+WANT: 0
OK
The active GNSS antenna was physically disconnected at this point and I measured 0 V at the antenna connector.
I then enabled the antenna bias:
AT+WANT=1
The modem returned:
OK
and the voltage at the antenna connector immediately became approximately:
3 V DC
Therefore the EM7455 was definitely able to provide the active antenna bias, but it had previously been disabled.
I then reconnected the active antenna.
After a reboot, I checked again:
AT+WANT?
+WANT: 1
OK
So the setting persisted across reboot.
This proves that the antenna bias is now enabled and remains enabled.
GNSS session
I used the following commands through the AT port:
AT!GPSSTATUS?
AT!GPSLOC?
AT!GPSAUTOSTART?
AT!GPSTRACK=1,255,1000,30,1
AT!GPSFIX=1,255,100000
The modem reports:
Fix Session Status = ACTIVE
but repeatedly:
Last Fix Status = FAIL
FAILCODE = 0
or, after one GPSFIX attempt:
Last Fix Status = FAIL
FAILCODE = 9
AT!GPSLOC? repeatedly returns:
Not Available
The modem’s internal time also remained:
Current time: 1980 01 06
while the Ubuntu system clock was correct:
Wed Aug 12 19:41:42 UTC 2026
Ubuntu reported:
System clock synchronized: yes
NTP service: active
I also tried AT+CCLK?, but that command returned an error on this modem/firmware.
I have therefore not yet established whether the 1980 date is a cause of the no-fix condition or simply a consequence of the GNSS engine never obtaining its first fix.
NMEA output under Linux
Initially /dev/ttyUSB1 did not output anything.
The important discovery was that this firmware requires the NMEA interface to be started using:
$GPS_START
I sent:
printf “\$GPS_START\r\n” > /dev/ttyUSB1
After that, /dev/ttyUSB1 immediately started producing NMEA.
For example:
$GPGSV,3,1,11,33,34,38,34,39,35,40,34*7F
$GPGSV,3,2,11,41,34,42,34,46,34,48,35*74
$GPGSV,3,3,11,49,34,50,35,51,34*73
$GPVTG,T,M,N,K,N*2C
$GPGSA,A,1,*1E
$GPGGA,0,*66
$GPRMC,V,N*53
So NMEA itself is working.
AT!GPSSATINFO?
This was probably the most important measurement.
With the antenna connected to the dedicated GNSS connector, I obtained:
Satellites in view: 11 (1980 01 06 …)
SV: 33 ELEV: 0 AZI: 0 SNR: 34
SV: 38 ELEV: 0 AZI: 0 SNR: 35
SV: 39 ELEV: 0 AZI: 0 SNR: 35
SV: 40 ELEV: 0 AZI: 0 SNR: 35
SV: 41 ELEV: 0 AZI: 0 SNR: 34
SV: 42 ELEV: 0 AZI: 0 SNR: 34
SV: 46 ELEV: 0 AZI: 0 SNR: 34
SV: 48 ELEV: 0 AZI: 0 SNR: 34
SV: 49 ELEV: 0 AZI: 0 SNR: 34
SV: 50 ELEV: 0 AZI: 0 SNR: 35
SV: 51 ELEV: 0 AZI: 0 SNR: 34
OK
This demonstrates:
- 11 satellites in view.
- SNR around 34–35.
- Therefore the GNSS receiver is definitely receiving RF energy from satellites.
However:
GPGSA,A,1
GPGGA,…,0
GPRMC,…,V
continues indefinitely.
The unusual part is that all satellites reported by GPSSATINFO have:
ELEV = 0
AZI = 0
despite having SNR around 34–35.
Testing the AUX antenna connector
Because I found Sierra documentation indicating that GPSSEL=0 corresponds to the dedicated GNSS input and GPSSEL=1 corresponds to the shared/AUX input, I performed a physical test by moving the same active antenna from the dedicated GNSS connector to AUX.
With the antenna on AUX:
Satellites in view: 1
SV:255
ELEV: 0
AZI: 0
SNR: 15
and:
Fix Session Status = ACTIVE
Last Fix Status = NONE
This is clearly worse than the dedicated GNSS connector, where I had:
11 satellites
SNR 34–35
Therefore I returned the antenna to the dedicated GNSS connector.
I tried querying and changing GPSSEL, but my PRI behaves differently from some examples found on the Sierra forum.
AT!CUSTOM? initially returned:
GPSENABLE 0x01
GPIOSARENABLE 0x01
IPV6ENABLE 0x01
SIMLPM 0x01
USBSERIALENABLE 0x01
It did not initially display GPSSEL.
However:
AT!CUSTOM=?
showed that GPSSEL is actually a supported custom parameter:
“GPSENABLE”
“GPSLPM”
“GPIOSARENABLE”
“GPSSEL”
“GPSREFLOC”
…
I tried:
AT!CUSTOM=“GPSSEL”,0
but the modem returned:
ERROR
I also tried querying it using:
AT!CUSTOM=“GPSSEL”?
which also returned:
ERROR
So at the moment I do not know the current GPSSEL value, and I have not been able to modify it.
GPSLPM test
I also found reports involving GPSLPM.
I changed:
AT!CUSTOM=“GPSLPM”,0
and restarted the modem.
The change did not solve the problem.
After reboot:
Fix Session Status = ACTIVE
Last Fix Status = NONE
and the modem still did not obtain a fix.
USB composition tests
The original USB composition was:
USB composition 8:
DM, NMEA, AT, MBIM
I temporarily changed the modem to composition 6:
USB composition 6:
DM, NMEA, AT, QMI
using:
qmicli --dms-swi-set-usb-composition=6
The command succeeded.
However, QMI access was not functioning correctly afterwards:
Couldn’t create QmiDevice
Operation timed out
CID allocation failed in the CTL client
The modem’s AT interface remained usable, but after the composition change the GNSS behaviour changed and GPSSATINFO returned:
NO SAT INFO
I therefore returned the modem to its original composition 8 before continuing.
The original composition 8 is:
DM + NMEA + AT + MBIM
Commands which do NOT work on this firmware
For reference, these commands produced ERROR or are not implemented on this particular EM7455:
AT!GPSSTART
AT!GPSCOLDSTART
AT!GPSGSV?
AT!GPSCFG?
AT!GPSNMEA?
AT!GPSXTRATIMEENABLE=2
AT+CCLK?
AT!ENTERCND
AT!HELP
AT+CLAC
More precisely:
AT!GPSNMEA?
→ !GPSNMEA: NOT IMPLEMENTED
AT!GPSSTART returns ERROR when a GPS session is already active.
AT!GPSEND=0 returns:
ErrCode = 12
OK
when there is no existing session to terminate.
AT!GPSFIX=1,255,100000 is accepted:
OK
but ultimately results in:
Last Fix Status = FAIL
FAILCODE = 9
or earlier FAILCODE = 0.
Current situation
At the moment the situation is:
Hardware
EM7455B
Active GNSS antenna
Antenna connected to dedicated GNSS connector
Firmware
SWI9X30C_02.24.03.00
PRI
VODAFONE_001.001_002
Antenna bias
AT+WANT?
+WANT: 1
Physical measurement:
approximately 3 V DC on the antenna connector
GNSS
GPSENABLE = 1
GPS session = ACTIVE
Satellite reception
Dedicated GNSS input:
11 satellites
SNR approximately 34–35
Position
Still:
Last Fix Status = FAIL
GPSLOC = Not Available
NMEA still shows:
GPGSA,A,1
GPGGA,…,0
GPRMC,…,V
Internal modem time
Still:
1980-01-06
even though the host system is correctly synchronized to:
2026-08-12
What I am trying to determine
At this point I believe the hardware RF path is basically working because:
- The active antenna is now definitely powered.
- The modem sees 11 satellites.
- SNR is around 34–35.
- The NMEA port works after $GPS_START.
- The GNSS session is active.
But the receiver never transitions from satellite acquisition to a valid navigation solution.
The most suspicious symptoms are:
1980-01-06 modem time
combined with:
ELEV = 0
AZI = 0
for all satellites despite:
SNR = 34–35
and the persistent:
GPGSA,A,1
GPGGA,…,0
GPRMC,…,V
I would particularly appreciate advice on:
- Whether GPSSEL can be read or changed on a module using PRI:
VODAFONE_001.001_002
- Whether this particular PRI expects the dedicated GNSS connector to be selected in another way.
- Whether the 1980-01-06 internal modem time is expected before first fix, or whether it must be explicitly initialized from the host.
- Whether ELEV=0 / AZI=0 / SNR=34–35 in AT!GPSSATINFO? indicates a GNSS firmware/PRI problem rather than a weak RF signal.
- Whether there is a known issue with:
SWI9X30C_02.24.03.00
and GNSS acquisition/fix on this PRI.
- Whether I should change the PRI/firmware to another known-good configuration for GNSS operation.
My ultimate goal is simply to make the EM7455 provide a valid GNSS position to Windows so that applications such as Google Maps can use it.
I have intentionally not flashed new firmware yet because I would prefer to understand whether this is a GNSS configuration/PRI problem before changing the modem firmware.
Any advice on the correct next step would be very much appreciated.
I can provide additional command outputs or logs if required.