UTILISING REMOTE CONTROL AND MOTION

1. UTILISING REMOTE CONTROL AND MOTION Colin Ford March 2012

2. SimGEN - standalone Terrain obscuration GLONASS Bulk logging GPS NMEA output Error modelling Galileo Antenna modelling SBAS Signal manipulation QZ Vehicle modelling Multipath

3. SimGEN – remote control • Remote desktop… Internet/LAN VPNRouter Or Switch SimGEN IP Address Remote computer (VPN or on LAN) Other test equipment

4. SimREMOTE • Much of what SimGEN is capable of can be accessed / controlled “remotely” – from another program on the same PC or from another system entirely. • Known as “SimREMOTE” • Depending upon the scale of your testing, these facilities can meet every need from simple remote control to automated testing through to full HWIL integration. • SimREMOTE allows a user to control SimGEN and input trajectories over several physical mediums using a defined syntax.

5. Remote Commands – Category Summary • See SimREMOTE manual for full list of available commands • Command Categories • Scenario Configuration : initial set-up commands • Antenna Pattern : select antenna pattern or set offsets • Signal Power : adjust simulated power, turn power on/off • Signal Control : add multipaths, apply code/carrier offsets • Data-streaming : enable/disable, output settings • Motion : vehicle motion control • Data Requests : scenario info such as time, vehicle position, etc. • Nav Data : insert nav data errors or modifications • Interference : control interference signals • ‘Typical’ syntax format • <timestamp>,<command_id>,<vehicle/antenna_id>,<parameter1>,<parameter2>,<parameter3>,…..etc….

6. Write Read Remote Commands – Read/Write Interaction • Remote control commands • ASCII based – for example: • SC,<scenario dir>  “Select scenario” • AR  “ARM” • RU  “RUN” • With each “write” of a command a “read” should be issued. This sequence should always be maintained (except UDP motion).

7. Remote commands - response

8. Remote System Example – auto test • Automating testing… Other equipment? SimGEN External System Control & Monitor CommandsSimREMOTE RF Generator Position Solution Data RF GNSS Receiver Auto-test controller system

9. Remote System Example - HWIL • A realistic simulation system • Open loop or closed loop Other equipment? SimGEN Trajectory / Control DataSimREMOTE External System RF Generator Position Solution Data RF GNSS Receiver

10. Available Sources • Remote commands can be supplied ‘external’ to the scenario • Standard • TCP/IP : standard ethernet protocol • UDP/IP : only supports MOD, MOT, MOTB commands (use another interface for initial scenario set-up) • RS-232 : only recommended for simple scenario start-up and data requests. • Remote Command File : stored local to the SimGEN PC but independent of scenario selection  ‘emulate’ the above interfaces • Optional (requires extra PCI cards) • IEEE • ScramNET • Equally, pre-configured commands can be specified directly in the scenario from file • User Motion File (.umt) : used for vehicle motion commands • User Command File (.ucd) : used for most other commands

11. Available Sources - User Motion File • Motion needs exceed capability of built-in SimGEN models • Avoids extra considerations for synchronisation with external system  open loop • Associate motion directly with scenario • Enable a user motion file (.umt file) from within the vehicle controls • .umt file syntax can be • MOT or MOTB format (see later slide) • Recorded NMEA data from actual route (GGA / GNS / GLL / RMC)

12. Available Sources - User Commands File • Previously, certain commands were only possible via “remote command file” or over a remote connection • Neither sources held any scenario association • Remote commands associated directly with scenario • The file should NOT contain commands such as • SC, RU, AR, TR, TIME, UTC_OFFSET, etc (that make reference to the scenario) • VEH_ , ANT_ , SIG_ (that make data requests) • Motion commands should be referenced in the .umt file

13. Available Sources - External Interface Selection • Access [Options->Remote Command Settings] • Can enable multiple interfaces • Currently use of command file is recommended as stand-alone • Settings saved in user settings file

14. Remote Commands – Remote Trajectories • The motion is a timed command that can be supplied in one of two formats: • MOT (ECEF frame with respect to WGS84) • <time>,MOT,v1_m1,X,Y,Z,Vx,Vy,Vz,Ax,Ay,Az,Jx,Jy,Jz…. • MOTB (Lat, long, height and linear motion is with respect to local geographic frame (north, east, down)) • <time>,MOTB,v1_m1,lat,lon,hgt,Vn,Ve,Vd,An,Ae,Ad,Jn,Je,Jd…. • Both take a large number of parameters but the minimum requirement is for position and velocity on all three axes • Better fidelity when acceleration and jerk supplied • Can be supplied in ASCII (TCP/IP) or binary UDP

15. TCP/IP Trajectory (ASCII) • <time>,MOT,v1_m1,…. • <msg><status>5</status></msg>

16. UDP/IP Trajectory (Binary) • 01110011001001001…

17. Remote Commands – Remote Trajectories • Ideally provide motion in-step with the scenario iteration rate • Dis-continuous motion data may lead to motion errors • SimGEN processes commands from a buffer 300-400ms before their time of applicability • Commands from file read-in to buffer so are always available when required • Commands from remote source, where possible, should be sent in sufficient time, ideally 1 epoch early • Closed-loop systems  data never available ‘early’. Best result is data arriving ‘on-time’ and thus applied on the following epoch (more detail in “Timing Considerations” session) • SimGEN uses cubic spline to • determine acceleration / jerk terms if not supplied • extrapolate motion if any iteration epoch is ‘missing’ supplied data (data not sent or arrives late or is lost ‘en-route’) • User must ensure motion is smooth / valid • Any motion error causing excessive acc / jerk is reported by SimGEN • Motion may deviate from required trajectory and/or cause ‘noisy’ RF

18. Time Synchronisation • Remote commands contain a timestamp • Need to be sent at the ‘right time’; corresponding to the scenario ‘time into run’ • No ‘master clock’; assume independent PC clocks are ‘close enough’ • Spirent ‘master clock’; supply 1PPS signal to remote system • External ‘master clock’; supply 1PPS to simulator SYNC IN • Spirent ‘master clock’ • [Hardware] Input simulator 1PPS Timer output to timer card installed in remote PC • [Software] Input SimGEN UDP datastream ‘time sync’ message via ethernet connection to remote PC • External ‘master clock’ • Simulator 1PPS aligned to signal at SYNC IN port • Source could be the remote system itself or other external equipment

19. Trigger Modes • Three modes • Disabled • Scenario runs as soon as SimGEN is armed and ready, on next 1PPS • Immediate • Scenario runs ‘immediately’, within 400-600ns of receipt of a trigger pulse • Simulator 1PPS is halted until trigger sent – pulse can be sent indiscriminately • Simulator 1PPS signal restart marks the t=0 of simulation • Delayed • Scenario runs ‘after’ receipt of trigger pulse, on next 1PPS • Simulator 1PPS still free running and should be monitored by remote system • Send trigger pulse at least 100ms BEFORE the 1PPS which will mark t=0 of simulation

20. Example Sequence of Events • Consider 100ms iteration rate 100ms User sync with 1PPS include t0 and t1 motion Send initialisation data REMOTE SYSTEM Send t2 motion by t1 Send t3 motion by t2 Read SC status Send SC Armed Send RU Send AR Configure hardware SIMGEN RUN 1PPS GNSS SIMULATOR Scenario t0

21. Data Streaming • Obtain simulation data in real-time • Remote system could simply send data request remote commands • Datastreaming feature offers scenario data ‘for free’ • Streamed over Ethernet using UDP/IP protocol • Client program provided to retrieve data • Configure manually within scenario tree or via remote

22. Data Streaming Equal to or less than SimGEN iteration rate Every second rather than at update rate Only when SimGEN state changes Where you want the data to go Log selected messages to a file Ensure client built with same version for data format compliance One datagram per selection output at selected update rate

23. Data Streaming Client • Spirent provide example client and source code • Customer required to create their own data streaming client • See user manual

24. Data Streaming Message Logger Choose which datagrams to log Choose file format Important to use with compatible version of SimGEN Replay binary file created by SimGEN (or this utility)

25. PosApp V4.XX Remote control PosApp PosApp GUI Read/Write Scenarios Shared drive Read/Write Control PosApp Engine Read/Write Remote commands / trajectory Control Control Monitor UUT Signal Generator RF

26. PosApp Engine V4.XX • Is run by the PosApp GUI at start-up if no Engine is detected or connected to if there is a Engine running already • GUI runs at normal priority • Engine runs at Windows Real Time priority • GUI does take a little longer to shutdown as it waits for the Engine to shutdown • Engine can be used without the GUI • Engine does all the logging, data production, signal generator control, command processing • Without the GUI bound in to the Engine code the Engine is less time sensitive and more stable • No longer uses the registry instead a User settings file is created • Ideal for remote control when a GUI is not required

27. User settings V4.XX • Human readable JSON formatted file that contains the data previously contained within the Windows registry

28. User settings V4.XX • File is loaded in to memory by the PosApp Engine at start-up • File stores settings by logged in user name • Settings can now be changed using the new remote commands • USER_SETTINGS_LOAD • USER_SETTINGS_UPDATE • USER_SETTINGS_SAVE • You can even use it to store your own settings!

29. User settings V4.XX • USER_SETTINGS_LOAD[,<user_id>][,<reload>] • user_id ::= ASCII string • reload ::= “reload_from_file” (rather than memory) • This command will cause the engine to examine the user settings for the user name given. If this user name is not found then a new user will be created with default settings applied. If no user name is given then the last user name to issue this command will be used. • Returns a JSON string in <data> • USER_SETTINGS_LOAD,CFord <msg> <status> 2 </status> <data> { "CFord": { "aiding logging on": "false", "motion logging on": "true", "sat data logging on": "false", "logging rate ms": "10", "output format": "1", "use scenario dir": "true", "scenario dir": "", "dump nav data": "true", "Novatel msg delay": "100“ ...

30. User settings V4.XX • USER_SETTINGS_UPDATE,<JSON_string> • JSON_string ::= JSON formatted string of settings • This command will update the currently loaded user settings within the Engine. The <JSON_string> can represent the full range of settings or can be a partial range. USER_SETTINGS_UPDATE,{"remote from scramnet": "false", "multiple remote enabled": "false", "remote from file": "false", "msg disable popups": "true", "aiding logging on": "false", "motion logging on": "false", "sat data logging on": "false", "logging rate ms": "10", "auto repeat run": "false", "dummy run": "false", "dump sig gen msgs": "false", "dump nav data": "false", "dummy run warning": "false", "high rate period": "10", "number of boards" : "1", "usage board 0": "2"}

31. User settings V4.XX • USER_SETTINGS_SAVE[,<user_id>] • user_id ::= ASCII string • This command will cause the engine to save the currently loaded user settings. If the <user_id> is supplied then the currently loaded settings will be saved under that user. If the <user_id> is not supplied then the settings will be saved under the last loaded user. • USER_SETTINGS_SAVE,CFord

32. User settings V4.XX • Storing your own settings is easy: • USER_SETTINGS_UPDATE,{“Hello”,”World”} • USER_SETTINGS_LOAD • Returns all our settings as well as the new “Hello”:”World” • With this feature your remote control system can store its own settings within the file for retrieval later • For instance the last scenario it ran • Receive set-up data etc…

33. Thank You Colin Ford