Customer Service Center

• PosApp (SimGEN)

• It is always best to provide motion that is at the same rate or is a multiple of the chosen scenario iteration rate.
  • PosApp offers three “scenario iteration rates” – 100ms, 10ms or 4ms (10Hz, 100Hz or 250Hz respectively).
• If unavoidable, only use a motion rate that is slower than the scenario iteration rate if you have slow or near linear vehicle motion.
• If you have high vehicle dynamics use a scenario iteration rate of 100Hz or 250Hz and the motion command rate must be the same or quicker than the chosen scenario iteration rate.
• Always take care to ensure that the motion commands are self-consistent
• The following articles are of interest for further reading --> SOL10324        SOL10215        SOL10218        DGP00792AAA

1. Motion Command Rate Is LESS THAN The Scenario Iteration Rate

• PosApp will use the last received motion command to extrapolate forwards the motion of the vehicle, i.e. it will “fill in the gaps”.
• For example
  • You have a scenario iteration rate of 100ms
  • You only send motion commands (the .umt file has motion commands) timestamped for every 1s
  • PosApp is calculating new data 10 times more often than it is receiving updated motion data from the .umt file or remote source.
  • It uses the motion command from the last 1s epoch to extrapolate how the vehicle will move for each 0.1s step between the last 1s epoch and the next 1s epoch.

2. Motion Command Rate Is EQUAL TO The Scenario Iteration Rate

• PosApp will use each motion command to define the progress of the vehicle motion.
• Motion is used at the 'specified' time - at the iteration rate epoch that matches the timestamp - when read from file (.umt) or when the remote command is received 'in advance'.
• But remote commands sent 'on time', e.g. from a HWIL (HardWare-In-Loop) system, will be used at the next iteration rate epoch
  • PosApp is required to extrapolate the motion by at least one iteration rate epoch (see articles below for further reading).

3. Motion Command Rate Is GREATER THAN The Scenario Iteration Rate

• PosApp will use the 'most recent' received motion command in its calculations to update the motion of the vehicle
  • It will 'discard' unnecessary motion commands
• For example
  • You have a scenario iteration rate of 100ms
  • You send motion commands (the .umt file has motion commands) timestamped for every 10ms
  • PosApp is calculating new data 10 times slower than it is receiving updated motion data from the .umt file or remote source.
  • So it does not need to use the motion commands from the 10ms steps that fall inbetween each 100ms epoch.

NOTES

• The scenario iteration rate is how often PosApp software calculates new pseudorange (PR) data ready for updating the simulator hardware.
  • The PR data is a result of the motion of the simulated vehicle as well as the satellites in-view.
  • The simulator thus uses the PR information to update the RF signal.
     
• When we are considering the rate of motion commands in a .umt file (or being sent via remote commands from a remote controller system) it is important to understand that they are first handled by the software and thus this selection of "scenario iteration rate" is all important.