Pulsvermenigvuldiging

@Mel, heb je hiervan een schema? ik zou het ook niet kunnen zonder controller en ben trouwens heel geïnteresseerd in een oplossing met een pll.

LDmicro user.
fatbeard

Honourable Member

Op 12 juni 2019 07:25:53 schreef mel:
Een landbouwtraktor gaat ook niet zo gek hard..Gewoon een PLL met een 4046 en een delertje er achter, dat is geen rakettechnologie.Is in een half uurtje gemaakt,en als je die deler dan ook nog kan instellen met dip switches of zo, kan je veel verhoudingen aan.
Beter dan arduinozooi (vind ik).

Tja... Een PLL mag dan geen rakettechnologie zijn, eentje met een holdbereik* van 1:80 is zeker niet triviaal.

* Jazeker, hold bereik. Het gaat over een tractor, die begint altijd vanuit stilstand...
Dus als de PLL een vangbereik heeft van zeg 2-20Hz (is ook niet ècht eenvoudig) zal het locken wel goed gaan, het is alleen verre van triviaal om die lock vast te houden tot 1.6kHz...
Ook ik ben reuze benieuwd naar een schema wat dat kan...

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.
EricP

mét CE

Op 12 juni 2019 09:51:57 schreef mel:
Waarom moet het nou altijd met die stomme software?

Omdat dat in deze context veel en veel eenvoudiger is.

Ik hou het gewoon op een schakeling die simpel is, en wat iedereen begrijpt.

Nou ja, wat is er simpeler dan 1 chippie? De evt. level shifts heb je toch, of je het nou in hardware of in software doet...

Niet iedereen is natuurlijk een softwaregoeroe..

Dat hoeft hiervoor ook niet. Dit is dusdanig triviaal dat iedereen die de hardware (timers) snapt het in een paar regels maakt. Er zit geen enkel algoritme achter behalve een deling (van de periode tijd). Zelfs de clock van de betreffende AVR is niet van belang...

Op 11 juni 2019 23:11:41 schreef Jaap86:
en dit is het enige tandwiel waar ik de sensor op kan zetten. Terug veranderen is geen optie

Je zou natuurlijk ergens een nieuw tandwiel kunnen plaatsen, alleen voor de sensor; dat hoeft niet meer dan zijn dan een stukje gesneden plaatstaal.

Ik kan een kalibratie van de snelheid uitvoeren, maar omdat ik al grotere wielen heb en daarmee ook een lagere omtreksnelheid van het tandwiel, kan ik niet in het meetbereik van de software komen

In dat geval kan het wellicht simpeler; weet je wat het meetbereik van de software is? Wellicht is er een verhouding die eenvoudiger is dan 1.25 en wel binnen het meetbereik valt.

Op 12 juni 2019 09:51:57 schreef mel:
Waarom moet het nou altijd met die stomme software?

Omdat het veel simpeler is, veel minder onderdelen bevat, en sommige van ons wel snappen hoe software werkt. Ga je nu echt beweren dat een phase-locked loop eenvoudiger is dan een paar regels software?!?

De code van REW is voor bijna iedereen met een heel klein beetje software ervaring in een paar seconden te begrijpen, terwijl ik dat schema van Fatbeard zou moeten napluizen, met pen en papier om de logica te bevatten, en te beoordelen of het correct is.

[Bericht gewijzigd door SparkyGSX op 12 juni 2019 13:45:37 (11%)]

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
fatbeard

Honourable Member

Als een factor 2 ook goed is, kun je af met alleen de flankdetector (4093 en R/C).

Los daarvan, ik heb een klein foutje gemaakt :o : de CLK ingang van de tweede flipflop moet aan de Q uitgang van de eerste zitten.
Zoals getekend levert de schakeling 6 pulsen per 4 input pulsen...

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.

Op 12 juni 2019 07:25:53 schreef mel:
Een landbouwtraktor gaat ook niet zo gek hard..Gewoon een PLL met een 4046 en een delertje er achter, dat is geen rakettechnologie.Is in een half uurtje gemaakt,en als je die deler dan ook nog kan instellen met dip switches of zo, kan je veel verhoudingen aan.
Beter dan arduinozooi (vind ik).

Klinkt voor mij toch een beetje als rakettechnologie :)

Je zou natuurlijk ergens een nieuw tandwiel kunnen plaatsen, alleen voor de sensor; dat hoeft niet meer dan zijn dan een stukje gesneden plaatstaal.

Intern kan ik nergens een tandwiel plaatsen, en extern een tandwiel vraagt om problemen met het gewas. Deze kan daar na omheen wikkelen

In dat geval kan het wellicht simpeler; weet je wat het meetbereik van de software is? Wellicht is er een verhouding die eenvoudiger is dan 1.25 en wel binnen het meetbereik valt.

In de software kan ik een waarde tot 530 ingeven en ik moet eigenlijk op 663 uitkomen (vandaar x1,25). Ik weet op dit moment alleen de maximale waarde die ik kan ingeven, minimaal kan ik niet zeggen. Misschien mag het ook x1,5 zijn als dat makkelijker is??

EricP

mét CE

Als je het met een AVR oplost, dan maakt die correctiefactor niks uit.

530 is een raar getal. 511 (of desnoods 512) had ik nog wel gesnapt... Maar als jij het zegt...

Waar iedereen aan voorbij lijkt te gaan is dat er ook nog wat interfacing naar de sensor gedaan zal moeten worden.
Waarop ik dan meteen denk... als die sensor per ongeluk een open collector (zo je wilt: open drain) uitgang heeft... Waarom dan niet een 2de sensor erbij knutselen en het deeltal aanpassen? Een vermenigvuldiging van '2' is wellicht ook haalbaar... Ergens een datasheet van die sensor te vinden?

Op 11 juni 2019 16:58:21 schreef Jaap86:
...
En omdat ik geen ervaring heb met de componenten om zoiets te maken kom ik niet bij het juist uit denk ik.

Op 12 juni 2019 15:29:14 schreef EricP:
Als je het met een AVR oplost..

Moeilijk als je geen ervaring hebt met componenten :?

LDmicro user.

Op 12 juni 2019 15:01:26 schreef Jaap86:
In de software kan ik een waarde tot 530 ingeven en ik moet eigenlijk op 663 uitkomen (vandaar x1,25). Ik weet op dit moment alleen de maximale waarde die ik kan ingeven, minimaal kan ik niet zeggen. Misschien mag het ook x1,5 zijn als dat makkelijker is??

x2 is veel eenvoudiger; zoals Fatbeard ook al zegt, je kunt dan simpelweg op elke flank een pulsje maken. Als je 332 kunt invullen (de helft van 663 met afronding omhoog), zou je goed uit moeten komen.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

Op 12 juni 2019 09:51:57 schreef mel:
Waarom moet het nou altijd met die stomme software?

Omdat het nou eenmaal veel betere oplossingen geeft. Met jouw PLL kun je maar een paar deeltallen maken, en achter de komma wordt het al lastig. In firmware is dat een eitje en ben je ook nog eens flexibel als het net een beetje anders moet. Of als het volgend jaar een beetje anders moet.
Beetje met de tijd meegaan mel, zo eng is het allemaal niet :-)
[edit] spuit11, we waren al een pagina verder. :-)

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

Golden Member

Ik ben al een ouwe l*l he, en een hardwareman :P

u=ir betekent niet :U bent ingenieur..

Mel, ik kan wel met je meevoelen. Ik zoek ook altijd naar hardware oplossingen. En degenen die roepen dat het met software zoveel makkelijker is vergeten gemakshalve het leertraject waar een beginner in deze materie eerst doorheen moet.

Ik zou het oplossen met een teller die met de pulsen mee tot 4 telt en dan bij de reset zelf de vijfde puls genereert.
Het enige probleem wat ik dan zie is dat bij de hoogste snelheid de opvolgingstijd tussen de pulsen te kort wordt. Als het verwerkende apparaat de normale pulssnelheid maar net aan kan zou het kunnen dat het zich in die extra tussengevoegde puls verslikt.

Het is nog nooit zo gemakkelijk geweest om met embedded software te beginnen als nu. Als je het altijd maar blijft uitstellen "want moeilijk", zal het ook altijd moeilijk blijven. Waarom kun je niet proberen in te zien dat het een wereld aan nieuwe mogelijkheden opent, en daar enthousiast over zijn?

Natuurlijk moet je ook niet elk probleem met software willen oplossen, maar het zou één van de gereedschappen in je kist kunnen zijn, zodat je voor een gegeven probleem de juist combinatie van tools kunt kiezen.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

Als je het in hardware wilt, kan het met een F/V en V/F converter, bijv. de LM331 en LM2907...

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com
EricP

mét CE

Ik zoek ook altijd naar hardware oplossingen. En degenen die roepen dat het met software zoveel makkelijker is vergeten gemakshalve het leertraject waar een beginner in deze materie eerst doorheen moet.

Je bedoelt... het leertraject in hardware is veel simpeler of korter? :+

Ik snap je wel. Echter... 'in hardware' heeft inmiddels steeds minder voordelen (en steeds meer nadelen). Een voordeel kan 'snelheid' zijn - iets in hardware is vaak sneller dan iets in software. Maar dat moet je maar nodig hebben. Een ander voordeel kan 'repareren' zijn. Een hand poortjes kan iedereen repareren, al is het maar blind de chippies vervangen en zeggen 'kijk, doet het weer'. Een voordeel kan zijn dat het makkelijker met een ruimer voedingsbereik overweg kan - een controller wil vaak toch wel 3V3 of 5V zien. Terwijl er best wel wat hardware poortjes zijn die het op een ruim bereik doen.
Maar het moet in jouw project wel een 'voordeel' zijn.

Verder heb ik voor wat niche-market dingetjes ook wel wat hardware oplossingen verzonnen, waarbij je dan zegt... Waarom niet in software? Nou, simpel... makkelijker met reviews en 'certificering' (want hey, het gaat er niet om of het werkt, het gaat erom dat er papier bij zit!). Het had in 1 8-potige AVR gekund, maar ja... 5 chippies met poortjes levert meer ontwikkeltijd en minder discussie op. Discussie is duurder. Dus doe het maar discreet...

En waar we nog steeds aan voorbij gaan, is de interfacing - zowel in de hardware als in de software oplossingen...

Dat softwareoplossingen vaak een slechte naam krijgen, komt ook doordat de software soms slecht in mekaar steekt.

Zoals bij het huidige geval, een frequentie van 17...1550Hz.
Veel softwaremakers houden dan geen rekening met waardes die daarbuiten vallen. ("dat komt toch nooit voor")
Maar waardes <17 en > 1550Hz zul je toch ook netjes moeten afvangen. (vaak gaat firmware dan 'rare' dingen doen...)

Arco - "Simplicity is a prerequisite for reliability" - www.arcovox.com

Arco, ik had van u toch verwacht dat je de softwareoplossing in het voordeel zou doen kantelen ;)
Maar na 40 reply's is er nog geen realistisch schema/ontwerp uit de bus gekomen en dan maak het niet meer uit denk ik.

LDmicro user.
EricP

mét CE

Een schema gaat er ook niet komen. Zolang er niks over de 'sensor' bekend is, is het ook niet zo zinnig om wat te maken - software, hardware of iets ertussen.

Maar ja, ook daar stapt iedereen al 2 pagina's overheen...

Op 13 juni 2019 07:42:21 schreef mel:
Ik ben al een ouwe l*l he, en een hardwareman :P

Jij vroeg je toch hardop af "waarom het altijd met die stomme software" moet. Daar lees ik in dat je het een slechte zaak vindt om het in software te doen. Maar nu zeg je dat het gewoon aan jezelf ligt, en dat de software oplossing toch wel beter is?

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

Honourable Member

Looks familiar? >:)
Werkt vanaf 3 tot en met 18V (afhankelijk van het merk).
Één puls in, twee pulsen uit.
De rest is het instellen van de snelheidsmeter...

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.

Op 13 juni 2019 13:26:26 schreef EricP:
[...]Je bedoelt... het leertraject in hardware is veel simpeler of korter? :+

Nee, dat bedoel ik niet. Ik bedoel dat ik het leertraject van de hardware al achter de rug heb, hoewel je natuurlijk nooit uitgeleerd bent.
Ooit heb ik een cursus gevolgd, programmeren in machinetaal. Dat stond me eigenlijk wel aan, je vult een code in en je ziet gelijk het effect. Nu programmeer je in een of andere hogere taal en een compiler of hoe zoiets mag heten vertaalt het naar machinetaal. Maar hoe dat resultaat er dan uitziet, dat blijft verborgen en dat maakt het voor mij minder grijpbaar.
En verder ben ik net als Mel een ouwe l*l, laat mij maar gewoon stoeien met techniek die ik beheers.

EricP

mét CE

[...]Nee, dat bedoel ik niet. Ik bedoel dat ik het leertraject van de hardware al achter de rug heb, hoewel je natuurlijk nooit uitgeleerd bent.

Ik heb dat traject ook deels achter de rug. Maar kwam er al snel achter dat iets wat 'programmeerbaar' is in zeg 80% van de gevallen de ontwikkeltijd decimeert. En ja, het brengt andere problemen met zich mee. Zonder meer waar. (en eh... om er maar eens eentje te noemen... als je nooit met hardware gestoeid hebt, dan lijkt de praktijk uit te wijzen dat het met firmware programmeren ook nooit wat gaat worden, uitzonderingen daar gelaten).

Ooit heb ik een cursus gevolgd, programmeren in machinetaal. Dat stond me eigenlijk wel aan, je vult een code in en je ziet gelijk het effect. Nu programmeer je in een of andere hogere taal en een compiler of hoe zoiets mag heten vertaalt het naar machinetaal. Maar hoe dat resultaat er dan uitziet, dat blijft verborgen en dat maakt het voor mij minder grijpbaar.

Wat in assembly de assembler heet... heet in C 'compiler'. Geef het beest een naam. Verder is op een AVR C niet zo heel veel anders dan assembly. Maar het maakt het leven makkelijker. In de zin van: ik hoef er niet over na te denken of ik een 16 bit ADD moet doen (of een 32 bit...), maar dat doet de compiler voor mij. Wat die compiler doet is echt geen 'black magic', meestal is een niet meer dan een set handige trucjes voor veel voorkomende situaties die men dan een andere taal noemt.
Daarnaast heb je bij een compiler vaak een soort van 'run time lib': verzamelingen van functies om een paar veel gebruikte algoritmen makkelijk te maken. Die HOEF je niet te gebruiken (maar iedereen doet het wel... dat heeft vast een reden, niet?).
En ook hier: als je nooit assembly geschreven hebt, dan gaat het in C meestal ook niks worden...

En verder ben ik net als Mel een ouwe l*l, laat mij maar gewoon stoeien met techniek die ik beheers.

Deels snap ik dat wel hoor. En in dat gebied denk ik dat je zomaar rondjes om 95% van de gebruikers hier heen rent. Niet elke verandering is een verbetering. Maar elke verbetering is wel een verandering... :+

Verder hoop ik - in de context van het schema van fatbeard - dat de 'meter' aan boord pulsen in een 'gate tijd' telt. Als het ding tijd tussen pulsen telt, dan kun je nog hopen dat er wat gemiddeld wordt (dat zal haast wel om de uitlezing 'rustig te krijgen), anders ga je op die manier natuurlijk hopeloos de mist in. Maar inderdaad, simpel en elegant. Als die factor ook 2 mag zijn...

Mocht je op "2x" willen overstappen, dan kan dezelfde hardware dat ook als je voor de "arduino oplossing zou hebben gekozen".

code:


void loop (void)
{
  static unsigned char old();
  if (digitalRead (THEINPUTPIN) != old) {
    old = !old;
    digitalWrite (THEOUTPUTPIN, 1);
    delay_us (1);
    digitalWrite (THEOUTPUTPIN, 0);
  }
}
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
mel

Golden Member

En ja. assembler programmeren lukt me ook vrij goed :P
PLC ook nog, maar "C" snap ik de ballen van. ;)

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

mét CE

En ja. assembler programmeren lukt me ook vrij goed :P

Wow. Ik heb nog nooit een assembler geprogrammeerd. Of bedoel je assembly? :+

PLC ook nog, maar "C" snap ik de ballen van. ;)

Terwijl C toch een hele simpele taal is...