Tagged: Thermocouple sporadic glitches
- August 1, 2016 at 1:16 am #10837AnonymousInactive
I tried to use the thermocouple feature to get my room temperature monitored. First it works fin, but after a few minutes it gets strange spikes . The spikes are also on the internal temperature. It can go down to minus 11 degrees C or up to 50 degree C. Sometimes the spikes happen every few seconds, sometimes every 10 to 20 seconds.
I’m using the newest build 1469410939 on a nexus 9 with the newest Android 6. The same happens on my Sony xperia Z3, also newest Android 6.
it looks like there is an internal reference disturbed, because not only the internal temperature changes, also the voltage from the Thermocouple signal.
- August 2, 2016 at 8:54 am #10848AnonymousGuest
I tried to humour myself last night and set mooshimeter log its internal temperature every second on both channels. Its possible, so it should not “break” anything?
There was crazy spikes at start, visible on normal meter screen, graph and now that i had time to check log-files, on there also. I stopped logging when i wake up and did not notice spiking anymore while seeing live values for a minute or so..
I did notice that both channels spiked at same time, but in different directions. In spreadsheet I first created graph of whole last night (almost 28000 lines of log) and somehow those spikes just disappeared in pretty much middle of that file. And ~2300 lines later, there is one similar spike and thats it, just normal ~298 deg K for rest of the night..
Then, as those spikes seemed identical, i tried to calculate channel difference (CH1-CH2) and that gave even stranger results.. Lines with reasonable values give about +/- 0.0025 degree range for difference, but spikes had three (suspiciously doubling) levels of difference: ~51-52, ~102-104 and ~208, with only one random ~91 degree result.
That big spikes are easily filtered from results, but it looks bad at first sight.. I thought there was few thousand of those, but as i checked those spike-levels, i had only 208 (of ~28K) lines after sorting.
Actually my biggest question right now is, what happened in a middle of a night, when errors just disappeared?
android-app: 1.0.29 (2071)
- August 3, 2016 at 4:30 am #10853AnonymousGuest
I see the same issue. I set my meter to log 2 AA batteries, 1s intervals. Very stable 3.812V except spikes at -3.4V. Always same negative spike, but not at repetitive intervals. Timestamps look ok. I think this was an issue several builds ago, but had been fixed. Filtering these spikes out could work for some situations, but if you are looking for some anomaly in the device being testing you may not be certain if it is the meter or the device being measured. Hope this is an easy one to fix.
– — – Duane
- August 21, 2016 at 1:56 pm #13863adminKeymaster
Thanks for this. I think I squashed this one a few weeks ago with release 1470628829.
- August 25, 2016 at 6:00 am #13906AnonymousInactive
I tried it, and it is nearly fixed.
A view days ago, I had to measure power consumption from a data logger and used this opportunity to play with the Mooshimeter.
All works fine, except when you set the sampling rate to 8000Hz. Then you will still find spikes. Same is, when you use thermocouples.
It looks like the root cause for this effect is independent from the actual measurement.
I uploaded you an ok and a nok SS.
In the measurement I did, was only one LED as load connected. I also crosschecked with a scope, and there were no spikes on the power supply.
Also it does not make much sense, that a LED jumps from +30 mA to a negative current.
You can download the SSs here:https://icsulrich.com:5001/sharing/9KV8gGiK6
By the way, my Nexus 9 tablet updated today to Android 7 and the Mooshimeter APP works without any incident.
- August 25, 2016 at 9:52 am #13907adminKeymaster
Thank you for the excellent data. I am considering removing the 8kHz sample rate from the available rates for two reasons:
1. The analog filters roll off around 1kHz, so sampling at 8kHz does not give you very much more information than sampling at 4kHz.
2. There is a sad interaction between the radio interrupts and the data ready interrupts that causes corrupt sample data when using 8kHz mode. I have not fully diagnosed this, but I remember seeing it crop up occasionally even in the very early days of development (2014).
Let me know if you have a strong opinion on this, thank you again!