Posts made by John Nomikos

@Alex-Kushleyev

Thank you for the advice. I did this a couple times, and the results are interesting to say the least.

If the testfile does not already exist, I get 1.4 gb/s.

If it does exist, I get 20mb/s with 10 blocks of 50M.

voxl2:/$ sync && time ./sd_test.sh
10+0 records in
10+0 records out
524288000 bytes (524 MB, 500 MiB) copied, 0.368724 s, 1.4 GB/s

real	0m7.950s
user	0m0.017s
sys	0m0.385s
voxl2:/$ rm /media/gfr/testfile 
voxl2:/$ 
voxl2:/$ sync && time ./sd_test.sh
10+0 records in
10+0 records out
524288000 bytes (524 MB, 500 MiB) copied, 0.365262 s, 1.4 GB/s
    
real	0m7.911s
user	0m0.015s
sys	0m0.383s
voxl2:/$ sync && time ./sd_test.sh
10+0 records in
10+0 records out
524288000 bytes (524 MB, 500 MiB) copied, 22.8395 s, 23.0 MB/s

real	0m24.506s
user	0m0.010s
sys	0m0.880s
voxl2:/$ sync && time ./sd_test.sh
10+0 records in
10+0 records out
524288000 bytes (524 MB, 500 MiB) copied, 22.8774 s, 22.9 MB/s

real	0m24.502s
user	0m0.003s
sys	0m0.870s
voxl2:/$ rm /media/gfr/testfile 
voxl2:/$ 
voxl2:/$ sync && time ./sd_test.sh
10+0 records in
10+0 records out
524288000 bytes (524 MB, 500 MiB) copied, 0.364634 s, 1.4 GB/s

real	0m7.992s
user	0m0.004s
sys	0m0.393s

When changing the block size to 5mb rather than 50, I saw faster speeds, even when writing to existing file.

voxl2:/$ rm -rf /media/gfr/testfile 
voxl2:/$ ./sd_test1.sh 
10+0 records in
10+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.0784419 s, 668 MB/s
voxl2:/$ 
voxl2:/$ ./sd_test1.sh 
10+0 records in
10+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.412609 s, 127 MB/s
voxl2:/$ ./sd_test1.sh 
10+0 records in
10+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.407672 s, 129 MB/s
voxl2:/$ 
voxl2:/$ ./sd_test1.sh 
10+0 records in
10+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.395725 s, 132 MB/s
voxl2:/$ ./sd_test1.sh 
10+0 records in
10+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.341873 s, 153 MB/s
voxl2:/$ ./sd_test1.sh 
10+0 records in
10+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.42811 s, 122 MB/s

Based on these results, I assume that optimizations are done when writing a new file to the SD card, because I thought the theoretical maximum for writing to an SD card via SDR104 was 104 MB/s. Either that, or the test is flawed if the file does not already exist.I know that there's likely more overhead when writing to an existing file.

Also I see that less block size is giving higher speed, so I am assuming that the slower speeds I am seeing is due to the overhead of writing very large blocks of data.

Appreciate the help

Good afternoon,

I was wondering if there is anything I can do to increase the speed of the SD card slot on the Ethernet and USB Hub Add-On board.

When an SD card is connected to it, the dmesg output shows that it is in SDR104 mode, and yet it only gives about 52 MB/S upload speed on average. However, the same SD card connected to an external SD card reader over USB 3.0 JST gives about 92 MB/S average upload speed.

Dmesg output:

[    0.323948] pm8150a_s3_mmcx_sup_level: regulator get failed, ret=-517
[    0.324633] pm8150a_s3_mmcx_sup_level: supplied by pm8150_s3_mmcx_sup_level
[    0.328906] pm8150a_s4_level: supplied by pm8150a_s3_mmcx_sup_level
[    1.905683] mmc0: SDHCI controller on 8804000.sdhci [8804000.sdhci] using 64-bit ADMA in legacy mode
[    2.168643] mmc0: new ultra high speed SDR104 SDXC card at address aaaa
[    2.169465] mmcblk0: mmc0:aaaa SR64G 59.5 GiB 
[    2.170249]  mmcblk0: p1
[    4.583627] mmc0: data txfr (0x00200000) error: -84 after 0 ms
[    4.583647] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[    4.583658] mmc0: sdhci: Sys addr:  0x00000018 | Version:  0x00007202
[    4.583671] mmc0: sdhci: Blk size:  0x00000200 | Blk cnt:  0x00000010
[    4.583681] mmc0: sdhci: Argument:  0x00000820 | Trn mode: 0x0000003b
[    4.583690] mmc0: sdhci: Present:   0x03f802f6 | Host ctl: 0x0000001e
[    4.583699] mmc0: sdhci: Power:     0x0000000d | Blk gap:  0x00000000
[    4.583708] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x00000007
[    4.583718] mmc0: sdhci: Timeout:   0x0000000a | Int stat: 0x00000000
[    4.583728] mmc0: sdhci: Int enab:  0x03bf100b | Sig enab: 0x03bf100b
[    4.583737] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[    4.583745] mmc0: sdhci: Caps:      0x3629c8b2 | Caps_1:   0x0000808f
[    4.583754] mmc0: sdhci: Cmd:       0x0000123a | Max curr: 0x00000000
[    4.583763] mmc0: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0x00000000
[    4.583772] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000900
[    4.583779] mmc0: sdhci: Host ctl2: 0x0000000b
[    4.583788] mmc0: sdhci: ADMA Err:  0x00000003 | ADMA Ptr: 0x00000000edc9a224
[    4.583958] mmc0: clk: 201500000 claimer: (null) pwr: 12
[    4.583960] mmc0: rpmstatus[pltfm](runtime-suspend:usage_count:disable_depth)(0:1:0)
[    4.583961] mmc0: sdhci: ============================================
[    4.591617] mmc0: data txfr (0x00200000) error: -84 after 1 ms
[    4.591630] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[    4.591640] mmc0: sdhci: Sys addr:  0x00000180 | Version:  0x00007202
[    4.591650] mmc0: sdhci: Blk size:  0x00000200 | Blk cnt:  0x00000030
[    4.591659] mmc0: sdhci: Argument:  0x00000880 | Trn mode: 0x0000003b
[    4.591668] mmc0: sdhci: Present:   0x030802f6 | Host ctl: 0x0000001e
[    4.591679] mmc0: sdhci: Power:     0x0000000d | Blk gap:  0x00000000
[    4.591691] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x00000007
[    4.591701] mmc0: sdhci: Timeout:   0x0000000a | Int stat: 0x00000000
[    4.591711] mmc0: sdhci: Int enab:  0x03bf100b | Sig enab: 0x03bf100b
[    4.591721] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[    4.591730] mmc0: sdhci: Caps:      0x3629c8b2 | Caps_1:   0x0000808f
[    4.591740] mmc0: sdhci: Cmd:       0x0000123a | Max curr: 0x00000000
[    4.591749] mmc0: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0x00000000
[    4.591758] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000900
[    4.591766] mmc0: sdhci: Host ctl2: 0x0000000b
[    4.591774] mmc0: sdhci: ADMA Err:  0x00000003 | ADMA Ptr: 0x00000000edc9a3c8
[    4.591933] mmc0: clk: 201500000 claimer: (null) pwr: 12
[    4.591935] mmc0: rpmstatus[pltfm](runtime-suspend:usage_count:disable_depth)(0:1:0)
[    4.591936] mmc0: sdhci: ============================================
[   76.014499] mmc0: data txfr (0x00200000) error: -84 after 0 ms
[   76.014523] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[   76.014533] mmc0: sdhci: Sys addr:  0x00000008 | Version:  0x00007202
[   76.014543] mmc0: sdhci: Blk size:  0x00000200 | Blk cnt:  0x00000001
[   76.014552] mmc0: sdhci: Argument:  0x00000810 | Trn mode: 0x0000003b
[   76.014561] mmc0: sdhci: Present:   0x03f802f6 | Host ctl: 0x0000001e
[   76.014569] mmc0: sdhci: Power:     0x0000000d | Blk gap:  0x00000000
[   76.014577] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x00000007
[   76.014586] mmc0: sdhci: Timeout:   0x0000000a | Int stat: 0x00000000
[   76.014594] mmc0: sdhci: Int enab:  0x03ff100b | Sig enab: 0x03ff100b
[   76.014603] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[   76.014612] mmc0: sdhci: Caps:      0x3629c8b2 | Caps_1:   0x0000808f
[   76.014620] mmc0: sdhci: Cmd:       0x0000123a | Max curr: 0x00000000
[   76.014629] mmc0: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0x00000000
[   76.014637] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000900
[   76.014650] mmc0: sdhci: Host ctl2: 0x0000000b
[   76.014659] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x00000000edc9a20c
[   76.014822] mmc0: clk: 201500000 claimer: (null) pwr: 12
[   76.014824] mmc0: rpmstatus[pltfm](runtime-suspend:usage_count:disable_depth)(0:1:0)
[   76.014825] mmc0: sdhci: ============================================
[   76.017195] mmc0: data txfr (0x00200000) error: -84 after 0 ms
[   76.017206] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[   76.017215] mmc0: sdhci: Sys addr:  0x00000038 | Version:  0x00007202
[   76.017224] mmc0: sdhci: Blk size:  0x00000200 | Blk cnt:  0x00000035
[   76.017232] mmc0: sdhci: Argument:  0x00000840 | Trn mode: 0x0000003b
[   76.017243] mmc0: sdhci: Present:   0x030802f6 | Host ctl: 0x0000001e
[   76.017251] mmc0: sdhci: Power:     0x0000000d | Blk gap:  0x00000000
[   76.017259] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x00000007
[   76.017267] mmc0: sdhci: Timeout:   0x0000000a | Int stat: 0x00000000
[   76.017276] mmc0: sdhci: Int enab:  0x03ff100b | Sig enab: 0x03ff100b
[   76.017284] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
[   76.017292] mmc0: sdhci: Caps:      0x3629c8b2 | Caps_1:   0x0000808f
[   76.017302] mmc0: sdhci: Cmd:       0x0000123a | Max curr: 0x00000000
[   76.017310] mmc0: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0x00000000
[   76.017318] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000900
[   76.017326] mmc0: sdhci: Host ctl2: 0x0000000b
[   76.017333] mmc0: sdhci: ADMA Err:  0x00000003 | ADMA Ptr: 0x00000000edc9a224
[   76.017488] mmc0: clk: 201500000 claimer: (null) pwr: 12
[   76.017490] mmc0: rpmstatus[pltfm](runtime-suspend:usage_count:disable_depth)(0:1:0)
[   76.017491] mmc0: sdhci: ============================================
[   76.326540] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)

Test Output For SD Card Slot

voxl2:/$ sync && dd if=/dev/zero of=/media/sdcard/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.965705 s, 54.3 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sdcard/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.956928 s, 54.8 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sdcard/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.970479 s, 54.0 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sdcard/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.03216 s, 50.8 MB/s
voxl2:/$ 
voxl2:/$ sync && dd if=/dev/zero of=/media/sdcard/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.06114 s, 49.4 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sdcard/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.00951 s, 51.9 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sdcard/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.0044 s, 52.2 MB/s

Test Output For External SD Card Reader Over USB 3.0

voxl2:/$ sync && dd if=/dev/zero of=/media/gfr/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.593894 s, 88.3 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/gfr/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.576349 s, 91.0 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/gfr/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.597077 s, 87.8 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/gfr/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.548355 s, 95.6 MB/s
voxl2:/$ 
voxl2:/$ sync && dd if=/dev/zero of=/media/gfr/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.585704 s, 89.5 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/gfr/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.552729 s, 94.9 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/gfr/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.591907 s, 88.6 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/gfr/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.550808 s, 95.2 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/gfr/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.588921 s, 89.0 MB/s
voxl2:/$ 
voxl2:/$ sync && dd if=/dev/zero of=/media/gfr/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.559946 s, 93.6 MB/s

I am thinking the difference in speeds is hardware related, but I would like to hear others input.

SD Card Specs: SanDisk Extreme PRO 64GB microSD V30

Note: I also tried a different microsd card, a ProGRADE 128Gb MicroSD card which is V60 and UHS II, and that one would not get detected in the microsd card slot, despite the card reader I have detecting it. I think that might be due to it being a UHS II card

@John-Nomikos Edit: I swapped SD card readers (the original was UHS-I, this one is now UHS-II) and now am seeing 150-200 MB/s for both hats. Speed difference was likely caused by the card reader and not the voxl2. Still weird that there was a speed difference, but oh well

Good afternoon,

I am seeing about double the upload speed when uploading data on to an ext4 SD card when I use the VOXL 2 Ethernet and USB Hub Add-on versus the USB3 UART Add-On, with the exact same SD card and SD card reader. Both are over USB 3.0 JST.

I am wondering what could cause this difference? I looked at the diagram for the Ethernet and USB Hub Add-on and I see that it goes through the legacy connector, yet it has double the upload speed on average when compared to the USB3 UART Add-On.

The specific SD card I am using

Note: I am using a UHS-I SD card reader, but it supports USB-3.0

Here is my data:

ext4 using USB 3.0 hat (27.65 MB/s AVG)

voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 4.83333 s, 10.8 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.43407 s, 36.6 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 3.06638 s, 17.1 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.44299 s, 36.3 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.7253 s, 30.4 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.44141 s, 36.4 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 2.3068 s, 22.7 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.44809 s, 36.2 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.726 s, 30.4 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.83522 s, 28.6 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.75136 s, 29.9 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 3.17873 s, 16.5 MB/s

ext4 using Ethernet and USB Hub Add-on (57.66 MB/s AVG)

voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 4.19313 s, 12.5 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.768765 s, 68.2 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.70849 s, 30.7 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.779255 s, 67.3 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.76896 s, 68.2 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.769244 s, 68.2 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.775723 s, 67.6 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.793661 s, 66.1 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.775242 s, 67.6 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.803807 s, 65.2 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.40681 s, 37.3 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.78479 s, 66.8 MB/s

I also tested with exfat rather than ext4 using the exfat-fuse package (Note: This is significantly slower than ext4, likely due to the fact that exfat-fuse is not a kernel-level package and thus, that slows it down).
The difference was not as substantial.

exfat using USB 3.0 hat (11.80 MB/s AVG)

voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 2.94688 s, 17.8 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 2.96565 s, 17.7 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 3.46706 s, 15.1 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 4.2239 s, 12.4 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 4.86253 s, 10.8 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 4.56537 s, 11.5 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 4.7555 s, 11.0 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 7.02502 s, 7.5 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 7.07462 s, 7.4 MB/s
voxl2:/$ 
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 6.7923 s, 7.7 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 4.75127 s, 11.0 MB/s

exfat using Ethernet hat (14.65MB/s AVG)

voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 3.23971 s, 16.2 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 2.21505 s, 23.7 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 3.28938 s, 15.9 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 3.7585 s, 13.9 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 3.81527 s, 13.7 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 3.99802 s, 13.1 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 3.76004 s, 13.9 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 4.03387 s, 13.0 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 4.20047 s, 12.5 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 3.72385 s, 14.1 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 3.80692 s, 13.8 MB/s
voxl2:/$ sync && dd if=/dev/zero of=/media/sd/testfile bs=50M count=1 oflag=dsync && sync
1+0 records in
1+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 3.98186 s, 13.2 MB/s

@Alex-Kushleyev I tried on a fresh VOXL2 that I factory flashed with 1.3.3 and did not see the same issue. Was probably something caused by my setup (either in config or something else). I know that particular voxl2 had damage to one of the mipi ports too

I appreciate the help!

Good afternoon,

I discovered an issue that particularly happens when you do voxl-inspect-cam -a.

Upon inspecting all cams, latency jumps dramatically and continues to slowly rise. It seems to cap out right before 1000. The latency reading appears accurate because the video itself also becomes stuttery and delayed on voxl-portal.

Upon further investigation, latency also jumps when inspecting just the hires_large_color stream, or the hires_large_grey streams. But it jumps less than if you inspect all the cams at once.

hires_small_grey, hires_small_color, and hires_small_encoded do not appear to increase in latency upon inspecting them, except if a large stream is being inspected.

Video showing what I am seeing:
https://drive.google.com/file/d/12jBzO54E5ibzsq-t-Q96cDMkEHvysYME/view?usp=sharing

@Moderator Yep, I got routing through the VOXL2 working. The problem was actually in my host and the device I was pinging. I would have to setup static routing on both devices. But I ended up using a NAT on the VOXL2

Thank you for the help!

Good afternoon,

For the past few days, I have been running around in circles trying to make it so my computer with a microhard can ping a device connected to the voxl2 via Ethernet.

Essentially, I have a camera connected to the VOXL2 via Ethernet and the microhard is on usb0. This camera hosts it's own rtsp stream, and does not need to be streamed from the voxl2. From my host computer, I want to be able to connect to the camera connected to the voxl2 and directly ping it's IP. I know to do this, I need to have the VOXL2 route from usb0 to eth0 in some way to make it so when the GCS pings the camera's ip, it goes through the usb0 interface to eth0.

I am pretty new overall to networking, so please correct me if my idea is wrong.

bond0: flags=5123<UP,BROADCAST,MASTER,MULTICAST>  mtu 1500
        ether 0e:ae:7a:d3:cb:54  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        inet6 fe80::aee5:90ba:7fd5:a0ed  prefixlen 64  scopeid 0x20<link>
        ether f2:fa:36:1f:17:83  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 15670 (15.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.144.21  netmask 255.255.255.0  broadcast 192.168.144.255
        ether 5c:85:7e:3e:94:33  txqueuelen 1000  (Ethernet)
        RX packets 2577  bytes 154620 (154.6 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 83  bytes 21341 (21.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 95  bytes 8224 (8.2 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 95  bytes 8224 (8.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.168.100  netmask 255.255.255.0  broadcast 192.168.168.255
        inet6 fe80::3b33:ef4a:4410:1470  prefixlen 64  scopeid 0x20<link>
        ether 96:dc:72:9d:a5:01  txqueuelen 1000  (Ethernet)
        RX packets 5661  bytes 324594 (324.5 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3874  bytes 456769 (456.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The first thing I did was enable forwarding on the VOXL2 by uncommenting this line on /etc/sysctl.conf
net.ipv4.ip_forward=1

Then I tried pinging the device from my home computer while connected via microhard.

From my home computer:
I was able to ping 192.168.168.100, which is expected since that is the microhard.
I was able to ping 192.168.144.21 which is the eth0 interface.
However, I have been unable to ping 192.168.144.52, which is the address of the camera, despite being able to ping it successfully on the VOXL2.

john@john-desktop:~$ ping -R 192.168.168.100
PING 192.168.168.100 (192.168.168.100) 56(124) bytes of data.
64 bytes from 192.168.168.100: icmp_seq=1 ttl=64 time=3.06 ms
RR: 	192.168.168.146
	192.168.168.100
	192.168.168.100
	192.168.168.146

64 bytes from 192.168.168.100: icmp_seq=2 ttl=64 time=3.59 ms	(same route)
64 bytes from 192.168.168.100: icmp_seq=3 ttl=64 time=2.68 ms	(same route)
64 bytes from 192.168.168.100: icmp_seq=4 ttl=64 time=3.31 ms	(same route)
^C
--- 192.168.168.100 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.680/3.159/3.585/0.332 ms
john@john-desktop:~$ ping -R 192.168.144.21
PING 192.168.144.21 (192.168.144.21) 56(124) bytes of data.
64 bytes from 192.168.144.21: icmp_seq=1 ttl=64 time=3.14 ms
RR: 	192.168.168.150
	192.168.144.21
	192.168.144.21
	192.168.168.150

64 bytes from 192.168.144.21: icmp_seq=2 ttl=64 time=2.81 ms	(same route)
64 bytes from 192.168.144.21: icmp_seq=3 ttl=64 time=2.99 ms	(same route)
64 bytes from 192.168.144.21: icmp_seq=4 ttl=64 time=2.84 ms	(same route)
64 bytes from 192.168.144.21: icmp_seq=5 ttl=64 time=2.85 ms	(same route)
64 bytes from 192.168.144.21: icmp_seq=6 ttl=64 time=2.77 ms	(same route)
^C
--- 192.168.144.21 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5009ms
rtt min/avg/max/mdev = 2.771/2.900/3.137/0.126 ms

I've tried changing the routing table to allow for connections over usb0 that point to 192.168.144.52 to go over eth0, but I haven't had luck. I am unsure if there is something I'm doing wrong here.

Here is my routing table:

voxl2:/etc/modalai$ ip route
default via 192.168.168.1 dev usb0 src 192.168.168.106 metric 209 
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.208.31 metric 208 
192.168.144.0/24 dev eth0 proto kernel src 192.168.144.21 metric 202 
192.168.168.0/24 dev usb0 scope link src 192.168.168.100 

I've also tried this routing table to enforce that we should be routing pings to 192.168.144.52 to eth0 :

default via 192.168.168.1 dev usb0 src 192.168.168.106 metric 209 
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.208.31 metric 208 
192.168.144.0/24 dev eth0 proto kernel scope link src 192.168.144.21 
192.168.144.52 dev eth0 scope link src 192.168.168.100 
192.168.168.0/24 dev usb0 scope link src 192.168.168.100 

The outcome is the same when changing the routing table. However, I know that changing the routing table is doing SOMETHING because if I remove all eth0 entries, I cannot ping any eth0 device.

Am I thinking of this wrong? Is there anything I should try? Does the VOXL2 handle routing differently, or is there anything custom going on?

@Alex-Kushleyev I mean, since it is a static service, disabling it does not actually disable it. It appears to do nothing. Upon rebooting, adb still works

I was able to "disable adb" by simply changing the name of the adbd executable to .adbd

@Alex-Kushleyev Thank you for the advice.

Since adbd is a static service (the usb service depends on it), it cannot be disabled through a systemctl disable.

I am going to take a look at other methods to disable it.

@Moderator

Tried what that article suggested and did some research. I think adb encryption is not a feature on adb daemon for linux devices, and is only available on actual android devices. I could be wrong, but it appears that way. Could also be a feature on newer adb daemon.

Regardless, I think it might be possible for me to open up a USB port on an extension board for ssh. That way I could have password protected serial access while having adb disabled. Am I wrong in thinking this?

Good afternoon,

I was wondering if there was a built-in method to require the user to input a password or have a correct adb encryption key to ADB into the VOXL2.

I could not find documentation relating to this on ModalAI website, and a lot of advice online seems to be only applicable to android devices.

Is there an area on the VOXL2 where the adb server is hosted so I can tinker around with it? Or is the adb functionality baked into the firmware itself?

The goal is to make the system more secure by only allowing authorized users to adb in.

If there is no way to require a password for adb on the VOXL2, is there a way to disable adb?

I have been able to change the ssh password which is nice.

Thank you,

John Nomikos.

@Chase-Riley

Thank you so much, that forum post basically describes the exact same issues I was running into. Going to test it out soon and see if that fix works on my end.

Yeah we always used attenuators and/or had long range. And I've tested this with like 5 different doodle radios and they all gave the same results

Good afternoon,

In the last month, I have been integrating doodle radios onto the VOXL2. There is one problem that is always consistent. Whenever I connect to the VOXL2 with the doodle radio on SDK 1.0 or 1.1, the connection will fail to complete. It will start connecting, freeze in the middle, take like 10 extra seconds, and then give "Parameters failed to download" errors on QGC. Sometimes it will successfully connect, but it takes minutes, and after it does, MAVLink appears to be very "choppy". As an example, if I move the VOXL2 around, the compass indicator will show it moving, but it is super laggy.

On QGC when I go to application settings -> Mavlink, I observe that the messages sent and received constantly freeze every second. The loss rate is only around 3% though.

This issue does not appear on 0.9.5. This issue also does not appear on 1.0 or 1.1 if I switch from using voxl-mavlink-server to mavlink-router (well the download stopping on QGC after taking too long does not appear. But it still takes forever to load up on QGC using mavlink-router).

This issue appears to be specific to doodle radios. I do not see similar problems when using a Microhard or WIFI adapter.

Moreover, this problem happens regardless of the bitrate between the radios. I've observed 30-50 mbps bitrate between the radios with a stable video stream, and still connection issues.

I know this problem isn't related to the bitrate being too high, because I've successfully connected to the VOXL2 via ethernet with no issues.

I did not observe any errors on voxl-mavlink-server or voxl-vision-hub. I also have the default configuration settings with both, but have toyed around a bit to try to see if this is a configuration issue.

I have observed this issue both with and without an external flight controller. The consistent thing is the doodle radio being in the equation and MAVLink being "choppy". My instinct is that the doodle is causing the issues here, but I am not sure because 0.9.5 works well. It loads up super fast when I am on 0.9.5 and MAVLink does not appear choppy.

Here is my voxl-mavlink-server config on 0.9.5:

/**
 * voxl-mavlink-server Configuration File
 * UART fields are for APQ8096 VOXL1 or QRB5165 VOXL2 with external fc
 * UDP fields are for PX4 on SDSP on QRB5165 only
 * External FC field is for QRB5165 only. Set to true to enable UART
 * communication to an external flight controller, otherwise a UDP interface
 * will be started to talk to voxl-px4 on localhost which is the default behavior.
 *
 */
{
	"px4_uart_bus":	1,
	"px4_uart_baudrate":	921600,
	"udp_port_to_px4":	14556,
	"udp_port_from_px4":	14557,
	"external_fc":	false
}

Here is it on 1.1.0

/**
 * voxl-mavlink-server Configuration File
 *
 * primary_static_gcs_ip & secondary_static_gcs_ip
 *    These configure voxl-mavlink-server to automatically try to connect to
 *    up to two known static GCS units. Set to empty or NULL if you don't want
 *    to use this and you want the GCS to initialize the connection instead.
 *    Note the default IP for the primary link is 192.168.8.10 which is the
 *    first IP that VOXL DHCP serves when connecting in wifi softap mode.
 *
 *
 * Settings for running voxl-px4 on SLPI:
 * onboard_port_to_autopilot   - UDP port to send high-rate onboard data to SLPI
 * onboard_port_from_autopilot - UDP port to receive high-rate onboard data from SLPI
 * gcs_port_to_autopilot       - UDP port to send normal-rate gcs data to SLPI
 * gcs_port_from_autopilot     - UDP port to receive normal-rate gcs data from SLPI
 *
 * Settings for running an external autopilot connected via UART:
 * en_external_uart_ap       - set to true to enable an external flight controller
 * autopilot_uart_bus        - uart bus, default 1 for VOXL2 
 * autopilot_uart_baudrate   - default 921600
 * en_external_fc_timesync   - enable responding to timesync messages
 *                                   (enabled by default)
 * en_external_ap_heartbeat  - enable automatic sending of heartbeat
 * gcs_timeout_s - time without heartbeat to consider GCS disconnected
 *
 * udp_mtu - maximum transfer unit for UDP packets back to GCS. voxl-mavlink-server
 *           will bundle up backets for the GCS into a single UDP packet with 
 *           a maxium size of this. This saves network traffic drastically.
 *           Set to 0 to disable this feature and send one UDP packet per msg.
 *
 *
 * External FC field is for QRB5165 only. Set to true to enable UART
 * communication to an external flight controller, otherwise a UDP interface
 * will be started to talk to voxl-px4 on localhost which is the default behavior.
 * Select UART port 1 to go through the legacy B2B connector, that's the port exposed by the
 * M0125 and M0141 accessory boards. Use port 12 to go through the ESC port (J18).
 *
 */
{
	"primary_static_gcs_ip":	"192.168.8.10",
	"secondary_static_gcs_ip":	"192.168.8.11",
	"onboard_port_to_autopilot":	14556,
	"onboard_port_from_autopilot":	14557,
	"gcs_port_to_autopilot":	14558,
	"gcs_port_from_autopilot":	14559,
	"en_external_uart_ap":	false,
	"autopilot_uart_bus":	1,
	"autopilot_uart_baudrate":	921600,
	"en_external_ap_timesync":	1,
	"en_external_ap_heartbeat":	1,
	"udp_mtu":	4000,
	"gcs_timeout_s":	4.5
}

The annoying thing is that OCCASIONALLY, on SDK 1.0 and above, it connects fine on QGC without stalling. So it is really hard for me to tell if this is a radio problem or a VOXL2 problem. Moreover, I've observed this problem on every doodle I've worked on.

Good afternoon!

I was running into an odd issue where I could not successfully connect to an RTSP stream on sdk 1.0.0. It seems like it kept adding clients repeatedly and disconnecting them when I tried connecting. I tried this on both VLC and QGC and the output was the same:

Mar 02 13:05:33 m0054 voxl-streamer[1803]: A new client has connected to the RTSP server
Mar 02 13:05:33 m0054 voxl-streamer[1803]: A new client rtsp://192.168.168.193:45922(null) has connected
Mar 02 13:05:33 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 1Camera server Connected
Mar 02 13:05:37 m0054 voxl-streamer[1803]: A new client has connected to the RTSP server
Mar 02 13:05:37 m0054 voxl-streamer[1803]: A new client rtsp://192.168.168.193:45938(null) has connected
Mar 02 13:05:41 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 2A new client has connected to the RTSP server
Mar 02 13:05:41 m0054 voxl-streamer[1803]: A new client rtsp://192.168.168.193:44512(null) has connected
Mar 02 13:05:45 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 3A new client has connected to the RTSP server
Mar 02 13:05:45 m0054 voxl-streamer[1803]: A new client rtsp://192.168.168.193:44522(null) has connected
Mar 02 13:05:49 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 4A new client has connected to the RTSP server
Mar 02 13:05:49 m0054 voxl-streamer[1803]: A new client rtsp://192.168.168.193:44534(null) has connected
Mar 02 13:05:53 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 5A new client has connected to the RTSP server
Mar 02 13:05:53 m0054 voxl-streamer[1803]: A new client rtsp://192.168.168.193:43914(null) has connected
Mar 02 13:05:53 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 6An existing client has disconnected from the RTSP server
Mar 02 13:05:53 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 5An existing client has disconnected from the RTSP server
Mar 02 13:05:53 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 4An existing client has disconnected from the RTSP server
Mar 02 13:05:53 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 3An existing client has disconnected from the RTSP server
Mar 02 13:05:53 m0054 voxl-streamer[1803]: Value of data num rtsp_client: 2An existing client has disconnected from the RTSP server

I switched back to 0.9.5 and was able to successfully connect without running into this issue. Makes me suspect that some change in voxl-streamer might be causing this. Also, I did not copy the last line of this, but I remember client 1 also disconnected from RTSP server as well as the rest.

I don't know if it is expected to have multiple clients connect when trying to connect once.

Next week, I'm going to try flashing platform 1.0.0 again to see if I run into the same problem on a different VOXL2.

Any help would be much appreciated!

Best regards,

John Nomikos

Hello @Vinny

Seems like the issue was a mixture of both things. Because there were times when the microhard was 100% touching J5 and that was the issue, but our cables are also finnicky, and cause problems as well. The solution was to make sure the microhard was not touching J5, and to mess with the MCBL wire a bit.

Thank you for the help, I very much appreciate it.

John Nomikos.

@tom

Hi Tom,

It could very well be the issue. I am aware of that problem, and I have 3 separate of those cables that I was trying, but perhaps all of them could be faulty. What is interesting is the fact that this restarting only happens after I have the microhard add-on attached. It is strange that there are no restart loops without it attached at all.

Good afternoon,

Recently, I have been trying to get a microhard modem attached to our VOXL 2. I have the M0048 add-on that works on the VOXL 1. But there is an interesting issue when I plug it into the VOXL 2. The VOXL 2 will constantly reboot, and the modem will as well, which makes me unable to adb in or do anything. But, when I don't have the add-on attached, there are no issues. The interval that the VOXL 2 restarts is very regular, and there is a weird (but annoying) method I've discovered to get it to work. Sometimes, if you plug in the USB-C at the exact moment before the VOXL 2 restarts, it won't restart and you can adb in and stuff. But after I turn the VOXL 2 off and on again, the issue will come back.

I was thinking maybe this could be a hardware issue with the specific VOXL 2 that I have. So I tried it on a different VOXL 2. Same problem. Then I thought maybe it was the add-on. I tried multiple different microhard add-ons (all M0048) and the same thing happened. One of the add-ons had a microhard attached to it, another didn't. But the same thing happened.

As a note, the voxl-platform on the main VOXL 2 I use is 0.9, and the other one I tested it on was 1.3, so I don't think it's a problem with the platform.

Also, sometimes, it just randomly works and doesn't restart, but the problem comes back after a little bit.

As another note, there are no other components on this VOXL 2. It is just the board and the microhard.

I am wondering if the microhard board is supported on the VOXL 2. If not, are there any alternatives I can try to get microhard working on the board?

After doing some digging, I think this might be the same issue: https://forum.modalai.com/topic/1273/voxl2-resetting-microhard-usb-chip-after-disconnecting-all-downstream-devices?_=1673379539228

Thank you,

John Nomikos.