Hallo Forum, Also ich habe vor kurzem eine Bitte unserer Dorfgemeinschaft entgegengenommen, das ich doch bitte bitte einen Rundenzähler für ein Mofarennen bauen soll. Da ich ja so gutmütig bin habe ich natürlich ja gesagt. Und nun habe ich ein Problem: Ich habe ein Frequenzbereich der Transponder (Kleine Sender an den Mofas) zwischen 10 und 30 MHz. Und mit einen ATmega8 will ich nun abtasten wie stark das Signal an der Antenne ankommt. Ich dachte mir dann, is doch ganz einfach, einen Hüllkurvendemodulator gebaut und dann die auf die Spannungsspitze der Jeweiligen Frequenz das Zählsignal ausgeben. Die Filter für das Empfangssignal sind Quarze welche ich über den µC so zuschalte das ich jede Frequenz nacheinander auswerten kann. Nun macht mir der Hüllkurvendemodulator allerdings enorme Probleme, den auser einem Signalgewirr krieg ich nichts raus. Deswegen bräuchte ich etwas Hilfe dabei, wie ich den Demodulator richtig auslege, sodass ich für den OP-Komperator ein verwertbares Analogsignal herausbekomme. Gruß Michael
Hi, Michael, > Da ich ja so gutmütig bin habe ich natürlich ja gesagt. Fein. Aber schließt das ein "Ja" ein zu einer Ordnungswidrigkeit? Die sogar im Internet angekündigt wird, nämlich hier? > Ich habe ein Frequenzbereich der Transponder (Kleine Sender an den > Mofas) zwischen 10 und 30 MHz. Frequenzzuteilung? Störungen durch Rundfunksender? Was hindert Dich, eine Indukltionsschleife zu legen und das Überfahren per ISM-Band mit Adresse zu melden? Ciao Wolfgang Horn
Rundenzähler bauen? Ganz einfach ;) -> Pappkarton, Kreisel ausschneiden, mit Pin an Holzlatte heften, Skala draufmalen, zwei Leute Mofas beobachten und Scheiben drehen lassen...
Ohh Michael Blöser, ich habe dein Problem gelesen. Ich habe auch den Beitrag von Wolfgang Horn gelesen und habe das Gefühl, dass da wieder die Bürgerwehr unterwegs ist. Wenn allerdings Wolfgang Horn derjenige ist, den ich schon oft im Forum gelesen habe, dann bin ich sicher, dass er es nicht so meinte. Bei Betrachtung deines Problemes fällt mir allerdings sofort auf, das wohl der Ansatz schon nicht optimal ist. Was wäre, wenn es so klappen würde, wie du es dir ausgedacht hast ? Erkennung an der Amplitude ? ... und wenn nun 2 Mofa quasi gleichzeitig eintreffen und der eine den anderen verdeckt (für die Funkwellen) ? Der einfachste Ansatz für ein Mofarennen wären vielleicht Staffelstäbe, die der Fahrer dann von seiner Angebeteten je Runde überreicht bekommt. Zur Gewichtseinsparung auf dem Rennsattel könnten es ja eingefärbte Q-Tips (Ohrenreiniger) sein. Dann kommen auch die süssen Dorfschönheiten (nett dekoriert) noch zur Geltung weil diese die q-Tips aushändigen. In America heissen die dann Cheerleader weil die immer schreien. .. Nun sag mal da gibt es doch diese wunderbaren mechanischen Handzähler, die immer einen weiter zählen, wenn man auf den Knopf drückt. Wenn man nun je Mofa eine solche Gerätschaft besorgt (jibbet auch in Plastik) , das ganze auf ein Brett montiert und für jeden fahrer einen Ehrengast auswählt, der das Knöpfchen drücken muss, wäre es doch eine Bereicherung für alle. Machs dir nicht so kompliziert. Gruss Klaus
Hi, Klaus, > Ich habe auch den Beitrag von Wolfgang Horn > gelesen und habe das Gefühl, dass da wieder die Bürgerwehr unterwegs > ist. > Wenn allerdings Wolfgang Horn derjenige ist, den ich schon oft im Forum > gelesen habe, dann bin ich sicher, dass er es nicht so meinte. Sicher habe ich das Wort für Wort genau so gemeint. Natürlich irre ich mich immer noch zu oft, aber Herumgerede oder gar Unwahrheiten erschweren die Kommunikation, dafür bin ich zu faul. Damit Du weißt, was ich meine, unterhalte Dich doch mal mit einem Psychologen, der geschult ist, ganz egal wie aufrichtig Du gerade bist, jedes Deine Worte nur als Symptom zu werten und sich dabei zu fragen, was Du wohl gerade "wirklich" meinen könntest. So etwas macht Dich kirre, bis er an Dir eine Neurose oder gar Psychose diagnostizieren kann. Bürgerwehr? Auch Du wirst Dich besser hüten, Ratschläge zu geben, die ein Staatsanwalt als Aufforderung für eine Ordnungswidrigkeit halten müsste. > Was wäre, wenn es so klappen würde, wie du es dir ausgedacht hast ? Gute Fragestellung. > Erkennung an der Amplitude ? Genau. Dann kommt die Frage nach Richtwirkung und Abschattung. Ich will das gar nicht vertiefen. Soll das machen, wem der Spaß am Ausdenken von Lösungen wichtiger ist als das Ergebnis. Ciao Wolfgang Horn
Wolfgang Horn schrieb: > Auch Du wirst Dich besser hüten, Ratschläge zu geben, die > ein Staatsanwalt als Aufforderung für eine Ordnungswidrigkeit halten > müsste. Was bist du denn für'n kranker Vogel...dann schreib doch lieber nichts!
Wolfgang Horn schrieb: > die > ein Staatsanwalt als Aufforderung für eine Ordnungswidrigkeit halten > müsste. Naja, einen Staatsanwalt interessieren Ordnungswidrigkeiten in der Regel nicht. Die zuständige Behörde, das zu verfolgen, wäre die BNetzA. (Das alles gilt für die BRD, in anderen Ländern könnten nicht genehmigte Aussendungen von elektromagnetischen Wellen im regulierten Bereich durchaus nach wie vor Straftaten sein.) Anyway, auch ich halte die ganze Vorgehensweise nicht für sinnvoll. Ich würde eher an jedes Mofa einen billigen Funkmodul bauen (damit ist man dann gleich das Problem der Ordnungswidrigkeit los ;), am besten vielleicht einen Transceiver, und der wird dann von der Rundenmesseinrichtung "gepollt". Jeder hat eine Kennung, und nachdem eine Kennung für die aktuelle Runde gezählt worden ist, muss erst eine gewisse Karenzzeit vergehen, bis sie wieder gezählt wird. Alternativ kann man hier auch den Verlauf des RSSI-Wertes als Kriterium für "jetzt ist er vorbei" benutzen, sofern man ihn direkt während der Übertragung der Information von der jeweiligen Station ermittelt hat (dadurch kann man ihn mit dem jeweiligen Fahrzeug korrelieren). Kann man natürlich auch ohne Pollen machen, dann muss man nur drauf achten, dass sie alle zufällig genug ihre "Bake" aussenden, damit auch wirklich jeder gehört wird.
Wie gut das ich ja nur den Empfänger bauen will und ich KEINE Elektromagnetischen Wellen abstrahlen WILL. Und selbst wenn es so währe, würde der Sendebereich max. 5m Radius um die Quelle betragen. Wo die die Transponder herbekommen is nicht mein Problem. So, und nun da das geklärt ist, und ich die 3. Unterweisung im Funkrecht (Ausbildung sei dank hatte ich schon 2) bekommen habe. Danke dafür. Währt ihr nun bitte so nett mir zu helfen, oder is das nun auch wieder illegal? Denn soweit mir bekannt ist, ist es das nämlich nicht. Und dann noch was, was is den wenn ich eine PWM Endstufe baue, die sehrschnelle MOSFETs benutzt? Dann haben wir in Verbindung mit einer langen Leitung zur Last auch einen wunderbaren Störsender, und ich will nicht wissen wieviel es davon in Deutschland gibt. Soviel zu unrechtmäßigen Sendern. Ich hätte dazuschreiben sollen das ich keinen Sender bauen will sondern nur den Empfänger, aber dennoch muss man deswegen doch keine solche Hysterie veranstalten. Ich finde das schon teilweise ein bischen lächerlich. Zu meiner eigentlichen Frage, worauf muss ich achten wenn ich einen solchen Empfänger bauen will, welche Kritschen Stellen gibt es etc. Gruß Michael
Nils S. schrieb: > Rundenzähler bauen? Ganz einfach ;) > -> Pappkarton, Kreisel ausschneiden, mit Pin an Holzlatte heften, Skala > draufmalen, zwei Leute Mofas beobachten und Scheiben drehen lassen... Bei "Ben Hur" gabs da auch ne recht interessante Lösung. :-) Gruss Harald
Michael Blöser schrieb: > Wo die die Transponder herbekommen is nicht mein Problem. Allerdings könntest du diejenigen ja zumindest drauf hinweisen, dass das offenbar nicht rechtens ist. Dessen werden sie sich gar nicht bewusst sein. "Transponder" sind das sicher auch nicht, sondern stinknormale Sender. Ein Transponder ist ein Gerät, das auf ein Signal reagiert und dann antwortet (oder das Signal weiterleitet). > Und dann noch was, was is den wenn ich eine PWM Endstufe baue, die > sehrschnelle MOSFETs benutzt? Dann haben wir in Verbindung mit einer > langen Leitung zur Last auch einen wunderbaren Störsender, und ich > will nicht wissen wieviel es davon in Deutschland gibt. Wenn sie gegen Vorschriften verstoßen und sich jemand darüber beschwert (weil er davon gestört wird), dann werden sie aus dem Verkehr gezogen - durchaus auch bei Bedarf gebührenpflichtig für denjenigen, der sie betrieben hat. Auch für solche Teile gibt es letztlich Vorschriften, was sie dürfen und was nicht. > Zu meiner eigentlichen Frage, worauf muss ich achten wenn ich einen > solchen Empfänger bauen will, welche Kritschen Stellen gibt es etc. Du hast's noch nicht begriffen: das ganze Konzept ist in der Form Sche***e. Du kannst von einem breitbandigen Empfänger, der das gesamte Spektrum aufnimmt, nicht die von dir gewünschte Selektivität erwarten. Das Mindeste, was du also brauchst, wäre eine Frequenzselektivität auf die Teile, die du da aufnehmen willst, aber das würde dann bedeuten, dass du als erstes mal deren Frequenz kennen müsstest. Alles andere ist ungenauer als eine Wünschelrute, damit wirst du nicht froh werden. Es hat keinen Sinn, wenn sich jemand einen irgendwie gearteten Sender beschafft und dann erwartet, dass andere das schon irgendwie auswerten können. Bei einem solchen System sollten Sender und Empfänger als ein System betrachtet werden, dem ein Konzept zugrunde liegt. Wie ein solches Konzept aussehen könnte, hab' ich dir oben skizziert. Wenn du weiter gegen Windmühlenflügel kämpfen willst, dann darfst du dich allerdings nicht wundern, wenn sich alle anderen weigern, dich gegen diese dagegen zu schmeißen.
Jörg Wunsch schrieb: > Du hast's noch nicht begriffen: das ganze Konzept ist in der Form > Sche***e. Du kannst von einem breitbandigen Empfänger, der das > gesamte Spektrum aufnimmt, nicht die von dir gewünschte Selektivität > erwarten. Das Mindeste, was du also brauchst, wäre eine > Frequenzselektivität auf die Teile, die du da aufnehmen willst, aber > das würde dann bedeuten, dass du als erstes mal deren Frequenz kennen > müsstest. Ich lese gerade, dass du ja offenbar irgendeine Selektivität schon hast. Nun, dann wirst du wohl mit der Umschalterei einfach nicht klarkommen, bis sich so ein Quarz als Filter eingeschwungen hat, dauert das seine Zeit. Ich finde das Konzept trotzdem daneben. Im Zeitalter billiger digitaler Funkmodule kann man sowas damit deutlich effizienter lösen, da man dann nicht mehr mit frequency diversity arbeiten muss sondern mit code diversity: jeder Sender strahlt seinen Code aus, aber alle arbeiten auf der gleichen Frequenz. Das macht die Auswertung viel einfacher.
Nimm doch Sender und Empfänger, wie sie auch bei Garagentoren verwendet werden. Jeder hat seinen Code, sie sind preiswert und ihre Reichweite ist auch begrenzt. Ein kleiner µC wertet sie aus und steuert vielleicht noch eine Anzeige an.
Wenn die zu fünft kanpp aneinander im Ziel vorbeirauschen, kommt doch Codediversity schon aus Zeitgründen nicht in Frage, oder? Man müsste über der Start- und Ziellinie mehrere Antennen aufhängen und die wiedrum mit mehreren Empfängern n:m verbinden, die gleichzeitig auf allen frequnezen empfangen. Es soll ja auch ermittelt werden wer der erste ist, denke ich mal. Also genau wann und wer zuerst Statt wiedermal auf irgentwelche Ordnungwidrigkeiten hinzuweisen,sollte man sich auch hier dem technischen Problem hingeben, oder die klappe halten! Axelr. (ist das eigentlich hier im Forum eine krankhafte Veranlagung einiger??!? Man erlebt das in letzter Zeit immer öfter. Ich denke da an den "mein Auto macht quiek quiek bei Tür zu" Thread)
Ich wollte dir gerade noch was auf deine Frage antworten, aber dann habe ich weitergelesen. Sorry. Mit dem Tonfall bekommst du von mir nichts mehr zu hören. Tschüss.
An alle, entschuldigung das ich mich im Ton vergriffen habe, ich wollte keinen Hier verletzten oder Angreifen. Ich kanns jetzt nichtmehr ungeschehen machen, was ich geschrieben habe, aber ich kann versprechen das in dieser Art keinen Post hier im Forum mehr schreiben werde. Also mein Konzept für besagten Empfänger sah folgendermaßen aus. Jeder Fahrer erhält eine eigene Frequenz, über seinen Sender (Die Frequenzen der Sender bekomme ich in den nächsten Tage mittgeteilt). Mein Ansatz sah dann so aus das ich mittels eines geeigneten Filters für jeden Kanal die Frequenz herausfiltere, gleichrichte und dann das Signal über einen Komperator mit einem einstellbaren Gleichspannungssignal vergleiche. Die Vergleichsspannung muss natürlich vor dem eigentlichen Zählbetrieb entsprechend eingestellt werden. Dieses Verfahren wollte ich für alle Kanäle des Empfängers anwenden, um allerdings die Anzahl der Bauteile gering zuhalten, wollte ich 1 Komperator für alle Frequenzen benutzen, indem ich die verschiedenen Filter durchschalte und zwischen dem durchschalten auswerte. Das durchschalten und an den PC senden der Signale würde dann über einen µC passieren über die RS232-Schnittstelle. Der einzige Teil der nun noch Probleme macht, ist wie gesagt der Teil der das Signal gleichrichten soll, ich dachte hier an einen Messgleichrichter mit einem schnellen OP und entsprechenden Dioden, allerdings hat das schon mit 16.000 MHz nicht wirklich funktioniert, obwohl der OP mit 25 MHz Oberer Grenzfrequenz noch Luft hatte. Wie kann ich nun das ganze so Aufbauen das ich das Vorverstärkte Signal meiner Antenne nach dem Filter (Wenn möglich sind das Quarze) gleichrichte und dann eine "Gleichspannung" herausbekomme die ich mittels eines Komperators auswerten kann. Gruß Michael
Wenn deine Empfangsfrequenzen nicht gerade Standardfrequenzen sind (wie 9 Mhz, 10.7 MHz 21.4 Mhz usw. oder andere Frequenzen zu denen man Quarze kaufen kann), dann sieht es schlecht aus mit Quarzfiltern. Außer natürlich du nimmst eine größere Menge Geld in die Hand... Mfg
Soweit mir das bekannt ist solls was einfaches mit Quarzen werden, daher gehe ich mal stark von Standartfrequenzen aus. Wenn nicht muss ich wohl oder übel entsprechende Filter ausrechnen und einbauen. Gruß
Michael Blöser schrieb: > Wenn nicht muss ich wohl > oder übel entsprechende Filter ausrechnen und einbauen. Warum klebst du eigentlich so sehr an deinem Ansatz fest? Ich bin immer noch der Meinung, dass es drastisch einfacher wird, wenn du ein paar Standardmodule (RFM12, Zigbit oder sowas) nimmst und auf einer Frequenz code-multiplex arbeitest. Das mit dem simplen Komparator kannst du so ziemlich vergessen: Signalstärken misst man in Dezibel, d. h. logarithmisch, und Unterschiede von 30 dB in der Feldstärke zwischen zwei Fahrzeugen sind normal. Das ist ein Unterschied von 1E-3, dafür kannst du nicht einfach eine Komparatorschwelle festlegen. Die genannten Module haben aber allesamt einen RSSI-Ausgang, an dem sie ein dem Logarithmus der Feldstärke proportionales Signal ausgeben bzw. sie geben dir die Signalstärke gleich digital mit. Dadurch kannst du zusätzlich zum Code-Multiplex-Verfahren noch anhand des Ansteigens und Abfallens der Signalstärke die Vorbeifahrt erkennen. > entschuldigung das ich mich im Ton vergriffen habe, ich wollte keinen > Hier verletzten oder Angreifen. Nö, meine Bemerkung war nicht auf dich bezogen sondern auf Kommentare wie: "Statt wiedermal auf irgentwelche Ordnungwidrigkeiten hinzuweisen,sollte man sich auch hier dem technischen Problem hingeben, oder die klappe halten!" Das war aber nicht von dir, und daher rede ich ja auch weiterhin mit dir. ;-)
Dann wars ein Missverständnis meinerseits. Nunja, ich habe da etwas bedenken wenn 3 dieser Standartmodule gleichzeitig versuchen ihre Daten zu senden. Da das dann mehr Krautsalat gibt als ein anständiges Signal. Daher wollte ich das Frequenztechnisch getrennt haben. Ich habe mich mittlerweile mit der ganzen Sache etwas intensiver beschäftigt, und erkannt das ich keine 22MHz mit einer Diode in ein einigermaßen anständiges Gleichspannungssignal wandeln kann, daher habe ich mir überlegt mittels einer PLL-Schaltung (MC145151/VCO) und einem Mixer (SA612) das Signal der Antenne auf eine ZF von 500kHz herunterzuholen. Und dieses Signal sollte dann leicht mit einem Hüllkurvendemod auszuwerten sein. Jörg, weist du, ich habe das Projekt auch deswegen angenommen, weil ich etwas in die Thematik der Empfänger einsteigen möchte, gerade die der AM-Empfänger da ich später noch mit dem Gedanken spiele ein Spektrumanalyzer zu bauen. Immerhin ist der Sprung meines jetzigen Konzeptes zum Speki nicht wirklich weit. Ein kleines Speki währe mit einem anderen Programm aufm µC und dem Ausgangssignals des Demod am ADC des µC schon möglich. Was die Sender angeht, ich habe vorhin die Frequenzen bekommen, die Vermutung hat sich bestätigt, er hat Standartquarze genommen im Bereich von 10MHz bis 22MHz für 16 Teilnehmer insgesamt. Rein Theoretisch könnte man sogar dank der PLL-Schaltung noch viel mehr Kanäle unterbringen, da ich ja mit dem Filter relativ genau abtasten kann. Dazu hätte ich auch noch eine Frage: Meine PLL soll ja die Mischfrequenz für meinen Mixer erzeugen, als Referenz ein Quarz is klar. Was würde nun passieren wenn mein VCO anstatt eines Sinussignals ein Rechteck in den Mixer schickt? Immerhin sind im Rechteck von der Frequenz 1MHz auch ein Sinussignal mit 1 MHz enthalten, aber eben auch die ganzen Oberwellen (3. OW, 5. OW, 7. OW, etc). Rein theoretisch müsste er nun ja mein Signal mit der Grundfrequenz mischen sowie auch mit allen anderen Frequenzen. Da ich ja nun aber ein Filter am Ausgang nutze, womit ich nur die 500kHz herausfiltere dürfte mich das ja nicht unbedingt interessieren müssen, oder? Oder währe es doch besser ein einigermaßen sauberes Sinussignal als Mischsignal auf den Mixer zu geben? Ich zerbrech mir dann mal im Bett weiter den Kopf darüber. Gruß Michael
Michael Blöser schrieb: > Nunja, ich habe da etwas bedenken wenn 3 dieser Standartmodule > gleichzeitig versuchen ihre Daten zu senden. Die senden doch nicht 100 % der Zeit! Du hast nur ganz kurze Telegramme und kannst dir ausreichend lange Pausen leisten. Es geht ja um ein Mofa-Rennen und nicht um eine Rakete, die in ein paar Millisekunden schon wieder vorbei ist. ;-) Du kannst die Teile entweder zu einem zufälligen Zeitpunkt senden lassen, dann kollidieren sie halt gelegentlich mal (das musst du über eine CRC im Telegramm feststellen und dann das entsprechende Telegramm verwerfen), oder aber du benutzt eine Methode, bei der man vorher in den Kanal reinhört. Sowas haben die Module auf Basis von IEEE-802.15.4 (bspw. Zigbits) bereits in der Hardware eingebaut, nennt sich CSMA/CA (carrier sense, multiple access, with collision avoidance - ist angelehnt an die Ethernet-Zugriffsmethode CSMA/CD). Aber auch da kann es natürlich Kollisionen geben. > Daher wollte ich das Frequenztechnisch > getrennt haben. Ich fürchte nur, dass die Umschaltzeiten deines Empfängers sehr viel länger werden als das, was die paar Funkmodule brauchen, um ihre Telegramme abzusenden. > Ich habe mich mittlerweile mit der ganzen Sache etwas intensiver > beschäftigt, und erkannt das ich keine 22MHz mit einer Diode in ein > einigermaßen anständiges Gleichspannungssignal wandeln kann, daher habe Das kannst du, aber du hast das Problem, dass du das Signal über wenigstens einen Dynamikbereich von 30 dB oder mehr empfangen können solltest, das schafft keine Diode. Im AM-Empfänger regelt man daher die Verstärkung der ZF-Stufen. > ich mir überlegt mittels einer PLL-Schaltung (MC145151/VCO) und einem > Mixer (SA612) das Signal der Antenne auf eine ZF von 500kHz > herunterzuholen. Hmm, nun kommst du vom 100ten ins 1000te und erfindest den Superhet neu ... > Und dieses Signal sollte dann leicht mit einem Hüllkurvendemod > auszuwerten sein. Das Dynamikproblem bleibt trotzdem noch. Ein ZF-Filter zum Rauswerfen des unerwünschten Mülls brauchst du auch noch. Deine Diode ist keineswegs so frequenzselektiv, wie du glaubst, ordentliche Schottky-Dioden kann man bis in den Gigahertzbereich nutzen. OK, du könntest dann zumindest die Sender ganz legal auf 27-MHz- Fernsteuerfrequenzen arbeiten lassen und zwischen denen umschalten. Eine PLL schafft das einigermaßen schnell. > Jörg, weist du, ich habe das Projekt auch deswegen angenommen, weil ich > etwas in die Thematik der Empfänger einsteigen möchte, ... OK, ich nahm nur an, dass du zeitnah fertig werden möchtest. ;-) > AM-Empfänger da ich später noch mit dem Gedanken spiele ein > Spektrumanalyzer zu bauen. Immerhin ist der Sprung meines jetzigen > Konzeptes zum Speki nicht wirklich weit. Antwort vom Sender Jerewan: "Im Prinzip nicht, aber". Der Teufel steckt in sehr vielen Details. Gerade beim Spekki musst du dir viel Gedanken machen um die ZF-Bandbreite, die macht man dort nämlich umschaltbar, damit man einerseits nicht mehr Rauschen als nötig erfasst (ist sowieso immer viel zu viel davon da), andererseits breit genug, dass das komplette Nutzsignal durch das Filter passt. Auch um die Dynamikprobleme musst du dir beim Spekki Gedanken machen. > Was die Sender angeht, ich habe vorhin die Frequenzen bekommen, die > Vermutung hat sich bestätigt, er hat Standartquarze genommen im Bereich > von 10MHz bis 22MHz für 16 Teilnehmer insgesamt. Schau dir bitte an, wen du damit alles störst. Nein, das ist keine Krümelkackerei, die Regulierung des Frequenzspektrums existiert nicht grundlos, sondern weil sonst keine "friedliche Koexistenz" der Funkdienste mehr möglich wäre. Was ihre machen wollt ist ungefähr so, wie auf der Straße ohne Beachtung der Straßenverkehrsregeln kreuz und quer umher zu fahren. > Was würde nun passieren wenn mein VCO > anstatt eines Sinussignals ein Rechteck in den Mixer schickt? Das ist gang und gäbe, dass man das tut, ein SA612 arbeitet auf diese Weise. Der Mischer mischt natürlich auch die Oberwellen mit, entsprechend muss die Vorfilterung das Eingangssignal vor dem Mischer im davon betroffenen Frequenzbereich weit genug unterdrückt haben. > Da ich ja > nun aber ein Filter am Ausgang nutze, womit ich nur die 500kHz > herausfiltere dürfte mich das ja nicht unbedingt interessieren müssen, > oder? Das Ausgangsfilter hat keinen Einfluss mehr darauf. Das kann nicht unterscheiden, ob die 100 kHz, die es als Signal reinbekommt, aus der Mischung eines Eingangssignals von 27,12 MHz mit der Oszillatorfrequenz 27,22 MHz entstanden sind, oder ob sie von einem Eingangssignal von 81,76 MHz stammen, dass sich mit der 3. Harmonischen des Oszillatorsignals gemischt hat.
Hm ok, es sind also irgendwelche Frequenzen zwischen 10 Mhz und 22 Mhz. Hast du mal darüber nachgeadcht was passiert, wenn irgendwelche anderen Funkdienste (sagen wir mal Radio) auf der gleichen Frequenz arbeiten? Und das Kurzwellenband ist recht dicht belegt... Mfg
Gut angenommen ich würde mir solch ein Funkmodul nehmen einen AT-Tiny 13 dranbauen welcher mir dann die Daten ausgibt, sagen wir mal mit dem Protokoll einer RS232 (Einfach zu realisieren) Schnittstelle. Dann währe im Prinzip der ganze Funkteil weg. Hm, ich habe ja nur 16 Teilnehmer geplant, dann brauchte es auch nur 16 Sender mit entsprechender Übertragung. Wenn ich nun die Zahl nichtnur zum Übertragen nehme sondern auch als Wartezeit zwischen den Übertragungen, dann kann ich eigentlich davon ausgehen das die 2 Sender falls sie sich einmal gestört haben kein 2es mal stören da ja der eine früher senden wird als der andere. Dürfte also daher funktioneren. Nochmal allgemein, das Gerät soll ein Rundenzähler werden, keine Zeiterfassung. Wenn sich die Zeiterfassung auchnoch realisieren lässt ist das ein schönes Gimick aber mehr nicht. Notwendig ist das die Runden der Teilnehmer gezählt werden. Von hand Zählen würde schwirig werden da wir einen sehr Matschigen Streckenabschnitt haben werden, und da das Rundenrennen 2 h gehen soll wird es wohl so sein, das die Fahrer irgendwann alle gleich aussehen werden. und dann soll mal wer von hand zählen!^^ Gruß Michael
Sorry für Doppelpost, aber ich habe hier eine Sender/Empfängerkombi gefunden, die denke ich doch akzeptabel ist. Eine Konformitätserklärung ist auch dabei, daher gehe ich mal davon aus das diese es legal ist diese zu nutzen: http://de.rs-online.com/web/p/hf-module/6666748/ Empfänger http://de.rs-online.com/web/p/hf-module/6666744/ Sender Das müsste doch zusammen funktioneren. Gruß Michael
Michael Blöser schrieb: > da ich später noch mit dem Gedanken spiele ein > > Spektrumanalyzer zu bauen. Da würde ich dir dringend raten, dir in den UKW Berichten den Bauvorschlag von Jochen Jirmann anzuschauen. Die Artikelserie geht über mehrere Jahre. Der geht zwar nur bis 500MHz. Aber der SA ist der einzige mir bekannte Bauvorschlag, der auch nur einigermasen die Bezeichnung Spektrumanalyzer verdient. Aber wundere dich nicht über den Aufwand der dort getrieben wurde. Einen Spektrumanalyzer selbst zu bauen ist alles andere als trivial, und erfordert neben der benötigten Messtechnik sehr viel Erfahrung, und vor allem Durchhaltevermögen und die Bereitschaft unzählige Rückschläge einzustecken. Es ist aber ungemein lehrreich so ein Projekt zu bauen. Ralph Berres
Michael Blöser schrieb: > aber ich habe hier eine Sender/Empfängerkombi gefunden, die denke ich > doch akzeptabel ist. Eine Konformitätserklärung ist auch dabei, daher > gehe ich mal davon aus das diese es legal ist diese zu nutzen: Ja, das auf jeden Fall. Allerdings sehe ich keinen Vorteil im Vergleich zu den weit verbreiteten RFM12-Modulen. Für letztere bekommst du zumindest ausreichend Softwarestückchen und -ideen im Netz. Bei deinen Modulen müsstest du das Modulationssignal noch im Controller aufbereiten, einen FIFO oder sowas haben die nicht. Alternativ eben die schon genannten Zigbits, da hast du für etwa EUR 15 das Stück nicht nur einen kompletten Transceiver, sondern auch gleich noch einen ATmega1281 mit dazu. Für die Fahrzeugsender brauchst du außer dem Zigbit eigentlich nur noch zwei LR03-Zellen und ein kleines Gehäuse, damit ist dein Gerät fertig. Für die Zigbits könnte ich dir (mit leichtem Eigenwerbungsanteil ;) das µracoli-Paket als Softwarebasis empfehlen. Michael Blöser schrieb: > Hm, ich habe ja nur 16 Teilnehmer geplant, dann brauchte es auch nur 16 > Sender mit entsprechender Übertragung. Wenn ich nun die Zahl nichtnur > zum Übertragen nehme sondern auch als Wartezeit zwischen den > Übertragungen, dann kann ich eigentlich davon ausgehen das die 2 Sender > falls sie sich einmal gestört haben kein 2es mal stören da ja der eine > früher senden wird als der andere. Ja, das könnte auch klappen. Du lässt sie beispielsweise im Abstand von (100 + 3 * Startnummer) Millisekunden senden.
Jörg Wunsch schrieb: >Bei deinen Modulen müsstest du das Modulationssignal noch im >Controller aufbereiten, einen FIFO oder sowas haben die nicht. Inwiefern aufbereiten? Demoduliert wird es ja von dem Reccievermodul, und dann sollte ich ja schon die Daten haben die aus dem Ausgang kommen. Nunja, irgendwie muss es letztendlich klappen, aber was die kosten angeht, ist das natürlich auch immer so eine Sache. Immerhin müssen die Sender im schlimmsten Fall Stürze überstehen, und falls sie kaputt gehen, sollen sie auch nicht ganz so viel kosten, daher wollte ich die Senderkosten möglichst gering halten. Der Empfänger ist dagegen kein so großes Problem, da dieser neben mir stehen wird, und nicht aufm Mofa mitdabei ist. Ich schau mir mal so nen Zigbee Modul an. Gruß Michael
Was auch noch eine Möglichkeit währe sind die HOPERF RFM02 module. Die währen mir sogar fast lieber da auf der Website eine ausführlichere Doku dabei ist. Kosten zwar mehr, aber was solls lieber ne ordentliche Doku. Jörg, du hast die RFM 12 angesprochen, die kommen ja auch von diesem Hersteller. Also das Demoboard is ziemlich teuer. Gruß Michael
Michael Blöser schrieb: >>Bei deinen Modulen müsstest du das Modulationssignal noch im >>Controller aufbereiten, einen FIFO oder sowas haben die nicht. > > Inwiefern aufbereiten? Ich habe mir das Datenblatt nur flüchtig angesehen, aber es sieht so aus, als wäre das eine reine Funkstrecke, und alles, was in Richtung Paketierung der Daten geht, muss der Controller bereits tun. Kann sogar sein, dass du sowas wie ein manchester encoding noch im Controller machen musst (damit das Signal gleichspannungsfrei wird), und in jedem Falle muss der Controller den empfangenen Datenstrom bit für bit in Echtzeit einlesen. Demgegenüber bieten "intelligentere" Transceiver-ICs (oder auch separate Sender/Empfänger) die Möglichkeit, eine Synchronisationsfolge festzulegen, ab der der Empfänger dann die Daten als "Paket" in einen Puffer schreibt, den sogenannten FIFO. Damit hat der Empfänger mehr Spielraum in seiner Reaktionszeit, und das Auslesen des FIFOs erfolgt (genauso wie die Kommandoverarbeitung) über SPI mit einer vergleichsweise hohen Datenrate. Funkmodule nach IEEE 802.15.4 (wie die Zigbits) gehen noch ein Stück weiter, indem der komplette Rahmenaufbau bis hin zur abschließenden CRC bereits im entsprechenden Standard festgelegt ist und in dieser Form in der Hardware implementiert wird. Dabei gibt es auch noch die Möglichkeit, Sender- und Empfängeradressen zu vergeben und den Empfang eines Rahmens nur dann an den Controller zu melden, wenn man selbst die angesprochene Station ist. (Ist allerdings vermutlich nicht ganz das Szenario, was du hier brauchst.) > Nunja, irgendwie muss es letztendlich klappen, aber was die kosten > angeht, ist das natürlich auch immer so eine Sache. Immerhin müssen die > Sender im schlimmsten Fall Stürze überstehen [...] Das Zeug ist dermaßen klein, wenn du das nicht gerade auf dem Lenker montierst, dann zerlegt es vorher das komplette Mofa, bevor dem Modul was passiert. Am meisten gefährdet dürfte die Anbindung der Batterie sein, da die Batterie selbst eine relativ große Masse (im Vergleich zum Funkodul) darstellt, dass sie durch die auftretenden Beschleunigungskräfte abreißen könnte. Aber davon ist der Modul selbst noch nicht kaputt. Wenn ich so einen Modul (ohne Batterie) aus 10 m Höhe zum Fenster rauswerfen würde, dann hätte ich nur Sorgen um ein einziges Bauteil darin: den Quarz. Aber den hast du bei jeder Art (sinnvollem) Funk-Konzept dabei.
Michael Blöser schrieb: > Jörg, du hast die RFM 12 angesprochen, die kommen ja auch von diesem > Hersteller. Also das Demoboard is ziemlich teuer. Da vergleichst du allerdings Äpfel mit Birnen. Demoboards kosten immer ihr Geld, während die reinen Module doch eher preiswert sind. Der RFM12 ist letztlich die Kombination aus RFM01 und RFM02 in einem. Brauchst du nicht unbedingt, erlaubt es aber, sich ein zwei-Wege- Protokoll auszudenken.
Gute, den Datenstrom Bit für Bit einlesen, stellt kein Problem dar, da der Empfänger ansonst nurnoch an die RS232 die Daten übergeben muss, mehr tut er ja nicht. Was mir mehr sorgen bereitet sind die Einstellungen des Transmitters/Recievers, da ich zwar eine "Programmieranleitung" habe, aber die sagt mir nicht wirklich viel. Meine Vermutung ist, das die Module Initialisiert werden müssen, vor dem Funkbetrieb, sprich einmal die ganzen Einstellungen an das Modul per SPI schicken, und danach müsste nurnoch der der Datenstrom bereitgestellt werden. Hab mir eben auch noch die RFM12B von Hope angeschaut, die sind eigentlich schon zuviel da das Transciever sind, und ich das eigentlich getrennt haben wollte. Lieber beides Einzeln. Immerhin müssen die Sendemodule ja wirklich nur senden. Also entweder ich nehme die Module von Quasar oder die von Hope, sind nämlich beide Pingleich (SMD ausführung) daher hab ich hier die Wahl. Gruß Michael PS: Den letzten Post von dir kam zu schnell. Die Demobards sind wirklich teuer im vergleich zu den Modulen. Die sind aber auch schon Oversized wie du schon sagst. PPS: Ich korregiere mich die sind doch nicht Pingleich, 1 Position ist vertauscht. Ist mir aber eben nicht aufgefallen.
Ich mach' mal die Ingrid: > Brauchst du nicht unbedingt, erlaubt es aber, sich ein zwei-Wege- > Protokoll auszudenken. Was mir dabei in den Sinn kommt wäre eine Rundenanzeige fürs Mofa selbst. ;-) Der Fahrer könnte dann also mitverfolgen, in welcher Runde er gerade fährt. Michael Blöser schrieb: > Meine Vermutung ist, das die Module Initialisiert werden müssen, vor dem > Funkbetrieb, sprich einmal die ganzen Einstellungen an das Modul per SPI > schicken, und danach müsste nurnoch der der Datenstrom bereitgestellt > werden. Ja, das würde ich auch vermuten. > Hab mir eben auch noch die RFM12B von Hope angeschaut, die sind > eigentlich schon zuviel da das Transciever sind, und ich das eigentlich > getrennt haben wollte. Lieber beides Einzeln. Warum? Letztlich kostet die reine Hardware doch praktisch nichts. Wenn ich beispielsweise im Octamex-Shop gucke, dann kostet ein RFM01 oder RFM02 etwas mehr als 3 Euro, ein RFM12 knapp 4 Euro. Da lohnt es sich doch nicht, noch über getrennte Sender oder Empfänger nachzudenken. (Ein Zigbit kostet um die EUR 16, aber dafür hast du dort gleich noch den Controller drin. Siehe oben, für das Mofa brauchst du dann nur noch Batterie und Gehäuse, also nicht einmal mehr eine zusätzliche Platine.)
Gute Ideen Jörg, aber soviel Zeit habe ich denke ich nichtmehr. Ich bräuchte mal Hilfe beim RFM01, ich bin gerade dabei diesen im Eagle anzulegen, und im Moment versteh ich von diesem Bauteil irgendwie nur Bahnhof was die Pinbelegung angeht. Bei diesem Modul verstehe ich nicht ganz wo den nun die Daten die das Modul empfängt herauskommen, und was ich auch nicht verstehe, ist wozu ein Recievermodul Data In braucht, immerhin empfängt es ja nur. Und die Sache mit dem FIFO verstehe ich auch nicht, hat das Modul nun einen FIFO oder nicht? Ich glaube es ist ganz gut das ich noch nichts bestellt habe!^^ Eventuell werde ich auch deinen Tipp befolgen und das Transcievermodul benutzen. Gruß Michael
Michael Blöser schrieb: > Gute Ideen Jörg, aber soviel Zeit habe ich denke ich nichtmehr. Gut, musst du selbst wissen. Aufgrund eigener Vorerfahrungen hätte ich für alles außer der Zigbit-Lösung wohl keine Zeit mehr. ;-) > Bei diesem Modul verstehe ich nicht ganz wo den nun die Daten die das > Modul empfängt herauskommen, und was ich auch nicht verstehe, ist wozu > ein Recievermodul Data In braucht, immerhin empfängt es ja nur. Das ist ein SPI-Interface, das ist praktisch ein Schieberegister. Selbst, wenn du also nur Daten auslesen willst, musst du immer zugleich auch Dummy-Daten am Eingang liefern (normalerweise gibt man dann einfach eine 0 aus), denn der Eingang kann ja während der 8 Taktimpulse, die du für das Byte am Ausgang brauchst, nicht "nichts tun". Davon abgesehen, brauchst du natürlich die Richtung zum Modul hin immer noch für die Kommandos, also Einstellung von Frequenz, Datenrate, weiß der Geier[tm].
Ich nehm die RFM12, das erscheint mir einfacher ein Bauteil zu nehmen welches alles kann. Vor allem es hat ein FIFO welches ich nutzen kann, was mir das ganze deutlich erleichtern sollte. Gruß Michael
Also die Hardware ist soweit aufgebaut und getestet, und derzeit bin ich am Programmieren der µC des Empfängermoduls sowie des Sendemoduls. Allerdings programmiere ich in Assembler (Ja ich weis altgebacken etc. aber C kann ich noch nicht, steht aber auf der To Do Liste) Das ganze soll alles über die SPI-Schnittstelle ablaufen, da so der Programmieraufwand sich in Grenzen halten sollte. Ich verwende ganz klassisch einen ATmega8 der mit 4 MHz Quarz läuft. Soweit mal vorneweg. Nun zu diesem RFM12 Modul. Ich habe mir nun ja schon einiges zu diesem Modul durchgelesen, sowohl von HopeRF als auch hier im Forum, aber ich verstehe immernoch nicht wie so eine Initialisierung solch eines Moduls ablaufen soll. Im Programming Guide steht zwar welches Bit für welche Einstellung genutzt wird, aber ich weis nicht wie ich dem Modul sage das diese 16Bit nun ins Einstellungsregister 0xXXXX muss. Hat da jemand eine Seite die diese Frage klärt, oder kann mir das Bitte jemand von euch sagen? Gruß Michael
Michael Blöser schrieb: > aber ich weis nicht wie ich dem Modul sage das diese 16Bit > nun ins Einstellungsregister 0xXXXX muss. Über SPI. Du musst /SEL auf low ziehen, dann sendest du (mindestens) zwei Byte über SPI. Auf dem "Rückweg" kannst du Daten vom RFM12 lesen. Quick hack:
1 | PORTX &= ~_BV(SELPIN); /* activate /SEL */ |
2 | |
3 | SPDR = command_high_byte; |
4 | while ((SPSR & SPIF) == 0) { |
5 | /* wait */
|
6 | }
|
7 | data_received_0 = SPDR; |
8 | SPDR = command_low_byte; |
9 | while ((SPSR & SPIF) == 0) { |
10 | /* wait */
|
11 | }
|
12 | data_received_1 = SPDR; |
13 | |
14 | PORTX |= _BV(SELPIN); /* deactivate /SEL */ |
U. U. musst du mehr als nur diese 16 Bit rausschieben, beispielsweise zum Lesen des FIFOs. In dem Falle interessiert sich der SPI-Slave typischerweise nicht dafür, welche Daten du ihm schickst, man schreibt dann meistens Nullen und ist nur an den auf MISO zurück- gelesenen (Empfangs-)Daten interessiert. Disclaimer: ich habe noch nie was mit dem RFM12 gemacht. ;-) Das ist nur aufgeschrieben aus der Erfahrung mit anderen ICs mit ähnlichen Interfaces sowie einem kurzen Blick ins Datenblatt des RF12.
Jörg also wenn ich dich richtig verstehe, muss ich nun als für die Einstellungen zu übertragen erst einmal die Registeradresse übertragen und danach die neuen Einstellungen, oder? Wenn ich nun etwas auslesen will bsp Statusregister, so muss ich dieses ansprechen und einfach nur 0000 senden, und auf dem Rückweg schickt mir das Modul dann die aktuellen Werte oder? Ich glaube ich verstehs immer noch nicht. Gruß Michael PS: Ich glaube eben bin ich durchgesteigen: Im Programming Guide sendet er im Beispielprogramm jeweils 4 Byte an das Modul, wobei die ersten beiden Byte die Adresse darstellen, und die letzten beiden Byte sind die Einstellungen. So jetzt macht der ganze Krempel solangsam auchmal Sinn. Was das auslesen angeht muss ich mich noch ein wenig durchkämpfen, ich hoffe das krieg ich auch noch irgendwie raus.
Michael Blöser schrieb: > Was das auslesen angeht muss ich mich noch ein wenig durchkämpfen, ich > hoffe das krieg ich auch noch irgendwie raus. Das, womit sich Anfänger auf dem Gebiet SPI immer wieder schwer tun ist: das ist immer eine Zweirichtungsübertragung. Wenn man vom Slave (also dem Transceiver in diesem Falle) etwas empfangen will (ein Statusregister), dann muss der Master dafür Taktimpulse liefern, denn er ist ja Master. Dafür wiederum muss er zwingend auch Daten rausschreiben, denn die MOSI-Leitung kann ja nicht einfach "freibleiben" oder sowas. Im Falle des RF12 taktest zwei Nullbytes raus, wenn du das Status- register lesen willst. So, wie ich das Datenblatt verstehe, ist dabei eigentlich nur das erste Bit (Bit 7 des zuerst gesendeten Bytes) für den Transceiver interessant: alle Schreiboperationen haben dieses Bit auf 1 gesetzt (die nachfolgenden Bits entscheiden dann, was beschrieben wird), und wenn das Bit 0 ist, wird zuerst der Status gelesen und anschließend die Information aus dem FIFO (dafür müsste man dann weitere Nullbytes rausschreiben). Sowie /SEL zurückgenommen wird, setzt sich die interne Logik auf den Anfangszustand zurück.
Also, kurze Zusammenfassung: Byte 1/2 = Adresse des Registers Bit 7 Byte 3 = lesen(0) oder Schreiben(1) Rest = Einstellungen/Daten Bei einer Leseoperation muss ich also erst den Befehl senden, nach Abschluss des Sendevorgangs muss ich allerdings weiter den CLK laufen lassen indem ich einfach 0er Übertrage. Dabei schreibt das Modul die Daten über SDO raus und ich kann nach 2 Bytes dann meine Daten des Statusregisters aus meinen SPI Recieve-Register im µC nehmen. Ich glaub das habe ich jetzt verstanden. Jetzt noch was zur Hardware: Am µC habe ich ja einen MISO und einen MOSI Pin, ich habe die beiden Pins folgendermaßen angeschlossen: MISO (µC) ==> SDI (RF12) MOSI (µC) ==> SDO (RF12) Gedanke dahinter ist, wenn ich bei MOSI (Serial In) habe muss ich beim Slave ja an SDO (Serial Out) anschließen. Und umgekehrt natürlich bei den beiden anderen Pins. Ich bin der Meinung das es logisch betrachtet so stimmen müsste. Sicher bin ich mir da allerdings nicht. Weis du da eventuell mehr (als SPI-Erfahrener) Gruß Michael
Michael Blöser schrieb: > Byte 1/2 = Adresse des Registers > Bit 7 Byte 3 = lesen(0) oder Schreiben(1) Nein. Bit 7 im ersten Byte entscheidet über lesen oder schreiben. Alle zu beschreibenden Register haben dort eine 1, d. h. die Registeradressen beginnen alle mit 0x8000 (als 16-bit-Zahl gelesen). Die Register lassen sich bei diesem IC offenbar nicht auslesen, so wie ich das Datenblatt verstanden habe. Sowie man eine Leseoperation beginnt, liest man zuerst den Status, und wenn man danach noch weiterliest, den FIFO. > Am µC habe ich ja einen MISO und einen MOSI Pin, ich habe die beiden > Pins folgendermaßen angeschlossen: > > MISO (µC) ==> SDI (RF12) > MOSI (µC) ==> SDO (RF12) Andersrum, würde ich sagen. "MISO" heißt ja "Master in, slave out". Damit muss dort SDO (serial data out) des Slaves dran, denn der AVR ist Master.
So, den Senderteil dürfte heute abend laufen. Ich habe nun im Sender die SPI-Schnittstelle manuell einprogrammiert als Subroutine, die 2 Registerinhalte an das RF12 sendet. Die Hardware SPI könnte ich zwar auch benutzen, da ich das USI-Interface aber nicht wirklich verstanden habe, hab ichs nun so gelöst. Also 1:0 für mich gegen die Elektronik.^^ Dann währe noch die Geschichte mit dem Empfänger zu programmieren. Gruß Michael
Michael Blöser schrieb: > Die Hardware SPI könnte ich zwar auch benutzen, da ich das USI-Interface > aber nicht wirklich verstanden habe, hab ichs nun so gelöst. Ist weniger schwierig, als du denkst. ;-) Das hier benutze ich auf meinem tiny230-Board:
1 | static uint8_t |
2 | SPITransfer(uint8_t d) |
3 | {
|
4 | USIDR = d; |
5 | USISR = _BV(USIOIF); |
6 | do { |
7 | USICR = _BV(USIWM0) | _BV(USICS1) | |
8 | _BV(USICLK) | _BV(USITC); |
9 | } while ((USISR & _BV(USIOIF)) == 0); |
10 | return USIDR; |
11 | }
|
Jörg, ich kann aber immernoch kein C ^^ Wie gesagt hab ichs nun so gelöst, was die Einstellung des moduls angeht bin ich mir allerdings noch unsicher. Da ich alles über SPI machen will, habe ich mal alles was an Einstellungen zu machen ist über den Guide von HopeRF gemacht. Folgende Einstellungen habe ich getätigt: Einstellungen für einen reinen Sendebetrieb Configuration Setting: TX-Reg enable,433MHz, 8,5pF Crystal Cap. Power Managment: Transmitter enable, enable OSC, Disable CLK-Pin Frequency Setting: 0xA0FF Wert den ich hineinschreibe Data Rate Command: 0xC6F0 Wert den ich hineinschreibe Reciever Control: brauche ich ja nicht oder doch? Data Filter: Brauche ich auch nicht Output and FIFO: brauche ich auch nicht AFC Command: Und hier weis ich nicht weiter AFC Command 2: Ebenfalls Was das AFC ist und was es bewirkt verstehe ich einfach nicht eventuell kannst du mir da etwas helfen Jörg. Gruß Michael
Michael Blöser schrieb: > Jörg, ich kann aber immernoch kein C ^^ Kann man lernen. ;-) Ich hab' das Teil auch in Assembler:
1 | #include <avr/io.h> |
2 | |
3 | .text |
4 | .global SPITransfer |
5 | SPITransfer: |
6 | #if 1 |
7 | out _SFR_IO_ADDR(USIDR), r24 |
8 | ldi r24,(1<<USIOIF) |
9 | out _SFR_IO_ADDR(USISR),r24 |
10 | ldi r24,(1<<USIWM0)|(1<<USICS1)|(1<<USICLK)|(1<<USITC) |
11 | 1: out _SFR_IO_ADDR(USICR),r24 |
12 | sbis _SFR_IO_ADDR(USISR), USIOIF |
13 | rjmp 1b |
14 | in r24, _SFR_IO_ADDR(USIDR) |
15 | ret |
16 | #else |
17 | out _SFR_IO_ADDR(USIDR), r24 |
18 | ldi r24, (1<<USIWM0)|(0<<USICS0)|(1<<USITC) |
19 | ldi r22, (1<<USIWM0)|(0<<USICS0)|(1<<USITC)|(1<<USICLK) |
20 | out _SFR_IO_ADDR(USICR), r24 ; MSB |
21 | out _SFR_IO_ADDR(USICR), r22 |
22 | out _SFR_IO_ADDR(USICR), r24 |
23 | out _SFR_IO_ADDR(USICR), r22 |
24 | out _SFR_IO_ADDR(USICR), r24 |
25 | out _SFR_IO_ADDR(USICR), r22 |
26 | out _SFR_IO_ADDR(USICR), r24 |
27 | out _SFR_IO_ADDR(USICR), r22 |
28 | out _SFR_IO_ADDR(USICR), r24 |
29 | out _SFR_IO_ADDR(USICR), r22 |
30 | out _SFR_IO_ADDR(USICR), r24 |
31 | out _SFR_IO_ADDR(USICR), r22 |
32 | out _SFR_IO_ADDR(USICR), r24 |
33 | out _SFR_IO_ADDR(USICR), r22 |
34 | out _SFR_IO_ADDR(USICR), r24 ; LSB |
35 | out _SFR_IO_ADDR(USICR), r22 |
36 | in r24, _SFR_IO_ADDR(USIDR) |
37 | ret |
38 | #endif |
Der C-Code war mir am Ende aber übersichtlicher. (Der else-Zweig ist eine entrollte Schleife, also gewissermaßen "optimized for speed".) > Was das AFC ist und was es bewirkt verstehe ich einfach nicht eventuell > kannst du mir da etwas helfen Jörg. Eine automatische Frequenznachstimmung. Ich habe mich mit diesem IC noch nicht befasst, aber das klingt so, als würde man das nur für den Empfänger benötigen, der sich damit auf die exakte Sendefrequenz einstellt.
Jörg, ja kann man lernen, wenn man Zeit hat und die wird immer knapper. Ich hab nun ein Problem mit meiner Empfängerschaltung, Ich habe dort einen ATmega8 verbaut welcher die Umsetzung auf RS232 übernimmt, und das Funkmodul initalisieren soll. Problem an der Geschichte ist folgendes: Ich programmiere den AVR über ISP, dann resetet sich der AVR jedesmal wenn er eine LED-Einschaltet, soweit kommt er nämlich, und startet das Programm neu. Dadurch ist es mir auch nicht möglich den AVR ein zweites mal zu Proggen da er danach in dieser Resetschleife festsitzt. Gottseidank habe ich einen Sockel verbaut, wodurch das neuproggen nur einmal Sockeltausch und zurück ist. Mein Problem bleibt aber warum funktioniert es beim ersten mal und bei zweitenmal nicht? Das SPI-Interface meint dazu nur das die ISP-Leitungen irgendwo kurzgeschlossen sind (Was aber nicht sein kann da beim ersten mal ja alles funzt) Ich hab dir jetzt mal das Layout sowie den Schaltplan angehängt, genau so liegt das Teil auch aufgebaut vor mir. Gruß Michael
Okay, hab den Fehler gefunden, die "Resetschleife" hatte mit einer Unterdimensionierten Spannungsversorgung zu tun. Die 4 LEDs und der MAX 232 haben anscheinend viel mehr wie 100mA gezogen, sprich sie haben den µA7805 überlastet, dieser hat sich abgeschaltet, bzw zurückgeregelt, dann hat sich der 330µF Elko langsam entladen und dann hat sich der µC resetet, was eine umständliche Resetschleife.^^ Ich hab jetzt einfach das Labor-Nt drangehängt, und siehe da 220mA braucht die Schaltung bei Volllast. Und diese schnellen Resets haben auch bewirkt, das ich den µC nichtmehr proggen konnte. Gruß Michael
So, nach einem quallvollen Tag Programmierarbeit und viel neuem lauft der Empfängerteil nun fast. Ich habe die RS232-Schnittstelle nun am laufen, dank dem Tutorial hier und dem Datenblatt. Nun muss noch der Empfänger und der Sender funktionieren, und dann ist soweit alles bestens. Jörg und dir möchte ich noch danken für deine Unterstützung. Vielen Dank Gruß Michael
Michael Blöser schrieb: > Jörg und dir möchte ich noch danken für deine Unterstützung. Freut mich, dass es hilfreich war. Schließlich habe ich komplett im "Blindflug" gearbeitet, ich habe diese Module nie selbst programmiert (aber dafür verschiedene andere).
Eventuell könntest du mir noch etwas weiter helfen, ich habe im Moment das Problem, das die Hardware soweit alles stimmt, nun endlich, aber anscheinend hängt es wie zu erwarten noch an der Software. Ich häng dir mal die beiden Programme an, das Senderprogramm ist für einen Tiny 26, und das Empfängerprogramm für einen ATmega8. Der Tiny läuft mit dem internen Takt, der Mega 8 mit einem externen Quarzoszi mit 4 MHz. Die RS232 funktioniert einwandfrei, es liegt wirklich nurnoch an der Funkgeschichte. Ich habe eben versucht das die beiden zusammen spielen, aber es funktioniert nicht, obwohl ich eine Antenne 1/4 Antenne an beiden dran habe und die beiden Module geschätzte 10 cm auseinander liegen. Währe schön wenn du mir da auch helfen könntest. Gruß Michael
Sorry, ich programmiere vor allem deshalb in C, weil ich keinen Assembler mehr debuggen möchte. ;-) Eins fällt mir sofort auf (und das ist einer dieser typischen Fehler, die einem der C-Compiler abgenommen hätte …):
1 | SPIS: ;Abfrage auf Vollständige Übertragung |
2 | |
3 | SBIS SPSR,7 |
4 | RJMP SPIF |
5 | |
6 | RET |
Ein RJMP auf das SPI-Interrupt-Flag? Ansonsten: stückweise debuggen. Als Debughilfe bei bestimmten Ereignissen mit einem Pin wackeln und dieses mit dem Oszilloskop verfolgen. Wenn du sowas nicht hast, eine LED stattdessen benutzen, aber dann musst du halt zusätzliche Wartezeiten einplanen, damit man die LED auch leuchten sieht.
Okay, den Fehler hatte ich zwischenzeitlich auch gefunden, aber danke. Nunja, ich werde nach dem Projekt auch auf C umsteigen, das geht mir nämlich allemählich auf den Geist. Danke dir fürs durchsehen. Bleibt immernoch das Problem mit der Funkübertragung. Gruß Michael
Michael Blöser schrieb: > Nunja, ich werde nach dem Projekt auch auf C umsteigen, das geht mir > nämlich allemählich auf den Geist. Wenn du in endlicher Zeit fertig werden willst, dann fang bereits bei diesem Projekt damit an. ;-) Hier mal als Vorlage der Empfänger mit dem ATmega8. Ich habe relativ stur deinen Assemblercode runtergeschrieben, mit folgenden Änderungen: . die ganzen SBI/CBI-Orgien in der Initialisierung sind durch eine Gesamt-Zuweisung an das jeweilige Register ersetzt . Register-Defaultwerte müssen nicht initialisiert werden . ich habe symbolische Bitnamen verwendet für die AVR-IO-Register . ich habe vorhandene Hilfen (delay, Baudrate) benutzt, statt das Rad nochmal zu erfinden (meist wird es nämlich beim ersten Versuch dann eckig ;-) Alle Dinge, die ich fragwürdig finde, habe ich mit Fragezeichen markiert. Ich glaube, damit hast du erstmal genug Brot. :) Falls es für den RFM12 ein Headerfile gibt mit symbolischen Register- und Bitnamen, könnte man dieses noch statt der vielen numerischen Konstanten in der RFM12-Konfiguration benutzen und so vielleicht weitere Fehler vermeiden. Danach habe ich aber jetzt nicht gesucht. Den Tiny-Code schreibe ich dir heute abend um. Compilieren mit
1 | avr-gcc -mmcu=atmega8 -Os -g -Wall -Wextra -std=c99 -o rfm12_rx.elf rfm12_rx.c |
2 | avr-objcopy -O ihex rfm12_rx.elf rfm12_rx.hex |
Jörg, vielen Dank. Ist der Code soweit fertig, oder muss ich hier noch etwas umschreiben? Gruß Michael
Michael Blöser schrieb: > Jörg, vielen Dank. Ist der Code soweit fertig, oder muss ich hier noch > etwas umschreiben? Du solltest dir insbesondere alle die Stellen mit dem Fragezeichen ansehen. Ich denke, an diesen Stellen hatte dein Assemblercode Probleme. Teilweise (TXC bei UART bspw.) habe ich diese schon behoben (man muss übrigens nicht TXC pollen, UDRE genügt völlig), teilweise solltest du nochmal über die Logik nachdenken. Ach, die Abfrage des Empfängers in der Hauptschleife braucht sicher noch eine Behandlung für "ich habe keine Daten empfangen". Du solltest natürlich sicherstellen, dass dein ATmega8 auch mit 8 MHz läuft, denn mit 1 MHz sind keine 19200 Bd sinnvoll zu erreichen. Dummerweise ist beim ATmega8 der 8-MHz-RC-Oszillator nicht werksseitig kalibriert, sodass du ggf. noch das OSCCAL-Register passend setzen musst. (Besser wäre da ein ATmega88, da der nur noch einen RC-Oszillator hat. Bei dem heißen aber einige Bits anders, sodass man den Code leicht umschreiben muss. Beispielsweise ist das Bit TXC dann ein TXC0 usw.) Hier noch Teil 2, der Sender. Ich habe nur eine "Gurke" entdeckt und denke, dass ich diese in deinem Sinne korrigiert habe, siehe wiederum das Fragezeichen. Was mir aber dabei aufgefallen ist ist, dass du das NSEL-Signal des RFM12 im Empfänger überhaupt nicht bedienst (im Sender hast du das dagegen implementiert). Das musst du natürlich auf jeden Fall noch nachholen (in spi_config() bzw. um die beiden spi_xfr-Aufrufe in main() herum). Compilieren wiederum wie oben, nur -mmcu=attiny26 diesmal. p.s.: Sieh dir natürlich bitte beide Quelldateien jetzt nochmal an, ob du noch irgendwelche logischen Fehler entdeckst. Die sind ja nun recht übersichtlich kurz geworden.
Vielen, vielen, vielen Dank Jörg du bist ein Gott. Auf den Fehler mit dem NSel währe ich garnicht gekommen. Dämlich von mir. Der ATmega8 läuft derzeit mit 4MHz externer Quarzoszi, die Einstellungen für das UART haben auch soweit gepasst. Ich habe da in etwa 1000 Zeichen Übertragung keinen Fehler feststellen können. Ich schau mir den Code an, aber ich denke da werde ich noch ein wenig Hilfe brauchen, den wie gesagt, C ist neu für mich. Die Hauptschleife für den Empfänger sollte so aussehen, das er die empfangenen Daten einfach nur an die RS232-Schnittstelle weitergibt, den auf dem PC wird das dann in einem eignen Programm entsprechend verarbeitet. Es braucht den Empfänger nur als Umsetzer zwischen Funk und RS232. Hast du auchmal über die Einstellungen des RF12 geschaut? Da bin ich mir ziemlich unsicher was diese Einstellungen angeht. Vielen Dank nochmals. Gruß Michael
Michael Blöser schrieb: > Auf den Fehler mit dem NSel währe ich garnicht gekommen. Ist mir auch erst aufgefallen, als ich den ATtiny26-Code umgeschrieben habe. > Der ATmega8 läuft derzeit mit 4MHz externer Quarzoszi, die Einstellungen > für das UART haben auch soweit gepasst. Dann müsstest du im C-Programm nur ganz oben das #define F_CPU ändern. > Die Hauptschleife für den Empfänger sollte so aussehen, das er die > empfangenen Daten einfach nur an die RS232-Schnittstelle weitergibt Ja, aber was machst du, wenn der FIFO leer ist und gar keine Daten hat? Im Moment bestimmt die Länge des übertragenen UART- Bytes (ca. 0,5 ms bei 19200 Bd) die Umlaufgeschwindigkeit der Hauptschleife, und es wird auf jeden Fall bei jedem Umlauf genau ein Byte zur UART geschickt. Du musst dir den FIFO im RFM12 nochmal ansehen, der heißt ja nicht umsonst so. Wenn der mehr als ein Byte hat, kannst du das auch gleich abholen und über die UART senden. Wenn er gar nichts hat, solltest du aber wohl besser nichts senden. > Hast du auchmal über die Einstellungen des RF12 geschaut? Nö, überhaupt nicht, aber wie schon geschrieben, ich habe von diesem Teil keine Ahnung. Ich würde aber zusehen, alle Register- und Bitnamen symbolisch (via #define) zu schreiben, dann sieht man die Probleme schneller.
Jörg, ich hab eben mal versucht das Statusregister des RF12 auszulesen, anscheinend stellt sich das Modul permanent stur. Ich habe nur 0x00 empfangen, kann ja aber nicht sein, das muss ja irgendwas eingestellt haben, vom Werk aus schon. Gruß Michael
Den nFFS-Pin hast du auf high gelegt? Ansonsten sprichst du den FIFO direkt an statt der Register. Hier gibt's ein Headerfile, was meiner Meinung nach ganz brauchbar aussieht: https://www.das-labor.org/storage/LaborLib/rfm12/trunk/src/include/rfm12_hw.h Sie benutzen die Register 16-bittig, da müsste man die Funktionen nochmal leicht umschreiben. Ach so, hast du beim ATmega8-Code das DORD-Bit wieder rausgenommen? Das ist meiner Meinung nach komplett daneben. Praktisch alle SPI- Implementierungen, die ich bislang gesehen habe, übertragen das MSB zuerst.
Jörg Wunsch schrieb: > https://www.das-labor.org/storage/LaborLib/rfm12/trunk/src/include/rfm12_hw.h > > Sie benutzen die Register 16-bittig, da müsste man die Funktionen > nochmal leicht umschreiben. Hier die umgeschriebene Variante des Empfängers mit diesem Headerfile. Ich habe mir Mühe gegeben, deine Hex-Werte in symbolische Namen zu übersetzen und zu codieren. Deine PLL-Konfiguration war komplett daneben (du hast da ein Lesekommando abgesetzt), auch sonst sind ein paar Fragezeichen drin. Es werden nur empfangene Bytes ausgewertet. Inwiefern gerade die FIFO-Einstellungen wirklich Sinn haben, vermag ich nicht zu beurteilen. Ich habe das Gefühl, dass der Empfänger nur nach dem Sync-Muster sucht und dann den FIFO füllt. Keine Ahnung, ob er bei zu geringem RSSI-Wert dann wieder abbricht, oder ob man das manuell anhalten muss; das solltest du dir mal im Datenblatt des RF12 oder im Beispielcode anderer Leute ansehen.
So, hatte noch einen länglichen Compilerlauf zu überbrücken. ;-) Hier nochmal die Senderseite mit 16-bittiger SPI-Routine. Das Einsetzen der symbolischen Namen und damit die Kontrolle auf Sinnfälligkeit überlasse ich dir dann mal als Fleißarbeit und Hausaufgabe. :)
Erstmal muss ich schauen das ich die Gesichte auch kompilieren kann. WINAVR ist installiert, den Rest muss ich schauen wie ich das kompiliere. Gruß Michael
Compilerkommando hab' ich dir ja oben hingeschrieben. Kannst du fürs erste in ein Batchfile schreiben.
Hört sich jetzt wirklich dämlich an, aber ich verstehs gerade nicht so ganz. Ich benutze normalerweise das AVR-Studio, worin ich beim ASM-Code ja meinen Build-Button habe. Ich hab nun deinen Code einfach nur reinkopiert in ein neues GCC-Projekt. Und wo genau muss ich jetzt deinen Befehl eingeben? Ich hab mich eben durch die Compile-Anweisung im GCC-Tutorial gekämpft aber irgendwie bin ich noch genauso schlau wie vorher. Gruß Michael
Michael Blöser schrieb: > Und wo genau muss ich jetzt deinen Befehl eingeben? Klapp' das AVR Studio zu, nimm dir ein cmd.exe, und tipp das da ein. ;-) Vermutlich kannst du das auch dem AVR Studio beibringen, aber frag' mich nicht, wie das geht. Klickerdihier, klickerdida, irgendwann wird er dir damit dann dein Projekt compilieren. Musst natürlich zwei Projekte machen, eins für den Sender und eins für den Empfänger. Vergiss nicht, die Optimierung einzuschalten (-Os). Je nach Version vom AVR Studio könnte die bei einem neuen Projekt ausgeschaltet sein, und dann gehen die delays nicht mehr so, wie sie gehen sollen (denn die Berechnung der Zyklenanzahl braucht eine aktivierte Compileroptimierung). Mit eingeschalteter Optimierung sind beide Binärdateien einige 100 Bytes groß, wobei ein nicht unbeträchtlicher Teil darin der konstante Overhead (Vektortabelle, Startup-Code) ist, d. h. wenn du mehr dazu schreibst, wächst das nur unterproportional weiter.
Jörg, solangsam verstehe ich C, deine Programme habe ich nun auch endlich soweit bekommen, das sie auf die µC übertragen konnte allerdings funzt das irgendwie immernoch nicht so ganz. Naja, ist nun auch egal, da ich es sowieso nichtmehr rechtzeitig schaffen werde, zu dem besagten Termin. Für das nächste Rennen in einem Jahr will ichs aber dann am laufen haben. Dafür werde ich mir dann aber überlegen ob ich wirklich nochmals dieses Funkmodul benutzen will, oder ob ich mir nicht ein anderes suche. Ich versteh zwar immernoch nicht woran es hängt, aber irgendwo steckt da ne gewaltige Gurke drinen. Gruß Michael
Michael Blöser schrieb: > Jörg, solangsam verstehe ich C, deine Programme habe ich nun auch > endlich soweit bekommen, das sie auf die µC übertragen konnte allerdings > funzt das irgendwie immernoch nicht so ganz. Die ganzen Fragezeichen und Ungereimtheiten hast du aber geklärt, ja? Das Gepostete da oben hatte keinen Anspruch auf funktionierenden Code, er sollte lediglich erst einmal compilierbar sein und dich in die Gänge bringen. Insbesondere habe ich die verkorkste Setup-Sequenz des Senders noch gar nicht angefasst/korrigiert. Das solltest du unbedingt nach dem gleichen Muster, wie ich das schon für den Empfänger getan habe, in die symbolische Form übertragen und dann nochmal genau im Datenblatt nachsehen, ob die Einstellungen so auch Sinn haben. Ein kleiner Funkscanner kann da eventuell auch ganz nützlich sein, damit man erstmal prinzipiell nachweisen kann, ob der Sender überhaupt etwas sendet. > Dafür werde ich mir dann aber > überlegen ob ich wirklich nochmals dieses Funkmodul benutzen will, oder > ob ich mir nicht ein anderes suche. Ich gebe zwar zu, voreingenommen zu sein, aber ich würde dir zu sowas wie den Zigbit-Modulen raten. Erstens hast du dabei schon soweit alles zusammen, dass du für den "Floh" (Sender) nur noch eine Batterie anlöten musst (und natürlich für die Inbetriebnahme einen Programmierstecker), und zweitens hast du mit dem µracoli-Projekt bereits eine solide Basis mit ein paar Beispielen, um in ein bis zwei Tagen grundsätzlich eine Funkstrecke am Laufen zu haben, sodass du dich danach auf die "Nutzlast" konzentrieren kannst.
Jörg Wunsch schrieb: > Inwiefern gerade die FIFO-Einstellungen wirklich Sinn haben, vermag > ich nicht zu beurteilen. Ich habe das Gefühl, dass der Empfänger > nur nach dem Sync-Muster sucht und dann den FIFO füllt. Keine Ahnung, > ob er bei zu geringem RSSI-Wert dann wieder abbricht, oder ob man > das manuell anhalten muss; das solltest du dir mal im Datenblatt des > RF12 oder im Beispielcode anderer Leute ansehen. Ja, man muss das manuell wieder "Abwürgen": https://www.mikrocontroller.net/articles/RFM12#RFM_empf.C3.A4ngt_nur_M.C3.BCll
Thread beobachten
Seitenaufteilung abschaltenBitte 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.