Posts made by Alex Kushleyev

@SKA , thank you for providing all the information. We are doing more testing and will get back to you. So far cannot reproduce.

Alex

can you please check output of ifconfig ? i wonder if wlan0 is not the primary interface for some reason

@SKA ,

I have the same same error, but wifi is working (/etc/network/interfaces: No such file or directory).

I also see that your dhcp client is able to get an ip address 10.10.10.116 for wlan0, which is strange that you don't see that ip address in ifconfig..

@SKA , can you also please check journalctl -u dhcpcd to see if there is anything interesting there?

Apr 03 18:10:27 m0054 systemd[1]: Starting LSB: IPv4 DHCP client with IPv4LL support...
Apr 03 18:10:27 m0054 dhcpcd[1982]: grep: /etc/network/interfaces: No such file or directory
Apr 03 18:10:28 m0054 dhcpcd[2095]: DUID 00:01:00:01:2b:93:59:dc:ea:a6:9f:04:b1:61
Apr 03 18:10:28 m0054 dhcpcd[2095]: wlan0: IAID ca:b3:a4:ec
Apr 03 18:10:28 m0054 dhcpcd[2095]: wlan0: adding address fe80::10c0:dcc6:145e:c4cd
Apr 03 18:10:28 m0054 dhcpcd[2095]: bond0: waiting for carrier
Apr 03 18:10:28 m0054 dhcpcd[2095]: dummy0: waiting for carrier
Apr 03 18:10:28 m0054 dhcpcd[2095]: wlan0: carrier lost
Apr 03 18:10:28 m0054 dhcpcd[2095]: wlan0: deleting address fe80::10c0:dcc6:145e:c4cd
Apr 03 18:10:28 m0054 dhcpcd[2095]: wlan0: carrier acquired
Apr 03 18:10:28 m0054 dhcpcd[2095]: wlan0: IAID ca:b3:a4:ec
Apr 03 18:10:28 m0054 dhcpcd[2095]: wlan0: adding address fe80::10c0:dcc6:145e:c4cd
Apr 03 18:10:28 m0054 dhcpcd[2095]: wlan0: carrier lost
Apr 03 18:10:28 m0054 dhcpcd[2095]: wlan0: deleting address fe80::10c0:dcc6:145e:c4cd
Apr 03 18:10:28 m0054 dhcpcd[2095]: dummy0: carrier acquired
Apr 03 18:10:28 m0054 dhcpcd[2095]: dummy0: IAID 5b:b6:cf:20
Apr 03 18:10:28 m0054 dhcpcd[2095]: dummy0: adding address fe80::8837:2803:320d:3a20
Apr 03 18:10:29 m0054 dhcpcd[2095]: dummy0: soliciting a DHCP lease
Apr 03 18:10:29 m0054 dhcpcd[2095]: dummy0: soliciting an IPv6 router
Apr 03 18:10:34 m0054 dhcpcd[2095]: wlan0: carrier acquired
Apr 03 18:10:34 m0054 dhcpcd[2095]: wlan0: IAID ca:b3:a4:ec
Apr 03 18:10:35 m0054 dhcpcd[2095]: wlan0: soliciting an IPv6 router
Apr 03 18:10:35 m0054 dhcpcd[2095]: wlan0: rebinding lease of 192.168.10.179
Apr 03 18:10:35 m0054 dhcpcd[2095]: wlan0: probing address 192.168.10.179/24
Apr 03 18:10:40 m0054 dhcpcd[2095]: wlan0: leased 192.168.10.179 for 7200 seconds
Apr 03 18:10:40 m0054 dhcpcd[2095]: wlan0: adding route to 192.168.10.0/24
Apr 03 18:10:40 m0054 dhcpcd[2095]: wlan0: adding default route via 192.168.10.1
Apr 03 18:10:40 m0054 dhcpcd[2095]: forked to background, child pid 2755
Apr 03 18:10:40 m0054 systemd[1]: Started LSB: IPv4 DHCP client with IPv4LL support.
Apr 03 18:10:41 m0054 dhcpcd[2755]: dummy0: no IPv6 Routers available

@SKA , please check the output of syslog, it may contain a hint as to why wlan0 has a static ip, maybe dhcpcd is not working properly.

Also, here is output of tail -n 100 /var/log/syslog:

Apr  3 18:17:22 m0054 dhcpcd[2755]: wlan0: carrier lost
Apr  3 18:17:22 m0054 wpa_supplicant[1996]: wlan0: CTRL-EVENT-DISCONNECTED bssid=5c:e9:31:0a:78:23 reason=3 locally_generated=1
Apr  3 18:17:22 m0054 kernel: [  402.693093] RTW: rtw_ndev_uninit(wlan0) if1
Apr  3 18:17:22 m0054 systemd[1]: Starting Load/Save RF Kill Switch Status...
Apr  3 18:17:22 m0054 systemd-rfkill[4368]: Failed to open device rfkill3: No such device
Apr  3 18:17:22 m0054 systemd[1]: Started Load/Save RF Kill Switch Status.
Apr  3 18:17:22 m0054 dhcpcd[2755]: wlan0: deleting address fe80::5c1e:5176:405d:82d8
Apr  3 18:17:22 m0054 dhcpcd[2755]: wlan0: deleting default route via 192.168.10.1
Apr  3 18:17:22 m0054 dhcpcd[2755]: wlan0: deleting route to 192.168.10.0/24
Apr  3 18:17:22 m0054 dhcpcd[2755]: wlan0: removing interface
Apr  3 18:17:29 m0054 kernel: [  409.880457] usb 1-1: new high-speed USB device number 5 using xhci-hcd
Apr  3 18:17:30 m0054 kernel: [  410.369086] RTW: HW EFUSE
Apr  3 18:17:30 m0054 kernel: [  410.369100] RTW: 0x000: 29 81 00 BC  09 00 21 00  6E 04 A4 34  10 00 30 0B  
Apr  3 18:17:30 m0054 kernel: [  410.369142] RTW: 0x010: 26 26 26 26  26 26 27 27  27 27 27 13  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.369221] RTW: 0x030: 13 FF FF FF  FF FF E0 FF  FF FF 28 28  28 28 28 28  
Apr  3 18:17:30 m0054 kernel: [  410.369299] RTW: 0x050: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.369377] RTW: 0x070: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.369454] RTW: 0x090: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.369532] RTW: 0x0B0: FF FF FF FF  FF FF FF FF  7F 1A 1B 00  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.369609] RTW: 0x0D0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.369687] RTW: 0x0F0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.369764] RTW: 0x110: 65 61 6C 74  65 6B 0E 03  38 30 32 2E  31 31 61 63  
Apr  3 18:17:30 m0054 kernel: [  410.369842] RTW: 0x130: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.369920] RTW: 0x150: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.369997] RTW: 0x170: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.370075] RTW: 0x190: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.370153] RTW: 0x1B0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.370230] RTW: 0x1D0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.370308] RTW: 0x1F0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
Apr  3 18:17:30 m0054 kernel: [  410.562635] RTW: [RF_PATH] ver_id.RF_TYPE:RF_1T1R
Apr  3 18:17:30 m0054 kernel: [  410.562646] RTW: [RF_PATH] HALSPEC's rf_reg_trx_path_bmp:0x11, rf_reg_path_avail_num:1, max_tx_cnt:1
Apr  3 18:17:30 m0054 kernel: [  410.562653] RTW: [RF_PATH] PG's trx_path_bmp:0x00, max_tx_cnt:0
Apr  3 18:17:30 m0054 kernel: [  410.562665] RTW: [RF_PATH] HALDATA's trx_path_bmp:0x11, max_tx_cnt:1
Apr  3 18:17:30 m0054 kernel: [  410.562680] RTW: [TRX_Nss] HALSPEC - tx_nss:1, rx_nss:1
Apr  3 18:17:30 m0054 kernel: [  410.562686] RTW: [TRX_Nss] Registry - tx_nss:0, rx_nss:0
Apr  3 18:17:30 m0054 kernel: [  410.562691] RTW: [TRX_Nss] HALDATA - tx_nss:1, rx_nss:1
Apr  3 18:17:30 m0054 kernel: [  410.562700] RTW: txpath=0x1, rxpath=0x1
Apr  3 18:17:30 m0054 kernel: [  410.562707] RTW: txpath_1ss:0x1, num:1
Apr  3 18:17:30 m0054 kernel: [  410.563928] RTW: rtw_regsty_chk_target_tx_power_valid return _FALSE for band:0, path:0, rs:0, t:-1
Apr  3 18:17:30 m0054 kernel: [  410.567269] RTW: rtw_ndev_init(wlan0) if1 mac_addr=00:c0:ca:b3:a4:ec
Apr  3 18:17:30 m0054 systemd[1]: Starting Load/Save RF Kill Switch Status...
Apr  3 18:17:30 m0054 systemd-rfkill[4511]: Failed to parse state file /var/lib/systemd/rfkill/platform-xhci-hcd.0.auto-usb-0:1:1.2:wlan: Invalid argument
Apr  3 18:17:30 m0054 systemd[1]: Started Load/Save RF Kill Switch Status.
Apr  3 18:17:31 m0054 dhcpcd[2755]: wlan0: waiting for carrier
Apr  3 18:17:31 m0054 systemd-udevd[4512]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Apr  3 18:17:36 m0054 kernel: [  416.679144] RTW: wlan0- hw port(0) mac_addr =00:c0:ca:b3:a4:ec
Apr  3 18:17:36 m0054 wpa_supplicant[1996]: wlan0: Trying to associate with 5c:e9:31:0a:78:24 (SSID='xxxxxx' freq=5200 MHz)
Apr  3 18:17:36 m0054 wpa_supplicant[1996]: FT: Invalid key management type (2)
Apr  3 18:17:36 m0054 kernel: [  416.734679] RTW: rtw_set_802_11_connect(wlan0)  fw_state=0x00000008
Apr  3 18:17:36 m0054 kernel: [  416.868146] RTW: start auth
Apr  3 18:17:36 m0054 kernel: [  416.871600] RTW: auth success, start assoc
Apr  3 18:17:36 m0054 kernel: [  416.883349] RTW: assoc success
Apr  3 18:17:36 m0054 wpa_supplicant[1996]: wlan0: Associated with 5c:e9:31:0a:78:24
Apr  3 18:17:36 m0054 wpa_supplicant[1996]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Apr  3 18:17:36 m0054 kernel: [  416.888060] RTW: curr_tx_rate : CCK_1M (L)
Apr  3 18:17:36 m0054 kernel: [  416.888070] RTW: curr_retry_ratio : 0
Apr  3 18:17:36 m0054 kernel: [  416.888075] RTW: ra_mask : 0x00000000003ffff0
Apr  3 18:17:36 m0054 kernel: [  416.898522] RTW: recv eapol packet 1/4
Apr  3 18:17:36 m0054 wpa_supplicant[1996]: wlan0: WPA: Key negotiation completed with 5c:e9:31:0a:78:24 [PTK=CCMP GTK=CCMP]
Apr  3 18:17:36 m0054 wpa_supplicant[1996]: wlan0: CTRL-EVENT-CONNECTED - Connection to 5c:e9:31:0a:78:24 completed [id=0 id_str=]
Apr  3 18:17:36 m0054 kernel: [  416.925772] RTW: set group key camid:1, addr:5c:e9:31:0a:78:24, kid:1, type:AES
Apr  3 18:17:36 m0054 dhcpcd[2755]: wlan0: carrier acquired
Apr  3 18:17:36 m0054 dhcpcd[2755]: wlan0: IAID ca:b3:a4:ec
Apr  3 18:17:36 m0054 dhcpcd[2755]: wlan0: adding address fe80::5c1e:5176:405d:82d8
Apr  3 18:17:37 m0054 dhcpcd[2755]: wlan0: soliciting an IPv6 router
Apr  3 18:17:37 m0054 dhcpcd[2755]: wlan0: rebinding lease of 192.168.10.179
Apr  3 18:17:37 m0054 dhcpcd[2755]: wlan0: truncated packet (179) from 127.0.0.1
Apr  3 18:17:37 m0054 dhcpcd[2755]: wlan0: truncated packet (207) from 127.0.0.1
Apr  3 18:17:37 m0054 dhcpcd[2755]: wlan0: probing address 192.168.10.179/24
Apr  3 18:17:42 m0054 dhcpcd[2755]: wlan0: leased 192.168.10.179 for 7200 seconds
Apr  3 18:17:42 m0054 dhcpcd[2755]: wlan0: adding route to 192.168.10.0/24
Apr  3 18:17:42 m0054 dhcpcd[2755]: wlan0: adding default route via 192.168.10.1
Apr  3 18:17:50 m0054 dhcpcd[2755]: wlan0: no IPv6 Routers available

@SKA , can you please try to power down the wifi device and power it back up (using the commands below) and check the output of dmesg.

#turn off USB VBUS
voxl-gpio write 157 0

#turn on USB VBUS
voxl-gpio write 157 1

my dmesg output:

[   24.123592] usb 1-1: USB disconnect, device number 2
[   24.152384] RTW: rtw_ndev_uninit(wlan0) if1
[   24.172973] RTW: rtw_dev_unload: driver not in IPS
[   33.464284] usb 1-1: new high-speed USB device number 3 using xhci-hcd
[   33.602465] usb 1-1: New USB device found, idVendor=0bda, idProduct=c820, bcdDevice= 2.00
[   33.602487] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   33.602502] usb 1-1: Product: 802.11ac NIC
[   33.602517] usb 1-1: Manufacturer: Realtek
[   33.602531] usb 1-1: SerialNumber: 123456
[   33.614447] RTW: [HALMAC]55772M
               HALMAC_MAJOR_VER = 1
               HALMAC_PROTOTYPE_VER = 6
               HALMAC_MINOR_VER = 6
               HALMAC_PATCH_VER = 22
[   33.760178] vdd_tof: disabling
[   33.760182] vdd_hap_boost: disabling
[   33.835010] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x40d00
[   33.835034] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x40d00
[   33.835055] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x40d00
[   33.835075] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x40d00
[   33.835095] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x40d00
[   33.835115] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x40d00
[   33.951477] RTW: HW EFUSE
[   33.951489] RTW: 0x000: 29 81 00 BC  09 00 21 00  6E 04 A4 34  10 00 30 0B  
[   33.951530] RTW: 0x010: 26 26 26 26  26 26 27 27  27 27 27 13  FF FF FF FF  
[   33.951570] RTW: 0x020: FF FF 2D 2D  2D 2D 2D 2D  2D 2D 2D 2D  2D 2D 2D 2D  
[   33.951632] RTW: 0x030: 13 FF FF FF  FF FF E0 FF  FF FF 28 28  28 28 28 28  
[   33.951671] RTW: 0x040: 28 28 28 28  28 02 FF FF  FF FF FF FF  FF FF FF FF  
[   33.951710] RTW: 0x050: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.951749] RTW: 0x060: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.951788] RTW: 0x070: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.951827] RTW: 0x080: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.951866] RTW: 0x090: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.951904] RTW: 0x0A0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.951943] RTW: 0x0B0: FF FF FF FF  FF FF FF FF  7F 1A 1B 00  FF FF FF FF  
[   33.951982] RTW: 0x0C0: FF 22 00 00  00 E6 00 00  00 FF 26 FF  FF FF FF FF  
[   33.952179] RTW: 0x0D0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.952291] RTW: 0x0E0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.952331] RTW: 0x0F0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.952369] RTW: 0x100: DA 0B 20 C8  C3 46 02 00  C0 CA B3 A4  EC 09 03 52  
[   33.952408] RTW: 0x110: 65 61 6C 74  65 6B 0E 03  38 30 32 2E  31 31 61 63  
[   33.952447] RTW: 0x120: 20 4E 49 43  08 03 31 32  33 34 35 36  FF FF FF FF  
[   33.952486] RTW: 0x130: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.952533] RTW: 0x140: FF FF FF FF  00 00 31 0F  FF FF FF FF  FF FF FF FF  
[   33.952602] RTW: 0x150: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.952641] RTW: 0x160: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.952691] RTW: 0x170: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.952730] RTW: 0x180: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.952769] RTW: 0x190: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.952808] RTW: 0x1A0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.952847] RTW: 0x1B0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.952885] RTW: 0x1C0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.952924] RTW: 0x1D0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.952963] RTW: 0x1E0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.953002] RTW: 0x1F0: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF  
[   33.953329] RTW: hal_com_config_channel_plan chplan:0x7F
[   34.184253] RTW: [RF_PATH] ver_id.RF_TYPE:RF_1T1R
[   34.184263] RTW: [RF_PATH] HALSPEC's rf_reg_trx_path_bmp:0x11, rf_reg_path_avail_num:1, max_tx_cnt:1
[   34.184269] RTW: [RF_PATH] PG's trx_path_bmp:0x00, max_tx_cnt:0
[   34.184276] RTW: [RF_PATH] Registry's trx_path_bmp:0x00, tx_path_lmt:0, rx_path_lmt:0
[   34.184283] RTW: [RF_PATH] HALDATA's trx_path_bmp:0x11, max_tx_cnt:1
[   34.184288] RTW: [RF_PATH] HALDATA's rf_type:RF_1T1R, NumTotalRFPath:1
[   34.184296] RTW: [TRX_Nss] HALSPEC - tx_nss:1, rx_nss:1
[   34.184301] RTW: [TRX_Nss] Registry - tx_nss:0, rx_nss:0
[   34.184307] RTW: [TRX_Nss] HALDATA - tx_nss:1, rx_nss:1
[   34.184315] RTW: txpath=0x1, rxpath=0x1
[   34.184321] RTW: txpath_1ss:0x1, num:1
[   34.185543] RTW: rtw_regsty_chk_target_tx_power_valid return _FALSE for band:0, path:0, rs:0, t:-1
[   34.188733] RTW: rtw_ndev_init(wlan0) if1 mac_addr=00:c0:ca:b3:a4:ec
[   35.507557] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

@SKA , I don't have a file "station_band", also 2ghz seems incorrect (maybe it should be 2.4ghz? not sure). Try to rename / remove that file?

what does iwconfig wlan0 output? what about dmesg? anything useful?

Alex

@Rowan-Dempster , Thanks for the update!

On my end, I did not get a chance to enable MISP pipeline (normalization in particular) to run offline. Let me double check something with you - would you want to load a log with raw10 and resize + generate the normalized image (of a different size) or just keep the same size as input?

Since you have the basic rolling shutter QVIO working, it would be interesting to see how that compares to the AR0144 QVIO from the same data set. Any details you would like to share? (only if you want to)

Regarding playback results from QVIO output not being exactly repeatable -- " no deterministic mechanism to ensure that voxl-qvio-server initializes using the same camera frame" -- what do you mean by that? if you start QVIO and start feeding the frames + imu data from voxl-replay, the data should arrive into QVIO repeatably and QVIO should initialize on the same frame - after the initialization conditions have been satisfied.

If I remember correctly the way QVIO app works is that it may hold the frame until all the IMU data for that frame has arrived and then pushes the frame into the QVIO algorithm. If you push the frame before pushing all the IMU data, then the algorithm will still process the frame but it wont have the IMU data for the whole duration of the frame capture.

The frame capture duration for global shutter cameras is simple :

• start = start of exposure
• end = end of exposure = start of exposure + exposure time
  (i believe it is common to assign a timestamp which is equal to the center of exposure, which is between the start and end timestamps).
• center of exposure = start of exposure + (exposure time)/2

In order to find the center of exposure for rolling shutter camera, you need to use the following formula, as used in our EIS implementation in MISP:

int64_t center_of_exposure_ns = start_of_exposure_ns + (exposure_time_ns + readout_time_ns)/2;

In any case, this would be something to double check.. also i don't know how far your trajectories are from run to run.

Another tip: since you don't have ground truth in your data, it helps to start and end your data collection in exactly the same spot and orientation, so you can use the end position drift as a good metric (ground truth).

Alex

@cbay ,

Here is the diagram for M0188 showing resistor R10 and R11 that need to be added (0 ohm) in order to connect the sync signal to the camera slot 1 and 3.

For some historical reasons, these resistors were DNI'ed in order to prevent (incorrectly configured) hires cameras from outputting a sync signal and interfering with the tracking cameras.

Please be careful when adding the resistors, as spacing between components is pretty tight.

We will update the docs for M0188, M0195 and M0173 to reflect the default state and how to enable the sync on the camera ports that do not have it already connected.

I have just tested this on voxl2 using SDK 1.6.3 and it seems to be working. The prints were updated, but what you see is normal (i saw the same messages). Did you check dmesg for any errors from wifi dongle? I used the following wifi adapter, which is unfortunately EOL (with our M0141 expansion board) :

────────────────────────────────────────────────────────────────────────────────
system-image: 1.8.06-M0054-14.1a-perf
kernel:       #1 SMP PREEMPT Wed Oct 22 04:13:18 UTC 2025 4.19.125
────────────────────────────────────────────────────────────────────────────────
hw platform:  M0054
mach.var:     1.0.1
SKU:          MCCA-M0054-C8
────────────────────────────────────────────────────────────────────────────────
voxl-suite:   1.6.3
────────────────────────────────────────────────────────────────────────────────
no current network connection
────────────────────────────────────────────────────────────────────────────────

voxl2:/$ voxl-wifi station xxxxxx yyyyyy
Detected WiFi interface: wlan0
NetworkManager not installed, using legacy wpa_supplicant/hostapd
stopping softap mode
Enabling station mode on wlan0 (legacy)...
creating wpa_supplicant configuration for station mode
Station mode enabled on wlan0
Station mode configured!

voxl2:/$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=118 time=11.806 ms

cross-posting the reply here as well, since this is more relevant thread:

I have uploaded the latest ar0144 drivers with fsin versions for all camera slots here : https://storage.googleapis.com/modalai_public/temp/ar0144/ar0144_drivers_20260402.zip

There are two additional files (inside the zip), which you should copy to /usr/lib/camera to make sure you have the latest updates:

• com.qti.sensor.ar0144.so -- contains functions for exposure / gain control (we recently made some improvements to make gain control smoother)
• com.qti.tuned.default.bin -- fixed gain scaling so that min gain (1.0x analog gain) is equal to 100 in the HAL3 gain units, not 54 (and the max gain will be 29.6 = 29600 for AR0144) -- you can also double check this using voxl-camera-server -l and update the min/max gain settings in your voxl-camera-server.conf to make sure you are using the full range.

My colleague will follow up with a diagram for locations of the DNI resistors that need to be installed to enable sync signal for camera slots 1 and 3 (0402 0-ohm resistor)

Alex

@Aniruddha , we currently do not have an option to order this via our online shop, but you have some other options:

• email us using contact form and request a custom order of those parts : https://www.modalai.com/pages/contact-us
• download the CAD model (https://developer.modalai.com/asset) and 3D print the part(s) yourself or order them to be printed. We use MJF material for these parts.

Sorry for the inconvenience. We will look into making the spare part ordering process easier.

Alex

I have uploaded the latest ar0144 drivers with fsin versions for all camera slots here : https://storage.googleapis.com/modalai_public/temp/ar0144/ar0144_drivers_20260402.zip

There are two additional files (inside the zip), which you should copy to /usr/lib/camera to make sure you have the latest updates:

• com.qti.sensor.ar0144.so -- contains functions for exposure / gain control (we recently made some improvements to make gain control smoother)
• com.qti.tuned.default.bin -- fixed gain scaling so that min gain (1.0x analog gain) is equal to 100 in the HAL3 gain units, not 54 (and the max gain will be 29.6 = 29600 for AR0144) -- you can also double check this using voxl-camera-server -l and update the min/max gain settings in your voxl-camera-server.conf to make sure you are using the full range.

My colleague will follow up with a diagram for locations of the DNI resistors that need to be installed to enable sync signal for camera slots 1 and 3 (0402 0-ohm resistor)

Alex

@cbay , thanks for clarifying

On M0188, J1 and J3 do not have the sync signal connected. We will release a diagram shortly showing where to install 0-ohm resistors on M0188 to connect the sync signal to the corresponding camera ports.

And you will need fsin drivers for J0, J1, J2, J3 (will share them shortly as well)

By default, the AR0144 tracking cameras are connected to J0 and J6 (camera slots 0, 6), which are actually connected to a single CSI interface and are used in a combo mode (two 1-lane (mipi lane) cameras merged into a single 4-lane mipi interface).

Note that when the fsin or combo (combo mode drivers also use input trigger) are used, but there is no actual sync / trigger signal getting to the camera, then there will be no frames produced. This is specific to the AR0144 camera, as other cameras may operate differently and use the sync signal to align the readout trigger (so in absence of trigger signal, those cameras would simply be not sync'ed, but AR0144 just does not send any frames)

Alex

@qt , there is a "decimator" param, which reduces the TOF fps in standby mode (when drone is not flying) in order to reduce the cpu usage, since the TOF processing software can use substantial cpu depending on the FPS. https://docs.modalai.com/voxl-camera-server/#camera-server-config-file

in your case, the decimator is set to 5, but i also see that "standby enabled" is set to false, so perhaps there is a bug that still applies the fps decimation.

Can you please try setting the decimator to 1 and see if that resolves your issue and we will double check if the standby_enabled parameter is not working correctly.

Alex

@SKA ,

Most of the supported cameras (except for Boson, Hadron) have their reset signal connected to VOXL2, so when the cameras are not in use, they are shut down via the reset pin. This means that the camera modules may still get power, but they are shut down.

There are many power rails and interposers - some power rails remain on all the time (5.0, 3.8V) and others may be shut down by PMIC when not in use. Different cameras use different power rails for their operation, so it is hard to answer this question without knowing the specific use case.

Alex

@jameskuesel ,

For item 1, (a frame from hires recording with eis), you can do this already by just capturing the YUV from the hires_misp_color stream. you could do this using existing tool voxl-record-raw-image.

For item 2, the full frame can also be captured (using the same tool) but only in raw bayer format. This would be good for offline processing, if you wanted to get the maximum image quality, however this image would not have any processing applied from MISP.

Additionally, since MISP supports multiple outputs, as you already know, (misp channels), you could set up one channel to be a full frame image (which you normally dont stream), with EIS off.

So with correct voxl-camera-server.conf, you should be able to get all the streams you want

• full frame
• hires recording
• low-res streaming

And grab YUVs from any of those streams. The last part would be then just encoding them to JPG (which could be done separately or part of voxl-record-raw-image, which we could add)

If you send me your voxl-camera-server.conf (or the part specific to the hires camera), i can update it to show you how you can get the three streams.

Alex

@bendraper , I will ask around.

Hello @Igor ,

After a quick look your concerns seem valid to me. We will investigate this further and get back to you soon.

Thank you for reporting the issue.

Alex