Hallo Zusammen, möchte gerne über einen Port des Atmega8 ein AFSK-Moduliertes Signal ausgeben ! Also 1200Hz für 1 und 2200 Hz für 0 ! Geht das über den internen DAC ? Hat da vielleicht jemand von euch Erfahrung, Codebeispiele in C oder sonstige nützliche Informationen ??? Im AVR-GCC Tutorial ist leider eine andere Art der DA-Wandlung beschrieben ( Oder ich habe was übersehen !!) Ich entschuldige mich jetzt schonmal dafür, wenn ähnliches Problem in einem anderen Beitrag schon behandelt wurde,habe extra gesucht :-) Gruß !! casa !
Hi! nen internen DAC hat der atmega nicht. Das was er hat ist ein ADC (analog nach digital wandler). Les dir mal das tutorial durch oder guck bei den PWM Erklärungen im Datenblatt. Wenn ich dich richtig verstanden hab brauchst du dann nur einmal den Timer so einstellen das am PWM Pin 1200Hz oder 2200 Hz anliegen.
Danke erstmal für deine Antwort !! Da habe ich mich wohl vertan was den Atmega angeht !! Werden mal genau nachlesen !! Und ich hoffe ,es ist so wie du sagst, und man muss nur was am Timer einstellen !!! Gruß !! casa
Bitte reparier bei Gelegenheit deine Punkt-Taste. Die scheint Leer- und Ausrufezeichen zu produzieren.
Ein paar Grundlagen der digitalen Signalverarbeitung sollte man sich zuvor aber zu Gemüte führen. Man kann in der Tat einen PWM als DA- Wandler benutzen, aber man muss natürlich die PWM-Grundfrequenz danach ordentlich rausfiltern, damit nur die gewünschte Modulationsfrequenz übrig bleibt. Rechnen wir kurz: ein 8-bit PWM (z. B. Timer 0) kann mit maximal CPU-Takt laufen und teilt diesen durch 256, das ist die PWM-Frequenz. Wenn der ATmega8 mit 8 MHz läuft, wären das 31250 Hz. Für eine saubere Filterung der gewünschten Nutzfrequenz von 2200 Hz von der PWM-Frequenz wäre ein Verhältnis von mehr als 1:2 notwendig (realistisch besser 1:4, wenn man den Filteraufwand nicht zu hoch treiben möchte). Bei 2200 Hz : 31250 Hz ist das offenbar OK. Würde man den ATmega8 nur mit 1 MHz betreiben, ergäben sich 2200 Hz : 3906.25 Hz, das wäre also komplett jenseits der Möglichkeiten. Für 8 MHz müsste es gehen. Man setzt einen Tiefpass mit vielleicht 3 kHz Schnittfrequenz nach, der dämpft ca. 10 dB pro Dekade, d. h. bei 31250 Hz hätte man 10 dB Dämpfung erreicht. Ist nicht berauschend. Besser wäre ein kleines aktives Filter (mit einem OPV) und wenigstens 2 Polen, dann hätte man 20 dB pro Dekade, also 1/10 der Spitzen- spannung noch an Rest-PWM-Träger. Damit kann man wahrscheinlich leben (insbesondere, wenn der nachfolgende Übertragungskanal sowieso dazu tendiert, hohe Frequenzen zu vernachlässigen). Ach, irgendwoher muss natürlich auch der Sinuswert kommen... Schnell ist natürlich immer eine Tabelle, aber man bräuchte für jede der beiden Frequenzen eine, das nimmt dann wieder Platz weg. In der Praxis dürfte man eher eine Mischung aus Tabellen-Stützwerten und Approximation der Zwischenwerte bevorzugen.
TP 1.Ordnung = 20dB/dek OPV: 1.Eckfrequenz -20dB 2.Eckfrequenz -40dB Ausser er ist Kompensiert (LEAD,LAG,TP). Gruss
> TP 1.Ordnung = 20dB/dek OK, habe ich mich um 10 dB geirrt... Ein Punkt mehr für den Delinquenten ;-), der einfache RC-Tiefpass könnte schon genügen. > OPV: 1.Eckfrequenz -20dB > 2.Eckfrequenz -40dB Was soll das sein? Ich meinte einen Tiefpass, der mit einem OPV gebaut ist. Sallen-key circuit ist wohl die gängige Grundschaltung für einen zweipoligen Tiefpass. Kurzes Gugeln bringt http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sloa024b&fileType=pdf als Referenz, danach sollte man real mit einer Dämpfung der ersten Dekade von vielleicht 35 dB rechnen können (theoretisch wären es 40 dB). Das ist für den vorliegenden Anwendungsfall sicher genug. Kein Grund, sich gleich hinter anonymen Sternen zu verkriechen.
Vielen Dank erstmal für die zahlreichen Informationen. Und nochmals sorry für meine defekte Punk-Taste, habe sie repariert. Die ganze Sache scheint(zumindest für mich) komplizierter als erst angenommen. Bezüglich der PWM-Funktion des AVR, steige ich da noch nicht ganz durch. Werde mich wohl da noch intensiver reinfuchsen müssen. Gruß Casa
Da ich gerade nichts Passendes auf die Schnelle gefunden habe, hab ich mal schnell ein Bild gemalt. Die grüne Linie ist dein PWM-Ausgang. Du siehst, dass die Frequenz des Rechtecks konstant ist, während die Pulsbreite moduliert wird (daher PWM = pulse width modulation). Wenn du das Signal durch einen Tiefpass schickst, dessen Grenzfrequenz hinreichend unter der PWM-Frequenz liegt, dann bleibt ein niederfrequenter Anteil übrig: die rote Linie. Das soll so schematisch mal ein Viertel einer Sinuswelle sein. Du musst die PWM-Generierung also beständig in ihrem Wert verändern (*), dann kannst du eine Ausgangskurvenform deiner Wahl erreichen. Es sollte auch optisch klar werden, warum die gewünschte Ausgangsfrequenz ,,ein ganzes Stückchen'' unter der PWM-Frequenz liegen muss. (Das ist jetzt nicht ganz wissenschaftlich, man könnte auch einen sogenannten Alias herausfiltern, aber das geht hier zu weit.) (*) Das ist so schwer nicht, da jedesmal am Endanschlag des Zählers, also am Ende einer PWM-Periode, ein Interrupt ausgelöst werden kann. Der kann den nächsten PWM-Wert berechnen. Auf ganz simple Weise findest du das im Minimal-Demo (demo.c) der avr-libc bereits vor (wenn du WinAVR hast, hast du dieses Demo mit auf deiner Platte), dort erfolgt die Modulation aber nicht sinus- sondern dreieckförmig. Das sollte ja schließlich einfach bleiben.
@jörg wunsch Vielen Dank für deine Mühe. Das hat mir auf jeden Fall geholfen die PWM Funktion besser zu verstehen Gruß casa
Hallo casa, schau mal bei dieser Url: http://www.knology.net/~gdion/whereavr.html Dort wird allerdings zur AFSK Erzeugung ein Port benutzt(4bit) Hab das schon getestet, funktioniert ohne Probleme !! Gruß Uli
Hi Ulli, du hast die schlatung schon aufgebaut? Hast du sie als APRS Tracker benutzt?!
Hi manu, habe die Schaltung in etwas abgewandelter Form aufgebaut, siehe meinen Beitrag zum Experimentalwettbewerb 2005: http://www.raketenmodellbau.org/showthread.php?s=&threadid=5350 Habe die Schaltung als APRS-Tracker aufgebaut, mit sekündlicher Datenübertragung. Uli
Hey, tolles Projekt! Habe mir gerade auch den WhereAvr zusammen geschustert.. In der Main.c habe ich dann den TestTone generator aktiviert, damit sollte ja an den Pins des R'Netzes ein Rechteck anliegen.. Leider habe ich da nichts...!? Wartet die SW auf ein Start-Signal? Das ganze GPS geraffel kommt ja erst hinterher!??!!?
Hallo manu, in main.c, die while Schleifen auskommentiert lassen !!!! while(1) WatchdogReset(); // Debug with a single one tone Programm bleibt ja dann in einer WatchdogReset-Schleife hängen !!! Ich hab bei mir das Watchdog- u. das Receive-"Geraffel" weggelassen. Gruß Uli
hast du evt. ein Code - Sample von dir!? Ich habe die while - Schleifen eingebaut, damit was zu messen habe.. ;-)
hey, prima.. nun moduliert mein whereavr ein sich eigentlich gut anhörendes 1200baud afsk signal... leider wird dieses jedoch nicht von meinem TNC3s dekodiert! evt. habe ich timing probleme? verwende den org. quarz und auch die org. software!! weiß jemand rat!?
;-) freu .. nun dekodiert das TNC auch das signal... leider geht der RX via AVR noch nicht richtig.. die DCD LED leutet aber auch nicht korrekt.. flakert irgendwie rum, aber nicht im takt des signales.. komisch...
Hochhol :-)) Ich habe mich nun auch mit dem APRS-Tracker von N4TXI befasst. Ich habe folgende kleine Problemchen: Da ich zZt nur einen MEga48 habe, den ich für dieses Projekt verwenden kann (die Mega8 sind alles "L" Typen), habe ich das Programm entsprechend angepasst. Waren nur die neuen Bezeichner für die USART, die Timerinitialisierung, das FR-Bit im ADC (heisst nun ADATE) und ein paar andre Kleinigkeiten anzupassen. Die gimmicks habe ich alle entfernt. So passt das in die 4K-Flash vom 48er. Zum Test habe ich in der main.c die nötigsten Sachen entfernt und mich auf eine periodische Positionsausgabe beschränkt. Leider habe ich keinen 14.7456Mhz Quarz. Ich habe an Stelle dessen einen 16 Mhz Quarz eingesetzt und (natürlich) stimmen nun die Timings nicht. Ich habe vom 2Meter Packet Zugang die Pakete mit der Soundkarte aufgenommen und "hintendrann" meine erzeugten Pakete. Mit CoolEdit2000 (waveeditor) kann ich nun das Signal analysieren. Das Bit-Delay ist definitiv zu kurz. Leider komme ich mit der Berechnung des richtigen Wertes fürs Bit-Delay in Rudern. Die 189, die im Quelltext als Konstante für 0.833uS bei 14.7456 Mhz angegeben sind, kann ich nicht nachvollziehen. Die Low-und High-Töne (1200 und 2200Hz) habe ich durch empirisches ändern und anschliessende Kontrolle im Wasserfall hinbekommen. Vlt. kann mir jemand die 189 erklären...? Ich werde mir jetzt nochmal die originalquellen ansehen. Warscheinlich bin ich auch mit den Timern beim "redefine" durcheinander gekommen. 833uS gehen bei der Quarzfrequenz nur bei einem Prescaler >8. Das wäre dann Timer2. Nur bei diesem steht der Presc. auf 1024. Mit der EEPROM-Schreiberei bin ich gut zurecht gekommen. Man kann den EEPROM super in der Quelle initialisieren und beim Programmieren gleich mit "brennen". im fertigen hex-File rumzueditieren fand ich müßig. viele Grüße 73 AxelR.
Jo, habe mich dann doch dazu überwunden, einen passenden Quarz bei RS zu bestellen... Wo anderst habe ich die leider nicht auf die schnelle herbekommen!
Habe den halben Sonntag rumtelefoniert und einen bekommen. Einen MEga8 hatte ich noch - funktioniert auf Anhieb #freu#. Jetzt taste ich mich mit dem Original und Soundkartendirektverbindung an die 16Mhz ran. VlG AxelR.
Hast du auch dass Decodieren versucht? Irgendwie läuft dass bei mir nicht so zuverlässig.... :-(
dekodieren: noch nicht, wollte ich heute eigentlich machen. Mal sehen, ob ich dazu komme
Also bei mir blinkt bei einem einkommenden AX25 Paket kurz die DCD-Led auf, aber er sendet mir dann leider kein ACK... Habe dass Paket so abgeschickt: :TE1ST-9 :nur ein test call.{31 Leider kommt aber keine reaktion.. dass Call habe ich natürlich entsprechend in der main.c angepasst...!
Hmm. Kann ich noch nicht allzuviel zu sagen, schade... Du könntest die Variablen, die für die Auswertung relevant sind, über die UART ausgeben static unsigned char start_temp; // Msg starts at end of header static unsigned char bytes_recd; // Incoming byte index static unsigned char crcstate; // State of message checksum check static unsigned char crchi; // High byte of expected crc Die Auswetung erfolgt ja nur, wenn MSG_end > 0 ist. da auch deine DCD gleich wieder aus geht, stimmt vlt. etwas mit der Checksume nicht. Das kann allerdings viele Ursachen haben. So könnte der Spannungsteiler am PIN AIN1 (R10/R11) etwas daneben liegen. Das Signal könnte einfach zu laut sein. Nun ja, ich muss die Schaltung nochmal richtig aufbauen und an mein TRX anpassen. Dann kann ich mehr sagen. vy73 AxelR. DG1RTO DL1RON silent key RIM
Hi Axel, also immoment schaut es so aus, als bräuchte ich abartig viel NF, damit es funktioniert.. Am Laptop mit voll aufgedrehter Lautstärke läuft es nämlich pirma! Aber der TRX bringt wohl nicht genug NF, darum geht es hier nicht... Evt. muss ich den Spannungsteile am Eingang noch anpassen! Oder vielleich ein POTI einbauen?! Welche werte würdest du empfehlen!?
[.. Evt. muss ich den Spannungsteile am Eingang noch anpassen! Oder vielleich ein POTI einbauen?! Welche werte würdest du empfehlen!? ..] Die Frage verstehe ich nicht: wenn R10 10K hat und R11 3.6K hat, welches Poti würdest Du statt dessen einsetzen? Der AnanlogKomparator liegt intern an 1.2Volt, die Spannung am Pin AIN1 liegt in Ruhe bei 5V/((R10+R11)/R11)=1.324V. Du brauchst also ca 100-200mV NF um die Schwelle von 1.2V zu unterschreiten. Nimm also iregntwas, was Du da hast(zB 22K). Die Enden an 5V und GND, den Schleifer an PD7/AIN1 und dann stellst Du 1.2xVolt ein. Es empfiehlt sich, die NF vom Funkgerät mal mit dem Oszi zu kontrollieren. Diese ist evtl zu stark verrauscht oder sieht anderweitig abnormal aus. Vlt. musst Du C8 nachbestücken... kA. vy73 AxelR. DG1RTO DL1RON silent key RIM
@baeri entschuldige bitte meinen Ton, bin zZt etwas durch den Wind... sorry vy73 AxelR. DG1RTO DL1RON silent key RIM
Hi Axel, danke für die Tipps... Also ist ein Poti wohl nicht nötig, die 100-200mV NF sollte ein TRX ja liefern können!? Die Signale schauen auf'm OSZI schon OK aus, auch direkt am Eingangspin des AVRs. Werde mal den Kondenser gegen Masse (C8) nachbestücken, evt. hilft dass ja..
ja schon. evtl mal einen 100Ohm als "Lautsprecherersatz" direkt bei "SPK_IN" vor C12 gegen GND schalten. vy73 AxelR. DG1RTO DL1RON silent key RIM
Habe nun den 100Ohm gegen Masse, mit und ohne C8 versucht.. Leider immer noch sehr unempfindlich.. Er dekodiert erst, wenn am TRX eine NF von ca. +-3V raus kommt...
Ohje Ohje, hatte eine "Leiterbahnen bruch", schhhwweerree Krankheit.. ;-) Die 10K gegen VCC haben somit gefehlt.. Nun dekodiert er "schon" bei ca. +-1V NF ... aber doch immer noch recht unempfindlich
Lieber gleich einen Dynamikkompressor-IC benutzen, aber damit sind wir langsam komplett OT hier.
Jörg hat Recht! wird OT. ich komme erst übernächstes WE wieder dazu (Trauerfall in der Familie), etwas zu machen. Ich berichte dann abschliessend über meine Ergebnisse. 73 AxelR. DG1RTO
Mache auch gerade ein paar Versuche mit dem whereavr. Habe alles originalgetreu, bis auf Kleinigkeiten, nachgebaut. Nur leider das gleiche Problem: Senden klappt prima aber irgendwie scheint das Teil taub zu sein. Auf der PC-Seite hab ich so ein PC-Com-Modem, also kein richtiges TNC. Beim Durchmessen mit dem Oszi ist mir aufgefallen, dass die Signale vom Modem anders aussehen, als vom whereavr. Irgendwie sind beim Modem die 1200 Hz Frequenzen viel lauter als die 2200 Hz. Beim lauter drehen des Funkgerätes werden die Signale zusätzlich noch komisch verzerrt. Könnte aber am Funkgerät liegen. Dann ist mir noch aufgefallen, dass die UI-Pakete vom Modem leicht verändert sind. Beispiel: 0: fm ABC001 to ALL ctl UI+ pid F0 wohingegen die Pakete vom whereavr ohne das Plus nach UI gesendet werden: 0: fm N4TXI to APAVR0 via ... ctl UI pid F0 Da scheint irgendwie das Protokoll etwas abgeändert zu sein. Möglicherweise stimmt deshalb die Prüfsumme nicht?! Werde mich mal mit dem Protokoll beschäftigen, vielleicht bekomme ich noch was raus. Habt ihr mal einen Versuch mit 2 whereavr Modems über 2 Funkgeräte gemacht? Mfg Nando
Hi Nando, dass die UI Pakte via ... gesandt werden kommt daher, dass der whereavr ja aus dem APRS - Bereich kommt. Da werden eigentlich immer alle Pakete "via" einem bestimmten Verteiler/Digi (z.B. RELAY, WIDE2-2) gesandt. Dass Problem mit der Unempfindlichkeit ist wirklich ärgerlich, allerdings habe ich auch (noch) keine Versuche mit 2 whereavr's gemacht. Als Signalquelle diente mit zum einen ein TNC3s vom Symek und zum anderen PC/FLEXNET via Soundkarte mit dem ich dann die NF-Signale direkt auf den Whereavr gegeben habe. Bei direkter Einspeisung der NF aus der Soundkarte wird prima Dekodiert!
Hallo Manuel, Danke für die schnelle Antwort. Wenn ich es diese Woche schaffe, werde ich ein 2. whereavr aufbauen und testen, ob die Kommunikation über 2 Funkgeräte funktioniert. Zum testen komme ich aber frühestens am Wochenende. Die Protokolldefinition hab ich mir schonmal runtergeladen, da lese ich mich bei Gelegenheit rein. Irgendwo im Internet hatte ich ein ähnliches Projekt gefunden, allerdings mit PIC. Bei dem wurde ein externer A/D-Wandler (oder Comperator?!) und ein MAX232 benutzt, um die Signale sauber auswerten zu können. Muss mal suchen, vielleicht hilft uns das weiter, falls alle Stricke reißen. MfG Nando
Bin jetzt soweit, dass ich einen Versuchsaufbau mit Sender und Empfänger zusammengeschlüsselt habe. Auf dem Steckbrett funktioniert das schonmal problemlos. Sollte es auch, da Sender und Empfänger direkt mit einer Drahtbrücke verbunden sind. Nur den 200 kOhm Widerstand musste ich kurzfristig mit einer Drahtbrücke überbrücken, weil sonst am Eingang nichtsmehr ankam. Die Brücke werde ich im Feldversuch wieder entfernen, die Verstärker von den Funkgeräten werden sonst übersteuert. Mir ist aufgefallen, dass es eine ganze Weile gedauert hat, bevor ich das gesendete Hello World wieder empfangen habe. Denke mal, dass das an den Entkoppelkondensatoren liegt. Die brauchen viel Zeit, um völlig geladen zu sein. Dachte schon, ich hätte einen Verdrahtungsfehler. Zum Testen mit 2 Funkgeräten komme ich erst am Wochenende. Ich berichte nächste Woche, obs geklappt hat. MfG Nando
Also letzter Stand: Es Funktioniert!!! Allerdings scheint die Geschichte doch sehr empfindlich zu sein. Ich habs einzig und alleine auf den AM-Frequenzen mit zwei DNT Scanner 4012 hinbekommen. Beim Testen war mir aufgefallen, dass die Signale auf den AM-Frequenzen viel sauberer übertragen und auch bei größerer Lautstärke nicht so stark verzerrt werden. Komisch ist nur, wenn ich ein anderes Empfänger-Funkgerät verwende, ist das Ding wieder taub trotz AM-Frequenz. Vielleicht kann das mal jemand hier im Forum bestätigen und schreiben, welche Funkgeräte und Frequenzen verwendet wurden. Interessieren würde mich, ob es mit zwei billigen PMR-Funkgeräten klappt. Noch was zu den Einstellungen: Also auf Senderseite kann das Poti (R5 im Originalschaltbild) auf Maximum gedreht werden. Auf der Empfängerseite hab ich mit maximaler Lautstärke begonnen und mich schrittweise heruntergetastet. Bei etwa 3/4-tel Lautstärke bekam ich das beste Signal und eine sehr hohe Reichweite. Die Funkgeräte-Rauschsperre hab ich auf Empfängerseite ganz aufgedreht. Es funktioniert auch mit knapp zugedrehter Rauschsperre. Auf Sender-Seite ist es sinnvoll, mit einem kurzen Text zu beginnen, denn bei einem verdrehtem Bit wird das gesamte empfangene Paket verworfen. Erstaulich ist die Reichweite. In 8 km Entfernung sind die Signale immernoch ohne Paketverlust, sehr gut zu empfangen. Jedenfalls bei kurzen Paketen. Also bitte testet mal selber und postet hier ins Forum womit und wie es geklappt oder nicht geklappt hat. MfG Nando
Hallo zusammen, leider bin ich im Moment mit der Nachlassverwaltung meines Vaters, DL1RON, so sehr "eingespannt", dass für ernsthafte Applikation mur weing Muße herrscht. Ich bin mal die letzten Beiträge durchgegenagen: das die AM Modulation sauberer ist, ist klar. Der Modulationsfaktor ist hier ein anderer, als bei FM. Die Modulation auf der Senderseite ein wenig zu laut aufgedreht und schon kommt am Empfänger kein sauberer SDinus mehr an. Hier ist weniger oft mehr. Also ruhig mal auf der Senderseite die Lautstärke zurücknehmen. Liegen TX und RX nicht exakt auf der gleichen Frequenz, wirkt sich diese fänomen(schreibweise?) noch stärker aus. ZUsätzlich zur FM Demodulation findet noch eine sog. Hängedemodulation an den Seitenflanken des FM Diskriminators statt, was zu starken Verzerrungen führt. Lieber den Sendehub zurücknehmen und am Empfänger etwas lauter stellen. Signal-Rauschabstand beachten. Die Widerstandskombination zum Erzeugen der beiden Töne: ich habe entgegen des Schaltvorschlages von N4TXI ein R2R Netzwerk verwendet. Hier ist die richtige Zeile im Quelltext einzusetzen, da es sondt kein Sinus, sondern was anderes wird. Die Dekodierung der Signale mittels Analogkomparator erscheint mir allerdings nicht wirklich PRaxistauglich zu sein. Ein bereits geringes Rauschen lässt jeden Versuch Pakete zu dekodieren scheitern. Hier ist evtl etwas mehr Hardwareaufwand im Eingang (Bandpassfilter) und/oder etwas mehr Softwareaufwand in der RX-Routine angesagt, denke ich. Wenn ich meine familiären Angelegenheiten aus der Welt habe und mir nichts anderes dazwischen kommt, widme ich mich gern wieder diesem Projekt. Bis zu letzt habe ich mich mit der Frequenzaufbereitung befasst. Der Sender soll ca.5Watt auf 144.800Mhz bringen. Ich habe einen 18.1Mhz Quarz verwendet(x2=36.2Mhzx2=72.4Mhzx2=144.8Mhz) und in Anlehnung an den "hohentwiehl"TRX die Aubereitung gestaltet (VCXO-Schaltung). Ich werde aber, weil nicht zeitgemäß und ein Quarz teuer (Sparsam->geizig->Funkamateur) ;-)) ist, die Sache nochmal auf PLL umstricken. Erste Sendeversuche mit einem kleinen Kenwood TH-22E verliefen allerdings sehr erfolgreich. Bei geringer NF-Modulation des Senders, wie gesagt! Der Frequenzhub sollte 70% der zur Verfügung stehenden Empfängerbandbreite nicht überschreiten, beide Töne sollten mit der gleichen Lautstärke gesendet werden. In diesem Sinne vy73 DG1RTO AxelR.
@AxelR. Das mit der Lautstärke muss ich bei Gelegenheit mal testen. Dachte mir nur, dass bei hoher Sendelautstärke der SNR möglichst groß ist. Hab mich selber noch nicht so tief mit der Materie beschäftigt, suche aber auch nach einer Möglichkeit, die Sache sicherer zu machen. Kannst du mal einen Schaltplan von deiner Lösung anhängen, sobald alles getestet ist? @SuperUser Derzeit wird mit 1200 Baud gesendet, wenn obige Probleme aus der Welt geschafft sind, ist auch mehr drinne.
@Alex: Hast du mittlerweile rausgefunden wie die Werte für mainDelay() und Delay() berechnet wurden sind, denn ich komme z.B. für die 189 bei Bit-Delay auf 102,564us.
wird Zeit, dass ich mal wieder was am Projekt mache, oder? Maindelay habe ich nch nicht weiter probiert - hatte noch einen 14,xMhz Quartz gefunden. Kann man sich doch aber sicher 'rantasten :-) Habe allerdings immernoch keine Zeit! Wer beräumt die 100m2 Funktechnik meines Vaters? Alles komplett und besenrein bitte, so wird es gewünscht (sicher - nicht von mir)... 73 de DG1RTO AxelR.
Ich hab jetzt nicht alles gelesen, aber für Deine Sache vergiß mal den ganzen PWM-Quatsch. Was Du brauchst, ist der "Clear On Compare" Modus und dann einen Pin auf "Toggle On Compare" setzen. Für nen 8MHz Quarz setzt Du dann den Comparewert (ICP) auf 1818 (= 2200,2Hz) bzw. 3333 (= 1200,1Hz) und fertich. Im Compare-Interrupt kannst Du dann noch mitzählen, nach wieviel Halbwellen Du das nächste Bit ausgeben willst. Peter
Hi, die 189 ergeben sich wie folgt: 1200 Bit/s bei 14,7456 MHz und einem Prescaler von 64 bei Timer0. 14745600 1200 64 = 192 Die 3 Zyklen weniger sind dann als Ausgleich für die Zeiten der Befehle in der Schleife. Ich hab die Schaltung auch eben aufgebaut, und hab das selbe Problem mit dem Empfang. Die DCD leuchtet nur ganz selten. Bisher hab ich noch kein einziges Paket empfangen. Gibt es hierzu schon weitere Tipps? KBr
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.