Motor stoort werking 433MHz ontvanger

Op 2 augustus 2015 12:58:15 schreef beest820:
Ik zou de MAX232 ook weg kunnen laten en het RCREG register van de PIC telkens inverteren als er een byte is ontvangen dan?

Dat gaat niet werken, tenzij je de hele UART zelf in software emuleert: een hardware UART moet een startbit zien van de correcte polariteit om te kunnen werken...
Een simpel transistor invertertrapje doet precies wat er nodig is.
De MAX232 is ook berucht om zijn EMC-gedrag, helemaal met de voedingsbaan zoals die nu loopt: eerst naar de MAX, dan pas naar de elko. Als je een MAX232 gebruikt moet dat echt andersom.

Als je een tweezijdige print gebruikt met de onderkant als massa zul je aanmerkelijk minder storing ondervinden: nu moet alle retourstroom van de motoren de hele print over en koppelt op die manier in op de voeding van de ontvanger en controller.
Voor een enkelzijdige print (eigenlijk altijd wel) is het beter om de grootste stroomafnemers (de motoren) fysiek zo dicht mogelijk bij het voedingspunt te zetten, en daar te zorgen voor voldoende capaciteit (100µF of meer). Als je dan ook de voedingsbanen als ster uitvoert (elke afnemer zijn eigen spoor) voorkom je allerhande wederzijdse beïnvloeding.

@MGP: In principe heb je daarmee (één ding tegelijk) volkomen gelijk, al kan het wel wat begrotelijk en/of tijdrovend worden om voor elke iteratie opnieuw een PCB te (laten) maken...

Op 2 augustus 2015 13:42:52 schreef fatbeard:
..al kan het wel wat begrotelijk en/of tijdrovend worden om voor elke iteratie opnieuw een PCB te (laten) maken...

Het is zelden van de eerste keer goed, al weet je heel veel

Hij heeft de pcb al, en met minime veranderingen toch een goed werkende schakeling bekomen is toch goed, vooral als je ervan geleerd hebt.

Een dikke draad van de accu min direct naar de motor driver min helpt ook (nu loopt dat door op sommige plaatsen zeer dunne baantjes)
De 7805 is hier ook niet op zijn plaats; de dropout is veel te hoog (~2V). Na de 1N4007 is er nog maar 6.6V of minder over.
Neem een LDO regelaar als de MIC29150-5.0...

Het werkt na een aantal aanpassingen al stukken beter. Alhoewel het stoorsignaal nog niet helemaal weg is is het al wel behoorlijk verminderd. Inmiddels zover dat met 4 motoren aangesloten 50% van de signalen goed binnenkomt. Aanpassingen tot nu toe:

- het bovenste spoor onderbroken en een apart draadje gelegd van de regelaar naar de + van de 100µF aan de 293
- de 334 condensator vervangen door een 10µF elco aan de regelaar
- de + van de motoren aangesloten voor de 1N4007
- de - van de motor drivers direct aangesloten op de - van de accu
- de MAX232 via de 1µf condensator naar +5V gelegd (had heel veel effect)

Het lijkt erop dat ik de PCB beter opnieuw kan ontwerpen (hij ziet er nu niet meer uit, en het ontwerp laat te wensen over). De kosten zijn niet heel hoog omdat ik die zelf maak, en vrijwel alles wat ik hiervoor gebruik relatief goedkoop vanuit Azië laat komen. Het is wel een hoop werk, maar dat geeft niet.. Bij mijn volgende bestelling laat ik meteen een aantal LDO regelaartjes komen. Kan zeker nog goed van pas komen.

Als het nieuwe PCB ontwerp klaar is, wat nog wel eventjes kan duren, zal ik deze posten om eventuele verbeterpunten door te kunnen voeren voordat alles weer opnieuw gemaakt kan worden

DC motoren maken een bak commutatie zooi.

Een paar ctjes van de motor aansluitingen naar het motorhuis willen dat wel oplossen, neem iets van 10nF oid.

Op 2 augustus 2015 23:07:04 schreef beest820:
Het lijkt erop dat ik de PCB beter opnieuw kan ontwerpen (hij ziet er nu niet meer uit, en het ontwerp laat te wensen over).

Als je toch gaat veranderen, zou ik eens kijken naar de voeding van je L293D, (en dan het voeding gedeelte voor je motoren, Pin_8 dus) je spoor loopt nu onder je pic door.

Daar komt veel rommel van af, en dat moet je uit de buurt van je controller zien te houden. En ik zou hier en daar toch noch wat meer 100nFjes plaatsen.

Aardvlak lijkt groot, maar er zitten een paar erg 'magere' doorgangen in (zie pijlen)...

Het is weer even geleden sinds mijn laatste post, maar heb nu eindelijk weer tijd gehad om met het ontwerp verder te gaan. Ik heb nog geprobeerd de veroorzaker van het stoorsignaal te vinden door een voor een mogelijke veroorzakers af te gaan, dit gaf echter geen goed resultaat. Daarom post ik even mijn nieuwe ontwerp zodat hopelijk deze print wel gaat lukken

De volgende punten zijn aangepast:
- Sporen verbeterd
- Meer ontstoring
- MAX232 vervangen door inverter
- Beter aardvlak
- 10nF Ctjes op de motoren
- 10uF Ctje voor spanningsregelaar (LDO regelaar heb ik nog niet)
- Grootste stroomafnemers zo dicht mogelijk bij de voeding (omringd door ontstoorleiding)

Hieronder staat het nieuwe ontwerp. Kan hieraan nog iets verbeterd worden??

Vandaag is de nieuwe print afgemaakt. Alleen werkt het weer net als voorheen. Nadat het eerste PWM signal ontvangen is komt er door storing niets (behalve storing van de motoren) meer binnen op de UART ingang omdat die constant wordt gestoord. Ikzelf nu ook zo'n beetje Welke grove fout zie ik nog over het hoofd?? (Het werkt alleen als ik de Tx antenne tegen de Rx antenne houdt)
Zal de enigste oplossing zijn om de motordrivers en voedingen op een apparte print te zetten, en de PIC controller met 433MHz ontvanger ook op een apparte print met 9v blok batterij??

Je zou dit kunnen proberen.

Hier staan wat filter methodes op, begin met de condensatoren op de motoren en kijk of het helpt.

Wat ook vaak helpt, is de bedrading naar je motoren twisten.

Kijk ook of je de besturing en de motor drivers apart kan voeden, uit verschillende bronnen dus.

Er zal toch echt wel wat schorten aan de schakeling...
Enige wat ik zo zie is dat je geen kristal gebruikt. Wel aan te raden (eigenlijk een 'must') met seriële communicatie.

Als vervolg op de vraag van Arco...

Op welke frequentie draait die pic en op welke baudrate staat de seriele verbinding?

Ik zal zo nog even naar de filters kijken. De draden naar de motor zijn ongeveer 6cm. Deze ga ik twisten en afschermen. Ik laat straks even weten wat dan het resultaat is.

De PIC draait op het interne Kristal @ 4MHz, en de Baudrate voor seriële communicatie is 9600 baud. Ik werk hier al een tijdje mee, en heb in andere projecten waar geen motoren worden gebruikt eigenlijk nooit problemen gehad. Als de communicatie bedraad is gaat 11500 baud zelfs prima. Dit heeft ook altijd zonder extern Kristal goed gewerkt. Als het interne Kristal niet accuraat genoeg is zouden de problemen toch vaker voor moeten komen?

Het vreemde in deze situatie is dat zonder motoren aangesloten alles prima werkt. Als ik een waarde zendt wordt deze goed ontvangen en uitgestuurd. Het lijkt mij dan het meest aannemelijk dat de motoren op een of andere manier een hoop ellende veroorzaken..

Pic heeft geen 'intern kristal'... (is een vrijlopende RC oscillator)
Als de frequentie erg afwijkt, zul je daar in een storende omgeving eerder last van hebben als in een 'rustige' omgeving.

Met een kristal van 4Mhz op 9600b zit je er al 7% naast.

Maw je mag er niet naar kijken of het gaat al fout.

En jij werkt met de onnauwkeurige RC oscillator, dat is normaal dat het fout gaat en je de antennes zo dicht bij elkaar moet plaatsen om enig signaal te kunnen detecteren.

Zie in de fig uit de datasheet, je kunt geen 9600b kiezen op 4Mhz

edit:

Op 21 september 2015 18:36:08 schreef beest820:
Ik werk hier al een tijdje mee, en heb in andere projecten waar geen motoren worden gebruikt eigenlijk nooit problemen gehad. Als de communicatie bedraad is gaat 11500 baud zelfs prima. Dit heeft ook altijd zonder extern Kristal goed gewerkt. Als het interne Kristal niet accuraat genoeg is zouden de problemen toch vaker voor moeten komen?

Chinezen werken ook zo, het werkt meer niet, dan wel

[Bericht gewijzigd door MGP op maandag 21 september 2015 19:14:44 (42%)

Nou, 7% is wel erg kras...
BRGH moet wel op '1' staan. En de afwijkingen van de oscillator komen er natuurlijk bij.

Op 21 september 2015 19:21:13 schreef Arco:
Nou, 7% is wel erg kras...

Mijn compiler doet nochtans heel moeilijk.

Je hebt BRGH wellicht op '0' staan?

Dan heb ik in deze storende omgeving geluk dat ik er zo een 4MHz Kristal en condensators op kan solderen Hoe kan ik nu het best berekenen welke condensators er in moeten?? Het lijkt mij voldoende om er in XT-mode een 4MHz Kristal in te zetten.

Uit de datasheet (blz 2-6) in onderstaande link haal ik dat 30pF voldoende moet zijn??
http://ww1.microchip.com/downloads/en/DeviceDoc/31002a.pdf
In de handleiding van PIC16F690 staat geen exacte waarde.

Dat er een error is bij de baudrate "los ik op" door in het vb.Net programma de baudrate aan te passen. Zo heb ik b.v. bij 11500 als baudrate weggeschreven 11100, en in het huidige programma 9615. Helaas kom ik er nu niet mee weg

@Arco, Dat weet ik niet, kan daar niets aan veranderen.
Kan enkel maar de Freq. en de baudrate ingeven.

Ik gebruik meestal 22pF. (de capaciteit van de printbaantjes komt er ook nog bij)
Bij de Mikrobasic compiler geef ik ook alleen de baudrate op, maar die rekent de boel wel goed uit:

Dan zal dat van u juister zijn.

Nog iets over die 433Mhz zendertjes, die kunnen maar max 4K data aan als dat van die goedkope spullen zijn.

Ik heb geen apparatuur die snel genoeg is om dit goed te kunnnen controleren, ik moet er dus helaas van uit gaan dat wat ik ingeef als baudrate in vb.net er ook zo uitkomt.. De zendertjes heb ik idd voor een paar dollar gekocht. Qua data valt het allemaal erg mee. Per keer dat ik zend worden er 2 x 6 bytes verstuurd, (2 x hetzelfde bericht achter elkaar met 50ms tussenpauze) na het zenden van de 2 x 6 bytes wordt er 150ms gewacht totdat er weer iets verzonden kan worden..

Dat heeft daar niks mee te maken, enkel de snelheid tussen 2 bits mag niet hoger zijn 4K en je zendt met 9K6, meer dan het dubbele.

edit: als je toch zo weinig data verzendt waarom geen lagere baudrate? 2400 of 1200 of nog lager?
Uw motor zal even rap reageren en de datatransmissie zal veel beter overkomen.

[Bericht gewijzigd door MGP op maandag 21 september 2015 20:51:55 (41%)

Baudrate in het VB programma altijd op een standaard baudrate laten staan. Niets is zo ergerlijk als een zelfverzonnen baudrate...
(En het is ook helemaal niet zeker wat VB daar mee doet)