Netzwerkprotokoll für RFM12

[cd_brenner]

Nehmen wir Mal an, du brauchst jede Sekunde neue Daten. Wenn das "Token" bei einem Knoten nicht ankommt, wird er im besten Fall eine Sekunde später (bei der nächsten Iteration) regieren. Oder wenn irgendetwas die Verbindung stark verschlechtert, erst noch viel später. Dieser Aussetzer kann unter Umständen zu lange für deinen Anwendungszweck sein.

Okay - jetzt hab ichs. Ich bin zu optimistisch an die Sache rangegangen und hab gedacht, dass Sendefehler eh recht selten ist. Wenn eine von 20 Tokennachrichten schief geht wärs nicht so tragisch, wenn das Ergebnis erst 1sec später kommt. Aber offenbar ist Funk doch fehleranfälliger.

Das nennt man kooperatives Multitasking.

An sowas hab ich schon gedacht: Quasi immer ein Stückerl abarbeiten sodass die Main-While nicht zu lange unterbrochen ist. Ich denke, ich werde hier relativ oft Flags einsetzen müssen um eine längere Aufgabe wie "fade über 3h ein" zu koordinieren. So wird halt der PWM-Wert alle 20ms (50hz) erhöht - pro Schleifendurchlauf 1x.

http://stefanfrings.de/avr_io/protosockets.html

LG Markus

[markusj]

Okay - jetzt hab ichs. Ich bin zu optimistisch an die Sache rangegangen und hab gedacht, dass Sendefehler eh recht selten ist. Wenn eine von 20 Tokennachrichten schief geht wärs nicht so tragisch, wenn das Ergebnis erst 1sec später kommt. Aber offenbar ist Funk doch fehleranfälliger.

Muss nicht. Kann aber. Das hängt von deinem Funkmodul, dem Rauschen was sonst noch so in der Umgebung unterwegs ist, sowie der Umgebung selbst, ab. Wenn du einen der Knoten hinter eine Blechwand steckst, kommt halt wenig Pegel beim Empfänger an.
Worauf ich hinaus wollte: Es gibt eine (dir momentan unbekannte) Verlustwahrscheinlichkeit, du solltest das also berücksichtigen und Gegenmaßnahmen einplanen.

An sowas hab ich schon gedacht: Quasi immer ein Stückerl abarbeiten sodass die Main-While nicht zu lange unterbrochen ist. Ich denke, ich werde hier relativ oft Flags einsetzen müssen um eine längere Aufgabe wie "fade über 3h ein" zu koordinieren. So wird halt der PWM-Wert alle 20ms (50hz) erhöht - pro Schleifendurchlauf 1x.

Mal rein aus Neugierde: 3h alle 20ms ein Inkrement entspricht 19-Bit PWM. Mit welchem Mikrocontroller hast du so eine hohe PWM-Auflösung?! Mir ist kein 8-Bit AVR bekannt, der das bietet.
Und Flags ... naja, ich hätte eher an Zähler gedacht. Wie gesagt, sieh dir Mal die Delta-Queue an, das eignet sich perfekt für zeitgesteuertes Task-Management.

mfG
Markus

[cd_brenner]

Muss nicht. Kann aber. Das hängt von deinem Funkmodul, dem Rauschen was sonst noch so in der Umgebung unterwegs ist, sowie der Umgebung selbst, ab. Wenn du einen der Knoten hinter eine Blechwand steckst, kommt halt wenig Pegel beim Empfänger an.
Worauf ich hinaus wollte: Es gibt eine (dir momentan unbekannte) Verlustwahrscheinlichkeit, du solltest das also berücksichtigen und Gegenmaßnahmen einplanen.

Okay - danke für deine ausführliche Erklärung!

Mal rein aus Neugierde: 3h alle 20ms ein Inkrement entspricht 19-Bit PWM. Mit welchem Mikrocontroller hast du so eine hohe PWM-Auflösung?! Mir ist kein 8-Bit AVR bekannt, der das bietet.

Bei dieser Aussage hab ich das natürlich nicht bedacht - ist aber klar, dass die Auflösung bei so vielen Werten nicht mitspielt. Ich denke die PWM Frequenz muss sowiso an den entsprechenden Anwendungsfall angepasst werden. Bei LEDs würde ich diese höher wählen als bei recht trägen Halogenspots.

Frage am Rande: Welchen MOSFET kann ich für einen 20W Halogenspot mit 12V verwenden?

Ist es klug auf einem Microcontroller den Speicher für den FrameBuffer (Nachricht empfangen -> Buffer schreiben -> Tokenweitergabe -> Buffer lesen -> Nachricht senden) dynamisch zu allokieren (malloc) - denn es ist effektiver wenn der Buffer nicht wie ein FIFO funktioniert, sondern auch Frames "in der Mitte" aus dem Buffer lesen kann, oder?

Vielen Dank.

[markusj]

Frage am Rande: Welchen MOSFET kann ich für einen 20W Halogenspot mit 12V verwenden?

So ziemlich jeder Leistungs-MOSTFET wird sich da langweilen. Nimm den günstigsten n-MOS der 2,5A oder mehr ab kann und einen niedrigen RDS_on bei Logikpegeln (5V) hat. Günstig zu haben ist zum Beispiel der IRLZ24, mit einem RDS_on von 0,1Ohm macht das eine Verlustleistung von nur 0,17W bei den 20W/12V=1,7V die da fließen.
Ach ja: Die Lampe wird mit Gleichspannung betrieben, oder? Normale MOSFETs können keine Wechselspannung schalten.

Ist es klug auf einem Microcontroller den Speicher für den FrameBuffer (Nachricht empfangen -> Buffer schreiben -> Tokenweitergabe -> Buffer lesen -> Nachricht senden) dynamisch zu allokieren (malloc) - denn es ist effektiver wenn der Buffer nicht wie ein FIFO funktioniert, sondern auch Frames "in der Mitte" aus dem Buffer lesen kann, oder?

Dynamische Speicherallokation auf Mikrocontrollern ist normalerweise eine schlechte Idee. Langsam, benötigt größere Mengen Flash für die Speicherverwaltung und ist anfällig für Speicherfragmentierung.

Was du mit dem zweiten Teil der Frage meinst, erschließt sich mir leider nicht.

mfG
Markus

[cd_brenner]

Dynamische Speicherallokation auf Mikrocontrollern ist normalerweise eine schlechte Idee. Langsam, benötigt größere Mengen Flash für die Speicherverwaltung und ist anfällig für Speicherfragmentierung.

Also besser schon beim Compillieren den max. benötigten Speicher einplanen. Verstehe.

Was du mit dem zweiten Teil der Frage meinst, erschließt sich mir leider nicht.

Nun ja - aus einem FIFO kann ich ja nur den aktuell ältesten Datensatz (First Out) lesen. Ich möchte aber Frames nicht im Buffer lassen, nur weil es zur Zeit nicht an erster Position verfügbar ist, sondern möchte an beliebigen Stellen im Buffer zugreifen können. Das sollte aber mit einer verketteten Liste kein Problem sein, oder?

LG aus Graz.

[markusj]

Nun ja - aus einem FIFO kann ich ja nur den aktuell ältesten Datensatz (First Out) lesen. Ich möchte aber Frames nicht im Buffer lassen, nur weil es zur Zeit nicht an erster Position verfügbar ist, sondern möchte an beliebigen Stellen im Buffer zugreifen können. Das sollte aber mit einer verketteten Liste kein Problem sein, oder?

FIFOs sind dafür nicht geeignet, da liegst du richtig. Normalerweise parst man die Daten aus empfangenen Paketen raus und legt sie dann in geeigneten Datenstrukturen ab, wenn man sie für länger braucht. Insbesondere trennt man eigentlich den Netzwerkstack von der weiteren Datenverarbeitung, einfach der Modularisierung/Flexibilisierung wegen.

mfG
Markus

[wkrug]

Thema FET:

Meine "Waffe" für solche Fälle ist der IRF3708.
Hat schon bei 5V sehr geringen RDS On ( 12mOhm ).
Genügend Reserven ( 63A ) - Bis 10A ohne Kühlkörper.
Leicht erhältlich, Preislich OK.

U-DS darf dabei allerdings 30V nicht überschreiten.

Wenn's was im SO8 Gehäuse sein soll - Wie wär's mit dem IRF7455.
Den verbau ich in kleineren Brushless Reglern. Ist aber etwas schwerer zu bekommen.

Da eine Halogen Lampe einen sehr geringen Kalt Widerstand hat, würde ich den FET 10fach überdimensionieren - Deshalb solche Oschis von FET Typen.

Die RFM12 Funk Module sind etwas Tricky, hast Du schon etwas Erfahrung mit den Bausteinen?

Thema Puffer:
Ich nehm für die Eingangs - Rohdaten gerne einen fixen Ringpuffer mit Schreib- und Lesezeigern.
Das schafft für den empfangenden Controller etwas Zeit für die Abarbeitung und es sollten keine Bytes verloren gehen.
Aus diesem Puffer kann man sich dann die Daten rausparsen und wieder Puffern oder in String Variablen oder struct's zur weiteren Verarbeitung ablegen.

Wenn Du die Daten schon verschlüsseln willst, würde ich versuchen ein Protokoll zu nehmen, das auch zumindest eine Einzelbit- Fehlerkorrektur erlaubt.
Wobei ich den Sinn einer Verschlüsselung für Deinen Zweck eigentlich nicht so richtig erkennen kann - Ausser als Lerneffekt, oder Kopierschutz für eventuelle Nachbauer.