Ich möchte schon seit einiger Zeit mit der Programmierung einer kleinen Automatisierungssoftware/Hausautomation beginnen. Nun wäre natürlich ein entsprechend einfacher, verständlicher Einstieg recht gut - dazu würde ich gerne folgendes aufbauen: Über einen Raspberry würde ich gerne ein Signal an einen mikrocontroller (via Funk?!) senden, dieser soll daraufhin einen Verbraucher (LED) schalten. Der Raspberry ist zunächst einmal gesetzt, d. h. mir fehlt eine Übersicht ob das Ganze via Zigbee oder besser RFM69 mehr Sinn macht.. oder was ganz anders? Habe mal kurz in Richtung von ganz normalen Netzwerkschnittstellen (Ethernet) gedacht aber einerseits ist der Netzwerkstack viel aufwändiger und auch die Erweiterbarkeit des ganzen Systems ist recht beschränkt. Logischerweise soll das Ganze natürlich bezüglich der Komponenten halbwegs günstig zu haben und auch erweiterbar sein (da ich tendenziell mehr Empfänger/Aktoren möchte...) Bereits vorhandene Hardware: - Raspberry Pi - STM32F4 Discovery Am liebsten wäre mir natürlich erst einmal eine Lösung mit dem STM32F4, welche ich dann z. B. auch auf einen anderen (günstigeren?) Controller "umziehen" könnte. Mein Hardware-Wissen ist ziemlich beschränkt, bisschen Löten bring ich noch hin aber an sich hätte ich lieber eine "fertige" Hardware-Plattform. Bezüglich der Software bin ich recht zuversichtlich halbwegs zurechtzukommen (da ich beruflich Software Entwickler bin, nur nichts mit Embedded zu tun habe) - wenn ich die Basis denn an's laufen bekomme. Wenn möglich würde ich bei der Programmierung auf C++ setzen, auf dem Raspberry ist das ja kein Problem... Nun also die konkrete Frage: - Wie/mit was realisiere ich am besten eine derartige Verbindung zwischen Raspberry und irgendeinem Controller? - Welcher ARM-Controller bietet sich da an? Habe ich völlig falsche Vorstellungen wie das aufzubauen/zu machen ist? ZigBee scheint mir "mehr" zu sein/zu können... Vielen Dank schon mal. Hier mal das ZigBee Modul das ich mir mal angesehen hab: Waveshare ZigBee Module Core2530 (B) XBee compatible CC2530F256 2,4GHz (ca. 13,5 EUR) Alternativ aus China: New CC2530 ZigBee Wireless Module Uart PWM Output GPIO 8CH ADC Mini Size (ca. 8 Euro) -> taugt das was? Oder eben das RFM69: RFM69HCW 100mW Wireless Transceiver 433Mhz HopeRF RFM69HCW-433S2 RFM22B comp. (etwa 6 EUR) - Unterscheidet sich preislich also nicht arg vom China-ZigBee
Moin, eine alternative Lösung wäre der ESP8266. Dieser Controller hat unter anderem WLAN und ist sehr mächtig. Du könntest deine Commandos dann via WLAN vom RPi zum Controller senden. Dazu gibt es dann verschiedene Ansätze. Gruß
Schau mal in den Nachbar-Thread! Da gibts gute Tipps für deine Fragestellung. Beitrag "Wie Messwerte über Wlan auslesen?"
> an sich hätte ich lieber eine "fertige" Hardware-Plattform Wer nur ein "bisschen" Funken ueben will, kann auch eine Betty nehmen. Da gibt es ARM (LPC2220) + TI (CC1100). Besser sind natuerlich 2. JTAG dran stecken stecken und los gehts.
Betty schrieb: > Da gibt es ARM (LPC2220) das ist eine Zeitreise die ich nicht empfehlen würde. Dazu musst du alle paar Wochen ein paar neue Batterien einsetzen oder ständig Akkus laden. Das Ding ist nicht ohne Grund gefloppt. Meine Lösung hatte ich hier gezeigt: Beitrag "Re: Sensormodul mit Funk" Es gibt aber auch kaufbare, z.B. die Moteinos (allerdings noch mit ATMega): https://lowpowerlab.com/shop/product/99 oder als Clone: https://www.ebay.de/itm/Canique-MK2-Arduino-Moteino-kompatibles-Board-mit-RFM69W-RFM69HW-433MHz-868MHz/322825110229?hash=item4b29e042d5:m:mnphQr0rJyTVyJsRWd3uewg Können über die Arduino IDE programmiert werden, auf Github ist von LowPowerLab einiges an Beispielen zu finden. Die haben auch eine neue Version mit Cortex-M0, aber mit 30 US$ + Steuern und Versand vermutlich kein Schnäppchen.
Welcher ARM da Kommandos hin- und herschickt, ist doch fast egal. Das unterscheidet sich gerade mal im HAL-Layer. Und vom CC1100 gibt es ja auch noch sparsamere Versionen. > Dazu musst du alle paar Wochen ein paar neue Batterien einsetzen > oder ständig Akkus laden. Das ist doch bei dem Antuino-Gedoehns doch erst recht so. Zum Debuggen hat mein J-Link die internen 3.3 V herausgefuehrt um das Target zu versorgen. Da hab ich noch nie Batterien gebraucht. Und seine Sensorknoten werden final wohl auch nicht gerade aus Primaer- oder Sekundaerelementen, sondern von einem NT gespeist.
Betty schrieb: > Das ist doch bei dem Antuino-Gedoehns doch erst recht so. Ein ATMega328 oder Cortex-M0 braucht incl. RFM69 im sleep mode wenige µA, das ist schon ein Unterschied. Ein Batteriebetriebener Sensor kann da mehrere Jahre mit kleinen Batterien laufen, jeden Sensor an ein Stromkabel zu hängen halte nicht für sehr praktisch. Für den Empfang braucht man ein paar mA, aber da möchte man ja auch etwas schalten und hat dann Strom aus der Steckdose. Und wenn der Sensor eine Steckdose in der Nähe hat sind die ESP unschlagbar einfach, mit ESPEasy als Standardsoftware die nur noch konfiguriert werden muss und direkt ins WLAN funkt. Wobei der ESP auch einen sleep mode hat und man den auch bei wenig Senden auch lange mit Batterien/Akkus betreiben kann.
Wolfgang V. schrieb: > Der Raspberry ist zunächst einmal gesetzt, d. h. mir fehlt eine > Übersicht ob das Ganze via Zigbee oder besser RFM69 mehr Sinn macht.. > oder was ganz anders? Habe mal kurz in Richtung von ganz normalen > Netzwerkschnittstellen (Ethernet) gedacht aber einerseits ist der > Netzwerkstack viel aufwändiger und auch die Erweiterbarkeit des ganzen > Systems ist recht beschränkt. Ethernet und mangelnde Erweiterbarkeit? Wie bitte? Du hast wohl nie wirklich große LANs gesehen? Ethernet ist wesentlich mehr erweiterbar als jegliche Funklösung, einfach deshalb, weil Funk ein shared medium ist und die Kanalkapazität auf den frei benutzbaren Frequenzbändern endlich ist. Und wenn Du Dich über die Komplexität von IP über Ethernet beschwerst, dann hast Du noch nie einen Zigbee Stack in den Fingern gehabt. TCP/IP kannst Du in wenigen kB Code implementieren, aktuelle Zigbee-Stacks brauchen deutlich mehr als 64k für die Basisfunktionen. Also Punkt 1: Wenn es irgendwie geht, dann nimm Kabel und kein Funk. Und dann entweder Ethernet oder alternativ auch was selbstgebasteltes auf CAN oder RS485 Basis. Stromversorgung über 48V Gleichstrom und einem kleinen DC-DC-Wandler an jedem Endpunkt. 48V deswegen, weil so der Strom durch Deine Kabel minimal wird und Du damit minimale Spannungsverluste und maximale Leistungsübertragung hast. Auch ISDN, oder Power Over Ethernet arbeiten mit 48V - Du solltest also nicht glauben, schlauer als die Profis zu sein. Der Spruch lautet: Wer Funk kennt, nimmt Kabel. Und das hat Gründe. Solltest Du doch Funk einsetzen müssen, dann: 1. WLAN funktioniert nur, wenn der Strom aus der Steckdose kommt. Wenn Du batteriebetriebene Endgeräte brauchst, die mit einer Knopfzelle ein Jahr lang funktionieren, dann vergiss WLAN sofort. 2. Zigbee ist schonmal rein theoretisch eine gute Wahl, aber eigentlich zu komplex für Dich, um es richtig spezifikationskonform zu implementieren. 3. Zigbee setzt auf IEEE 802.15.4 auf. Daneben gibt es noch Thread und 6Lowpan, die auch auf dieses Basisformat aufsetzen. Diese beiden Netzwerkprotokolle benutzen IPv6. Wenn Dir IPv4 schon zu komplex ist, ist es IPv6 erst recht. Ansonsten wäre das meine Empfehlung. Es gibt z.B. kleine Funkmodule wie dieses hier, die einen kompletten Endpunkt abgeben: https://www.silabs.com/products/wireless/mesh-networking/mighty-gecko-modules/mgm13p-mighty-gecko-module Das ist nicht nur ein Funkmodul, sondern auch ein Prozessormodul. Dein Applikationscode wird auf dem Cortex M4 in dem Modul laufen. Dein Discovery Board ist überflüssig und eh nicht zu gebrauchen, weil es viel zu viel Strom zieht. Dieses Modul zieht im Ruhezustand 87µA, nur um da mal eine Hausnummer zu nennen. > Logischerweise soll das Ganze natürlich bezüglich der Komponenten > halbwegs günstig zu haben und auch erweiterbar sein (da ich tendenziell > mehr Empfänger/Aktoren möchte...) Das Modul gibts bei Mouser für ca 9€ in Einzelstückzahlen. Wenn Du gleich 500 Stück brauchst, wirds natürlich billiger. > Bereits vorhandene Hardware: irrelevant, sorry. > Wenn möglich würde ich bei der Programmierung auf C++ setzen, auf dem > Raspberry ist das ja kein Problem... Auf den ARMs auch nicht. Dehe aber davon aus, dass da noch recht viel klassisches C dabei sein wird. Und vermutlich wirst Du erst einmal lernen müssen, wie man stromsparend programmiert. Ja, genau DEIN Code kann einen erheblichen Einfluss auf die Batterielaufzeit haben. > Nun also die konkrete Frage: > - Wie/mit was realisiere ich am besten eine derartige Verbindung > zwischen Raspberry und irgendeinem Controller? SPI, UART. > Waveshare ZigBee Module Core2530 (B) XBee compatible CC2530F256 2,4GHz Der TI CC2530 ist eine Einheit aus einem 8051 8 Bit CPU-Kern, Flash, RAM, IO-Pins und einer Funkhardware. Auch da kannst Du Deinen eigenen Code drauf laufen lassen, aber Du brauchst zwingend(!) den sauteuren IAR EW8051 ab Version 9.1 oder 9.2 (Kostenpunkt: etwa 4-5 Kiloeuro). Dieser Chip (und sämliche Platinen, da darauf beruhen) lohnt sich nur, wenn Du größere Stückzahlen hast. Der Chip ist naämlich mit 1-2 Euro ziemlich günstig, und wenn Du die Chinesen eben mal 10000 Stück raushauen kannst, hast Du den teuren Compiler schon wieder amortisiert. BTDT Die Chinesen packen auf diese Module immer eine einfache Applikation, mit der man zwei dieser Module koppeln kann und dann eine serielle Verbindung hat. Das ist zwar ganz nett, nützt Dir aber nicht wirklich was. > Alternativ aus China: > New CC2530 ZigBee Wireless Module Uart PWM Output GPIO 8CH ADC Mini Size Gleicher Chip, gleiches Problem. Finger wech. > Oder eben das RFM69: > RFM69HCW 100mW Wireless Transceiver 433Mhz HopeRF RFM69HCW-433S2 RFM22B > comp. (etwa 6 EUR) - Unterscheidet sich preislich also nicht arg vom > China-ZigBee Das ist etwas proprietären, was sich an keinerlei Standards hält. Es ist nur ein nackter Empfänger und Sender, d.h. um solche Sachen wie Fehlerkorrektur und Fehlererkennung oder Transportsicherung (Paket angekommen?) musst Du Dich kümmern. Zu dem Preis für das Modul musst Du dann natürlich auch noch den Prozessor mit Leiterplatte etc rechnen. Und: Das RFM69 arbeitet nicht wie Zigbee, Thread, 6lowpan oder andere 802.15.4-basierte Verfahren im 2.4 GHz Band, sondern im 433 MHz Band. Das hat Vorteile und Nachteile. Vorteil ist, dass die geringere Frequenz eine geringere Dämpfung durch Wände, Luft (Feuchtigkeit!!!) und andere Materialien verursacht, so dass Du eine bei gleicher Sendeleistung größere Indoor-Reichweite hast. Aber: 433 MHz ist ziemlich unreguliert, so dass Dir da auch ein Babyfon, ein Funktheromometer oder sonst irgendetwas ziemlich den Tag versauen kann. Wenn Du in den Sub-GHz Bereich willst, nimm den 868 MHz Bereich. Das ist deutlich stärker reguliert, hier wirst Du mit wesentlich weniger Störungen zu rechnen haben. Eine der Auflagen, die Teil der Allgemeinzuteilung ist und an die Du Dich unter Strafandrohung zu halten hast, ist, dass jedes Deiner Geräte nur zu maximal 0.1% oder 1% (je nach Frequenzbereich) der Zeit senden darf. Das soll verhindern, dass irgend ein Idiot das Band vollmüllt. Das erstmal als Orientierungshilfe. fchk
Ich kenne einen Entwickler, der in seinem Shop ZigBee Module verkauft. Angeblich verdient er an den Modulen nichts, wohl aber den Kunden, die kurze zeit später zurück kommen und ihn beauftragen, die Software dazu zu entwickeln. Keine Ahnung, ob die Story wahr ist. Bei anderen Themen hatte ich bisher jedenfalls nicht das Gefühl, dass er Quatsch erzählt.
Wolfgang V. schrieb: > Oder eben das RFM69: > RFM69HCW 100mW Wireless Transceiver 433Mhz HopeRF RFM69HCW-433S2 RFM22B Da du wohl kein ham bist, darfst du auf 433Mhz nur mit 10mW senden. Auf 869,525 MHz sind es immerhin 500mW. Stromsparend und klein sind ICs wie TIs CC1310 (cortex M3+RF). Als Modul mit Quarz und U.FL nennt sich das dann z.B. E70-868T14S2 (5€).
Frank K. schrieb: >> Waveshare ZigBee Module Core2530 (B) XBee compatible CC2530F256 2,4GHz > > Der TI CC2530 ist eine Einheit aus einem 8051 8 Bit CPU-Kern, Flash, 8051? Der neue '8051' nennt sich ARM Cortex M0+. Der alte 8051 ist für Neuentwicklungen nicht mehr zu empfehlen!
funkie schrieb: >> Der TI CC2530 ist eine Einheit aus einem 8051 8 Bit CPU-Kern, Flash, > > 8051? > Der neue '8051' nennt sich ARM Cortex M0+. Der 8051 hat einen riesengroßen Vorteil: Jedermann darf ihn lizenzkostenfrei implementieren. Beim Cortex will ARM Geld sehen, und zwar nicht wenig. Aus diesem Grund haben viele SOCs, bei denen die Binärkompatibilität egal ist, keine ARM-Cores, sondern welche von MIPS - weil die weniger Geld haben wollen. Beispielsweise die DSL-Chipsätze in den Fritzboxen: MIPS eben. Und jetzt rate mal, was der größte Hauptfeind von ARM ist? Nicht MIPS. Nee, nee. https://www.theregister.co.uk/2018/07/10/arm_riscv_website/ Zigbee auf 8051 ist keine Schönheit, funktioniert aber hinreichend, und das Zeugs ist billig. Wer Stückzahlen machen will, den interessiert genau das. Die meisten USB-Hubs (auch die mit 3.0) enthalten einen 8051. Reicht aus, belegt wenig Chipfläche und ist billig. Passt. > Der alte 8051 ist für Neuentwicklungen nicht mehr zu empfehlen! So undifferenziert ist das eben falsch. Klar, die paar Bastler sollten woanders spielen gehen. Die sollten aber auch meiner Meinung nach kein Zigbee anfassen. Da gibt es sinnvollere Alternativen, wo in den (kostenflichtigen!) Standard nicht mit Absicht Sicherheitslücken und statische Generalschlüssel für alle Devices hineingeschrieben wurden. fchk PS: Die 100mW beim RFM69 habe ich glatt übersehen. Danke für den Hinweis.
:
Bearbeitet durch User
Vielen Dank zunächst für die vielen, ziemlich fundierten Antworten... jetzt hab ich zwar mehr Information als zuvor aber irgendwie weiß ich immer noch nicht genau was es nun werden soll. Habe den Eindruck dass ihr teilweise in ganz anderen Dimensionen denkt als ich es für mein Hobby-/Bastelprojekt benötige. Und auch dass meine Aussagen etwas missverstanden worden sind... von daher nochmal kurz zur besseren Spezifizierung: Mit schlechter "Erweiterbarkeit" bein Ethernet hatte ich mich darauf bezogen, dass es mir schlichtweg nicht möglich ist überall dort, wo ein Controller vielleicht mal sinnvoll wäre ein Netzwerkkabel hinzuziehen. Mit "mehrere" Devices spreche ich von einer Größenordnung von vielleicht mal 30 bis 60 Stück.... nicht von 1000 und mehr. Auch bezüglich der Reichweite muss das "nur" innerhalb des Hauses bzw. eines Stockwerks funktionieren da ich bei WLan dann eben entsprechende Hotspots einrichten würde. Auch muss das Gerät nicht ein Jahr lang mit einer Knopfzelle zurechtkommen, 48V mit DC-DC Wandler hört sich recht vernünftig an - da könnte ich dann wohl auch mit wenigen Hauptpunkten alles versorgen ohne überall neue Leitungen zu ziehen. Und ja, ich hatte auf der Ebene bislang weder einen Zigbee Stack, noch einen TCP/IP Stack in der Hand da ich hier einfach nicht unterwegs bin. Das was ich mir vorstelle wäre halt ein "fertiges" Modul, welches ich per UART oder SPI ansteuern kann um recht simpel einen Datensatz zuzustellen. Mit verlorenen/beschädigten Packeten kann ich dann wohl auf einer höheren Ebene umzugehen - Insofern das nicht TCP übernehmen würde. Nachdem, was ich bislang gelesen habe würde meine Wahl auf WLAN fallen - oder hab ich mich da in die falsche Richtung "gelenkt" gefühlt? Gibt es dann bezüglich Verschlüsselung (WPA2 oder was auch immer) irgendwas besonders zu berücksichtigen? Um ganz ehrlich zu sein hätte ich mir Funk tatsächlich nicht so kompliziert vorgesellt - dachte lan/wlan wäre da "schlimmer".
https://www.amazon.de/AZDelivery-NodeMCU-ESP8266-ESP-12E-Development/dp/B06Y1LZLLY/ref=pd_lpo_vtph_107_bs_t_1?_encoding=UTF8&psc=1&refRID=349D8BEPZYM2JTTCNCAY ( AZDelivery NodeMCU Lua Amica Module V2 ESP8266 ESP-12E Wifi Wifi Development Board mit CP2102 ) oder https://www.amazon.de/NodeMCU-Internet-Development-ESP8266-ESP-12E/dp/B01GCK3J40/ref=pd_sim_107_3?_encoding=UTF8&pd_rd_i=B01GCK3J40&pd_rd_r=b62436b3-9a5e-11e8-81ab-010f3875a609&pd_rd_w=uj0Ly&pd_rd_wg=drm0j&pf_rd_i=desktop-dp-sims&pf_rd_m=A3JWKAKR8XB7XF&pf_rd_p=5296994838746851949&pf_rd_r=349D8BEPZYM2JTTCNCAY&pf_rd_s=desktop-dp-sims&pf_rd_t=40701&psc=1&refRID=349D8BEPZYM2JTTCNCAY ( tinxi® NodeMCU Lua WIFI Internet Development Board Based on ESP8266 ESP-12E CP2102 ) Würde das dann meinen Anforderungen genügen oder brauche ich da dann noch was anders um das ans laufen zu bekommen? Komme mir da gerade ziemlich dämlich vor :-(
:
Bearbeitet durch User
> Nachdem, was ich bislang gelesen habe würde meine Wahl auf WLAN fallen - > oder hab ich mich da in die falsche Richtung "gelenkt" gefühlt? > Würde das dann meinen Anforderungen genügen oder brauche > ich da dann noch was anders Tja wenn man denn wüsste, wie deine Anforderungen lauten... Viel mehr als "ich will irgendetwas mit Funk machen" kam dabei ja nicht heraus. So kann Dir niemand sagen, ob WLAN für dich eine Gute Wahl sein wird. Zweifellos kann es funktionieren, also ist es einen Versuch Wert. Diese ESP Module kannst du zum Ausprobieren direkt an einen PC anschließen, oder als Netzwerk-Interface an einen µC anschließen oder selbst programmieren, so dass sie Kern deiner verteilten Stationen werden. > Gibt es dann bezüglich Verschlüsselung (WPA2 oder was auch immer) > irgendwas besonders zu berücksichtigen? Die ESP Module unterstützen verschlüsselte Verbindungen mit WPA2. Sie bauen eine Verbindung zum AP (Fritzbox oder so) automatisch auf, wenn SSID und Passwort richtig konfiguriert sind. Lies diese Infos, danach hast du einen Plan, wie es weiter gehen kann: http://stefanfrings.de/esp8266/index.html
Naja, habe mich bemüht die Anforderung rüber zu bringen. Vielen Dank für den Link, das auf der Seite liest sich schon recht gut verständlich. Also wirds für wohl das NodeMCU Board werden und dann sehe ich schon weiter.
Wolfgang V. schrieb: > Mit schlechter "Erweiterbarkeit" bein Ethernet hatte ich mich darauf > bezogen, dass es mir schlichtweg nicht möglich ist überall dort, wo ein > Controller vielleicht mal sinnvoll wäre ein Netzwerkkabel hinzuziehen. So, Du kannst also kein Netzwerkkabel hinlegen, aber ein Stromkabel wäre kein Problem? > Mit "mehrere" Devices spreche ich von einer Größenordnung von vielleicht > mal 30 bis 60 Stück.... nicht von 1000 und mehr. 60 Geräte sind für IEEE 802.15.4 kein Problem, für etliche Billig-WLAN-Router schon. Wenn es tatsächlich 60 Endpunkte werden sollen, dann streiche WLAN. Mehr als 30 Knoten solltest Du mit WLAN und dem üblichen Consumer-Zeugs nicht einplanen. Bei WLAN Enterprise-Lösungen sind auch 1000 Geräte kein Problem - aber diese Infrastruktur wirst Du weder bezahlen noch administrieren können. > Auch bezüglich der Reichweite muss das "nur" innerhalb des Hauses bzw. > eines Stockwerks funktionieren da ich bei WLan dann eben entsprechende > Hotspots einrichten würde. Denke dran: Du hast und willst nur Consumer-Zeugs. Da hast Du überhaupt nur drei überlappungsfreie Bänder im 2.4GHz Bereich. Klar, 5GHz WLAN gibts auch seit langem. Nur halt nicht im Billig-Zeugs vom Chinamann. > Auch muss das Gerät nicht ein Jahr lang mit einer Knopfzelle > zurechtkommen, 48V mit DC-DC Wandler hört sich recht vernünftig an - da > könnte ich dann wohl auch mit wenigen Hauptpunkten alles versorgen ohne > überall neue Leitungen zu ziehen. Aber auch die 48V gehen nicht drahtlos durch die Luft, sondern erfordern Kabel. Und wenn da eh schon ein Kabel lang geht, dann kannst Du auf das zweite Adernpaar Deines Sternvierers auch einen CAN- oder RS485-Bus drauflegen. Das würde Dir viele Probleme ersparen, von Denen Du bislang noch gar nichts weißt. Nochmals: Wer Funk kennt, nimmt Kabel. Merke Dir Dir das! > Nachdem, was ich bislang gelesen habe würde meine Wahl auf WLAN fallen - > oder hab ich mich da in die falsche Richtung "gelenkt" gefühlt? Nochmal meine ganz dringende Empfehlung: Wenn es nicht zwingend drahtlos sein muss, mache es drahtgebunden. Ethernet mit POE, CAN oder RS485 sind hier die gängigen Alternativen. Ethernet ist das schnellste, aber auch das teuerste und Aufwändigste. CAN ist von der Ansteuerung am Einfachsten, weil die Hardware sehr viel automatisch macht, was Du bei RS485 selber programmieren müsstest. Bei drahtgebundener Kommunikation hast Du keine Probleme mit beschränkten Frequenzresourcen, brauchst Dich um Verschlüsselung nicht zu kümmern (wer abhören will, muss sich ans Kabel klemmen), hast bei CAN und RS485 keine komplexen Softwarestacks, wenn Du es nicht willst, etc. WLAN ist nichts halbes und nichts ganzes. Ein WLAN-Gerät braucht für den Dauerbetrieb trotzdem Kabel, nämlich für Strom, und dann kannst Du auch Ethernet oder einen CAN-Bus hinlegen. Und vor den wirklich stromsparenden Dingen wie 802.15.4, die dann wirklich komplett drahtlos (auch für Strom!) sind, scheinst Du Angst zu haben und nicht die erforderlichen Vorkenntnisse. > Um ganz ehrlich zu sein hätte ich mir Funk tatsächlich nicht so > kompliziert vorgesellt - dachte lan/wlan wäre da "schlimmer". Das ist eine krasse Fehleinschätzung. Elektrodynamische Feldtheorie ist quasi eine der "Höhepunkte" in einem E-Technik-Uni-Studium. Zu meiner Studienzeit waren die Hochfrequenztechniker die einzigen, die einen Cray Supercomputer in ihrem Institut hatten, einfach weil die Lösung von Feldverteilungen unter realen Bedingungen so schwierig und rechenaufwändig ist. Wobei das heutzutage ein normaler Xeon auch schafft - aber eben nicht vor 30 Jahren. PS: Es gibts ja noch eine ganz andere Möglichkeit: Powerline. Datenübertragung über die Stromleitung. Damit z.B: https://www.sparkfun.com/products/retired/10918 Aber ich möchte nicht für Dein Ableben verantwortlich sein. PPS: Komm jetzt bloß nicht auf die Idee, Dir das Powerline-Board zu besorgen. Das gibts eh nicht mehr, außerdem ist USA 2*115V-Land, d.h. für unsere Stromnetze und die damit einhergehenden Regularien wäre das Board eh neu zu designen.
:
Bearbeitet durch User
> ein normaler Xeon reicht fuer Ansys Maxwell 3D auch nicht. > PPS: Komm jetzt bloß nicht auf die Idee, Dir das Powerline-Board zu > besorgen. Er koennte ja X10 machen. Ist halt ein wenig langsam...
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.