Troubleshooten vreemd probleem custom pcb RF69

[fommes]

Beste Medetweakers,

Ik zit met een probleem en hoop dat iemand me kan vertellen hoe ik dit het beste kan gaan troubleshooten

wat achtergrondinfo:

een ontwerp van m'n pcb

Ik heb een tijdje geleden 50 custom pcb's laten maken, deze hebben onder andere een atmega VL53L0X en een rf69hcw aan boord.

Ik gebruik deze om data te versturen naar een basisstation, die het vervolgens via internet naar een webservice post.

De flow ziet er ongeveer zo uit:
- sensor stuurt metingdata naar basis station
- Basis station antwoord met het aantal sleepcycles dat de sensor moet gaan uitvoeren alvorens hij weer gaat meten en verwerkt daarna pas de ontvangen data.
- sensor gaat in powerdown modus (en dit herhaalt hij totdat hij het aantal sleepcycles heeft behaalt)

Van de 50 pcbs heb ik er nu 16 compleet gemaakt (antenne gesoldeert, fuses geset, bootloader geburned, sketch geupload).

Bij het testen is me opgevallen dat de helft niet helemaal correct werkt, en de andere helft wel helemaal correct werkt.

Bij de defecte nodes gaat het verzenden van de metingen goed, het ontvangen van de reply van het basistation niet.

Het vreemde is, dat bij de probleemgevallen het ontvangen van een reply alleen niet werkt wanneer ik batterijen gebruik (2x AA of 2x AAA), via de FTDI connector gaat het wel goed..


De code waarbij hij dus een timeout geeft bij de defecte pcbs

code:

if (rf69.waitAvailableTimeout(500))
  {
    // Should be a reply message for us now
    if (rf69.recv(buf, &len))
    {
 
      sleepCycles = buf[0] <<8;
      sleepCycles |= buf[1];
      blinkLed(1, 200);
    
    }
  }
  else
  {
    blinkLed(4, 50);
   //Timeout? try again in 15 minutes 
  }

ik heb geprobeerd de timeout op 2000 te zetten, zonder resultaat.
Kwa uiterlijk zien ze er goed uit
Ik heb ook met een multimeter de resitors en capacitors gemeten en vergeleken met een werkend bordje, deze lijken allemaal in orde te zijn en een vergelijkbare waarde te hebben.

hoe zou ik dit het beste verder kunnen troubleshooten?

[ Voor 3% gewijzigd door fommes op 20-04-2017 15:25 ]

[memphis]

Het vreemde is, dat bij de probleemgevallen het ontvangen van een reply alleen niet werkt wanneer ik batterijen gebruik (2x AA of 2x AAA), via de FTDI connector gaat het wel goed..

Dus moet je het in de voeding zoeken......

Als eerste valt mij op dat je rondom U1 wel condensatoren van 100nF hebt zitten maar geen elkco, plaats over een condensator ook eens een elko van 47 of 100uF, Overigens zie ik in je schema maar 2x een elko van 10uF, dat lijkt mij ook erg weinig....
Misschien moet je er eens een scoop aan hangen om te zien hoe stabiel je voeding is.

[fommes]

C5, C6, C9 en C10 zijn 10uF, ik ga van het weekend de stabiliteit can de voeding bekijken, Het vreemde is dat ze verder stabiel draaien, verzenden werkt probleemloos, alleen het ontvangen van de reply gaat fout.

Het valt me op dat wanneer ik de FTDI gebruikt heb de batterij het ook tijdelijk doet, net of er een condensator opgeladen is en get geheel stabieler maakt.

Ik had een 5tal test pcb's besteld die probleemloos werkten, enige verschil is dat ik op het laatste moment de RF69HW vervangen heb met de RF69HCW, misschien gebruiken die dan toch meer dan ik geanticipeerd had..

Ik laat weten wat er uit de scoop meting komt

[Ploink]

Het kan zijn dat je DCDC converter als stoorzender werkt, misschien via de voeding die niet stabiel genoeg is, misschien via L1 die een sterk wisselend magneetveld uitstraalt.

In het ene geval, plak nog eens een paar 10uF caps bovenop C8 om dat te testen.
In het andere geval, er bestaan spoeltjes die geheel magnetisch zijn afgeschermd, probeer die eens.

De frequentie van de DCDC zit rond de 500kHz en dat kan behoorlijk storen, maar je kan ook meer laagfrequente storing krijgen door de PFM mode als je onder de PFM/PWM threshold zit, dit geeft een ruim 100mVpp rimpel op je voeding volgens figuur 2-18 in de datasheet. Voeg eventueel een load weerstand toe om er boven te komen zodat je kan testen zonder deze rimpel.

[ Voor 7% gewijzigd door Ploink op 20-04-2017 18:49 ]

[fommes]

Thanks voor je tips, ik heb m'n laptop met de datasheet niet bij de hand, volgens mij was het een magnetisch afgeschermde spoel, ik ga met je andere adviezen aan de slag, en laat het weten als ik meer weet, bedankt

[memphis]

fommes schreef op donderdag 20 april 2017 @ 18:43:
C5, C6, C9 en C10 zijn 10uF,

C5 zit primair aan de voeding dus die mag je niet mee tellen. Maar als ik het ontwerp bekijk heb je bij de processor geen elco zitten, soldeer over C12 en C7 (mits dicht bij de processor) ook een elko voor een betere stabiliteit bij de processor.

[fommes]

Hier nog ter aanvulling een foto van de pcb (met een RF69HW maar verder identiek)

https://imgur.com/gallery/Sl4sy

[DavidZH]

De RFM trekt bij het zenden behoorlijk veel stroom, dus je moet een goede buffer hebben zo dicht mogelijk bij de voedingsaansluiting van de module. Net zoals alle bovenstaande reacties al zeiden. Ik heb op mijn eigen PCBs een SMD elco van 47µF op enkele mm van de voedingsaansluiting zitten en heb eigenlijk nog geen problemen ondervonden (al zijn dat er nog lang geen 50...).

En het is jammer dat de TOF-sensor een minimumvoeding van 2,6V nodig heeft, anders had je de boost-converter kunnen laten vallen. De RFM en ATmega werken prima tot ongeveer 1,8 á 2,0V. Ik heb ze zelf nooit gebruikt, maar op het MySensors forum zijn er toch een aantal lieden na die het een ander doorgerekend te hebben vertellen dat zo'n constructie niet langer meegaat als zonder boost. En het introduceert zeker vuiligheid op de lijn.

Mooie printjes btw!

[fommes]

Thanks

Ik heb even overlegt met de ontwikkelaar van de talk2 whisper nodes, die me geholpen heeft met het ontwerpen van deze bordjes, ook hij heeft nog wat punten doorgegeven die ik kan checken, ik zal volgende week alle adviezen nalopen, en wat metingen verrichten, hopelijk kom ik hiermee tot een conclusie.

ondertussen lopen de helft van de bordjes die het wel goed doen al 7 dagen probleemloos ieder kwartier een meting door te sturen (en in de nacht 8 uur geen meting omdat er dan geen veranderingen zijn), zonder dat er één vreemd doet

Ik heb bewust de pcbs en m'n laptop op kantoor laten liggen omdat ik anders weet dat ik hier het hele weekend tot diep in de nacht mee bezig ben, ik heb er nu al spijt van

Bedankt voor het meedenken, ik houd jullie op de hoogte.

[ Voor 17% gewijzigd door fommes op 21-04-2017 22:53 ]

[TommyboyNL]

Bij het debuggen van dit issue moet je eigenlijk een logic analyzer aan je SPI bus hangen, zodat je kan zien wat er daadwerkelijk overheen gaat. Je kan kijken naar een saleae kloon als je een kleine beurs hebt, dan ben je onder de €10 klaar.

PCBs laten maken bij Eurocircuits?

[ Voor 7% gewijzigd door TommyboyNL op 21-04-2017 23:33 ]

[fommes]

dat is ook wel een idee, misschien krijg ik uit de spi bus meer info dan uit de serial port.. ik ga zo'n saleae bestellen bedankt.

Ik heb de pcbs bij proto-service laten maken.

[fommes]

Ik heb het werk even een weekje of 2 moeten laten liggen wegens andere prioriteiten.

Ondertussen heb ik de saleae binnen, en ben ik aan het proberen de spi data te interpreteren.

Ik heb de analoge input van de logic4 gebruikt om de stabiliteit van de 3.3v rail te bekijken (zowel op de rfm module, als bij de atmega), deze blijft tussen de 3.1v en 3.2v, dus de stabiliteit van de pcb lijkt in ieder geval in orde..

Als ik meer ontdekt heb laat ik het weten.

[Ploink]

Als de DCDC onder de PWM treshold zit en dus in PFM mode werkt dan klappert de voeding 100mV op en neer. Tussen de 3.1 en 3.2V kun je dus een 100mV rimpel hebben en dat is niet echt geweldig.

Heeft de RF69 module nog een eigen spanningsregelaar? Staat er iets over de eisen aan de stabiliteit of rimpel van de voeding in de datasheet?

Die spoel L1 op je PCB ziet er niet magnetisch afgeschermd uit, maar kan het niet goed zien op de foto.

Op deze afbeelding zijn de spoelen waar je het koper kan zien zoals de 331 onderaan niet afgeschermd, de spoelen die helemaal zijn omhuld door ferriet zoals die links midden waar 510 op staat zijn wel afgeschermd.


Edit: Ik zie een groundplane op je PCB, maar nergens via's. Zeker in RF designs is het gebruikelijk om via's rond te strooien om de alle massavlakjes zo grondig mogelijk met elkaar te verbinden. Bij jou zie ik een verzameling schiereilandjes die nauwelijks met elkaar verbonden zijn. Bij sommigen twijfel ik of er uberhaupt een verbinding is met de andere eilandjes, maar misschien zie ik het niet goed.

[ Voor 21% gewijzigd door Ploink op 10-05-2017 21:08 ]

[fommes]

Ploink schreef op woensdag 10 mei 2017 @ 20:18:
Als de DCDC onder de PWM treshold zit en dus in PFM mode werkt dan klappert de voeding 100mV op en neer. Tussen de 3.1 en 3.2V kun je dus een 100mV rimpel hebben en dat is niet echt geweldig.

Heeft de RF69 module nog een eigen spanningsregelaar? Staat er iets over de eisen aan de stabiliteit of rimpel van de voeding in de datasheet?

Die spoel L1 op je PCB ziet er niet magnetisch afgeschermd uit, maar kan het niet goed zien op de foto.

Op deze afbeelding zijn de spoelen waar je het koper kan zien zoals de 331 onderaan niet afgeschermd, de spoelen die helemaal zijn omhuld door ferriet zoals die links midden waar 510 op staat zijn wel afgeschermd.
[afbeelding]

Edit: Ik zie een groundplane op je PCB, maar nergens via's. Zeker in RF designs is het gebruikelijk om via's rond te strooien om de alle massavlakjes zo grondig mogelijk met elkaar te verbinden. Bij jou zie ik een verzameling schiereilandjes die nauwelijks met elkaar verbonden zijn. Bij sommigen twijfel ik of er uberhaupt een verbinding is met de andere eilandjes, maar misschien zie ik het niet goed.

Als het de ripple zou zijn, dan zou ik die problemen op alle bordjes moeten hebben.

Sowieso blijft het vreemd dat verzenden helemaal goed gaat, en ook als ik één van de 'defecte' bordjes als ontvanger gebruik gaat het helemaal goed, alleen het verzenden van data en dan direct ontvangen van de response gaat bij een aantal van de bordjes verkeerd..

[ Voor 4% gewijzigd door fommes op 01-02-2018 17:36 ]

[Flake]

Ploink schreef op woensdag 10 mei 2017 @ 20:18:
Edit: Ik zie een groundplane op je PCB, maar nergens via's. Zeker in RF designs is het gebruikelijk om via's rond te strooien om de alle massavlakjes zo grondig mogelijk met elkaar te verbinden. Bij jou zie ik een verzameling schiereilandjes die nauwelijks met elkaar verbonden zijn. Bij sommigen twijfel ik of er uberhaupt een verbinding is met de andere eilandjes, maar misschien zie ik het niet goed.

Bullseye. RF is niet mijn sterkste kant maar je groundplane kan zeker beter. Ook de trace naar je antenne toe mag wel wat meer clearance hebben, tussen je trace en groundplane zit altijd wat parasitaire capaciteit en om die reden mag de clearance bij je antenne trace wel wat groter, en impedance matching.

fommes schreef op woensdag 10 mei 2017 @ 11:29:
Ik heb de analoge input van de logic4 gebruikt om de stabiliteit van de 3.3v rail te bekijken (zowel op de rfm module, als bij de atmega), deze blijft tussen de 3.1v en 3.2v, dus de stabiliteit van de pcb lijkt in ieder geval in orde..

Zo werkt dat niet. Op deze manier van meten weet je helemaal niks over de ruis of rimpel die op die lijn kan zitten.

[fommes]

Flake schreef op donderdag 11 mei 2017 @ 11:27:
[...]


Bullseye. RF is niet mijn sterkste kant maar je groundplane kan zeker beter. Ook de trace naar je antenne toe mag wel wat meer clearance hebben, tussen je trace en groundplane zit altijd wat parasitaire capaciteit en om die reden mag de clearance bij je antenne trace wel wat groter, en impedance matching.


[...]

Zo werkt dat niet. Op deze manier van meten weet je helemaal niks over de ruis of rimpel die op die lijn kan zitten.

Dit klinkt allemaal erg aannemelijk, en de genoemde zaken zal ik in de volgende bestelling zeker meenemen maar dit verklaart nog steeds dit verschijnsel niet. Ik denk toch eerder aan een hardware probleem, zoals gezegd werkt een groot deel van de pcb's wel, en als het ontwerp niet correct zou zijn werkt het gewoon niet. Ik ga verder op onderzoek uit..

[Flake]

fommes schreef op donderdag 11 mei 2017 @ 11:47:
[...]


Dit klinkt allemaal erg aannemelijk, en de genoemde zaken zal ik in de volgende bestelling zeker meenemen maar dit verklaart nog steeds dit verschijnsel niet. Ik denk toch eerder aan een hardware probleem, zoals gezegd werkt een groot deel van de pcb's wel, en als het ontwerp niet correct zou zijn werkt het gewoon niet. Ik ga verder op onderzoek uit..

Zo werkt het ook niet. Ieder component heeft toleranties, ook je PCB's, ze zullen allemaal net ietsjes anders zijn en die parasitaire capaciteit kan per PCB verschillen. Hetzelfde geldt voor een spoel, die hebben ook meestal iets van 5-10% tolerantie. Als zenden wel werkt maar ontvangen niet, dan denk ik dat je RF problemen hebt, en die kunnen overal vandaan komen. Maar een goede groundplane en antenne trace zijn wel essentieel.

[fommes]

Flake schreef op donderdag 11 mei 2017 @ 11:54:
[...]

Zo werkt het ook niet. Ieder component heeft toleranties, ook je PCB's, ze zullen allemaal net ietsjes anders zijn en die parasitaire capaciteit kan per PCB verschillen. Hetzelfde geldt voor een spoel, die hebben ook meestal iets van 5-10% tolerantie. Als zenden wel werkt maar ontvangen niet, dan denk ik dat je RF problemen hebt, en die kunnen overal vandaan komen. Maar een goede groundplane en antenne trace zijn wel essentieel.

Ik kan heel de dag berichten verzenden, en ik kan heel de dag berichten ontvangen, alleen na verzenden kan ik op de defecte bordjes niet direct een reply ontvangen.. Enfin, misschien moet ik gewoon een delay in bouwen na het verzenden, zodat eventuele ripples en vreemde overspraak de kans niet krijgt m'n bericht te vernachelen.. (ik ga vandaag het SPI verkeer eens bekijken, misschien crashed alleen de RF module na verzending, want de atmega blijft gewoon draaien ook na het niet ontvangen van de reply)

[_Mithrandir]

Wat je nog zou kunnen proberen is het zend vermogen van de rfm module op minimum te zetten.

Het probleem wat je omschrijft klink voor mij dat er 2 mogelijkheden zijn

1. De voedingsspanning word omlaag getrokken tijdens het zenden.
Of
2. De register settings van je rfm zijn niet goed, maar om dat te kunnen zien moet wel de register settings weten van zowel de sensor als die van het basisstation

[TommyboyNL]

Kan je eens een high-res foto uploaden van één van de bokkende bordjes en één van de goed werkende bordjes? Wellicht zelfs op de scanner gooien en op de hoogste resolutie scannen.
Waar woon je ongeveer? Wellicht kan iemand een tweede blik erop komen werpen (ik houd bijvoorbeeld wel van dit soort puzzeltjes). Onbewuste aannames kunnen soms je denkmethodiek zeer sterk beïnvloeden waardoor je bepaalde potentiële issues compleet negeert.

[Ploink]

fommes schreef op donderdag 11 mei 2017 @ 10:35:
[...]


Als het de ripple zou zijn, dan zou ik die problemen op alle bordjes moeten hebben.

Sowieso blijft het vreemd dat verzenden helemaal goed gaat, en ook als ik één van de 'defecte' bordjes als ontvanger gebruik gaat het helemaal goed, alleen het verzenden van data en dan direct ontvangen van de response gaat bij een aantal van de bordjes verkeerd..

@_Mithrandir brengt mij op een idee wat dit betreft.
Stel, je DCDC converter werk in PFM mode. Je zend een pakket data en door het stroomverbruik zakt je voeding tot onder de hysterese grens, dan kickt de DCDC converter er in om je lijn weer op te pompen tot boven de hysterese. Als deze DCDC converter burst samenvalt met het moment van ontvangen, dan wordt dit gestoord. Strooiveld van L1 zou de oorzaak kunnen zijn, maar ook de slechte ground.
Als workaround kun je de tijd tussen zenden en ontvangen verlengen.

Ter aanvulling hier nog de gerber file
http://demo.tom-it.nl/gerber.pdf

Ik zie daar een probleem met de ground. Je hebt eerst ground traces gemaakt en achteraf een groundplane gemaakt. Normaal zouden die traces dan moeten verdrinken in die flood fill, maar dat gebeurt bij jou niet. Er lopen overal GND traces geisoleerd door je ground plane, maar ground pads zitten er wel aan vast met thermal reliefs.
Welke CAD software heb je gebruikt?

Verder raad ik aan ground via's (zonder thermal relief) rond te strooien en de groundplane clearance wat te vergroten.
De PCB is netjes gesoldeerd. Heb je die gebakken? In dat geval kun je overwegen om geen thermal reliefs toe te passen in SMD pads voor een nog betere ground.

[fommes]

Ik weet niet of ze gebakken zijn, ik heb ze laten produceren, ze zijn wel machinaal gemaakt, en niet met de hand.

Bedankt voor de toelichting, ik zal in de volgende bestelling zeker zorgen dat het ontwerp wat strakker wordt uitgewerkt, ik heb zelf geen pcb ontwerp software, ik heb alleen het technische ontwerp getekend, en iemand anders de gerberfile e.d. Laten uitwerken, en waar nodig laten verbeteren.

@TommyboyNL ik woon in zeeland, heb jij een oscilloscope misschien? Anders rij ik ook graag een keer jouw kant op als ik er niet uit kom komende week. (En als je dat ziet zitten uiteraard) de dichtsbijzijnde kennis met een scope woont in Zwitserland dus alles is dichterbij ik stuur je van de week nog wel een pb.

[memphis]

Oei, aardlusjes.....

[fommes]

Om voor deze sensoren in ieder geval het probleem (tijdelijk) op te lossen ga ik niet meer wachten op de reply, ik ga gewoon direct na verzenden data in slaapmodus, dan laat ik de radio module in rx draaien. Ik zorg dan dat de sensor board periodiek (eens per uur oid) een wakeup burst ontvangt met config gegevens die hij nodig heeft.

Ik heb het net op een weigerend bordje getest, en dit lijkt goed te gaan, in listenmode gebruikt hij dan +/- 40uA, kijken of ik dat nog om laag kan krijgen.

Bijkomend voordeel hiervan is dat ik altijd bij de sensoren kan, en niet hoef te wachten tot hij mij weer eens een berichtje stuurt.

Ik ga de functionaliteit verder uitwerken en dan een 10tal sensoren laten draaien, om te kijken of het geen problemen oplevert.

[Flake]

Mijn tip voor een goed groundvlak is om te proberen om te visualiseren hoe de stroom terug kan lopen vanaf een component door het groundvlak terug naar de voeding. Het liefst wil je die stromen zo min mogelijk laten kruisen door het groundvlak. Alles loopt tenslotte van + naar -. Als je dat doet, dan valt me nog wel wat meer op.


Ik weet niet wat die chip op dat nokje is, maar de route terug naar de voeding heb ik er even op getekend en dat is een aardig nauwe route waar volgens mij aardig wat stromen doorlopen.
Op de tweede afbeelding kun je zien dat de groundstroom voor zowel de MCU als RF69 tussen die landingplanes van dat dochterbordje mag lopen. Dat is vrij akelig. Het liefst zou je willen dat de retourstromen van de RF69 en de MCU elkaar niet kruisen, en dat doen ze nu wel.

Die omcircelde via zou je op je bottomplane eens moeten volgen. Op de bottomplane heb je ook behoorlijk wat groundvlak zitten, maar met de traces die je daar hebt getrokken creëer je daar wel een aantal vernauwingen in die helemaal niet nodig zijn.

Wat voor training heb je gehad in PCB design? Misschien zou je iemand moeten zoeken die jouw pcb's kan verifiëren voordat je ze laat produceren, want dit is vrij zonde van je geld als ik heel eerlijk ben.

[fommes]

Thanks voor de tips, zoals gezegd ik heb alleen een schematische tekening gemaakt, ik kan geen pcb's ontwerpen en dacht het aan iemand overgelaten te hebben die er verstand van had maar helaas, Naja er is geen man over boord want ze werken wel, alleen begrijp ik uit al jullie reacties dat dit een stuk netter opgezet kan worden.

deze 50 worden als testpilot ingezet, ik zal bij de volgende productie zorgen een andere ontwerper er naar te laten kijken (mochten jullie nog bedrijven kennen die dit kunnen hoor ik het graag)

[_Mithrandir]

fommes schreef op vrijdag 12 mei 2017 @ 12:47:
Om voor deze sensoren in ieder geval het probleem (tijdelijk) op te lossen ga ik niet meer wachten op de reply, ik ga gewoon direct na verzenden data in slaapmodus, dan laat ik de radio module in rx draaien. Ik zorg dan dat de sensor board periodiek (eens per uur oid) een wakeup burst ontvangt met config gegevens die hij nodig heeft.

Ik heb het net op een weigerend bordje getest, en dit lijkt goed te gaan, in listenmode gebruikt hij dan +/- 40uA, kijken of ik dat nog om laag kan krijgen.

Bijkomend voordeel hiervan is dat ik altijd bij de sensoren kan, en niet hoef te wachten tot hij mij weer eens een berichtje stuurt.

Ik ga de functionaliteit verder uitwerken en dan een 10tal sensoren laten draaien, om te kijken of het geen problemen oplevert.

Voor mij klinkt het steeds meer naar een probleem waarbij de radiomodules rfm69 niet op de juiste manier word aangestuurd. Probeer is tussen het schakele naar verschillende modussen is een wachtlus in te voegen van 100 ms ofzo en kijk dan is wat dat doet