Forum: Mikrocontroller und Digitale Elektronik Tipp für Protokoll für 12 Sensoren im Abstand von 10-40 Meter (Seriell?)


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 Frank (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Hallo Forumsgemeinde,

ich bräuchte mal einen Tipp von euch, wie ihr folgendes lösen würdet 
(unten meine Überlegungen)

Ich plane den Garten ein bisschen zu "digitalisieren" - also 
Bodenfeuchtesensoren, Temperatursensoren, Regenmesser etc.

In Summe werden es 12 Sensoren sein, die vom "zentralen Punkt" ca. je 
10-40 Meter weg sind (Kabellänge). Sensoren liefern fast alle ein 
Spannungssignal.

Wie würdet ihr die Sensordaten aufbereiten, um Sie dann relativ 
störungssicher, mit ca. 1Hz auslesen/übertragen zu können?


Meine Idee:
a) Jeden Sensor mit Chip (kleinen Atmel etc.) ausstatten, dass er 
seriell senden kann - der zentrale uC hat einen MUX und ließt dann ab 
und zu mit (1Hz)
=> habe noch keinen MUX gefunden ... zur Not müsste ich den selbst bauen 
(Tipp?)

b) SPI nutzen und verstärken

c) Sensor in Frequenzsignal umsetzten und dann am uC die Frequenzen 
messen


Habt ihr bessere Ideen ?

von Kevin M. (arduinolover)


Bewertung
1 lesenswert
nicht lesenswert
Frank schrieb:
> SPI nutzen und verstärken

SPI ist wie I2C ein Bus für AUF der Leiterplatte.

Frank schrieb:
> Sensor in Frequenzsignal umsetzten und dann am uC die Frequenzen
> messen

Habe ich auch schon gemacht war ganz ok, würde ich aber nicht nochmal 
machen.

Ich würde etwas wie CAN vorschlagen, das ist auch beinahe beliebig 
skalierbar.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:
> Habt ihr bessere Ideen ?

Seriell ist schon ok, nicht aber RS232C, das hat ausser dem Nachteil, 
dass man multiplexen muss die Beschränkung auf offiziell 15 m - ich 
würde einen Bus wie z.B. RS485 verlegen. Dann kann man von Sensor zu 
Sensor verlegen und braucht nur 1 Anschluss an der Zentrale.

Georg

von dummschwaetzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
funk?

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
Die grundlegende Frage: wie willst du verdrahten? Wenn eh jeder Sensor 
seine eigene Leitung bekommt, kannst du auch das Spannungssignal 
verwenden, 12 Spannungseingänge sind kein Problem.

Wenn dir aber eher eine lineare Verdrahtung von Sensor zu Sendsor 
vorschwebt dann RS485. CAN bringt hier keine Vorteile (reiner 
master/slave möglich).

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:

> Meine Idee:
> a) Jeden Sensor mit Chip (kleinen Atmel etc.) ausstatten, dass er
> seriell senden kann - der zentrale uC hat einen MUX und ließt dann ab
> und zu mit (1Hz)
> => habe noch keinen MUX gefunden ... zur Not müsste ich den selbst bauen
> (Tipp?)

Dann nimm doch Halbduplex-RS485-Transceiver (z.B. MAX3483) an jedem 
Kabel-Ende. Jeder Transceiver hat ein DE (Driver Enable) und ein /RE 
(Receiver Enable) Signal, und damit und beispielsweise einem 74HC138 
(für die /RE) bzw 74HC238 (für die DE) kannst Du dann den einzelnen 
Sensor selektieren. Und RS-485 geht einige 100m weit. Abschluss- und 
Failsafe-Widerstände nicht vergessen!

fchk

von Uwe Bonnes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn der Stromverbrauch der CAN Tranceiver nicht stoert, ist CAN auch 
eine gute Wahl.

von 100Ω W. (tr0ll) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Was spricht gegen RS485 und Modbus?

von Sebastian S. (amateur)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde einen Kleinst-µP, für jeden Teilnehmer, verwenden und dann 
einen offenen Ring mittels RS485 - notfalls RS232 - aufbauen. Bei so 
geringer Belastung kannst Du die Daten jeweils "Durchleiten". D.h. der 
jeweilige µP empfängt die Daten und leitet sie, gefolgt von dem eigenen 
Datenpaket weiter. Hat der µP keine zweite serielle Schnittstelle, so 
reicht auch eine, durch Software emulierte, Schnittstelle aus.
Der letzte Mohikaner bekommt dann alle Daten, hübsch der Reihe nach und 
hat somit auch keine Probleme mit irgendwelchen Kollisionen und 
ähnlichem Schweinkram.
Die Reihenfolge richtet sich nach der physikalischen Reihenfolge, oder 
jeder Teilnehmer packt eine/seine Adresse dazu.

: Bearbeitet durch User
von Harald (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also ich würde CAN den Vorzug geben, da jeder Knoten beliebig ohne große 
Absprache senden und empfangen kann. Bei RS485 muss man sich ja immer 
ein wenig Gedanken um die Koordinierung machen.
Immer wieder gerne genommen für solche kleinen Sensorknoten: LPC11C24, 
im Grunde den STM32 sehr ähnlich. Als Besonderheit hat der den 
CAN-Transceiver gleich mit eingebaut.
Oder den STM32F042 im SSOP20, dazu ein MAX3051 als CAN-Transceiver, der 
ist schön klein (SOT23-8) und sparsam.

von 100Ω W. (tr0ll) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Harald schrieb:
> Bei RS485 muss man sich ja immer
> ein wenig Gedanken um die Koordinierung machen.

Es gibt das schon eine fertige Lösung, die sich um die Koordinierung 
kümmert: Modbus.

von Kevin M. (arduinolover)


Bewertung
0 lesenswert
nicht lesenswert
Uwe Bonnes schrieb:
> Wenn der Stromverbrauch der CAN Tranceiver nicht stoert, ist CAN auch
> eine gute Wahl.

Harald schrieb:
> MAX3051 als CAN-Transceiver, der
> ist schön klein (SOT23-8) und sparsam.

Dafür gibt es vielen CAN Transivern mit sleep Pin, um in einen low power 
Modus zu gehen.

Microchip hat auch einige die sehr günstig sind unter anderem auch im 
QFN Package, falls interessant.

von Harald (Gast)


Bewertung
0 lesenswert
nicht lesenswert
100Ω W. schrieb:
> Es gibt das schon eine fertige Lösung, die sich um die Koordinierung
> kümmert: Modbus.

Ja, habe ich auch schon mit gearbeitet. Muss man halt alles nur in SW 
ausführen, aber funktionieren wird das, keine Frage!

War auch nur als meine persönliche Meinung zum Thema gedacht, ohne dabei 
andere Vorschläge schlecht machen zu wollen.
Was der OP daraus macht ist mir eigentlich egal.

von N. M. (mani)


Bewertung
0 lesenswert
nicht lesenswert
Harald schrieb:
> LPC11C24

Ja hätte ich vermutlich auch genommen. CAN ist doch ziemlich einfach. 
Und Single Chip kann auch seinen Charme haben.

RS485 würde auch gehen. Würde ich mir wahrscheinlich einen Controller 
suchen der den Multiprocessor Mode unterstützt. Dann kann man relativ 
leicht adressieren und der Controller kann zu 99.9% im Sleep verbringen. 
Muss man sich halt etwas Gedanken zu Protokoll und Sicherung (z.B CRC) 
machen. Kollisionen könnte man bei so langsamen Daten so gut wie 
ausschließen.
Das nimmt einem CAN halt größtenteils ab.

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
Ich würde mir ja ein 8-Pinner AVR mit internem CAN-Transceiver wünschen.
Aber bis dahin könnte man das hier probieren:

Beitrag "mehrere MC seriell über Datenbus verbinden (1Draht)"

von Harald (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bei nicht differentiellen Übertragungen (RS232, 1-Draht) kann man auf 
den Strecken schnell ein Problem durch die unterschiedlichen 
Massepotentiale bekommen. Von daher würde ich etwas Differentielles 
vorziehen. Zusätzlich dann noch die Störsicherheit.

Peter D. schrieb:
> Ich würde mir ja ein 8-Pinner AVR mit internem CAN-Transceiver wünschen.
Das wäre mal gut, dann muss der Quarz aber gleich mit drin sein. Ich 
habe mir auch schon mehrere Male Gedanken um einen besonders kleinen 
CAN-Knoten gemacht, der auf dem Tisch mit Hausmitteln noch bequem zu 
bauen ist (jaja, ich weiß, dass das hier nicht gefordert wurde):

LPC11C24 oder STM32F042 mit MAX3051, dazu ein Quarz im 2016 Package. Als 
Netzteil den MAXM15064 (MAXM, nicht MAX), der macht 5V/300mA aus bis zu 
65V(!) in einem unglaublich kleinen Package. Funktioniert sehr gut!

von Max H. (nilsp)


Bewertung
1 lesenswert
nicht lesenswert
100Ω W. schrieb:
> Was spricht gegen RS485 und Modbus?

Das wäre auch mein Vorschlag.

von Kevin M. (arduinolover)


Bewertung
0 lesenswert
nicht lesenswert
Harald schrieb:
> Ich habe mir auch schon mehrere Male Gedanken um einen besonders kleinen
> CAN-Knoten gemacht, der auf dem Tisch mit Hausmitteln noch bequem zu
> bauen ist

Was sollte der denn deiner Meinung nach so können? Ich überlege auch 
schon lange sowas zu bauen, als Auflötplatine ähnlich einem ESP, nur bin 
ich immer unschlüssig was an sonstiger Perepherie so Sinn macht. Ein 
paar Analogeingänge, SPI, I2C, etc.

von Flo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was auch ginge wäre ein LIN Bus.
Als Slaves dann jeweils nur einen UJA1023 verwenden, dann musst du die 
Slaves nicht mal seprat programmieren sondern nur vom Master 
konfigurieren.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kevin M. schrieb:
> als Auflötplatine ähnlich einem ESP, nur bin ich immer unschlüssig was
> an sonstiger Perepherie so Sinn macht. Ein paar Analogeingänge, SPI,
> I2C, etc.

Vor allem ist ein ESP nicht nur ein WLAN Knoten sondern der uC darin 
PROGRAMMIERBAR. Das macht den Reiz aus. Ob dann 1 Analogeingang oder 4 
ist eher egal, klug wäre es sowieso den CAN auf mehreren 
unterschiedlichen Prozessoren einer Familie (eben allen mit on board 
CAN) laufen lassen zu können.

von Kevin M. (arduinolover)


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Vor allem ist ein ESP nicht nur ein WLAN Knoten sondern der uC darin
> PROGRAMMIERBAR.

Klugscheißer, darum geht es doch.... Einen mini CAN Knoten auf Basis 
eines programmierbaren uC mit einem Transüber und Versorgung, der noch 
andere Schnittstellen bereitstellt. So kann man ihn standalone benutzen 
oder in einem größeren Projekt bei dem man noch etwas Analogaufbereitung 
o.ä. braucht. Oder eben um einen Sensor auszulesen.....

von Flo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der UJA1023 macht genau das für LIN. Eine single-Chip-Lösung mit 
parametrierbarer Peripherie, LIN Transcheiver und Spannungsregler.

von Harald (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kevin M. schrieb:
> Was sollte der denn deiner Meinung nach so können?

Einfach nur der uC mit allen sinnvollen Pins rausgeführt. Nur dass, was 
man immer braucht (Quarz, Reset, Power, Transceiver) auf einem eigenen 
Board.

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.

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