- May 5, 2016 at 12:26 am #9639TimGuest
I am trying to get the best responsiveness to transient voltage signals out of the graph display. Currently it’s struggling to follow anything faster than about a 0.2hz sine wave in a way that still resembles a sine wave.
I have it set to the lowest sample rate and buffer: 125hz and 32 samples. I’m assuming the averaging of the sample buffer is a running average, not waiting 32 samples before each new average is calculated and displayed ?
But where is the bottleneck in the whole process that is limiting the responsiveness ?
Is the graph plotting every buffer, or just whatever it can manage to keep up with ?
Would it be possible to have a 1 sample buffer and slower sample rate (eg 10hz), plotted just whenever it can ? Would that reduce the processing burden while increasing the responsiveness ?
On Android Beta, Nexus 5, Android 6.0.1
- May 5, 2016 at 1:00 pm #9641
The averaging window is not a moving window, the Mooshimeter fills up the whole buffer, calculates the metrics (average or RMS), and sends the calculated value over the BLE link. So if you’re set to the default 125Hz, 32smpl, you’ll get a mean value roughly every .26 seconds.
If you want to increase this rate in the graph’s “trend mode”, you can increase the sampling frequency. I can’t say for sure how far this will get you though, because on many Android phones it’s the BLE that’s the bottleneck.
Another approach, depending on what you’re trying to measure, would be to keep the sample rate low (125Hz) and increase the buffer depth all the way to 256. Then use the graph in “buffer mode”, which will display one complete buffer at a time (256/125Hz = 2 seconds of data). You’ll miss a lot of data because the time to transmit the frame will dominate the sampling cycle, but if your signal is periodic it might give you the insight you’re looking for.
I hope this is helpful, please let me know how else I can help. Best
- May 8, 2016 at 11:43 pm #9669AnonymousGuest
Do you have feel for what input sample rate could be pushed over BLE ? I have played with Measurement Computing’s example Android apps for their Bluetooth ADC box that we own, and frequency response is not too bad. But we’re looking at portable/wearable applications and their box is quite big.
I guess to some extent I am trying to get your device to do something it wasn’t designed to do – I know it’s a multimeter not an oscilloscope ! But the presence of the graph makes me think ‘oscilloscope’. ;)
Is it at all possible that you could implement lower sample rates (eg 10hz) on the meter side and a 1-sample buffer (ie actually no longer a ‘buffer’), so basically data was then being sent over BLE every 0.1 sec, or whatever it can handle ? And the app just plots whatever it receives and can keep up with ?
- May 10, 2016 at 2:05 pm #9686
You should be able to increase the update rate of the graph by adjusting the sample rate. If you want about 10 samples/second sent to the phone, you could set the meter to use a 32 sample buffer and sample at 250Hz. This would give you about 8 samples per second over the air. Does that do what you want it to?
I haven’t used the Measurement Computing example. If you have a video reference I would happily take a look.
- June 23, 2016 at 8:45 pm #10351AnonymousGuest
The MCC example app for their Bluetooth ADC you asked about is here:
The example shows sampling 2 channels at 500hz without buffering, with good following of ‘higher’ frequency signals.
Your latest app/firmware seems a little more responsive than before, but still not quite enough for what we need.
Would the solution to greater responsiveness be simply adding the option for a 1-sample ‘buffer’ (plus some lower sample rate options to avoid sampling more data than is necessary at that low-ish end) ?
BTW how do I now turn off the current graph when I only want to see voltage ? Could the graph also retain its user settings, rather than reverting to defaults each time you go back to the main screen to tweak something ?
- June 24, 2016 at 2:01 am #10361
Thanks for the video. A big reason why they are able to get data across the link faster is that the BTH1208-LS is a Classic Bluetooth device, which the Mooshimeter is a Bluetooth Low Energy device. Classic has much higher data rate and can get more across the link. That’s the bottleneck on the Mooshimeter. And due to a weird caveat with Android, the effective datarate is actually highly dependent on the make/model/Android version of the smartphone you’re using (I’ve mentioned in other places that Android BLE is a mess, but if I haven’t said it here yet… Android BLE is a mess). If you can try a different phone, please do. iOS’s BLE datarate is also higher than most Android phones. Unfortunately I have not used a Nexus running 6.1 so I am not sure where your baseline is.
If you’re interested in why, it’s because all the different Android phones have different BLE “connection intervals” – basically how often it will wake up to exchange data with the Mooshimeter. It can vary from 7.5ms (on some LG smartphones) to 50ms (on some Samsung devices), and the amount of data you can get across the link is inversely proportional to the connection interval. So that’s a factor of 8 spread there. Hopefully your Nexus is nearer the 7.5ms side.
I was considering making buffer depths of 1, 2, 4, available again but they don’t offer much benefit since the bottleneck is not processing, it’s comms. You can set a 32 sample buffer and raise the sample rate to 4000Hz, that would be equivalent to 1 sample at 125Hz. But I think it’s your link that’s saturating.
Sorry I don’t have a magic bullet, I hope some of this is helpful though. Let me know if you have other questions. Best
- This topic has 0 replies, 1 voice, and was last updated 6 years, 1 month ago by .
Viewing 5 reply threads
Viewing 5 reply threads