DHT22 & arduino Langer kabel?

Ik heb een DHT22 temp sensor aan een arduino, met een kabel van 4 meter...

althas ik heb er 2... 1 bijna rechtstreeks p[ de arduino, die doet het prima...

dan heb ik er eentje op een kabel van een meter of 4... en die val heel vaak weg.... of refresh niet meer op me Nextion schermpje...

dus ik vroeg me af wat nu de beste manier is om deze op een wat langer kabel aan te sluiten...

Ik heb een weerstand van 10K aan de sensor kant? misschien moet ik die aan de arduino kant zetten?

wat is de beste kabel?

en ik zie heel veel Cat5 kabel... maar ook dan weer, plus en min 1 paartje? en de data een aparte draad? ?

wie heeft tips??

Alvast bedankt!!!

cnc filmpjes op Http://www.arjan-swets.com

https://www.kiwi-electronics.nl/nl/dht22-am2302-temperatuur-vochtighei…

Wat voor kabel heb je nu gebruikt en hoe heb je dat precies aangesloten? Cat5 kabel heb je niets aan omdat je geen dataparen hebt die bij elkaar horen.

Ik zou als eerste proberen de 10k weerstand een stuk kleiner te maken, helaas is het een waardeloze datasheet die ik gevonden heb en er staat bv niet in hoeveel mA hij max mag schakelen. Ik zou de weerstand eens 2k7 maken. Dat zorgt voor wat steilere en betere flanken van het digitale signaal. Welke kant van de kabel? ik heb geen idee.

[Bericht gewijzigd door benleentje op 15 oktober 2021 00:02:56 (41%)]

Meeste (half chinese) datasheets ervan bevatten inderdaad bijna geen nuttige informatie, heb er wel een gevonden...
Pull-up aangeraden is 5k1 (4k7 wordt dat dus)
Bij 3.3v voeding is de max. kabellengte 1m.

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Helaas voor de TS gaat een simpel serieel touwtje over grote afstanden niet echt werken. Tegenwoordig helemaal niet meer omdat de IOP (Internet over the powerlines) systemen steeds populairder worden.

Lang geleden had ik ook zo'n soort probleem en dat had ik eerst opgelost door met twee trafo'tjes te werken. Een aan het begin en een aan einde van de lijn. De trafo's kwamen uit kleine audio eindversterkers van die kleine draagbare transistor radio'tjes. Om die trafo's aan te sturen gebruikte ik toen een video power opamp van philips. De 392 ofzo dacht ik.

Later had ik iets ander verzonnen met een balanced linedriver van lineair technology.

Ik dacht deze:

Voordeel is dat je hier een gewone UTP kabel kunt gebruiken. Je gebruikt dan een van de twisted pairs. Omdat je in elke kabel vier twisted pairs zitten heb je dan een heen en retour kanaal en je je hebt nog draden over om een voedingsspanning over te brengen.

Ik heb dit gebruikt om zowel analoge als digitale signalen over 900 meter te transporteren door een industriële omgeving. De analoge signalen (geen audio) waren sinusvorming en gingen tot iets van 10KHz ofzo. Digitaal was een serieel signaal (afkomstig van een echte RS232 poort) van 19K2 bauds ofzo. Ik weet het allemaal niet zeker meer. Was denk ik een goede 20 jaar geleden.

Ik denk overigens dat je eerst Arco's idee moet proberen en wat spelen met die pullup weerstandjes. Misschien werkt dat dan en ben je daar gewoon klaar mee.

Voorstel: Ontkoppelcondensator 100nF bij de DHT22 monteren. Probeer ook eens een 10uF elcotje er naast te zetten als dat onvoldoende helpt.

@Ex-fietser: En hoe doe je dat met een bidirectioneel signaal?

[Bericht gewijzigd door rew op 15 oktober 2021 09:16:41 (19%)]

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

@REW;

Is dit signaal bidirectioneel? Dat kon ik niet echt vinden in de beroerde datasheet. Dacht eerst ook dat het iets van I2C zou zijn ofzo. Maar in de datasheet kon ik dat niet echt duidelijk vinden. Misschien te snel gekeken. Maar eigenlijk wel logisch als je zowel vochtigheid en tempereatuur wilt meten en de waarde over twee touwtjes wilt versturen.

Dan gaat het dus helaas niet. Er zal iets van een splitter bij moeten komen. Maar ik denk dat het handiger is om uit te kijken naar een repeater achtig ding zoals die in meer tweedraads netwerkjes gebruikt worden.

buckfast_beekeeper

Golden Member

Een ESP (of ATtiny) naast de DHT22 en serieel laten communiceren met de arduino?

Van Lambiek wordt goede geuze gemaakt.
Stijnos

Golden Member

ik weet ook niet hoe de sensor communiceert met de arduino, of de arduino iets opvraagt bij de sensor en daarmee dus bi-directionele communicatie nodig is.
Ik zou een 2e arduino micro pakken deze dicht bij de sensor houden en de meetwaarden inderdaad serieel (eventueel via 2x max485 differentieel) versturen naar de arduino waar de nextion aan hangt.

En dan ipv "serieeel" moet dat gewoon RS485 zijn. Toch?

Dit wordt, schat ik, veel te ingewikkeld voor de TS. Die wil gewoon op 3 plekken de vochtigheid en temperatuur meten en heeft drie DHT22's (*) aan z'n arduino gehangen.

@exfietser: In het datasheet dat door Arco gelinkt is, zie je na verloop van tijd een golf-vorm-plaatje. Daar staat het eerste deel van de golfvorm extra dik gedrukt met als onderschrift: "by the host". (of zoiets).

De host stuurt een startpuls, daarna gaat die de datalijn pollen: na iedere opgaande flank: 35 us wachten en dan het databit inlezen van de communicatiedraad. Zo haal je bijna? 40 bitjes binnen (#).

Als de TS zegt dat de chip "vastloopt" dan denk ik dat er powerdips op de lijn zitten waardoor de chip dus onderuitgaat maar net niet genoeg om de brownout reset te triggeren.

Er zijn systemen zoals i2c en dit (en de echte) one-wire protocol waarbij het "hoog" niveau door een weerstand geleverd wordt.

Bij lange draden op zo'n protocol is het van belang om de weerstand zo laag te kiezen dat de RC van de draad en de R laag genoeg is dat je er geen last van hebt bij het protocol. Omdat "ouderwets" i2c met iets van 4k7 op 5 microseconde per halve-periode werkte en 4m kabel aankon, zou ik bij deze ongeveer 10x langzamere situatie niet direct een probleem verwachten met een weerstand van 4k7, 5.1k of 10k. Maar het zou kunnen. Een onnodig lage weerstand verhoogt het stroomverbruik, en kan in extreme gevallen te veel zijn voor de output poort. Bij de arduino is dat officieel 20mA, dus 5V/20mA = 250 Ohm. Dat is het minimum. De DHT zou best wel eens minder sterke drivers kunnen hebben -> ik zou niet lager gaan dan 1k.

Als dat het geval is, dan loopt niet de DHT22 maar de arduino vast. Als die verwacht 37 of 40 bits te ontvangen en geen timeout heeft dan hangt ie als er een start-van-een-bit puls gemist wordt.

Wat ik vroeger deed met de DHT22 is de lengte van de "hoog" periode meten. Ik kreeg dan iets van 5 loops voor een 0 en 14 voor een 1. Nu ik ouder ben heb ik bovenstaande truuk: "na 35 microseconden het datbit van de lijn plukken" bedacht. Met mijn oude implementatie zou je "te kleine weerstand" zien doordat je maar 2-3 hoog meet met uitschieters naar 1 en heel soms 0: puls helemaal gemist.

(*) En een manier om die data te presenteren: Display, link-naar-een-database, zoiets.
(#) ik zag vandaag iets van "bitje 37" als naam voor het eerste bitje. Maar nu ik dat afrond naar "bijna 40" denk ik me te herinneren: "precies 5 bytes, ja dat was het".

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Ik zou beginnen met de pull-up de juiste waarde te maken. (max. kabellengte op 3.3v is 1m, op 5v is 20m)
Is zou te zien een 1-wire achtige interface...

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Ik zou een 2e arduino micro pakken deze dicht bij de sensor houden

Ga dan meteen aan de gang met een wmos dingetje. Dan heb je geen draad meer nodig ook.

Pull-up aangeraden is 5k1

Er is nu al een 10K pull-up aan de ene kant - misschien waard om te proberen met een tweede 10K aan de andere kant?

hoe beter de vraag geschreven, zoveel te meer kans op goed antwoord

Met dit soort protocols is het meestal een timing probleem; het steekt nogal nauw met die vrij korte tijden...
(ook veel voorkomende fout: men laat de interrupts aanstaan tijdens het 'binnenharken' van de data, dat geeft variabele en onvoorspelbare extra delays)

Je kunt ook de data binnen een timerinterrupt binnenhalen, dan klopt de timming altijd.

[Bericht gewijzigd door Arco op 15 oktober 2021 11:33:26 (15%)]

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
buckfast_beekeeper

Golden Member

Op 15 oktober 2021 10:45:20 schreef Ex-fietser:
[...]

Ga dan meteen aan de gang met een wmos dingetje. Dan heb je geen draad meer nodig ook.

Is wel kort door de bocht. Moet je nog steeds de spanning voorzien. Met WiFi verbruikt dat wemos bordje (ESP8266) net wat meer als een ATtiny.

Van Lambiek wordt goede geuze gemaakt.

Met WiFi verbruikt dat wemos bordje (ESP8266) net wat meer als een ATtiny.

Da's heel netjes uitgedrukt... ;) (verschil is 5mA vs 250mA...)

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

waarom hang je voor 1,5€ er geen arduino nano aan achter die 4meter, laat je die de dht uitlezen en dat die zijn gegevens over RX terug stuurt, desnoods aan lage snelheid. zo zou ik het toch altijd doen als ik over verre afstand met onbekende procotollen moet werken.

meen me te herinneren dat die dht library idd een paar precise flanken maakt om te communiceren

ik hou van werken ..., ik kan er uren naar kijken
bprosman

Golden Member

Op 15 oktober 2021 09:00:15 schreef Arco:
Meeste (half chinese) datasheets ervan bevatten inderdaad bijna geen nuttige informatie, heb er wel een gevonden...
Pull-up aangeraden is 5k1 (4k7 wordt dat dus)
Bij 3.3v voeding is de max. kabellengte 1m.

Volgens mij zijn die sensors allemaal "Sensirion clonen".
https://www.sensirion.com/en/download-center/

De jongere generatie loopt veel te vaak zijn PIC achterna.

Ik ken deze sensor niet, maar het protocol lijkt simpel: De datalijn heeft een pullup, de microcontroller trekt hem laag voor > 1ms en kijkt wat er terug komt.
https://www.sparkfun.com/datasheets/Sensors/Temperature/DHT22.pdf

Mijn gevoel, op basis van vrij goede ervaringen met het op papier veel kritischer 1-wire en I2C over wat langere afstand, is dat het tenzij de sensor een zeer slappe open drain heeft zou moeten gaan, allicht niet foutloos maar een gemiste meting is bij zoiets toch geen ramp? Er is niet voor niets een checksum.
Wordt dit mogelijk niet goed afgehandeld en/of zitten er torren in de code?

Op UTP zou ik data en ground samen in een pair nemen, dat is de meest kritische stroomkring. De voeding laat zich ontkoppelen.

Komt vaak door slechte firmware functies. De sensor moet 40 bits data verzenden. Veel firmware wacht dan tot die binnen zijn.
Als er dan een bitje 'zoekraakt', blijft de boel eindeloos op dat bitje wachten. (vaak wordt niet in een timeout voorzien...)

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Op 15 oktober 2021 11:31:15 schreef Arco:
Je kunt ook de data binnen een timerinterrupt binnenhalen, dan klopt de timming altijd.

Pfoeh! timer interrupt??? Tricky lijkt me.

Mijn truuk met "het datasignaal is gewoon het gestuurde bitje als je 30 µs wacht na de opgaande flank is redelijk te doen met een pin change interrupt. Op de opgaande flank de interupt nemen, dan 30 microseconden verdoen en dan het databit pakken en opslaan.

Overweeg om "lastbit=digitalRead (DHT_PIN); return" te doen als de 30 microseconden over zijn. In die 30 microseconden kan je dan rustig het "lastbit" verwerken, en bijvoorbeeld "lastbit" op 42 zettten. Dan de teller met het aantal bits ophogen. Het hoofdprogramma weet dan dat er haast nieuwe data is bij 40 bits en dat ie dan moet wachten op "lastbit != 42" voordat hij ook het laatste bit kan verwerken en de gemeten data kan interpreteren.

Dit is wel "klote code" want voor iedere code wijziging moet je eigenlijk opnieuw calibreren hoelang je code nodig heeft en hoeveel microseocnden er nog bij moet om op 30 uit te komen....

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

ik heb ge-googled.... maar max lengte zo 30 meter zijn op 5 volt? en heb ook 60 meter gezien....

en ik heb het over 3 meter.... en dan doet hij het al niet lekker meer...

vandaar dat ik het vraag....

maar ik ga dus eerst naar 4k7

en dan een elco op de + en - , aan de sensor kant?

Ontkoppelcondensator 100nF die zit dan tussen de data lijn en de min?

cnc filmpjes op Http://www.arjan-swets.com
buckfast_beekeeper

Golden Member

Ontkoppel altijd tussen + en -. Je gaat de steilheid van de datalijn alleen verslechteren met een 100n c er over.

Storing in de omgeving kan altijd een invloed hebben. Bij gebruik van afgeschermde kabel, maar 1 zijde van de afscherming aan GND leggen.

Als je een elco plaatst, zet er dan een 100n naast.

Van Lambiek wordt goede geuze gemaakt.

Met een 100nF tussen datalijn en gnd werkt er gegarandeerd niks meer... ;)

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Op 15 oktober 2021 21:46:38 schreef Arjan Swets:
..maar max lengte zo 30 meter zijn op 5 volt? en heb ook 60 meter gezien....
en ik heb het over 3 meter....

Ik heb "vroeger" ook zo'n DHT2x gebruikt. Op een Arduino Nano deed ie het prima, weken achter elkaar zonder problemen. Toen naar een ESP12...ging een paar uur goed, daarna was ie "kwijt" geen response meer. Ik heb de driver aangepast, extra delays erin, die dingen, niks. Maw, het is een vrij kritisch ding. Dat het bij jouw met 3m kabel (!!!) nog werkt is op zich al bijzonder.
Tip: gebruik BMP280 of BME280.

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein

kabel iets korter gemaakt.... weerstand veranderd... elco er bij...
en nu doet hij het goed....

dus eerst maar ff zo kijken....

allemaal bedankt!!!

cnc filmpjes op Http://www.arjan-swets.com