[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gpsd-dev] GPDS hand hardware fault/alarm reporting
From: |
Michael J. Tubby B.Sc. MIET |
Subject: |
[gpsd-dev] GPDS hand hardware fault/alarm reporting |
Date: |
Sun, 29 Oct 2017 09:48:15 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
We have been using GPS receivers in vehicle location systems since the
early 1990s and the Trimble Advanced Navigation Sensor (TANS) - if
anyone remembers that - and have worked through multiple generations
from SVeeSix, ACE to Lassen-iQ and have always used Timble's TSIP binary
code.
We have a new product design and we've switched to Ublox MAX-M8W and I
face a but of a dilemma, I could:
a) keep our codebase and write a new UBX binary driver; or
b) switch to using GPSD as effectively a Hardware Abstraction Layer
(HAL) - our preferred route
Our platforms are ARM-based (i.MX6, Linux 4.1, Ubuntu 14.04 LTS server)
and I have downloaded and built GPSD 3.19, got working with MAX-M8W on
out platform, got NTPD working with shared memory and built a prototype
test client - all in one evening! While I'm impressed with the quality
and ease of use of both GPSD and libgps it leaves us with a challenge
for GPS receiver and antenna fault monitoring and reporting.
Our products are designed for business-critical and mission-critical
users (e.g. Emergency Services and other government agencies). Equipment
gets broken both accidentally and (on occasions) deliberately we need to
monitor the hardware for faults as we generally need to get faulty
installations fixed asap.
All of our products use an external antenna with active pre-amp and we
monitor the power consumption of the pre-amp to determine whether the
antenna is good or faulty, there are three conditions - "good", "open
circuit" (not plugged in) and "short circuit". These are reported via
status bits in TSIP and UBX - some chips have the hardware built in
while other's you have to add bits around the GPS receiver.
When using the proprietary binary interfaces, e.g. Trimble TSIP and
Ublox UBX, additional instrumentation is available for faults and alarms
and we use these as well.
Several receivers support 'battery backup failed' and or 'system RAM
corrupt' at start-up along with 'DSP faults' and many newer GPS
receivers support jamming detection by detecting the presence of in-band
RF interference and flag this also.
I am only across the Trimble and Ublox GPS/GNSS receivers that we
currently use but an approach for adding generic support these
faults/alarms would be to add a new set of flags as a uint32_t called
'gps.fault' or similar and define a set of values:
GPS_FAULT_BATTERY_BACKUP_FAIL 0x00000001
GPS_FAULT_SYSTEM_RAM_CORRUPT0x00000002
GPS_FAULT_DSP_FAILURE 0x00000004
GPS_FAULT_ANTENNA_OPEN 0x00000008
GPS_FAULT_ANTENNA_SHORT 0x00000010
GPS_FAULT_JAMMING_DETECTED 0x00000020
that the drivers could set.
Before we go off hacking GPSD and libgps too much I thought I'd check if
we're going in the right direction or overlapping with anyone else.
Does anyone else want to work on this? Does anyone want to contribute
to the list of faults/fault codes for other receivers?
Mike
- [gpsd-dev] GPDS hand hardware fault/alarm reporting,
Michael J. Tubby B.Sc. MIET <=