@Eric-Katzfey Ok, thanks. Looking forward to it. For now, we have put a forked version of voxl-mavlink-server on 1 drone which had this issue a few times. This forked version will log the requested time offset instead of applying it. If we get a log from that, we will post it here if that helps.

@Eric-Katzfey Thanks for your prompt response! I think it is going down because it gets out of offboard mode because when the time is updated some of our processes also don't work properly anymore. But I don't know if it is only our processes which are affected.

The drone already had GPS disabled when this happened:

AIRFRAME=MULTICOPTER
GPS=NONE
RC=CRSF_MAV
ESC=VOXL_ESC
POWER_MANAGER=VOXLPM
AIRSPEED_SENSOR=NONE
DISTANCE_SENSOR=NONE
OSD=DISABLE
DAEMON_MODE=ENABLE
SENSOR_CAL=ACTUAL
ARTIFACT_MODE=DISABLE
EXTRA_STEPS=()

We are not connected to a GCS. Just PX4. We haven't seen this issue on sdk 1.1.3 (our previous version) but sometimes on sdk 1.4.5 (our current version) and also on multiple drones.

We have experienced an issue where the system clock of the voxl is set based on a system time message received via mavlink which causes all kinds of timing issues resulting in an immediate drone landing/crash. The time which is set is incorrect. In one instance I even saw that it sets it to a day ahead. Note that it only sometimes happens. Most of our flights don't have this issue but when it happens it is a direct problem.

In our logs we see the following log lines

Oct 27 08:21:29 JOHN voxl-mavlink-server[2280]: setting UTC clock from GPS to: Mon Oct 27 08:20:15 2025
Oct 27 08:21:29 JOHN voxl-mavlink-server[2280]: setting UTC clock from GPS to: Mon Oct 27 08:20:16 2025
Oct 27 08:21:29 JOHN voxl-mavlink-server[2280]: setting UTC clock from GPS to: Mon Oct 27 08:20:17 2025
Oct 27 08:21:29 JOHN voxl-mavlink-server[2280]: setting UTC clock from GPS to: Mon Oct 27 08:20:18 2025
Oct 27 08:21:29 JOHN voxl-mavlink-server[2280]: setting UTC clock from GPS to: Mon Oct 27 08:20:19 2025
Oct 27 08:21:29 JOHN voxl-mavlink-server[2280]: setting UTC clock from GPS to: Mon Oct 27 08:20:20 2025
Oct 27 08:21:29 JOHN voxl-mavlink-server[2280]: setting UTC clock from GPS to: Mon Oct 27 08:20:21 2025

The software versions on this drone are:

────────────────────────────────────────────────────────────────────────────────
system-image: 1.8.02-M0054-14.1a-perf
kernel:       #1 SMP PREEMPT Mon Nov 11 22:47:44 UTC 2024 4.19.125
────────────────────────────────────────────────────────────────────────────────
hw platform:  M0054
mach.var:     1.0.1
SKU:          MCCA-M0054-C28-T0-M0-X0
────────────────────────────────────────────────────────────────────────────────
voxl-suite:   1.4.5
────────────────────────────────────────────────────────────────────────────────

 Service Name             |  Version  |  Enabled  |   Running   |  CPU Usage
───────────────────────────────────────────────────────────────────────────────
 docker-autorun           |    1.3.1  | Disabled  | Not Running |
 modallink-relink         |    1.1.6  | Disabled  | Not Running |
 voxl-camera-server       |    2.2.1  |  Enabled  | Not Running |
 voxl-cpu-monitor         |    0.6.0  |  Enabled  |   Running   |     0.0%
 voxl-dfs-server          |    0.2.0  | Disabled  | Not Running |
 voxl-elrs-startup        |    0.4.7  | Disabled  | Not Running |
 voxl-feature-tracker     |    0.5.2  | Disabled  | Not Running |
 voxl-flow-server         |    0.3.6  | Disabled  | Not Running |
 voxl-imu-server          |    1.1.3  |  Enabled  | Not Running |
 voxl-io-server           |    0.0.5  | Disabled  | Not Running |
 voxl-lepton-server       |    1.3.3  | Disabled  | Not Running |
 voxl-lepton-tracker      |    0.0.4  | Disabled  | Not Running |
 voxl-logger              |    0.5.3  | Disabled  | Not Running |
 voxl-mavcam-manager      |    0.5.8  | Disabled  | Not Running |
 voxl-mavlink-server      |    1.4.7  |  Enabled  |   Running   |     3.8%
 voxl-modem               |    1.1.6  | Disabled  | Not Running |
 voxl-open-vins-server    |   0.3.12  |  Enabled  | Not Running |
 voxl-osd                 |    0.1.7  | Disabled  | Not Running |
 voxl-portal              |   0.7.10  | Disabled  | Not Running |
 voxl-px4-imu-server      |    0.1.2  | Disabled  | Not Running |
 voxl-px4                 |   1.14.0  |  Enabled  |   Running   |    19.2%
 voxl-qvio-server         |    1.2.0  | Disabled  | Not Running |
 voxl-rangefinder-server  |    0.1.5  | Disabled  | Not Running |
 voxl-remote-id           |    0.0.9  | Disabled  | Not Running |
 voxl-seek-server         |   0.3.12  | Disabled  | Not Running |
 voxl-softap              |    0.3.5  | Disabled  | Not Running |
 voxl-state-estimator     |    0.0.5  | Disabled  | Not Running |
 voxl-static-ip           |    0.3.5  | Disabled  | Not Running |
 voxl-streamer            |    0.7.5  | Disabled  | Not Running |
 voxl-tag-detector        |    0.0.4  | Disabled  | Not Running |
 voxl-tflite-server       |    0.4.1  | Disabled  | Not Running |
 voxl-time-sync           |    1.4.7  | Disabled  | Not Running |
 voxl-uvc-server          |    0.1.7  | Disabled  | Not Running |
 voxl-vision-hub          |   1.8.21  |  Enabled  | Not Running |
 voxl-vrx                 |   1.3.14  | Disabled  | Not Running |
 voxl-vtx                 |   1.3.14  | Disabled  | Not Running |
 voxl-wait-for-fs         |    1.4.7  |  Enabled  |  Completed  |

Where voxl-camera-server and voxl-open-vins-server are our own forked versions with some minor changes.

We don't have GPS enabled on our drone:

px4-param show -a | grep GPS
    ADSB_GPS_OFF_LAT [-1,5] : 0
    ADSB_GPS_OFF_LON [-1,6] : 0
x   COM_ARM_WO_GPS [208,483] : 1
x   EKF2_GPS_CHECK [304,586] : 245
x + EKF2_GPS_CTRL [305,587] : 0
x   EKF2_GPS_DELAY [306,588] : 110.0000
x   EKF2_GPS_POS_X [307,589] : 0.0000
x   EKF2_GPS_POS_Y [308,590] : 0.0000
x   EKF2_GPS_POS_Z [309,591] : 0.0000
x   EKF2_GPS_P_GATE [310,592] : 5.0000
x   EKF2_GPS_P_NOISE [311,593] : 0.5000
x   EKF2_GPS_V_GATE [312,594] : 5.0000
x   EKF2_GPS_V_NOISE [313,595] : 0.3000
x   EKF2_REQ_GPS_H [357,641] : 10.0000
    FW_GPSF_LT [-1,721] : 30
    FW_GPSF_R [-1,722] : 15.0000
    GPS_1_GNSS [-1,841] : 0
    GPS_1_PROTOCOL [-1,842] : 1
    GPS_2_GNSS [-1,843] : 0
    GPS_2_PROTOCOL [-1,844] : 1
    GPS_DUMP_COMM [-1,845] : 0
    GPS_PITCH_OFFSET [-1,846] : 0.0000
    GPS_SAT_INFO [-1,847] : 0
    GPS_UBX_BAUD2 [-1,848] : 230400
    GPS_UBX_CFG_INTF [-1,849] : 0
x + GPS_UBX_DYNMODEL [418,850] : 6
    GPS_UBX_MODE [-1,851] : 0
    GPS_YAW_OFFSET [-1,852] : 0.0000
    LPE_GPS_DELAY [-1,937] : 0.2900
    LPE_GPS_VXY [-1,938] : 0.2500
    LPE_GPS_VZ [-1,939] : 0.2500
    LPE_GPS_XY [-1,940] : 1.0000
    LPE_GPS_Z [-1,941] : 3.0000
x   MAV_USEHILGPS [456,999] : 0
    SENS_EN_GPSSIM [-1,1448] : 0
    SENS_GPS_MASK [-1,1484] : 7
    SENS_GPS_PRIME [-1,1485] : 0
    SENS_GPS_TAU [-1,1486] : 10.0000
    SIM_GPS_USED [-1,1555] : 10
x + SYS_HAS_GPS [764,1658] : 0
    UAVCAN_SUB_GPS [-1,1930] : 1
    UCAN1_GPS0_SUB [-1,2048] : -1
    UCAN1_GPS1_SUB [-1,2049] : -1
    UCAN1_GPS_PUB [-1,2050] : -1
    UCAN1_UORB_GPS [-1,2053] : -1
    UCAN1_UORB_GPS_P [-1,2054] : -1

Have you seen this issues before and/or do you have any idea how this could be caused?

@Alex-Kushleyev I tested it and it works nice (I didn't test the 255 but I expect that should work). I already figured that the frequencies are now multiples of 10Hz with some minimum value (I don't know which one but at least below -p 10 I don't hear the frequency drop anymore). So it ranges up to 2550Hz. And I think you also adjusted the duration to be multiples of 10ms to match with the format of the ESC parameters?

Regarding the usage change, I understand if you don't want to create a breaking change. But I think it would be good when the print_usage matches with the actual use. It took me some trial and error to get it working. Maybe also an idea to use -f for the frequency because -p refers to period which is not correct anymore and it is now already changing the functionality of the tone generation (you could even let -p in it to keep it backwards compatible but that maybe makes it unnecessarily complicated). And also good to allow the ESC mapping to go up to 15.

For us it is sufficient to use the startup tone. But I played around a little bit with the tone generation and if you use it using the qshell commands you need to wait the duration of the tone to send a new tone (as the qshell command immediately returns and it doesn't accept a command while the sound is still playing) which makes it difficult to get the timing right in playing a tune. I don't know what the end goal should be of this but if it is playing custom tunes using the commands this is something to keep in mind I think. I had some fun trying to play the Imperial March on the ESCs which kind of works but not as smooth as the startup sound can play.

@Alex-Kushleyev Thanks for the update! Sorry for my slow response. I was away since last Thursday. Sounds great to use the 0 values for the startup tone. That is really helpful. I will test this as soon as I can. Did you also change the frequency mapping (although I don't think I need this if I use the startup tone)?

Will you still make the change from qshell voxl_esc [arguments...] <command> to qshell voxl_esc <command> [arguments...]? If not, can you update the print_usage: https://github.com/modalai/px4-firmware/blob/main/src/drivers/actuators/voxl_esc/voxl_esc.cpp#L1350 to match with the actual usage?

@Alex-Kushleyev Thanks for your response. Sounds good.

For some background, we currently only put power on the ESC when we are about to fly. When the ESC is powered, the startup sound can be heard which is an audio notification to anybody closeby that this drone can soon start spinning up his motors. With the new PX4 firmware in sdk-1.3, there is a version check in the ESC initialization which now fails because we haven't powered the ESC at that moment. We're now thinking of keeping the ESC always powered but we still want to have this audio notification when the drone is about to fly. So that's why I was looking into this and also wanted to mimic our startup tone with the same frequencies. It would be nice if we could also send a sequence of tones or reference to preconfigured sounds but else I will just send multiple commands after each other. The python script looks nice but it doesn't work for us because it requires voxl-px4 to be not running. If you have a better suggestion of playing the tones I would be interested to hear it.

I can play tones on the ESC via the following command (after running px4-alias.sh) :

qshell voxl_esc -i 1 -p 50 -d 30 -v 20 tone

This should actually be qshell voxl_esc tone -i 1 -p 50 -d 30 -v 20 but that will fail because voxl_esc will take the last command as verb but it should take argument index 2 as verb.

https://github.com/modalai/px4-firmware/blob/f9d249f170d15c34217c849980cd8ecd4b0a17ad/src/drivers/actuators/voxl_esc/voxl_esc.cpp#L673:

const char *verb = argv[argc - 1];

should be

const char *verb = argv[2];

If you put the tone in front you get the following usage message:

Aug 06 10:10:11 SPOT voxl-px4[11774]: INFO  [muorb] SLPI:
Aug 06 10:10:11 SPOT voxl-px4[11774]: ### Description
Aug 06 10:10:11 SPOT voxl-px4[11774]: This module is responsible for...
Aug 06 10:10:11 SPOT voxl-px4[11774]: ### Implementation
Aug 06 10:10:11 SPOT voxl-px4[11774]: By default the module runs on a wor
Aug 06 10:10:11 SPOT voxl-px4[11774]: INFO  [muorb] SLPI: Usage: voxl_esc <command> [arguments...]
Aug 06 10:10:11 SPOT voxl-px4[11774]: INFO  [muorb] SLPI:  Commands:

which says the <command> (tone) should be in front of the arguments.

I have a question about the usage. The documentation says this:

Aug 06 10:10:28 SPOT voxl-px4[11774]:    tone          Send tone generation request to ESC
Aug 06 10:10:28 SPOT voxl-px4[11774]: INFO  [muorb] SLPI:      -i <val>    ESC ID, 0-3
Aug 06 10:10:28 SPOT voxl-px4[11774]: INFO  [muorb] SLPI:      -p <val>    Period of sound, inverse frequency, 0-255
Aug 06 10:10:28 SPOT voxl-px4[11774]: INFO  [muorb] SLPI:      -d <val>    Duration of the sound, 0-255, 1LSB = 13ms
Aug 06 10:10:28 SPOT voxl-px4[11774]: INFO  [muorb] SLPI:      -v <val>    Power (volume) of sound, 0-100

I want to know how the period relates to the tone frequency in Hz. The documentation is not correct or incomplete because I can hear a sound with period=0 which should be an infinitely high frequency. When I want to play a tone of 2110 Hz, the inverse is 0,0004739 seconds. I thought there is maybe a scaling factor of 1e5 to make it within the range of 0-255 but the sounds I hear do not match up with the frequencies I expect. How does it work?

@James-Strawson Thanks for your reply! It made me realise what the error must be. We use a locally cloned repository for libmodalpipe because we want to build our software directly on the drone. This is then used in the build and link process of our software. This happened to be on the 'master' branch and not the 'SDK-1.0.0' branch. So the pipe clients use a different version than the pipe servers which is likely the cause of our errors.

@James-Strawson Any comment on this?

I have the same issue. If you try it multiple times sometimes it will work but most of the times it will crash like shown.