I’m not sure where this problem is so please bear with me. I am fairly new to electronics but not software so i tend to think this is an electronics problem.
I am doing a thermostat modeled after the nest project Spark did for the hackathon. My problem is that the variable resistor I am using is a small thumbwheel type from radio Shack 10K Ohms, linear taper. (Not the large audio style the original used. This is used to choose the setpoint. The setpoint can also be set by a variable so it is important that the pot be stable because if it detects a large enough change, it overrides the variable setting. I originally did it with a Core and and used the Cores pin that put out a regulated 3.3V. The photon does not have this pin so I am using the regular 3.3v. The Core seemed to behave just fine, but when I changed to the Photon, the setpoint shows momentary glitches where the setpoint display changes for a split second. This is enough to stop the set by variable feature.
I can only assume that something is causing a voltage fluctuation big enough to make the system think that someone is messing with the dial. I don’t have a way to measure a continuous plot of the voltage but I just did a count of how often the display changes to a different number momentarily, I got about 24 times in 60 seconds. I read the Pot as often as the loop can, but I update the temperature reading 1/second, and update the weather and plot data every 15 minutes. I see bursts of changes usually not faster than 1/second but I can go several seconds without a problem.
One other departure I use from the Spark design is I use an ILI9340 LCD Display which uses hardware SPI.
What kinds of things should I be looking at to see where the problem could lie?
You could be seeing ripple from the WiFi module and/or OLED display…
you can try to decouple the OLED with a capacitor, are you using one there?
try putting into SYSTEM_MODE(MANUAL); and see if you still see spikes, printing the value serially at the same frequency that you are posting data.
Thanks for the suggestion it makes some sense to me, but as an electronics noob could I ask what type and range might be appropriate? I did learn about a capacitor’s role in communication when I was hooking up the HIH series temperature sensor. Would I put this inline on the breadboard connection of power from the Photon to the display?
I ran it in manual mode and sure enough I don’t see the jittery behavior. I’m a bit confused that cutting off the WiFi cured so many problems, I thought I was only using the net every 15 minutes or so. Would having exposed variables that are updated every second but not read more than every 15 minutes cause traffic anyway? I am still not sure how to determine where and how big the capacitors should be but I thank you that I now know which path Grasshopper must take to obtain electronic enlightenment.
So, how are you powering your Particle device?
A 5V USB transformer 550mA. I had tried it with a 1000mA but results were the same. I also had tried running the display directly from the 5V without going through the spark for power. Actually powering it that way seemed to increase the fluctuations.
Capacitors for decoupling go one leg in VCC and the other in GND… IF DECOUPLING with polarized make sure u put the right leg in the right polarity.
Another suggestion is changing the ADC sample time to take more time (cycles), and if everything else fails you might do a running average function where you take several samples and keep an array of the last N samples and average their readings. Not ideal but if the noise is not too much and you don’t want extreme precision it might work.
It is more like a FIFO array (first in first out) newest sample is move along the index and the oldest one discarded, then you sum all the readings cached and average them by the number of samples kept in the array or cache. The more samples you keep the more lag for response to reading changes, and the more stable the final averaged reading will be. Try 10-20-50-100 even more… Adjust to see if that helps and the reading speed/ precision is within tolerable levels.
Another obvious solution is to turn off wifi when reading ADC… but I guess this will be less than efficient and ideal.
As a debug I am taking a running max and min of the readings I get from the POT and in a range from 4095 to zero I am getting 3218 and 347. I misspoke earlier, I don’t check as often as possible I do it on every 1000th count of the loop, still more than 1/second or so but I want to be responsive to the user. I use the map function to do a range of 45-90 which means it won’t change to the next reading until it changes by more than 90 and I only use the map function if it has changed at least 64 from the last reading. The fact that I can get such a wide range tells me I’m going to have a heck of a time smoothing this out with software
Also I only update the display if there is something new to show, I save the previous reading and check the new one to see it it is the same, if so, I don’t update, so while I check a lot, I theoretically update the display only when necessary (Ironically I update my debug max min the most.)
This is what makes me think I need to fix the circuit not the software.
When you say it should be between VCC and GND, would this be on the feed to the POT or the main feed to the circuit? I do have what I now think must be a decoupling capacitor on the temperature sensor, so I’m figuring this is going on the Pot.
Well, if the OLED is taking the power needed… Then between the VCC and GND that power the OLED. or if this is happening when the radio is on, then do it in the mains that power the photon.
The capacitors will serve as a reservoir of power when something suddenly needs it.
Try something in the range of 470uF.
Do you have a drawing on how you are hooking this up?
Where is the power coming from for the potentiometer? Are you using regulated 3v3?
The core used to have a filtered power output that could help you here, but the photon did away with it. It needed the pin.
The weird thing is that I am doing ADC in photon without that much variation as you are seeing even with the radio in auto mode.
I fixed an issue rescently with some servos by putting decoupled capacitors in the power input of the photon by suggestion of users here. That was another issue entirely, the servo was starving the core from its power under high loads. However this servos where high power hungry ones. I don’t think it is normal for the radio to produce variations that big on ADC readings. I would also consider high pass filter capacitors with lower F rating… However…
I would check your cabling first. It the cable near the antenna ? Are the cables peeled open? Do you have cold sodders?
Try unhooking peripherals. For instance the OLED display. Maybe a component is serving as a big antenna and sending interference thru your lines.
I am not super good at this so I might be suggesting something stupid here, but hey !! It only takes time and not too much effort to try and a lot of upside of we find your culprit!.
Good luck and keep us posted.
you may want to google “low pass filter [arduino potenitiometer]”
I thank you for your input even if it may be flawed, I think the biggest power hog of this circuit has to be the display, though your comments made try another look at things, I am doing some “fencing” by pinging phones to see who is home, and if no one is home, I use different temperature settings and I also dim the display with PWM. I occurs to me that when I went manual, I also dimmed the display since it couldn’t find anyone. So this time I stayed in normal mode but set the display to dim unconditionally. It is more stable this way, but I do see fluctuations when it is pinging phones. Hmmm. But I also just realized that I didn’t recheck to see if the A0 pin which I am using to read the POT is one that won’t play well if other pins are being used. BTW, the display id TFT and I should have specified it it ILI9340C because that is a newer model than it’s predecessor.
AO seems to not have any issues with other pins by my reading of the docs.
I have to leave this right now, but I have a schematic that I just have to review for accuracy and I will post it.
Here is the schematic of what I am up to It is on a breadboard, the relay is not currently connected.
Try a blank program with only readADC on that pin. Disconnect power to the OLED.
And print out the readings… see if that fixes it. If it does, start adding the OLED… And so on…
THat didn’t work too well, but a big part of that is reading from serial which is like drinking from a firehose for this.
What I did do was look more closely at the code I was using to print the debug info and I found that it was being affected by initial values of zero and making false max and min values. I have fixed the output and am getting more meaningful info, I slowed the loop down with delay so I don’t read faster than 1/10th per second.
What I see is that the majority of readings are very stable with a difference from previous in single digits. Then it seems to have steps of going into a series of 17 or so and also low 30’s for a period of time. All of which are fine since as long as it’s below 64. But when it goes over it’s just a single blip between 120 and 350 sometimes more.so the worst case is under 10% of the range. But it’s still doing it. I triggered web updates which would use the WiFi and I saw no real change.
I’m going back to manual mode with this improved info to see what I see.
I installed a second Photon today for other reason on one of my apps. I found erratic ADC readings!! Like you describe!
I returned to my previous photon and found that the readings where fine!!
Not trying to imply anything here… But there “MIGHT” be a problem with your device. Do you have another to test?
I emailed Support without answer yet. Let you know of anything.
I had some interesting results myself. I set the system to manual so it wouldn’t communicate with the internet. I have my display constantly reporting the following: A counter of how many times the reading changed by more than 64 (The threshold for deciding a user is turning the knob), the previous reading , the current one, the difference between them and the maximum difference seen.Normally in a matter of minutes I have double digit numbers for the counter, this morning the number stayed at 1 all night (1 is the initial set after boot so it is the minimum number). Watching the difference, I saw single digits or a number around 40. The max value of difference overnight was 47.
I am using A0 for the readings. I am going to see if I can change to a different pin and get different results. I don’t have another Photon, just a core which can no longer hold my current code. But as I said from the beginning One the Core, I had no problems with the stability.
OK, I just did something that seemed to cure my ills, but it is early yet.
I reversed the photon’s position on the breadboard Initially I had built the breadboard with the Core’s USB connector right on the edge of the breadboard on the left side arranged in Landscape mode as a breadboard would force you to do. This meant that the WiFi antenna was about 1/4" away from the edge of the LCD Display.
Now when I got the Photon, I just swapped the chips out so everything was the same. I did have to rearrange a couple of pins such as the 3v3+ power regulated pin, had to now be on the regular 3v3 pin. I had even run 5V directly to the POT with no notable change in the behavior.
So I pulled out all of the wires and turned the chip around so the chip is in the same footprint but the antenna (I use the built-in). is now at the edge of the board and the unused USB port is pointing to the LCD screen. At this point running about 1/2 hour this way, I’ve done several updates if data over the web and I am still sitting at 1 setpoint change and the largest fluctuation is at 22. Previously this would have had several bad fluctuations.
SO a shout-out to @BulldogLowell for suggesting looking at this as the issue, Now that I have better data this really becomes clear as the right track.
I’m going to let this run the rest of the day and report back, but this seems to point to the Photon being at least more sensitive to interference than the Core.
A picture’s worth a thousand words. The POT is way over on the right. The Photon is in the same spot it has been just turned around.