Using GPS Emulator for facilitating onboard Systems Integration

I am firm believer in ability to design an emulator is an essential repertoire for any Systems integrator. For me , laptop ports with GUI coded in say VB always came very handy. In exceptional cases where time synchronisation was critical, I would code a 80x51 based emulator sitting between laptop (running GUI) and System to be interfaced. I would always desire to finish bulk of functional testing using emulators in lab conditions so that surprises in live conditions are least. Though few iterations were always needed to get it right. Thus in addition to actual applied R&D associated with Systems Interface design , design/coding of suitable emulators was also an important task.

Back in early 2000, I was tasked to design a GPS based interface unit to feed latitude in resolver format to a Russian vertical reference Gyro system. This interface was meant to capture GPS’s NMEA 0183 stream , extract latitude from GLL sentence using micro controller , apply this 12 bit latitude to a Digital to Synchro converter (5 VA rated )and then enhance VA rating using analog buffer amplifiers to ~ 20 VA. Block schematic as illustrated below :-

Being a Russian system , it had strange interface requirements i.e

(a) Drive capacity of ~ 20VA buffer amplifier for receiving resolver (In my initial efforts to drive this resolver chain , I ended burning two in number 5 VA Digital to Synchro modules. DSC are expensive modules , in 2001 it costed ~ INR 60K each and post Pokharan was on blocked list of dual use items)

(b) Receiving resolver rotates 360 deg for every minute change in the latitude i.e fine feed

(c) Direction of rotation of receiving resolver for vessel movement in northern / southern hemisphere for both north and south bound journey as enumerated below. Thus, North to South hemisphere and vice versa equator crossing was a critical boundary condition that had to be checked prior acceptance of the interface solution. Image below sums up the boundary test conditions.

Clearly taking a Ship with a complement of 200+ personnel to equator to test this in live conditions i.e north hemisphere to south and back was at best a wasteful and not so clever idea. Besides even if essential , no one would have given me a listening ear.

GPS emulator was the way out to simulate everything whilst the ship remained tied along side and I fed simulated GLL sentences with ship doing 40+ knots cross-cross over equator into live systems chain. Block level test setup enumerated below

NMEA to Synchro converter consisted of an 80x51 micro-controller listening to GLL sentence on NMEA 0183 stream coming from GPS on serial port. Once latitude is read correctly , same is applied in correct sector value to Digital to Synchro Converter (DSC) module. Output of DSC is converted into Resolver format using Scott Transformer and VA boosted to 20 VA using suitable power Amplifiers. This Resolver output is then applied to the Latitude resolver on the Vertical reference gyro System

How Does GPS (NMEA Version 2.0) represent Latitude in GLL sentence ?

Sample GLL sentence looks like $ GPGLL, DDMM.MMM, H,........

Above , DD represents Degrees, MM.MMM represents minutes with 3 decimal space accuracy. H denotes the Hemisphere i.e. North (denoted by - N) or South (denoted by S).

Sample output of the laptop based GPS emulator is illustrated below :

In 1st prototype, change of rotation direction was implemented using a relay to swap S2/S3 of Synchro Output. I was advised by a senior to consider a software solution since in the long run relays trend to be unreliable. In a subsequent embedded software release, I could implement this in the embedded code and removed relay from board.

Once the prototype unit was proven operationally in live conditions and exploited for over 6 months, based on directives for superior Naval authority , above design (hardware and embedded code) was handed over on ToT to BEL (B’lore) for ruggedised production versions.

Conclusions :-

• A cleverly designed emulator always eases the process of Systems integration. This is something one learns gradually as a process. Using an emulator , lots of unknown variables get discovered in lab conditions. Any emulator is only as good as the understating of source and sink systems interface requirements. Emulator with GUI and text file dump goes a long way in deciphering packet exchange between two interfaced systems
• Any systems integrator essentially must posses a wide range of skills i.e embedded hardware design , embedded software , integrated testing , ability to design and code an emulator i.e overall grasp of everything.
• I took about 5 months to execute above, succeeded in 3rd attempt, learnt what's not working as desired in 1st two and in 1st attempt came back with burnt PCBs !! Thus it is important not to get disheartened upon discovering unknowns in live conditions. It always is an iterative process, rarely do the integration works as desired in 1st go.