@groupo Our goal is to use the Starling MAX with 5G to build a coverage map of our CBRS network. So I am planning to write a small bash script to periodically do AT!NRINFO? and AT!GPSLOC? alongside a timestamp. Then in post processing we can use the data to construct a heat map to see the extent. Once I get things working the way I want, I can share the script here if it would be useful to you.

@tom There is also another anomaly: voxl-inspect-battery shows voltage and current, but charge is listed as 0%. Is there some service that needs to be restarted/configured, like voxl-px4, in order to get a reading of the battery charge?

I also ran px4-listener battery_status which also doesn't seem right. The cells that came with the Starling MAX I believe are 7.2V (two 2s in series, so 4 cells total).

voxl2:/$ px4-listener battery_status

TOPIC: battery_status
 battery_status
    timestamp: 1051478873 (0.067609 seconds ago)
    voltage_v: 5.76600
    voltage_filtered_v: 5.76056
    current_a: 1.00800
    current_filtered_a: 0.96054
    current_average_a: 3.40000
    discharged_mah: 299.21326
    remaining: 0.00000
    scale: 1.30000
    time_remaining_s: 0.00000
    temperature: nan
    voltage_cell_v: [0.00000, 0.00000, 0.00000, 0.00000, 0.00000, 0.00000, 0.00000, 0.00000, 0.00000, 0.00000, 0.00000, 0.00000, 0.00000, 0.00000]
    max_cell_voltage_delta: 0.00000
    custom_faults: 0
    average_power: 0.00000
    available_energy: 0.00000
    full_charge_capacity_wh: 0.00000
    remaining_capacity_wh: 0.00000
    design_capacity: 0.00000
    nominal_voltage: 0.00000
    capacity: 3950
    cycle_count: 0
    average_time_to_empty: 0
    serial_number: 0
    manufacture_date: 0
    state_of_health: 0
    max_error: 0
    interface_error: 0
    faults: 0
    average_time_to_full: 0
    over_discharge_count: 0
    connected: True
    cell_count: 4
    source: 0
    priority: 0
    id: 1
    is_powering_off: False
    is_required: False
    warning: 3
    mode: 0

Do I need to change the POWER_MANAGER in /etc/modalai/voxl-px4.conf from VOXLPM to NONE and restar the voxl-px4 service? The comments seem to indicate that we should be using NONE with the Mini-ESC 4 in1:

# POWER_MANAGER:
#     Tell PX4 which power manager to use.
#     Use NONE for ModalAI Mini-ESC since the ESC driver handles PM.
#     Use EXTERNAL when not using the ModalAI APM power manager to power the board
#       This also just disables the voxlpm driver, same as the NONE option
#     Options include: [VOXLPM, EXTERNAL, NONE]

@groupo To get a shell, you just do

busybox microcom /dev/ttyUSB0

Without the echo, it will just wait for your input and output the result after you type each command and hit enter. CTRL-X will return you to the voxl2 shell. i.e.:

voxl2:/$ busybox microcom /dev/ttyUSB0
AT!NRINFO?
!NRINFO:
Connectivity Mode: SA

NR5G Cell ID:    8001 (32769)
NR5G band:       n48       	        NR5G Carrier ID: 0
NR5G dl bw:      40 MHz    	        NR5G ul bw:      40 MHz
NR5G Tx Power:   ---        	        NR5G Tx chan:    0
NR5G Rx chan:    638856
NR5G dl MIMO:    4         	        NR5G ul MIMO:    1
NR5G(sub6) Rx0 RSSI (dBm):   -39.9	NR5G(sub6) Rx1 RSSI (dBm):   -44.8
NR5G(sub6) Rx2 RSSI (dBm):   ---  	NR5G(sub6) Rx3 RSSI (dBm):   ---

NR5G RSRP (dBm): -68		                NR5G RSRQ (dB):  -11
NR5G SINR (dB):  21.0


OK

I think the reason I wasn't getting output via echo, was because I forgot to send it the carriage return-line feed so it was still effectively 'waiting for me to press ENTER'.

voxl2:/$ echo -ne 'AT!NRINFO?\r\n' | busybox microcom -t 1000 /dev/ttyUSB0
AT!NRINFO?
!NRINFO:
Connectivity Mode: SA

NR5G Cell ID:    8001 (32769)
NR5G band:       n48       	        NR5G Carrier ID: 0
NR5G dl bw:      40 MHz    	        NR5G ul bw:      40 MHz
NR5G Tx Power:   ---        	        NR5G Tx chan:    0
NR5G Rx chan:    638856
NR5G dl MIMO:    4         	        NR5G ul MIMO:    1
NR5G(sub6) Rx0 RSSI (dBm):   -41.0	NR5G(sub6) Rx1 RSSI (dBm):   -53.4
NR5G(sub6) Rx2 RSSI (dBm):   ---  	NR5G(sub6) Rx3 RSSI (dBm):   ---

NR5G RSRP (dBm): -67		                NR5G RSRQ (dB):  -11
NR5G SINR (dB):  21.0


OK

Thanks @tom! That seems to have worked. After configuration, I ran voxl-esc spin and all 4 rotors spun up in turn. Just another quick question about the output.

Finished!
[4.992197] TX=504, RX=1000 packets, RX CRC ERRORS=0
Average RPMs: 0.00 0.00 0.00 1998.98
Average RPM deviation between ESCs : 1998.98
disabling bridge

Is this just a quirk in the way the average RPMs are reported or should I be concerned that 3 of the 4 have a 0 average? They definitely all spun up, and seemed to reach the same speed.

Hello,

We had to replace the power/ESC module on our Starling MAX and now we cannot arm the drone. voxl-esc scan seems to detect the ESC, but perhaps we are missing some configuration. There are a number of setup_ commands for voxl-esc, but it is not clear which applies to the Starling Max. How can we set up the new ESC?

Thanks,
Tom

@Thomas-Eiszler Rather than echoing commands, I just went into the microcom shell and interactively ran some commands. AT+COPS? took a long time, and then afterwards, other commands also seemed to work, so I think it was perhaps the -t flag that was causing it to exit prematurely. Or something with redirection of stdout/stderr...

@groupo Thanks for the tutorial! It didn't work the first time I echoed to new_id, but after I restarted the VOXL, the second time the kernel picked it up and created the ttyUSB0 device. Now I just need to figure out what command to use to get the signal strength. So far, most of the commands I have tried either yield no output or 'ERROR'. Progress by degrees...

voxl2:/$ echo -ne "AT+QENG=\"servingcell\"\r" | busybox microcom -t 1000 /dev/ttyUSB0
AT+QENG="servingcell"
ERROR
voxl2:/$ echo -ne 'AT!LTEINFO?' | busybox microcom -t 1000 /dev/ttyUSB0
AT!LTEINFO?voxl2:/$ echo -ne 'AT+COPS=?' | busybox microcom -t 1000 /dev/ttyUSB0
AT+COPS=?voxl2:/$
voxl2:/$ echo -ne 'AT!NRINFO?' | busybox microcom -t 1000 /dev/ttyUSB0
AT!NRINFO?voxl2:/$

@pthomason I, too, am trying to find a way to get the signal strength periodically to build a coverage map of our 5G CBRS deployment. It seems like qmicli can be used for this purpose, but it doesn't give me anything interesting when I query for the signal information:

voxl2:/$ qmicli -d /dev/cdc-wdm0 --device-open-proxy --nas-get-signal-info
[/dev/cdc-wdm0] Successfully got signal info

Has anyone successfully retrieved the signal information from voxl?

Update:

I also tried the following from another post, but the 5G Sierra Wireless modem is not on ttyUSB2, so I am not sure how to address it.

echo -ne "AT+QENG=\"servingcell\"\r" | busybox microcom -t 1000 /dev/ttyUSB2

lsusb shows it is on bus 002, device 003.

voxl2:/dev/bus/usb/002$ lsusb
Bus 002 Device 003: ID 1199:90e3 Sierra Wireless, Inc.