Arduino sensorgegevens onregelmatig

Ik ben een noob die alleen maar nat wordt in EE, dus doe het rustig aan, alsjeblieft. Ik heb een Arduino Uno gekocht en de afgelopen weken tons geleerd. Ik nam een ​​LM35-sensor, een generieke thermistor (met een weerstand van 10kohm), een lichtafhankelijke weerstand (fotoresistor?) (Met een weerstand van 10k), een knop (met interne Arduino-pullupweerstand) en een paar LED's (met 220ohm-weerstanden ) en bedraad ze allemaal naar mijn Uno. Ik kan een diagram geven, maar ik vermoed niet dat het er veel toe doet. Kortom, sommige delen dezelfde basis en sommige delen dezelfde 5v.

Ik merk dat de temperatuurgegevens van de LM35 en de thermistor erg grillig zijn. Het varieert helemaal vanzelf, plus wanneer ik op de knop druk. Ik heb veel forumberichten gelezen die zeggen dat dit soort sensoren een spanningsregelaar nodig hebben om accuraat te zijn, dus hier is mijn vraag: is het waarschijnlijk dat de oorzaak van mijn grillige sensorgegevens is omdat het aanbod van mijn Arduino niet constant genoeg is, en dat het verslapt of spiking?

Zo ja (of zo niet), wat is de oplossing voor dit probleem? Moet ik een van die kleine 5v-broodplank-voedingen kopen?

Update: Ok, here's a diagram. It's a proud day for me, this is my first circuit schematic ever! enter image description here

And here's a graph of the LM35 readings. It's only read once every 9 seconds. It's just sitting on my office desk, no furnace vent nearby or anything. Now, the graph is not raw analog readings, but rather F temperature. But the raw analog readings are all over the map, including 116, 107, 90, 145, 129, etc. Don't get distracted by the analog->temperature math, I don't care about the accuracy, I just want it to be stable! enter image description here

Update 2: The photoresistor and the thermistor are reading very consistent, only the LM35 is all over the map.

0
ja ru de
Mijn aanbeveling zou zijn om elk van uw sensoren alleen in zijn eigen circuit te testen
toegevoegd de auteur wannabecapablanca, de bron
Je zou een diagram moeten geven - het maakt wel uit. Inclusief ALLE verbindingen naar voeding en aarde, en ALLE verbindingen met de Arduino. Je vraag is niet erg goed zonder deze (en dus geen kandidaat voor migratie !!). U kunt zelfs uw code opgeven.
toegevoegd de auteur wannabecapablanca, de bron
@ScottSeidman Ok, sloeg er een in Visio. Bijgewerkt. Ik denk niet dat de code relevant is. Het leest feitelijk elke sensor eens in de 9 seconden af.
toegevoegd de auteur Arno van der Weijden, de bron

4 antwoord

Bepaal of de ruis is gecorreleerd of willekeurig.

Het helpt als je een heleboel gegevens vastlegt en plot. De frequentie en het soort ruis kunnen erg belangrijk zijn. Als u "willekeurige" ruis heeft, kunt u deze gemakkelijk filteren in de software zolang u uw ADC snel genoeg samplet. Als je gecorreleerde ruis hebt, wat in feite betekent dat de ruis verandert met het signaal dat je probeert te meten, kan het moeilijker zijn.

Dus, om je oorspronkelijke vraag te beantwoorden, om te bepalen of de ruis te wijten is aan schommelingen in de stroomvoorziening, zou ik een andere ADC-pin op de Arduino verbinden met de voeding (via een weerstandsverdeler) en deze tegelijkertijd met de sensor samplen. Als u gegevens voor beide plot, is het heel duidelijk of de ruis is gecorreleerd.

Als ze gecorreleerd zijn, zou een optie kunnen zijn om de toevoer-ADC in je ontwerp te houden en af ​​te trekken van de sensorwaarde, wat een quasi-differentiële uitlezing geeft.

Als ze niet gecorreleerd zijn, komt het geluid waarschijnlijk van iets anders. In dat geval,

  • Hoe lang zijn de draden aangesloten op de sensor?
  • Hebt u filterdoppen op de afstandssensor?

Ook is dit een uitstekende tool die ik vaak gebruik om softwarefilters snel te ontwerpen: http: //t-filter.engineerjs .com/ Het genereert de broncode voor u. (Stel voor Arduino de getalnotatie in op integer!)

1
toegevoegd
Absoluut FFT is het beste voor Arduino en deze meer dan eenvoudige taak. Arduino staat bekend om zijn rekenkracht.
toegevoegd de auteur Chuck Mattern, de bron

Eerlijk gezegd kan ik me niet herinneren hoe precies de LM35 op zijn best is.

Maar een zeer bekend algoritme dat gebruikt moet worden (vooral met 'onregelmatige' sensoren) is om het 'voortschrijdend gemiddelde' van de laatste x metingen te gebruiken. Dit betekent dat u het gemiddelde van de laatste x-waarden neemt. Als u een nieuwe sensorwaarde krijgt, neemt u opnieuw het gemiddelde van de laatste x-waarden (dat is het 'bewegende' gedeelte).

Hierdoor wordt de temperatuur in de loop van de tijd veel soepeler. Welke x is u zelf kunt definiëren. Voor een grote x krijg je een beetje 'vertraging' omdat je eerste x-metingen nodig hebt. Maar mijn vermoeden als je x tussen 5 en 10 neemt, zal je veel verbeteren.

Een andere toevoeging is het verwijderen van waarden waarvan u weet dat ze niet waar kunnen zijn (zeer lage of hoge pieken).

Als u geen rekening houdt met de spike-waarden en het gemiddelde van de laatste x-metingen neemt, krijgt u een veel betere waarde.

There seems to be even an Arduino library for it (it's calling running average), see here.

0
toegevoegd
Overweeg het gemiddelde van de laatste 10 waarden elke keer dat de eerste 2/3 een redelijke vloeiende stroom zal hebben, de laatste 1/3 hebben lagere waarden, maar misschien is de temperatuur ook in realtime enigszins gewijzigd.
toegevoegd de auteur Spike, de bron
Bedankt voor je suggestie. Mijn gegevens zijn zo gek dat ik er niet zeker van ben dat het middelen van de gegevens nuttig is omdat de gegevens zo verspreid zijn. Ik heb mijn bericht bijgewerkt met een beetje meer details en een grafiek.
toegevoegd de auteur Arno van der Weijden, de bron

IMO veel beter dan het gemiddelde is een heel eenvoudig digitaal laagdoorlaatfilter.

LPF_DEPTH_SHIFT as large as slower reaction to the changes (lower filter "frequency"). Remember that LPF_data has to accommodate (max value) << LPF_DEPTH_SHIFT. You need to choose the proper type.

#define LPF_DEPTH_SHIFT   3

unsigned int LPF_data = UINT_MAX;

unsigned int lowpassfilter(unsigned int value)
{
    unsigned int v = LPF_data >> LPF_DEPTH_SHIFT;
    if(LPF_data == UINT_MAX)
        LPF_data = value << LPF_DEPTH_SHIFT;
    LPF_data -= v;
    LPF_data += value;
    return LPF_data >> LPF_DEPTH_SHIFT;
}
0
toegevoegd
Ik heb al gezegd dat ik ongelijk had.
toegevoegd de auteur wannabecapablanca, de bron
Dit is niet wat de meeste mensen een laagdoorlaatfilter zouden noemen.
toegevoegd de auteur wannabecapablanca, de bron
Meer specifiek, je hebt een IIR-filter
toegevoegd de auteur wannabecapablanca, de bron
... en een voortschrijdend gemiddelde is ook een LPF, een goederenwagon.
toegevoegd de auteur wannabecapablanca, de bron
Het is een LPF, maar verklaart zeker niet het LM35-probleem - dekt het gewoon af.
toegevoegd de auteur wannabecapablanca, de bron
@ScottSeidman - je kunt gewoon niet toegeven dat je ongelijk hebt. Belachelijk.
toegevoegd de auteur Chuck Mattern, de bron
@ScottSeidman - is dit het laagdoorlaatfilter of niet? Heb je het google?
toegevoegd de auteur Chuck Mattern, de bron
@ScottSeidman Vertrouw me, deze code gaat niet zo goed. Lees de code zorgvuldig door en probeer deze te begrijpen. Het is slechts 5 lijnen - niet de raketwetenschap
toegevoegd de auteur Chuck Mattern, de bron
@ScottSeidman Maar dat is het. Een heel eenvoudige natuurlijk. Dit wordt een bewegend (of lopend) gemiddeld laagdoorlaatfilter genoemd. Google het als je er nog nooit van gehoord hebt
toegevoegd de auteur Chuck Mattern, de bron

Je kunt RC het apparaat filteren als alternatief voor het kopen van een regelaar. De datasheet laat zien dat het IC kan werken op 4V en u levert 5V. Er staat ook dat het maximale stroomverbruik ongeveer 100uA is, ervan uitgaande dat u de output niet laadt die uw Arduino waarschijnlijk niet is, tenzij u zo snel mogelijk bemonstert. Laten we voor de veiligheidsmarge ervan uitgaan dat de IC tot 1000uA kan verbruiken.

5V-4V = 1V 1V/1000uA = 1k ohm

Pas de grootste condensator toe die je redelijkerwijs kunt na de weerstand en direct tegenover de voedingsingangen van de IC en je hebt een veel schonere toevoer. Simulatie link hieronder.

Falstad Sim

0
toegevoegd
Merk op dat u ditzelfde type filter ook direct op de invoer van de ADC kunt toepassen na de uitvoer van de LM35. Dit kan effectiever blijken.
toegevoegd de auteur NKN, de bron
Dat is cool, bedankt voor de simulatie en voor het idee. Ik moet een dop kopen en dat uitproberen.
toegevoegd de auteur Arno van der Weijden, de bron