Attendees max: 12
UTC0702
- Issues with MACOS builds.
- Ignoring for now.
- Forgot to backport #27736.
- This doesn’t seem right. But it has gone in master, though, so in it goes.
UTC0712
- Andrew: With this, what prevents successive writes to conflict?
- Andy: This happens already with NEOPIXELs.
- A: We should still do this per group, and also ensure the correct dead-time.
- Probably by changing
push_local. - Likely it’s harmless, but it highlights that there might be another bug lurking.
- Approved.
- Probably by changing
UTC0724
- Andrew: A bit scheptical of the optimizaiton in minimum task delay.
- Relevant to a bug introduced by #27029, being one loop behind.
- Andy: It’s not a bug, it’s how locking semantics work.
- A: Still concerned about the repercussions of reducing the min task delay on the other threads.
- Andy: I think 100us is too large, and we can still reduce it, but find a value >0 that makes us both happy.
- A: I don’t see how 100us is making a difference? We don’t sample at 10kHz.
- Andy: And yet it’s necessary. How do I show it’s making a difference?
- A: I would still like to understand why going lower than 100us is necessary. We don’t know how close your system to its CPU limit.
- Sid: Buffering those samples and batch sampling could help a lot with saving processing time.
- A: These loop rate changes should go under an ifdef, they’re quite dangerous.
- Sid: If we merge sensor accessing and value usage in the same thread, the loop rate changes would be much more concentrated, and easy to put under an ifdef.
- Andy: That wouldn’t necessarily be simpler.
- A: I don’t like this very much either, because of its structural approach.
UTC0751
- Andrew: This is a difficult PR. We need to have a separate call about this.
- Andy: I’m surprized even these small PRs are so difficult to bring in. I need some direction.
- A: We don’t bring in PRs that don’t change anything but use up space.
- Peter: But Andy needs these stepping stones to bring in the larger loop rate PR.
- I don’t know. Andrew is better equipped to propose a way forward.
- Randy: I think it’s easier if this feature is always enabled. It makes testing simpler. At least as an expectation, a final goal.
- Andy: How about we wait for 4.6 beta to be over?
- A: That would be better, yes. If the feature was behind ifdefs, I wouldn’t worry.
- Michelle: Putting it in master after 4.6 would allow just the more risky/small quads users to test this, without endangering other users.
UTC0823
- Sid: We’re trying to make a bare-bones GPS board.
- We want to drive ProfiLEDs with that.
- A: What is the clock running at? I’m surprized there are no delays here.
- S: The LED still works, at tens of MHz of successive writes.
- A: It might not work in a Pixhawk6X, since it’s a lot faster.
- S: I’ve tested it in a very fast processor, still works.
- A: This is the 2nd specialized request for IOMCU. Our flash space is still sufficient.
- But RAM might be an issue. We have around 600B left, a bit low.
- The safety function still needs to work always. Option=3 prevents software-defined functionality.
UTC0844
- A: Not sure why some tests fail.
- Not understanding why origin altitude shifts continuously.
- The backend origin shifts, but the one exposed in the frontend doesn’t.
- Logging the internal origin altitude would help track down these shifts.
- Peter: I’m sceptical for getting this into 4.6.
UTC0859
- A: Note sure this is totally safe.
- P: We could make it a Q_OPTION.
- A: We probably need a Q_OPTION2.
UTC0906
- A: Looks reasonable. Approved.
UTC0908
- A: The absolute pressure readings can be very off, depending on proble placement.
- P: We could support the absolute in a separate PR.
- Can we create a dual-use sensor backend definition?
- A: Perhaps we could even open the sensor twice. Makes the structure easy.
- If that’s not possible we might need to create a dual-use sensor.
- Needs some tidying up anyways.
UTC0917
- George: How about the currently default value of TKOFF_THR_MIN?
- A: Yes, that can be an issue.
- We can override the default for quadplanes.
- Or perhaps better set to cruise.