Forum: Projekte & Code NRF24L01+ test program for Arduino Uno


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von NRFTestGuy (Gast)


Angehängte Dateien:

Bewertung
lesenswert
nicht lesenswert
Arduino Uno NRF24L01+ Test Code
--------------------------------
(c) NRFTestGuy  07'2016

Free for private non-commercial usage.

Also works with the Windows App NRF24_Tester
available here:
Beitrag "NRF24L01 - Testprogramm für Windows PC"

Prerequisites
---------------

- Arduino Uno (Arduino Micro, Arduino Nano)
  must be set up to run at 16 MHz

  The Arduino as a board is not absolutely required. You can
  use a naked ATMega328p running at 16 MHz with RS232
  connection to your computer. Just use the port pins  PB0-PB5
  (as documented in the Fritzing schematic) and the RX/TX
  lines.

- USB Connection to Arduino's USB Port

- NRF24L01+  wired to the Arduino (see Fritzing schematic)

- A Terminal Application on your PC
  (connect at baud rate 115200 baud, 8 bit, 1 stop, no parity)

- A Programmer (such as AVRDude) to put the HEX file via USB
connection on your Arduino

- program the hex file in your ATMega328


This is how the terminal output should look like:

  Arduino Uno - NRF24L01+ Test
  Version 0.10 (c) NRFTestGuy
  (Build xxx xx xxxx  xx:xx:xx)
-----------------------------------
 T: Transmit Data
 R: Receive Data
 F: Fast Transmit
 G: Fast Receive

 L: NRF24 Loopback Test
 O: Continuous Loopback Test
 S: Show Parameters
 A: Required Pin Assignments
 config:0x2D  status:0x0E  mem:127
-----------------------------------
>

von Lars R. (lrs)


Bewertung
lesenswert
nicht lesenswert
...also ein SPI-RS232-USB-VirtualCom Konverter mit Funktionsgarantie für 
NRF24. Interessant. Funktioniert das auch performant mit 1Mbit und 
2Mbit? HW/Handshake beim RS232?

: Bearbeitet durch User
von NRFTestGuy (Gast)


Bewertung
lesenswert
nicht lesenswert
Lars R. schrieb:
> ...also ein SPI-RS232-USB-VirtualCom Konverter

Nein. Ein Arduino (Mega328-) Code zur prinzipiellen Funktions-
überprüfung. Man lese den Titel (--> Test Program)

Lars R. schrieb:
> mit Funktionsgarantie für NRF24.

Willst du ein Zertifikat?

Lars R. schrieb:
> Funktioniert das auch performant mit 1Mbit

Ja. Im Fast Mode werden Pakete nicht angezeigt sondern nur
ein minimalistischer Funktionsablauf gezeigt der das Senden/
Empfangen von Paketen bestätigt. Die Netto-Datenrate (payload)
liegt bei 1 Mbit etwa bei 1200 Paketen (a 32 Bytes) pro Sekunde.
Mit Arduino-Lib wird das wohl nicht so funktionieren.

Im nicht-fast Mode wird das empfangene Paket angezeigt. Durch
die Ausgabe via Terminal wird die Transfer-Rate heruntergebremst.

Lars R. schrieb:
> und 2Mbit?

Nein weil Bitrate festverdrahtet ist auf 1 Mbit.

von Lars R. (lrs)


Bewertung
lesenswert
nicht lesenswert
NRFTestGuy schrieb:
> Lars R. schrieb:
>> mit Funktionsgarantie für NRF24.
>
> Willst du ein Zertifikat?

Nein, so war das nicht gemeint.

> Lars R. schrieb:
>> Funktioniert das auch performant mit 1Mbit
>
> Ja. Im Fast Mode werden Pakete nicht angezeigt sondern nur
> ein minimalistischer Funktionsablauf gezeigt der das Senden/
> Empfangen von Paketen bestätigt. Die Netto-Datenrate (payload)
> liegt bei 1 Mbit etwa bei 1200 Paketen (a 32 Bytes) pro Sekunde.
> Mit Arduino-Lib wird das wohl nicht so funktionieren.

Ein Mehrwert (der ursprünglich nicht von Dir absichtigt war), entsteht, 
wenn man das NRF24 komfortabel über UART oder virtualCOM konfigurieren 
kann und dann eine transparente UART-Verbindung hat. Wobei die 
Verbindung auch nicht komplett transparent sein braucht; nur so, dass 
man auf einfache Weise eine Datenverarbeitung anbinden kann.
2Mbit müssen es für mich nicht sein, aber weniger als 1MBit Over-the-air 
ist für manche Anwendungen zu wenig. Da geringen Datenraten sind dann 
die RFM performanter.

> Lars R. schrieb:
>> und 2Mbit?
>
> Nein weil Bitrate festverdrahtet ist auf 1 Mbit.

Wo? Bei der Beschaltung des nrf24?

: Bearbeitet durch User
von NRFTestGuy (Gast)


Bewertung
lesenswert
nicht lesenswert
Lars R. schrieb:
> Wo? Bei der Beschaltung des nrf24?

Auch eine Software kann "festverdrahtet" sein. Im Gegensatz
zu konfigurierbar oder parametrisierbar.

Lars R. schrieb:
> wenn man das NRF24 komfortabel über UART oder virtualCOM konfigurieren
> kann und dann eine transparente UART-Verbindung hat.

Das war absolut nicht Sinn der Übung.

Du würdest sicherlich auch bei Kommunikation Wert darauf legen
einen zuverlässigen Partner jederzeit zur Verfügung zu haben.
Dieses Stück Programm erfüllt genau diesen Anspruch.

von Lars R. (lrs)


Bewertung
lesenswert
nicht lesenswert
..."fest kodiert", um Verwirrungen vorzubeugen; gerade bei HW-bezogenen 
Projekten.


...schon klar, wie geschrieben. Ich wollte nur noch einen anderen Weg 
aufzeigen. Wie im anderen Thread bereits geschrieben wurde: Wenn man 
sich für die Nutzung eines NRF24 selbst in das NRF24 einarbeiten muss, 
weil Dein Projekt für die Nutzung nicht vorgesehen ist, dann braucht man 
Dein Projekt auch nicht, weil man sich ohnehin selbst einarbeiten muss. 
Natürlich war das Projekt sinnvoll für Dich. Nur, wenn die 
Projekteigenschaften derart sind, dass dieses Projekt nur für Dich einen 
Vorteil hatte und haben kann und dies auch so bleiben soll, so stellt 
sich die Frage, warum Du das Material dazu hier überhaupt online und zur 
Diskussion stellst. Vielleicht ist mir das entgangen. Etwa für den Fall, 
dass man ein paar NRF24 herumliegen hat, sich nicht einarbeiten will, 
weil man ohnehin die Nutzung nicht plant, aber trotzdem mal schauen 
will, ob sie noch funktionieren?

von NRFTestGuy (Gast)


Bewertung
lesenswert
nicht lesenswert
Lars R. schrieb:
> so stellt
> sich die Frage, warum Du das Material dazu hier überhaupt online
> und zur Diskussion stellst

Ich stelle es zur Verfügung. Zur Diskussion stelle ich es nicht,
(wo wäre diese Bemerkung zu finden?) habe nicht dazu aufgerufen,
habe aber auch nichts dagegen.

von NRFTestGuy (Gast)



Bewertung
lesenswert
nicht lesenswert
Hier zwei Beispiel-Aufbauten welche einwandfrei funktionieren
(entsprechend der Eingangs gezeigten Schaltung).

Hervorzuheben wären die jeweils vorhandenen Abblock-
Kondensatoren die den NRF24 erst auf den Arduinos
funktionssicher machen. Man darf sich keinesfalls alleine auf
die Stabilisierung und Entstörung der Versorgung von den
Arduinos zum NRF24 hin verlassen.

Diese Aussage mag nur teilweise zutreffen da es bekanntlich
eine grosse Auswahl von mehr oder weniger verschieden
hergestellten Arduinos gibt (Bauteil- bzw Layout-Streuungen).

Aber zwei zusätzliche Kondensatoren kosten nichts und geben
die Sicherheit dass an dieser Stelle nichts im Argen liegt.

von Lars R. (lrs)


Bewertung
lesenswert
nicht lesenswert
NRFTestGuy schrieb:
> Im nicht-fast Mode wird das empfangene Paket angezeigt. Durch
> die Ausgabe via Terminal wird die Transfer-Rate heruntergebremst.

Darf ich noch einmal darauf zurück kommen?
Auf welchen Wert wird die Transfer-Rate bei Ausgabe via Terminal aktuell 
heruntergebremst?
Kannst Du abschätzen, was mit Deinem Design mit einem STM32-Arduino 
(32Bit, 72MHz, HW-SPI) möglich ist?

> Ja. Im Fast Mode werden Pakete nicht angezeigt sondern nur
> ein minimalistischer Funktionsablauf gezeigt der das Senden/
> Empfangen von Paketen bestätigt. Die Netto-Datenrate (payload)
> liegt bei 1 Mbit etwa bei 1200 Paketen (a 32 Bytes) pro Sekunde.

1200*32*8=0.3Mbit Ist diesbezüglich trotz deaktivierter Terminalausgabe 
das Bottleneck der ATMega328p?

von NRFTestGuy (Gast)


Bewertung
lesenswert
nicht lesenswert
Lars R. schrieb:
> Darf ich noch einmal darauf zurück kommen?

Ja sicher.

Lars R. schrieb:
> Auf welchen Wert wird die Transfer-Rate bei Ausgabe via Terminal aktuell
> heruntergebremst?

Das ist nicht relevant, auch schlecht messbar. Dahingehend habe
ich nichts optimiert, daher ist ein Rückschluss auf das maximal
Mögliche nicht ermittelbar.

Lars R. schrieb:
> Kannst Du abschätzen, was mit Deinem Design mit einem STM32-Arduino
> (32Bit, 72MHz, HW-SPI) möglich ist?

NRFTestGuy schrieb:
> Die Netto-Datenrate (payload)
> liegt bei 1 Mbit etwa bei 1200 Paketen (a 32 Bytes) pro Sekunde.

Das trifft es schon ganz gut. Die Begrenzung liegt an der SPI
Datenrate mit der man den NRF speisen darf. Und die liegt zufällig
bei den 8...10 MBit/s die ein AVR kann.

Eine leichte Verbesserung wird man noch mit SPI-DMA auf einem ARM
erreichen können, und das "Umkopieren" des Datenblocks mag auch
noch etwas schneller vonstatten gehen. Also alles in allem
vielleicht 1500-2000 Pakete/s .....

Lars R. schrieb:
> 1200*32*8=0.3Mbit

So darf man nicht rechnen, denn der Overhead den der NRF braucht
ist enorm (siehe Timing-Diagramme). Und man darf nicht übersehen
dass bei jedem Paket ein Acknowledge dabei ist, eine Garantie dass
die Daten korrekt, fehlerfrei angekommen sind. Wenn man das nicht
braucht geht es ohne Ack nochmal schneller.

Lars R. schrieb:
> mit Deinem Design

hat das nicht viel zu tun (ich schliesse ja den NRF auch nur an
das SPI an) ausser dass ich schon immer Speed wollte und ich
dahingehend vielleicht etwas "optimierend" arbeite, keine
Arduino-Lib auch nur anrühre ...

von Lars R. (lrs)


Bewertung
lesenswert
nicht lesenswert
NRFTestGuy schrieb:
> Eine leichte Verbesserung wird man noch mit SPI-DMA auf einem ARM
> erreichen können, und das "Umkopieren" des Datenblocks mag auch
> noch etwas schneller vonstatten gehen. Also alles in allem
> vielleicht 1500-2000 Pakete/s .....
>
> Lars R. schrieb:
>> 1200*32*8=0.3Mbit
>
> So darf man nicht rechnen, denn der Overhead den der NRF braucht
> ist enorm (siehe Timing-Diagramme). Und man darf nicht übersehen
> dass bei jedem Paket ein Acknowledge dabei ist, eine Garantie dass
> die Daten korrekt, fehlerfrei angekommen sind. Wenn man das nicht
> braucht geht es ohne Ack nochmal schneller.

Das hatte ich nicht bedacht, weil ACK für mich nicht wichtig ist. Ja, es 
ist dann schon performant wenn 1500-2000 Pakete mit ACK übertragen 
werden und ohne ACK mehr.

von NRFTestGuy (Gast)


Bewertung
lesenswert
nicht lesenswert
Um mal zu sehen was beim NRF24 theoretisch "geht" hier
eine Abschätzung zur Datenrate:

Ein gesamtes Paket besteht aus

Preamble   1
Address    5
Packet control field  2 (9 bit, unklar)
Payload   32
CRC        2
---------------
Summe     42 Bytes

42 x 8 = 336 bits

336 bits @ 1MBit/s --> 336 usec
wenn man annimmt dass die Codierung auf dem HF-Träger nicht
redundand ist.

Hinzu kommt eine interne Verarbeitungszeit der Maschine
für ein Paket die offensichtlich fest 130usec dauert.

Das Mindeste für einen ACK-Transfer von 32 Bytes bei
1MBit/sec wären also 466usec, Overhead des Mikrocontrollers
nicht mitgerechnet.

Zurückgerechnet auf die maximal mögliche Datenrate wären
das 2145 Blöcke/s (à 32 Bytes netto ergibt 68640 Bytes/s)
rein bezogen auf das was der NRF24 zu leisten vermag.

Bei 2 MBit/sec kann man das nochmal etwas schneller werden
aber die 130usec Verarbeitungszeit bleiben wohl fest.

Für Das "Abholen" (oder Senden) eines Blocks mit dem
Mikrokontroller (beschränkt durch die SPI Datenrate 10MBit/sec
des NRF24) wären dann noch mindestens 25usec zusätzlich
erforderlich. Nehmen wir mal für SPI Kommandierung und
Interrupt-Latenz noch 5usec dazu ergibt das für ein gesamtes
Paket 466+30usec = 496usec oder umgerechnet 2016 Blöcke/s
(ergibt eine Netto-Datenrate von gut 64 KBytes pro Sekunde).

Falls ich etwas nicht richtig betrachtet habe korrigiert mich.

von Lars R. (lrs)


Bewertung
lesenswert
nicht lesenswert
In Deiner Kalkulation habe ich keinen Rechenfehler gefunden.

Falls man jedoch die Shockburst-Features und ACK nicht benötigt, so ist 
die minimale Packetgröße:

Preamble   1
Address    3
Payload   32
============
36 Byte = 288Bit

http://yveaux.blogspot.de/2014/07/nrf24l01-sniffer-part-1.html

Mit Shockburst und ACK in Bits:

Preamble   8  (1 Byte)
Address    24 (3 Byte)
Packet control field  9
Payload   256 (32Byte)
CRC        8 (1 Byte)
---------------
305 Bits

Die Variante ohne Shockburst finde ich nicht deshalb interessant, um 
die letzten Prozente an Performanz heraus zu holen, sondern weil man 
ohne Shockburst auch Pakete mit fehlerhaftem CRC empfangen kann.

von Lothar (Gast)


Bewertung
lesenswert
nicht lesenswert
> Falls ich etwas nicht richtig betrachtet habe korrigiert mich.

Die Quelltexte fehlen (mir).

von NRFTestGuy (Gast)


Bewertung
lesenswert
nicht lesenswert
Lars R. schrieb:
> sondern weil man
> ohne Shockburst auch Pakete mit fehlerhaftem CRC empfangen kann.

An welche Anwendung (mit ohne ACK) denkst du da?

Mir fällt da momentan nur Audio Streaming ein wo es nicht auf
das letzte Bit ankommt, oder Nahfeld-Kommunikation beliebiger
Art wo die Übertragung an sich sowieso sicher(er) ist.

Mir leuchtet nicht so recht ein was man mit geschrotteten
Empfangspaketen machen kann .....

von NRFTestGuy (Gast)


Bewertung
lesenswert
nicht lesenswert
Lothar schrieb:
> Die Quelltexte fehlen (mir).

Soll ich dir das PDF vom NRF24 hier reinkopieren?

von Lars R. (lrs)


Bewertung
lesenswert
nicht lesenswert
Anmerkung:
Vielleicht wird ein Teil der 130usec auch für das Shockburst-Protokoll 
und die CRC-Berechnung benötigt.

von NRFTestGuy (Gast)


Bewertung
lesenswert
nicht lesenswert
Lars R. schrieb:
> Vielleicht wird ein Teil der 130usec auch für das Shockburst-Protokoll
> und die CRC-Berechnung benötigt.

So ist es wohl.

von Lars R. (lrs)


Bewertung
lesenswert
nicht lesenswert
NRFTestGuy schrieb:
> Lars R. schrieb:
>> sondern weil man
>> ohne Shockburst auch Pakete mit fehlerhaftem CRC empfangen kann.
>
> An welche Anwendung (mit ohne ACK) denkst du da?
>

https://hackaday.io/project/11942-antenna-diversity-receive-and-transmit

Ich würde die Algorithmen und die praktische Nützlichkeit gern erst 
einmal am PC testen. Daher der Wunsch nach einem UART-Umsetzer.

von Lars R. (lrs)


Bewertung
lesenswert
nicht lesenswert
Hier wurde mit dem ESP8266 erwartungsgemäß gemessen und visualisiert, 
dass der Empfang von 2.4GHz-Signalen je nach Umgebung (die sich ggf auch 
noch verändert) lokal stark schwankt:

https://youtu.be/aqqEYz38ens?list=PLDRymMFQl3Nktk_pjlUP_wbLIXre3sody&t=168

Eine Antenne kann zu einem Zeitpunkt aber immer nur an einer Stelle 
sein...

von NRFTestGuy (Gast)


Bewertung
lesenswert
nicht lesenswert
Lars R. schrieb:
> Daher der Wunsch nach einem UART-Umsetzer.

Nimmst du die Arduino-Lib und schreibst deinen "Dreizeiler"
zum Kommunizieren mit der RS232.

von Lars R. (lrs)


Bewertung
lesenswert
nicht lesenswert
NRFTestGuy schrieb:
> Lars R. schrieb:
>> Daher der Wunsch nach einem UART-Umsetzer.
>
> Nimmst du die Arduino-Lib und schreibst deinen "Dreizeiler"
> zum Kommunizieren mit der RS232.

Diesbezüglich ergeben sich Fragen:
Ist die Lib für den Betrieb ohne Shockburst vorgesehen?
Ist die Lib auch performant genug und holt wirklich jedes Paket aus dem 
NRF?
Nutzt sie dafür den IRQ?
Gibt es diesbezüglich Stolpersteine mit dem Arduino, die eine hohen 
Durchsatz verhindern können? (Habe noch nichts mit Arduino gemacht)
Am Besten ist wohl der Betrieb am STM32-Arduino für 2,50EUR von Ebay?
Wahrscheinlich benötige ich auch noch eine einmalige Synchronisation 
zwischen den Empfangern.

Mein Eindruck war, dass es mit einem "Dreizeiler" nicht getan ist. Daher 
habe ich das erst einmal liegen lassen.

von Arduinoquäler (Gast)


Bewertung
lesenswert
nicht lesenswert
Lars R. schrieb:
> Diesbezüglich ergeben sich Fragen:

.... die ich dir nicht beantworten kann, die sich aber
durch ein Studium der (offenen) Quellen und der Arduino-API
klären lassen können.

Lars R. schrieb:
> Mein Eindruck war, dass es mit einem "Dreizeiler" nicht getan ist.

Dafür habe ich ja auch nicht Dreizeiler geschrieben sondern 
"Dreizeiler".
Bei der Arduino Gemeinde ist alles immer soooooooo einfach .....

von Arduinoquäler (Gast)


Bewertung
lesenswert
nicht lesenswert
NRFTestGuy = Arduinoquäler

von Lars R. (lrs)


Bewertung
lesenswert
nicht lesenswert
Eben deshalb. Die Lib ist dafür nicht vorgesehen. Es geht nicht mit 
einem Dreizeiler und auch nicht mit einem "Dreizeiler" ;)

Achso. Oder meintest Du die ganze Aussage ironisch? Falls ja, dann 
Zustimmung.

: Bearbeitet durch User
von Lothar (Gast)


Bewertung
lesenswert
nicht lesenswert
NRFTestGuy schrieb:
> Lothar schrieb:
>> Die Quelltexte fehlen (mir).
>
> Soll ich dir das PDF vom NRF24 hier reinkopieren?

Ja.

von NRFTestGuy (Gast)


Bewertung
lesenswert
nicht lesenswert
Du wirst mit RS232-Umsetzung vermutlich sowieso nicht die
"Performanz" (gibt's das?), Performance herausholen können
die du dir wünschst.

Nicht einmal mit einem FT2232 der direkt SPI könnte, denn
das USB Protokoll lässt nur einzelne Transfers (mehrere
Kommandos + IRQ Polling + 1 Nutzdatenblock) im 1ms-Zeitraster
zu die die ganze Kommunikation stark ausbremsen.

Alles selbst schon durchgemacht. Deshalb habe ich diesen
Ansatz schon mal nicht umgesetzt, nicht zuletzt wegen des
Aufwands ein Testinterface mit FT2232 aufzubauen.

von NRFTestGuy (Gast)


Bewertung
lesenswert
nicht lesenswert
Lothar schrieb:
> Ja.

Mach ich aber nicht. Kannst du dir bei Nordic selbst abholen.

von Lars R. (lrs)


Bewertung
lesenswert
nicht lesenswert
NRFTestGuy schrieb:
> Du wirst mit RS232-Umsetzung vermutlich sowieso nicht die
> "Performanz" (gibt's das?), Performance herausholen können
> die du dir wünschst.
>
> Nicht einmal mit einem FT2232 der direkt SPI könnte, denn
> das USB Protokoll lässt nur einzelne Transfers (mehrere
> Kommandos + IRQ Polling + 1 Nutzdatenblock) im 1ms-Zeitraster
> zu die die ganze Kommunikation stark ausbremsen.
>
> Alles selbst schon durchgemacht. Deshalb habe ich diesen
> Ansatz schon mal nicht umgesetzt, nicht zuletzt wegen des
> Aufwands ein Testinterface mit FT2232 aufzubauen.

Da sehe ich kein Problem, zumindest nicht beim Empfangen. Die Daten 
landen im Buffer. Beim Senden kann es sein, das man mit dem Schreiben 
von lediglich 32Byte nicht die volle Performance erzielt. Aber dazu gibt 
es Optionen im Treiber. Vielleicht könnte man ja auch mehrere Pakete auf 
einmal schicken? Ein paar Byte SRAM hat der uC schließlich auch.

Der Ablauf wäre wie folgt:
PC sendet "C" (oder ähnliches): Es folgen Konfigurationsdaten
PC sendet "T": Es folgen 32 Byte Daten
Idealerweise hat der uC HW-Handshake für UART. Dieses kann man am PC 
auswerten. Falls der uC kein Handshake hat (AtMega), so müsste der uC 
jedesmal ein "R" für Ready schicken.
Alternativ legt man fest, dass der uC eine bestimmte Menge Daten pro 
Zeit auf jeden Fall vom PC empfangen und über NRF24 wegsenden kann.

Beim Empfänger würde der uC einfach alles auf den UART schreiben. Der PC 
muss es eben schnell genug aus dem Buffer holen. Das sollte bei diesen 
Transferraten passen. (Auch hier bestünde zusätzlich die Möglichkeit für 
Handshake, wenn es der uC könnte. Ich denke jedoch, dass es auch ohne 
geht)

USB->SPI->NRF24 sehe ich auch nicht.

von Lars R. (lrs)


Bewertung
lesenswert
nicht lesenswert
Anmerkung:

Die Idee, dass der uC dem PC jede Übertragung mir "R" bestätigt, wird 
wohl nix.

Aber selbst ohne hardware-Handshake-Funktionalität könnte der uC die 
entsprechende Handshake-Leitung des USB-Uart-Interfaces über einen IO 
schalten, wenn sein Buffer fast voll ist und er mit dem Wegsenden der 
Daten über das NRF24 nicht hinterher kommt.

von Lothar (Gast)


Bewertung
lesenswert
nicht lesenswert
NRFTestGuy schrieb:
> Lothar schrieb:
>> Ja.
>
> Mach ich aber nicht. Kannst du dir bei Nordic selbst abholen.

> NRFTestGuy = Arduinoquäler

War nicht anders zu erwarten.

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]
  • [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.