Thanks for the email.
Some of the GPS receivers used in semi-professional and professional applications have a degree of hardware self-test and monitoring, this can include:
* detecting that the internal battery backed RAM/RTC has failed on power up (which may cause the GPS receiver to perform a master reset and take an extended period to provide 'first fix')
* detecting internal faults (loss of master oscillator, loss of PLL)
* detecting antenna faults (open circuit, short circuit) based on the curret consumption by the external antenna connected to the GPS receiver
* detecting of 'in band' interference or deliberate jamming
Most GPS receivers export these items via their proprietary binary interfaces (Trimble TSIP, Ublox UBX, etc.)
What I think we need is a continuation of the Hardware Abstraction Layer (HAL) in the GPSD protocol interface to represent these conditions and then 'driver implementations' for specific receivers. This might take the form of a set of 'capabilities' like 'can perform internal hardware diagnostics', 'can monitor antenna faults' and 'can detect jamming' along with a set of boolean items ('flags') to show weather the fault condition is present.
Mike
On 12/24/2017 1:53 PM, Vaish, Atul
wrote:
Let me know , I am spending on this quite a bit and see how Can I help you in this regard ? Btw just an introduction , at Intel , I work on providing GPS solutions over Android . Regards Atul Vaish -----Original Message----- From: gpsd-dev [mailto:address@hidden] On Behalf Of Michael J. Tubby B.Sc. MIET Sent: Sunday, October 29, 2017 3:18 PM To: address@hidden Subject: [gpsd-dev] GPDS hand hardware fault/alarm reporting 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
--
Michael
J Tubby B.Sc MIET / Technical Director
address@hidden / +44 (0)7973 225144
Thorcom
Systems Ltd
Office: +44 (0)1905 756 700
/ Fax: +44 (0)1905 755 777
Unit 4, 96B
Blackpole Trading Estate West, Worcester, WR3 8TJ Registered in England
& Wales 2704696 / VAT number GB 487 9256 81
www.thorcom.co.uk