SET_MESSAGE_INTERVAL ignored by SITL after a few seconds

Starting simulation with -w, I then send long SET_MESSAGE_INTERVAL 33 10000 1 in the console and receive Got COMMAND_ACK: SET_MESSAGE_INTERVAL: ACCEPTED.

It can also be reproduced by selecting Telemetry Stream Rates in QGroundControl.

I can see in MAVlink inspector the rate change to 100Hz, but after couple seconds, it falls back to the default 4Hz. This time interval is not constant, sometimes it takes 5 seconds, sometimes 10 seconds…

The frequency that is requested also is not a factor, it behaves the same when I request 10Hz.

The version of Arducopter is 4.1.0dev.

To confirm this is not intended behavior, I checked it on Cube Orange (Arducopter 4.0.7), which held the requested frequency no problem.

If it works with 4.0.7 and it does not work with 4.1.0-dev then it is a regression.

Can you please open an issue on ?

I will do that, but just note that it is not just a version difference, there is also the fact that one is SITL and the other is on a physical FCU. There might be some components of the SITL causing this to happen.

That isn’t a bug … that is just MAVProxy that set back the streamrate

1 Like

use --streamrate==-1 to fix that :slight_smile:

Yes, -m --streamrate=-1 solves it. The only problem is that then I need to set rates for all messages manually, since it stops sending everything except for heartbeat.

You can still use the parameters to set the stream rate on your serial port. ArduPilot will always obey the latest message. So if you set the parameters or issue a set_streamrate first, you will be able to set your message interval as intended

can you please elaborate on this?
does this mean that, if I set rosrun mavros mavsys message_interval --id 32 --rate 15
and the run mavproxy without --streamrate==-1 option will it work?