I have been trying to interface flex sensor with raspberry pi pico. I am using thonny IDE. For time being I’m using inbuilt ADC of pico but output isn’t stable. I read that flex sensor needs to be calibrated each time we connect it. If we are using it with arduino we have function called “map()” in arduino IDE but in thonny how do I calibrate flex sensor?
There is a discussion here that gives you the equivalent of the map() functiion from the Arduino core in several different languages, including python.
Thanks I’ll check that out
That’s interesting, when you say that the output isn’t stable, is that the reading that you’re getting back from the ADC via Serial or the actual output of the sensor? I’m a huge fan of data filtering, so if it’s just a noisy sensor I’ll see what I can do to help out with setting up some filters on your Pico to get clean data back.
Re instability. Has anybody ever considered the situation where what a sensor (of any flavour) is seeing is not stable and maybe the sensor is telling the truth. Randomly throwing filters at “unstable” situations could sometimes be likened to shooting yourself in the foot.
I mention this possibility as although I have only been involved with this Forum a relatively short time I have NEVER seen the situation where anyone has considered the above scenario. Sometimes it is best to track a problem down to its source and get rid of it there instead of trying to brush it under the carpet with filters. Also if you try to filter Data signals too much you will end up with sine waves which may or may not work.
Also a little tip. If a filter is required you should only have one on any wire. If you for instance have a filter at each end these will, in association with the wire inductance, form a tuned circuit with its own set of problems.
I’m pretty sure Bryce prefers data filtering in the digital realm, so that’s probably what he’s referring to there. Good tips nonetheless, and short of rejecting stray values (i.e. if a digital sensor fails a checksum or the like), fixing the underlying issue is always a great idea.
Hi James. Not quite sure what you mean by that. I will have to try and find out. Being basically an analog person I regard filters in 3 main types, High pass, Low pass and band pass or combinations. What I was trying to get at is if a digital stream is bouncing around and becomes unusable there will be a cause and it will be better to fix that instead of trying (usually unsuccessfully) to “smooth” it out. If external interference is the problem one should either remove/reduce it or screen your cables /equipment or whatever but attempting to “filter” it off a data stream is usually not very successful. Something like this may work on the odd occasion.
The only idea really.
Another thing that does not get much of a mention is measurement technique. Know the limitations of the instrument in use. Even the common DMM. some think this is the be all to end all. Sometimes it is but quite often the opposite is true. The effect of the 10MΩ input impedance has to be considered when dealing with circuits that involved resistances over about 100kΩ or more. Experiment: use a DMM to measure a 5V supply. It should measure 5V. Now insert a 10MΩ resistor in series and measure at the end of this. It will measure 2.5V. The 10MΩ of the meter has become the “bottom leg” of a voltage divider. The same thing happens when measuring voltages across any resistor of a higher value. The 10MΩ must be considered in parallel with the resistor being measured. Current measurement can be worse. The “voltage burden” on the mA ranges and lower can be quite high and upset the circuit under test resulting in erroneous readings. The 10A range should be used where possible and usually gives a reasonable resolution for most purposes.
The length and positioning of the earth clip on an oscilloscope lead can have some interesting effects where problems like ringing etc seen on screen have actually been introduced by the measurement technique used.
Ah, the penny drops. “Data filtering”, use it all the time. Especially when searching places like Element 14 for particular class of component. There is a fairly simple explanation here https://www.techopedia.com/definition/26202/data-filtering
I don’t think that would be much help with instability or unreliability though.
You’re exactly right, it depends on whether by stability that means noise, or whether the system is having intermittent issues causing dropouts or similar. What I was suggesting was that if the sensor is producing output data that occasionally becomes inaccurate (the flex sensors are usually good within a 2.5 degree margin either way), on your Pico you can write a script to recognize the inaccuracy (potentially flagging the raw data in a log so that it can be identified later) and present a more stable output which can then be used by other parts of the script. A very simple example of this is a Kalman filter, essentially a running average producing a less noisy estimation. There’s a fairly extensive wiki on it:
That being said, it’s fairly easy to write custom scripts to clamp or otherwise filter the data which is output from the flex sensor or generic sensor based on what the noise looks like (assuming that it is in fact noise and not some kind of continuity issue or other problem with the setup).
Thanks for that. I was aware of the averaging technique for measurement to get a stable outcome. Any involvement by myself has mainly been measurement. Some high end test equipment has a function built in where values are measured over a number of repetitions or time (usually controllable) and an average used for display. I wasn’t sure what the system was called until now. The nitty gritty as in that wiki well above my pay rate and boiled down to be aware of it but don’t have to worry about the fine details. Just know what it does. It really comes down to
which I mentioned earlier.
The writing of software to do all this I will leave to you guys as I am no where near that level in this realm. Nor at my age (85) am I likely to get there. I will leave this sort of thing to you young guys.
I don’t think averaging in measurement meters is super new. A common example is the moving coil meter. Here the extent of averaging would depend on the ballistics of the meter. A good example is the analog VU meter as used in Audio applications. Here the ballistics are tightly defined and a spec laid down. The simple bar graph types don’t go close. I think some of the high end (read expensive) professional types closely emulate what a VU meter is supposed to display.
Another example would be the analog oscilloscope where the screen and eye persistence tend to average small variations showing up as a thickening of the trace. A digital scope is similar in that the instantaneous measurement can be done with a single sweep but if sweeps are stacked up over a period small variations will also show up by once again a thickening of the displayed trace.
Anyway thanks for clearing up what you meant by “filter”. I think you possibly meant “digital” or “software” filtering as it seems “data” filtering has another meaning as well and is something I seem to do most days (see above).
No worries, I agree data-filtering is a misnomer, approximation in software is likely the best way to describe what I was thinking may be suitable for this project.
If possible Sakshi, can you send through your code that you’re using to measure the sensor and some sample output that you’re getting from it? We’ll take a look at it and see whether there’s any bugs or functions that can be improved/added to help get some more precise data back from your flex sensor if that is the issue.