Hi Forumgemeinde, ich bin neu hier und benötige fachkundige Hilfe. Ich muss an einem Projekt arbeiten, bei welchem ein Sender mit Datensignalen gespeisst wird und die Daten via Funk überträgt und ein Empfänger sie empfängt und an eine serielle Schnittstelle weitergibt. Hörte sich unkompliziert an, aber nun weiß ich das es das nicht ist.:-) Ich habe mir ein Funk-AVR-Evaluationsboard von Pollin mit einem ATmega8 und jeweils 1 Funkmodul RFM01/02 868MHz gekauft. Da ich Anfänger bin, habe ich versucht, mich in diesem und einigen anderen Foren schlau zu machen.....ich weiß garnicht mehr wieviele Threads ich bisher gelesen habe....ich habe nun soviel gelesen, das ich absolut nicht weiß wie ich anfangen soll....hat mich alles etwas verwirrt.... ich habe einige testcodes für bascom gefunden, weiß aber eigentlich garnicht was ich da teste, da in den Threads soviele Fremdwörter vorkommen welche auch google nicht findet. Ich weiß nicht ob ich noch einen 2. ATmega8 brauche oder ob ich Sender und Empfänger mit einem realisieren kann oder nicht?! Ich bräuchte nur etwas Starthilfe von jemandem der sich bereits hiermit beschäftigt hat und die dementsprechende Erfahrung besitzt. Könnte mir jemand von euch helfen??? Lg
angeblich sind einige Bascom-Codes betreffend dieser Module fehlerhaft programmiert. Da aber niemand Links zu diesen Codes gesetzt hat, ist es nicht einfach dies zu checken. Mich hätten diese Codes auch interessiert zwecks eigenen Tests, aber wie sollte ich wissen welche Codes so bezeichnet sind. Welche Web-Seiten hast du gefunden?
eigentlich habe ich nur hier im Forum und im Bascom Forum Testcodes gefunden! Weiß aber nicht so recht was damit anzufangen, wie bereits oben geschrieben! :-/
Schoneinmal kurz vorweg: du benötigst für jeden RFM einen Mikrocontroller. Falls du die Minimalschaltung dafür nicht selber zusammenlöten/stecken kannst auch noch ein 2. Board. Es gibt zumindest für das RFM12 hier ein gutes Beispiel um eine serielle Verbindung über Funk herzustellen. Das ist schoneinmal sehr hilfreich. Allerdings in C geschrieben. Genauso gib es vom selben Autor auch Testcodes für die 1er und 2er Modelle... Du bist mir dem Programmieren und dem Flashen von Mikrocontrollern vertraut? Sonst wird es möglicherweise etwas länger dauern, bis du das Wissen angehäuft hast um die Module anzusteuern. Alternativ hilft natürlich auch die "zusammenklaumethode" ;-)
hi stryker, ich bin ja heilfroh das du mir geantwortet hast, hierfür schonmal danke! :-D deine erste aussage hat mir schonmal sehr weitergeholfen.....ich brauche also 2 microcontroller! kennst du das funk evaluationsboard von pollin? hier ist noch ein steckplatz für ein attiny 2313, denke hiermit könnte ich das 2. RFM modul ansteuern, oder? auf dem board ist ja auch platz für RFM1 und RFM2! ja, mit dem programmieren und flashen bin ich einigermaßen vetraut....beschäftige mich seit kurzem mit bascom, da ich c für zu umständlich und kompliziert halte! mein größtes problem momentan ist, das ich die datenblätter der module nicht so ganz kapiere....hast du ahnung davon? lg
Welchen Teil der Datenblätter verstehst Du nicht? Beim Sender wird z.B. zuerst die SPI-Schnittstelle korrekt eingerichtet und dann durch Übertragung von jeweils 2Bytes die Initialisierung des RFM02 durchgeführt. Init Bsp: CC00 Status lesen 8B61 +- 90kHz Bandbreite A640 434MHz D040 RATE/2 C823 4,8kbps C220 Bit Sync ein C001 Tx deaktivieren Die Übertragung eines oder mehrerer Bytes per HF erfolgt so: C039 Sender aktivieren (Bitweise übertragen -> siehe unten 0xAA ; Preamble 0xAA ; Preamble 0xAA ; Preamble 0x2D ; High Byte für Frame-Erkennung 0xD4 ; Low Byte für Frame-Erkennung dann ein oder mehrere Datenbytes senden ) vor dem Ausschalten des Senders kurz warten C001 Sender deaktivieren der eingeklammerte Teil wird wie folgt bitweise übergeben: Datenbyte bitweise (MSBit -> LSBit) bei jeder fallenden Clockflanke von nIRQ an den FSK Pin des Moduls anlegen, damit es bei der steigenden Clockflanke von nIRQ übernommen wird. Ich hoffe das hilft dir weiter.
hi hope, habe mich nochmal intensiv mit den datenblättern befaßt und weiß jetzt so grob worum es geht! würde nun gern mal den rfm01 testen, aber hier bin ich auch leider etwas überfragt???
Da hilft wohl nur ein Rezept: beim RFM01 gehe ich wie folgt vor: Init Bsp: -> SPI (per SPI die folgenden Kommandos an den RFM01 schicken) 0000 null: Status auslesen 898A Config 433 MHz Band 134kHz Bandbreite Clk out aus A640 434MHz C847 4,8kbps C69B AFC C42A Clock recovery manual control, Digital Filter DQD=4 CE84 FIFO sync word CE87 FIFO fill und enable C081 Rx aktivieren Das Empfangen eines Bytes per HF erfolgt danach so: ; auf fallende Flanke von nIRQ warten -> SPI Chip Selct Low 0000 null: Status auslesen 0000 null: Status auslesen 0000 null: Datenbyte lesen <- SPI Chip Select High -> SPI CE84 FIFO sync word CE87 FIFO fill und enable fertig, das Datenbyte liegt im SPI Eingangsregister Diese Init-Routinen benutze ich unverändert auch für die RFM02/01 868MHz Module.
hi hope, erstmal danke für die schnelle antwort! :-) wie du ja bereits mitbekommen hast, bin ich noch nich so bewandert in diesen geschichten, deswegen bitte ich darum, es mir nicht übel zu nehmen wenn ich mal ne dumme frage stelle. wenn ich dein rezept richtig verstehe, muss ich nun die initialisierungsdaten in ein bascomcode verpacken und damit den atmega8 füttern welcher dann das modul rf01 steuert und konfiguriert!? richtig? habe im anhang mal nen testcode hochgeladen, welchen ich gefunden habe.....soll ich diesen einfach mit deinen init daten anpassen? kannst du mir eventuell erläutern was dieser code sonst noch macht? lg
Also wenn du mit einem fertigen Programm nichts anfangen kannst, was willst du eigentlich noch? Die Programm kommst übrigens von hier: http://bascom-forum.de/showthread.php?1344-RFM-01-02-Testprogramm Für RFM12: http://bascom-forum.de/showthread.php?1600-RFM12-Codebeispiele http://bascom-forum.de/showthread.php?1630-RFM-12-PingPong-Test
hi holli, ich bat bereits in meinem vorherigem beitrag mir mein unwissen bitte nicht übel zu nehmen, ich bin halt beginner.....aber davon mal ganz abgesehen hilft es mir nicht weiter einfach etwas zu kopieren und nicht zu wissen wie es funktioniert und warum!!!! ich werde später diesen code erklären müssen bei der projektpräsentation.....deswegen kopier ich nicht einfach und gut is.....hoffe das ist nachvollziehbar. lg
Wie kommt man eigentlich zu so einem Projekt und welche Vorkenntnisse sind eigentlich vorhanden? Damit meine ich Hardware- und Programmierkenntnisse.
bezen bu schrieb: > wenn ich dein rezept richtig verstehe, muss ich nun die > initialisierungsdaten in ein bascomcode verpacken und damit den atmega8 > füttern welcher dann das modul rf01 steuert und konfiguriert!? richtig? < ja! bezen bu schrieb: > soll ich diesen einfach mit deinen init daten anpassen? < nein! bezen bu schrieb: > kannst > du mir eventuell erläutern was dieser code sonst noch macht? < nein Damit du diese Module zum Laufen bekommst, musst du es schon alleine schaffen, mehrmals hintereinander je 2Byte am Stück über die SPI Schnittstelle zu schicken und beim Umgang mit dem nIRQ Pin bei jeder fallenden Flanke ein Datenbit des zu sendenden Bytes an den FSK Pin zu legen. Die beiden Rezepte sollten lediglich eine Hilfestellung zur Vorgehensweise sein, da die Fehlersuche bei solchen Systemen nicht ganz einfach ist, wenn man nicht weiss, ob nicht gesendet oder nicht empfangen wird.
@ holli : technikerschule..vorhanden sind grundlagen der nachrichtentechnik und übertragungstechnik, sowie grundlagen digitaltechnik und microcontrollertechnik (assembler), ausserdem grundlagen c-programierung... @ hope : danke für die infos....werd mal weiter testen und ausprobieren, hoffe bei problemchen kann ich dich mal fragen.....werde meine ergebnisse auch hier mitteilen.... lg
Hallo bezen bu, mir geht es exakt so wie du in deinem ersten Posting geschrieben hast! Ich habe auch die beiden Funkmodule RFM01 und 02 hier vor mir liegen und weiß nicht recht wie ichs angehen soll.Bist du denn inzwischen schon weiter gekommen? viele Grüße
hi merlin, hab über die feiertage nix gemacht, werd mich spätestens übermorgen wieder mit der thematik beschäftigen und dann schreiben was bei rumkam....irgendwie werden wir das schon hinbekommen! ;-)
Hallo nochmal,
ich habe mich heute mal mit dem o.a. testprogramm beschäftigt....ich
habe den rfm01 initialisiert und versuche seitdem den code zu
verstehen...ich frage mich was genau getestet wird und wie ich
feststellen kann ob der test erfolgreich ist oder nicht!?
am meisten interessiert mich die schleife mit der led....
Do
Toggle Led
For Count = 1 To 32
Bitwait Nirq , Reset
'While Nirq = 1
'Wend
Spiin Fifo(1) , 3
Rx(count) = Fifo(3)
Next
Call Rf_cmd(&Hce89)
Call Rf_cmd(&Hce8b) 'Reset FIFO
For Count = 1 To 32
Print Chr(rx(count)) ;
Next Count
Print
Loop
was bedeutet dieser code?
nach jedem reset blinkt die led kurz auf und zeitunabhängig geht sie
dauerhaft an und nach einer weile wieder aus?!?!
weiß aber leider nicht warum und weshalb!?
@ hope: kannst du mir vielleicht das empfangen von HF signalen etwas
genauer erläutern?
stehe da noch so etwas auf dem schlauch! :-(
gruß
bezen bu schrieb: > @ hope: kannst du mir vielleicht das empfangen von HF signalen etwas > genauer erläutern? Wenn du mir die Frage etwas genauer erläuterst. ansonsten: HF-Signal -> Synchronisation -> Demodulation (Trennung von Takt und Daten) -> füllen des FIFOs
Hallo bezen bu schrieb: > technikerschule..vorhanden sind grundlagen der nachrichtentechnik und > übertragungstechnik, sowie grundlagen digitaltechnik und > microcontrollertechnik (assembler), ausserdem grundlagen > c-programierung... Warum versuchst du dann in Basic zu programmieren? Diese Programmiersprache erwähntest du doch gar nicht zu deinen Vorkenntnissen?!? Ansonsten: Wie fit bist du denn in Assembler? Da hätt ich nämlich was für dich: Beitrag "[ASM] RFM02 sendet an RFM01 Sensor Daten" Gruß Steffen
@ hope: Hope schrieb: > ; auf fallende Flanke von nIRQ warten > > -> SPI > Chip Selct Low > 0000 null: Status auslesen > 0000 null: Status auslesen > 0000 null: Datenbyte lesen <- SPI > Chip Select High > > -> SPI > CE84 FIFO sync word > CE87 FIFO fill und enable > > fertig, das Datenbyte liegt im SPI Eingangsregister mir ist nicht so ganz bewußt wie ich mit diesen angaben umgehen soll...auf die fallende flanke des interrupts warten kann ich noch nachvollziehen....für was genau ist chip select low/high zuständig? die daten müssen doch ins fifo register, richtig? an welchem pin des empfängers ist das spi eingangsregister? danke im vorraus. lg
@ steffen: richtig, bascom habe ich nicht erwähnt. unser lehrer hat uns empfohlen mit bascom zu arbeiten, auch wenn wir das neu lernen müssten, da in bascom einige dinge einfacher umzusetzen seien als in den anderen programmiersprachen....somit fing ich an mich mit bascom zu beschäftigen....also suche ich momentan noch eine bascom lösung...dein thread werd ich mir allerdings auch nochmal genauer anschauen morgen! danke für deine hilfe! lg
bezen bu schrieb: > für was genau ist chip select low/high zuständig? Damit wählt der Mikrocontroller aus, für welchen Chip die Daten die er per SPI übertragen will gedacht sind. z.B. Aufbau aus Mikrocontroller, RFM und LC-Display(mit SPI Interface). Dann existieren zwei CS Leitungen. Eine zum RFM und eine zum Display. zur Übertragung von Daten an das Display wird dann die CS-Leitung des Displays auf Low gelegt, per Clock- und Datenleitung ein oder mehrere Bytes übertragen und dann CS wieder auf High gelegt. Werden Daten an das RFM übertragen, so wird eben dessen CS-Leitung benutzt. Am Display liegen zwar auch diese Daten, aber dieses "hört nicht zu", weil es per CS nicht selektiert ist. Am Besten du eignest dir mal SPI-Grundlagen an, z.B. hier: http://de.wikipedia.org/wiki/Serial_Peripheral_Interface
bezen bu schrieb: > unser lehrer hat uns empfohlen > mit bascom zu arbeiten, auch wenn wir das neu lernen müssten, da in > bascom einige dinge einfacher umzusetzen seien als in den anderen > programmiersprachen.... Was dieses Forum und Hilfe im Internet betrifft, keine so gute Empfehlung... die Bascom-Fraktion ist hier zwar vertreten, aber viele Forumsteilnehmer kommen auch aus der Industrie, und da ist in diesem Fall halt C der Standard... oder Assembler, für diverse Spezialfälle und wenn's zeitkritisch ist.
@ hope vielen dank für den tip, dass hat mir sehr weitergeholfen, nun ist mir einiges klarer. nun muss ich nur noch schauen wie ich das mit bascom programiere, hierfür bräuchte ich noch unterstützung! wie bzw. womit programierst du die module? ach übrigens: Hope schrieb: > -> SPI > Chip Selct Low > 0000 null: Status auslesen > 0000 null: Status auslesen > 0000 null: Datenbyte lesen <- SPI mir ist noch unklar warum ich mehrmals den status auslese?! hier hab ich noch verständnisprobleme!? @ sebastian das problem ist, das ich mich nun auf bascom eingeschossen hab und mir kaum die zeit bleibt umzuschwenken! :-/ ich habe ja schon eine menge threads zum thema bascom hier gelesen, da waren codes dabei, welche absolut lang, kompliziert und komplex waren, welche erklärt wurden.... da sollte mein kleiner code doch eigentlich eine kleinigkeit sein.....ist ja nichts hoch komplexes (für jemand der ahnung hat, für mich schon :-)) deshalb hoffe ich immernoch auf etwas was hilfe! lg
bezen bu schrieb: > wie bzw. womit programierst du die module? mit MPLAB die PICs und mit AVR-Studio 5 die Atmels (beide in Assembler) bezen bu schrieb: > mir ist noch unklar warum ich mehrmals den status auslese? weil beim Senden zunächst 24Bit lang ein 1010... Muster gesendet wird, die Preamble: 0xAA 0xAA 0xAA damit kann sich der Empfänger auf das Signal bzw. dessen Takt einstellen (PLL Lock). Dann folgt ein 16Bit langes Synchronisiermuster: 0x2D 0xD4 Dieses ermöglicht es dem FIFO, sich auf den Datenstrom zu synchronisieren. Das Kommando "Status lesen" dient nicht nur zum Lesen des Status Registers, sondern auch zum löschen des Interrupts. D.h. die ersten beiden Aufrufe: > 0000 null: Status auslesen dienen genau genommen nicht dazu den Status zu lesen, sondern die Interrupts zu löschen, die durch das Synchronisiermuster verursacht werden. der nächste Aufruf: > 0000 null: Status auslesen ist ein Dummy-Kommando, das im Gegenzug das Datenbyte über die SPI-Schnittstelle zurück liefert. Das ist im Datenblatt der Module ausführlich beschrieben.
danke für die info, muss allerdings etwas nachfragen....da du alles in assembler machst, wirst du mir bei bascom wohl nicht helfen können, aber deine grundsätzlichen infos sind sehr nützlich, werde versuchen diese in bascom umzusetzen. verstehe ich es richtig, das immer erst die syncinfos kommen und im anschluss die eigentlichen nutzdaten? ich habe mal in den datenblättern geschaut nach der ausführlichen beschreibung, aber hab nichts gefunden. hab von hope den o.a. rf01 programming guide....hast du andere unterlagen?
>verstehe ich es richtig, das immer erst die syncinfos kommen und im >anschluss die eigentlichen nutzdaten? JA! sowie das Modul die Synchrobytes empfängt werden die nachfolgenden Daten in den FIFO geschrieben. Hat der den, beim init programmierten Füllstand erreicht, wird NIRQ low. Das Syncmuster selber wird nicht im FIFO abgespeichert sondern ist nur der "Empfangstrigger".
Angehängte Dateien:
-
package.jpg
17 KB
bezen bu schrieb: > ....hast du andere unterlagen? Nein, aber die Info die es auf der Hope RF Seite gibt ist völlig ausreichend. Da gibt es noch einige weitere Dokumente z.B. eines über den "RF02 Universal ISM Band FSK Transmitter", wo solche Dinge erklärt sind.
Angehängte Dateien:
-
terminal.jpg
190 KB
danke für die info....ich tu mich noch recht schwer mit den datenblättern...aber mühsam ernährt sich das eichhörnchen....noch ne frage zum fifo register...wie groß ist dies beim atmeg8? habe übrigens eine verbindung von rfm01 und rfm02 hinbekommen, läuft recht gut und ich habe die codes aus folgendem thread verwendet. http://bascom-forum.de/showthread.php?1344-RFM-01-02-Testprogramm habe allerdings noch das problem, das nicht alle datenpakete so ausgegeben werden wie sie sollen....habe zwischendrin immerwieder komische dreiecke auf der seriellen ausgabe und hab kein plan woran das liegt!? hat jemand ne idee??? screenshot ist im anhang... lg
bezen bu schrieb: > danke für die info....ich tu mich noch recht schwer mit den > datenblättern...aber mühsam ernährt sich das eichhörnchen....noch ne > frage zum fifo register...wie groß ist dies beim atmeg8? der/das FIFO bezieht sich zunächst auf das FIFO-Register im RFM-Modul. mit dem SPI Befehl CE87 wird u.A. der FIFO-Interupt auf 8 bit programmiert (bits f3-f0) so daß dann, beim Erreichen dieses Füllstands die Pins FFIT, SDO & NIRQ auf low gehen. Nach dem SPI Auslese Befehl hast Du im Mega8 den FIFO Inhalt dann entweder mit Hard-Spi im 8bit SPI Register SPDR oder Du schreibst es mit der Soft SPI in eine Variable. Welches (8 bit) Register Bascom hierfür auswählt müsstest Du Dir in der Simulation anschauen.
Angehängte Dateien:
-
Unbenannt.png
120 KB
danke max! :-) wieder etwas schlauer! hast du vielleicht ne idee, warum ich fehler in meiner seriellen ausgabe habe? habe mal ein besseres bild des terminalprogramm angehängt sowie die verwendeten codes! lg
bezen bu schrieb: > danke max! :-) > > wieder etwas schlauer! > > hast du vielleicht ne idee, warum ich fehler in meiner seriellen ausgabe > habe? vielleicht solltest Du, nachden das letzte byte ins array geschrieben wurde den receiver ausschalten oder den FIFO reseten.
obwohl, sollte ja der Code Call Rf_cmd(&Hce88) Call Rf_cmd(&Hce8b) 'Reset FIFO eigentlich machen > > vielleicht solltest Du, nachden das letzte byte ins array geschrieben > wurde > > den receiver ausschalten > oder > den FIFO reseten.
Evtl. empfängt dein RFM01 auch Daten von "Fremd Sendern". Dann musst du beim Senden einen "Schlüssel" mit in deine eigenen Daten packen, mit dessen Hilfe du beim Empfangen deine eigenen Daten von fremden Daten unterscheiden kannst.
Hope schrieb: > Dann musst du beim Senden einen "Schlüssel" mit in deine eigenen Daten > packen, mit dessen Hilfe du beim Empfangen deine eigenen Daten von > fremden Daten unterscheiden kannst. ok, das könnte eventuell sein!? einen schlüssel in meine daten packen hört sich für mich als anfänger doch reichlich kompliziert an....werd mal suchen...oder hast du vielleicht nen hilfreichen link oder thread parat? lg
Nein, ist nicht kompliziert. Du musst lediglich ein oder mehrere dir bekannte Bytes mit in deine Datenpakete packen, egal, ob am Anfang, Ende oder irgendwo dazwischen. Wenn du dann Daten empfängst und sie enthalten diese Daten an der richtigen Stelle, so sind es deine Daten.
sorry, aber das verstehe ich nicht so ganz!? wenn ich die mir bekannten 32Byte sende, kommen diese ja ab und zu genauso an, aber mal kommen sie richtig an und ein anderes mal werden die daten als komische dreiecke dargestellt?! was würde es nun ändern wenn ich ein zusätzliches Byte einfüge? lg
also ich sende ja alle 2 sekunden dieses 32Byte Datenpaket, mal kommt es genauso an und 2sekunden später spuckt er mir diese Dreiecke aus...und so wechseln sich die richtigen Daten und die Dreiecke alle 2 sekunden ab!
Demnach scheinen es schon deine Daten zu sein und es liegt kein Empfang von Fremdaten vor. Dann würde ich die Fehlersuche im Bereich des FIFO Resets fortsetzen, wie Max oben schon geschrieben hat. Was passiert, wenn du nur wenige Datenbytes sendest? Kommen die dann korrekt an?
Originaldaten mit 2 Sekunden Echoverzögerung als Dreiecke? he he, da arbeiten andere Funkamateure Jahre drauf hin in Erde Mond Erde Experimenten, und das mit einem RFM01/2. Respekt Namaste
Hope schrieb: > Was passiert, wenn du nur wenige Datenbytes sendest? Kommen die dann > korrekt an? ich habs nun mit 16 und mit 8 Bytes versucht.....allerdings derselbe effekt, die Daten kommen mal richtig an und mal als Dreiecke, ausser das die Dreiecke auch weniger werden! was könnte ich noch tun?
Angehängte Dateien:
-
8byte.png
50 KB
Winfried J. schrieb: > mach mal nen schuß davon hab ich oben schon bei 32 Byte....hier nochmal bei 8 Byte!
ach die dreiecke das sind asscii zeichen mit dem code 0x10 (dec 17) entweder spuckt dein Sender sie ungewollt aus oder sie kommen von einem fremden Sender das reproduzierbar empfangen werden: -> sender abschalten bleiben sie aus? nein: -> fremder sender -> filtern ja: -> weitersuchen Funkstrecke rausnehmen und sender und empfänger direkt vebinden bleiben sie aus? nein: -> in der Senderansteuerung oder im Empfänger weitersuchen. ja: -> modulansteurung untersuchen schläft das modul automatisch ein? wenn nicht gesendet/empfangen wird?
Winfried J. schrieb: > Originaldaten mit 2 Sekunden Echoverzögerung Vielleicht sollte man erstmal das was oberhalb steht lesen, bevor man einfach drauf los tippt
hallo winne, also ich verzweifel noch...die dreiecke sind 0x10 (dec 16), hab den hexwert mit in den code eingebaut und es kommen tatsächlich dreiecke dabei raus, also weiß ich schonmal was die dreiecke sind! wenn ich den sender ausschalte kommt nix mehr..... die funkstrecke rausnehmen und direkt verbinden krieg ich irgendwie nicht hin, also das verbinden schon, aber ich weiß nicht genau wie ich das programm hierfür schreiben muss bzw. wie ich die spi schnittstelle programieren muss?! die module schlafen meiner meinung nach nicht ein wenn nichts gesendet oder empfangen wird! beide befinden sich in schleifen und es wird alle 2 sekunden gesendet und empfangen.....ein ändern dieser zeit hat auch nichts bewirkt! :-(
ohne die schaöltung zu sehen kann ich nur ins blaue schießen wichtig wäre zu wissen ob die funkstreke teil des problem ist oder nicht Außerdem weiss ich nicht wie du die Spi via Funkstrecke synchronisierst. auch das kann ein Problem sein. also schaltbilder und sämtliche Code von sender und empfänger kommen in frage, bis du etwas davon ausschließen kannst ein paar Schuss mit dem Osziloskop war was ich ursprünglich meinte, von unterschiedlichen messpunkten wären hilfreich oder eben dort sniffen wo man rankommt am RF_Sendereingang zum beispiel liese sich der sendende µC ausschließen am reciverausgang liese sich alles aussschließen was in der funkstrecke und davor liegt problematisch sehe die Clokregenerierung aber ev. mach das rf modul das ja auch??? dan könnte noch das clock signal im empfänger falsch ausgewertet werden Variante Halfclock controllieren je nach einstellung wechseln die Daten syncron mit dem Clock oder in der mitte des Bits ein Fehler hier könnte die fehl interpretetertion erklären erstaunlich ist aber das die fehlerhafte flanke reproduzierbar in der mitte des Bytes liegt. ?? keine Ahnung was da bei dir auf dem Tisch passiert.
hi winne, damit du weißt was bei mir passiert! ich habe 2 funkevaluationsboards von pollin mit jeweils einem atmega8 drauf und ner quarzfrequenz von 12mhz, auf dem einen ist der rfm01 auf dem andren der rfm02. die empfangenen daten gebe ich an die serielle schnittstelle weiter. etwas weiter oben, habe ich die verwendeten codes gepostet, hier ist auch die spi programmierung zu sehen falls es dich interessiert. ich finde deine idee mit der direktverbindung nicht schlecht, habe auch ein ide-kabel zum verbinden beider ports, da ich das allerdings noch nie gemacht habe, weiß ich nicht wie ich die spi's der beiden atmegas programmieren soll?!? momentan habe ich leider nicht die möglichkeit mit dem oszi zu messen, nächste woche habe ich allerdings ein digitales speicheroszi zur verfügung, dann mach ich paar schüsse wenn das problem bis dahin noch besteht, was ich nicht hoffe....hab nämlich bereits am 21. ne zwischenpräsentation....da sollte es funzen.... @ hope: hast du nichgt noch ne idee? du hast dich ja auch ne weile mit den modulen beschäftigt?!? lg
bezen bu schrieb: > also ich verzweifel noch...die dreiecke sind 0x10 (dec 16), hab den > hexwert mit in den code eingebaut und es kommen tatsächlich dreiecke > dabei raus, also weiß ich schonmal was die dreiecke sind! beim ini code CE88 ist das lsb 10001000 -> Zufall? was ändert sich wenn Du stattdessen mit CE89 initialisierst? For Count = 1 To 32 While Nirq = 1 Wend Spiin Fifo(1) , 3 Rx(count) = Fifo(3) Next Call Rf_cmd(&Hce88) <-- hier mal &HCE89 probieren! Call Rf_cmd(&Hce8b) .... übrigens, zum Thema Datasheets: Beitrag "Beispielprogramm für RFM12 433MHz Funk-Module" Die Pollin Module sind von Hoperf. Hoperf wiederum verbaut Chips von Silicon Labs. RFM01 -> Si4320 RFM02 -> Si4021 RFM12 -> Si4420 Die Dokumentation ist besser und die Diagramme lassen sich erkennen. Auch gibt es ein Konfigurationstool, mit denen sich anhand von Einstellungen die Registerwerte berechnen lassen.
Max schrieb: > beim ini code CE88 ist das lsb 10001000 -> Zufall? Der Originalcode ist von mir, es müsste tatsächlich eigentlich &HCE89 sein. Bei den anderen Versionen die ich noch habe ist es auch so. Aber ich glaube es hat auch so funktioniert, komisch. Ist aber auch schon eine lange Zeit her.
Holli schrieb: > es müsste tatsächlich eigentlich &HCE89 Die 9 hinten darf aber laut Datenblatt nicht sein: die hinteren 8Bit lauten: f3 f2 f1 f0 s1 s0 ff fe die f Bits sind der FIFO IT Level und dann kommen die beiden s Bits für die "FIFO fill start condition" und die auf 1 0 zu setzen ist verboten. s1 s0 = 1 0 ist reserved. 89 wäre 1000 1001 ^^ Hier initialisiere ich mit 0 1 (Sync Word) Dann sieht der FIFO Reset so aus: cmd: CE 84 Bits ff und fe Null setzen -> FIFO ausschalten und seinen Zähler und Inhalt löschen cmd: CE 87 Bits ff und fe Eins setzen -> FIFO einschalten und Füllen ab dem Synchron Word erlauben Damit läufts bei mir problemlos.
hi max, hi holli, wenn ich den code auf ce89 ändere, kommen nur noch dreiecke an und kein richtiges datenpaket mehr!:-( es ist echt zum verrückt werden...ich hab schon die datenmenge geändert, das bitwait länger und kürzer gemacht, sender und empänger eng aneinander und weit entfernt und und und....ich versteh auch nicht warum die falschen daten immer diese dreiecke sind (hex 10 dez 16)????
bezen bu schrieb: > kein > richtiges datenpaket mehr!:-( ----> Initialisierung des Senders oder des Empfängers oder beide fehlerhaft. siehe oben
hi hope, habe nun bei der initialisierung deine codes angewendet (CE84 und CE87) allerdings auch in der schleife und leider immernoch die hex 10 werte (dreieck)! :-( allerdings hab ich den eindruck das mehr richtige datenpakete ankommen!? du hast geschrieben falsche initialisierung des senders??? die codes haben sich doch nur auf den fifo, also empfänger bezogen,oder? habe nochmal die geänderten codes angehangen.
bezen bu schrieb: > hi max, hi holli, > > wenn ich den code auf ce89 ändere, kommen nur noch dreiecke an und kein > richtiges datenpaket mehr!:-( und wie verhält sich CE87?
Hope schrieb: > > Die 9 hinten darf aber laut Datenblatt nicht sein: > > die hinteren 8Bit lauten: f3 f2 f1 f0 s1 s0 ff fe > > die f Bits sind der FIFO IT Level und dann kommen die beiden s Bits für > die "FIFO fill start condition" und die auf 1 0 zu setzen ist verboten. > s1 s0 = 1 0 ist reserved. > > 89 wäre 1000 1001 scheint so ein undokumentierter Code zu sein. laut Datenblatt reseved aber im RFM01_Eva (controller-designs.de) als Startcondition: VDI + Syncword angegeben
bezen bu schrieb: > du hast geschrieben falsche initialisierung des senders??? die codes > haben sich doch nur auf den fifo, also empfänger bezogen,oder? Nein, weiter oben (Datum: 15.12.2011 23:30) habe ich die Init-Werte und Vorgehensweise für den Sender RFM02 beschrieben. und am (Datum: 21.12.2011 19:14) die Init-Werte und Vorgehensweise für den Empfänger RFM01. Den Code benutze ich unverändert !!! (auch diese Zeile: A640 434MHz) für die 868MHz Module. Da ist dann lediglich der Kommentar falsch. Von deinen beiden Init-Sequenzen weichen die aber deutlich ab.
Hope schrieb: > > Den Code benutze ich unverändert !!! (auch diese Zeile: A640 434MHz) > für die 868MHz Module. Da ist dann lediglich der Kommentar falsch. > > Von deinen beiden Init-Sequenzen weichen die aber deutlich ab. A640 bedeutet aber 434 MHz. Der Empfänger auf 868 MHz bekäme dann nur die schwächere 2. Oberwelle, die Reichweite sinkt somit. Dürfte aber nichts mit den mysteriösen Dreiecken zu tun haben. Einfach mal mit den beiden Ini Werten rumspielen: Könntest ja auch mal die Kombination CE88 zusammen mit CE8A probieren ?
Hope schrieb: > Das Empfangen eines Bytes per HF erfolgt danach so: > > ; auf fallende Flanke von nIRQ warten > > -> SPI > Chip Selct Low > 0000 null: Status auslesen > 0000 null: Status auslesen > 0000 null: Datenbyte lesen <- SPI > Chip Select High > > -> SPI > CE84 FIFO sync word > CE87 FIFO fill und enable > > fertig, das Datenbyte liegt im SPI Eingangsregister So hatte ich den Datenempfang oben beschrieben. Damit wird ein einzelnes Datenbyte empfangen. Wenn mehrere wie bei dir gesendet werden, hier z.B. 3 Datenbytes, müsste diese Sequenz so aussehen: ; auf fallende Flanke von nIRQ warten -> SPI Chip Selct Low 0000 null: Status auslesen 0000 null: Status auslesen 0000 null: Datenbyte lesen <- SPI erstes Datenbyte ; auf fallende Flanke von nIRQ warten 0000 null: Datenbyte lesen <- SPI zweites Datenbyte ; auf fallende Flanke von nIRQ warten 0000 null: Datenbyte lesen <- SPI drittes Datenbyte Chip Select High -> SPI (FIFO Reset) CE84 FIFO sync word CE87 FIFO fill und enable Das bedeutet: vor den weiteren Datenbyte erneut auf nIRQ warten !
Max schrieb: > Hope schrieb: >> > > A640 bedeutet aber 434 MHz. > Der Empfänger auf 868 MHz bekäme dann nur die schwächere 1. Oberwelle, > die Reichweite sinkt somit. > Ah, Korrektur: ist nur die Center Frequency je nach im Config gewähltem Band doch 868 oder 434 MHz!! Schon länger nicht mehr damit befaßt ...
hi hope, Hope schrieb: > ; auf fallende Flanke von nIRQ warten > > -> SPI > Chip Selct Low > 0000 null: Status auslesen > 0000 null: Status auslesen > 0000 null: Datenbyte lesen <- SPI erstes Datenbyte > > ; auf fallende Flanke von nIRQ warten > > 0000 null: Datenbyte lesen <- SPI zweites Datenbyte > > ; auf fallende Flanke von nIRQ warten > > 0000 null: Datenbyte lesen <- SPI drittes Datenbyte > Chip Select High > > -> SPI (FIFO Reset) > CE84 FIFO sync word > CE87 FIFO fill und enable ich krieg es irgendwie nicht hin das in nen code zu verpacken.....sender hab ich hinbekommen, der arbeitet, aber empfangen bräuchte ich etwas hilfe bitte! lg
Hope schrieb: > > > > Das bedeutet: > vor den weiteren Datenbyte erneut auf nIRQ warten ! For Count = 1 To 8 While Nirq = 1 <-- macht es das hier nicht?? Wend Spiin Fifo(1) , 3 Rx(count) = Fifo(3) Next
bezen bu schrieb: > habe nochmal die geänderten codes angehangen. Probiere doch mal die originalen Programme ohne irgendwelche Änderungen. Und auch mal die aus der Datei "RFM01_02_12_868MHz.rar" im Bascom Forum. Ich habe im Moment keine Module zum Testen hier. Außerdem müsste der Pin 6 (nFFS) auf high gesetzt werden.
Hi Holli, wenn der Code von Dir kommt, vielleicht kannst Du mir sagen warum das Bit fe für "deep 16 Bit FIFO Mode" je nach Programm mal gesetzt und dann wieder nicht gesetzt wird ?? Wird ja im RFM12 anders gemacht!
Angehängte Dateien:
-
rfm02-01.png
53 KB -
rfm12-01.png
56 KB
Max schrieb: > wenn der Code von Dir kommt, vielleicht kannst Du mir sagen warum das > Bit fe für "deep 16 Bit FIFO Mode" je nach Programm mal gesetzt und dann > wieder nicht gesetzt wird ?? Du meinst weil es einmal &Hce89 und &Hce88 gibt? Zufall, ich habe auch mit den Einstellungen etwas experimentiert. Es hat funktioniert sonst wäre das so nicht drin. Ich habe die Dateien von Logikanalysator gefunden, hier mal 2 Beispiele. In der oberen Hälfte ist der Sender, unten der RFM01. Wie man sieht, funktioniert beides.
Ah, interessant! der RFM 02 kommt auch gut mit den kurzen Nirq-Pulsen zurecht! Hatte da bei 4MHz ohne half rate schon Probleme. Was passiert eigentlich wenn Pin 6 (nFFS) floatet?
so, mal wieder viel rumprobiert....also wenn ich den in rar gepackten original code verwende, gibt er mir nur irgendnen zeug raus...nicht die daten..... wenn ich den anderen original code (434MHz) verwende wird zwar etwas gesendet und empfangen, aber nichts ausgegeben! :-/ würde gern noch das beispiel von hope versuchen, aber wie bereits gesagt, krieg ich die rf anweisung nicht in nen code verpackt und hope scheint schon offline zu sein. @holli und max könnt ihr mir hierbei helfen?
> > würde gern noch das beispiel von hope versuchen, aber wie bereits > gesagt, krieg ich die rf anweisung nicht in nen code verpackt und hope > scheint schon offline zu sein. > welche anweisung meinst Du denn? ging es da nicht um CE84 CE87 als ini ?
Max schrieb: >> >> würde gern noch das beispiel von hope versuchen, aber wie bereits >> gesagt, krieg ich die rf anweisung nicht in nen code verpackt und hope >> scheint schon offline zu sein. >> > > welche anweisung meinst Du denn? > > ging es da nicht um CE84 > CE87 als ini ? sehe gerade, das hast Du ja schon probiert. und auf das nächste Datenbit wartest Du ja mit der while Schleife. Könntest ja auch mal die Kombination CE88 zusammen mit CE8A probieren
Nee, meinte das hier: Hope schrieb: > beim RFM01 gehe ich wie folgt vor: > > Init Bsp: > -> SPI (per SPI die folgenden Kommandos an den RFM01 schicken) > > Das Empfangen eines Bytes per HF erfolgt danach so: > ; auf fallende Flanke von nIRQ warten > > -> SPI > Chip Selct Low > 0000 null: Status auslesen > 0000 null: Status auslesen > 0000 null: Datenbyte lesen <- SPI > Chip Select High > > -> SPI > CE84 FIFO sync word > CE87 FIFO fill und enable > fertig, das Datenbyte liegt im SPI Eingangsregister Die init Daten bekomm ich noch hin, aber das empfangen der Daten bekomme ich nicht programmiert!?weiss nicht wie ich es programmieren muss!?
bezen bu schrieb: > gibt er mir nur irgendnen zeug raus...nicht die > daten..... Ist auch kein Wunder, deshalb: $baud = 19200, du hast zuletzt $baud = 9600 drin. bezen bu schrieb: > weiss nicht wie ich es programmieren muss!? Die Programmierung passt, die ist so wie es sein soll. Und bei mir hat es immer zuverlässig funktioniert.
bezen bu schrieb: > Nee, meinte das hier: > > >> >> -> SPI >> Chip Selct Low >> 0000 null: Status auslesen >> 0000 null: Status auslesen >> 0000 null: Datenbyte lesen <- SPI >> Chip Select High >> das dürfte doch der Bascom Befehl: Spiin Fifo(1) , 3 schon so machen >fertig, das Datenbyte liegt im SPI Eingangsregister Rx(count) = Fifo(3) das 3.byte wird verwendet macht das Programm doch schon >> -> SPI >> CE84 FIFO sync word >> CE87 FIFO fill und enable entspricht Call Rf_cmd(&Hce84) Call Rf_cmd(&Hce87 sehe da keinen grossen Unterschied?!
Max schrieb: > der RFM 02 kommt auch gut mit den kurzen Nirq-Pulsen zurecht! > Hatte da bei 4MHz ohne half rate schon Probleme. > > Was passiert eigentlich wenn Pin 6 (nFFS) floatet? Der RFM liefert die nIRQ-Pulse, das Programm hat Probleme die Pulse zu erkennen wenn keine INT's benutzt werden. Das war wohl ab 4 MHz der Fall. nFFS wird meistens mit einem Pull-Up auf high gezogen. Damit kann man den FIFO korrekt lesen. Es ist noch eine 2. Methode beschrieben, da wird nFFS auf low gesetzt und der FIFO direkt gelesen. Bei nFFS high wird der FIFO zusammen mit dem Status gelesen. Ist auch so im Datenblatt beschrieben und funktioniert auch.
Holli schrieb: > > nFFS wird meistens mit einem Pull-Up auf high gezogen. Damit kann man > den FIFO korrekt lesen. Es ist noch eine 2. Methode beschrieben, da wird > nFFS auf low gesetzt und der FIFO direkt gelesen. Bei nFFS high wird der > FIFO zusammen mit dem Status gelesen. Ist auch so im Datenblatt > beschrieben und funktioniert auch. also entspricht doch Spiin Fifo(1) , 3 >> 0000 null: Status auslesen >> 0000 null: Status auslesen >> 0000 null: Datenbyte lesen <- SPI oder? @bezen bu hast Du eigentlich denn nFFS Pin über pullup auf high?
juhuuuuuuuuuuuuuuuuuuuuuu, es geht nun....hattest recht holli, lag an der baudrate ich depp! :-) gibts ja garnicht das ich das noch erleben darf!!!! vielen vielen dank! @max: Max schrieb: >>> -> SPI >>> Chip Selct Low >>> 0000 null: Status auslesen >>> 0000 null: Status auslesen >>> 0000 null: Datenbyte lesen <- SPI >>> Chip Select High >>> > das dürfte doch der Bascom Befehl: > > Spiin Fifo(1) , 3 schon so machen > > >>fertig, das Datenbyte liegt im SPI Eingangsregister > > Rx(count) = Fifo(3) das 3.byte wird verwendet > macht das Programm doch schon > > >>> -> SPI >>> CE84 FIFO sync word >>> CE87 FIFO fill und enable > > entspricht > Call Rf_cmd(&Hce84) > Call Rf_cmd(&Hce87 > > sehe da keinen grossen Unterschied?! es ist wohl so, das dieser code das bereits macht, da ich allerdings noch ein bascom anfänger bin, konnte ich das noch nicht so interpretieren und kann es immernoch nicht....muss mich mit dem gesamten code auseinandersetzen um ihn erklären zu können bei der prüfung! :-/ weiß auch nicht ob ich den nffs auf high hab???aber ich geh mal von aus, damit wird doch der fifo mode ausgewählt, oder?
Vor allem zur Hartnäckigkeit. Und solche Erfolge bringen dn größten Lerneffekt. Man lernt bei einer Fehlersuche deutlich mehr als nur den Fehler zu finden. Baudrate versieben das ist ein Klassiker, hatte ich hier allerdings nicht vermutet. Viel Spass und mach es nicht nur für die Prüfung mach es für dich. Namaste
danke an winne, max, hope und holli für eure unterstützung! :-) das war nu der erste wichtige schritt ohne den alles andere nicht funktionieren würde! jetzt hab ich ne funktionierende verbindung und kann fehlerfrei daten versenden. als nächstes muss ich die beiden codes genau verstehen, wo ja noch etwas hapert, sonst zerpflückt mich der prüfungsausschuss. hoffe da kann ich euch ab und an mal nerven! ;-) also das eigentlich entgültige ziel ist, das der rfm02 mit aktuellen gps-daten gespeißt wird und ich am empfäger rfm01 per taster die daten abrufen und an die serielle schnittstelle übermitteln kann. dort werden die daten auf eine software gegeben, welche den aktuellen standort des senders auf einer karte ausgibt. denkt ihr das ist zu machen? momentan weiß ich noch nicht wie die daten vom gps aussehen werden und wie ich in bascom programmiere, dass keine festgelegten daten, sondern sich ändernde daten übermittelt werden sollen. das mit dem taster trau ich mir noch zu.....denke ich! habt ihr sowas in der art schonmal gemacht? lg
Der Taster irritiert mich. Wenn das so sein soll, dann entprellen nicht vergessen. Die Daten vom GPs kommen als Stream von Strings. Die kann man auch zyklisch auswerten. Pufferverwaltung und Fehlerbehandlung nicht vergessen sonst erhälst du noch mehr so Datenmüll wie eben, versprochen. Also mach dir vorher darüber Gedanken was könnte passieren und wie kann man dem begegenen. Für dein Projekt ist das hier nur ein Schritt, aber du hast eine wichtige Lektion gelernt.: Fehlersuche braucht Ausdauer! berücksichtige das in deinenm persönlichen Zeitmanagment. So jetzt fahre ich eine Fehler an einem Lift suchen, die Tür öffnet sporadisch nicht und keiner weiß warum. Namaste
Winfried J. schrieb: > Der Taster irritiert mich. > Wenn das so sein soll, dann entprellen nicht vergessen. > dafür gibt's in Bascom den High-Level Befehl Debounce
Ja mit Basic kann man anfangen, macht es aber letztendlich nur schwerer gut und effektiv zu programmieren. Ich bin den Weg auch gegangen. Namaste
Winfried J. schrieb: > Ja mit Basic kann man anfangen, macht es aber letztendlich nur schwerer > gut und effektiv zu programmieren. Ich bin den Weg auch gegangen. > und, was nimmst Du jetzt: C oder Assembler? für zeitkritsches läßt sich letzteres auch in Bascom (wie in C ja auch oft gemacht) inlinen.
CVAVR und ASM Aber mit Basic habe ich vor 26Jahren auf dem 8 Bit Atari angefangen nachdem ich am ZX Spectrum blut leckte ZXSpectrum ASM war dan ziemlich schnell das Mittel der Wahl. Bei C bin ich erst vor zehn Jahrem mit dem AVR eingestiegen. Das war anfänglich dann doch schwer wegen der völlig anderen Struktur und Syntax aber inzwischen fällt es mir tausend mal leichter als Basic. Namast
Hi, @ winne Also das mit dem Taster war nur ne Idee, weiß ja noch garnicht ob und wie ich das alles realisieren kann!?ich hab auch noch keine Ahnung wie das GPS Signal aussieht!dachte ich könne das einfach mittels der rfm's transparent weiterleiten!aber wie ich schon deinen Ausführungen entnehmen kann, wird das nicht so einfach!:-/ Werde mich morgen erstmal mit den Codes auseinandersetzen frag mich z.b. Was der do Code bei Sender und empfânger bedeutet!?was bedeuten die zahlen in den Klammern der variablen? @max, hope und holli: Was sagt ihr zu mein Vorhaben? Hab ihr sowas schonmal gemacht oder kennt ihr ne nützliche Seite? Lg
bezen bu schrieb: > Also das mit dem Taster war nur ne Idee, weiß ja noch garnicht ob und > wie ich das alles realisieren kann!?ich hab auch noch keine Ahnung wie > das GPS Signal aussieht! GPS http://www.kowoma.de/gps/zusatzerklaerungen/NMEA.htm mußt wohl den NMEA-String im Sender über RS232 einlesen, zum anderen Board senden dort emfangen und wieder mit RS232 zum PC schicken. gibt hier im Forum mit dem RFM12 sowas.
bezen bu schrieb: > Was der do Code bei Sender und empfânger bedeutet!?was bedeuten die > zahlen in den Klammern der variablen? wie wo was poste mal Konkret was du meinst und die Sprache, ich müsste sonst ers danach suchen und dich fragen ob ich das richtige herrausgesucht habe. Es sollten Indizes sein wenn wir beide das gleiche meinen. In disem Fall handelt es sich um ein Variablenarray. Oder meinst du in Parameter bei Funktionsaufrufen? ??? Gruß Winne
@winne Meine das hier zum Beispiel: For Count = 1 To 8 While Nirq = 1 Wend Spiin Fifo(1) , 3 Rx(count) = Fifo(3) Next Sprich Bascom, was bedeuten die Zahlen 1 und 3 in den Klammern bei fifo und die 3 hinter fifo(1),??? Auch der subbefehl ist in meinem Code ist mir ein Rätsel!bin noch nicht so bewandert was Bascom betrifft! @ max So wie du es beschrieben hast, habe ich es vor, gucke mir dein link mal an und suche mal den thread!brauch ich also kein Taster? Lg
Das sind indizes eines linearen Arrays mit namen fifo() ferne istr count eine (Zähl)Variable deren Inhalt als indize des ebenfalls linearen Feldes(Arrays) mit Namen Rx() Achtung strings sind in der Sache nach ebenfalls linearearrays aber vom typ char es kommt also darauf an wie fifo und rx dimensioniert(definiert) wurden ich tippe mal als char respektive string. Dann würde dem Char 1 des Strings fifo der ascii-wert 3 zu gewiesen und dem char des strings Rx mit dem (zähler)wert count der der ascii wert des char welcher in fifo(3) gespeichert ist. wie ich sehe sind dir noch keinerlei Grundlagen bekannt, dafür ist dein Projekt reichlich ambitioniert. Namaste
bezen bu schrieb: > gucke mir dein link mal > an und suche mal den thread!brauch ich also kein Taster? > da das Programm die meiste Zeit in der While Nirq = 1 Wend Schleife hängt würde (ohne Interrupt)der Taster immer nur kurz nach Empfang eines Datenpakets abgefragt werden. Der Taster müsste dann immer solange gedrückt werden bis das nächste Paket ins Rx(32) array eingeschrieben wäre. Wozu also der Taster? Im Bascom auf Hilfe->Hilfethemen->language reference->SPIIN Spiin Fifo(1) , 3 Syntax: SPIIN var, bytes
bezen bu schrieb: > Meine das hier zum Beispiel: Hast Du mal einen Oszi an den Ausgang geklemmt und das zu übertragene Byte in binärer Form angesehen? Man sieht dann recht schnell, warum es "Count 1 to 8 heißt". While Nirq...Hier wird ein Interrupt abgefragt. X(y) sind in Bascom Arrays (siehe BASCOM-Hilfe). Fifo und Rx sind übrigens Bytes (bzw. Char). Im aktuellen Fall empfängt Fifo 3 Bytes, also Fifo(1), Fifo(2) und Fifo(3). Nur Fifo(3) wird in Rx gespeichert. Das erste übertragenen Zeichen ist also in Rx(1), das zweite in Rx(2) usw. Jetzt schau Dir mal an, wieviel Zeichen übertragen werden und wie hoch der Index von Rx ist. Na, alles klar?
> > Spiin Fifo(1) , 3 > > Rx(count) = Fifo(3) > > > Sprich Bascom, was bedeuten die Zahlen 1 und 3 in den Klammern bei fifo > und die 3 hinter fifo(1),??? > Auch der subbefehl ist in meinem Code ist mir ein Rätsel!bin noch nicht > so bewandert was Bascom betrifft! > macht also genau das was Hope postete: 0000 null: Status auslesen 0000 null: Status auslesen 0000 null: Datenbyte lesen <- SP
@ winne: danke für die erklärung! Winfried J. schrieb: > wie ich sehe sind dir noch keinerlei Grundlagen bekannt, dafür ist dein > Projekt reichlich ambitioniert. man wächst mit seinen aufgaben! mir fehlen noch einige grudlagen, nicht jegliche. ich werde das hinbekommen, dafür das ich vor 3 wochen noch garnichts zu diesem thema wußte, weiß ich nun schon ne ganze menge. @ max und sebastian danke für die erklärungen, habe leider erst mittwoch wieder zeit mich mit dem thema zu beschäftigen....dann werd ich aber auch mal das oszi anklemmen. ich versuch neure erklärung mal kurz zusammenzufassen. bezen bu schrieb: > For Count = 1 To 8 > > While Nirq = 1 > Wend > > Spiin Fifo(1) , 3 > > Rx(count) = Fifo(3) > > Next während nirq = 1 ist, werden 3 bytes ins fifo register geladen, jedoch nur das 3. wird in rx gespeichert und zählt count hoch bis die 8 byte nutzdaten angekommen sind. die jeweils ersten beiden bytes dienen zum löschen der interrupts des synchronisationsmusters. ist das soweit richtig? dazu noch eine frage....der sender schickt für ein datenpaket (8byte) die preamble mit 3 Byte und eine framekennung mit 2 Byte! so wie ich es verstanden hab, empfängt der fifo vor jedem nutzbyte 2 bytes zum löschen der interrupts und syncmuster, woher kommen den diese jeweiligen 2 bytes? oder ist es so, das diese 2 bytes nur einmal kommen und die nutzdaten dann grundsätzlich in fifo 3 landen? ist hoffentlich nicht zu kompliziert geschrieben! lg
bezen bu schrieb: > > > ich versuch neure erklärung mal kurz zusammenzufassen. > > bezen bu schrieb: > >> For Count = 1 To 8 >> >> While Nirq = 1 >> Wend >> >> Spiin Fifo(1) , 3 >> >> Rx(count) = Fifo(3) >> >> Next > > während nirq = 1 ist, werden 3 bytes ins fifo register geladen, jedoch > nur das 3. wird in rx gespeichert und zählt count hoch bis die 8 byte > nutzdaten angekommen sind. die jeweils ersten beiden bytes dienen zum > löschen der interrupts des synchronisationsmusters. > ist das soweit richtig? nicht ganz: solange(while) kein Nirq low kommt, also NIRQ =1 wartet das Programm in der Schleife While Nirq = 1 Wend sowie die abgefragte Schleifenbedingung NIRQ = 0 ist wird die Schleife verlassen und der nächste Prorammschritt ausgeführt > dazu noch eine frage....der sender schickt für ein datenpaket (8byte) > die preamble mit 3 Byte und eine framekennung mit 2 Byte! so wie ich es > verstanden hab, empfängt der fifo vor jedem nutzbyte 2 bytes zum löschen > der interrupts und syncmuster, woher kommen den diese jeweiligen 2 > bytes? oder ist es so, das diese 2 bytes nur einmal kommen und die > nutzdaten dann grundsätzlich in fifo 3 landen? > ist hoffentlich nicht zu kompliziert geschrieben! > schau dir mal im Mega8 Datenblatt die SPI an. um 1 bit an SDO auszulesen mußt du ein bit in SDI reinschieben. In Bascom ganz easy mit SPIIN werden 8 Nullen in den slave (RFM) getaktet und im Gegenzug die Daten vom RFM in die variable Fifo geschrieben.
bezen bu schrieb: > oder ist es so, das diese 2 bytes nur einmal kommen und die > nutzdaten dann grundsätzlich in fifo 3 landen? Spiin Fifo(1) , 3 bedeutet daß jedesmal Spiin Fifo(1) Spiin Fifo(2) Spiin Fifo(3) ausgeführt wird. Bascom füllt also freundlicherweise damit automatisch das Fifo(4) array bis zum 3. Element auf. Außerdem, wird durch: Config Spi = Hard , .... Noss = 0 (No Slave Select),... auch noch vor dem SPI Transfer nSel am RFM auf low gesetzt und danach wieder auf high.
danke, das hab ich soweit kapiert! versteh trotzdem noch nicht um welche datenbytes es sich hier handelt! der befehl sagt ja, dass nur das dritte datenbyte vom fifo in rx gespeichert wird! der sender schickt doch in einem frame aber nur 3 byte zur sync, dann die nutzdaten welche in rx gespeichert werden sollen und dann 2 bytes zur framekennung. das würde ja bedeuten, dass vor jedem nutzbyte welches gesendet wird, 2 byte für fifo(1) und fifo(2) gesendet werden müßten???!! oder bin ich komplett auf dem falschen dampfer? naja, heute messe ich mal bissl mit dem oszi....mal schauen ob es zum verständnis beiträgt! lg
Angehängte Dateien:
-
RFM01_SCK.JPG
1,8 MB -
RFM01_SCK_16.Impuls.JPG
2,2 MB -
RFM02_FSK.JPG
2 MB
hi, das ist echt alles zum ......! hab mich heute mal mit nem digitaloszi an meine platinen gewagt.....hab ewigkeiten rumgemessen (wer viel mißt mißt mist :-)), aber bin nicht viel schlauer geworden. denke ein logikanalysator würde eher helfen, aber den habe ich leider nicht! hätte da nochmal ne frage zu meinen messungen.... habe am rfm01 mit atmega8 an sck,mosi,miso und ss gemessen und bekomme überall meine 16 Nutzdatenbytes angezeigt, bei sck 15x 1 byte immer mit 9 impulsen...denke da ist immer ein stopbit dabei...aber das 16. mit 21 impulsen....warum??? am pin fsk des rfm02 habe ich 53 bytes je paket gezählt, hier weiß ich auch nicht wie ich auf die 53 bytes komme?! nachmeiner logik müßten es 21 sein... 3xpreamble, 2xframekennung und 16xnutzdaten!? habe mal die bilder und codes angehängt! lg
bezen bu schrieb: > das würde ja bedeuten, dass vor jedem nutzbyte welches gesendet wird, 2 > byte für fifo(1) und fifo(2) gesendet werden müßten???!! oder bin ich > komplett auf dem falschen dampfer? die kommen aber nicht vom Sender, sondern der Bascom Befehl SPIIN sendet 8 Nullen über SPI zum RFM um im Gegenzug die Daten vom RFM zu holen. Diese Nullen werden über den SDI-Pin mittels des Takt Signals an SCK in den RFM getaktet. Du hast also am SCK-Pin kein Daten-Byte sondern einen Takt. Wenn Du die zeitliche Auflösung an deinem Scope erhöhst, müsstest Du dies auch besser erkennen können. Du mußt da unterscheiden zwischen den Daten vom Sender im FIFO und der SPI Kommunikation zwischen RFM & Mega8 übrigens, was Dein eigentlich entgültige ziel betrifft: die mit Call Rf_cmd(&Ha686) gewählte Frequenz 868,35 MHz unterliegt der 1% Regel (max. 36 sec. on air / 1h) schätze bei den 4800 Baud des NMEA-Strings, mit dem dieser alle 2 sec. übertragen werden soll, dürfte diese wohl nicht allzu lang konform sein. Könnte bei Deinem Prüfungsausschuss vielleicht ja auch nicht so toll ankommen? http://www.mikrocontroller.net/articles/Allgemeinzuteilung
Max schrieb: > die kommen aber nicht vom Sender, sondern der Bascom Befehl > > SPIIN > > sendet 8 Nullen über SPI zum RFM um im Gegenzug die Daten vom RFM zu > holen. > Diese Nullen werden über den SDI-Pin mittels des Takt Signals an SCK in > den RFM getaktet. > Du hast also am SCK-Pin kein Daten-Byte sondern einen Takt. > Wenn Du die zeitliche Auflösung an deinem Scope erhöhst, müsstest Du > dies auch besser erkennen können. > > Du mußt da unterscheiden zwischen den Daten vom Sender im FIFO und der > SPI Kommunikation zwischen RFM & Mega8 merci, was würde ich nur ohne dich machen! :-) wieder etwas schlauer! Max schrieb: > übrigens, was Dein eigentlich entgültige ziel betrifft: > > die mit Call Rf_cmd(&Ha686) > gewählte Frequenz 868,35 MHz > unterliegt der 1% Regel (max. 36 sec. on air / 1h) > > schätze bei den 4800 Baud des NMEA-Strings, mit dem dieser alle 2 sec. > übertragen werden soll, dürfte diese wohl nicht allzu lang konform sein. > Könnte bei Deinem Prüfungsausschuss vielleicht ja auch nicht so toll > ankommen? auch danke hierfür, das werde ich beachten müssen! aber bevor ich dazu komme, muss ich erstmal ein code-grundgerüst finden um die nmea-strings via rs232 (uart)in den sender einzulesen und zu übertragen! ich suche mich echt dumm und dämlich.....auch ein neues bascom buch hielt nicht was es verspricht! um einen kompletten code selbst zu erstellen bin ich leider noch zu unerfahren! du hast oben geschrieben, das es hier nen thread gibt, wo dies mit nem rfm12 gemacht wurde....weißt noch zufällig welcher das genau ist? ich finde irgendwie nichts passendes?! oder kennst du threads in anderen foren die ich nicht kenne? lg
bezen bu schrieb: > du hast oben geschrieben, das es hier nen thread gibt, wo dies mit nem > rfm12 gemacht wurde....weißt noch zufällig welcher das genau ist? > ich finde irgendwie nichts passendes?! > oder kennst du threads in anderen foren die ich nicht kenne? ist allerdings in C: Beitrag "bidirektionale RS232 Funkbrücke mit RFM12" auf Bascom: http://comwebnet.co.funpic.de/RFM12/rf12Tranceiver.bas müsste wohl noch etwas auf die nmea-strings angepaßt werden, sowie den fifo-losen rfm02. vielleicht zur neuen Aufgabe 'nen neuen thread aufmachen, damit die uartleute sich auch angesprochen fühlen & tipps geben?!
hi max, Max schrieb: > müsste wohl noch etwas auf die nmea-strings angepaßt werden, > sowie den fifo-losen rfm02. was heißt fifo-losen?! Max schrieb: > vielleicht zur neuen Aufgabe 'nen neuen thread aufmachen, damit die > uartleute sich auch angesprochen fühlen & tipps geben?! hab ich schon gemacht! http://www.mikrocontroller.net/topic/goto_post/2508925 aber da kommt nicht viel, ein link betrachte ich mir mal genauer....problem ist, das die meisten ein display ansteuern....ich weiß halt nicht wie ich den rfm02 in den code bekomme!? lg
bezen bu schrieb: > was heißt fifo-losen?! der RFM02 hat keinen Sendefifo um Daten byte-weise zu verschicken, diese müssen bit-weise über FSK (oder SDI) mit der entspechenden Baudrate vom µC zum RFM02 gesendet werden. macht in dem Programm die Sub Fsk_send(byval Fsk_byte As Byte) >weiß halt nicht wie ich den rfm02 in den code bekomme!? mit dieser Sub! z.B.: ein TX-array definieren und dieses anstatt des festen Daten-Blocks (im Programm mit 'Daten bis 'Frame-Ende Kennung kommentiert) "einfach" mit einer for count=1 to (z.B.)32 Schleife (analog zum RFM01-Programm) über diese Sub senden. Da das Sendeprogramm ja schon läuft dieses nur noch um die UART-Einlesung erweitern. zB. mit UART-Interrupt, hierzu konfigurieren: Dim Tx(32) as byte 'Tx-array hier zum testen mit 32 byte 'analog zum RX(32) im RFM01-Prog. Dim n as byte 'Zählvariable On Urxc Onrxd 'Uart-Interruptroutine deklarieren Enable Urxc Enable Interrupts und dann die ISR zum einlesen, (außerhalb der do-loop Schleife): Onrxd: incr n Tx(n)=UDR 'Uart-Daten ins array einlesen return Im Hauptprogramm dann n > wert abfragen, wenn ja ->senden & danach n auf 0 setzen. gehört aber eigentlich wohl mehr in den anderen thread?!
@ max: ich werde das morgen mal versuchen umzusetzen soweit ich es hinbekomme....bin mal gespannt! schreibe dir dann was bei rumgekommen ist und ruf um hilfe! :-) vielen dank vorab schonmal! lg
hi max, hab nun den ganzen abend rumprobiert, aber krieg nix auf die reihe! :-/ kannst du mir vielleicht mal bitte ein beispiel schreiben? gern auch an meine e-mail! muß ich für die for count schleife trotzdem die preamble und die framekennung programmieren bzw. tx an und tx aus? die gps daten ($GPRMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a*hh) kommen ja im hex format, muss die variable dann nicht als string programmiert werden? ( dim tx as string * 32 ) hab auch was gelesen von: Config Serialin = Buffered , Size = 100 Enable Interrupts usw. weiß leider nicht weiter!?!?
bezen bu schrieb: > die gps daten > ($GPRMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a*hh) > kommen ja im hex format, muss die variable dann nicht als string > programmiert werden? ( dim tx as string * 32 ) nur wenn Du die Daten hier schon auswerten willst, wie zB. nur den $ GPRMC string übertragen. ist doch so wie Karl Heinz Buchegger (kbuchegg) (Moderator) & andere in dem anderen thread posten: >>"Der Brücke ist es doch völlig wurscht, welche Daten das sind. >>Zeichen von der einen UART einlesen und auf der anderen ausgeben. UNd >>das alles in einer Schleife." >muß ich für die for count schleife trotzdem die preamble und die >framekennung programmieren bzw. tx an und tx aus? nur den festen Datenblock ersetzen, das andere vorher & danach so lassen. >hab auch was gelesen von: >Config Serialin = Buffered , Size = 100 >Enable Interrupts usw. ist die von Bascom automatisch erstellte Alternative zu On Urxc Onrxd ...
hi max, vorab nochmal danke für die antwort. ich glaube ich kapier langsam was du meinst. vorerst würde ich gerne zum testen alle NMEA-Daten übertragen und wenn es dann mal funktioniert, würde ich gerne einige daten rausfiltern, aber prio hat erst mal das einlesen und senden hinzubekommen. hab mal versucht den code anzupassen nach deiner anleitung, aber es ist leider nicht alles richtig....kann nicht kompalieren......ausserdem weiß ich noch nicht, wie ich folgendes machen soll? : Max schrieb: > Im Hauptprogramm dann n > wert abfragen, > wenn ja ->senden & > danach n auf 0 setzen. in der variable n sind doch nun die daten des udr registers, welchen wert muss ich an welcher stelle abfragen? sorry nochmal, wenn ich für dich einfache dinge nicht gleich auf anhieb kapiere, geb mir mühe, aber hab halt keine erfahrung. habe den veränderten code beigefügt, wäre toll wenn du mal drüberschauen könntest. lg
bezen bu schrieb: > hab mal versucht den code anzupassen nach deiner anleitung, aber es ist > leider nicht alles richtig....kann nicht kompalieren Z.B: >For Count = 1 To 32 >Call Fsk_send(tx(32)) 'sendet nur den Inhalt v. tx(32) 32 mal! NEXT COUNT 'vergessen! Hi bezen bu, Hatte mir das zum testen so etwa vorgestellt: .... Call Rf_cmd(&Hb300) '-9 db Call Rf_cmd(&He000) 'disable wakeup timer Toggle Led Do If N > 0 Then Goto Senden N = 0 Reset Led End If Loop End Senden: 'TX an Call Rf_cmd(&Hc039) 'Preamble 3x AA Call Fsk_send(&Haa) Call Fsk_send(&Haa) Call Fsk_send(&Haa) 'HI/LOW Frame-Erkennung Call Fsk_send(&H2d) Call Fsk_send(&Hd4) 'Daten For Count = 1 To 16 'to Wert wie im RFM01-Prog. Call Fsk_send(tx(count)) 'array senden Next Count 'Frame -ende Kennung Call Fsk_send(&Haa) Call Rf_cmd(&Hc001) 'TX off Return Sub Fsk_send(byval Fsk_byte As Byte) Toggle Led .... sollte doch, zusammen mit dem vorher geposteten Uart-interrupt, Daten ans Terminal senden? Habe leider nicht die Hardware ums selber zu testen. Wenn das von Terminal zu Terminal funktioniert, dann mit GPS noch die 4800 Baud beachten und optimieren. Hast Du für Dein Projekt eigentlich keinen Betreuer?
hi max, du bist mein projektbetreuer! :-D neee, spaß beiseite....ich habe einen projektbetreuer, dieser kommt allerdings aus der nachrichtentechnik und hat von microcontrollern sowie dessen programmierung keine ahnung, leider! deswegen bin ich dir auch sehr dankbar für deine unterstützung! (den anderen im forum auch) so, ich hab den code nochmals angepaßt und das gute ist, dass ich ihn compilen kann ohne das ich ne fehlermeldung bekomme. testen kann ich das programm erst später, da an den gps-empfänger noch pins angelötet werden müssen, damit ich das serielle tx-signal abgreifen kann und auf den empfangspin des max232 und von dort an rxd am atmega8 anbringen kann! ich hab den code nochmals angehangen, damit du nochmal drüber schauen kannst, ob ich es richtig gemacht habe! ich habe allerdings noch nicht ganz kapiert, wie die daten zum sender kommen?! Max schrieb: > Onrxd: > incr n > Tx(n)=UDR 'Uart-Daten ins array einlesen > return die interupt-routine wird ausgelöst und schreibt die daten des udr in die variable tx und n? n wäre also größer als 0 und er springt zu senden, dort werden die daten in der variable tx gesendet und das 16x! ist das so richtig? lg
bezen bu schrieb: > die interupt-routine wird ausgelöst und schreibt die daten des udr in > die variable tx und n? > n wäre also größer als 0 und er springt zu senden, dort werden die daten > in der variable tx gesendet und das 16x! > ist das so richtig? nee, nicht so ganz ;-) wenn ein Zeichen im Uart buffer ist -> interrupt & dieses wird in tx(1) geschrieben, beim nächsten Interrupt in tx(2) usw. Jenachdem wie Du N > Wert abfragst wird dann dieses, bis zu tx(n)aufgefüllte array, paket-weise(mit den in der for-Schleife eingetragenen Werten)gesendet. Danach n = 0 gesetzt und auf ein Neues. So wie in dem Testprogramm wäre nur tx(1) gefüllt, gefolgt von "to Wert" mal dem (nichtdruckbaren) Ascii-Code 0 Zeichen als Übertragungs-Artefakt. Keine Ahnung ob der GPS-Empfänger diese ignoriert? Müßte, wenn die Übertragung erst mal läuft, noch angepaßt werden. Ist daher erstmal zum Testen von Terminal zu Terminal gedacht schon mal wegen der Baudrate v. 19200 die nicht zum GPS paßt.
ok ok, dass klingt logisch! also sind die tx-werte von der variablen n abhängig!? sprich, wenn ich: ...... If N > 16 Then Goto Senden N = 0 Reset Led ...... schreiben würde, würden 16 zeichen von der uart kommen und dann erst gesendet??? Max schrieb: > So wie in dem Testprogramm wäre nur tx(1) gefüllt, gefolgt von "to Wert" > mal dem (nichtdruckbaren) Ascii-Code 0 Zeichen als > Übertragungs-Artefakt. > Keine Ahnung ob der GPS-Empfänger diese ignoriert? > Müßte, wenn die Übertragung erst mal läuft, noch angepaßt werden. bedeutet das, dass ich lediglich 1 zeichen des nmea-strings (ist ja ascii) übertragen würde mit programm wie es nun ausschaut? lg
bezen bu schrieb: > schreiben würde, würden 16 zeichen von der uart kommen und dann erst > gesendet??? 17 >bedeutet das, dass ich lediglich 1 zeichen des nmea-strings (ist ja >ascii) >übertragen würde mit programm wie es nun ausschaut? jedes string zeichen würde sofort mit den 15 angehängten artefakten gesendet, aber die artefakte auf dem Terminal wohl nicht dargestellt.
Max schrieb: > 17 warum 17? Max schrieb: > jedes string zeichen würde sofort mit den 15 angehängten artefakten > gesendet, aber die artefakte auf dem Terminal wohl nicht dargestellt. also sind diese artefakte unechte daten welche aus der for count = 1 to 16 befehl resultieren? also sowas wie platzhalter, da nur tx(1) nutzdaten enthält? konnte heute leider die gps-maus noch nicht dranhängen, kam nicht ins labor....werde das aber nun zügig tun, möchte unbedingt wissen ob des nun klappt! muß ich eigentlich zum testen des programms schon was an der baudrate ändern? die maus sendet ja mit 4800 baud! oder ist das bei dem 1 zeichen noch unrelevant!? lg
bezen bu schrieb: > warum 17? weil bei Bascom der 1. array-index 1 ist, anders als bei C wo es mit 0 anfängt & 16 NICHT > 16 ist. ;-) >also sind diese artefakte unechte daten welche aus der for count = 1 to >16 befehl resultieren? also sowas wie platzhalter, da nur tx(1) >nutzdaten enthält? sind die leeren, nicht aufgefüllten array-elemente, die durch die starre (for 1 to 16) Programmierung in Sender & Empfänger mitübertragen werden. Mit z.B. for count=1 to 1 (in Send.& Empf.) würde jedes byte einzeln ohne "anhang" übertragen. >die maus sendet ja mit 4800 baud! oder ist das bei dem 1 zeichen noch >unrelevant!? wie soll der Uart den seriellen Input korrekt decodieren, ohne die Baudrate zu kennen?? Außerdem werden die Zeichen ständig empfangen, auch wenn das Programm nur eins sofort weitersendet! Übrigens, solltest mal die RFMs mit der für solche Übertragungen auch zulässigen Frequenz initialisieren bevor sich igendwann die Nachbarn beschweren, daß Ihre Türöffner, Rollos etc. gestört werden!
Und wieder ein bischen schlauer!:-) Also wenn ich deine Aussage richtig deute, muss ich die baudrate von 19200 auf 4800 ändern im Quellcode!? Bin echt mal gespannt ob des klappt! Meine Frequenz ist nicht zulässig??? Lg
bezen bu schrieb: > Meine Frequenz ist nicht zulässig??? sofern Du denn Sender nicht nach 36 s für die restliche Stunde ausschaltest!! http://www.mikrocontroller.net/articles/Allgemeinzuteilung
Muss ich den die baudrate im Quellcode ändern auf 4800baud? Die Frequenz war so in dem beispielprorgramm drin, wie ich das sehe, gibts da von 865 bis 869mhz nicht viel Alternativen!?oder hast du nen Vorschlag welche Frequenz ich problemlos nutzen könnte? Dort wo ich das immer teste, gibt's weit und breit nichts was ich stören könnte! Lg
bezen bu schrieb: > Muss ich den die baudrate im Quellcode ändern auf 4800baud? ja, $baud=4800 in Sender QT & das andere Baud darunter löschen oder auskommentieren, da hier unnötig & auf Empf.-Terminel anschauen was kommt. >wie ich das sehe, >gibts da von 865 bis 869mhz nicht viel Alternativen!? das Band geht aber noch weiter, z.B. 869,700 - 870,000 MHZ mit max. 5mW ERP mal mit Deinem Betreuer diskutieren! >Und wieder ein bischen schlauer!:-) und, nun schlau genug um das Programm so zu erweitern, daß es nur die, auch mit Nutzdaten gefüllten array-elemente überträgt?
hallo nochmal, es hätte ja schön sein können indem es funktioniert hätte, hat es aber leider nicht! ich weiß nun dummerweise nicht, ob das problem am code, oder am gps-empfänger liegt!? ich habe ein gps-empfänger, welcher die daten seriell ausgibt und auf einen seriell-usb wandler geht, damit man das ding über den pc konfigurieren kann. habe dann den tx-ausgang des gps-empfängers mit ner klemme an rx des seriell-usb wandlers abgegriffen und auf den rxin-pin am max232 geführt, der rxout des max232 geht direkt auf den pin 2 des atmega8 (PD0 RXD). passiert ist rein garnichts, egal welche baudrate im qt usw. ...keine led hat geblinkt und es kam auch nichts beim empfangsterminal an. frage mich nun, wie ich weiter vorgehen soll? habe auch nirgendwo einen für rs-232 üblichen wert messen können?! weder am max232 noch am gps-empfänger oder dem wandler?! bin mal wieder überfragt und brauche bitte einen rat! lg
bezen bu schrieb: > es hätte ja schön sein können indem es funktioniert hätte, hat es aber > leider nicht! business as usual ;-) > ich weiß nun dummerweise nicht, ob das problem am code, oder am > gps-empfänger liegt!? brauchst doch nur den gps output direkt mit Terminalprogramm (bei 4800 Baud) anschauen! kannst auch ins Prog. eine Sende-Testfunktion einbauen: im Konfig.-Bereich eintragen: T1 Alias Pinb.1 'Taster T1 und in der do-loop: ...... Reset Led End If Debounce T1 , 1 , Senden Loop End > habe auch nirgendwo einen für rs-232 üblichen wert messen können?! > weder am max232 noch am gps-empfänger oder dem wandler? mit scope/logicanalyser rx & tx von gps & wandler angeschaut? bekommt gps-empf. auch strom?
hi max, schön wieder von dir zu lesen, dachte schon ich nerv dich zu sehr! :-) ich werde deine tips natürlich versuchen umzusetzen. Max schrieb: > brauchst doch nur den gps output direkt mit Terminalprogramm (bei 4800 > Baud) anschauen! werd ich später im labor basteln. Max schrieb: > im Konfig.-Bereich eintragen: > > T1 Alias Pinb.1 'Taster T1 > > und in der do-loop: > > ...... > Reset Led > End If > Debounce T1 , 1 , Senden > Loop > > End ist dies ein test um auszuschließen, dass die interruptroutine spinnt!? Max schrieb: > mit scope/logicanalyser rx & tx von gps & wandler angeschaut? > bekommt gps-empf. auch strom? ja, das werd ich mal tun später! strom bekommt er über den usb-port, würde erklären warum die spannungen so niedrig sind (ca. 5,3V). damit könnte ich doch auch ohne max232 auf den atmega, oder? lg
@ max: hätte da noch ne frage...bei dem alten programm, welches ich ja für die zwischenpräsentation verwende, wollte ich einen text senden, welcher 37 byte hat! allerdings werden nur 32 byte fehlerfrei übertragen bzw. richtig bei hyperterminal ausgegeben. liegt das an der konfiguration das nur 32 byte funktionieren? beim empfänger habe ich for count = 1 to 37 eingestellt! lg
bezen bu schrieb: > @ max: > hätte da noch ne frage...bei dem alten programm, welches ich ja für die > zwischenpräsentation verwende, wollte ich einen text senden, welcher 37 > byte hat! allerdings werden nur 32 byte fehlerfrei übertragen bzw. > richtig bei hyperterminal ausgegeben. > liegt das an der konfiguration das nur 32 byte funktionieren? > beim empfänger habe ich for count = 1 to 37 eingestellt! hat sich erledigt, ich depp habe vergessen den index der rx variable anzupassen (dim rx(32) as byte). lg
bezen bu schrieb: >dachte schon ich nerv dich zu sehr! hi bezen bu, grade noch erträglich ;-) aber warum wähltest Du eigentlich nicht ein Projekt in einem Bereich, wo Du etwas fitter bist? > ist dies ein test um auszuschließen, dass die interruptroutine spinnt!? die dürfte sich doch eher langweilen, daß wohl nichts im uart ankommt ;-) test sendet das tx(count) array wenn Taster gedrückt, also auch ohne das was in den uart eingelesen wurde. >damit könnte ich doch auch ohne max232 auf den atmega, oder? kenne Deinen aufbau nicht. wenn das gps usb out hat, mußt Du den RS232/TTL Wandler(max232) durch einen usb/TTL-Wandler ersetzten oder: gps--> usb/rs232 --> rs232/TTL(max232) -->ATmega8 mal googlen z. thema usb auf ATmega
hi max, leider kam ich bisher noch nicht dazu deine tips umzusetzen, da ich die präsi für die zwischenpräsentation erstellen mußte und noch einige klausuren hatte. die präsentation lief bestens! :-) auch dank deiner unterstützung, danke sehr!!! werd es auch am we nicht schaffen, aber am montag setz ich mich dran und geh ins labor. werd dich auf dem laufenden halten. Max schrieb: > aber warum wähltest Du eigentlich nicht ein Projekt in einem Bereich, wo > Du etwas fitter bist? lief etwas blöd, das projekt sollte eher in richtung nachrichtentechnik gehen, aber als wir uns dafür entschieden hatten, haben wir im nachhinein erfahren, dass es verboten ist, sender und empfänger usw. selbst zu bauen. also ging es in richtung rfm01/02 und microcontroller. das ist auch der grund, warum der projektbetreuer von programmieren keine ahnung hat. haben nun neben dem eigentlichen, noch einen anderen betreuer und zwar der fachlehrer für microcontrollertechnik, der kann eher helfen. der einzigste größere knackpunkt ist nun ja nur noch, das gps-signal einzulesen und zu senden....aber das wird schon....auch dank deiner unterstützung. Max schrieb: > kenne Deinen aufbau nicht. > wenn das gps usb out hat, mußt Du den RS232/TTL Wandler(max232) durch > einen usb/TTL-Wandler ersetzten oder: > > gps--> usb/rs232 --> rs232/TTL(max232) -->ATmega8 der empfänger gibt die daten seriell aus, aber bezieht seine stromversorgung vom rs232/usb wandler.....der usb port liefert aber nur ca. 5.3Volt, deswegen weiß ich halt nicht so genau wie ich mit dem signal umgehen muss, oder ob das zu wenig ist usw..... lg
bezen bu schrieb: > der empfänger gibt die daten seriell aus, aber bezieht seine > stromversorgung vom rs232/usb wandler.....der usb port liefert aber nur > ca. 5.3Volt, deswegen weiß ich halt nicht so genau wie ich mit dem > signal umgehen muss, oder ob das zu wenig ist usw..... schau mal hier: Beitrag "Re: Leidiges Thema RS232!"
hi max, hier bin ich wieder! :-) kam nun endlich dazu weiter zu testen, mit folgenden ergebnissen: Max schrieb: >> ich weiß nun dummerweise nicht, ob das problem am code, oder am >> gps-empfänger liegt!? > > brauchst doch nur den gps output direkt mit Terminalprogramm (bei 4800 > Baud) anschauen! ich habe den gps-empfänger mit 38400 baud an das terminal gehangen und er gibt auch genau das raus was er soll! das ist schonmal positiv. nun zum negativen, was mich wieder zum grübeln bringt: da die interruptroutine ja nicht läuft, habe ich den taster gemäß deiner anweisung programmiert, leider hat der taster keinerlei auswirkungen auf irgendwas. :-/ einen kleinen erfolg hatte ich jedoch, aber ich weiß nicht warum dies so ist, eigentlich sollte ja alles automatisch laufen..... wenn ich beim sender reset drücke, wird ein zeichen am terminal ausgegeben.....allerdings immernur wenn ich den reset taster betätige.....ich hab keine ahnung warum das so ist und warum die programmierte schleife über den interrupt nicht funktioniert. ich hoffe du hast ne idee....habe nochmals die verwendeten codes angehängt! lg
bezen bu schrieb: > ich habe den gps-empfänger mit 38400 baud an das terminal gehangen 38400 Baud? wie hast Du jetzt das gps an das Pollinboard angeschlossen? >leider hat der taster keinerlei auswirkungen wenn vom uart nichts ins array eingelesen wurde, also das array leer ist, werden nul-zeichen übertragen, dann gibts auf dem Terminal auch nichts zu sehen! Müsste doch aber die Led toggeln?
Angehängte Dateien:
-
IMG_0695.JPG
1,3 MB
hi max, Max schrieb: > 38400 Baud? > wie hast Du jetzt das gps an das Pollinboard angeschlossen? hab 38400 genommen, da der gps empfänger gemäß datenblatt so konfiguriert ist!? war des falsch? hab den tx des empfängers an ein nen rs232 kabel gebastelt und gehe über die rs232 schnittstelle über den max232 auf den rxd des atmega8. allerdings kommt die versorgungsspannung des gps vom usb port(5,3 Volt). (siehe bild) Max schrieb: > wenn vom uart nichts ins array eingelesen wurde, also das array leer > ist, werden nul-zeichen übertragen, dann gibts auf dem Terminal auch > nichts zu sehen! > Müsste doch aber die Led toggeln? also von alleine passiert ja leider nichts, sprich der interrupt wird nicht ausgelöst wie es eigentlich sein sollte. wenn ich den taster betätige, toggelt zwar die led, also sie leuchtet auf, aber das wars...beim empfänger passiert nichts??? wenn ich einen reset durchführe, geht die led an und die led des empfängers toggelt, es wird ein zeichen ausgegeben.....aber nur nach dem betätigen des reset tasters?!? wie bereits gesagt, der gps empfänger gibt die erwarteten daten aus, wenn ich ihn direkt ans terminal anschliesse! bin etwas ratlos? woran kanns liegen? lg
Hi bezen bu, sehe gerade, daß sowohl bei senden: ...... For Count = 1 To 16 Call Fsk_send(tx(count)) Next Count ....... wie auch in der darin aufgerufenen Sub fsk_send() dieselbe zähl-variable Count verwendet wird :-( Wäre wohl "vorteilhaft" eine davon umzubenennen! also z.B.: dim i as byte senden: ........ For i = 1 To 16 Call Fsk_send(tx(i)) Next i ........ >wie bereits gesagt, der gps empfänger gibt die erwarteten daten aus, >wenn ich ihn direkt ans terminal anschliesse! wie denn ans terminal angeschlossen? Mit dem rs232 kabel? Was steht denn im Datenblatt über das output signal, außer den 38400 baud? was zeigt das scope - kommen daten am mega8 rx an?
hi max, habe gute nachrichten! :-) habe heute zunächst das oszi an den ausgang des gps-empfängers angeschlossen und ca. +/- 10V signalpegel messen können, also rs232 pegel! am rx des mega8 habe ich das erwartete rechtecksignal mit 0 und 5V messen können. also schloss ich daraus, das bis zum atmega alles soweit ok ist und wohl mit der programierung was nicht stimmt. habe dann die zählvariable geändert wie du es vorgeschlagen hast und siehe da....es passiert was! :-) die schleife wird ausgeführt...die sende led flackert auf und im selben moment toggelt die led des empfängers und es wird irgendein willkürliches zeichen ausgegeben am terminal. die pausen zwischen dem senden sind unterschiedlich lang....mal schnell aufeinanderfolgend, mal einige sekunden nichts....aber der interrupt scheint zu klappen! :-) Max schrieb: >>wie bereits gesagt, der gps empfänger gibt die erwarteten daten aus, >>wenn ich ihn direkt ans terminal anschliesse! > > wie denn ans terminal angeschlossen? > Mit dem rs232 kabel? > Was steht denn im Datenblatt über das output signal, außer den 38400 > baud? genau, mit dem rs232 kabel direkt auf die serielle schnittstelle an den pc...38400Baud eingestellt und schon gibt er zyklich das nmea-format aus. würde dir gern das datenblatt senden, dann hast du alles auf ein blick und ich kann nichts vergessen, aber kann kein pdf anhängen wie es aussieht!??? lg
bezen bu schrieb: >habe dann die zählvariable geändert wie du es vorgeschlagen hast und >siehe da....es passiert was! :-) erfolgreich debugged ;-) >die pausen zwischen dem senden sind unterschiedlich lang....mal schnell >aufeinanderfolgend, mal einige sekunden nichts.... da du mit 38400 Baud einliest aber nur mit 19200 sendest (und das auch noch uneffizient, da das tx-array nur unvollständig gefüllt) mußt du das noch optimieren. Könntest, in anlehnung an benedikts funkbrücke, Beitrag "bidirektionale RS232 Funkbrücke mit RFM12" nach dem einlesen des 1. bytes kurz warten ob noch weitere bytes folgen, also n weiter hochgezählt wird und dann das tx(n)-array übertragen. senden: ........ For i = 1 To n Call Fsk_send(tx(i)) Next i ........ wenn das funktioniert, dem empfänger n noch mitteilen, damit der sein rx(n) array anpassen kann.
Hallo Max, hab bissl getestet... Max schrieb: > da du mit 38400 Baud einliest aber nur mit 19200 sendest (und das auch > noch uneffizient, da das tx-array nur unvollständig gefüllt) mußt du das > noch optimieren. die 19200 Baud hatte ich schon im Empfangscode geändert. Max schrieb: > nach dem einlesen des 1. bytes kurz warten ob noch weitere bytes folgen, > also n weiter hochgezählt wird und dann das tx(n)-array übertragen. > > senden: > ........ > For i = 1 To n > Call Fsk_send(tx(i)) > Next i > ........ n wird weiter hochgezählt und übertragen, dass funktioniert, ausser das die Zeichen undeutbar sind! Max schrieb: > wenn das funktioniert, dem empfänger n noch mitteilen, damit der sein > rx(n) array anpassen kann. ich weiß nicht warum, aber sobald ich dim rx(16) as byte in rx(n) ändere und auch die for count befehle in 1 to n, krieg ich fehlermeldungen und kann nicht compalieren?! im vorfeld hatte ich auch versucht das array komplett zu füllen mit if N > 16 then goto senden es wurden 16 zeichen übertragen, allerdings auch lediglich undefinierbare zeichen! lg
bezen bu schrieb: > die 19200 Baud hatte ich schon im Empfangscode geändert. Call Rf_cmd(&Hc811) '19,2 kbit die hf-strecke läuft doch mit 19,2 kBaud >sobald ich dim rx(16) as byte in rx(n) ändere warum dim? >und auch die for count befehle in 1 to n, krieg ich fehlermeldungen du mußt, im sender, vor der übertragung der nutzdaten ZUSÄTZLICH die array-größe n senden, im empfänger dann erst n empfangen und damit dort die arraygröße rx(n) der folgenden nutzdaten anpassen. >es wurden 16 zeichen übertragen, allerdings auch lediglich >undefinierbare zeichen! Baudrate?
hi max, Max schrieb: > Call Rf_cmd(&Hc811) '19,2 kbit > die hf-strecke läuft doch mit 19,2 kBaud ich habe den code im sender und empfänger auf &hc808(38,4kbaud) geändert! läuft auch. Max schrieb: > du mußt, im sender, vor der übertragung der nutzdaten ZUSÄTZLICH die > array-größe n senden, im empfänger dann erst n empfangen und damit dort > die arraygröße rx(n) der folgenden nutzdaten anpassen. hier weiß ich nicht so recht wie das zu programmieren ist...hab in der bascomhilfe nach arrays geschaut und weiß wie ich arrays erstelle usw. aber weiß nicht genau wie ich die größe sende bzw. empfange. ich dachte an sowas... Sender : ...... 'Daten call fsk_send(rx(n)) For I = 1 To N Call Fsk_send(tx(i)) Next I ....... Empfänger : ........ Do Toggle Led call rf_cmd(rx(n)) For Count = 1 To 16 Bitwait Nirq , Reset 'While Nirq = 1 'Wend Spiin Fifo(1) , 3 Rx(count) = Fifo(3) Next ......... war das so gemeint? Max schrieb: >>es wurden 16 zeichen übertragen, allerdings auch lediglich >>undefinierbare zeichen! > > Baudrate? noch auf 19,2 kbaud lg
bezen bu schrieb: > ich habe den code im sender und empfänger auf &hc808(38,4kbaud) > geändert! grössere Baudrate -> grössere Bandbreite-> dann auch anpassen in Configuration: 868MHzband, 12pf, ->134kHz bandwidth ? aber das ist nicht das eigentliche Problem! probier mal: Senden: Disable Interrupts Call Rf_cmd(&Hc039) 'Tx 'Preamble 3x AA ................ 'Frame -ende Kennung Call Fsk_send(&Haa) Call Rf_cmd(&Hc001) 'TX off Enable Interrupts Return kannst auch mal die test-funktion etwas erweitern: Debounce Pinb.1 , 1 , Senden in Debounce Pinb.1 , 1 , test ändern & außerhalb von do-loop einfügen: test: tx(1)= 84 tx(2)= 69 tx(3)= 83 tx(4)= 84 tx(5)= 58 tx(6)= 10 tx(7)= 13 goto senden >ich dachte an sowas... >Sender : >...... >'Daten >call fsk_send(rx(n)) >For I = 1 To N >Call Fsk_send(tx(i)) >Next I >....... call fsk_send(rx(n)) in call fsk_send(n) ändern, bringt aber nur was, wenn auch im empfänger ausgewertet, aber nicht so: >Empfänger : >........ >Do >Toggle Led >call rf_cmd(rx(n)) was ist denn das??
hi max, hatte letzte woche ne menge zutun privat und klausurentechnisch....deswegen konnte ich mich erst heute wieder mit dem projekt beschäftigen.... ich habe nun das problem nicht mehr, dass der gps-empfänger die daten mal langsamer und mal schneller über den rfm02 sendet. der gps-empfänger hatte seine betriebsspannung vorher von einem usb-seriell-wandler, damit gabs wohl probleme....nun ist der empänger über 5v vom evo-board versorgt und schon funktioniert es dass der rfm zyklisch sendet. habe die bandbreite auf 270khz erhöht aufgrund der erhöhten baudrate. mittlerweile kommen ab und an sogar datenpakete zur ausgabe, welche dem gewünschtem nmea-format einigermaßen entsprechen.....von den 16 zeichen sind dann 10 bis 12 richtig. da gibts noch irgendwelche abstimmungsprobleme?!?!aber das ziel kommt näher... :-) Max schrieb: > aber das ist nicht das eigentliche Problem! > probier mal: > > Senden: > Disable Interrupts > Call Rf_cmd(&Hc039) 'Tx > 'Preamble 3x AA > ................ > 'Frame -ende Kennung > Call Fsk_send(&Haa) > Call Rf_cmd(&Hc001) 'TX off > Enable Interrupts > Return > > > kannst auch mal die test-funktion etwas erweitern: > > Debounce Pinb.1 , 1 , Senden > in > Debounce Pinb.1 , 1 , test > > ändern & außerhalb von do-loop einfügen: > > test: > tx(1)= 84 > tx(2)= 69 > tx(3)= 83 > tx(4)= 84 > tx(5)= 58 > tx(6)= 10 > tx(7)= 13 > goto senden ich habe natürlich auch das programm geändert nach den vorgaben.....man konnte beobachten, das das senden und empfangen viel gleichmäßiger und stabiler läuft.....allerdings bekomme ich weniger richtige (nmea) daten an der ausgabe wie beim alten programm!?! beim test mittels taster, stimmt auch was nicht?! sobald ich den taster drücke, wird die übertragung unterbrochen und es passiert nichts mehr, warum auch immer!? werde morgen weiter testen, diese woche hab ich mehr zeit! die aktuellen codes sind angehängt! lg
hi bezenbu, >ich habe natürlich auch das programm geändert nach den vorgaben.....man >konnte beobachten, das das senden und empfangen viel gleichmäßiger und >stabiler läuft.....allerdings bekomme ich weniger richtige (nmea) daten >an der ausgabe wie beim alten programm!?! während des sendens mit (disable interrupts) wird ja auch nichts eingelesen, es gehen somit zeichen verloren. Deshalb nach einlesen des 1. Bytes kurz warten (waitms x) ob weitere zeichen folgen, (bzw. ob n weiter hochgezählt wird) und dann erst das tx(n)-array senden. (wie in Benedikts bidirekt. funkbrücke) idealerweise tx(82) erst füllen, bzw. anpassen wenn weniger zeichen. >beim test mittels taster, stimmt auch was nicht?! sobald ich den taster >drücke, wird die übertragung unterbrochen und es passiert nichts mehr, >warum auch immer!? fehlt wohl das "return": test: tx(1)= 84 tx(2)= 69 tx(3)= 83 tx(4)= 84 tx(5)= 58 tx(6)= 10 tx(7)= 13 goto senden return
bezen bu schrieb:
>beim test mittels taster, stimmt auch was nicht?!
sehe gerade, du hast ja schon auf variables n beim senden geändert:
For I = 1 To N
Call Fsk_send(tx(i))
Next I
mußt dann natürlich noch n = 7 setzen.
da dein empfangsprogramm aber noch mit festem n läuft
For Count = 1 To 16
Call Fsk_send(tx(count))
Next Count
und kein time out hat besser:
test:
tx(1)= 84
tx(2)= 69
tx(3)= 83
tx(4)= 84
tx(5)= 58
tx(6)= 10
tx(7)= 13
n = 16
goto senden
return
hi max, werd die testroutine mittels taster am montag ausprobieren....hab die hardware auf der arbeit. hab allerdings noch ne frage.... Max schrieb: > während des sendens mit (disable interrupts) wird ja auch nichts > eingelesen, es gehen somit zeichen verloren. > Deshalb nach einlesen des 1. Bytes kurz warten (waitms x) ob weitere > zeichen folgen, (bzw. ob n weiter hochgezählt wird) und dann erst das > tx(n)-array senden. (wie in Benedikts bidirekt. funkbrücke) > idealerweise tx(82) erst füllen, bzw. anpassen wenn weniger zeichen. mir ist leider immernoch nicht so ganz klar wie genau das gemeint ist bzw. umzusetzen ist. hab mir den beitrag von benedikt angeschaut und das prinzip verstanden denk ich....meinst du das ich nach: Onrxd: Incr N Tx(n) = Udr "waitms 100" Return also nach einlesen des 1.Bytes ca. 100ms warten soll oder in der do schleife? Do "waitms 100" If N > 0 Then Goto Senden N = 0 Reset Led End If Debounce T1 , 1 , Test Loop End sobald N größer 0 geht er ja gleich zum senden des arrays?! sind 100ms eine ausreichende wartezeit? warum wird das einlesen der daten eigentlich beim senden des arrays unterbunden? lg
hi bezen bu, wenn du in der ISR wartest gehen doch die zeichen während der wartezeit verloren! >Do >"waitms 100" >If N > 0 Then >Goto Senden so wartest du ja vor dem einlesen! um NACH dem 1. byte zu warten: If N > 0 Then If N < 2 Then Set Led1 Waitms 15 ' wert an array größe & baud rate anpassen Reset Led1 End If Goto Senden N = 0 Reset Led End If ........... für die LED1 noch in config. eintragen: Config Portd.6 = Output Led1 Alias Portd.6 good luck!
hi max, erstmal nochmals danke für deine schnelle und qualifizierte hilfe... ich habe den ganzen abend damit verbracht zu testen und rechnen usw......anfangs lief garnichts bei meinen errechneten wartezeiten ausser paar richtige daten und viel müll...wollte schon aufgeben, aber bei 50 und 60 ms programmierter wartezeit lief es auf einmal....die nmea-strings wurden bestens übertragen und ich war total happy...jedoch liegt der gps-empfänger auf meinem schreibtisch und liefert nur 0er oder alte daten, also hab ich den empfänger nach draussen verfrachtet....schwupps waren die strings weg und ich bekam wieder nur schrott!auch im anschluss auf den schreibtisch bekam ich nur mist....hab dann die zeit etwas geändert und irgendwann gings wieder ne weile! hab nun den ganzen abend gemacht und getan um rauszufinden woran es liegen kann, aber keine ahnung. :-( vielleicht ist auch was bei der wartezeit falsch?!? max.82 asci-Zeichen je string a 8 bit = 656 bit/s ca.1kbit 1kbit/38,4kbaud= ca.26ms klappt aber nur bei 50 oder 60ms! test via taster geht leider auch nicht, löst lediglich nen interrupt aus und das wars! lg
bezen bu schrieb: >habe die bandbreite auf 270khz erhöht aufgrund der erhöhten baudrate. laut rfm02 data sheet gilt für 38,4kBaud das pll setting command d2c0 statt d240 >warum wird das einlesen der daten eigentlich beim senden des arrays >unterbunden? du mußt ja beim rfm02 die nutzdaten bits einzeln z.b. über den fsk-pin senden. Wenn da zu einem ungünstigen zeitpunkt der interrupt erfolgt, wird dieser bitstrom gestört. mal ausprobieren: einfach mal auskommentieren: 'disable interrupts >sind 100ms eine ausreichende wartezeit? bei 38,4kB (->4800 zeichen/s) & tx(82) array zu lang! da wäre das Tx(82) array ja schon nach etwas mehr als 17 ms gefüllt! müßtest eigentlich während der delay time noch abfragen ob n>= 82 ist, wenn ja ->senden, würde aber zum programmieren eine laufzeit-schleife oder timer erfordern. außerdem mit For Count = 1 To 82 Bitwait Nirq , Reset Spiin Fifo(1) , 3 Rx(count) = Fifo(3) Next erwartet dein empfänger immer volle 82 zeichen. nochmal hierüber nachdenken: Beitrag "Re: RFM01/02 Basics"
Hi bezen bu,
>test via taster geht leider auch nicht
gibt da leider noch einen "kleinen rücksprung-bug".
deshalb alle
goto senden
durch
gosub senden
ersetzen und ergänzen:
Debounce T1 , 1 , Test , Sub
könntest bei der gelegenheit auch mal ein bischen "aufräumen"
und den auskommentierten code, wie z.b. in der fsk_send entfernen.
Wenn du das programm dann noch etwas eindeutiger benennst, wie etwa
rfm02uart_v1, oder so, dann die nächste v2 usw. wird das alles auch
etwas übersichtlicher!
hi max, Max schrieb: > laut rfm02 data sheet gilt für 38,4kBaud das pll setting command d2c0 > statt d240 hatte ich übersehen, hab ich korrigiert. Max schrieb: > mal ausprobieren: einfach mal auskommentieren: > 'disable interrupts wenn ich es auskommentiere, wird der bitstrom so extrem gestört, dass nur datenschrott übertragenwird. die wartezeit habe ich nun auf 20ms konfiguriert, hier ist auch die anzahl der fehler am geringsten. Max schrieb: > außerdem mit > For Count = 1 To 82 > Bitwait Nirq , Reset > Spiin Fifo(1) , 3 > Rx(count) = Fifo(3) > Next > > erwartet dein empfänger immer volle 82 zeichen. > > nochmal hierüber nachdenken: > > Beitrag "Re: RFM01/02 Basics" hier ist zurzeit mein problem.....hab drüber nachgedacht, aber nach etlichen tests hat dies nicht geklappt, ich weiß nicht, wie ich die gesendete arraygröße im empfänger auswerten muss.ich weiß was zutun ist und warum, kann es aber nicht umsetzen, hier brauch ich mal nen hinweis von dir programmierungstechnisch! ist das array bei der wartezeit 20ms eigentlich nicht immer 82 zeichen groß? noch ne weitere frage zum array, wenn ich ca. 20ms warte für max 82 zeichen ins array einzulesen, aber der nmea-string nur 60 zeichen hat, würden ja vom nächsten string unerwünschte daten angehangen und gesendet.....also funktioniert es doch nicht, einen string einzeln in variabler größe zu senden, oder? der string, welcher im späteren verlauf rausgefiltert werden soll, hat nur ca. 70 zeichen +/-. Max schrieb: > gibt da leider noch einen "kleinen rücksprung-bug". > deshalb alle > goto senden > durch > gosub senden ist geändert und siehe da, die übertragung ist zwar aufgrund der fehlenden array-abstimmung noch fehlerhaft, aber viel stabiler. :-) es geht vorwärts! :-) lg
Hi bezen bu, >es geht vorwärts! ja, erfreulich, aber wir nähern uns auch den grenzen des derzeitigen konzepts. >ist das array bei der wartezeit 20ms eigentlich nicht immer 82 zeichen >groß? nicht, wenn während der wartezeit weniger zeichen gesendet werden, wie z.b. am ende der übertragung. wie bereits gepostet, die exaktere programmierung wäre: (wartezeit vorbei? ODER n>= max. arraygröße) wenn ja -> senden. wenn zu lang gewartet wird gehen ja die zeichen >82 verloren. >der nmea-string nur 60 zeichen hat,würden ja vom nächsten string >unerwünschte daten angehangen da jeder string mit den zeichen <cr> & <lf> abgeschloßen wird doch kein problem. somit brauchst du das zusätzliche print For Count = 1 To 82 Print Chr(rx(count)) ; Next Count 'AN DIESER STELLE Print für die gps übertragung nicht! ->auskommentieren. das eigentliche problem ist vielmehr, daß während dem senden keine weiteren uart zeichen eingelesen werden & der mega8 interne uart rx buffer nur 2 byte groß ist. >ich weiß nicht, wie ich die >gesendete arraygröße im empfänger auswerten muss. Beitrag "Re: RFM01/02 Basics" >die nutzdaten dann grundsätzlich in fifo 3 landen? also, um n zu empfangen: Bitwait Nirq , Reset Spiin Fifo(1) , 3 n = Fifo(3) Happy weekend Max
hi max, Max schrieb: >>es geht vorwärts! > ja, erfreulich, aber wir nähern uns auch den grenzen des derzeitigen > konzepts. reicht das konzept den für das ziel aus? bisher schauts eigentlich recht gut aus. Max schrieb: >>ist das array bei der wartezeit 20ms eigentlich nicht immer 82 zeichen >>groß? > nicht, wenn während der wartezeit weniger zeichen gesendet werden, wie > z.b. am ende der übertragung. > wie bereits gepostet, die exaktere programmierung wäre: > (wartezeit vorbei? ODER n>= max. arraygröße) wenn ja -> senden. > wenn zu lang gewartet wird gehen ja die zeichen >82 verloren. wenn zulange gewartet wird gehen zeichen verloren, das ist klar. also sollte ich die exaktere programmierung anstreben? Max schrieb: > nicht, wenn während der wartezeit weniger zeichen gesendet werden, wie > z.b. am ende der übertragung. wieso werden am ende der übertragung weniger zeichen gesendet? der gps-empfänger gibt doch kontinierlich seine daten an die uart raus, somit wäre das array doch immer komplett gefüllt nach 20ms wenn 82 zeichen ca.17ms dauern?! Max schrieb: > das eigentliche problem ist vielmehr, daß während dem senden keine > weiteren uart zeichen eingelesen werden & der mega8 interne uart rx > buffer nur 2 byte groß ist. wo wäre der unterschied wenn daten während dem senden eingelesen werden würden? das hatten wir doch schon und hierdurch wurde der bitstrom gestört. verstehe die problematik noch nicht so ganz!? Max schrieb: >>ich weiß nicht, wie ich die >>gesendete arraygröße im empfänger auswerten muss. > > Beitrag "Re: RFM01/02 Basics" >>die nutzdaten dann grundsätzlich in fifo 3 landen? > > also, um n zu empfangen: > > Bitwait Nirq , Reset > Spiin Fifo(1) , 3 > n = Fifo(3) leider bekomme ich bei dieser programmierung keine ausgabe mehr, es kommt nix am terminal an!? fragen über fragen! lg
bezenbu schrieb: >> n = Fifo(3) >leider bekomme ich bei dieser programmierung keine ausgabe mehr, es >kommt nix am terminal an!? hi bezenbu, mußt natürlich, nachdem dem empfänger nun n bekannt ist, die normale empfangsroutine mit der for count = 1 to n schleife ausführen, vergessen??
Max schrieb: > mußt natürlich, nachdem dem empfänger nun n bekannt ist, die normale > empfangsroutine mit der for count = 1 to n schleife ausführen, > vergessen?? Ja, hab ich natürlich nicht dran gedacht!:-/ Was sagst zu meinen anderen Fragen? Lg
bezenbu schrieb: >wo wäre der unterschied wenn daten während dem senden eingelesen werden >würden? ganz einfach: sie würden nicht verloren gehen :-D >reicht das konzept den für das ziel aus? hängt somit von obiger einschränkung ab >wieso werden am ende der übertragung weniger zeichen gesendet? der >gps-empfänger gibt doch kontinierlich seine daten an die uart raus keine kurze pause zwischen den einzelnen blöcken? updaterate? >somit wäre das array doch immer komplett gefüllt wenn du immer volle tx(82)-arrays senden willst, gehts doch viel einfacher: Do If N > 81 Then Gosub Senden N = 0 Reset Led End If ...... Loop end brauchst dann auch keine variable array größe, hast ja immer tx/rx(82)!
hi max, hab mich heute wieder ans projekt gesetzt und leider klappts immernoch nicht, trotz for count = 1 to n..... Max schrieb: > mußt natürlich, nachdem dem empfänger nun n bekannt ist, die normale > empfangsroutine mit der for count = 1 to n schleife ausführen, > vergessen?? am empfänger tut sich seitdem garnichts mehr, während der sender zyklisch sendet!??? Max schrieb: >>wieso werden am ende der übertragung weniger zeichen gesendet? der >>gps-empfänger gibt doch kontinierlich seine daten an die uart raus > > keine kurze pause zwischen den einzelnen blöcken? > updaterate? pause weiß ich nicht, er hat ne updaterate von 4 hz, also alle 250ms. lg
Angehängte Dateien:
-
gps_daten.jpg
190 KB
hab mal ein screenshoot der ausgabe am terminal gemacht, mit den alten einstellungen (for count = 1 to 82), damit du mal siehst was ausgegeben wird. Dim Count As Byte Dim Temp As Byte Dim Rx(82) As Byte Dim Cmd(2) As Byte Dim Fifo(4) As Byte Dim N As Byte hierzu noch ne frage, was muss ich als indize bei rx reinschreiben wenn ich mit der variablen arraygröße arbeiten möchte? lg
bezenbu schrieb: >was muss ich als indize bei rx reinschreiben wenn >ich mit der variablen arraygröße arbeiten möchte? hi bezenbu, der ändert sich doch nicht. Einfach, bei empfang & print, statt der konstanten 82 die variable n verwenden. übrigens, mit const n=82 statt dim n As Byte kannst du das dann auch wieder rückgängig machen ohne es in den einzelnen routinen zu ändern. bezüglich deines ziels, da die derzeitige modulationsroutine im polling- mode keine interrupts zum einlesen weiterer uart-daten zuläßt, wäre es wohl am besten erst mal alle, für dich wichtigen strings (dein ziel?) einzulesen und dann erst diese zu senden.
hi max, Max schrieb: > Einfach, bei empfang & print, statt der konstanten 82 die variable n > verwenden. das habe ich schon versucht, hatte im vorherigen beitrag schon geschrieben, das ich das versucht habe und immernoch nichts funktioniert..... :-( siehe hier: bezenbu schrieb: > hab mich heute wieder ans projekt gesetzt und leider klappts immernoch > nicht, trotz for count = 1 to n..... > > Max schrieb: >> mußt natürlich, nachdem dem empfänger nun n bekannt ist, die normale >> empfangsroutine mit der for count = 1 to n schleife ausführen, >> vergessen?? > > am empfänger tut sich seitdem garnichts mehr, während der sender > zyklisch sendet!??? sobald das n im spiel ist auf der empfängerseite, geht garnichts mehr! :-( Max schrieb: > bezüglich deines ziels, da die derzeitige modulationsroutine im polling- > mode keine interrupts zum einlesen weiterer uart-daten zuläßt, wäre es > wohl am besten erst mal alle, für dich wichtigen strings (dein ziel?) > einzulesen und dann erst diese zu senden. ja, es ist mein ziel gewisse strings zu filtern, mir würde eigentlich der GPRMC-string vollkommen ausreichen! hier muss ich nun rausbekommen wie das funktioniert das nur der GPRMC-string eingelesen wird....wird wohl auch recht schwierig werden. lg
bezenbu schrieb: >das habe ich schon versucht, hatte im vorherigen beitrag schon >geschrieben, das ich das versucht habe und immernoch nichts >funktioniert..... :-( hi bezenbu, poste mal deinen code in der do-loop. wenn der sender n als 1. byte im array überträgt, müsstest du das auch als 1. byte im bisherigen rx(82) (oder erweitertem rx(83)) programm erkennen können! funktioniert das überhaupt soweit? >sollte ich die exaktere programmierung anstreben? probier mal ob: waitms 17 ersetzt durch for count=1 to 170 'delay > 17 ms waitus 100 if n>81 then exit for next weniger fehlzeichen bewirkt.
end if vergessen :-(
for count=1 to 170 'delay > 17 ms
waitus 100
if n>81 then
exit for
end if
next
hi max, Max schrieb: > poste mal deinen code in der do-loop. > > wenn der sender n als 1. byte im array überträgt, müsstest du das auch > als 1. byte im bisherigen rx(82) (oder erweitertem rx(83)) programm > erkennen können! > funktioniert das überhaupt soweit? hier der code der do-loop: Do If N > 0 Then If N < 2 Then Set Led1 Waitms 20 Reset Led1 End If Gosub Senden N = 0 Reset Led End If Debounce T1 , 1 , Test , Sub Loop End wenn n als erstes byte übertragen wird bei alter konfiguration (for count = 1 to 82) bekomme ich ein zeichen vor dem $-zeichen des nmea-strings....das scheint zu passen. Max schrieb: > probier mal ob: > > waitms 17 > > ersetzt durch > > for count=1 to 170 'delay > 17 ms > waitus 100 > if n>81 then > exit for > next > > weniger fehlzeichen bewirkt. habe im code 20ms, da 17ms zuviele fehler lieferte....aber auch wenn ich die 1 to 170 mit 1 to 200 ersetze, ändert das nichts an den fehlern. ich hänge nochmal die jetzigen (nicht funktionierenden...zumindest epfänger) codes an incl. deiner änderungsideen. eventuell würde der alte code reichen, wenn es klappen würde den gprmc-string rauszufiltern, oder? verstehe nicht, warum er das n im empfänger nicht schluckt bzw. warum der emfänger garnichts mehr macht!?? lg
bezenbu schrieb: >hier der code der do-loop: hi bezenbu, meinte natürlich den der empfangsroutine, denn sender scheint ja zu funktionieren: >bekomme ich ein zeichen vor dem $-zeichen des >nmea-strings....das scheint zu passen. das zeichen mal mit ascii-tabelle decodieren. paßt das in den bereich 1 - 82 ? uart_receive.hex ? quellcode wäre hilfreicher ;-) >ja, es ist mein ziel gewisse strings zu filtern am einfachsten doch, das gps gleich so zu initialisieren, daß die nicht benötigten strings abgeschaltet werden.
hi max, Max schrieb: > meinte natürlich den der empfangsroutine, > denn sender scheint ja zu funktionieren: sorry... :-) da is er Do Toggle Led For Count = 1 To N Bitwait Nirq , Reset 'While Nirq = 1 'Wend Spiin Fifo(1) , 3 N = Fifo(3) Next Call Rf_cmd(&Hce89) Call Rf_cmd(&Hce8b) 'Reset FIFO For Count = 1 To N Print Chr(rx(count)) ; Next Count 'Print Loop End Max schrieb: >>bekomme ich ein zeichen vor dem $-zeichen des >>nmea-strings....das scheint zu passen. > das zeichen mal mit ascii-tabelle decodieren. > paßt das in den bereich 1 - 82 ? ist mal ein Q und mal ein R in ASCII, ist entweder 51hex oder 52hex gemäß tabelle. also paßt es in den bereich.... Max schrieb: > uart_receive.hex ? > quellcode wäre hilfreicher ;-) mist... :-) verguckt... Max schrieb: >>ja, es ist mein ziel gewisse strings zu filtern > am einfachsten doch, das gps gleich so zu initialisieren, daß die nicht > benötigten strings abgeschaltet werden. da hast du recht, bisher habe ich allerdings noch kein plan ob und wenn, dann wie es geht...versuche das mal endlich rauszufinden! lg
bezenbu schrieb: >Toggle Led >For Count = 1 To N >Bitwait Nirq , Reset >'While Nirq = 1 >'Wend >Spiin Fifo(1) , 3 >N = Fifo(3) hi bezenbu, du bist ja lustig, weist hier n zu BEVOR du es überhaupt empfangen hast! außerdem, zum empfang eines einzigen bytes bedarf es hier keiner zählschleife! hab dir den "n-empfang" doch schon gepostet: Beitrag "Re: RFM01/02 Basics"
hi max,
wenn ich mehr erfahrung hätte und es besser wüßte, hätte ich es richtig
gemacht. hast recht, dummer denkfehler....
weiß nun nicht ob das programmiertechnisch so geht, da die hardware auf
der arbeit ist kann ich nich testen.....beim fifo bin ich mir nicht
sicher.....
klappt des so?
do
toggle led
Bitwait Nirq , Reset
Spiin Fifo(1) , 3
n = Fifo(3)
next
For Count = 1 To 82
Bitwait Nirq , Reset
Spiin Fifo(1) , 3
Rx(count) = Fifo(3)
Next
Call Rf_cmd(&Hce89)
Call Rf_cmd(&Hce8b) 'Reset FIFO
For Count = 1 To 82
Print Chr(rx(count)) ;
Next Count
Loop
lg
bezenbu schrieb:
>klappt des so?
hi bezenbu,
wenn du noch das "next" nach n=... entfernst siehts gut aus!
btw, arbeit- dachte du bist auf der technikerschule?
happy weekend
hi max, Max schrieb: > wenn du noch das "next" nach n=... entfernst siehts gut aus! > btw, arbeit- dachte du bist auf der technikerschule? > happy weekend ok, super.... ja, bin auch auf technikerschule, sag halt immer arbeit! :-D dir auch ein schönes restwochenende...meld mich dann montag nach dem testen.
hi max, man glaubt es kaum, aber es funktioniert! :-D :-D :-D habe keinerlei störenden zeichen mehr bei der übertragung! bin nun dabei zugriff auf den gps-empfänger zu bekommen um nur den gprmc-string zu bekommen. habe hier kontakt mit dem hersteller....welcher mir schrieb wie das funktioniert....problem ist nur, dass ich über hyperterminal zwar das signal 1a bekomme, aber die software des herstellers es nicht erkennt, obwohl sie das nach deren angaben sollte wenn hyperterminal die daten auch empfangen kann....das beschäftigt mich nun noch...nebenbei läuft schon der entwurf und bau der hardware! :-) hoffe das klappt zügig mit der software des herstellers den string zu filtern..... lg
bezenbu schrieb: >man glaubt es kaum, aber es funktioniert! hi bezenbu, Glückwunsch !! :-) hast ja dann auch was "programmiertechnisch" gelernt, wobei >beim fifo bin ich mir nicht sicher..... die 16-bit SPI kommunikation mit den modulen sicherlich auch nicht gerade der ideale Einstieg hierfür war. Solltest allerdings auch nicht vergessen, daß deine derzeitige frequenz der 1% regel unterliegt, gemäß: http://www.mikrocontroller.net/articles/Allgemeinzuteilung erscheint der bereich 869,700 - 870,000MHz hierfür geeigneter!? SOLLTEST DIES MAL GEMÄSS DEN BUNDESNETZAGENTUR VORGABEN PRÜFEN ! >nebenbei läuft schon der entwurf und bau der >hardware! kein Pollinboard? lg
hi max, hatte die letzten wochen ne menge prüfungen usw. deswegen hatte ich kaum zeit fürs projekt! :-/ aber diese woche ist nur fürs projekt, da nächsten montag die projektpräsi ist. Max schrieb: > Glückwunsch !! :-) > > hast ja dann auch was "programmiertechnisch" gelernt, wobei > >>beim fifo bin ich mir nicht sicher..... > > die 16-bit SPI kommunikation mit den modulen sicherlich auch nicht > gerade der ideale Einstieg hierfür war. :-) danke, ja hab ne menge gelernt und wie du auch schon sagtest, da war nicht der einfachte einstieg! :-D Max schrieb: > Solltest allerdings auch nicht vergessen, daß deine derzeitige frequenz > der 1% regel unterliegt, gemäß: > > http://www.mikrocontroller.net/articles/Allgemeinzuteilung > > erscheint der bereich 869,700 - 870,000MHz hierfür geeigneter!? > > SOLLTEST DIES MAL GEMÄSS DEN BUNDESNETZAGENTUR VORGABEN PRÜFEN ! habe diesen bereich nun genommen, immerhin 10x mehr zeit! :-) Max schrieb: >>nebenbei läuft schon der entwurf und bau der >>hardware! > > kein Pollinboard? die pollinboards sind / waren reine experimentierboards.... die sind für die umsetzung des projekts zu groß! der sender muss ja im anwendungsfall an einem hund befestigt werden. wir haben von daher kleine platinen angefertigt mit nem gehäuse drumherum! wenn du magst, kann ich dir mal fotos schicken!? was allerdings immernoch nicht funktioniert, ist die testroutine! :-D aber das ist ja auch nicht so wichtig! lg
hi bezenbu, hoffe Deine Prüfungen liefen gut. bezenbu schrieb: >der sender muss ja im anwendungsfall an einem hund befestigt werden. interessant- das gibt dem Ganzen ja eine sinnvolle Anwendung! Bilder wären interessant. Muß mich mal anmelden. >was allerdings immernoch nicht funktioniert, ist die testroutine was passiert denn, wenn Taster gedrückt? probier mal den $swstack = 10 auf 20 zu erhöhen. n sollte außerdem der Anzahl der gesendeten Zeichen entsprechen.
hi max, :-) die abschlussprüfungen stehen noch an, aber erstmal die projektpräsentation am montag! also wenn ich den taster drücke, wird lediglich der programmablauf gestoppt, aber es wird nichts ausgegeben! das ändern des stackwertes hat daran auch nichts geändert. deswegen hab ich die routine erstmal rausgenommen um fragen hierzu zu vermeiden! :-D hab mir eben mal ne e-mail eingerichtet.....wenn du mir hierauf ne nachricht schreibst schick ich dir paar bilder: (für spamer: adresse wird wieder aufgelöst) bezenbu@yahoo.de lg
Hallo Ich betreibe RFM12 Module ohne Probleme Dummerweise habe ich mir auch RFM01 + RFM02 Module gekauft und die bekomme ich nicht zum laufen. Der Pollin Bsp. Code funktioniert leider nicht. Hat jemand funktionierenden Code in PIC "C" oder einen einfachen Code für 868 Version mit Atmel MPUs.
Martin Michael schrieb: > Dummerweise habe ich mir auch RFM01 + RFM02 Module gekauft > und die bekomme ich nicht zum laufen. Du weißt, dass die eine ganz andere Funktion haben, als die RFM12? Was willst du denn damit machen und was hast du probiert?
Natürlich weiß ich das. Nichts erst mal nur eine Verbindung aufbauen und dann eine Temperatur Überwachung.
Hallo Ich habe da noch eine Frage zum Transmit Modul RFM 02 Wie unterscheidet man in der Config ob ich mit FSK oder SDI sende. Also an welchen Bits muss man setzen, ich finde in der Doku darüber nichts.
Hallo Hatte ich im Datenblatt übersehen mit Data Transit Cmd 0xC6 dann werden danach die Daten mit SDI übertragen
Hallo ( für Microchip Pics) Zum Abschluss möchte ich meine Kenntnis über RFM Module von Hope mitteilen. Also RFM12 Module habe ich ohne weitere Probleme , zum funktionieren gebracht. Das RFM02 Sende Modul, funktioniert sagen wir zu 90%. Wenn ich mehr als 17 Byte versuche zu übertragen ist die Prüfsumme die ich am ende übertrage, nicht stimmig. Das RFM01 Empfangsmodul habe ich leider überhaupt nicht überreden können etwas, vernünftiges zu empfangen, obwohl mir das Statusbits aussagen das was vernünftiges im Fifo anliegt. Ich hatte Hope (mehrmals) angeschrieben, die mich aber nur in Kenntnis setzen, das diese Module Out auf Date sind, auf Hobby Tüftler sind die gar nicht eingestellt.
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.