question

tbungard avatar image
tbungard asked talal.abbasi answered

Spirent GSS8000 taking a very long time to process MOT commands with timestamps

I am trying to send motion messages at 100Hz over TCP. When I set the timestamp field in the motion message to "-", to establish the time-of-validity as the time PosApp receives the message, I get a response from PosApp in approximately 2 milliseconds. However, when I set the timestamp field in the motion message to a properly formatted string containing the actual time-of-validity of the data contained in the message, i.e. ("00:00:03.01000"), PosApp appears to take upwards of 600 milliseconds to send a response to my message. Has anyone seen this behavior before? Is it possible that the update rate of the simulation could have something to do with that? Is it possible that my string is not formatted correctly and that is making PosApp lag? When looking at the PosApp logs, I do not see any errors reported, but I do see my messages with correct data and timestamps in the message log. Thanks in advance for any help!

PositioningSimREMOTEtimestamp
10 |950
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Answer

·
talal.abbasi avatar image
talal.abbasi answered

Hi @tbungard,

The simulator takes a small amount of time to process the RU (run) command. As a result, it is recommended that at least a few ms delay is left between the RU command and the external trigger pulse being sent. In 'Immediate' mode, the simulator's 1PPS is halted and the scenario won't start until the trigger pulse is received, so the RU command can be sent well in advance.

Normally 100ms should be treated as okay but 600ms is too delayed.

Once armed, the RU command should be very quick to action. However, it will of course take a finite amount of time, so it is possible that the trigger could be received too soon. However, the first thing to do is ensure that your sequence is allowing the arming process to finish before progressing to RU.

The correct sequence is AR -> RU -> trigger pulse

what length of pulse gave better results?

  1. Please read if this can make sense => Section 7.4 GSS8000-series and earlier signal generators - SimRemote User manual.pdf
  2. Please ready if this make sense => Section 8.6 8.6 Using reduced data rates with GSS8000-series signal generators - SimRemote User manual.pdf
  3. Perhaps you can use RU_NOWAIT command to delay. => Section 6.5.9 - SimRemote User manual.pdf
  4. Similarly AR_NOWAIT => Section 6.5.13 - SimRemote User manual.pdf
  5. Read more for external trigger setup, then perhaps diagram can help you => Section 8.5.2 GSS8000 and earlier start-up procedure - trigger mode Delayed - SimRemote User manual.pdf

Please make my response as answer if post for helpful for you :)


Thanks

Talal

10 |950
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.