Hallo zusammen, ich möchte eine Bidirektionalle Funkstrecke zwischen zwei Chipcon CC1000 (Transceiver) realisieren, die Transceiver sind jeweils mit einem 18er PIC von Microchip verbunden (ok ok ich weiß das hier im Forum AVR favorisiert wird aber ich habe nur eine "Ausrüstung" für Microchip). Aber nun meine Frage weiß jemand ob es schon fertige C-Sourcecodes gibt, die die Sendemimik bzw. das Protokol beinhalten (z.B. Präambel, Fehlerkorrektur, wiederholendes Senden, Acknoledge)? Ich denke mir dass so eine Programmierung von null an recht komplex ist und dass man das Rad hierfür nicht neu erfinden muss. Ich hab aber im Internet bisher so gut wie gar nix gefunden;-( (obwohl es immer pauschal heisst, dass es tausende von Protokolle gibt) Ich bin also für jede Hilfe offen! Vielleicht hatte ja von Euch jemand schon ein ähnliches Prob. und kann mir weiterhelfen! thx im voraus Christoph;-)
Hi, ich habe sehr gute Erfahrungen mit diesem Transciever modul gemacht: http://www.active-robots.com/products/accessories/radio-modules.shtml Von der Anwendung her ist es so einfach, das man eigentlich nur einen Seriellen Kaber ausseinander schneiden muss. Dann zwei Transciever dazwischen klemmen und schon funktioniert die Funkübertragung. Oh, jetzt sehe ich, dass du nach den SourceCode gefragt hast... Gruß Zoltan
Danke für eure Hilfe! @zoltan mein Hauptproblem ist nicht die Funktstrecke sondern die sichere Datenübertragung mit allem was dazu gehört. @OldBug Das ist richtig, allerding ist der Code von der Chipcon HP sehr einfach gehalten bzw. es ist eine einfach (also keine BI-direktionalle) Funkstrecke und da mir eine sichere Übertragung wichtig ist, muss der Empfänger dem Sender mitteilen dass das Signal richtig angekommen ist. Ansonsten hat Chipcon nichts fertiges, hab schon mit en paar Leuten von denen geredet, aber die meinten immer nur, dass es kein Problem ist und dass es da viele freie Protokolle geben muesste die man heranziehen kann (aber irgendwie bin ich zu doof etwas im inet zu finden) vielleicht weiß ja jemand noch etwas Gruß Christoph
Ich hoffe, Du verwechselst Bidirektional nicht mit Vollduplex... Wenn Du ein Software-Grundgerüst von der Hersteller-Firma hast, schau doch mal, ob Du etwas drumherumbasteln kannst. "Sicher" manchen kann man die Übertragung mit Prüfsummen. Um die Rückmeldung zu übertragen, mußt Du einfach die Richtung umkehren: Sender wird Empfänger, Empfänger wird Sender. Gleichzeitig geht nicht, dann müßtest Du auf verschiedenen Frequenzen arbeiten. Also: Du sendest Dein Datentelegramm, anschließend wird der Sender auf Empfang umgeschaltet (sofern das nötig ist, ich kenne Deine Module leider nicht). Entweder empfängt man vom angesprochenen Modul ein Acknowledge, oder geht nach einer angemessenen Time-Out Zeit in die Fehlerbehandlung.
@Christoph Probiers mit folgendem Link: http://www.chipcon.com/index.cfm?dok_id=98&kat_id=6 Die beiden Dateien Application Note 25 und der dazugehörende Sourcecode sollten einen Einstieg ermöglichen. Jedenfalls ist das Protokoll in der AN beschrieben. Ich habe ein ähnliches Problem, allerdings verwende ich weder einen PIC noch einen Chip von Chipcon, sondern als Controller kommt ein Atmel mega169 zum Einsatz und als RF Teil werden Private Mobile Radios eingesetzt, wobei ich die Daten über das Sprachband übertragen werde. Gruss Justus
@Christof: thkais beschreibt das ja schon ganz gut! Was etwas Problematisch ist, sind Präambel und Framestart, das war in der Beispiel-ISR vom ChipCon nicht gut implementiert! Ich habe da auch ne Weile tricksen müssen. Was das Protokoll betrifft: Ich sende mit fester Framelänge (dynamisch wäre auch nicht so Wild, war bei mir aber nicht notwendig) und hänge an das Datenfeld noch mal 16Bit-CRC hinten dran. Kommt das Packet beim Empfänger an und ist gültig (kein CRC-Fehler), so wird ein ACK zurück zum Absender geschickt. Der wartet etwas länger als beide Packete zum Senden benötigen würden (Daten + ACK) und wiederholt dann mit einer "Zufällig" gewählten (begrenzten) Verzögerung das Packet. Wenn ich das Richtig im Kopf habe, dann hat ChipCon allerdings auch schon ein winziges Protokoll mit ACK in ihren App-Notes.
vielen Dank mal für Eure Hilfe, ich werd jetzt mal schauen ob ich weiterkomme und auf jedenfall wieder bescheid geben. Die Apllikationen hab ich mir schon angeschaut aber wie @OldBug schon sagte, die Präambel Funktion versteh ich nicht so richtig (und dadurch dass der Code für die 16er Famielie geschrieben ist muessen erst die ganzen Schnittstellen neu für den 18er angepasst werden). Ich mach mir jetzt erst mal zwei Testplatinen dass ich ein bischen rumspielen kann. Wenn ich etwas herausgefunden habe werde ich es hier gleich posten, vielleicht könnt ihr ja etwas damit anfangen! gruß Christoph
Die Präambel ist hauptsächlich dafür da, den Demodulator auf die richtige Empfindlichkeit einzustellen (eine Reihe von aufeinander folgenden nullen und einsen, 0b1010101010101010 [0xAA], kann auch beim Verlust des ersten Bits als 0x55 erkannt werden). Es gibt auch eine Betriebsart, in der keine Präambel benötigt wird, hab ich aber nie benutzt...
Wenn eine Präambel benötigt wird, dann gehe ich davon aus, daß es sich um AM-Funkübertragung handelt. Bei AM werden die Daten mit unterschiedlicher "Lautstärke" übertragen (eigentlich nur "Sender an" und "Sender aus". Deshalb muß der Empfänger trainiert werden, weil man ja nie weiß, wie weit der Sender entfernt ist und wie "laut" er nun tatsächlich ist (Stichwort: Pendelempfänger). Man kann sich das so vorstellen, wie eine automatische Pegelanpassung bei Kassettenrekordern. Eine Präambel besteht eigentlich nur aus einem oder mehreren "01010101" - Bytes. Zusätzlich wirst Du auch die Daten Manchester-Kodieren müssen, weil die Pendelempfänger ein Problem mit Gleichspannungsanteilen haben. Die Manchester-Kodierung sorgt dafür, daß nie mehr als 2 "0" oder "1" Bits hintereinander vorkommen. Zu diesem Thema gibts schon einige Beiträge.
@OldBug steht Dein Code für ein Weiterverarbeiten zur Verfügung? Justus
thkais: Neinein, ist kein AM, sondern FSK und die Kodierung (Manchester/NRZ) macht der Chip selbständig. Die Präambel ist für den Bit-Synchronyzer notwendig: "[..]All modes need a DC balanced preamble for the internal bit slicer to acquire correct comparison level from an aveaging filter. The suggested preamble is a '010101...' bit pattern.[..]This is necessary for the bit synchronizer to synchronyze correctly.[..]" @justus: Den Code kann ich so ohne weiteres nicht rausgeben, aber ich kann mal versuchen am Wochenende die essentiellen Dinge der Übertragung herauszuziehen.
@OldBug da hät ich auch Interesse;-) wenn du so etwas herausgeben kannst (darfst)! Jetzt muss ich aber erst noch mit der SPI Konfiguration rummachen das der CC1000 sauber konfiguriert werden kann, in dem Bereich hat Chipcon schon einiges vorgelegt was die Sache erheblich einfacher machen sollte. Was für eine Übertragungsbaudrate empfiehlt ihr? Ich muss wenige Daten übertragen und der Strombedarf sollte niedrig sein da dachte ich geh ich auf 19,2KBaud (der Pic wird mit 4MHz betrieben dadurch habe ich eh nicht alzuviel Möglichkeiten was den Asyncronen USART Modus betrifft). Gruß Christoph
@OldBug - habe ich mich da ein wenig getäuscht ? g Kann schonmal passieren... @Christoph: 19200 Baud sind eigentlich noch recht viel - ich arbeite teilweise mit 1200 Baud und weniger.... Kommt auf die Datenmenge an. Ich berechne die Anzahl der Bytes, die ich pro Sekunde erwarte, dann nochmal 30% Aufschlag, der Sicherheit wegen, dann *10 (1 Start, 1 Stop und 8 Datenbits) und schon hat man die theoret. min. Baudrate. Ich nehme dann bestenfalls die nächsthöhere.
19.200 geht mit den CC1000s ganz gut! Hab ich auch verwendet, für die jenseits 70k braucht man nen bestimmten Quarz am CC1000... Das Konfigurations- und das Kommunikationsinterface ist sehr einfach gehalten, könnte ich auch noch mal reingucken, wenns da Probleme geben sollte.
@OldBug he vielen Dank für dein Angebot! Hab mich nochmal mit den Datenblätter beschäftigt, denke dass es mit der Konfiguration hoffentlich nicht alzuviel Probleme gibt. Die SPI "Schnittstelle" ist ja beim PIC recht einfach zu handeln. Also für die Konfiguration SPI und für die Übertragung der Daten denk ich ist wohl die Synchrone Slave Schnittstelle bestens geeignet. Da der CC1000 ja den Takt im Syncronen Manchester encoded Modus vorgibt dachte ich ist es wohl eine saubere und recht unkomplizierte Lösung (oder lieg ich da falsch?) mit der ich direkt die Daten wieder in ein Register bekomme. Wie ich dann aber die Schnittstelle nach der Präambel auf das erste Datenbit syncronisiere (möglichst ohne jedes Byte kompliziert zu "shiften"), da werd ich dann vielleicht wieder auf dich zurückkommen (wenn das OK ist)! Ps. ich hoffe dass ich mich nicht zu doof anstelle aber es ist meine erste Funkstrecke und mit USART / SPI und Co. hatte ich bisher auch recht wenig zu tun;-) Gruß Christoph
Hallo Christoph, Bist du mit deinem Projekt inzwischen weitergekommen? Könntest du mir deinen Code per Mail zusenden, da ich das gleiche Problem mit dem 18er Pic und dem CC1000 Ic habe. Gruss Christian
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.