Gathering of Tweakers

quote:

mauws79 schreef op dinsdag 04 maart 2008 @ 21:27:
Wat verloopt.. RTC of kristal? Ik heb inderdaad wel ontwerpen gezien zonder RTC
maar als het enigzins betaalbaar te doen is met een rtc lijkt me dat toch mooier.
(misschien zelfs met alarm en ander coole features). Heeft maxim niet zo'n standaard
ding hiervoor, ik meen er al eens iets over gelezen te hebben maar of die dingen ook
bij de standaard elec.boer verkrijgbaar zijn...

Ik kan me herinnneren dat sommige AVR's zelfs een speciale aansluiting hebben voor een klokkristal (32.768kHz). Deze kristallen zijn goed genoeg voor een simpele klok. Correct geprogrammeerd zal deze evenveel 'verlopen' als een normale alarmklok. Alleen met een DFC ontvanger kun je nog preciezer (met de ontvanger kun je je eigen kristal corrigeren en zelfs calibreren als je het goed aanpakt).

Of je kan een atoomklok bouwen/kopen maar die zijn nogal duur en lastig te gebruiken

Anyhow, met een microcontroller met een klokkristal kun je perfect een eigen alarmklok bouwen. Ik weet ook niet wat je voor ogen hebt met een 'RTC'. Een klokmodule oid. zal ook altijd een 32.768kHz kristal gebruiken. Er is dus geen voordeel uit het gebruik van zoiets te halen.

Ik dacht altijd dat een gewone alarmklok de 50Hz van de netstroom gebruikt (ik heb nog een alarmklok gehad die perfect nauwkeurig was zolang de stekker inzit, maar op batterij zeer zwaar voor/achter ging lopen).

Als ik me niet vergis moeten de elektriciteitsleveranciers zorgen dat die 50Hz over lange tijd gezien voldoende nauwkeurig is om een klok op te laten draaien. Op kortere termijn kan er wel schommeling van de frequentie zijn, maar uiteindelijk is alleen de lange termijn nauwkeurigheid belangrijk...

Dat kun je ook doen (en zelf in een microcontroller bouwen). Echter zal dit, volgens mij, meer afwijken dan een (goed) klokkristal.

Die 50Hz is echt maar een richtgetal. Als het net overbelast raakt zal die 50Hz dalen. En dan gaan ze niet even later teveel vermogen op het net gooien om dat te compenseren. Hang ook maar eens een scoop aan het net, dan zie je wat voor 'troep' daar allemaal op zit. (Ik heb iig nog nooit een sinus uit het stopcontact gezien.)

Dat de alarmklok die je had ging afwijken komt omdat het een slechte klok is, niet omdat kristallen slecht zijn. Die klok zal uberhaupt geen kristal gehad hebben. Mischien een keramische resonator of een RC opstellinkje. Maar die zijn behoorlijk onnauwkeurig en erg temperatuurgevoelig.

Ok lastig, op zich hebben beide alternatieven hun voor- en nadelen. Voor de rtc had ik zo'n
PCF8183 ding in gedachten, simpel met backup batterij te voorzien. voordelen van alarm op
interupt, nauwkeurigheid blijft dus hypothetisch, nadelen: duurdere oplossing, I2C werk, fout-
gevoeliger. Voordelen RTC in de AVR: goedkoper, gebruik van timer nadelen: 'extra werk'.
Ik heb inderdaad AVR's gezien die direct de timer konden gebruiken ( mega168 ofzo) . Maar
met een standaard tiny zou dit op de timer/input kunnen met crystal + 2 condensatortjes ?
Is er animo om te bekijken welke mogelijkheden er zijn voor een DIY ?

De 50Hz van het net is nauwkeuriger dan een kristal bij het gebruiken voor een klok. De leveranciers zijn zoals al gezegt verplicht om hier voor te zorgen. Dus mocht de frequentie even iets minder zijn dat zullen ze dus er voor zorgen dat het even later iets meer is.
Het meest naukeurig (en meest onpraktisch) is natuurlijk een klok die stil staat. Die geeft tenminste 2 of 1 keer per dag precies de goed tijd aan

Ik moet zeggen dat ik ooit een nixieklok voor iemand heb gemaakt, die na klooien met zo'n RTC chip omgebouwd is op 50hz, klok heeft nog nooit zo stabiel gelopen. Loopt gerust minstens een jaar zonder scheef te gaan.

Woei, jtag is gaaf De manier waarop je gewoon een hele chip als een marionet kan besturen is erg leuk. Het is alleen enigszins jammer dat 't wat traag gaat... weet er iemand hier misschien snellere jtag-units dan de standaard parallele poort wiggler-klonen? Ik heb hier nog wel een FT2232 liggen, maar ik geloof dat dingen daarmee opgebouwd 'slechts' 2 keer zo snel zijn, terwijl versnellingen tot 10 keer haalbaar zouden moeten wezen. Ik moet trouwens wel echt JTAG hebben, ik ben namelijk een bootloader voor Linux op mijn smartphone aan het bouwen dus ik heb nog niets aan handig OS oid draaien wat het flashen voor mij kan doen.

JTAG voor wat voor chip? Met FTDI chipjes kun je aardig bitbangen maar zo zullen die FT2232 dingen ook wel werken. Snelheid hangt dan grotendeels van de buffering af, als je losse bytes gaat sturen en ontvangen gaat het lang duren maar als je bijvoorbeeld een grote complete bitstream moet shiften via JTAG (zoals bij FPGA's vaak) kan je flink wat bitbang-bytes bufferen. Door het bitbangen wordt de effectieve snelheid natuurlijk wel 1/8e (8 bits tegelijk per byte).

He bah, m'n Clapper (jeweetwel, zo'n klapklaplampgaataan-ding ) is kapot.. max 200W, laptop van minder dan 90W erin geprikt maar nee hoor, psssj en dood is 'ie

R.I.P.

*WeeJeWel wacht nog steeds op z'n clapon chip van velleman voor de pc

madwizard: het voordeel van de FT2232 is dat 'ie een ingebouwde engine voor JTAG-transfers heeft. Het schijnt echter dat de USB1-interface die 'ie heeft zo nu en dan nog wel es een bottleneck kan vormen; vooral de latency ervan is een probleem.

Latency zou ik niet weten, wat ik wel weet is dat met de MPSSEE engine van die chip een JTAG bus op 3 MHz zonder problemen gaat hier. Kweenie of dat snel genoeg is voor je
Theoretisch kan de boel op 6 MHz maar dat vind m'n target chip niet meer leuk. In mijn geval flash ik veel data richting de chip telkens dus dan maakt latency niet zoveel uit. Als je telkens een paar bitjes erin, een paar bitjes eruit wilt doen gaat het wel langer duren waarschijnlijk omdat je USB bus toch een tiental ms nodig heeft om de packets weer heen en weer te schoppen.

Schema's zijn trouwens bloedsimpel, dus als je toch chips over hebt zou ik zeggen; knutsel er een in elkaar en kijk of het sneller is.

Bleah, geen zin in printjes maken Maar es kijken of ik met experimenteerprintplaat iets inelkaar kan zetten, ik zit atm toch weer 20 min te wachten voordat mijn nieuwe compile van U-boot erinzit.

quote:

ShadowLord schreef op woensdag 05 maart 2008 @ 00:54:
Dat kun je ook doen (en zelf in een microcontroller bouwen). Echter zal dit, volgens mij, meer afwijken dan een (goed) klokkristal.

Die 50Hz is echt maar een richtgetal. Als het net overbelast raakt zal die 50Hz dalen. En dan gaan ze niet even later teveel vermogen op het net gooien om dat te compenseren. Hang ook maar eens een scoop aan het net, dan zie je wat voor 'troep' daar allemaal op zit. (Ik heb iig nog nooit een sinus uit het stopcontact gezien.)

Dat de alarmklok die je had ging afwijken komt omdat het een slechte klok is, niet omdat kristallen slecht zijn. Die klok zal uberhaupt geen kristal gehad hebben. Mischien een keramische resonator of een RC opstellinkje. Maar die zijn behoorlijk onnauwkeurig en erg temperatuurgevoelig.

Het lichtnet is inderdaad stukken correcter dan een kristalletje met een avr als klok. Compenseert als het een keer wat minder is waardoor hij echt goed loopt.

Zo een klok ictje is leuk, maar zal uiteraard ook enkele minuten in een jaar achter/voor lopen. Altijd nog beter dan een avr/pic.

Het kan uiteraard altijd nog op de atoomklok, volgensmij zijn die dingen niet zo duur meer tegenwoordig..

Als het echt nauwkeurig moet, maak dan een klok die minder dan 1 seconde afwijkt per dag (dat is niet zo bijzonder), en hang er ook een DCF77 ontvanger aan.
Hoe gestoord de DCF77 ontvangst ook is, elke dag zal je wel een volledig pakket binnen krijgen (een minuut lang goed ontvangen voor een pakket), dus zal je klok nooit mis staan.

Wil je de nauwkeurigheid van een atoomklok, dan heb je een GPS ontvanger nodig, in de wetenschap wordt GPS erg vaak gebruikt als betaalbare exacte tijdsstandaard.

Maar voor wat maus97 wil zal een standaard RTC IC met backup batterij/condensator het gemakkelijkste zijn imho.

naftebakje wijzigde dit bericht 05-03-2008 19:45 (15%)

Voor een RTC circuit gebruik ik meestal een DS1307. Een maxim-ic niet al te duur en doet het perfect.

Maar ik heb zelf even een vraagje over een component. Wat is dit? En waar is het eventueel te verkrijgen.

Totaal plaatje
Het zit in de voedingslijn van een ECU, maar de onderkant is een beetje zwartig.
Een printzekering heeft meestal twee pootjes.
Een keramische resonater is het ook niet, want dat is niet logisch om in een voedingslijn te plaatsen.
Ik denk zelf iets van een filter, twee condensatoren naar massa toe of iets dergelijks alleen de waarde is niet te lezen, iets van ...47 100V. Zover kom ik. Maar hoe heet dit beestje en wat is het?

@pep_82
Volgens mij is het een filtertje bestaande uit 2 ferriet kraaltjes en een condensatortje. Zie ook : http://search.murata.co.j...Q54B&sCapt=Appearance
Het zwart aan de onderzijde kan gewoon het ferriet zijn, mogelijk is er niets aan de hand met dit componentje.
Te koop bij o.a. Farnell http://nl.farnell.com/952...u=MURATA-DSS6NC52A470Q55B

jeronimo wijzigde dit bericht 05-03-2008 20:52 (13%)

Ha, dank je je hebt me de goede kant in geholpen, het is een Ferrite Pi Filter. Het hoort er inderdaad een beetje zwartig uit te zien aan de onderkant.

PDF over het filtertje.

Hier nog een videotje van een project waar ik nu mee bezig ben:
http://www.youtube.com/watch?v=mvKZAltvkQg

Het is nog wat houterig en niet perfect, maar alles komt met zijn tijd, het begin is er

quote:

naftebakje schreef op woensdag 05 maart 2008 @ 19:43:
Als het echt nauwkeurig moet, maak dan een klok die minder dan 1 seconde afwijkt per dag (dat is niet zo bijzonder), en hang er ook een DCF77 ontvanger aan.
Hoe gestoord de DCF77 ontvangst ook is, elke dag zal je wel een volledig pakket binnen krijgen (een minuut lang goed ontvangen voor een pakket), dus zal je klok nooit mis staan.

Wil je de nauwkeurigheid van een atoomklok, dan heb je een GPS ontvanger nodig, in de wetenschap wordt GPS erg vaak gebruikt als betaalbare exacte tijdsstandaard.

Maar voor wat maus97 wil zal een standaard RTC IC met backup batterij/condensator het gemakkelijkste zijn imho.

Het lijkt/leek mij dat het elektriciteitsnetwerk bedoeld is om elektriciteit te leveren, niet een kloksignaal. Daarom is het in mijn optiek niet de beste methode om een klok te bouwen. Hebben jullie ergens een bron van het verhaal dat die 50Hz over tijd perfect uitgemiddeld wordt? Ik kan namelijk niets vinden.

DFC77 is trouwens gekoppeld aan een atoomklok, dus dat is ook erg nauwkeurig (zolang je ontvangst hebt).

Een GPS kun je ook gebruiken als klok, maar wil je echter een zeer hoge nauwkeurigheid hebben dan moet je deze in een andere modus laten draaien. In de klok-modus moet je de positie van de ontvanger weten en die kan dan aan de hand van de verwachte reistijd van de tijdsignalen van de satelieten de huidige tijd uitrekenen. Hierbij heb je overigens nog een afwijking, tenzij je in de VS zit. Daar heb je namelijk ook een correctiesateliet die rekening houd met atmosferische storingen.

Voor een alarmklok however vind ik zelf de combinatie van een kristal (of zelfs netfrequentie) en een DFC77 ontvanger het beste. Simpele klok, maar je hoeft hem nooit bij te zetten.

Als je niet weet waar je bent duurt een seconde nog steeds een seconde. Dus is GPS data prima te gebruiken als referentie signaal. Alleen een beetje overkill voor een klok

Wat betreft de RTC ga ik voorlopig op de uC oplossing met een timertje, als het niet
stabiel blijkt probeer ik wat anders. Ik staar mij alleen blind op de communicatie met
avr over usart. Ik heb een echo test ingevoerd, en het vreemde is: hij doet 't een beetje.
(ik ben van 1 en 0.. hij doet 't wel of niet). Als ik karakters invoer krijg ik bij een 'a' netjes
een 'a' terug, maar van een aantal andere letters krijg ik om en om rotzooi terug.
Ik heb de ubbr op 23 (9600 baud bij 3,2768 Mhz), 8 data & 2 stop bits.. iemand tips?

Ik ben ook weer wat begonnen met mijn meerjaren project om iets met AVR's te gaan doen en wel een sterrenhemel bouwen waarin alle ledjes individueel te dimmen zijn.
Ik doe dit door middel van multiplexing icm met een PWM signaal. Op de Tiny2313 zitten 4 onafhanelijke PWM kanalen die ik voor de rijen gebruik. De kolommen stuur ik met een normaal poortje. Ik moet dus iedere keer dat ik overschakel naar een andere kolom de vier compare values van de PWM timers aanpassen. Dit ging niet helemaal goed in het begin maar na heel goed het datasheet lezen ben ik er toch achter gekomen waar het misging.
Op het moment stuur ik slechts 16 ledjes aan met een pic mischien worden dat er meer ik denk dat ik tot max 32 kan gaan hoewel ik dan mischien wel in de problemen kan komen dat de frequenties dan wel wat te laag worden.

Mauws: Hoe kom je daarop? Iirc is de formule om de baudrate uit te rekenen baud=fosc/((ubrr+1)*16); dan kom ik op een baudrate van 8533 uit. Dan kom je er met een ubrr van 20 meer in de buurt, dan heb je een baudrate van 9752 wat anderhalf procent van je gewenste 9600 afzit. Zolang je niet ongelovelijk veel data zonder error-detectie gaat versturen moet dat prima werken.

Trailblazer: Je kan het ook enkel in software doen Ik heb ooit een 7x7 matrixdisplay gemaakt waarbij elke led 128 grijstinten kan displayen: zie [leds] 7x7 monochroom led-display voor meer indo en source enzo.

Edit: Ik zie net dat ik die source nooit goed gedocumenteerd heb Nja, ik hoop dat je er alsnog wat aan hebt.

Sprite_tm wijzigde dit bericht 09-03-2008 13:21 (62%)

quote:

Sprite_tm schreef op woensdag 05 maart 2008 @ 16:16:
madwizard: het voordeel van de FT2232 is dat 'ie een ingebouwde engine voor JTAG-transfers heeft. Het schijnt echter dat de USB1-interface die 'ie heeft zo nu en dan nog wel es een bottleneck kan vormen; vooral de latency ervan is een probleem.

Ik ga er over een aantal weekjes oook mee aan de slag.. Ga de JTAG gebruiken om een Xilinx FPGA te proggen met zijn .bit file Woei via USB proggen

Heeft iemand een idee hoe ik een PDF file kan spiegelen?

Ik heb namelijk een layout voor een PCB in een pdf-je maar die is niet gespiegeld, dus als ik toner-transfer wil doen dan heeft dat geen zin. Nu kan ik in mijn printersettings niks vinden over gespiegeld afdrukken, en ik ben bang dat als ik printscreen -> plakken in paint doe dat de schaal dan niet meer klopt.