raspberry ziet pulsen niet

ik ben al een tijdje met een systeem bezig om mijn zonnepanelen te monitoren.

wat doe ik daarvoor:

ik heb 2 kwh meters in mijn kast hangen.

bij beide zit er binnenin een opto coupler parallel over de pulse led (P+ en P- onder het display). dus ipv het licht van het ledje te detecteren, heb ik die opto coupler uitgang naar buiten gebracht.
de linkse hangt op een raspberry die toevallig in de garage hangt (camera systeem). en mijn webserver (andere raspberry) leest die pulsen in.

dat wou ik compacter. dus de 2de kwhmeter hangt direct op een raspberry zero en die handelt ook de hele website af. dat is dus 1 toestel die alles doet.

probleem:
die rpi zero heeft een aantal dagen goed gewerkt, en gisteren niet meer. zie geen pulsen. ik heb een camera systeem op die kwh meters hangen en zie de pulse led af en toe knipperen.

ik heb als test met een schroevendraaier mijn GPIO18 aan massa getikt, de rpi ziet pulsen. ik heb de kwh meter met een andere rpi getest, die ziet wel de pulsen.
mijn rpi zero ziet de kwh meter echter NIET.

voor de grap heb ik de pulsedraad op GPIO23 gezet en even de code veranderd, ding werkt.

de code is dit:

code:

#!/usr/bin/env python2.7

import time
from datetime import datetime, timedelta
import RPi.GPIO as GPIO

GPIO.setmode(GPIO.BCM)
PIN=23
GPIO.setup(PIN,GPIO.IN, pull_up_down=GPIO.PUD_UP)
lasttime = 0
pulseskwh = 1000

def pulseinterupt(channel):
        time.sleep(0.002) # debounce
        if GPIO.input(PIN,) ==  0:
                global lasttime
                global kw
                kw = 0
                if lasttime==0:
                        lasttime=time.time()
                else:
                        nu=time.time()
                        gap=nu-lasttime
                        kw = (3600/gap)/pulseskwh*1000
                        kw = int(kw)
                if kw <= 1000 and kw >= 2:
                        writepulse(kw)
                        writemonth(kw)
        printlog("pulse gezien")


de writepulse en writemonth zijn 2 procedures die gewoon een regeltje toevoegen met datum en tijd van mijn logfiles. en deze leest mijn webserver dan weer in.

mijn probleem dus:
1)met schroevendraaier de GPIO18 en massa aantikken werkt.
2)de kwh meter tussen GPIO18 en massa wordt niet herkent (heeft 1week wel gewerkt)
3)de kwhmeter tussen GPIO23 en massa doet het wel
4)mijn andere rpi heeft al 4maand de optocoupler tussen GPIO18 en massa zitten en die blijft wel werken.

is er ergens een timing probleem ofzo? een pulse te traag/te zwak? waarom werkt het wel op gpio23 en niet op 18 (en bij het andere systeem wel).

ik vrees dat ik ergens mijn GPIO kapot maak en wil voorkomen dat GPIO23 er volgende week ook aan is. maar aan de opto coupler zitten geen spanningen, dus mismatch 3,3-5V is er niet, de rpi werkt met interne pullup, dus ook geen rare weerstand die aan de GPIO extern hangen. rpi hangt op ene plankje 1meter verder van de zekeringkast, kan dus ook niet per ongeluk tegen een fase zijn gekomen.
ik ben op het werk, er worden ook geen inductieve lasten gestart in de loods die op mijn bekabeling kan inwerken.

de verbinding van de linkse kwh meter naar de oude rpi loopt over die wit/blauwe tweedraad.
het nieuwe systeem met de rpi zero werkt met een microfoon jack en dus afgeschermde audiokabel. ik zou eerder verwachten dat het oude systeem zou sneuvelen

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

Golden Member

Zou de ene io pin een pullup weerstand nodig hebben en de andere io pin niet?

is de ene ingang sneller?

u=ir betekent niet :U bent ingenieur..
EricP

mét CE

Zet er eens een scope op en meet wat er gebeurt. Dan kun je pas conclusies trekken over de oorzaak.

Het zou zomaar kunnen dat het 'op het randje' zit qua spanningen ofzo. En dat het daarom soms wel en soms niet werkt. Of op een andere ingang wel. Er zit spreiding in! In de datasheet staat vast wel hoeveel. En meestal heeft de temperatuur daar ook wel invloed op.

Verder willen die 'klink' stekkertjes ook wel eens beroerd contact maken. Zeker als je er een keer met je vingers aan gezeten hebt. Koptelefoons gebruiken ze ook wel. Zou het kunnen zijn dat je bij omzetten van I/O pin ook die stekker bewogen hebt en dat het gewoon toeval is?

GPIO zonder enige beveiliging 'naar buiten' brengen is ook wel een beetje vragen om problemen. Dat spul is vaak best hoog-impedant, en daarmee best gevoelig voor enige vorm van 'koppeling', wellicht met desastreus gevolg.

Interne pullups gebruiken met lange bedrading is af te raden.
Er vloeit maar heel weinig stroom en zijn enkel goed voor bediening op de print zelf.
Ook bij pic's heb ik dat ervaren, er vloeit maar ~200µA.

Als proef zou je eens een 1k weerstand naar de + kunnen leggen.

LDmicro user.

in mijn eerste versie had ik dat zo, maar had wel van 5V afgetakt.
5V-weerstand-GPIOpin-weerstand-massa.
en de opto zat tussen gpio en massa dan.

echter hier in een ander topic te zien gekregen dat rpi maar max 3,3V op zijn gpio mag hebben. en ik werkte al een aantal weken met 5V.

daarom alles eraf, interne pull up en 2draad naar de opto coupler gebracht. eenvoudiger en minder kans op fouten.

maar nu nog loopt het fout. en als dat toch de oorzaak zou zijn, waarom werkte het dan 2uur wel met GPIO 23 en ervoor niet 'meer' met GPIO18. want tenslotte werkte het al 1week op de 18 ook voor die gisteren zomaar uitviel.

vanavond een beetje aanpassen en zal een 'adapter' voorzien die dan 3,3V met weerstand naar GPIO brengt.
kan ik een kleine C ofzo ook best tussen GPIO en massa zetten dit om eventuele storigen de grond in te trekken?
dan plug ik de 2draad op die adapter in en is er weeral geen kans op fouten

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

mét CE

Zoals reeds opgemerkt: het kan zo simpel zijn als een temperatuurverschil, verschil in luchtvochtigheid...
En als je wilt weten wat er gebeurt, dan hang je er een scope aan.

Verder kun je natuurlijk prima een weerstandsdeler maken om op 3V3 te eindigen. Geen enkele reden voor ingewikkeld gedoe. Wellicht zijn de pins ook gewoon '5V tolerant' en dan ben je een niet bestaand probleem aan het oplossen.
Een condensator zou wat ellende buiten de deur kunnen houden. Maar maakt de ingang ook trager. Daarnaast moet de opto-coupler elke keer de C ontladen, die stroom moet je wellicht beperken (alhoewel het met 100nF wel los zal lopen qua. stroom). Ook hier: als je echt wilt weten wat er gebeurt: hang er een scope aan.

Free_electron heeft hier ooit eens een knappe beveiliging voor een input pin gepost, zo heb ik wel eens gezien. Mag je zelf ff zoeken.

Op 6 april 2022 09:25:30 schreef fcapri:
in mijn eerste versie had ik dat zo, maar had wel van 5V afgetakt.
5V-weerstand-GPIOpin-weerstand-massa.
en de opto zat tussen gpio en massa dan.

Ik begrijp dat allemaal niet, je gebruikt interne pullups en je spreekt nog van 5V en ook van een weerstand tussen de GPIOpin en de massa..?
Een schemaatje is toch veel eenvoudiger dan een hoop tekst ;)

LDmicro user.
buckfast_beekeeper

Golden Member

Op blz 15 van deze pdf in tabel 3 staat als VGPIO_ref minimum -0,5V en maximum 3,6V. Op de volgende regel staat Vgpio minimum -0,5V en maximum VGPIO_ref +0,5V.

Gaan we er vanuit dat VGPIO_ref een correcte 3,3V krijgt zou 3,8V de veilige max zijn.

Volgens tabel 4 op dezelfde bladzijde is een VIH(GPIO) bij 3,3V minimum 2V en max VGPIO_ref. TS zal dus boven 2V moeten zitten om een zekere 1 te bekomen.

Van 5V tolerant is er dus geen sprake. Wat uiteraard niet wil zeggen dat het niet een bepaalde tijd kan goed gaan. De clamp diodes zullen hun werk ook wel doen binnen bepaalde grenzen.

Van Lambiek wordt goede geuze gemaakt.

Op 6 april 2022 10:15:11 schreef MGP:
[...]
Ik begrijp dat allemaal niet, je gebruikt interne pullups en je spreekt nog van 5V en ook van een weerstand tussen de GPIOpin en de massa..?
Een schemaatje is toch veel eenvoudiger dan een hoop tekst ;)

mijn eerste testopstelling was met weerstandsdeler op 5V.
toen hier op CO een topic gezien waar het af te raden was, dus heb alles gesloopt, en heb met de interne pullup gaan werken zodat ik dat probleem niet meer heb dan.
nu 3maand later werkt dat ding goed, maar door de testopstelling zit het verspreid over 2 raspberry's. (1 aan de zonnepanelen voor de pulsentelling en 1 in mijn huis voor het grafische gedeelte).

die hele opstelling wordt nu vervangen door een kwhmeter en rpi zero in de zekeringkast waarbij die rpi zowel het pulsentellen als het grafische voor zijn rekening neemt. en in die testfase zit ik nu (de software loopt wat traag op een single core).
volgende stap is toevoegen van een WPS knop zodat je die zo aan je wifi kan koppelen. alle beheer is remote, fysiek kan je niet aan de rpi dan. databackup is via een usb poort in de zekeringkast

en terwijl alles fysiek hetzelfde is als mijn oude versie, loopt het op de zero niet zo goed
beide softwares lopen nu parallel om kleine bugs eruit te halen

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

Op 6 april 2022 09:25:30 schreef fcapri:
maar nu nog loopt het fout. en als dat toch de oorzaak zou zijn, waarom werkte het dan 2uur wel met GPIO 23 en ervoor niet 'meer' met GPIO18. want tenslotte werkte het al 1week op de 18 ook voor die gisteren zomaar uitviel.

Weet je zeker dat je de 5V van de GPIO af hebt gehaald?

Dit is precies het verhaal waar mensen die 5V op IOs van de pi zetten mee komen: Het heeft 2 weken gewerkt, maar toen ineens niet meer.

Worst case was je te laat met het fixen van de 5V situatie en is ie later alsnog stuk gegaan.

@mel: Alle GPIOS op de BCM chip zijn in princiepe hetzelfde. 't enige is dat op de I2C pins een externe 1.8k pullup naar 3.3V zit... Hey... Idee! (moet ik het nog uitschrijven?)

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

mét CE

@rew: als het 5V via een pull-up weerstand is en de weerstand is niet te klein gekozen, dan lossen de protectie dioden dat wel op. En ja, dat is vreselijk lomp. En nee, zo moet je het niet maken. En het zal ook niet eeuwig goed gaan.
Het wordt een ander verhaal als je de boel uit 5V gaat 'driven' met iets wat meer dan zeg 0.5mA stroom kan leveren.

Op 6 april 2022 15:34:59 schreef rew:
[...]Weet je zeker dat je de 5V van de GPIO af hebt gehaald?

Dit is precies het verhaal waar mensen die 5V op IOs van de pi zetten mee komen: Het heeft 2 weken gewerkt, maar toen ineens niet meer.

Worst case was je te laat met het fixen van de 5V situatie en is ie later alsnog stuk gegaan.

@mel: Alle GPIOS op de BCM chip zijn in princiepe hetzelfde. 't enige is dat op de I2C pins een externe 1.8k pullup naar 3.3V zit... Hey... Idee! (moet ik het nog uitschrijven?)

dat was de andere, de rpi3 die mijn cameras heeft, die als eerste ook de pulsen van de zonnepanelen mag tellen.
de huidige is een rpi zero die dedicated voor de zonnepanelen zal draaien, deze heeft nooit op 5V gedraaid

als ik me goed herinner was dat iets van 100K dat ik tussen 5V en GPIO had zitten

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

Golden Member

Op de interne pullup, pulldown zit een serieuze spreiding. Bij 3,3V minimum 33k, typical 47k en max 73k.

Wat is de spanningsval over de transistor in je optocoupler? Trekt je opto je uitgang onder 0,8V om een low te krijgen en zit je boven 2V om een high te krijgen?

Heel snel zal het allemaal wel niet lopen. Je kan dan nog overwegen een levelshifter te nemen en de opto op 5V te gebruiken.

Van Lambiek wordt goede geuze gemaakt.

ik gebruik pullup, en de opto staat tussen de GPIO pin en massa geschakelt, die trekt dus naar beneden.
aangezien het maar een heel korte puls is, die afhankelijk is van de hoeveel zon die energie opwekt, kan ik daar moeilijk met een multimeter staan wachten op een pulsje om zo de spanning te meten.

momenteel draait het al 2 dagen probleemloos op GPIO23.
ik ga binnenkort een adapterprint maken die dan als shield op de rpi klikt. daarop zal ik dan een pullup weerstand naar 3,3V voorzien, en voor de zekerheid ook misschien een BC547 erop zetten die dan aangestuurd wordt door een optocoupler. ik kan die dan zo maken dat de BC547 van 5 naar 0V werkt. alles boven de 2V is dan een low, alles boven de 3V is een high

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

Honourable Member

Opto's zijn -als het op snelheid aankomt- nogal kritisch op de stromen.
Zo kan een korte puls (10us) volledig in het niet verdwijnen door een verkeerd gekozen stroombegrenzing aan de primaire kant en/of verkeerd gekozen pull-up waarde aan de secundaire kant.
De CTR van de gebruikte opto beïnvloedt beide waarden, de CTR is op op zijn beurt weer afhankelijk van de temperatuur....

De moraal: het doorgeven van korte pulsen met een willekeurige optocoupler is zonder oscilloscoop (met een voltmeter ga je ze never nooit zien) en pulsgenerator nauwelijks goed (lees: betrouwbaar) te krijgen.

Zet de zaak eerst op een breadboard en biedt pulsjes aan mbv een pulsgenerator en kijk aan de uitgang met een scoop om de juiste waardes te bepalen.
Ik ben ooit een dag bezig geweest om met een flut opto seriële communicatie op 19.2kbps te scheiden; dat ging uiteindelijk zo marginaal dat er van hogerhand werd besloten om 'dan maar' een goede (=duurdere) opto in te zetten...

Een goed begin is geen excuus voor half werk; goed gereedschap trouwens ook niet. Niets is ooit onmogelijk voor hen die het niet hoeven te doen.

Nu denk ik at hier de pulsen niet zo kort zijn omdat de opto origineel bedoelt waren om een led te pulsen, dan zit je toch ik eerder op 10mS en hoger.

de puls is zeker lang genoeg, ik zie ze vaak genoeg op de webcam,en die refreshed elke seconde

nu heb ik wel een ander probleempje, kan niet fysiek bij de RPi dus probeer mijn probleem te omschrijven.

zoals eerder vermeld heb ik 2 rpi's nu, het prototype en een nieuwe zero (laatste zag op GPIO18 zijn pulsen niet).

die zero werkt nu perfect op GPIO23, alles wordt gelogged, alle grafieken werken.
hert probleem blijkt nu in mijn prototype te zitten. deze reboot ele dag iets na de middag, onverklaarbaar waarom.

dit is de grafiek van de laatste 4dagen uit de zero

en dit de grafiek van prototype. als die crashed en reboot, begint dus dus opnieuw te tellen, daarom zie je enkel het laatste deel data
vandaag vind die zelf niks meer terug

nu technisch:

dit is een camera systeem, daar hangen dus 3 USB webcams aan en via software zijn die via het netwerk zichtbaar.

deze wordt gevoed met 12V over de netwerkabels, en aan de rpi zelf wordt die 12V omgezet naar 5VDC met DC/DC converter van 3A (5,25V ingesteld).
dit systeem werkt al maaanden goed.
daarom gebruik ik die RPI ook om de pulsen van de kwh meter. de pulsen zijn maximaal 1 puls per 6sec op vol vermogen. niet echt een probleem dus voor de load op die rpi.
nu valt die regelmatig uit sinds een paar weken, nuja, zo eens om de 4-5 dagen eens en moet ik het process van het logging weer manueel starten. ik heb dit in crontab laten meebooten nu zodat ik dat niet hoef te bekijen.
maar sinds kort is het al dagelijks.

in de logs kan ik niet direct wat vinden, via dmesg vond ik vorige week 1 melding van "undervoltage detected" en erna 'voltage normalised'.
ik ben gaan meten, DC geeft exact 5,25V af, en heb voor de zekerheid de usb kabel vervangen EN heb 1 usb camera uitgetrokken. dus al minder stroomverbruik.

echter valt die dus nog altijd uit, heb een heleboel fouten van undervoltage (terwijl ik het niet kan meten), EN, dit gebeurd alle dagen tussen 13h en 15H, ervoor en erna NIKS van last.
ik kan totaal niet thuisbrengen wat het rebooten kan triggeren in de namiddag.

temperatuur van de rpi3 is nu 33,6°C

9 april: reboot 15:48
10april: reboot 14h42
11april: reboot 14h35
12april: reboot 13h04, 13h21 en 13h32 en dan nog eens om 15h32 waardbij alles onderuit ging en niks meer meete
13april: uit sinds dag ervoor

nu manueel reboot en logged weer pulsen sinds 17h.
deze rpi is tevens ook mijn VPN server waar i nu op inlog vanuit spanje. je moet wel iets doen als het hier regent :-)

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

Ik vermoed dat de 12V onderuit gaat.

De undervoltage detect staat "strak" afgesteld. De pi1 heb ik een keer gemeten: Die werkt zelf prima tot een volt of 2.7. Ethernet valt uit onder de 3V. en USB officieel onder de 4.5V of zoiets (op de host computer hoor je zelfs significant meer dan 4.5 te hebben). Als je USB cameras het blijven doen, dan is de undervoltage, mits beperkt tot "niet te veel onder de 4.6" niet zo'n probleem.

Maar je hebt wel een probleem. Dus ik denk dat ie soms VEEL dieper inzakt dan wat ie kan loggen.....

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

Nu de rest van de avond is alles blijven werken, ook mijn vpn.

Die 12v voedt ook mijn rpi4 achteraan, waar de volgende 2 cameras op zitten, die heeft niks van last. Vooraan had ik 3 cameras zitten waar ik er vorige week dan ook 1 uit trok om het verbruik op usb te beperken (vandaar het 5de grijze beeld met geen signaal). Maar ook dat heeft geen invloed. De 12v voeding is 4,5 of 5A waar 2 rpi's op draaien met dc converters, de ene rechtstreeks, de andere met 20meter utp tussen.

De vraag is ook, waarom werkt alles van 16h tot 13h de dag erop, en zit je met die 2-3 uurtjes namiddag met ellende. Er draaien geen scripts meer bij. Het enige is dat het warmer is in de namiddag.
vanmiddag was de rpi 33 graden, nu geeft die 42graden op, de zero staat op 22.8 graden nu.

Als ik volgende week terug ben zal ik die eens op een aparte usb voeding hangen, als dat werkt, wat bufferelcos op de 12 en 5v toevoegen.
Begin eerder een 'storing' te vermoeden die hem onderuit haalt. Het is ook niet de kwh meter want de piek in zonnenstroom is vroeger tusse 11 en 12h

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

Vandaag iets na 14h weer uitgevallen(wintertijd).
Rpi3 42,8graden
Rpi zero 36.8
Daar ligt het dus niet aan

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

Golden Member

Heb je niks in huis waarmee je de voedingsspanning, direct op de Pi zelf dus, kunt monitoren?

Don't Panic!

Je zult toch wel kunnen zien of er een Brown-out is geweest?

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

Op 14 april 2022 17:19:32 schreef Hensz:
Heb je niks in huis waarmee je de voedingsspanning, direct op de Pi zelf dus, kunt monitoren?

De rpi kan dus blijkbaar wel meten dat de spanning te laag komt, maar heeft geen dac. Vind ook nergens een systeem commando te vinden om te cpu spanning te zien.
Ik kan niks doen want zit 1300km verder :-)

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

Spanning hoef je ook niet te zien, er is bij bijna alle processoren een brown-out alarm/reset (spanning komt onder Vccmin)

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

als de rpi reboot, zie ik dat toch niet meer?
alsik nu kijk naar dmesg heeft die 5 fouten gegeven van undervoltage, maar is er niet op reboot.
als ik morgenvroeg kijk in de voormiddag, zal er niks veranderd zijn, en tegen 15h namiddag, is die reboot

die is rond 14h reboot,
na 45sec dus nog eens undervoltage
na 165sec nog eens (2,5min later)
na 3700 nog eens (61min)
na 4300 nog eens (71min)
na 4900 nog eens (81min)
en nu al 5uur NIKS van problemen

en je zal zien dat die tot morgen namiddag geen ellende geeft

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