Hi, the crux of the problem is this
When you connect Pixhawk 2.4.8 to a computer in QGround control, everything works (ready for flight, engines start) when you disconnect Pixhawk 2.4.8 from the computer, it starts flashing red and when you turn on the stick in the ARM, it emits a beep while continuing to flash red. What could be the problem, where to dig Thanks!
My guess is that complains that it has no connection to a ground station. We usually recommend to have some sort of connection, at least something like a SiK telemetry radio to the ground station.
Are you using PX4 or ArduPilot? For ArduPilot head over to discuss.ardupilot.org.
For PX4, you can get a log from boot that will tell us more. Just set SDLOG_MODE to “from boot”, then upload the log to logs.px4.io and share it here.
I got three of them
1 - https://logs.px4.io/plot_app?log=fce482b0-42b2-4ad3-b867-bfe94b71cc81
2 - https://logs.px4.io/plot_app?log=929c61a9-29ad-4cb6-a16d-91dbfdb49dd8
3 - https://logs.px4.io/plot_app?log=1893c95b-d749-4dc5-8f72-51083520e9ed
I cleaned the logs, set the parameter, and after rebooting (connecting/disconnecting from the PC) in three files
1
2
not sure 
3
Not sure why that happens. I would probably try a more recent PX4 version like 1.15.4 or 1.16.0.
1 Like
I was installing a new version, and another story begins. An additional problem, after updating version 1.16 (PIX 2.4.8 FMU-v2), is that “the RAM usage is too high - 96.5” Can you tell me how to solve this?
And maybe there is an instruction where all the items in the parameters are described, I find only a minimal list. Thank you.
It sounds like PX4 1.16 hasn’t really been tested on smaller STM32F4 and RAM usage is too high. Generally, PX4 developers are using boards with STM32H7 these days to avoid these troubles.
That being said, can you share the output of top in the MAVLink console, if you are even able to start it…
What airframe are you using?
1 Like
Hello, MAVLink console readings
PID COMMAND CPU(ms) CPU(%) USED/STACK PRIO(BASE) STATE FD0 Idle Task 32632 13.832 272/ 768 0 ( 0) READY 31
hpwork 0 0.000 284/ 1224 249 (249) w:sem 32
lpwork 0 0.000 284/ 1576 50 ( 50) w:sem 33
nsh_main 0 0.000 2348/ 3144 100 (100) w:sem 34
wq:manager 0 0.000 636/ 1232 255 (255) w:sem 45
wq:lp_default 1225 0.666 1068/ 1896 205 (205) w:sem 4406
wq:rate_ctrl 30246 16.508 2316/ 3120 255 (255) w:sem 4335
wq:hp_default 2970 1.630 1100/ 2776 237 (237) w:sem 4359
dataman 5 0.003 852/ 1376 90 ( 90) w:sem 5377
wq:I2C1 1170 0.638 872/ 2312 246 (246) w:sem 41598
mavlink_rcv_if1 989 0.542 1732/ 4776 175 (175) w:sem 7410
wq:I2C2 280 0.152 700/ 2312 245 (245) w:sem 4424
wq:SPI1 30410 16.553 1500/ 2368 253 (253) w:sem 4622
wq:nav_and_controllers 9382 5.075 1244/ 2216 242 (242) w:sem 4635
wq:INS0 35543 19.099 3644/ 5976 241 (241) w:sem 4637
commander 2654 1.421 1652/ 3192 140 (140) w:sig 51421
septentrio 2242 1.440 908/ 1936 205 (205) READY 41489
mavlink_if0 4544 2.470 1932/ 2704 100 (100) w:sig 51490
mavlink_rcv_if0 954 0.526 1324/ 4776 175 (175) w:sem 51525
navigator 467 0.253 1740/ 2104 105 (105) w:sem 111578
logger 6746 3.669 3412/ 3616 230 (230) w:sem 41580
log_writer_file 1222 0.622 644/ 1144 60 ( 60) w:sem 41596
mavlink_if1 18598 10.060 1980/ 2792 100 (100) READY 71599
mavlink_shell 0 0.000 1012/ 2000 100 (100) w:sem 31606
top 4061 2.207 3060/ 4056 237 (237) RUN 3
Processes: 25 total, 4 running, 21 sleepingCPU usage: 83.54% tasks, 2.63% sched, 13.83% idleDMA Memory: 5120 total, 1536 used 1536 peakUptime: 216.705s total, 32.633s idle
When turned on, it produced more lines
nsh: sysinit: fopen failed: No such file or directory
NuttShell (NSH) NuttX-11.0.0
nsh> top
I use Quadrotor X (S500 Generic) airframe
Ok, I mean as long as it stays below 100%, you might be ok anyway. It does work, doesn’t it?
But once you need more drivers or functionality (such as VTOL) you likely would have to upgrade to an F7 or H7 based autopilot.
1 Like
Thanks for the help, I will try
The reason was found - when connecting the telemetry, I saw the message “Avionics power low” (4.6-4.8 V) although it outputs stable 5.1 V on the connector, disabling the CBRK_SUPPLY_CHK parameter is running successfully, it remains to find the cause