Does this mean that the sensor can only gather 1 sample/sec? If not, do I need to multiply the given current by the amount of samples per second, in order to calculate the current draw for a higher sampling rate?
Also, my understanding of the OSR is that it is higher than the sampling rate. If an OSR of, for example, 256 is used, should the supply current given on the datasheet for the condition of 1 sample/sec be multiplied by 256 or does it only count as 1 sample?
Finally, how can I determine the maximum sampling rate of the Bar30?
I expect that’s primarily so that the numbers are comparable. Oversampling adds extra resolution to a single output measurement, but at the cost of both time and energy. Fixing the number of output measurements and the time period makes it easier to compare just the energy difference (seemingly with an averaged current in this case).
Note that the peak supply current (same table) is 1.25mA, which occurs while actually sampling, and the standby current (the rest of the time) is typically 0.01uA. With an oversampling rate (OSR) of 8192, the “supply current” over 1 second is given as ~20.09uA. Taking the typical 8192 OSR conversion time from the next table, and noting that for 1 sample per second t_{idle} = 1\text{s} - t_c,
No, the sensor can take measurements whenever it’s not communicating. Lower resolution measurements take less time, but sending more measurements requires more communication.
If you’re interested in more precise timing information you can either try getting samples as fast as you can and measuring the output rate, or use the i2c clock speed (commonly 100kHz) to calculate how much time will be spent communicating throughout each conversion sequence (page 9), and assume the rest of the time is spent taking samples. That doesn’t account for calculation time in the main computer, but it may be possible to do that while the next measurement is being taken by the sensor (especially for the larger OSRs).
We are also using the Bar30 pressure sensor with the Navigator setup in our robots and was wondering if there is a way to find out what the actual sampling rate of the sensor is. We use the pressure sensor coupled with the IMU data for positioning of the robot, so it would be very useful for us to know how often we are able to get a reading from the pressure sensor. Currently we update the value from the pressure sensor at 10 Hz in our code, but ideally we would like to increase this frequency by a factor of 2-5. This would really only be useful if the pressure sensor is actually able to deliver readings at this rate. Does this seem reasonable?
Presumably that means that you can request SCALED_PRESSURE2 messages at up to 50Hz and get meaningful data from each one, but the VFR_HUD messages will likely only show changing altitudes at up to 10Hz. If you want to go beyond that I expect you’ll need to modify the relevant rate schedule and recompile ArduSub.
