This logs with frsky sbus and sport telemetry connected to serial1 and notch_opt - 0. i’m now not using crsf or elrs. F7 have 216mhz f4 have 168mhz - this differnces in rc loading. 5ms - for sbus i’m think normal or?
Idle - dont know why this… But i’m only see that DMA breaks GPS stability…
Why rcin loading cpu ? maybe more priority?
The big difference between F4 and F7 is not the clock speed but rather M4 vs M7 architecture
well, not the point.
Might just turn off these warnings 
Please say where in code writing to log about GPA delta - I want to trace the full path - and try to figure out the reason in instability GPA delta.
And I can say that lately, when using crossfire, I began to receive a failsafe without causation - perhaps this is somehow related and saw such entries on the forum…
I am investigating the CRSF failsafe as I have a reproducer here. The GPA delta is because of the GPS jitter correction code - no idea where the code is.
Ok - i’m find where.
Jitter maybe present in rcin - and some time we have failsafe.
I’m test GPS_DRV_OPTIONS - and this not working - baud always == 234000
I’m partial fix this when change gps_rate_ms to 100ms
Now spikes from 100 to 170ms from logs, but jitter detector using 215ms as max value - now AP silent but spikes present!
I’m think this need attention from devs…
@Evgen_Stenkin can you try my branch to see if that helps:
this doesn’t fix the jitter issues but does fix DMA contention on F4s and issues with CRSF frame timeouts.
@Derek The log shows that the crystal on this board sets a new record for poor calibration. The system clock is off by 6631 parts per million. That is why we’re getting those delta corrections.
It would be good to know if this affects all MambaF405v2 boards or if you just got a bad one.
1 Like
Thanks, when i’m have time i’m test. crsf.
Where from log i’m can see this? i’m have other f405 fc - i’m try test.
With 10hz settings i’m have 10sec between spikes - corrections makes only after some time (10 sec) ? i’m think if we have different time we reading data from gps at some not 200ms range - but each reading and not after 10s or im wrong?
No other fc have problem too, but i’m save logs without any recievers - and i’m think with using recievers spikes there will be much more…
This is the graph that shows it most clearly:
it shows the difference between the system clock for each GPS sample, and the difference in the GPS timestamp.
If you look at the start and end of the logs GPS messages you’ll see that the system clock (in GPS.TimeUS) advances consistently faster than the GPS timestamps (in GPS.GMS).
The difference is about 0.8%, which is much larger than should be possible with a crystal.
To get this data you just need a bin log for a sufficient period of time with GPS lock. As this board has such a large error just a few minutes is enough to measure it.
Cheers, Tridge
Ok. But no one guarantees 100% accuracy with xtal - xtal always have some difference. this should not affect the operation of the software - we do not follow the time, but the difference when receiving packets from the gps module - which should not jump by 140ms.
Moreover, the STM has a real-time clock - which can be calibrated, but again - is this the problem? are there any logs from other controllers with an ideal crystal?
Moreover, sometimes when I connect to a computer, I see a lot of these errors - this is clearly due to the fact that some thread interrupts the work of another - and this is due to incorrect operation or setting of the thread handler, incorrect priorities, too long operation of one of the threads … Where is it possible to see what time the maximum or average time each task takes and why turning on dma worsens the situation and I see these messages more often than without dma - time has nothing to do with it?
All this requires attention and I think the crystal has nothing to do with it.
Above I put statistics on tasks
AP_GPS::update MIN= 12 MAX=564 AVG= 64 OVR= 12 SLP= 0, TOT= 1.0%
And MAX - how can it be 564us if from code i’m see that for this task - 200us max?
/*
scheduler table for fast CPUs - all regular tasks apart from the fast_loop()
should be listed here, along with how often they should be called (in hz)
and the maximum time they are expected to take (in microseconds)
*/
const AP_Scheduler::Task Copter::scheduler_tasks[] = {
SCHED_TASK(rc_loop, 100, 130),
SCHED_TASK(throttle_loop, 50, 75),
SCHED_TASK_CLASS(AP_GPS, &copter.gps, update, 50, 200),
The schedule is the budget, but it does not prevent tasks from taking longer.
Dear all,
another 30 minute testflight. As 5 days before i could not reproduce the error. It seems the instability of the VCC feeding is at least one major problem. Here is the log until the buffer was filled:
https://drive.google.com/file/d/18Tnq_42w4-go0Xts599bGc41F0s3swwN/view?usp=sharing
@rmackay9: As mentioned by @Evgen_Stenkin the GPS_DRV_OPTIONS is not working - the baud rate is always == 234000
@Evgen_Stenkin: If you power the FC with the VCC coming from the ESC, there are strong interference with the ESC. VCC coming from the ESC is not stable, thus 5v and 9v on the FC is not stable.
The rest of the setup: R9Slim receiver, 9" props, 2212 motors, 4s 5500mAh battery, BN880, 10" FPV frame
No - i’m power from 5v BEC from FC. And i’m cant have any reinitialization problems - only contionous GPS health warnings…
Hi, I’m not sure that’s the right place to post but this is the only topic I have found that match my problem.
I’ve got the gpa.delta spike with the unhealthy warning on a F765-WING board with plane4.1beta5 and expressLRS (CRSF).
I can help you with testing if you need me to.
Have a nice day.
Nico
Could you re-try with the latest Plane beta? It’s got this fix which I think might resolve it
- increase CRSF frame timeout to cope with scheduling delays
I’m have crutch for fixing this AP issue - i’m change rate_ms in AP to 190ms - and warning go gout and gpa delta stay in good time!
Yes maybe this board have bad xtal and messages from gps have different time with cpu - but this should not affect the operation of the software, as data from gps come without interruptions and errors. The request of the developers to take into account this moment and fix this strange issue - ignore the time difference for this error!!