Extended CLI Status Report

[Phil-MC]

Current Behavior

Desired Behavior

Add the current installed firmware name and user selected ESC protocol to the CLI status report.

Suggested Solution

Who does this impact? Who is this for?

All users and those who try to help them with their issues.

Additional context

This would make it much easier to diagnose problems when troubleshooting as it puts together the causes of common mistakes in one report which is easy for the inexperienced user to produce and submit on our forums.

[Phil-MC]

@DzikuVx What do you think? I have wasted time on a user problem searching for a cause only to find that the wrong ESC protocol has been chosen. There have been a few lately where a reminder in the often requested CLI STATUS REPORT would have led straight to a solution.

[b14ckyy]

Target Name is part of the Report already. ESC protocol might be a useful addition.

INAV/MATEKF405TE 7.1.0 Mar 19 2024 / 18:41:39 (3f3b1521)
GCC-10.3.1 20210824 (release)
System Uptime: 164440 seconds
Current Time: 2024-03-22T20:02:12.927+01:00
Voltage: 0.00V (0S battery - NOT PRESENT)
CPU Clock=168MHz, GYRO=ICM42605, ACC=ICM42605, BARO=SPL06, PITOT=VIRTUAL
STM32 system clocks:
  SYSCLK = 168 MHz
  HCLK   = 168 MHz
  PCLK1  = 42 MHz
  PCLK2  = 84 MHz
Sensor status: GYRO=OK, ACC=OK, MAG=NONE, BARO=OK, RANGEFINDER=NONE, OPFLOW=NONE, GPS=OK
Stack size: 6144, Stack address: 0x10010000, Heap available: 1596
I2C Errors: 0, config size: 10467, max available config: 131072
ADC channel usage:
   BATTERY : configured = ADC 1, used = ADC 1
      RSSI : configured = ADC 3, used = none
   CURRENT : configured = ADC 2, used = ADC 2
  AIRSPEED : configured = ADC 4, used = none
System load: 7, cycle time: 1007, PID rate: 993, RX rate: 194, System rate: 9
Arming disabled flags: NAV RX CLI
OSD: MAX7456 [30 x 16]
VTX: not detected
GPS: HW Version: UBLOX10 Proto: 34.09 Baud: 115200
  GNSS Capabilities:
    GNSS Provider active/default
    GPS 1/1
    Galileo 1/1
    BeiDou 0/1
    Glonass 0/1
    Max concurrent: 3

[Phil-MC]

Thanks @b14ckyy for taking a look at this, It has been on my back burner for a while, hence the FIRMWARE NAME.
The ESC is a major part of the system and more information here would be helpful.
I think the selected PROTOCOL would be the easiest. The installed ESC firmware would be a problem as it would need accessing from the ESC.

[b14ckyy]

The TARGET is the firmware name. Overall the target just defines what sensors are available and what pin on the processor does what. Not sure what else you mean with Firmware name.
The used ESC type is also not readable. Only the ESC target, if at all. But as there are many different ESC firmware types it will be hard to detect what firmware it is (BLHeli, BLHeli_S, BLHeli_32, BlueJay, .... etc etc. Most ESC firmwares also require a reboot after accessing the config (all the mentioned) so this would mess up a lot of things.

We can consider adding 1 or 2 more information in the Status report that could make sense but the rest would not be practical.

Will move this to Discussions for now.

[Phil-MC]

I was wondering if ESC information was available to the FC via its telemetry link.

[b14ckyy]

INAV does not support bidirectional dshot to give general feedback. DSHOT is otherwise a one way street only.
I am not sure though, what ESC telemetry sends back when wired up on compatible ESCs. But this is a rare edge case on most builds I think.

[Phil-MC]

Yes, I think you are right. Most users requesting assistance will not have connected the ESC to a UART. Therefore, it will not be worth the effort. On the other hand, I wonder how blheli tools accomplish it?

[b14ckyy]

BLHeli set the flight controller into a serial passthrough mode directly to the Signal outputs. The ESCs then switch into config modes to read data through a specific protocol. To switch themback into motor control mode they need to be rebooted (happens automatically when disconnecting the config tool)

[Phil-MC]

Thanks. That is what I have read. This would be a waste of FC resources. It would be better performed by the CONFIGURATOR and the firmware details copied to a suitable data area on the FC (OSD). This could then be accessed by the 'status' script.
This is one component of the system that currently is not covered by the CONFIGURATOR. It could appear for reference under the OUTPUTS TAB say.