Guten Abend Community Da dies mein erster Beitrag hier ist, hoffe ich, dass ich hier im richtigen Unterforum bin. Nun ein mal zum konkreten Projekt: Ich möchte mir eine Art Hue selbst bauen, hierfür möchte ich mir LED Module selbst bauen, die über einen BUS angesprochen werden und entsprechend LEDs dimmen. Hier bei stoße ich jedoch auf ein paar Probleme und Fragen, die ich aufgrund mangelnder Erfahrung nicht so leicht beheben oder beantworten kann. Da ich mich mit der PWM Steuerung nicht so auskenne, würde ich die LEDs via µCU + DAC + Mosfet dimmen, doch stelle ich mir hier die Frage, ob eine PWM Dimmung nicht effizienter einfacher günstiger ist. Mein Hauptproblem stellt jedoch derzeit die Suche nach einem geeignten BUS dar. Bis auf I2C habe ich noch nicht wirklich mit BUS Systemen gearbeitet, doch I2C reicht hier bei weitem nicht aus. Als Anforderungen an den BUS habe ich folgende: Leitungslänge bis ca. 25 Meter (ggf. eine Aufteilung direkt am Master) Slavezahl bis zu 250, in ersten Tests jedoch 11. Nutzdaten gibt es 10 Byte pro Slave und Befehl. Da ich gerne bis zu 20 Hz bei der Ansteuerung erreichen würde, kommen bei angenommenen 250 Slaves bis zu 50kByte/s an Nutzdaten zusammen. Als letztes würde ich gerne die Möglichkeit haben, Slaves Hotplug fähig einzubinden und via Knopfdruck am entsprechenden Slave, diesem eine im BUS einzigartige Adresse zu zuweisen. Gibt es diese letzte Möglichkeit überhaupt? Schließlich muss der Master ja auf einen noch nicht registrierten Slave reagieren und diesem dann seine neue gültige Adresse übermitteln. Meine letzte Frage zum BUS ist dann noch, ob ein Slave auch auf mehrere Adressen hören kann, um mehrere Slaves zu gruppieren und somit die Datenlast auf dem BUS zu reduzieren. Die Programmierung an sich traue ich mir zu, doch fehlen mir Kenntnisse über mögliche zu verwendende Komponenten, die das ganze erschweren. Ich hoffe, dass ihr mir helfen könnt und bedanke mich schon mal im Voraus. Mit freundlichen Grüßen Marcel
Moin, Ethernet, DHCP, Multicast? Gruss
:
Bearbeitet durch User
Das mit dem Hotplug ist erstmal größtenteils eine Frage des Protokolls das man auf dem Bus fahren will... Selbst mit SPI sollte sich das alles realisieren lassen wenn man das Übertragungsprotokoll intelligent genug gestaltet und die Registrierung der Slaves über die applikation macht.
@ The Supercomputer (the_s616) >Ich möchte mir eine Art Hue selbst bauen, Ein was? >hierfür möchte ich mir LED Module selbst bauen, >die über einen BUS angesprochen werden und entsprechend LEDs dimmen. DMX512 >Da ich mich mit der PWM Steuerung nicht so auskenne, Das kann man ändern. PWM ist kein Hexenwerk. >würde ich die LEDs via µCU + DAC + Mosfet dimmen, Machbar, aber eher unüblich. >doch stelle ich mir hier die Frage, ob eine PWM Dimmung nicht >effizienter einfacher günstiger ist. Wahrscheinlich. >Leitungslänge bis ca. 25 Meter (ggf. eine Aufteilung direkt am Master) >Slavezahl bis zu 250, in ersten Tests jedoch 11. DM512. >Nutzdaten gibt es 10 Byte pro Slave und Befehl. Das geht damit nicht, DMX512 hat bis zu 512 Kanäle a 8 Bit. >Da ich gerne bis zu 20 Hz bei der Ansteuerung erreichen würde, >kommen bei angenommenen 250 Slaves bis zu 50kByte/s an Nutzdaten >zusammen. Ggf. Artnet, das ist eine Ethernetvariante davon. Vorteil. Es gibt auch massenhaft Software dafür. >Schließlich muss der Master ja auf einen noch nicht registrierten Slave >reagieren >und diesem dann seine neue gültige Adresse übermitteln. Nicht zwingend. >Meine letzte Frage zum BUS ist dann noch, ob ein Slave auch auf mehrere >Adressen hören kann, >um mehrere Slaves zu gruppieren und somit die Datenlast auf dem BUS zu >reduzieren. Du machst es für den Anfang zu kompliziert.
The S. schrieb: > Ich möchte mir eine Art Hue selbst bauen, > hierfür möchte ich mir LED Module selbst bauen, > die über einen BUS angesprochen werden und entsprechend LEDs dimmen. Was für LEDs hast du dir dafür vorgestellt. Die WS2812 mit integrierten Controller für ihren seriellen Bus wurden doch schon erfunden.
Der CAN-Bus dürfte für dich auch gut passen. Es gibt genügend Controller mit CAn und dir wird dort auch einiges schon abgenommen.
Als Daisy-Chain : RS485. Alles kein Problem. Auch 50Hz sind kein Problem. An jedem Knoten einen AVR der die Umsetzung nach PWM macht. Sinnvollerweise schleift man den pwm clock durch, fuer synchronen PWM, sonst gibt es interferenz effekte.
:
Bearbeitet durch User
idealer Anwendugsfall für one-wire-bus.
Falk B. schrieb: >> Nutzdaten gibt es 10 Byte pro Slave und Befehl. > > Das geht damit nicht, DMX512 hat bis zu 512 Kanäle a 8 Bit. Kann man denn nicht jedem Gerät zwei Slave-Adressen geben und dann damit 256 Kanäle à 16 Bit machen?
@Christopher Johnson (christopher_j23) >> Nutzdaten gibt es 10 Byte pro Slave und Befehl. > > Das geht damit nicht, DMX512 hat bis zu 512 Kanäle a 8 Bit. >Kann man denn nicht jedem Gerät zwei Slave-Adressen geben und dann damit >256 Kanäle à 16 Bit machen? Bei DMX512 wird den Empfängern eine Basisadresse zugewiesen und sie nutzen dann soviele Kanäle wie nötig. Z.B. Basisadresse 123 mit 5 Kanälen nutzt dann Kanal 123-127.
@grundschüler (Gast)
>idealer Anwendugsfall für one-wire-bus.
Ist heute Ironie-Tag?
Zwölf M. schrieb: > Als Daisy-Chain : RS485. Alles kein Problem. Auch 50Hz sind kein > Problem. An jedem Knoten einen AVR der die Umsetzung nach PWM macht. > Sinnvollerweise schleift man den pwm clock durch, fuer synchronen PWM, > sonst gibt es interferenz effekte. Naja, so einfach ist es mit dem RS485 nun auch wieder nicht. Wenn die Transceiver den Bus mit 1 Unit Load belasten, ist nach 32 Clients Schluss. Es gibt auch noch Transceiver, die mit nur 1/8 Unit Load arbeiten, und damit theoretisch 256 Geräte erlauben. Und bei so vielen Geräten am Bus sind die Pull-Widerstände an den Datenleitungen sehr genau zu wählen, damit die 250 Clients erreicht werden können.
SPI und I2C sind vom Ursprung her Busse die für die Verbindung von IC's auf der Leiterplatte gedacht sind. Ein Kommunikationsprotokoll muss man sich selbst überlegen. Die Namen SPI und I2C stehen nur für die Hardware. Der Name RS485 steht eigentlich nur für den verwendeten Transceiver, den man an den UART des uC anschliesst. Also auch hier muss man sich selbst ein Kommunikationsprotokoll überlegen und implementieren. Bei einem Buss darf man dabei das Thema Busarbitrierung, also das Management wann wer lesend oder schreibend auf den bus zugreifen darf, nicht vergessen. CAN Bus bezeichnet nun sowohl die Hardware als auch das Kommunikationsprotokoll. Das Kommunikationsprotokoll ist im CAN Controller realisiert, der Teil des Mikrocontrollers sein kann, und somit recht preiswert ist. Als BUS-Treiber schliesst man an diesen CAN-Controller noch einen CAN-Transceiver an. Befindet sich der Teilnehmer am Ende des Busses muss dieser mit Abschlusswiderständen versehen werden, um Reflektionen auf den Bus zu vermeiden. Das im Controller vorhandene Kommunikationsprotokoll regelt auch die Busarbitrierung, und gibt das Format der Messages vor. Ein Gruppierung könnte man elegant durch eine Anpassung des Master/Slave Predefined Connection Set erreichen. Da muss man den CAN-Bus aber gut kennen und verstehen. Einfacher ist es sicher Du würdest Broadcast Messages senden, die erstmal jeder Slave empfangen kann. In der Message schickst du neben den anderen Daten eine Gruppenkennung mit. Der jeweilige Slave überprüft diese Kennung, ist es seine Gruppenkennung, verarbeitet er die Message. Ist sie es nicht, verwirft der Slave die Message. Grundsätzlich denke ich, ist es eine gute Idee, wenn man Dinge so benutzt wie es ursprünglich gedacht war. Jedenfalls wenn Du auf möglichst wenige Probleme stossen möchtest. RS485 oder CAN sind sicher möglich. Aufgrund des fehlenden Kommunikationsprotokoll habe ich aber RS485-Busse in der Praxis bis jetzt noch nicht gesehen. Um die Implementierung des Kommunikationsprotokolleinfach zu halten kenne ich RS485, nur als Direktverbindung zweier Teilnehmer. Ok, in diesem Fall müsste es RS422 heissen. Denn RS422 steht für Direktverbindungen, und RS485 für Bus-Verbindungen. Elektrisch sollten aber beide identisch sein. Zusammengefasst wäre also CAN meine Wahl für diese Aufgabe.
In form des UART gibt es natürlich auch bei RS485 ein einfaches Kommunikationsprotokoll. Aber die Bus-Arbitirierung fehlt.
Nur noch als Tip zur weiteren Information. Controller, Transceiver, Protokolle was sich dahinter "verbirgt" ist das sogenannte OSI-Schichtenmodell. ;-)
Stefan schrieb: > Der CAN-Bus dürfte für dich auch gut passen. Es gibt genügend Controller > mit CAn und dir wird dort auch einiges schon abgenommen. Gibt es für den CAN günstige Karten für den PC? Karten die ich gefunden habe liegen bei 500 bis 700 Euro.
@ Lutz H. (luhe) >Gibt es für den CAN günstige Karten für den PC? Karten die ich gefunden >habe liegen bei 500 bis 700 Euro. Es gibt CAN-USB Umsetzer für ~100 Euro. http://www.can232.com/
Decius schrieb: > Als BUS-Treiber schliesst man an diesen > CAN-Controller noch einen CAN-Transceiver an. Gibbet aber auch onchip: LPC11C12FBD48/301
Falk B. schrieb: > Es gibt CAN-USB Umsetzer für ~100 Euro. > > http://www.can232.com/ Der konvertiert ja erst auf RS232, ob damit die maximale CAN-Buslast erreichbar ist? Bei diesem Projekt wird man da vermutlich in die Nähe kommen. Gibt es eigentlich kein vernünftiges DIY/OpenSource CAN-USB-Adapter Projekt welches USB direkt umsetzt und auch volle Buslast abkann? Kann doch eigentlich nicht so schwierig sein...
Dr. Sommer schrieb: > Gibt es eigentlich kein vernünftiges DIY/OpenSource > CAN-USB-Adapter Projekt... Wollte ich auch schon mal machen. Hatte dann aber etwas zu wenig Zeit mich in eine neue Controllerfamielie einzuarbeiten, die USB und CAN integriert hat. Von den PIC18, mit denen ich mich im Allgemeinen beschäftige bietet das leider keiner. Lösungen mit zwei Controllern (USB-RS232-CAN, USB-RS232-BT) waren mir dann zu umständlich, bzw. hatte ich schon (BT). DIY USB Lösungen mit zwei Controllern gibt es auch. z.B. http://www.fischl.de/usbtin/
@Dr. Sommer (Gast) >> http://www.can232.com/ >Der konvertiert ja erst auf RS232, Nein, die USB-VErsion arbeitet mit einem virtuellen UART. >ob damit die maximale CAN-Buslast >erreichbar ist? Nicht ganz. Für die meisten Sachen reicht es. "CANUSB uses FTDI USB chip FT245RL and we have developed our own DLL which in turn interfaces with the D2XX DLL from FTDI. This threaded DLL includes Open, Close, Read, Write & Status functions and will make it quick and easy for customers to make their own applications in a snap without understanding on how to parse commands and get into how the D2XX driver work. Tests with VB6 using this DLL shows that the CANUSB is fast and can receive 5000+ frames per second without loosing any frames. However due to the Windows USB driver 1mS time slot (gitter) you cannot send more than about 1000 messages per second, since the CANUSB needs to report back (this apply to sending & receiving, i.e. ping pong messages)." > Bei diesem Projekt wird man da vermutlich in die Nähe >kommen. Gibt es eigentlich kein vernünftiges DIY/OpenSource >CAN-USB-Adapter Projekt welches USB direkt umsetzt und auch volle >Buslast abkann? Kann doch eigentlich nicht so schwierig sein... Mach mal ;-)
Wolfgang schrieb: > The S. schrieb: >> Ich möchte mir eine Art Hue selbst bauen, >> hierfür möchte ich mir LED Module selbst bauen, >> die über einen BUS angesprochen werden und entsprechend LEDs dimmen. > > Was für LEDs hast du dir dafür vorgestellt. > > Die WS2812 mit integrierten Controller für ihren seriellen Bus wurden > doch schon erfunden. @Wolfgang: Volle Zustimmung, das sollte die einfachste Lösung sein.
Falk B. schrieb: > Nein, die USB-VErsion arbeitet mit einem virtuellen UART. Falk B. schrieb: > "CANUSB uses FTDI USB chip FT245RL Ah, das ist wohl USB<->Parallel. Auch wenn's geht finde ich so eine Lösung schon irgendwie hässlich. Falk B. schrieb: > Mach mal ;-) Bin gerade noch an einem anderen Projekt dran ;-) Aber spannend wäre es...
PS: Scheints doch zu geben: https://github.com/linklayer/candleLight_fw https://github.com/fabiobaltieri/open-usb-can
Daisy chain bedeutet an jedem Knoten rein und raus. Nicht aufstecken, nicht parallel am Bus. Jeder Knoten haette 2 Uart, eins fuer ein, das andere fuer raus. Oder wenn man sparen wollte, das UART wird umgeschaltet. Aber 2 Transceiver .
:
Bearbeitet durch User
@Dr. Sommer (Gast) >Ah, das ist wohl USB<->Parallel. Auch wenn's geht finde ich so eine >Lösung schon irgendwie hässlich. Das sehe ich genau anders herum 8-0. Es ist eine clevere Lösung, welche für 99% aller Anwender schnell genug ist und so weit wie möglich auf Standardlösungen in Hard- und Software zugreift. Dazu mit 100 Euro noch recht preiswert. Ein Mega-Teil ala CANalyzer etc. ist um Größenordnungen teurer und für eine ganz andere Zielgruppe.
Na, alles in einem Mikrocontroller zu machen ist noch günstiger und gut möglich, wie an den genannten Projekten sichtbar ist. Die Nutzung von dedizierten USB<->Seriell/Parallel-Adaptern wie FT245RL ist für mich immer eine Kapitulation vor der Software-Entwicklung - weil das Zusammensetzen von Hardware-Komponenten einfacher erscheint als das Zusammensetzen von Software-Komponenten (CAN-Treiber + USB-Treiber).
@Dr. Sommer (Gast) >Na, alles in einem Mikrocontroller zu machen ist noch günstiger und gut >möglich, wie an den genannten Projekten sichtbar ist. Wenn gleich vollintegrierte Lösungen oft Vorteile bieten, sind sie nicht immer zwingend nötig. > Die Nutzung von >dedizierten USB<->Seriell/Parallel-Adaptern wie FT245RL ist für mich >immer eine Kapitulation vor der Software-Entwicklung - weil das >Zusammensetzen von Hardware-Komponenten einfacher erscheint als das >Zusammensetzen von Software-Komponenten (CAN-Treiber + USB-Treiber). Andere Leute haben andere Stärken und Gewichtungen.
Dr. Sommer schrieb: > PS: Scheints doch zu geben: > ... > https://github.com/fabiobaltieri/open-usb-can Dr. Sommer schrieb: > Na, alles in einem Mikrocontroller zu machen ist noch günstiger und gut > möglich, wie an den genannten Projekten sichtbar ist. Zumindest das zwiete Projekt scheint so wie das von Thomas Fischl zu sein. Nur eben mit einem ATMega anstelle von einem PIC. Beide (ATMega, PIC) erledigen nur den USB Teil und sind über SPI mit einem CAN Controller verbunden.
:
Bearbeitet durch User
Lutz H. schrieb: > Gibt es für den CAN günstige Karten für den PC? Karten die ich gefunden > habe liegen bei 500 bis 700 Euro. Bei PEAK ab 200€ https://www.peak-system.com/PCAN-PCI.207.0.html
Mit den Adaptern habe ich gute Erfahrungen gemacht. Der CAN-Monitor ist inklusive. Allerdings kann ich nicht sagen, ob man die als Privatperson irgendwo zu kaufen bekommt. https://www.peak-system.com/PCAN-USB.199.0.html Preiswerter gehts hier. Allerdings ist der CAN-Monitor anscheinend nicht inclusive. Erfahrungen habe ich aber nicht mit dem Teil. https://elmicro.com/de/canusb.html Ansonsten würde ich mal nach CAN Adapter open source suchen.
Ahh sorry, Du hattest nach CAN Karten gefragt. Sicher da Du den dauerhaften Betrieb und nicht die Entwicklung im Focus hattest. Mit Peak machst Du sicher nichts falsch.
Vielen Dank für die große Anzahl und zum Teil sehr ausführlichen Antworten. So schnell habe ich nicht mit so vielen Antworten gerechnet :) Nun möchte ich euch aber auch nicht länger im Trüben fischen lassen. Falk B. schrieb: >>Ich möchte mir eine Art Hue selbst bauen, > > Ein was? Hue ist eine Produktreihe von smarten Lampen von Philips, doch bieten diese nicht alles was ich mir wünsche, zudem sind diese recht teuer. DMX512 ist leider nicht geeignet, zwar lassen sich die Slaves schnell gruppieren und einfach steuern, doch ist die Kanalzahl nicht ausreichend. So währen maximal 51 Slaves in einem Universum möglich, sprich ich benötige mindestens zwei DMX512 Universen. Falk B. schrieb: >>Da ich mich mit der PWM Steuerung nicht so auskenne, > > Das kann man ändern. PWM ist kein Hexenwerk. > (...) > >>doch stelle ich mir hier die Frage, ob eine PWM Dimmung nicht >>effizienter einfacher günstiger ist. > > Wahrscheinlich. Dann werde ich mich hier mit auch etwas genauer befassen. Doch kommt es bei PWM gerade bei kleinen Werten nicht zu einem merklichen Flackern? Wolfgang schrieb: > The S. schrieb: >> Ich möchte mir eine Art Hue selbst bauen, >> hierfür möchte ich mir LED Module selbst bauen, >> die über einen BUS angesprochen werden und entsprechend LEDs dimmen. > > Was für LEDs hast du dir dafür vorgestellt. > > Die WS2812 mit integrierten Controller für ihren seriellen Bus wurden > doch schon erfunden. Die WS2812 sind in der Tat nicht uninteressant, jedoch bieten auch diese nicht, was ich mir wünsche. Derzeit habe ich mir R+G+B+NW 3-Chip LEDs und eine UV (Schwarzlicht) LED heraus gesucht. Um möglichst viel Licht und eine gute Kontrolle über dieses zu bekommen. Daher habe ich die WS2812 wieder verworfen. Decius schrieb: > Nur noch als Tip zur weiteren Information. Controller, > Transceiver, > Protokolle was sich dahinter "verbirgt" ist das sogenannte > > OSI-Schichtenmodell. ;-) Keine Sorge, ich habe drei Jahre eine Schulische Ausbildung zum ITA hinter mir, die Grundlagen sind mir daher durchaus bekannt. ;) Jedoch fehlt mir viel praktische Erfahrung, die ich durch solche Projekte versuche zu bekommen. CAN ist nach dem, was ich so gefunden habe recht teuer, würde aber in der Tat am nächsten heran kommen. Wenn ich die Beiträge recht verstehe, geht die Tendenz 1. Richtung UART mit RS485 und einem ggf. selbst entwickeltem Protokoll. 2. Dimmung via PWM, jedoch eine zentrale Uhr, damit keine Interferenzen entstehen. Falls ich irgendwie falsch liege, bitte ich um Korrektur meiner Aussagen. Mit freundlichen Grüßen Marcel
Hmm, auch wenn es gegen den Trend ist, hier noch eine Liste mit möglichen CAN-Interfaces. http://www.can-wiki.info/doku.php?id=can_interfaces:main Wenn es ein privates Projekt ohne EMV Anforderungen unter starken Kostendruck ist, ist der UART+RS485 sicher eine Alternative. Privat hast Du ja alle Zeit der Welt, Dir ein eigenes Kommunikationsprotokoll zu schnitzen. :-) Allerdings nicht vergessen, die serielle Schnittstelle am Pc ist eine RS232, die ist elektrisch gesehen nicht identisch zur RS485. Zur Gruppierung würde ich auch hier schauen, ob Broadcast Messages möglich sind, und dann eine Gruppenkennung mitschicken.
Es gibt auch einige SBCs mit CAN. Ein BeagleBone(Black) braucht z.B. nur einen Transceiver, einen Raspberry könnte man über einen MCP2515 o.ä. damit bestücken... Im Dauerbetrieb brauchen die auch weniger Strom als ein PC, bieten aber dennoch eine angenehme Umgebung...
Decius schrieb: > (...) > Wenn es ein privates Projekt ohne EMV Anforderungen unter starken > Kostendruck ist, ist der UART+RS485 sicher eine Alternative. Privat hast > Du ja alle Zeit der Welt, Dir ein eigenes Kommunikationsprotokoll zu > schnitzen. :-) > > Allerdings nicht vergessen, die serielle Schnittstelle am Pc ist eine > RS232, die ist elektrisch gesehen nicht identisch zur RS485. > > Zur Gruppierung würde ich auch hier schauen, ob Broadcast Messages > möglich sind, und dann eine Gruppenkennung mitschicken. Ja, es ist ein rein privates Projekt, da sind gerade bei vielen Modulen natürlich die Kosten nicht zu vernachlässigen. Das mit den Broadcast Messages klingt tatsächlich gar nicht schlecht, danke dir. CC schrieb: > Es gibt auch einige SBCs mit CAN. Ein BeagleBone(Black) braucht > z.B. nur > einen Transceiver, einen Raspberry könnte man über einen MCP2515 o.ä. > damit bestücken... Im Dauerbetrieb brauchen die auch weniger Strom als > ein PC, bieten aber dennoch eine angenehme Umgebung... Die Steuerung würde ich über einen Pine Rock64 realisieren, der sowieso bald (wenn er ankommt) in Dauerbetrieb geht. Eine Frage zu möglichen LEDs ist mir da jedoch gerade gekommen. Ich habe mir zu erst bei leds-and-more die benötigten LEDs heraus gesucht, nun habe ich jedoch bei Led1 deutlich günstigere und etwas stärkere LEDs gesehen, ist hier die Qualität viel schlechter, oder ist leds-and-more einfach total überteuert?
Decius schrieb: > In form des UART gibt es natürlich auch bei RS485 ein einfaches > Kommunikationsprotokoll. Aber die Bus-Arbitirierung fehlt. Was willst du beim Steuern von Lampen mit Bus-Arbitrierung? Die LED-Module sollen gefälligst zuhören, was der Master ihnen befiehlt - ohne Widerworte.
The S. schrieb: > Eine Frage zu möglichen LEDs ist mir da jedoch gerade gekommen. > Ich habe mir zu erst bei leds-and-more die benötigten LEDs heraus > gesucht, nun habe ich jedoch bei Led1 deutlich günstigere und etwas > stärkere LEDs gesehen, ist hier die Qualität viel schlechter, oder ist > leds-and-more einfach total überteuert? Was für LEDs denn genau? (die Qualität hängt ja nicht vom Verkäufer ab)
Ich wuerde mit SPI anfangen, und dann, wenn Du die grossen Kabellaengen brauchst, einfach isoSPI machen. Der LTC6820 ist Dein Freund. :-) Ich denke damit laesst sich das Vorhaben gut realisieren.
Mark W. schrieb: > Der LTC6820 ist Dein Freund. :-) Für vermutlich deutlich weniger Geld bekommt man aber auch sicher einen uC mit integriertem CAN Modul + einen externen Transceiver.
Volker S. schrieb: > Mark W. schrieb: >> Der LTC6820 ist Dein Freund. :-) > > Für vermutlich deutlich weniger Geld bekommt man aber auch sicher > einen uC mit integriertem CAN Modul + einen externen Transceiver. Ja, schon klar. Die billigste Loesung ist es nicht. Marcel wird schon wissen, was sein Geldbeutel hergibt. :-)
Mark W. schrieb: > Ich wuerde mit SPI anfangen ... wenn die Leitungslänge 10cm nicht überschreitet. Darüber kann SPI schon Probleme machen. SPI ist mit Abstand der störempfindlichste Bus. Oder man nimmt differentielle Treiber+Empfänger für sämtliche Signale.
Peter D. schrieb: > Mark W. schrieb: >> Ich wuerde mit SPI anfangen > > ... wenn die Leitungslänge 10cm nicht überschreitet. Darüber kann SPI > schon Probleme machen. > SPI ist mit Abstand der störempfindlichste Bus. Oder man nimmt > differentielle Treiber+Empfänger für sämtliche Signale. Die Datenraten sind ja nicht soo hoch. Aufm Tisch kann man das ja mit wenigen Teinehmern anfangen, dann hat man schon mal die Software. Dann nimmt man die SPI Bruecke LTC6820 und testet mit den Kabellaengen.
Peter D. schrieb: > SPI ist mit Abstand der störempfindlichste Bus. Nicht I²C, wo positive Pegel und steigende Flanken durch Pullups erzeugt werden (statt mit Push-Pull-Stufen wie bei SPI) und somit beliebig kaputt gehen - besonders lustig bei Serienwiderständen?
Volker S. schrieb: > The S. schrieb: >> Eine Frage zu möglichen LEDs ist mir da jedoch gerade gekommen. >> Ich habe mir zu erst bei leds-and-more die benötigten LEDs heraus >> gesucht, nun habe ich jedoch bei Led1 deutlich günstigere und etwas >> stärkere LEDs gesehen, ist hier die Qualität viel schlechter, oder ist >> leds-and-more einfach total überteuert? > > Was für LEDs denn genau? > (die Qualität hängt ja nicht vom Verkäufer ab) Oh stimmt ^^, dass hätte ich natürlich dazu schreiben müssen. Im konkreten geht es um die PLCC6 LEDs, der jeweiligen Verkäufer. https://www.led1.de/shop/smd-leds/smd-led-bauform-plcc6/?xoid=nhbfu7rp06uj7cjonr4ca17vm6 gegen diese LEDs https://www.leds-and-more.de/catalog/5050-bauform-viel-licht-auf-wenig-raum-c-26_143.html?osCsid=bufpq135qghfc5sdgdnupc4sk0 nur bei der UV LED, muss ich bei leds and more auf eine andere Bauform zurück greifen, bei LED1 hätte ich alles in einer Bauform. Oder gibt es noch andere Shops, die Seriös zu einem guten Preis LEDs anbieten? Bei LED1 ist der Hersteller Winger angegeben, zu dem im Netz nicht so viel zu finden vermag, beim anderen Shop ist soweit ich gesehen habe kein Hersteller angegeben. Mark W. schrieb: > Ja, schon klar. Die billigste Loesung ist es nicht. > Marcel wird schon wissen, was sein Geldbeutel hergibt. :-) Als Student, ist der tatsächlich nicht so propper gefüllt. ^^ Ich denke über die MAX1483 ICs, werde ich etwas gutes hin bekommen, gerne bin ich für weitere Ideen offen. Ich bedanke mich noch mal für die wirklich gute Hilfe. Mit freundlichen Grüßen Marcel
:
Bearbeitet durch User
Mark W. schrieb: > Die Datenraten sind ja nicht soo hoch. Die ist für die Störsicherheit nicht entscheidend, sondern die Grenzfrequenz des Empfängers. Z.B. ein 74HC595 kann bis 30MHz, d.h. 17ns kurze Störungen bringen ihn schon aus dem Takt. CAN hat den großen Vorteil, daß es Störungen selber erkennt und ohne jedes Zutun automatisch den Transfer wiederholt. Außerdem wird jedes Bit 3-mal abgetastet. CAN wurde speziell auf Störsicherheit hin entwickelt.
Dr. Sommer schrieb: > Nicht I²C, wo positive Pegel und steigende Flanken durch Pullups erzeugt > werden (statt mit Push-Pull-Stufen wie bei SPI) und somit beliebig > kaputt gehen - besonders lustig bei Serienwiderständen? Nööö... I2C, in der Regel niedrigere Frequenzen. Meist 100kHz. SPI oft an die 4MHz. Da beginnt ganz schnell der Kampf gegen/mit Reflektionen. Typisch: Oszi dran, alles ok, Oszi ab, sporadische Fehler.
The S. schrieb: > gerne bin ich für weitere Ideen offen. muss alles 'roh' über den BUS gehen? muss es ein BUS für 'beide' Richtungen sein? kann ein Slave nicht Aufgaben übernehmen? Wir haben mal vor ein paar Jahren Experimente mit unterschiedlichen LED 'Situationen' (sehr dunkel punktförmige f. Sternenhimmel vs. flächige ) bzgl. Wahrnehmung von Flackern, Helligkeitsunterschieden probiert und sind nach sehr grober Erinnerung auf: ab 2kHz: kein Flackern/Perlenschnureffekt (ansonsten besonders bei kleinen punktförmigen und unterem Helligkeitsbereich) Dynamik: für indirekte, flächige Beleuchtung reichen wohl 10-12bit; f. Sternenhimmel 14-bit nicht ganz Unterschiede: 8-bit sollten reichen; mit 7-bit haben probierte LUT tw. wahrnehmbare 'Sprünge' gehabt (Test: zufälliges +-1 alle 0,1..2 sek) einige Effekte könnten auch tw. durch die Ansteuerung (wohl zu langsame uln2003)verursacht sein, aber 8-bit Werte mit 14-bit LUT im µC können den weiteren Umgang vereinfachen. Ein µC kann u.U. auch Fading übernehmen (auf feste Update Frequenz bsp. 5/10/20 Hz oder wie eine Glühlampe schnell aufleuchten und langsamer bei verringerung regieren) Gruppenadressen und/oder kombinierte R/G/B Datenpakete sollten kein Problem sein, allerdings hängt (bei den probierten Ideen) viel im Status der µC was auch unübersichtlich werden kann ;-) Beim BUS noch der Gedanke an Leitungslänge und chaotische Plug&PrayStruktur: vom Gefühl schadet eine gelegentliche Potentialtrennung (Optokoppler/WLan) nicht unbedingt. Vom PC über WLan (bsp. Esp266) in die gröbsten Ecken und von da mit einfachst seriell in die µC oder weiteren 'Hubs' und die Rückmeldung 'nur' über die Ecke oder gar per Hand ... kurz: der 1-wire BUS könnte etwas zu wenige Ideen gehabt haben, ansonsten kann vieles gut funktionieren
The S. schrieb: > würde ich die LEDs via µCU + DAC + Mosfet dimmen, Das würde ich als eklatanten Designfehler ansehen. > Da ich mich mit der PWM Steuerung nicht so auskenne, Ändere das. Du musst es, wenn du so ein Projekt in ernsthaften (Beleuchtungs-)Dimensionen durchziehen willst. The S. schrieb: > Um möglichst viel Licht und eine gute Kontrolle über dieses zu bekommen. So eine lineare Ansteuerung mit "DAC + Mosfet" (am besten noch ohne Stromregelung, sondern nur über Spannungssteuerung), wie du sie dir vorstellst, ist nebenher für sinnvolle Helligkeiten auch noch eine brauchbare Heizung. > Derzeit habe ich mir R+G+B+NW 3-Chip LEDs und eine UV (Schwarzlicht) LED > heraus gesucht. Welche denn? Arduino F. schrieb: > I2C, in der Regel niedrigere Frequenzen. Meist 100kHz. > SPI oft an die 4MHz. > Da beginnt ganz schnell der Kampf gegen/mit Reflektionen. Die Frequenz der Datenübertragung ist dabei aber nicht das Problem, sondern, dass beim SPI die Flanken aktiv getrieben werden und je nach Treiber entsprechend steil sein können. Beim I2C ist zumindest die steigende Flanke wegen des Pullups nur eine e-Funktion... Fürs Thema sicher interessant ist deshalb auch der Beitrag "Re: Serienwiderstand bei Hochfrequenz"
Dirk schrieb: > kurz: der 1-wire BUS könnte etwas zu wenige Ideen gehabt haben, > ansonsten kann vieles gut funktionieren Der ist universell und kann alles in nahezu jeder Geschwindigkeit. Funk ist z.B. eine quasi-1-Wire-Verbindung, da nur ein pin getoggelt wird. 1-Wire unterscheidet sich auch nicht so sehr von twi oder spi. Es kommt immer darauf an, dass die Geschwindigkeit so gedrosselt wird, dass die Signale sicher unterscheidbar sind. ob die Signale einen Spi- oder twi-clock oder 1-wire-daten darstellen, ist im Prinzip egal. Die Leitungsverbindung muss so gut sein, dass die Datenübertragung sicher erfolgen kann. Ob das nun ein clock- oder 1-wire-Daten sind, ist der Leitung egal und weiß sie im Zweifel nicht. Der to kann also von spi bis 1-wire alles nehmen. Wichtiger als die Busleitung ist das Protokoll. Das protokoll ist von der Art der Übertragung unabhängig. Man kann für 1-Wire, twi, spi, 4bit, 8bit etc. im Prinzip das gleiche Protokoll verwenden. Fragestellung ist eigentlich immer nur, was erfüllt alle Anforderungen mit dem wenigsten Aufwand.
Bei verkabelten Geräten sollte man bedenken, dass die Kabel, Stecker und Verteiler am Ende oft die teuersten Komponenten sind - vor allem bei größeren Installationen. Ethernet Komponenten sind derzeit unschlagbar billig. Da kann es sich unter Umständen lohnen, in die Geräte entsprechende Schnittstellen einzubauen, auch wenn das technisch unnötig Aufwändig erscheinen mag.
Lothar M. schrieb: > So eine lineare Ansteuerung mit "DAC + Mosfet" (am besten noch ohne > Stromregelung, sondern nur über Spannungssteuerung), wie du sie dir > vorstellst, ist nebenher für sinnvolle Helligkeiten auch noch eine > brauchbare Heizung. Genau so eine Spannungssteuerung baue ich gerade für mein Arbeitszimmer, weil ich keine PWM-gesteuerten LED haben will. Die "Heizleistung" wird gnadenlos überschätzt. Durch die nichtlineare Kennlinie der LED spielt sich das alles im oberen Spannungsbereich ab. Bei einem 12V-24W LED-Strip mit 2A beträgt die maximale Verlustleistung am Transistor 2W, wenn man die Schaltung mit 12.5V versorgt, bei voller Helligkeit beträgt sie noch 1W. Damit kann ich leben. Die Alternative wäre ein Schaltregler, aber der müsste dann 95% Effizienz haben, damit sich das lohnt.
Moin, Stefan U. schrieb: > Ethernet Komponenten sind derzeit unschlagbar billig. Da kann es sich > unter Umständen lohnen, in die Geräte entsprechende Schnittstellen > einzubauen, auch wenn das technisch unnötig Aufwändig erscheinen mag. Uii, duennes Eis. Ethernet scheint aus mir unbekannten Gruenden hier im Thread nicht ganz so wohlgelitten zu sein ;-) Gruss WK
...dann kann man ja auch einfach Ethernetkabel und -stecker verwenden und die Adern für eigene Dinge nutzen. Verdrillt ist es, z.T. geschirmt, passives PoE hat ja auch mehr oder weniger seine Standardleitungen...
Ich dachte dabei nicht nur an Kabel, sondern auch an Switche.
Dirk schrieb: > muss alles 'roh' über den BUS gehen? > muss es ein BUS für 'beide' Richtungen sein? > kann ein Slave nicht Aufgaben übernehmen? Alles Roh über den BUS zu realisieren erscheint mir die einfachste Möglichkeit, was die Programmierung betrifft bin ich an sich recht fit, klar werde ich mich bei dem ein oder anderen speziellen Thema noch mal kurz einlesen müssen, doch das sollte keine Probleme bereiten. Für beide Richtungen würde bei meiner aktueller Planung das einbinden der Slaves erleichtern. Wenn ich den RS485 richtig verstanden habe, ist es hier möglich Full Duplex zu arbeiten. Somit kann ich die Slaves fast Hotplug fähig machen. Man würde einen Slave während des Betriebs einfach anschließen und einen Taster an diesem betätigen. Hierdurch würde der Master über die Rückleitung eine Signal bekommen, dass jemand auf seine Adresse wartet. Nun wird allen bereits im BUS befindlichen Slaves signalisiert, dass sie die nächste Nachricht ignorieren sollen. Nun bekommt der neue Slave seine Adresse im BUS, da er ja weiß, dass er die Adresse angefordert hat, ist dies der einzige, der sie verarbeitet. Nach einer kurzen Rückmeldung zum Master, dass die Adresse richtig verstanden wurde, geht der Regelbetrieb im BUS weiter. (Das wäre jetzt im Groben meine Vorstellung davon, wie ich den Slaves in richtiger Reihenfolge ihre jeweilige Adresse zuordnen würde) Ich wüsste ehrlich gesagt nicht, welche Aufgaben ich einem Slave übertragen soll? Im Prinzip stelle ich mir die Slaves als schlichte µCU gestützte multichannel PWM Dimmer vor, die über einen BUS die benötigten Daten bekommen. Dirk schrieb: > Beim BUS noch der Gedanke an Leitungslänge und chaotische > Plug&PrayStruktur: vom Gefühl schadet eine gelegentliche > Potentialtrennung (Optokoppler/WLan) nicht unbedingt. Vom PC über WLan > (bsp. Esp266) in die gröbsten Ecken und von da mit einfachst seriell in > die µC oder weiteren 'Hubs' und die Rückmeldung 'nur' über die Ecke oder > gar per Hand ... An Potentialtrennung habe ich tatsächlich noch keinen Gedanken verschwendet, schaden wird es auf jeden Fall nicht hier für etwas Sicherheit zu sorgen. Für die weiteren Informationen möchte ich dir wirklich danken, nun habe ich sehr viel wichtiges, worüber ich mir Gedanken gemacht habe kompakt an einer Stelle und kann mich nun weiter orientieren. Lothar M. schrieb: >> Derzeit habe ich mir R+G+B+NW 3-Chip LEDs und eine UV (Schwarzlicht) >> LED >> heraus gesucht. > Welche denn? Konkret geht es hier um quasi das gesamte Sortiment an PLCC6 LEDs dieser beiden Händler. Als konkretes Beispiel hier ein mal die möglichen grünen LEDs ich bin mir weiterhin unsicher, ob ich bei LED1 zu wenig für eine Brauchbare Qualität zahle, oder ob ich bei leds and more zu viel bezahle, daher einmal die konkreten LEDs um die es geht: https://www.led1.de/shop/smd-leds/smd-led-bauform-plcc6/led-smd-bauform-plcc6-gruen-15lm-wergn15-cm.html gegen https://www.leds-and-more.de/catalog/smd-5050-plcc6-led-ultrahell-gruen-2500mcd-120-chip-p-1379.html?osCsid=bufpq135qghfc5sdgdnupc4sk0 Stefan U. schrieb: > Bei verkabelten Geräten sollte man bedenken, dass die Kabel, Stecker und > Verteiler am Ende oft die teuersten Komponenten sind - vor allem bei > größeren Installationen. Das habe ich auch schon fest gestellt, ich hatte zu erst an eine 9W4 D-Sub Verbindung gedacht, doch dies ist in diesem Preisbereich fast unbezahlbar. Da ziemlich schnell viele Ampere zusammen kommen fällt PoE so wie Ethernet an sich eigentlich raus. Wobei die von "hause" aus geschirmten Kabel natürlich Vorteile mit sich bringen. Für grob 10 Slaves sollte es tatsächlich reichen, doch wie viel kann ich damit wohl überspannen? 2-3 Meter würde ich mal schätzen, dass ist für den Alltag wohl etwas zu kurz. Ich bedanke mich auch weiterhin für die vielen sehr hilfreichen Antworten. Mit freundlichen Grüßen Marcel
>Wenn ich den RS485 richtig verstanden habe, ist es hier möglich Full Duplex zu arbeiten. Ja, allerdings auf Kosten der Nutzdaten und du musst entweder selber ein Protokoll basteln wer wann senden darf oder die von Modbus/KNX/..o.ä. nutzen. DMX (RS485 1:n) hat praktisch die durch Aufwand in Kabel etc. begrenzte Bandbreite zur Verfügung, während Modbus/KNX/? (RRS485 m:n) jeweils noch eigene Daten zur 'Freigabeverhandlung' brauchen. DMX ist sehr effizient, da du praktisch nur d_0,d_1,....d_511 überträgst (ähnlich Ws2812,Monitor,....) mit Adresse: a_0,d[a_0],a_1,d[a_1],... (bei 10 Byte Daten + 1 Byte Adresse noch nicht dramatisch) aber dann noch: a_0,d[a_0],a_1,d[a_1],...,f_jmd_anderes?....nein->...a_10,d[a_10] ist für seltene Rückmeldungen bei begrenzter Bandbreite ungünstig. Die Variante bsp. RS485/DMX für Steuerdaten + 1-wire für Rückleitung dürfte für Plug'n Play (neue Geräte nur alle paar Sekunden) ein deutlich besseres Aufwand/Nutzenverhältnis haben. >Alles Roh über den BUS zu realisieren erscheint mir die einfachste Möglichkeit das ist es wohl auch (irgendwie/häufig), allerdings kann die Frage wie roh genau auch bei BUS Ideen unterschiedliche Wirkungen haben. DMX ist konzeptionell sehr roh : das Universum-Speicherabbild des PC wird jeweils komplett roh an alle Geräte (ob aktiv oder nicht) übertragen. Selektive Updates an einzeln adressierte Geräte können die Bandbreite reduzieren oder durch den Overhead erhöhen, aber mit dem 'Feature' Gruppenadressen zur Busoptimierung ist es mit dem einfachen Speicherabbild vorbei. Praktisch ist DMX erstmal wie eine Grafikkarte die das Bild roh an den Monitor sendet aber für "schlichte µCU gestützte multichannel PWM Dimmer" (linear codiert/statuslos) grob 12-14 bit für die Dynamik beim Monitorbild benötigt(der Monitor rechnet mit gamma-funktion UND Status Helligkeit/Kontrast praktisch intern auf 14-bit hoch) kurz: Vereinfachung kann Bandbreite kosten und kompliziert werden sobald man beim vereinfachen nicht gaaaanz vorsichtig ist. >An Potentialtrennung habe ich tatsächlich noch keinen Gedanken verschwendet, schaden wird es auf jeden Fall nicht hier für etwas Sicherheit zu sorgen. Sicherheit im Sinne von Menschenschutz ist wohl bei den Netzteilen relevant. Ich hab mehr an Erfahrungen: Monitor-Stecker in Grafikkarte v.PC -->Autsch--> käme mein Bastel-µC damit klar? müssen kleine µC die eigentlich nur unter harmloser Kleinspannung stehen gleich bei Kontakt mit einer (geerdeter) Lötspitze verunglücken? oder brummt der PC mit vielen Metern Empfangschleifen wie eine Stereoanlage? gedacht kurz: mehr als eine Fehlerquelle weniger gemeint, auch wenn "Sicherheit" natürlich auch wichtig ist (in Anführungszeichen da es sehr viele Arten von Sicherheit gibt und "Sicherheit" aufgrund der unsicheren Bedeutungen eigentlich für Ironieanwendungen brauchbar wäre) >Ich wüsste ehrlich gesagt nicht, welche Aufgaben ich einem Slave übertragen soll? das Beispiel Fading hat sich bei den Experimenten zur Wahrnehmung ergeben(allerdings nicht 'blind' getestet). Ein Farbsignal mit 30HZ Update 'fühlte' sich mit Fading/Interpolation anders an (ließt sich etwas merkwürdig) Für Ambilight o.ä.kann u.U. 10fps Analyse reichen wenn der Slave interpoliert. Mehr als Fading und Gammafunktion im µC ist nach einer privat Untersuchung (n=1) sicher nicht die einfachste Möglichkeit. Dynamisch Gruppenadressen zuweisen ist eine nette Möglichkeit die am einfachsten nicht genutzt wird und auch Sequenzer im µC sind nett und machen kompliziert. kurz: zu viele Möglichkeiten sind nicht auch nicht zwingend besser...
Dirk schrieb: > (...) > Die Variante bsp. > RS485/DMX für Steuerdaten > + 1-wire für Rückleitung > dürfte für Plug'n Play (neue Geräte nur alle paar Sekunden) ein deutlich > besseres Aufwand/Nutzenverhältnis haben. Ich dachte eigentlich, auf Basis dieses Datenblatts: https://datasheets.maximintegrated.com/en/ds/MAX1482-MAX1483.pdf Seite 11, Figure 15. Dass es möglich ist, den "Empfänger" aller Slaves auf ein und den "Sender" dieser auf ein weiteres Leitungspaar zu legen. Der Master würde entsprechend anders herum angeschlossen werden, somit kann der Master auf einem Paar den Slaves ungehindert Steuerdaten übermitteln und eben über das andere Paar Informationen wie "Neuer Slave" oder "Übertragungsfehler" zurück bekommen. Aber nach deiner Aussage scheint dieses nicht zu funktionieren. Mittlerweile habe ich mich noch etwas intensiver mit der Thematik befasst, daher möchte ich nun 6 Statt 5 LEDs einsetzen, alles andere (abgesehen von einer leicht gestiegenen Datennutzung) bleibt erst mal gleich. Ich denke, dass ich mittlerweile auch ein nutzbares Protokoll erdenken konnte. Hierbei werden insgesamt 14 Byte für einen Slave übertragen, die wie folgt aufgeteilt sind: 1. Byte Adresse (1-250) 2.-13. Byte für jede Farbe einzeln: 10 Bit Farbwert und 6 Bit für ggf. Fading. (0-63 ms) Ab 16Hz ist so ein durchgehendes Faden über den gesamten Wertebereich möglich. 14. Byte Kontrollbyte um Übertragungsfehler zu detektieren. Es würden noch 6 Broadcastadressen für allgemeine Steuerungen zur Verfügung stehen. Hierzu zähle ich etwa die BUS Steuerung zu deaktivieren und aktivieren. (ignorieren der Nachrichten). Die Hardwaregruppierung war eine Idee um mehrere Slaves exakt gleichzeitig zu steuern, doch bei einer möglichst hohen angestrebten Aktualisierungsfrequenz wird der zeitliche Unterschied bei seriellen ansprechen der Slaves wohl nicht auffallen. Ich bin gestern auch auf einen vielversprechenden Controller für die PWM Steuerung gestoßen: https://www.microchip.com/wwwproducts/en/PIC24F08KL301 Jedoch bin ich mir hier nicht sicher, ob tatsächlich 6 unabhängige PWM Channel zur Verfügung stehen, in der Übersichtstabelle von den 16 Bit µCUs steht zwar, dass maximal 6 PWM Channel genutzt werden können, doch ist auf der direkten Produktseite folgendes zu lesen: >Capture/Compare/PWM Peripherals 3/3 das verwirrt mich jedoch ein bisschen. Gibt es ggf. alternativen zu diesem Controller? Ist dieser Controller überhaupt geeignet? Soll ich hier überhaupt nach dem entsprechenden Controller fragen, oder ist es besser ein neues Thema hierfür zu erstellen? Mit freundlichen Grüßen Marcel
:
Bearbeitet durch User
Also der PIC24... kann meiner Meinung nach, laut Data Sheet, 3 unabhängige Hardware PWM und ist demnach nicht für deine 6 Kanäle geeignet. Wenn du einen uC von Microchip oder Atmel suchst, dann würde ich dir MAPS empfehlen http://www.microchip.com/maps/Microcontroller.aspx
:
Bearbeitet durch User
Stefan U. schrieb: > Ich dachte dabei nicht nur an Kabel, sondern auch an Switche. Die braucht man bei CAN nicht.
The S. schrieb: > Wenn ich den RS485 richtig verstanden habe, ist es hier möglich Full > Duplex zu arbeiten. Somit kann ich die Slaves fast Hotplug fähig machen. > Man würde einen Slave während des Betriebs einfach anschließen und einen > Taster an diesem betätigen. Hierdurch würde der Master über die > Rückleitung eine Signal bekommen, dass jemand auf seine Adresse wartet. Nö, RS-485 ist Halb-Duplex. Der Master muß immer nur einen Slaven zum Senden auffordern und diese dürfen nicht einfach so dazwischen quatschen, sonst kommt es zu Datenkämpfen. Viele Transceiver haben deshalb eine Übertemperaturabschaltung, aber diese sollte man nicht für den regulären Betrieb mißbrauchen. Das ganze Protokollgeraffel mit der Slaveadressierung, Richtungsumschaltung, Fehlererkennung, Timeouts usw., was Du bei RS-485 mühsam in SW machen mußt, kriegst Du bei CAN für umsonst. Und dann ist auch Hotplugging kein Problem. Der gerade laufende Transfer erkennt Fehler und wiederholt sich automatisch und ein neuer Slave darf einfach drauflos quatschen.
Morgen, Wie wäre es mit LIN? Wenn eine typische Übertragungsrate von 19k2 ausreicht. Man muss auch nicht zwingend das LIN-Protokoll anwenden, LIN-UART geht auch und man hat maximal drei Leitungen. Ein LIN-Transceiver wäre der ATA6625. Gruß Tobi
Ich habe auch zuerst an CAN gedacht. Da gehen zwar nur max. 127 Teilnehmer pro Bus, aber mir stellt sich eine ganz andere Frage: was will der TO denn eigentlich verbinden? Geht es um eine lange Kette an LEDs oder um im Raum verteilte Module mit jeweils mehreren LEDs? Vermutlich werden es mehrere Module mit eigenem uController die einzeln oder gemeinsam gesteuert werden können sollen. So ala Smart Home. Die WS2812 oder ähnliche LEDs (RGBW) mit integriertem Controller vereinfachen sicherlich den Aufbau der einzelnen Module. Für verteilte Module die fest installiert sind kann auch eine CAN verkabelung machbar sein. Das wird dann zwar nicht mehr anfängerfreundlich, aber eine interessantere Variante wären autarke Module die zB per ESP8266 im WLAN hängen. Ein Modul kann zB die komplette TV-Hintergundbeleuchtung, die gesamte Sofaunterleuchtung etc sein. Per WLAN ist dann auch eine Steuerung per Smartphone oder Smart Home Zentrale denkbar. Sei es nun über eine App oder über URLs. Dann wird der TO vermutlich auch keine 250 Module mehr benötigen. Denkbar sind auch vernetzte Controllereinheiten, die dann mehrere LED Aufgaben in einer Raumecke erledigen. Also z.B. mehrere LED Ketten unabhängig ansteuern können. Das reduziert die Anzahl der Module nochmals. Und einen PC als CAN Master möchte man auch nicht unbedingt haben. Das würde dann auch eher ein dediziertes Modul übernehmen, oder aber jedes Modul ist eigenständig. Ein CAN Interface für die Entwicklung bräuchte man aber wohl trotzdem. Die PEAK Teile sind preiswert und gut.
Bernd schrieb: > Ich habe auch zuerst an CAN gedacht. > Da gehen zwar nur max. 127 Teilnehmer pro Bus, Kann man im Prinzip nicht so viele Teilnehmer wie mögliche Message IDs haben, wenn man sich an kein vorgegebenes Protokoll hält?
Volker S. schrieb: > Bernd schrieb: >> Ich habe auch zuerst an CAN gedacht. >> Da gehen zwar nur max. 127 Teilnehmer pro Bus, > > Kann man im Prinzip nicht so viele Teilnehmer wie mögliche Message IDs > haben, wenn man sich an kein vorgegebenes Protokoll hält? Stimmt. Ich hatte CANopen im Kopf... Aber die grundsätzliche Frage bleibt, ob er wirklich 250 Slaves über den Bus ansprechen können muss. Jeder Slave braucht dann einen uController, einen CAN Transceiver etc. Ich würde versuchen, das so weit wie möglich zusammen zu fassen und so etwas wie die schon genannten Module mit mehreren Ausgängen für intelligente LED Ketten machen.
Mal was ganz anderes: Es gibt günstige Bluetooth LE oder IEEE 802.15.4 (Zigbee, 6LoWPan und andere) Module für ein paar Euro. Auf dem Funkchip kann man auch seinen eigenen Code mit laufen lassen, so dass ein extra Controller entfällt. In jeder Philips Hue und Osram Lightify Birne ist so ein Teil drin. Die Funktchips enthalten in der Regel einen 8051 oder einen ARM Cortex M Prozessorkern. fchk
>über das andere Paar Informationen wie "Neuer Slave" oder"Übertragungsfehler" zurück bekommen. >Aber nach deiner Aussage scheint dieses nicht zu funktionieren. Sorry, die Variante hatte ich überhaupt nicht weiter bedacht und praktisch als zweiten Bus abgestempelt (knapp daneben,ups) Solange die Slaves sich absprechen und nicht gleichzeitig "Übertragungsfehler"/"Neuer Slave" senden funktioniert das sicher problemlos; die Regelung: Slave darf nur antworten wenn er zuvor vom Master gnädig auf Paar 1 adressiert wurde ist für "!Übertragungsfehler!" ganz praktisch, bei Neueinsteigern ist etwas Vorsicht geboten für den Fall, dass sich viele gleichzeitig anmelden bsp. wenn plötzlich gute Stromverhältnisse herrschen. kurz: im wesentlichen hatte ich einen Übertragungsfehler (vielleicht eine Abneigung gegen aufwändig verdrillte 4 polige Leitungen oder inkl.Stromversorgung 6 Leitungen f. 6 Kanäle oder ...) aber etwas "Protokollgeraffel" benötigst du und da ist die Frage welche Information ein neuer Slave eigentlich hat oder ob nur 'Ansprechbar' die Information ist u.U. sehr interessant. >einzeln: 10 Bit Farbwert für 'vernünftige' (im Sinne sichtbarer Bereich) physische Auflösung zu wenig (8MHz µC @2KHz schafft 12-bit)und für auf wahrgenommene Werte transformierten Bereich zu viel. wenn du im µC eine (programmiertechnisch) einfache LUT implementierst (gamma 2,2; 12-bit) W[0..255] mit W[x]=(2^12-1)*(x/255)^2,2 dann benötigst du extern lediglich 8-bit (u.U. 7) und - das ist der eigentliche Punkt - der Bereich ist praktisch linear zur Wahrnehmung d.h. ein Fading 255-->0 wird als 'gerade' wahrgenommen und du hast bei rgb grob PC Farbwerte (der genaue gammawert müsste gemessen werden aber 2,2 sollte grob passen) >einzeln: 6 Bit für ggf. Fading. (0-63 ms) unpraktisch: wenn der PC sendet wann das nächste Datum zu erwarten ist, dann betrifft das alle Kanäle; für Effekte mit etwas anderer Definition z=1ms*2^(w/c) u.U. nett, aber kompliziert für einfaches Softwaremodell. >Kontrollbyte nice to have kurz: für wahrnehmungsnützliche Daten sollten 9 Byte reichen >Soll ich hier überhaupt nach dem entsprechenden Controller fragen, oder ist es besser ein neues Thema hierfür zu erstellen? bei der Frage nach dem Bus wäre für der Punkt ob der µC genau für den Bus besondere Merkmale benötigt. Mit Software-PWM kann jeder µC, der 6 Ausgänge an einem Port/ 8MHz /einen Timer und etwas Speicher hat, die Aufgabe bewältigen. Vom Prinzip könnten die Antworten ähnlich wie die Frage nach dem Bus enden, schließlich hat jeder einen Hammer zu Hause der genau zur Frage passt.
Peter D. schrieb: > Nö, RS-485 ist Halb-Duplex. Der Master muß immer nur einen Slaven zum > Senden auffordern und diese dürfen nicht einfach so dazwischen > quatschen, sonst kommt es zu Datenkämpfen. Viele Transceiver haben > deshalb eine Übertemperaturabschaltung, aber diese sollte man nicht für > den regulären Betrieb mißbrauchen. Dann verstehe ich aber die eine Darstellung im Dokument zu den MAX1483/MAX1482 nicht, da hier eindeutig von Full-Duplex mit einem Single Master BUS geschrieben wird. Alles was ich bei CAN an Bauteilen gefunden haben liegt Kosten technisch über denen von RS485, zugegebener Maßen blicke ich hier nicht ganz durch. Abgesehen von ein paar einzelnen ICs / Controllern für ein paar Euro das stück, finde ich nur große Bausteine für mindestens 30 Euro. Bernd schrieb: > Die WS2812 oder ähnliche LEDs (RGBW) mit integriertem Controller > vereinfachen sicherlich den Aufbau der einzelnen Module. Für verteilte > Module die fest installiert sind kann auch eine CAN verkabelung machbar > sein. Die WS2812 sind nur RGB, weitere ähnliche LEDs sind mir bisher nicht bekannt. Da es eine einzelne 3 Chip LED ist, wird hier die Lichtausbeute wohl deutlich unter der von 6 autarken 3 Chip LEDs liegen. Mir geht es in erster Linie darum, möglichst viel Licht mit einer guten Farbkontrolle zu erlangen. Ich möchte mir einzelne Module basteln. (Die erwähnten Slaves) Ein Modul soll jeweils aus 6 LEDs bestehen. Rot, Grün, Blau, Gelb (Amber), Neutral Weiß und UV. Die Module sollen später via Computer bzw. einer Smartphone App gesteuert und einzeln angesprochen werden können. So lassen sich die gleichen Module für eine passive Raumbeleuchtung und gleichzeitig für eine Arbeitsplatzbeleuchtung oder ähnliches einsetzen. Es würde sich somit die gesamte Raumbeleuchtung mit einem Master und den dazu gehörigen Slaves verhältnismäßig einfach einrichten. (Nach dem die ganze Arbeit getan ist) Als Beispielrechnung wieso ich gerne so viele Slaves unterstützen möchte. Mein aktuelles Zimmer ist 16qm groß, und hat einen gesamt Umfang von 16 Metern, wenn ich alle 10cm ein Modul einsetze um im Raum eine Flächendeckende, ausreichend starke Beleuchtung zu gewährleisten, dann sind 160 Module im Einsatz. Durch direkte Beleuchtung an verschiedenen Stellen, oder weitere Einsatzmöglichkeiten an unterschiedlichen Positionen können es noch deutlich mehr Module werden. Dadurch, dass es eine Adressierung jedes einzelnen Moduls gibt, lässt sich dennoch alles jedes Modul unabhängig Steuern. So ist die passive Raumbeleuchtung unabhängig vom Arbeitslicht, da jeder Slave nur auf die für ihn bestimmte Anweisung hört. Frank K. schrieb: > Mal was ganz anderes: Es gibt günstige Bluetooth LE oder IEEE 802.15.4 > (Zigbee, 6LoWPan und andere) Module für ein paar Euro. Auf dem Funkchip > kann man auch seinen eigenen Code mit laufen lassen, so dass ein extra > Controller entfällt. In jeder Philips Hue und Osram Lightify Birne ist > so ein Teil drin. Das hört sich interessant an, halten mich jetzt ruhig für paranoid, doch sehe ich in jeder Schnittstelle die Außerhalb meiner 4 Wände zur Verfügung steht ein potentielles Einfallstor für Leute die da eigentlich nichts zu suchen haben. Mache ich bsp. einen gravierenden Fehler in der LEDs Steuerung via Funk, könnte es über Umwege möglich sein in das Netzwerk ein zu dringen und ggf. weitere Geräte zu befallen. Zudem hängen hier mindestens die WLAN Netze recht nah aufeinander, weshalb ich auf Funkverbindungen nach Möglichkeit verzichte um nicht für noch mehr Störungen zu sorgen. Dirk schrieb: > Solange die Slaves sich absprechen und nicht gleichzeitig > "Übertragungsfehler"/"Neuer Slave" senden funktioniert das sicher > problemlos; die Regelung: Slave darf nur antworten wenn er zuvor vom > Master gnädig auf Paar 1 adressiert wurde ist für "!Übertragungsfehler!" > ganz praktisch, bei Neueinsteigern ist etwas Vorsicht geboten für den > Fall, dass sich viele gleichzeitig anmelden bsp. wenn plötzlich gute > Stromverhältnisse herrschen. An ein solches Problem hatte ich zunächst nicht gedacht, danke für den Denkanstoß. Da die Slaves nach einander durch ihre jeweilige Adresse angesprochen werden, sollte es bei einer ausreichend kurzen Rückmeldung möglich sein, den Rückweg auch bei massiven Übertragungsfehlern frei von Störungen durch überlagerte Nachrichten zu halten. Um neue Slaves ein zubinden, könnte nach dem alle bekannten Slaves angesprochen wurden, eine kurze Pause seitens des Masters statt finden. Diese Pause wird dann zum Zeitfenster, welches ein neuer Slave hat um eine Adresse an zu fordern, da der Rückkanal auch bei vielen Störmeldungen nach einer kurzen Verzögerung frei ist. Damit nun nicht alle Adresslosenslaves gleichzeitig während der Pause eine Adresse anfordern, wird eine Anforderung mittels Knopfdruck auf dem Slave veranlasst und in der Pause ausgelöst. So kommt sich kein Slave in die Quere und dennoch erreichen den Master alle benötigten Informationen. Dirk schrieb: > wenn du im µC eine (programmiertechnisch) einfache LUT implementierst > (gamma 2,2; 12-bit) > W[0..255] mit W[x]=(2^12-1)*(x/255)^2,2 > dann benötigst du extern lediglich 8-bit (u.U. 7) und - das ist der > eigentliche Punkt - der Bereich ist praktisch linear zur Wahrnehmung > d.h. ein Fading 255-->0 wird als 'gerade' wahrgenommen und du hast bei > rgb grob PC Farbwerte (der genaue gammawert müsste gemessen werden aber > 2,2 sollte grob passen) Diese Information ist sehr hilfreich, vielen Dank. Hier werde ich mich auch noch etwas genauer einlesen, bisher habe ich nur etwas von einer logarithmischen Helligkeitswahrnehmung gelesen. Dirk schrieb: >>einzeln: 6 Bit für ggf. Fading. (0-63 ms) > unpraktisch: wenn der PC sendet wann das nächste Datum zu erwarten ist, > dann betrifft das alle Kanäle; für Effekte mit etwas anderer Definition > z=1ms*2^(w/c) u.U. nett, aber kompliziert für einfaches Softwaremodell. Da habe ich mich wohl etwas missverständlich ausgedrückt, mit dem Fadingwert, sollte angegeben werden, bis wann der im vorderen Teil angegebene Farbwert erreicht werden soll. Bei 0 sofort und bei 63 ms ein herunter dimmen auf den angegebenen Wert. So können bei Farbwechseln weichere Übergänge geschaffen werden, ohne viele Daten über den BUS senden zu müssen. Wenn ich nur 8 Bit für den Farbwert benötige und weiterhin bei 2 Byte für jede Farbe bleibe, so würden theoretisch sogar Fadingzeiten von bis zu 255ms möglich sein. Die den BUS bei konstanten Farbverläufen zusätzlich entlasten würden. So würden beim sanftem Ausschalten mit einer Sekunde fading auf Null nur vier Nachrichten benötigt werden. Erneut muss ich mich bei euch für die Vielzahl an wirklich hilfreichen Antworten bedanken, diese helfen mir wirklich sehr. Vielen Dank an alle, die sich bemühen mir weiter zu helfen. Mit freundlichen Grüßen Marcel
RS485 kann man in zwei Varianten betreiben: * 1 Leiterpaar = Half Duplex * 2 Leiterpaare = Full Duplex Die erste Variante scheint häufiger vor zu kommen.
The S. schrieb: > Dann verstehe ich aber die eine Darstellung im Dokument zu den > MAX1483/MAX1482 nicht, da hier eindeutig von Full-Duplex mit einem > Single Master BUS geschrieben wird. Prinzipiell ginge das (MAX1482), man muß allerdings 4 Datenleitungen verlegen. Auch gewinnt man dabei nichts, da trotzdem der Master immer erstmal einem Slave sagen muß, wann er auf Senden umschalten darf. Man treibt also einen doppelt hohen Aufwand an Verkabelung und hat davon keinerlei Nutzen. The S. schrieb: > Alles was ich bei CAN an Bauteilen gefunden haben liegt Kosten technisch > über denen von RS485, zugegebener Maßen blicke ich hier nicht ganz > durch. Z.B. der CAN-Transceiver TJA1050T (0,821€) kostet bei Farnell nur die Hälfte vom MAX1482 (1,63€). Und ein AVR mit CAN kostet 3,60€ (ATMEGA16M1-AU).
The S. schrieb: > Abgesehen von ein paar einzelnen ICs / Controllern für ein paar Euro das > stück, finde ich nur große Bausteine für mindestens 30 Euro. Verstehe ich auch nicht. Wie hast du denn da gesucht? Ein PIC18F25K83 kostet ~2€ (Einzelstück), bei 100 dann nur noch 1,50 Transceiver bei Hundert, wohl so ~50ct. OK, der 18F hat nur 4 Hardware PWM. Wenn man bei MAPS sucht, CAN und 6*PWM auswählt, dann kommen da 202 Treffer. Schränkt man das auf möglichst wenig Pins (z.B 32) ein, dann bleiben noch 24. Die kann man auch nach Preis sortieren...
The S. schrieb: > wenn ich alle 10cm ein Modul einsetze Dann brauchst du kein fettes Bussystem, wie CAN RS485 usw. WLAN ist sowieso bei der Anzahl aus dem Rennen. Die meisten Haushalts Router können maximal 32 Geräte. Ein Tokenpassing System auf TTL Level ist voll ausreichend. Nahezu jeder (alle?) ATMega hat eine UART on Board. Jeweils Tx zum rechten Partner, an Rx, und fertig ist der Ring. Adressierung, kann man machen, ergibt sich aber auch schon aus der Position.
Arduino F. schrieb: > Ein Tokenpassing System auf TTL Level ist voll ausreichend. > Nahezu jeder (alle?) ATMega hat eine UART on Board. > Jeweils Tx zum rechten Partner, an Rx, und fertig ist der Ring. Kann man machen wenn die Datenrate ausreicht. Mit Tokenpassing hat das allerdings gar nichts zu tun.
avr schrieb: > Kann man machen wenn die Datenrate ausreicht. Mit Tokenpassing hat das > allerdings gar nichts zu tun. Nunja... Will man wirklich Adressen vergeben, Geräte einzeln ansprechen, Rückmeldungen auswerten, usw. dann ist man schon fast bei einem Tokenpassing System angekommen.
Arduino F. schrieb: > Dann brauchst du kein fettes Bussystem, wie CAN... Also ich finde CAN recht schlank ;-) Nimmt mir einen Haufen lästiger Arbeit ab!
Volker S. schrieb: > Nimmt mir einen Haufen lästiger Arbeit ab! Glaube ich dir.... Habe ja auch nichts grundsätzlich gegen CAN. Halte es nur nicht für das Optimum, für dieses Problem. The S. schrieb: > dann sind 160 Module im Einsatz. Habe noch keinen CAN Bus mit 160 Teilnehmern laufen sehen. Sehe da Probleme leuchten, kann mich aber irren. Außerdem dürfte das erheblich teurer werden als 160 * 10cm Schaltdraht.
Falk B. schrieb: > and we have developed our own DLL > which in turn interfaces with the D2XX DLL from FTDI. This threaded DLL > includes Open, Close, Read, Write & Status functions and will make it > quick and easy for customers So ein crap. Ein CAN Controller Treiber hat sich gefälligst als Netzwerkschnittstelle anzumelden so daß man es in /etc/network/interfaces konfigurieren und die normale Socket CAN API benutzen kann wie jeder andere CAN controller unter diesem Himmel es auch tut.
Arduino F. schrieb: > Habe ja auch nichts grundsätzlich gegen CAN. > Halte es nur nicht für das Optimum, für dieses Problem. Ich denke es wäre sehr einfach umsetzbar, aber da ich mich nicht mit allen Alternativen auskenne, kann ich auch nicht sagen, ob es das Optimum ist. Arduino F. schrieb: > The S. schrieb: >> dann sind 160 Module im Einsatz. > Habe noch keinen CAN Bus mit 160 Teilnehmern laufen sehen. > Sehe da Probleme leuchten, kann mich aber irren. Die Teilnehmer wären ja mehr oder weniger passiv, wenn eigentlich immer nur der ein und selbe sendet.
Arduino F. schrieb: > Nunja... > > Will man wirklich Adressen vergeben, Geräte einzeln ansprechen, > Rückmeldungen auswerten, usw. dann ist man schon fast bei einem > Tokenpassing System angekommen. auch nunja, aber beim Tokenpassing geht es um die Verwaltung von Multimaster-Systemen. Und das "schon fast" lasse ich hier nicht gelten, denn eine sichere Multimaster-Steuerung ist nicht trivial. Beim Ring geht es erst einmal um die Topologie des Busses und man kann den Datenverkehr ohne weiteres als Master-Slave-System mit nur einem Master organisieren.
Dietrich L. schrieb: > auch nunja, Genau! Bisher wurde in diesem Thread noch kein solches "Ring" System in den Raum geworfen. Weiter verteidigen will ich es nicht. Was der TE daraus macht, soll nicht mein Problem sein. Und wenn dich das Wort Tokenpassing so sehr stört, dann ignoriere es doch bitte. Aber wenn jemand anders das Wort Tokenpassing noch nicht kennt, dann sollte er mal bei Google rein klappern. Vielleicht hilfts ja dabei, das Denken zu ändern. Dietrich L. schrieb: > Beim Ring geht es erst einmal um die Topologie des Busses Und wenn du schon so pingelig bist, dann sage bitte nicht Bus zu einem Ring. Denn das ist kein Bus.
Volker S. schrieb: > Also ich finde CAN recht schlank ;-) > Nimmt mir einen Haufen lästiger Arbeit ab! Insbesondere sehr viel Programmierarbeit, wenn man noch nicht so vertraut mit Busprotokollen ist. Man kann auf CAN auch höhere Protokolle aufsetzen, aber der Clou ist, man muß es nicht. CAN läuft auch bare metal schon stabil und zuverlässig, was auf jegliche UART-Spielereien erstmal nicht zutrifft. Ohne ein Protokoll ist man bei der UART erschossen.
Arduino F. schrieb: > Bisher wurde in diesem Thread noch kein solches "Ring" System in den > Raum geworfen. Weiter verteidigen will ich es nicht. Das ist auch gut so und durchaus eine sinnvolle Idee. > Dietrich L. schrieb: >> Beim Ring geht es erst einmal um die Topologie des Busses > Und wenn du schon so pingelig bist, dann sage bitte nicht Bus zu einem > Ring. > Denn das ist kein Bus. Physikalisch nicht, aber logisch schon: jeder kann mit jedem reden. Ob das dann allerdings "logischer Bus" genannt werden kann weiß ich nicht :-( Insofern gebe ich dir recht ;-)
Hallo, Bei 160 Knoten fällt der Preis pro Knoten schon deutlich ins Gewicht. Deshalb sollten diese einfach/billig sein. CAN hat zwar seine Vorzüge, die aber hier m.E.n. gar nicht genutzt werden. Es gibt doch nur einen Master, der die Kommunikation steuert. Und ein Slave antwortet nur auf Befehl des Masters --> keine Multimaster-Fähigkeit nötig. Bei dem Anwendungsfall ist eine Rückantwort auch nur selten nötig. Das eigentliche Problem ist doch eher ein physikalisches: 160 Knoten die als Last am Bus hängen. Eine UART-Daisy-Chain von jeweils Tx->Rx ist wahrscheinlich zu langsam, selbst bei 460800 baud braucht ein Byte (10bit) 22µs + Verarbeitungszeit für den Kontroller. Bei 30µs würde der letzte Knoten die Daten erst nach ca. 5ms bekommen. Aber warum sollte dass Signal erst durch den µC? Einfach ein Gatter zum nächsten Knoten und Abgriff zum µC. Wäre dann wie MIDI. Protokoll ganz einfach: Adresse, Daten, CRC Die Antwort des Slave könnte genauso zurück laufen. Oder noch primitiver über ein Gatter auf ein wired-And Bus, der mit deutlich niedriger Baudrate fährt. BG, Tom
The S. schrieb: > Die WS2812 sind nur RGB, weitere ähnliche LEDs sind mir bisher nicht > bekannt. > Da es eine einzelne 3 Chip LED ist, wird hier die Lichtausbeute wohl > deutlich unter der von 6 autarken 3 Chip LEDs liegen. Es gibt den Controller darin auch einzeln als WS2811. Die 3 Ausgänge kann man für die Ansteuerung beliebiger LEDs in beliebiger Helligkeit verwenden. Für 6 verschiedene LEDs bräuchtest du eben 2 Stück WS2811. > Mein aktuelles Zimmer ist 16qm groß, und hat einen gesamt Umfang von 16 > Metern, wenn ich alle 10cm ein Modul einsetze um im Raum eine > Flächendeckende, ausreichend starke Beleuchtung zu gewährleisten, dann > sind 160 Module im Einsatz. Mit den WS2811 bräuchtest du dann nur jeweils 10cm Datenverbindung von einem Modul zum nächsten. Da jeder nur bis zum nächsten sendet, ist sie weniger störanfällig als ein langer Bus für alle.
:
Bearbeitet durch User
Tom schrieb: > Aber warum sollte dass Signal erst durch den µC? Das hat den Vorteil, dass es prinzipbedingt keine Buskollision gibt, mit dem Nachteil der Latenz, die natürlich mindestens ein Frame beträgt. Außerdem wird die Hardware einfacher und günstiger. 1 MBaud kann übrigens so ziemlich jeder µC. Ein STM32F0 kann bis zu 6 MBaud, da sieht die Sache gleich schon ganz anders aus. Arduino F. schrieb: > Und wenn dich das Wort Tokenpassing so sehr stört, dann ignoriere es > doch bitte. Wenn man über die Topologie spricht (wie schon angemerkt), dann ist das Wort fehl am Platz. Nimm das nicht persönlich - es geht mir nicht um dich, sondern um andere Personen, die dabei etwas Lernen könnten was so nicht stimmt.
@AVR: Warum sollte es Buskollisionen geben in dem System? Master->Slave:geht HW technisch gar nicht. Slave ->Master: Der Slave hat zu schweigen, bis er gefragt wird. Bei dem Anwendungsfall sollte das reichen. Natürlich kann man die Kette schneller fahren, aber: - für den Rückkanal bräuchte man aber eine 2.UART (d.h. ein zweites Rx/Tx Paar). Es sei den man hat wirklich einen Ring - Ok, haut im Zimmer hin, aber was ist wenn man mal Abstiche haben will. Reine Ringtopologie wäre mir persönlich zu restriktiv. - jeder Knoten muss alle Pakete weiterleiten. Hängt der µC nicht dazwischen, dann kann er sich nach der Adresse ausklinken und auf die nächste Nachricht warten bzw. etwas sinnvolles machen (PWM ohne HW-Timer z.B.). Eine neue Nachricht kann z.B. durch Break oder Parity Fehler von der HW allein erkannt werden. Naja, wie gesagt bei 160 Knoten würde ich alles so günstig machen wollen wie möglich, also auch PWM mit GPIO und keinen µC mit 6PWM Kanälen. -> STM32F030F4P6 BG, Tom
:
Bearbeitet durch User
Ok, eine Sache die eine UART-Daisy-Chain erlauben würde ist die Adressierung der Knoten durch ihre Position in der Kette. Wenn man das braucht... Erzwingt natürlich wieder ein Ketten- bzw. Ringtopologie. Auf jeden Fall Viel Spaß beim Basteln :)
Jobst Q. schrieb: > Es gibt den Controller darin auch einzeln als WS2811. Das ist noch nicht alles. Da man in Asien bunte Lichter liebt, gibt es gefühlt tausend fertige Sachen. Mal bei Aliexpress nach RGB oder RGBW suchen. Da kommen dann neben den WS281x auch APA102 oder SK68xx, zum Teil mit SPI. Da bekommt man richtig Geschwindigkeit in die Ansteuerung. Auch Module mit mehreren LEDs pro Farbe für 12 oder 24V Betrieb findet man. Mit einer Neuentwicklung lässt sich nichts mehr gewinnen. > In contrast to the SK6812 used in some of our other similar LED strips, > which use a specialized one-wire control interface and require strict > timing, the SK9822 uses a standard SPI interface for control (with > separate data and clock signals) and has no specific timing requirements, > making it much easier to control Das stammt von hier https://www.pololu.com/product/3090 die Doku ist bei den Amis besser, die Preise eher in China MfG Klaus
Thomas H. schrieb: > Warum sollte es Buskollisionen geben in dem System? > Master->Slave:geht HW technisch gar nicht. > Slave ->Master: Der Slave hat zu schweigen, bis er gefragt wird. > Bei dem Anwendungsfall sollte das reichen. Ich sagte prinzipbedingt. OneWire funktioniert auch ohne Kollision, aber nur bei fehlerhafter Software kann es auch Kollisionen geben. Bei dem Ring muss man sich darüber keine Gedanken machen, da logisch jeder µC eine direkte Verbindung zum nächsten hat. > Natürlich kann man die Kette schneller fahren, aber: > - für den Rückkanal bräuchte man aber eine 2.UART (d.h. ein zweites > Rx/Tx Paar). Es sei den man hat wirklich einen Ring - Ok, haut im Zimmer > hin, aber was ist wenn man mal Abstiche haben will. Reine Ringtopologie > wäre mir persönlich zu restriktiv. Man kann den Ring auch zurückführen, mit ein paar Buffer dazwischen. Du vergisst hier, dass die Lösung als Ring erstmal eine Leitung weniger benötigt. > - jeder Knoten muss alle Pakete weiterleiten. Hängt der µC nicht > dazwischen, dann kann er sich nach der Adresse ausklinken Mit DMA kein Problem. Ich sehe den großen Vorteils des Rings erstmal in dem Reduzierten HW-Aufwands. Man braucht keine extra Buffer, die Adressierung ist einfach und die Software ebenso, da es Punkt-zu-Punkt-Verbindungen sind.
Vielen Dank für die weiteren sehr ausführlichen und hilfreichen Antworten. Peter D. schrieb: > Auch gewinnt man dabei nichts, da trotzdem der Master immer erstmal > einem Slave sagen muß, wann er auf Senden umschalten darf. > Man treibt also einen doppelt hohen Aufwand an Verkabelung und hat davon > keinerlei Nutzen. Ok, dann werde ich den Plant mit den MAX1482 und voll duplex verwerfen und stattdessen mit den MAX1483 arbeiten, 100 Stück gibt es hier für 11 Dollar bei Aliexpress. Arduino F. schrieb: > Ein Tokenpassing System auf TTL Level ist voll ausreichend. > Nahezu jeder (alle?) ATMega hat eine UART on Board. > Jeweils Tx zum rechten Partner, an Rx, und fertig ist der Ring. Ein sauberer Ring ist die fertige Installation (so wie ich sie mir vorstelle) leider auch nicht. Oder stört es bei dieser Variante nicht, wenn dann auch mal zwei Meter zwischen zwei Modulen liegt? (Arbeitslicht von Deckennähe herunter geführt) Tom schrieb: > Eine UART-Daisy-Chain von jeweils Tx->Rx ist wahrscheinlich zu langsam, > selbst bei 460800 baud braucht ein Byte (10bit) 22µs + Verarbeitungszeit > für den Kontroller. Bei 30µs würde der letzte Knoten die Daten erst nach > ca. 5ms bekommen. Aber warum sollte dass Signal erst durch den µC? > Einfach ein Gatter zum nächsten Knoten und Abgriff zum µC. Wäre dann wie > MIDI. > Protokoll ganz einfach: Adresse, Daten, CRC > Die Antwort des Slave könnte genauso zurück laufen. Oder noch primitiver > über ein Gatter auf ein wired-And Bus, der mit deutlich niedriger > Baudrate fährt. Ein interessanter Ansatz, 5ms Verzögerung könnte sogar tatsächlich ausreichend sein, weniger ist natürlich dennoch schön :D Jobst Q. schrieb: > Mit den WS2811 bräuchtest du dann nur jeweils 10cm Datenverbindung von > einem Modul zum nächsten. Da jeder nur bis zum nächsten sendet, ist sie > weniger störanfällig als ein langer Bus für alle. Ich sehe hier eine Einschränkung in der Versorgung. Da es ja 3 Chip LEDs in 6 "Farben" sind. Also insgesamt 18 LEDs die versorgt werden wollen, jedoch effektiv 6 Kanäle die gesteuert werden müssen. Lässt sich hier etwas mit MOSFETS machen? Dann könnte schon ein kleiner ATMEGA48PA-AU ausreichen, oder ist der dann bei 6 PWM Kanälen zu langsam / ungenau? Wenn ich es richtig verstanden habe, lässt sich theoretisch jeder I/O Pin via Software zum PWM Signalgeber "umbauen", der dann CPU Takt gebunden eine entsprechende Frequenz erreicht? Eine Sache ist mir erst in der Nacht klar geworden, über die Stromversorgung habe ich mir bisher keine Gedanken gemacht. Zunächst hatte ich geplant alles mit 5V zu betreiben (Hier wären dann die 3 Chip LEDs intern Parallel geschaltet worden) doch mit der Lösung über einen Vorwiderstand würde hier pro Modul alleine für die LED Versorgung maximal 1,8 Watt anfallen. Nach längerer Überlegung bin ich dann zum Schluss gekommen, die 3 Chip LEDs jeweils so zu verleiten, dass sie in Reihe geschaltet sind. Somit kommen die LEDs auf eine Durchlassspannung von 6,0V respektive 9,6V. Mit einem PC Netzteil lässt sich nun mittels 12V, 7V und 5V alles mit hoher Effizienz versorgen. (12V und 7V für die LEDs, 5V für MCUs) So erhalte ich bei selber Lichtleistung einen Energiebedarf von 1,24W für die LED Versorgung pro Modul. Nun stellt sich mir jedoch die Frage, ob ein solches NT mit einem Negativen Stromfluss auf der 5V Schiene gut zurecht kommt, oder ob es hier zu Problemen kommen kann. Mit freundlichen Grüßen Marcel
Jemand hat vor ein paar Jahren mal was gepostet über einen Ring bei dem über jeweils ein Relais pro Slave der Ausgang entweder direkt an den Eingang geschaltet war oder wenn das Relais anzog war der Ausgang an den UART TX des Slave geschaltet, der hat da irgendeine Mimik die in einer Reihe nebeneinander stehender Schränke eingebaut war angesteuert wenn ich mich recht erinnere. das müsste sich auch statt Relais mit einen einzigen und-Gatter pro Slave machen lassen, ungefähr so:
1 | RX TX Master |
2 | | | |
3 | O O |
4 | | | |
5 | | |_____________RX |
6 | | | |
7 | | | ___________TX |
8 | | | | |
9 | | ----- |
10 | | | & | |
11 | | ----- |
12 | | | |
13 | | | |
14 | | | |
15 | | | |
16 | O O |
17 | | | |
18 | | |_____________RX |
19 | | | |
20 | | | ___________TX |
21 | | | | |
22 | | ----- |
23 | | | & | |
24 | | ----- |
25 | | | |
26 | | | |
27 | | | |
28 | | | |
29 | O O |
30 | | | |
31 | | |_____________RX |
32 | | | |
33 | | | ___________TX |
34 | | | | |
35 | | ----- |
36 | | | & | |
37 | | ----- |
38 | | | |
39 | | | |
40 | | | |
41 | | | |
42 | O O |
43 | | | |
44 | | |_____________RX |
45 | | | |
46 | | | ___________TX |
47 | | | | |
48 | | ----- |
49 | | | & | |
50 | | ----- |
51 | | | |
52 | | | |
53 | | | |
54 | | | |
55 | O O |
56 | |___| |
Aber mit Relais hätte es den Vorteil daß ein Slave komplett abrauchen könnte und der TX dennoch weiterhin durchgeschleift wäre. Protokollmässig kann man das dann so behandeln als wäre es RS485, jeder Slave hat eine Adresse und antwortet nur wenn er gefragt wird.
:
Bearbeitet durch User
Bernd K. schrieb: > das müsste sich auch statt Relais mit einen einzigen und-Gatter pro Interessante Idee, jedoch vermutlich tatsächlich teurer, als mit MAX1483 von Aliexpress. Mein aktueller Schaltplan wurde von mir mal an gehangen. Gibt es hier irgendwelche groben Schnitzer? Hat jemand eventuell noch einen Tipp? Der ATmega ist nicht als absolut fest eingeplant, sondern soll nur ein funktionierender Platzhalter sein. PWM werde ich wohl nun via Software lösen, da hier dann kleinere MCUs eingesetzt werden können. Insgesamt fallen über den LEDs "RED" und "AMBER" 6V und über den restlichen jeweils 9,6V ab. Die Transistoren habe ich mit einer Usat von 0,7V eingerechnet, da ich hier noch keine konkretes Bauteil gefunden habe. Mir wird mittlerweile klar, dass ich den Titel anders hätte wählen sollen, dann wäre ich vermutlich schneller zu einem brauchbaren Ergebnis gekommen. Ich hoffe, dass mir kurz vor der Zielgeraden noch geholfen werden kann, auch wenn es schon längst nichts mehr mit der eigentlichen Frage zu tun hat. Doch extra einen neuen Beitrag zu eröffnen, erscheint mir etwas zu viel des Guten, da hier ja nun alle Informationen vorliegen. Hierfür möchte ich mich entschuldigen. Mit freundlichen Grüßen Marcel
Du vermischt in diesem Thread ziemlich viele Einzelprobleme, weshalb dieser nun schon ziemlich unübersichtlich ist. Wenn ich das richtig sehe, dann hast du dich für RS485 entschieden. Ist auch meine Wahl. Ich nehme den MAX3072 auch deswegen, weil ich meinen uC (EFM32GGxxx) mit 3,3V versorge. Ebenfalls slew rate limited und 1/8 load. Den Aufwand für das Protokoll solltest du aber nicht unterschätzen. Ich hab das für mich mit Gruppenbildung und hot plugging spezifiziert und zu einem größeren Teil auch schon implementiert. Sowohl am uC als auch für einen rudimentären PC Tracer. Deshalb kann ich dir auch sagen, dass ist ein ziemlicher Aufwand. Wenn du das ernsthaft weiterverfolgen willst, würde ich dir raten die Teile getrennt zu diskutieren. Und beschäftige dich nacheinander mit den einzelnen Teilen. Also nicht PWM Steuerung von LEDs mit Bustyp und Protokoll in einem Thread. Denk auch über mögliche Abstriche bei den Anforderungen nach. Z.B. brauchst du wirklich hot plugging mit automatischer Adressvergabe? Die Abritrierung erfolgt bei mir indirekt über eine vorher einprogrammierte einzigartige MAC Adresse und bewusst in Kauf genommener eventueller (Verzögerungs- und Verarbeitungszeit abhängig) Buskollisionen. Ich mach das. Aber überlege ob du dir den Aufwand nicht doch sparen willst. Könnte sonst leicht zu einem Monsterprojekt ausarten, welches nie fertig wird. Ich weiß wovon ich rede :-)
Andi B. schrieb: > Deshalb kann ich dir auch sagen, dass ist > ein ziemlicher Aufwand. Das ist auch meine Erfahrung, Protokolle werden oft unterschätzt. Daher meine Empfehlung zu CAN, auch wenn die MCs mit CAN einige Cent teurer sein mögen. Es gibt neben AVRs auch günstige PIC18 mit CAN.
Peter D. schrieb: > Protokolle werden oft unterschätzt ... weil viele erstmal nur den "Gut"-Fall betrachten. Im Fehlerfall - Störungen auf der Leitung - Unterbrechung der Leitung - Ausfall eines Teilnehmers - Kollision auf dem Bus - Dauersenden eines Teilnehmers - ??? kann es kompliziert werden, besonders dann, wenn ein Fehler u.U. nicht erkannt wird und zu ungewollten und kritischen Aktionen führt.
Ich würde hier auf ein Tranceiver Baustein verzichten, und es z.B. mit einem Tiny20 machen. 6x pwm + i2c slave sowie 2x i2c master in SW.
chris schrieb: > Ich würde hier auf ein Tranceiver Baustein verzichten, und es z.B. mit > einem Wenn schon integrierter Transceiver, dann gleich das störsichere CAN statt dem störempfindlichen I²C: Peter D. schrieb: > Gibbet aber auch onchip: > LPC11C12FBD48/301
Integrierten Can Tranceiver, nur LPC11C22, also 2,68 € gegen 0,394 € , bei 250 Schaltungen ist die Differenz genau 571,5 € . Und i2c bei diesen kurzen Strecken, nur point to point, master push pull, die Fehleranfalligkeit ist sehr gering, aber jedem das Seine.
chris schrieb: > Und i2c bei diesen kurzen Strecken, nur point to point, master push > pull, > die Fehleranfalligkeit ist sehr gering, aber jedem das Seine. I²C auf 25m mit 50kByte/s (--> >> 500kBit)? Das meinst du aber nicht ernst.
Ich meinte auf keinem Falle ein shared I2C bus für alle Nodes, sondern ein point to point i2c bus, ein master, ein slave ! Wenn im Anfangspost bei noch ungewisser Architektur 25mt bus für eine Deckenbeleuchtung steht, bei 250 clients sind warscheinlich 10cm Abstand von einem Node zum nächsten gemeint. Kann mich irren, ich lese es so aber raus. Mfg Chris
Peter D. schrieb: > Das ist auch meine Erfahrung, Protokolle werden oft unterschätzt. > Daher meine Empfehlung zu CAN, auch wenn die MCs mit CAN einige Cent > teurer sein mögen. > Es gibt neben AVRs auch günstige PIC18 mit CAN. Als Student sitzt der Geldbeutel nicht ganz so locker, bei ein paar wenigen macht es kaum was aus, doch bei geplanten >160 summiert sich da schon was hübsches auf. Bei der Lösung über einen externen MAX1483 habe ich kosten von ca. 10 Ct. pro Knoten. Bei dieser Lösung kann zudem der MCU stark beschnitten ausfallen. Hardware PWM wäre zwar schön, doch über Software lässt sich das ganze auch noch steuern. Wenn nun ein entsprechender MCU mit CAN bei einem relativen Aufpreis von unter 10 Ct. liegt, wäre ich geneigt mir diese noch mal etwas genauer an zu schauen. Das soll jetzt keines Wegs abwertend klingen, auch wenn es den Eindruck erwecken könnte. Ich möchte halt mit diesem Projekt so viel wie Möglich lernen, was mir später einmal von nutzen sein kann. Da sehe ich ein zusammen basteln nach "Baukasten" nicht als erstrebenswert an. CAN mag mir einiges an Arbeit abnehmen, doch denke ich, dass ich bei einem RS485 BUS zwar ordentlich aufs Maul bekommen, doch auch am meisten lernen kann. So muss ich mich um alles selbst kümmern, somit wird sich jeder Fehler Sofort bemerkbar machen, hieraus kann ich dann versuchen möglichst viel Wissen zu generieren. (Natürlich in der Hoffnung, dass ich nicht vor Frust alles an die Wand schmeiße) ;) chris schrieb: > Wenn im Anfangspost bei noch ungewisser Architektur 25mt bus für eine > Deckenbeleuchtung steht, bei 250 clients sind warscheinlich 10cm Abstand > von > einem Node zum nächsten gemeint. Kann mich irren, ich lese es so aber > raus. Nein, du irrst nicht. Im Mittel wird es wohl auf ca. 10cm pro Node heraus laufen. Doch möchte ich die Möglichkeit haben, auch mal zwischen zwei Nodes um die zwei Meter zu haben. Um so z.B. Arbeitslicht ebenfalls über einen Master steuern zu können. Spart im Endeffekt dann wieder ein bisschen was, wenn der gesamte Raum nur einen Master benötigt. Die geschätzt zwei Meter entstehen halt dadurch, dass ich den BUS und die Versorgung von Deckennähe zu mir herab hole, dann ein Array aus ein paar sehr kurz verbundenen Nodes Bilde und die Kabel dann wieder Richtung Decke die allgemeine Raumbeleuchtung weiter Versorgen lasse. So kommt tatsächlich annähernd eine Ringtopologie zu Stande. Jedoch habe ich keine Erfahrungen wie es sich mit den Latenzen verhält. (bei maximal Ausbau wären dann 250 Hops für einen Umlauf von Nöten) Andi B. schrieb: > Wenn du das ernsthaft weiterverfolgen willst, würde ich dir raten die > Teile getrennt zu diskutieren. Und beschäftige dich nacheinander mit den > einzelnen Teilen. Also nicht PWM Steuerung von LEDs mit Bustyp und > Protokoll in einem Thread. Also stellt es hier kein Problem dar, wenn man verschiedene Teile eines Projekts in spezialisierten Beiträgen einzeln ausdiskutiert? Leider habe ich bisher in Foren die Erfahrung gemacht, dass alles was Ansatzwiese mit dem Thema zu tun hat gefälligst in einem Thread zu stehen hat. Derzeit habe ich noch zu ein paar Punkten offene Fragen, die ich dann ggf. in einzelnen Themen behandeln werde, damit es hier noch möglichst übersichtlich bleibt. Sollte ich in den Themen, die ich in Zusammenhang mit diesem Projekt erstelle die jeweils anderen Themen Verlinken, oder einfach nur bei Bedarf entsprechende Informationen zwischen diesen austauschen? An sich benötige ich eine Kommunikation die folgende Eigenschaften erfüllt: 1. Relativ störsicher. 2. Hohe Datenrate. 3. Niedrige Latenz. 4. Günstig. 5. Nachrichtenzuweisung. Hier hatte ich halt in erster Linie an einen klassischen BUS mit Adressierung gedacht. Ich bedanke mich auch weiterhin für diese wirklich freundliche und sachkundige Hilfe bei meinen Fragen. Mit freundlichen Grüßen Marcel
The S. schrieb: > So muss ich mich um alles selbst kümmern, somit wird sich jeder Fehler > Sofort bemerkbar machen In der Praxis ist es aber nicht so einfach. Gerade Kommunikationsprobleme treten selten sofort auf. Und wenn dann der Bus alle Stunde abkackt, muß man erstmal den Teilnehmer finden, der es verursacht hat. UART-Protokolle werden gerne als Text aufgebaut. Das kostet zwar Datenrate, aber man kann es mit einem PC mitloggen, in eine Datei schreiben und dann später analysieren. Binärprotokolle sind nicht direkt lesbar, insbesondere bei Fehlern.
Wenn dir 245 Adressen genügen würden, wäre Modbus eine plug and play Möglichkeit. Tiny414 (0.394 € Mouser) mit HW rs232, driver 1/8 load unit (z.B. ISL81487IBZ-T 0.494 €) .
Hi, Also ich würde mich mittlerweile dem Vorschlag von AVR anschließen: - die TXD-RXD-Verkettung kostet keine zusätzliche HW --> Die Knoten können sehr günstig sein (µC + LED) aliexpress 10 Stück STM32F030F4P6 < 5€ - Adressierung nach ID und Position ist möglich - Entnahme, Zufügen von Knoten dadurch problemlos möglich - Buskollisionen kann es prinzipbedingt nicht geben --> sehr einfaches Master/Slave Protokoll möglich - Man könnte sogar etwas Vergleichbares wie beim WS8212 basteln: Jeder Knoten knabbert etwas von einem Bytestring ab und gibt nur den Rest weiter --> eine lange Nachricht, die alle Knoten ansteuert - die Durchlaufzeit ist für den Anwendungsfall bei hoher Übertragungsrate zu vernachlässigen - Die kurzen Abstände zwischen den Knoten erlauben eine hohe Baudrate ohne Mehraufwand an Treiber etc. - Wenn ein Knoten spinnt, sieht man an der LED Reaktion sofort bis wohin die Kette funktioniert Wenn der Tag 48h hätte, könnte man sich so etwas glatt auch mal basteln ;). BG, Tom
Thomas H. schrieb: > --> Die Knoten können sehr günstig sein (µC + LED) aliexpress 10 Stück > STM32F030F4P6 < 5€ > Wenn der Tag 48h hätte, könnte man sich so etwas glatt auch mal basteln > ;). > > BG, Tom Das hört sich tatsächlich nicht ganz so verkehrt an, auch wenn ich mir dann mit der Spannungsversorgung Gedanken machen muss, hatte eigentlich geplant ein PC Netzteil zu nutzen. Doch der STM verträgt ja keine 5V ^^ Laut Datenblatt, http://www.st.com/content/ccc/resource/technical/document/datasheet/a4/5d/0b/0e/87/c4/4d/71/DM00088500.pdf/files/DM00088500.pdf/jcr:content/translations/en.DM00088500.pdf verfügt der Controller zwar über 6 PWM, doch wenn ich es richtig verstehe, kann er nur 4 unabhängige Channel erzeugen, oder gilt das nur für den TIM1 und über den Link mit den weiteren speziellen Timern, kommen so 6 unabhängige PWM Channel zu Stande? Der Preis ist natürlich ansehnlich, Steuerung und Kommunikation wäre hier dann 50 Ct. + eventuelle Spannungsanpassung. Auf der andern Seite hätte ich bei RS485 ich 10 Ct. Kommunikation + Steuerung. 48h Tage, kann ich aber auch nur aktuell abreißen ^^. Peter D. schrieb: > In der Praxis ist es aber nicht so einfach. Gerade > Kommunikationsprobleme treten selten sofort auf. Und wenn dann der Bus > alle Stunde abkackt, muß man erstmal den Teilnehmer finden, der es > verursacht hat. Liegt darin nicht erst der Spaß? Wenn scheinbar alles läuft und plötzlich alles "brennt", dann den Fehler zu suchen, finden und zu beseitigen sehe ich als zufriedenstellende Aufgabe an. (Natürlich nicht als Ziel) Mit freundlichen Grüßen Marcel
Hi Marcel, Ja, du hast Recht. Ich bekomme auch nur 4 Kanäle zusammen. Aber ich dachte, dass es für solche Lichtsteuerungssachen reicht, einfach die GPIOs direkt anzusteuern. Leider geht bei den einfachen Teilen die Ansteuerung der GPIO-Ports über DMA nicht. Also hätte ich nach einem neuen Lichtbefehl die PWM Signale als zb. 100 32bit Werte vor berechnet und dann timergesteuert an das GPIO-BSRR ausgegeben. SW-DMA sozusagen. PWM-Frequenzen von 10kHz sollte ausreichen und sich damit problemlos herstellen lassen. (Vorsicht nur gefühlt, nicht gerechnet oder probiert ;) ). Ja, die 5V sind natürlich ein Problem. Also entweder Regler oder schauen, ob man doch lieber einen z.B. ATTiny nimmt (gibts auch günstig bei aliexprees). Ob es dort mit PWM-Kanälen oder GPIO geht - keine Ahnung. BG, Tom
Ich bedanke mich für alle Antworten und werde nun ein kurzes Resume aus den Beiträgen ziehen: Zur Auswahl stehen im Prinzip drei Möglichkeiten. 1. Möglichkeit CAN Vorteile: Sehr einfach Sehr störungssicher Hohe Datenraten möglich Nachteile: Relativ Teuer Die 250 Teilnehmer lassen sich nur über die Message ID Addressieren. (Beim 2. Punkt bin ich mir nicht ganz sicher) 2. Möglichkeit direkte UART Verbindungen. Vorteile: Sehr günstig Sehr einfach Einfaches DMX ähnliches Protokoll möglich Relativ störungssicher Adressierung erfolgt automatisch durch Position in der Kette. Nachteile: Zunehmende Latenz, je weiter der Client weg ist. Nur realtiv Kurze Verbindungen zwischen den jeweiligen Modulen möglich. Rückkanal nur bei geschlossenem Ring möglich. 3. Möglichkeit RS485 via MAX1483 Vorteile: Keine Latenzvariation Relativ hohe Datenraten Sehr große Strecken möglich Nachteile: Kompliziertes Protokoll Relativ störanfällig Sollte ich hier etwas vergessen haben, gerne einfach Antworten und ich werde es dann entsprechend aufnehmen. Damit möchte ich dieses Thema hier auch beenden, da wohl nicht mehr all zu viel dazu kommt. In einem weiteren getrennten Thema werde ich mich dann mit der Hilfe des Forums genau mit der LED Steuerung und deren Versorgung befassen um anschließend den dazu passenden Controller mit seinen Fähigkeiten zu nutzen um den für diesen Controller besten BUS zu wählen. Zum Schluss möchte ich mich noch mal für alle Hilfreichen Antworten und eure Geduld bedanken. Mit freundlichen Grüßen Marcel
>Zur Auswahl stehen im Prinzip drei Möglichkeiten. eigentlich nicht, da die "drei" Möglichkeiten eher eine zufällige 'Zählung' sind. Ein kompliziertes Protokoll lässt sich beispielsweise praktisch immer implementieren sofern man nicht aufpasst und versehentlich ein fertiges 'unkompliziertes' nimmt und RS485 via MAX1483 funktioniert auch mit unkomplizierten Protokollen. Vom Prinzip haben wir eine sehr sehr bunte Mischung aus im wesentlichen elektrischen bestimmten Eigenschaften und welchen die sich aus der Adressierung ergeben zusammen mit unkontrollierten zeitlichen Anforderungen beim CAN. Ich versuche mal ein paar strukturelle Eigenschaften anhand eines leicht modifizierten Schichtenmodells der OSI-Religion aus dem letzten Jahrtausend sehr sehr grob in Stichpunkten zu schildern (die einzelnen Schichten lassen sich nicht wirklich klar abgrenzen, deswegen mit +-5 Toleranz) OSI 1 (Spannungen): differenzielle Signale (zwei verdrillte Adern, RS485/CAN/DMX) erlauben lange Leitungen praktisch ohne Störungen; die letzten Millimeter vom Transceiver werden immer 'konventionell' bewältigt. Bei kurzen Entfernungen (direkte UART Verbindungen) reicht eine Leitung mit Massebezug. OSI 2 (Medien/Leitungszugriff): weiter unten ein Beispiel aus einer Praxis... OSI 3 (Adressierung/Link layer):DMX-artig ist die Adresse in der Position des Datenpakets kodiert, während die anderen Varianten jeweils die Adresse als Datum zusätzlich übertragen. Daisy-Chain (V2) kann bzw. könnte die Position in der Kette als Adresse verwenden, aber auch von 'Start' abzählen und eine 'freie'(nicht positionsgebundene) Adresse benutzen. An ganz vielen Stellen schleicht sich zu dem bekannten Wertebereich eines Bytes (0..255) noch ein weiterer Wert (start/brk o.ä.) um einen Anfang zu definieren. Wenn man daisy-chain mit 'freier' Adressierung auf 8-bit realisieren möchte müsste man bspw. einen Wert aus 0..255 für brk opfern. ((unkonventionell(nicht weiter geprüft): intern daisy-chain mit 9bit für "out-of-band" (Begriff für Informationen die nicht im eigentlichen jeweiligen{!}Datenstrom übertragen werden))) == kurze Zwischenbilanz == bei freier Leitung ohne Diskussionen: Gemeinsamkeiten M1..M3: - asynchron d.h. der Takt/Zeit wird nicht über die Leitung übertragen. Alle Beteiligten müssen auf einem anderen Weg für gleiche Zeiten sorgen (Hauptfehlerursache neben komplettem Ausfall wie Stecker vergessen o.ä.) Da die Länge bekannt ist wird doch etwas Zeitinformation mit übertragen und es gibt damit Möglichkeiten zum nachjustieren aber gedanklich und 'Normalbetrieb' ist asynchron (ohne Zeit) passender. - digitale Signale/keine Rauschstrecke d.h. sofern keine kritischen Daten übertragen werden (Steuerung Herzschrittmacher o.ä.) oder spezielle Ängste aus dem Internet mitübertragen werden müssen, lassen sich mit den Daten weltweit Lampen auf Bühnen (DMX) oder ähnliches steuern. - Datenrate hängt von Leitungen bzw. Transceivern, Zeit und den beteiligten µC ab RS485 MAX1483/DMX (elektrisch identisch) ("250kbps") ==> 25fps (ZimmerOS mit 160*6 LED ca. 1000; netto ohne Adressen) ISL81487: ("up to 5Mbps") ==> 500fps (8-bit µC könnten in dem Bereich disqualifiziert sein) Bei einem wirklich einfachen Programmmodell und Slaves die nicht regelmäßig die Bühne wechseln sondern zumindest im Betrieb an einer festen Position bleiben, ließe sich ohne Angst vor falschem leuchten selbst mit den MAX1483 eine Latenz 1/25 sek realisieren Zum Besuch in einer Praxis (OSI 2) Szene: du (Marcel:M) besuchst Peter (P) in der Praxis aus der er seinen Beitrag geschrieben hat und ein Master (MA; je nach Praxis Betreuer/Arzt/ o.ä.) 'leitet' die Kommunikation: == 1. Möglichkeit CAN == M:Nachricht_1; P:NACHRICHT_1 MA:NACHRICHT_1!!! -->MA sendet NACHRICHT_1!!!(MA) M:Nachricht_1; P:NACHRICHT_1 MA:NACHRICHT_2!!! -->MA sendet NACHRICHT_2!!!(MA) M:Nachricht_1; P:NACHRICHT_1 -->P sendet NACHRICHT_1(P) ... in der Praxis: "Geraffel" wer am lautesten schreit == 2. Möglichkeit direkte UART Verbindungen.== N_1(MA)==>M; N_1(M)==> P; N_1(P)==>MA (N1 vom P,M anfangs 'leer') N_2(MA)==>M; N_2(M)==> P; N_2(P)==>MA ... in der Praxis: multiprozess (zuhören/reden gleichzeitig) stille Post, ohne Implementierung der für das original Spiel wichtigen Fehler) == 3. Möglichkeit RS485 via MAX1483 == (kein festes Protokoll. Szene aus DMX-RDM mit Stammpatienten) MA:N_1 (Antworterlaubnis:1) ==>M M:N_1 MA:N_2 (A:0) ==>M MA:N_3 (A:0) ==>M MA:N_4 (A:1) ==>P P:N_1 ..... in der Praxis: sehr protokollarisch geprägte mündliche Prüfung mit mehreren Prüflingen oder Podiumsdiskussion ==> Kompliziert werden Protokolle für Möglichkeit 3 durch fehlende Signale die Anfang UND Richtung definieren (bsp. 256=brk;257=brk-Antwort) UND wenn flexible Datenmengen angefragt werden. Beim MAX1482 (getrennter Antwortbus)kein Problem solange die Antworten < Anfrage bleiben. Bei einem gemeinsamen Bus muss a) der Master genug Zeit für die Antwort lassen und b) die Antwort als solche erkennbar sein bsp. durch Adresse:Master Eine sehr unkompliziertes Protokoll ließe sich basteln wenn von der Anwendungsebene OSI 7-8 nicht alle 0..255 benötigt werden und ein Paket ==> slave mit brk=255 und umgekehrt mit brk=254 definiert werden kann. Grundsätzlich wird es schwierig falls Gerüchte aus einer Praxis über Vorlieben von UART-Protokollen ("werden gerne als Text aufgebaut") mit Protokollen außerhalb der betroffenen Praxis verwechselt werden. Am OSI-Modell lässt sich das grob nachvollziehen: Du (OSI 8/ Anwender) möchtest von deinem Sklaven (S)(bei Auskünften tw. Diener engl. 'server' genannt) den Zustand der aktuellen Helligkeit erfahren, dann könnt ihr auf OSI 7 ein einfaches Textprotokoll bsp. http installieren für das es sogar fertige Programme gibt. Dann könnt ihr euch auf OSI 7 mit M->S: GET /LED1 HTTP/1.1 S->M: HTTP/1.1 200 OK S->M: Content-Type: text/plain S->M: S->M: S->M: 42 unterhalten und du weißt => die LED leuchtet 42 - Anwender: glücklich - UART-Protokoll (falls beteiligt): Hä? (muss für http aber 7-bit Zeichen, für bestimmte Content-typen sogar 8-bit, übertragen können) - uC Slave: unglücklich, weil Texte interpretieren für µC relativ viel Arbeit macht. kurzes Zwischenergebnis: a) die Ausgaben die vermutlich durch Kollision mit einem CAN-Bus entstanden sind (neben den Vorlieben von UART-Protokollen waren auch besondere Leseschwierigkeiten bei Fehlern und - vorsichtig formuliert - 'spezielle' Problemklassifikationen in der Kollisionsausgabe) fallen eher in den Unterhaltungsbereich. Möglichkeit 1 ist für Menschen die mit dem CAN-Bus aufgewachsen sind oder einfach gerade einen da haben sicherlich praktisch, aber solche Faulheit erzeugt manchmal skurrile Fehler und kann Menschen aus einer Praxis berichten lassen die einfach keine konkreten Daten kennt. b) Anforderungen aus OSI 7 (http:7/8bit) müssen von allen(!) 'unteren' Schichten erfüllt werden, aber vom Prinzip ließe sich unser Textprotokoll http auch über das Internet benutzen sofern OSI 6.. das organisieren. c) wie schon weiter oben von 'unten' (OSI 1) vermutet kommen schnell Schichten durcheinander Für den Anwendungsfall LED ließe sich OSI 7 Binärprotokoll (Anwender Marcel kann Software zur Dekodierung entwickeln ==> keine Leseschwierigkeit insbesondere bei Fehlern) mit Bus-Protokoll OSI 1-3 als Gesamtpaket unter Umgehung von OSI 4-6 definieren. Dann stehen im Prinzip zwei Möglichkeiten für OSI 7 zur Auswahl: 1. Möglichkeit 8-bit Daten/ 256 mögliche Werte je Datum Helligkeit/Fehler/Adresse Vorteile: - Sehr einfach zu denken - kompatibel mit 8-bit Denkmustern Nachteile: - benötigt 8-bit Busprotokoll 2. Möglichkeit fast 8-bit Daten/ 255 mögliche Werte je Datum (u.a. Helligkeit/Fehler/Adresse) Vorteile: - erlaubt Busprotokolle die einen Wert für interne Zwecke benötigen Nachteile: - erzeugt Probleme beim 8-bit denken - u.a. nicht mit http (Content-Type:binary u.ä.)kompatibel für Möglichkeit 2 aus OSI 7 ergäben sich für OSI 2 +-1 (die geraffel Variante mit unkontrollierten Tn aus der CAN-Paxis gemuted) 2.1 Daisy-chain Vorteile: - 'volle' Bandbreite da kein Zeitfenster für Rückantwort benötigt wird - Fehler lokalisierbar (Rest fällt aus) Nachteile: - schwerer denkbar - Mehrbelastung µC - Rest fällt aus wenn ein Slave ausfällt - zus. Latenz von (je nach Geschwindigkeit) 0,01sek 2.2 physikalisch gemeinsamer Bus Gegenteil von 2.1 für alle Möglichkeiten die Adressierungsmöglichkeiten x.x.1 Möglichkeit DMX-artig Adressen durch Position im Datenpaket Vorteile: - hohe Datenbandbreite Nachteile: - könnte ein (real) einfaches Sofwaremodell erzwingen x.x.2 Adressierung je Datenpaket Vorteile: - erlaubt weniger Banbreitenstrafe bei komplizierten Softwaremodellen - vermutlich etwas einfacher für µC also grob 8 Möglichkeiten von denen nicht alle unkompliziert sind (bsp. 1.2.1 gäbe bei freien Adressen Chaos, aber 2.2.x oder 1.2.1. mit festen Adressen nicht) Ein kurzes Resumee: vom Prinzip wird die Nettodatenrate bei den aktuellen Möglichkeiten durch die µC und deren Programmierung limitiert (460 kbs sollte mit allen diskutierten µC möglich sein, allerdings mit teils sportlichen Kombinationen wg. Soft-PWM und einige bräuchten einen Quarz für einen langfristig praktisch störungsfreien Betrieb) Hauptprobleme dürften psychologischer Natur sein (der Verzicht auf einen Wert erzeugt bei einigen Programmierern merkwürdige Nebenwirkungen/ unsicheres Leuchten trotz aller Gefahren aus dem Internet/ LED mit Anzeigen haben die ohne PC/Smartphone zu erkennen ist/...) Vermutlich wäre Daisy-Chain die Leistungsfähige Variante auch wenn ich mich dabei erwische das abzulehnen (Gehirne funktionieren nicht wirklich digital); Gedanklich wäre evtl. DMX+RDM mit 500kbs (statt 250kbs) /960 Adressen (statt 512) und einer gedanklichen Trennung von Wartungsbetrieb (Slave können Fehlerspeicher melden/ Plug'n play spielen aber evtl. 0,1 sek Latenz haben) und Normalbetrieb (50fps) praktisch wie auf 'normalen' Bühnen mit DMX-RDM auch, ein sinnvoller Kompromiss. Noch ein paar kleine Anmerkungen (LED 'Wahrnehmungen' wären noch mal so lang wie dieser Text) - falls du r+g+b=bunt planst dann könnten 3*rgb(w) Chips statt r*3 +3*g+3*b deutlich besser sein, da einzelne LED sich optisch nur schwer homogenisieren/mischen lassen. - 3,6 Volt gibt es für <1€ Step-down - µC-Wahl hat tw. ähnliche psychische Probleme wie Buswahl wenn 32bit praktisch das gleiche wie 8bit kosten. Manchmal können 8bit aber durch die erzwungenen Beschränkungen vieles vereinfachen,manchmal allerdings extrem kompliziert machen.
Vielen Dank Dirk, dass du dir solch eine Mühe gemacht hast, auch wenn mir das ISO/OSI Schichtmodell bekannt ist, fand ich deine Erklärung gut und leicht verständlich. Beim Protokoll konnte ich mir zwei Möglichkeiten erdenken. Eine Adressierung jedes Paketes, zum genauen bestimmen des Zieles. Hier würde es dann wie Folgt aufgebaut werden: Für einen einen Zyklus: 8 Bit Startzeichen -> (...) -> 8 Bit Adresse + 96* Bit Daten. (...) -> 8 Bit Stopzeichen -> Pause*1 -> 8 Bit Startzeichen (...) Wenn mehrere Clients die selben Daten bekommen, findet eine Gruppierung wie folgt statt: 8 Bit Startzeichen -> (...) -> 8 Bit Gruppierung -> 8 Bit Anzahl Adressen -> Adressen jeweils 8 Bit -> 96* -> (...) -> 8 Bit Stopzeichen -> Pause*1 -> 8 Bit Startzeichen (...) * Die genaue Bitzahl setzt sich aus 8 Bit Farbe + Benötigte Bits für eventuellen Verlauf zusammen. Bei entsprechend hoher Wiederholrate lässt sich hier natürlich etwas sparen. *1 während der Pause können die Clients mit dem Server kommunizieren, oder eben nicht. Bei Kommunikation wer das Startzeichen entsprechend verzögert. Bei diesem Protokollaufbau gäbe es eine Variable Zykluszeit, da wenn nur ein Client angesprochen wird, auch nur Daten für diesen einen Versendet werden müssen und der Zyklus damit abgeschlossen ist. Das andere Protokoll wäre einfach ein erweitertes DMX Protokoll, nichts besonderes. Der Grund wieso ich 6 einzelne LEDs einsetzen möchte, liegt in der erreichbaren Helligkeit. Auf einer Platine werde ich diese wohl auf etwas mehr als 1,5 * 1,5 cm unter bringen können. Da wird sich der Effekt der Abtrennung hoffentlich noch nicht so stark bemerkbar machen, gerade bei Passiver Beleuchtung. Auf der anderen Seite habe ich so auch eine Standard Bauform und Ansteuerung, bei der ich solange die Technischen Daten gleich bleiben die LEDs beliebig austauschen kann. So könnte ich z.B. beim Anwendungsfall "Arbeitslicht" statt R+G+B+W+A+UV 4 mal W und zwei mal 2 wählen. Je nach Anwendungsfall dann auch nur UV oder der gleichen. Dennoch ein großer Dank an euch alle. Mit freundlichen Grüßen Marcel
>auch wenn mir das ISO/OSI Schichtmodell bekannt ist, fand ich deine Erklärung gut und leicht verständlich. ups, das hätte nicht passieren sollen. Das war eigentlich keine Erklärung des OSI-Modells sondern eine _|Verwendung|_ zur Herleitung und Übertragung einer Antwort die genügend Fixpunkte hat um entscheidbar zu sein. Und leicht verständlich kann die auch nicht gewesen sein, sonst hättest du auf die Daten darauf antworten können und nicht mit deiner Bekanntschaft. Zur Erklärung (hier folgt ein Versuch einer Erklärung): OSI ist kommunikationstechnisch praktisch (auch) ein 'vereinbartes' Modell/Symbolgruppe ähnlich wie Deutsch/Englisch/Chinesisch zur Kodierung. Wenn Menschen über die Gestaltung von technischer Kommunikation kommunizieren möchten, dann kann OSI praktisch mit jeder Sprache 'darunter' benutzt werden (nach M-OSI evtl. OSI over deutsch over latin-char-set over Internet over Ethernet) Formal sehr kompliziert aber für OSI-Schreiber bzw. Verabredende einfacher als auf ungenaue/undefinierte Bekanntschaften bezugnehmen zu müssen. Wenn du bsp. OSI 6..1 entwickelst und u.a. innerhalb deiner Implementierung >8 Bit Startzeichen -> (...) -> 8 Bit Adresse + 96* Bit Daten. (...) -> 8 Bit Stopzeichen -> Pause*1 -> 8 Bit Startzeichen (...) verwendest, dann kannst du mir entweder : OSI 6: Adr:[0..255 -startzeichen(SZ),-endezeichen(EZ)] Daten [0..255 -SZ,-EZ] übermitteln und ich schreibe die einfache Anwendung ohne SZ,EZ Helligkeitswerte. oder du gibst OSI 6: Adressen:8-bit Daten:8-bit an und ich schreibe die einfache Anwendung mit 8-bit Daten. Deine OSI 6..1 Implementierung sorgt dann für überraschendes Blinken falls eine LED zufällig in der Helligkeit des Startzeichens leuchten soll was den Start einer Übertragung markiert und das nachfolgende Datum zúr Adresse und die danach folgenden zu Daten der ungeplanten Adresse werden lässt. Wenn wir uns dann vor Gericht treffen und der Falsche verurteilt wird dann ist der Falsche im Idealfall derjenige der die vereinabrte Spezifikation (OSI ist praktisch auch Vertragssprache) nicht eingehalten hat (lt. Gerücht manchmal auch der Andere) OSI kann aber auch als eine Möglichkeit genutzt werden um Fragen zu (anderen) Kommunikationsprotokollen herstellen zu können, dadurch das es Fixpunkte im Modell vorschlägt. Praktisch kann ein handelsüblicher Mensch unter optimalen Bedingungen gerade einmal (gemessene) 7 Items verarbeiten, wobei für praktische Anwendungen i.A. 2-3 (+ 3 im Hinterkopf )nutzbar sind. Der Rest ist entweder vorherige erfolgreiche Itemisierung d.h. bspw. aus 1+2+3+4+5+6 wurde vorher(!) erfolgreich 6[wg."1+2+3"] +15["4+5+6"] oder gefühlt erfolgreich 5["1+2+3"] +15["4+5+6"] verarbeitet und dann kann ein Mensch bequem 1+2+3+4+5+6= 21 bzw.=20 berechnen und sowohl 6+15=21 als auch 5+15=20 sind richtige Ergebnisse. Problematischerweise fühlen sich gefühlt richtige und andere richtige Items genau gleich an und ohne einen externen Schiedsrichter (Richter) wären unsere beiden Implentierungen für uns beide jeweils Richtig.(NB.:gäbe eine interessante Relativitättheorie in der die relative Richtigkeit vom jeweilgen Standpunkt ter abhängt. Beim Verarbeiten von 2 'richtigen' Informationen zusammen mit 1 Information, nach der zumindest eine der beiden doch unrichtig sein muss, kommt es bei Menschen schnell zu einer kognitiven Dissonankatastrophe ähnlich wie in der Praxisausgabe nach der CAN-Bus Kollision ("Bus kackt ab"/UART-Vorlieben/etc.) praktisch wie bei einer Seekrankheit ( 2 'richtige' Informationen von Auge/Ohr und eine weitere dass die beiden eigentlich gleich sein sollten) Ich fürchte das dürfte hier passiert sein und deswegen kannst du die Antwort (keine Erklärung von OSI) >>>Gibt es einen passenden BUS zur steuerung vieler Clients über mehrere Meter? >>2.1 Daisy-chain [vs.RS485] >>Vorteile: >>- 'volle' Bandbreite da kein Zeitfenster für Rückantwort benötigt wird >>- Fehler lokalisierbar (Rest fällt aus) >>Nachteile: >>- schwerer denkbar >>- Mehrbelastung µC >>- Rest fällt aus wenn ein Slave ausfällt >>- zus. Latenz von (je nach Geschwindigkeit) 0,01sek nicht empfangen und glaubst an eine Erklärung zu deiner Bekanntschaft mit ISO/OSI. Ich könnte versuchen anstatt mit OSI das Ergebnis mit anderen Modellen oder irgendwie ohne weiteres Protokoll zu übertragen, aber vermutlich ist das Ergebnis an sich blockiert (praktisch eine Firewall durch Dissonanzkatastrophe) Rein technisch/finanziell dürfte Daisy-chain die beste Lösung für die behaupteten Anforderungen sein. Klassische Schutzmaßnahmen (ich verwende sehr gerne unstrukturierte Baumstrukturen damit daisy-chain gar nicht als Möglichkeit in Betracht kommt)fallen weg, aber der entscheidende Nachteil:"schwerer denkbar" ist schwer akzeptierbar (auch eine Art Denkbarkeit, hmm) Also lieber eine Variante 2 (Menschen haben neben OSI noch weiche Protokolle): >>>Gibt es einen passenden BUS zur steuerung vieler Clients über mehrere Meter? - ES485 ist hinreichend lange ausgedeutet (Standardprotokoll außerhalb harter Entscheidungen)und damit der passende Bus - der Vorschlag evtl. 7,97-bit für OSI 7 zu definieren erlaubt bei ES485 sehr einfach denkbare Protokolle, da ein start/escape zeichen für Buszwecke zur Verfügung steht. Zu den 'Neben'bedingungen des Projekts: >gerade bei Passiver Beleuchtung (indirekt) - dann ist der Helligskeitsbereich deutlich(!) weniger wichtig (Sterne in der Nacht könnten für indirekte Beleuchtung praktisch gleich hell geschaltet werden, haben aber im direkten Sichtfeld eine Dynamik von ca. 6 Größenordnung) - auch PWM -Frequenz ist indirekt nicht soo sichtbar (die flackernden punktförmigen LED an billigen Blechkisten auf den Straßen sind für einige ärgerlich, aber nicht die flächigen) - UV passiv? kann u.U. witzlos sein warum 3*r +3*g 3*b (9 led) heller als 3* 3*rgb (9 led) sein soll versteh ich nicht, aber wenn Mischung kein Problem ist dann wäre evtl. für rot eine 4.te sinnvoll, da rot häufig dunkler erscheint Projektorganisation : Prognose: - es wird Überraschungen beim Treffen mit der Softwareabteilung geben wenn die versucht die Informationen über den Bus zu erhalten und Anzeigen für den Benutzer designt die dieser auch von den LED direkt sehen könnte. - die Softwareabteilung wird die Verärgerung über die Mehrarbeit durch die vielen Möglichkeiten aus der Busabteilung nicht offen zu Sprache bringen dürfen. - die versunkenen Kosten in die Denkarbeit für den aufwendigen Bus erlauben keine kostengünstige Softwareproduktion. Was implementiert ist muss auch genutzt werden, egal um welchen Preis. - Plug'n Play wird aufgrund der Vielzahl unterschiedlicher Geräte sehr einfach, evtl. reicht ein bit um alle Möglichkeiten zu erfassen - die Qualität des Endprodukts hängt zu 60% an der PC/Smartphonesoftware und zu 40% am Lampendesign (wenn der Bus nicht abkackt und einen Kurzschluss hat) Projektleiter: - handelsüblichen Studenten wird eine Restlaufzeit von teils über 60 Jahren prognostiziert, während LED o.ä. evtl. mit 15J zu rechnen sind. Investitionen in erstere sind praktisch das 4-fache wert. - je nach Studiengang gibt es evtl. mal ein Modul OR, vielleicht fallen ein paar Gemeinsamkeiten auf (vielfach mathematisch vertuscht, aber ...) Welt: - die Ähnlichkeiten technischer Kommunikation mit menschlicher lässt sich plausibel erklären, wenn die Hintergründe dass Technik von Menschen entwickelt wird/wurde bekannt sind. Manchmal werden menschliche Protokolle aber auch durch Technikvergleich bewusst, da viele Protokolle auf unbewussten Schichten implementiert sind. - die Helligkeitswahrnehmung (Hauptthema für direktstrahlende LED) ist wohl doppeltlogarithmisch (vom Prinzip logarithmisch aber im Kernbereich noch einmal anders, also komisch) mit einer Gamma-Funktion kommt das manchmal hin, ist aber sehr uneinheitlich. LG
Beitrag #5317038 wurde von einem Moderator gelöscht.
Bitte 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.