RFOXiA LogoRFOXiA Club
← Back to DevHub

MultiNav Pro+ sensors - humidity sensor response time during rapid env changes?

tod nickJune 15, 2026
Working on a weather balloon payload project and I'm using the MultiNav Pro+ sensors module alongside the GNSS module to log environmental data during ascent. Everything's working pretty well overall but I've got a question about the humidity sensor specifically. When the balloon climbs through different atmospheric layers the humidity can shift pretty drastically in a short window - we're talking going from like 60-something percent near the ground to near-zero in the upper troposphere over maybe 10-15 minutes. I'm wondering what the actual response time on that humidity sensor is, because I'm starting to suspect my readings are lagging behind reality and I might be capturing a smeared curve rather than what's actually happening at each altitude.
💬 5 replies👍 0 likes👁 0 views

💬 Want to join this discussion?

Join the Community on RFOXiA Club →

Replies

AdamJune 15, 2026
@tod nick yeah that suspicion is almost certainly correct — humidity sensors in general have a notoriously slow response time compared to temperature or pressure, and the effect gets significantly worse at low temperatures and low humidity levels, which is exactly the environment you're flying through in the upper troposphere.
 
I don't have the exact response time spec for the specific sensor on the Sensors Module in front of me right now, but most MEMS-based humidity sensors in this class (the module uses a combined environmental sensor package) have a t63 response somewhere in the 6-15 second range under ideal conditions — and that number can balloon (no pun intended) to 30+ seconds when you're dealing with sub-zero temps and the polymer sensing element gets sluggish. If your ascent rate is anywhere near a typical 5 m/s, you're covering 150-300 meters per sensor time constant, which absolutely produces that smeared curve you're describing.
 
A few things worth trying: one is to correlate your humidity data against your GPS altitude from the GNSS module and apply a simple first-order lag correction in post-processing — you know your ascent rate, so you can estimate the offset. The other thing I'd look at is whether there's any physical shielding on your payload housing that's trapping a microclimate around the sensor; even a loose enclosure can add several seconds of thermal/humidity lag on top of whatever the sensor itself contributes. If you can share your ascent rate and the altitude profile where you're seeing the most obvious lag, I might be able to help you sanity-check whether it matches a typical sensor response curve or if something else is going on.
Peter AdkinsJune 15, 2026
The humidity sensor on the MultiNav Pro+ has a response time of around 8 seconds for a 63% step change under normal conditions, but that can stretch out significantly in low pressure environments like you'll encounter above ~5km, so if you're logging at high frequency you'll basically see the sensor lagging behind reality during fast transitions. Honestly for balloon work I'd factor that into your data processing rather than trying to fight it in firmware - smooth it out in post with the pressure/altitude data you're already capturing from the GNSS module and you'll get a cleaner picture of what's actually happening.
Jessica ChanJune 15, 2026
Peter's point about post-processing is solid - we actually ran into the same lag issue on a high-altitude drone project and ended up applying a simple first-order correction using the known response time constant against our altitude rate of change, worked surprisingly well for cleaning up the transition zones. Might be worth logging your ascent rate from the GNSS at high resolution so you've got good data to work with when you go back through it.
Harold BrownJune 15, 2026
Both solid approaches - one thing I'd add is that the MultiNav Pro+ logs a sensor temperature reading alongside humidity which can help you flag those transition zones automatically in post, since you'll see a pretty sharp temp drop correlating with the humidity lag window, makes it easier to apply Jessica's correction only where you actually need it rather than across the whole dataset.
Curtis ElliottJune 15, 2026
Harold that's a really useful flag - I've been doing something similar on a soil sensor project where I use temp as a proxy for "trust this reading or don't" and it translates really cleanly to a simple validity mask in the dataset. Combining that with Jessica's rate-of-change correction should get you pretty close to actual atm conditions through those transition bands without having to throw out data entirely.

💬 Want to join this discussion?

Join the Community on RFOXiA Club →