Sport-Anzeigetafel über USB

[ijjiij]

Aber meine Berechnung mit den 100mcd je LED waren schon richtig? Wie wirkt sich das auf die 7-Segment-Anzeigen aus? Sind hier die 50mcd für dne Outdoor-Einsatz ausreichend?

[wkrug]

Ich würde pro Segment ( Balken ) 2 Reihen superhelle LED's machen.
Wie wärs z.B. mit diesen: http://www.ebay.de/itm/100-super-ult...item439dd85d1c
Vorne vor die LED's kommt eine rote Filterscheibe.
Grüne LED's sind tendenziell noch heller, aber ich denke mal das man die bei Tageslicht schlechter sieht als rote.
Ich denke dann dürfte das Ganze, dürfte auch mit ultrahellen roten LED's, für den Outdooreinsatz hell genug sein.
Letztlich macht hier nur "Versuch - Klug", oder jemand hätte das schon ausprobiert.
Besorg Dir einfach mal so 10 bis 20 Stück von den LED's, löt das mal auf eine Punktrasterplatine und mach ein Stückchen Filterscheibe davor.
Eventuell ist auch eine Filterfolie wie Sie für PAR Strahler verwendet wird ( Gibts im Musikgeschäft als Meterware ) dafür geeignet, falls Du keine geeignete farbige Plexiglasscheibe kriegst.
Eventuell wär eine leicht mattierte Plexischeibe ohnehin besser, wegen der Reflexion.

Was sicher einen Effekt bringt wäre die zusammengehörenden LED's mit einem weissen Kunststoffstreifen einzukreisen, der bis zur Frontplatte geht. Weil dadurch das überleuchten auf andere Segmente verhindert wird. Du bekommst also einen besseren Kontrast zwischen den einzelnen Segmenten.

[ijjiij]

So, nach fast einer Woche melde ich mich jetzt auch mal wieder...

Meine Aufgabenstellung hat sich Ende letzter Woche ein wenig geändert.
Die Große Anzeigetafel wurde aus meinem Teil des Projekts entfernt, da wird jetzt eine LED-Anzeigetafel aus Einzelmodulen inklusive Ansteuerung aus China genommen. Das war eine rein kostentechnische Entscheidung.

Die kleinen Anzeigetafeln sind außerdem keine 7-Segment-Anzeigen mehr, sondern auch hier kommen fertige LED-Module aus China zum Einsatz (auch hier eine Kostenfrage).
Folglich muss ich also einen komplett neuen Entwurf für die Ansteuerung der kleinen Displays machen. Die LED-Module haben bereits Segmenttreiber und einige Schieberegister verbaut. Ich hab also lediglich 16 Signal-Leitungen die ich mit 1ern und 0ern befüllen muss.

Mein Plan hierfür sieht jetzt folgendes vor:
Der AtMega16 empfängt die Daten vom Controller-Board, übergibt sie an 2 Schieberegister (2*8 bit sollte ja ausreichen für 16 Leitungen), von hier aus dann über ein (kurzes) Flachbandkabel zum LED-Modul und die Anzeige sollte laufen.
Soviel zur Theorie, Meinungen dazu sind natürlich wie immer sehr erwünscht!

Außerdem hat sich die Aufgabenstellung an das Controller-Board wieder etwas geändert!
Rund um das Spielfeld sind 6-8 (oder noch mehr) Buzzer verteilt, welche bei Betätigen ein Signal an den Laptop ausgeben sollen, und dann diverse Funktionen haben. Unter anderem wird so die Zeit angehalten, Strafen können verhängt werden etc.
Diese Buzzer würden wir aus Platzgründen jetzt auch gerne über das Controller-Board für die Displays laufen lassen.
Problem an der Sache: die am weitesten entfernten Buzzer haben eine Kabellänge von über 40m! Und gerade diese sollten eigentlich die Zeit anhalten...
Derzeitige Lösung (auch um Selbstinduktion in den Leitungen zu vermeiden): Die Buzzer schließen eine 12V Stromkreis, wodurch in Notebooknähe ein Relais geschaltet wird. Das gibt dann einen Impuls ab.
Vorteil: keine Selbstinduktion
Nachteil: Zeitverzögerung durch das Relais von ca. einer halben Sekunde!

Desshalb sollte dieses System wie gesagt auch noch überarbeitet werden...

Das Beeinflusst das Design des Conroller-Boards jetzt insofern, als das der Controller selbst jetzt auch Daten (vom Buzzer) auswerten, und zurück an den Laptop senden soll. Genau diesen Fall haben wir ja jetzt aufgrund der TxD / RxD Schleife am USB-Modul ausgeschlossen...
Hier bräuchte ich wirklich dringend Rat...

[wkrug]

Die kleinen Anzeigetafeln sind außerdem keine 7-Segment-Anzeigen mehr, sondern auch hier kommen fertige LED-Module aus China zum Einsatz (auch hier eine Kostenfrage).
Folglich muss ich also einen komplett neuen Entwurf für die Ansteuerung der kleinen Displays machen. Die LED-Module haben bereits Segmenttreiber und einige Schieberegister verbaut. Ich hab also lediglich 16 Signal-Leitungen die ich mit 1ern und 0ern befüllen muss.

Ohne Schaltplan, Funktionsbeschreibung und Datenblätter der verwendeten Displays nichts zu machen.
Die Helligkeit der Module spielt nun wohl keine Rolle mehr?
Probier die Dinger erstmal aus, ob die bei Tageslicht überhaupt noch erkennbar sind - Ich hab da schon meine Erfahrungen mit günstigen Siebensegment LED Uhren gemacht.

Der AtMega16 empfängt die Daten vom Controller-Board, übergibt sie an 2 Schieberegister (2*8 bit sollte ja ausreichen für 16 Leitungen), von hier aus dann über ein (kurzes) Flachbandkabel zum LED-Modul und die Anzeige sollte laufen.

Sind das parallel in seriell out Schieberegister oder warum so viele Leitungen?

Das Beeinflusst das Design des Conroller-Boards jetzt insofern, als das der Controller selbst jetzt auch Daten (vom Buzzer) auswerten, und zurück an den Laptop senden soll.

Der Grund für diese Entscheidung war letztlich dein Bus Design.
Du wolltest vom Laptop aus sowohl eine Stern als auch eine Bus Topologie haben. Dadurch war ein Rückkanal nicht mehr so einfach möglich.
Zur Zeit beschäftige ich mich mit dem CAN Bus. Der könnte eine Lösung für dein Problem sein.
Dieser Bus ist Multimaster fähig und hat eine Kollisionserkennung und eine Nachrichtenpriorisierung.
Aber auch hier ist eine 2 Draht Leitung ohne sternförmige Abzweigungen nötig.
Da der PC aber auch in der Mitte dieser Busleitung sein kann, kannst Du von hier aus maximal 2 Stiche abgehen lassen, die an den Enden der Leitungen einen Abschlusswiderstand kriegen müssen.
Nun die Nachteile: Die Reichweite ist nicht mehr ganz so groß wie bei RS485. Das kommt aber auch auf den gewählten Bus Speed an.
Für den Bus benötigst Du einen speziellen CAN Controller, der entweder extern angeschaltet ( z.B. MCP2515 ) oder bereits im Controller integriert ist, wie bei der AT90xxCAN Controller Serie. Für beide Varianten sind aber umfangreiche Software Konfigurationen nötig um einen lauffähigen CAN Bus zu kriegen.
Ausserdem wird ein CAN Bus Treiber benötigt wie der MCP2551.
Du kannst auch weiterhin dein "altes" RS485 Bussystem mit serieller Datenübertragung beibehalten, musst Dich dann aber um Kollisionserkennung und die Absicherung der Daten auf dem Bus selber kümmern. Dafür hab ich aber gerade kein Patentrezept parat. Da es bei der Buzzer Geschichte anscheinend sehr auf das Timing ankommt wird da wohl ein System mit festen Zeitschlitzen nicht in Betracht kommen.

Unabhängig vom verwendeten Bus System wirst Du jetzt wohl oder übel Adressen an deine Uhren vergeben müssen. Schliesslich willst Du ja wissen welcher Buzzer gedrückt wurde. Das liesse sich am einfachsten mit einem oder 2 BCD Schaltern machen.

Aus einer im Prinzip einfachen Aufgabenstellung hast Du nun ein größeres Bus Projekt mit mit sehr vielen Unbekannten vererbt gekriegt - Herzlichen Glückwunsch!

[ijjiij]

Ganz einfache Frage zur USB-Seriell Datenübertragung wie sie geplant war:
Also du hast gesagt, wenn der Laptop ein Signal sendet, muss er gleichzeitig auch wieder eines Empfangen (Empfangsbestätigung also sozusagen). Gilt das umgekehrt auch so? Also muss zuerst ein Signal gesenet werden um eines erhalten zu können?

Ich habe dazu auch gegoogelt, mangels sinnvoller Suchbegriffe zu dem Thema aber leider kaum was gefunden...

EDIT:
Ganz naiv drauflosgedacht jetzt einmal:
Das USB-Experimentierboard von Velleman hat ja nur Digitale/Analoge In- bzw. Outputs.
Könnte man nicht ganz einfach hier an die Outputs die Steuerung für Displays anschließen? Also eventuell noch einen AtMega, dann den BUS, dann das Display...
An die Inputs könnte man dann ja auch die Buzzer, bzw. das komplette Buzzer-System anschließen.

Die Frage die sich mir hier dann stellt ist halt, ob man die Display-Steuerung mit dem Board überhaupt so betreiben kann? Hier gibt es ja keinen RxD / TxD Anschluss, sondern Lediglich digitale/analoge In- und Outputs.

[wkrug]

Also du hast gesagt, wenn der Laptop ein Signal sendet, muss er gleichzeitig auch wieder eines Empfangen (Empfangsbestätigung also sozusagen). Gilt das umgekehrt auch so? Also muss zuerst ein Signal gesenet werden um eines erhalten zu können?

Das ist absolut kein muß.
Es ging darum eigentlich um das debuggen mittels Terminal Programm.
Alle Daten die dein PC sendet werden nicht! im Nachrichtenfester des Terminalprogrammes angezeigt.
Die Nachrichten die von der Zielschaltung zum PC gesendet werden, zeigt tas Terminalfenster dagegen an.
In fast jedem Terminalprogramm gibt es eine Einstellung für ein "Local Echo". Mit dieser Einstellung werden wieder alle vom PC gesendeten Daten im Terminalfenster angezeigt. Allerdings auch, wenn die Zielschaltung gar nicht an der Komunikation teilnimmt.

Du kannst als Ebenso gut die Daten quasi "blind" vom PC aus senden und Dir von der Zielschaltung eine Quittung geben lassen:
z.B. Du sendest "blind" $t14:15<CR><LF>
Der Atmega antwortet mit OK<CR><LF> wenn er die Nachricht verstanden hat und mit Error<CR><LF> wenn die Nachricht unbekannt, oder fehlerhaft war.

Somit kann der PC feststellen, obe er den überhaupt ein Gegenüber hat ( Kommandoquittung kommt an ) und ob die Nachrichten richtig angenommen wurden ( OK oder Error ).
Weiterhin kannst Du das System ja noch ausweiten und bei "Error" einen Error cause mit ausgeben.
Error 0<CR><LF> könnte so z.B. Nachricht nicht verstanden bedeuten.
Error 1<CR><LF> wäre dann vieleicht Ausgang Bus Fehler.

Zudem kannst Du auch die betätigten Buzzer an den PC zuück senden lassen.
Buzzer 09<CR><LF> wäre z.B. Buzzer 9 betätigt.

Aber ich bin jetzt schon wieder mal in den Details. Ich versuch mal Dich mittels SKYPE zu erreichen.

[ijjiij]

Gut, ich war gerade dabei die neuen Schaltpläne nach unserer gestrigen Unerhaltung zu zeichnen. Leider kennt mein Eagle die MCP2515 und MCP2551 nicht.
Muss ich mir wohl neue Bibliotheken aus dem Internet besorgen...

[wkrug]

Wenn Du welche findest OK.
Wenn nicht, ich hätte da was passendes für Eagle 5.6 hier.
Lediglich für den MCP2515 ist die SMD Bauform für die Handverlötung ein wenig ungünstig, aber brauchbar