www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RFM12 Protokoll Stack


Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird die zum Beitrag 'RFM12 Protokoll Stack' (Wettbewerb) angekündigte 
Referenzimplementierung noch erscheinen?

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da wird es wohl nichts geben!?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Implementierung gibt's doch.  Was es nicht gibt, ist ein
fertig compilierbares Beispiel.

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Aussage nutzt mir nichts.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin grad dabei Diplomarbeit zu schreiben, deswegen läuft das etwas 
zögerlich. Außerdem hab ich kein konkretes Projekt bei dem ich den Stack 
einsetzen will.

Auf der anderen Seite hab ich jetzt dank dem Wettbewerb zwei USBprog und 
werde mir noch ein paar RFM12 kaufen. Dann kann ich etwas effizienter 
testen.

Das Projekt ist also definitiv nicht gestorben.
(Bei konkretem Interesse ist auch ne Mail besser, als ein Eintrag hier 
im Forum, den bekomme ich ja nicht zwingen mit)

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde demnächst am Stack weitermachen, hätte aber vorher Feedback ob 
das Design so für die meisten taugt, oder ob ich lieber was ändern soll.

Wer hätte denn überhaupt Interesse den Stack zu benutzen?

Autor: Chris R. (mrgreen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich.

Autor: SD-Fritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HIER

Autor: O. Hagendorf (ohagendorf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und ich auch

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hört sich doch schon mal gut an. Könnt ihr vielleicht den 
Verwendungszweck etwas genauer beschreiben?

Welche Hardware (µC) wollt ihr einsetzen?

Wie viele Teilnehmer soll ein Netz haben?

Braucht ihr eher hohe Datenrate oder hohe Datensicherheit?

Autor: Chris R. (mrgreen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Parametrisierbar :)

Erstmal hätte ich ganz gerne Doku. Das ist ja alles nett, aber noch 
nicht ganz ausgereift, oder?

Wenn ich nach dem Schichtenmodell gehe, dann muss ich doch auch Daten 
auf dem PHY Layer durch einen einfachen Aufruf versenden können.

Wenn ich davon ausgehe, dass deine Konvention RFM12_PHY_xxx bedeutet, 
dass dies die Zugriffsfunktionen für den Layer1 sind, dann fehlt mir 
aber eine Funktion "rfm12_phy_send_data(void* data)".
Hier klingelt der Phy-Layer den Mac-Layer durch einen Callback an, um 
Daten abzusenden?

Das Schöne an einem Schichtenmodell ist doch grade, dass die Schichten 
gegeneinander gekapselt sind. Warum muss der Mac-Layer bei einem 
Sendevorgang wieder aufgerufen werden?


Hast du denn schon mal eine Anwendung dafür gebaut?
Wenn man definitiv weiß, dass die Funktionen zum Einstellen der Hardware 
(mit den teilweise unergründbaren Konfigurationen) funktioniert, dann 
ist das doch schon mal richtig cool.

Es scheint aber bisher keiner einzusetzen? Hat jeder sein selbst 
erfundenes Rad am Laufen?

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doku wird's hoffentlich noch geben, der Wiki-Artikel soll ja erst mal 
ein Entwurf sein über den man diskutieren kann.

Zum Schichtenmodell:

Wenn man das auf einem PC implementiert geb ich dir vollkommen recht, da 
schieben die Layer einfach Daten nach unten durch.

So einfach ist es auf einem µC leider nicht, wenn man RAM und Rechenzeit 
sparen will.

1. Wenn die Daten im Layer 3 vorliegen und zum Layer 2 übergeben werden, 
müsste dieser z.B. für die FEC ein neues Array mit doppelter Größe 
anlegen, und dann für die Berechnung über das ganze Array laufen und 
dieses kopieren. Ist natürlich nicht sehr effizient, da die Daten gar 
nicht gleichzeitig vorliegen müssen.

2. Häufig liegen die Daten (z.B. Header) gar nicht als Array vor, 
sondern werden "on-the-fly" generiert, auch hier ist es geschickter, 
wenn der untere Layer die Daten erst bei Bedarf vom oberen Layer 
anfragt.

Hier haben wir jetzt also den Konflikt, dass man den oberen Layer zwar 
nicht kennen möchte, diesen aber aufrufen muss. In meiner 
Implementierung hab ich das so gelöst, dass der untere Layer zumindest 
die Deklaration der Funktion des oberen Layer kennt.

Noch schöner wäre natürlich gar kein Funktionsaufruf, sondern inline 
Code. TinyOS löst das sehr schön mit einem eigenen Präprozessor, der aus 
generischen Vorlagen C-Code erzeugt.

Vollständige Kapselung ist bei einem µC auch nicht nötig, da die Layer 
ja zur Compile-Zeit bekannt sind (im Gegensatz z.B. zu einem PC 
Betriebssystem).


MAC und PHY hab ich so schon für einfache (nur 2 Teilnehmer) Projekte 
eingesetzt. Die optimalen Einstellungen für Bandbreite, Baudrate und 
Kanalabstand müssen aber dringend noch diskutiert werden!

Autor: Chris R. (mrgreen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, seh ich ein. Aber gerade für so etwas braucht es ein paar Zeilen 
Doku^^

Und wenn du die FUnktionen als inline deklarierst, hast du auch keinen 
Function Call, dafür aber eine (wie ich finde) schöne Schnittstelle.

Das inline könnte man sogar noch hinzu-#definen, je nachdem, ob man die 
Layer3-Schnittstelle nutzen möchte und somit Layer2 und 1 kapseln will.


Kann man den µC eigentlich in den Sleepmode schicken, sodass er wieder 
durch einen INT bei Empfang geweckt wird, oder macht er dann 
Merkwürdigkeiten mit seinen Pins, die dem RFM stören?


Wie genau funktioniert deine Collision Detection (oder Avoidance)? 
Listen-before-Talking ist ja cool, aber rein theoretisch kann es 
trotzdem knallen. Kriegt man das mit (außer man definiert sich dann ein 
Handshake)?


Stell doch einfach mal dein 2-Teilnehmer-Beispiel bereit, vielleicht 
wird dann einiges klarer :)

MfG
Mr.Green

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit inline ist leider nicht so einfach mit dem avr-gcc, der 
ignoriert das gern mal. Vor allem wenn die Funktion in einer anderen *.c 
Datei aufgerufen wird.

Sleep-Modus sollte grundsätzlich möglich sein. Vom RFM her spricht nix 
dagegen.

Collision Detection sollte ähnlich wie bei WLAN und Zigbee 
funktionieren, also Random Backoff bei Sendewunsch dagegen aber 
sofortiges ACK, wenn gewünscht. Einfach mal die Wiki-Artikel zu beiden 
oben genannten durchlesen.

Beispiel kann ich mal vorbereiten, sobald der USB-HID Stack für den 
USBprog zuverlässig geht.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manuel Stahl wrote:
> Das mit inline ist leider nicht so einfach mit dem avr-gcc, der
> ignoriert das gern mal. Vor allem wenn die Funktion in einer anderen *.c
> Datei aufgerufen wird.

Der ignoriert da gar nichts. Das Inlinen erledigt der Compiler und der 
arbeitet halt nur mit einer *.c Datei zur gleichen Zeit. Es kann also 
gar nicht funktionieren.

Meine Lösungen dafür: Entweder Alle Inline Funktionen in eine *.c Datei, 
oder in unterschiedliche *.c Dateien und diese per #include inkludieren 
oder den Code in *.h Dateien schreiben und diese inkludieren.

Autor: Chris R. (mrgreen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und was mir grad noch einfällt: Welche Schaltung liegt dem denn nun zu 
Grunde?
Exakt die hier?
http://www.mikrocontroller.net/wikifiles/5/51/AVR_...

Gruß
Mr.Green

Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, melde mich auch mal mit Interesse.

Würde auch gerne ein Netz mit etwa 10 Teilnehmner (in der Art: 1xMaster 
und 9x Slave) aufbauen.
Datenrate wäre da nicht so wichtig, aber Datensicherheit (nicht, dass 
die Daten verschlüsselt sind, sondern dass sie korrekt gesendet werden).

Würde mich über eine weiterentwicklung freuen :)

Auch eine Doku und ein gut dokumentiertes Beispiel wären nicht schlecht.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris R. wrote:
> Und was mir grad noch einfällt: Welche Schaltung liegt dem denn nun zu
> Grunde?
> Exakt die hier?
> http://www.mikrocontroller.net/wikifiles/5/51/AVR_...

Das ganze ist völlig unabhängig von der Schaltung. In der 
Referenzimplementierung ist nur wichtig, dass der RFM12 per SPI am Atmel 
hängt. Zum Experimentieren hab ich den RFM12 direkt (ohne weitere 
Bauteile) am USBprog ;)

Autor: Chris S. (schris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Frage,
im Artikel ist die maximal Laenge des L2 Pakets mit 517 bytes angegeben.
Spaeter jedoch, wird von 973 bytes Paketgroesse ausgegangen.
Was stimmt ?

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
512 nicht 517. Das wäre mal so n Vorschlag. Zigbee erlaubt z.B. nur 128 
byte. Wo das Optimum liegt, hängt stark von der zu erwartenden 
Fehlerrate ab.

Wo genau ließt du 973?

Autor: Chris S. (schris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unter Frames, MACLLCL3

Beachte: Durch die Hamming-Codierung sind alle Bytes innerhalb des 
MAC-Layer doppelt so lang wie angegeben!

also(layer2):
preamble 2 bytes 0xAA
sync     2 bytes
suffix   1 byte  0xAA

Nutzdaten (layer3):
header   4 bytes   src,dst,flags,crc
data     0-480 bytes

Nutzdaten x2, wegen des Hamming, also 968 bytes + 3 byte layer 5
macht 973 bytes, bei 4800bps ca 2sek uebertragungszeit.

Ich weiss, dass das Modul schneller sein kann, aber bei weiten 
Entfernungen muss die Geschwindigkeit gedrosselt werden.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt bin ich glatt selber durcheinander gekommen. 512 Bit, nicht Byte, 
macht 64 Byte. Minus 4 Byte bleiben nocht 60 Byte, aber nicht Nutzdaten 
sonder mit FEC. Wären dann nur 30 Byte Nutzdaten für Layer 3. Ist 
möglicherweise etwas wenig. Wie gesagt, hier kann man noch 
Experimentieren.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Erfahrung mit dem RFM12, Paketgröße, Baudrate usw.:
Zu kleine Pakete bremsen aus, das ist klar (RX-TX Umschaltung usw.).
Je größer das Paket dagegen ist, desto höher ist die Wahrscheinlichkeit, 
dass es durch einen Übertragungsfehler beschädigt wird (ich verwende 
keine Fehlerkorrektur, sondern fordere das komplette Paket neu an). Ein, 
meiner Meinung nach häufige Fehler ist, dass ein Bit verschluckt wird. 
Dann nützt auch Hamming nichts. Ich hatte Hamming anfangs auch 
verwendet, aber am Ende verworfen, da es letzendlich schneller ging die 
Daten ab und zu nochmal komplett neu zu übertragen, als immer die 
doppelte Datenmenge rumschleppen zu müssen. Keine Ahnung ob es 
realisierbar ist, aber ich würde zu einer effizienteren Fehlerkorrektur 
tendieren (leider ist das nicht wirklich mein Fachgebiet). Um die 
Probleme mit aus dem Takt kommen des Empfängers zu vermeiden, füge ich 
nach einem 0x00 oder 0xFF ein 0xAA ein. So sind worst case 8 Bits ohne 
eine Flanke.
Weiterhin kommt dazu, dass große Pakete auch viel RAM brauchen, vor 
allem wenn mehrere in kurzer Zeit empfangen werden, und der µC noch 
andere Sachen zu tun hat. Bei mir haben sich daher 64 oder 128Byte 
Pakete durchgesetzt (64Byte für Netzwerke mit vielen Teilnehmern, 
128Byte für Punkt zu Punkt Verbindungen).

Als Baudrate verwende ich meist 10-20kBaud. Auch hier hat man wieder den 
Kompromiss: Hohe Baudraten sind störanfälliger, bei niedrigen Baudraten 
dauert die Übertragung länger, und die Warscheinlichkeit dass irgendein 
anderer Sender dazwischenfunkt wird höher. Bei höheren Baudraten nimmt 
meiner Erfahrung nach die Fehlerrate schnell zu.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Benedikt, dass sind schon mal brauchbare Anhaltspunkte.


> Meine Erfahrung mit dem RFM12, Paketgröße, Baudrate usw.:
> Zu kleine Pakete bremsen aus, das ist klar (RX-TX Umschaltung usw.).
> Je größer das Paket dagegen ist, desto höher ist die Wahrscheinlichkeit,
> dass es durch einen Übertragungsfehler beschädigt wird (ich verwende
> keine Fehlerkorrektur, sondern fordere das komplette Paket neu an).

So wie immer halt. Welche Paketlänge (in Millisekunden) empfiehlst du 
denn?

> Ein,
> meiner Meinung nach häufige Fehler ist, dass ein Bit verschluckt wird.
> Dann nützt auch Hamming nichts. Ich hatte Hamming anfangs auch
> verwendet, aber am Ende verworfen, da es letzendlich schneller ging die
> Daten ab und zu nochmal komplett neu zu übertragen, als immer die
> doppelte Datenmenge rumschleppen zu müssen.

Das Problem hatte ich auch schon, aber Schuld war nicht das RFM12 
sondern ein zu langsames SPI am Sender. Nur mit Hardware SPI auf 2Mbit 
und Interupts konnte ich sicherstellen, dass ich rechtzeitig Daten 
nachschieb. Könntest du mal prüfen, ob das nicht auch bei dir das 
Problem ist?

> Keine Ahnung ob es
> realisierbar ist, aber ich würde zu einer effizienteren Fehlerkorrektur
> tendieren (leider ist das nicht wirklich mein Fachgebiet).

Die Tabelle geht halt schön schnell. Polynome berechnen ginge auch noch, 
braucht aber wesentlich mehr Takte. Das Hauptproblem sind ja auch 
Büschelfehler, daher müsste die Redundanz über das gesamte Paket 
verteilt werden, was natürlich wieder ein Puffern des Gesamtpakets nötig 
macht.

> Um die
> Probleme mit aus dem Takt kommen des Empfängers zu vermeiden, füge ich
> nach einem 0x00 oder 0xFF ein 0xAA ein. So sind worst case 8 Bits ohne
> eine Flanke.

Das wäre auch ne Möglichkeit, aber 0xAA ist bei mir z.B. auch Paketende. 
Dann müssen auch wieder Escapezeichen mit rein, das wollte ich 
eigentlich vermeiden.

> Weiterhin kommt dazu, dass große Pakete auch viel RAM brauchen, vor
> allem wenn mehrere in kurzer Zeit empfangen werden, und der µC noch
> andere Sachen zu tun hat. Bei mir haben sich daher 64 oder 128Byte
> Pakete durchgesetzt (64Byte für Netzwerke mit vielen Teilnehmern,
> 128Byte für Punkt zu Punkt Verbindungen).

Hört sich vernünfig an, wobei der Stack auch "on-the-fly" Verarbeitung 
und Generierung der Daten erlaubt.

> Als Baudrate verwende ich meist 10-20kBaud. Auch hier hat man wieder den
> Kompromiss: Hohe Baudraten sind störanfälliger, bei niedrigen Baudraten
> dauert die Übertragung länger, und die Warscheinlichkeit dass irgendein
> anderer Sender dazwischenfunkt wird höher. Bei höheren Baudraten nimmt
> meiner Erfahrung nach die Fehlerrate schnell zu.

Hälst du es für realistisch, dass man die Baudrate variabel macht? Also 
erst ein kurzes Sync mit Aushandlung der Baudrate und dann erst die 
Daten. Oder man legt für verschiedene Kanäle Baudraten fest. Dann hätte 
man einen Kanal für Signalisierung und einen für Burst-Transfers.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manuel Stahl wrote:

> So wie immer halt. Welche Paketlänge (in Millisekunden) empfiehlst du
> denn?

Ich würde bis etwa 100ms gehen. Das ergibt 256Bytes bei 20kBaud.

> Das Problem hatte ich auch schon, aber Schuld war nicht das RFM12
> sondern ein zu langsames SPI am Sender. Nur mit Hardware SPI auf 2Mbit
> und Interupts konnte ich sicherstellen, dass ich rechtzeitig Daten
> nachschieb. Könntest du mal prüfen, ob das nicht auch bei dir das
> Problem ist?

Ich lasse das SPI Interface mit 2.5MHz laufen (das maximale was der RF12 
kann). Bei einem 1 Byte im FIFO und 20kBaud hat der AVR 400µs Zeit um 
ein Byte zu liefern. Da sehe ich eigentlich keine Probleme, das kann ich 
bei mir auch ausschließen, da meine Senderoutine blockierend ist, der 
AVR wartet also nichtstuend darauf, das nächste Byte senden zu können. 
Ganz 100%ig kann ich es nicht ausschließen, da ich aber seit dem 
Einfügen des 0xAA nach 0x00 und 0xFF eine sehr viel geringere Fehlerrate 
habe, dürfte es daran gelegen haben.

> Das wäre auch ne Möglichkeit, aber 0xAA ist bei mir z.B. auch Paketende.

Ich übertrage gleich als erstes die Länge des Pakets. Das hat auch vor 
und Nachteile (was ist wenn die Länge falsch übertragen wurde? -> 
Plausibilitätsprüfung anhand der maximal zulässigen Paketgröße)

> Dann müssen auch wieder Escapezeichen mit rein, das wollte ich
> eigentlich vermeiden.

Bei mir sind 0x00 und 0xFF quasi die Escapezeichen selbst: Sobald die 
empfangen wurden, wird das nächste Byte komplett ignoriert.
Der Hamming Code sollte aber eigentlich vermeiden, dass 0x00 und 0xFF an 
Daten entstehen, so dass dieses Problem garnicht erst entsteht.

> Hälst du es für realistisch, dass man die Baudrate variabel macht? Also
> erst ein kurzes Sync mit Aushandlung der Baudrate und dann erst die
> Daten. Oder man legt für verschiedene Kanäle Baudraten fest. Dann hätte
> man einen Kanal für Signalisierung und einen für Burst-Transfers.

Sowas hatte ich anfangs vor, habe es dann aber verworfen, da mir der 
Aufwand zu hoch war:
Der Empfänger beurteilt die Qualität des empfangenen Signals und passt 
dynamisch die Parameter wie Baudrate, Sendeleistung usw. an. Bei einer 
Punkt zu Punkt Verbindung ist das noch leicht zu lösen, aber spätestens 
bei mehreren Teilnehmern dürfte das sehr kompliziert werden, vor allem 
wenn alle Teilnehmer gleichberechtigt sind, und es keinen Master gibt, 
der mit fester Baudrate arbeitet und an den sich alle anderen anmelden 
und der so die Parameter aller anderen kennt.
Dann müsste jeder neue Teilnehmer durch ausprobieren die Baudrate der 
anderen ermitteln, man müsste also einen Befehl einbauen, der an alle 
gesendet wird, und auf den diese mit einer Liste der aktuellen Parameter 
antworten.
Ein Problem wäre dann noch, wie man einen Baudratenwechsel sauber unter 
allen Teilnehmern koordiniert. Wie stellt man sicher, dass alle 
Teilnehmer die neue Baudrate mitbekommen haben? Eine mögliche Lösung 
wäre regelmäßig einen Ping auszusenden, und wenn der eine bestimmte Zeit 
lang nicht beantwortet wurde, springt das entsprechende Modul in den 
Suchmodus in dem es mit allen Baudraten versucht jemanden zu erreichen.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder eben fixe Baudraten für verschiedene Kanäle. Wenn man schneller 
übertragen möchte, wechselt man (nach Absprache) den Kanal.

Autor: Chris S. (schris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Module, welche zusaetzlich eine uC draufhaben, haben eine AVR drauf.
Kostenpunkt, 3-4Euro.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich überlege gerade Broadcast Gruppen einzuführen.

Individuelle IDs und Gruppen IDs wären nur 7-bit groß. Ist das MSB 
gesetzt, ist die Gruppe gemeint. 0xff ist Broadcast an alle.

Ein mögliches Anwendungsgebiet wären z.B. Lichtschalter, die mehrere 
Lichter gleichzeitig Schalten wollen.

Oder man könnte alle Steckdosen ausschalten, ohne das Licht 
auszuschalten.

Die Konfiguration der Gruppen müsste dann über das Layer 3 Protokoll mit 
der TypeID 0 gehen.

Autor: Helmut -dc3yc (dc3yc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Manuel,

könntest du bitte ins Programm eine Abfrage reinmachen, dass nur die 
Kanäle 4-7 verwendet werden können? Ausserdem wäre ein Hinweis nicht 
schlecht, dass beim Verwenden von Kanälen ausserhalb dieses Bereiches 
andere Funkdienste gestört werden und dieser Betrieb in der EU nicht 
erlaubt ist. Im Störungsfall können Messeinsätze der BNetzA nicht 
unerhebliche Kosten sowie Bussgelder verursachen, da diese Sender kein 
CE-Kennzeichen besitzen.

Servus,
Helmut

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut -dc3yc wrote:
> Im Störungsfall können Messeinsätze der BNetzA nicht
> unerhebliche Kosten sowie Bussgelder verursachen, da diese Sender kein
> CE-Kennzeichen besitzen.

Keine Ahnung wie das genau ist, da der Sender ja an sich nicht komplett 
ist ohne Ansteuerung, aber für die RFM12 gibt es hier eine CE 
Konformitätserklärung:
http://www.pollin.de/shop/static/konformitaet/D810049K.PDF

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Helmut:

geb mir mal noch n Link auf ne Seite wo die entspr. Richtlinie steht. 
Dann bau ich das ein.

Das Wiki kannst du übrigens selbst ändern.

Autor: Helmut -dc3yc (dc3yc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also der Link der Allgemeinverfügung der BNetzA ist hier: 
http://www.bundesnetzagentur.de/media/archive/298.pdf

Ui, die CE-Erklärung hab ich mir mal ausgedruckt! Da werde ich morgen 
gleich den Herrn Dipl. Ing. (FH) Werner Pollin anrufen und ihn fragen, 
wie er dafür  CE erteilt.

Ok, dann werde ich das mal wieder rückändern, hatte das Wiki schon 
ergänzt. Aber da muss ich nachfragen, wie man dafür CE erteilen kann.

Werde mich da wieder melden, was herausgekommen ist.

Servus,
Helmut.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manuel Stahl wrote:

> Ich würde demnächst am Stack weitermachen, hätte aber vorher Feedback ob
> das Design so für die meisten taugt, oder ob ich lieber was ändern soll.

> Wer hätte denn überhaupt Interesse den Stack zu benutzen?

Also ich habe den Stack für mein Projekt lauffähig gemacht. Allerdings 
bin ich jetzt etwas stutzig geworden. Das Problem ist, wie der CRC Check 
von der LLC Schicht gemacht werden soll ohne die empfangenen Daten in 
der LLC Schicht zu puffern und ohne die CRC Checksumme als letztes Byte 
der L3 Schicht zu übergeben. Die sollte ja vom CRC Check nichts 
mitbekommen. Die einzige Lösung aus meiner Sicht wäre, das LLC 
Frameformat um eine Längenangabe zu erweitern.

Viele Grüße,

Jens

Autor: Manuel Stahl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man die CRC checken will, müsste eigentlich sowieso das ganze Paket 
gepuffert werden und erst nach erfolgreichem Check an den L3 gehen. Um 
nachträglich zu prüfen reicht jedoch schon 1 Byte Puffer, so dass der L3 
den Datenstrom um 1 Byte versetzt bekommt. Die LLC bekommt ja mit, wenn 
das Paket zu Ende ist und kann dann das Byte im Puffer als CRC 
verwenden.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Manuel,

> Wenn man die CRC checken will, müsste eigentlich sowieso das ganze Paket
> gepuffert werden und erst nach erfolgreichem Check an den L3 gehen.

Die in der Referenzimplementierung verwendete 
_crc_ibutton_update()-Funktion benutze ich byteweise (direkt beim 
Empfangen eines Bytes), dann speichere ich jeweils die temporäre CRC 
zwischen und am Ende wird die Funkton mit der gesendeten CRC aufgerufen 
- als Ergebnis muss Null herauskommen. So kann man sich das 
Zwischenspeichern des gesamten Frames sparen.

Die eigentliche Frage ist, wie man die Daten an die L3 Schicht übergeben 
soll. Ich bin bis jetzt von der Beispiel L3-Implementierung aus der 
Diskussion zum Stack ausgegangen. Hier werden die Daten byteweise 
übergeben.
Das hat aus meiner Sicht den Nachteil, dass die L3-Schicht erst am Ende 
der Übertragung weiss ob die Daten korrekt sind (die sie aber schon 
empfangen hat). Die Fehlersicherung findet doch aber in der LLC-Schicht 
statt und sollte die L3-Schicht nicht kümmern.
Es wäre natürlich auch möglich die Fehlersicherung für Bytestreams ganz 
wegzulassen.

Alternativ kann man, wie Du schon vorgeschlagen hast, das ganze Paket in 
der LLC-Schicht zwischenspeichern, dann den CRC-Check machen und 
anschließend als ganzes Paket an die L3-Schicht übergeben. Hiermit 
könnte man auch streamen indem man ein Byte pro Paket verschickt - 
allerdings mit großem Overhead.

Also Byte oder Paket an die L3 übergeben, das ist die Frage ;-)

Viele Grüße,

Jens

Autor: Manuel Stahl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Meinung nach beides, über zwei getrennte APIs für die L3, weil 
nur diese entscheiden kann, ob sie streaming- oder packet-basiert 
arbeiten will.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.