Neues Blinkmuster der Blaulichter

Alles rund um Computertechnik, LEDs, und und und....
Benutzeravatar
hendrik.s
Forumane
Beiträge: 304
Registriert: Sonntag 16. September 2007, 19:31

Re: Neues Blinkmuster der Blaulichter

Beitrag von hendrik.s » Freitag 22. Juli 2011, 17:26

Hallo alle zusammen,

wie ist so ein Quadroblitz eigentlich aufgebaut? Laut Gerrit's Tagebuch ist der An-Teil größer als der Aus-Teil.

Ich versuche im Moment einen Controller mit einem Quadroblitz zu programmieren. Bis jetzt blinken erst zwei LEDs.Die dürften ungefähr mit der Blinkfrequenz des RTW der Hamburger Airport Feuerwehr gleich kommen. Aufgebaut habe ich das Programm auf einen Attiny 13. Laut Datenblatt benötigt er eine Spannung von 1,8 - 5,5 V.

Viele Grüße

Hendrik

Benutzeravatar
Oysos
Forumane
Beiträge: 793
Registriert: Samstag 4. August 2007, 11:43
Wohnort: Kiel

Re: Neues Blinkmuster der Blaulichter

Beitrag von Oysos » Freitag 22. Juli 2011, 17:57

Moin,

ich zitiere mich mal selbst:
Oysos hat geschrieben:ich kenne diese RTW aus Hamburg, dort dürften sie ja mit identischen oder ähnlichen Lichtern fahren.

Die Blaulichter sind LED-Blaulichter von Hänsch. Die Blaulichtblitzfolge sieht ungefähr so aus:

Code: Alles auswählen

# = LED ein
_ = LED aus
##########__##__##__##______
|    |    |    |    |     |
0    100  200  300  400   500  ms 

T = 0,52 s
(genaue Zeiten variieren je nach Position des Blaulichts)
[...]

So sehen die aus: (Lichter sind gut zu erkennen, aber insbesondere die runden Rückleuchten dürften eine Herausforderung werden ;-) )
http://bos-fahrzeuge.info/einsatzfahrze ... TW_HH-2784
http://bos-fahrzeuge.info/einsatzfahrze ... TW_HH-2724
http://bos-fahrzeuge.info/einsatzfahrze ... TW_HH-2732

http://www.rescue911.de/vid-rtw-bf-hamb ... -14249.htm
http://forum.miniatur-wunderland.de/car ... ml#p233644
Zumindest der statische RTW am Flughafenabschnitt entspricht diesem Muster aber nicht.

Gruß
Hannes

TokyoDrift

Re: Neues Blinkmuster der Blaulichter

Beitrag von TokyoDrift » Freitag 22. Juli 2011, 18:14

Deswegen wäre eben was konfigurierbares schön. Man müsste halt noch nen Programmer für 15 Euro dazu kaufen.

Benutzeravatar
hendrik.s
Forumane
Beiträge: 304
Registriert: Sonntag 16. September 2007, 19:31

Re: Neues Blinkmuster der Blaulichter

Beitrag von hendrik.s » Samstag 23. Juli 2011, 12:49

Hallo,

vielen Dank Hannes für das Blinkmuster :) .

Also, konfigurierbar ist der Tiny nicht. Habe das von Hannes angegebene Blinkmuster mal programmiert.
Ich werde die Tage mal ein Video machen.

Viele Grüße

Hendrik

TokyoDrift

Re: Neues Blinkmuster der Blaulichter

Beitrag von TokyoDrift » Samstag 23. Juli 2011, 17:26

Ich möchte mal ein bisschen was von meinen Überlegungen offenlegen. Ich nehme eh nicht an damit groß Geld zu verdienen von daher schon ok.
Ich würde einen ATTiny25 nutzen. Der hat 128Byte RAM und EEPROM.

Ich würde nun ein Blinkmuster im EEPROM ablegen, für jeden Kanal eins. Sagen wir mal wir nutzen 120 Bytes. macht dann 20Byte pro Kanal, also 160 Bit. Dort speichert man nun eben ab, zu welchen Zeiten die LED an und aus sein soll.

Dann speichert man ein Byte Multiplikator. Der gibt an wie lange ein "Takt" ist. Also, sagen wir, wir machen 1ms für einen Wert der LEDs. Dann könnte man mit 160 Werten ganze 160ms Sequenz ablegen. Schon ok, aber nicht so der bringer. Nun feuern wir also jede ms einen Interrupt, wenn das aber nicht der x-te Takt (steht dann im Multiplikatorbit) ist, dann machen wir garnichts. Also mit Multiplikator=1 hätten wir eine Auflösung t von 1ms bei 160ms Periodenzeit T. bei Mul=100 hätten wir t=100ms bei T=16s. Sprich t=MUL*1ms; T=MUL*160ms.

Und dann haben wir noch ein Byte, das angibt, wie lang die Periode genau ist. Nennen wir es PER. Das gibt an nach wie vielen "Takten" wieder von Anfang gestartet werden soll. Also die Periode T ist das Minimum aus PER*MUL*1ms und MUL*160ms.

Der Inhalt des EEPROMs wird am Anfang in den RAM geladen. Dann bleiben noch 8 Bytes für den Stack (die 2 Konfig Bytes laden wir in Register)

Als Konfigurationsschnittstelle nehmen wir SPI.
Pro: nur eine Schnittstelle für SPI und Config, kein genaues Timing nötig -> wir sparen nen Quarz auf dem PCB, schnell
Cons; mehr als nur ein Pegelwandler als Programmer nötig, 3 Leitungen + GND nötig
Der AVR agiert dabei als SPI Slave. Sobald ein Master (=Programmer) ein bestimmtes Byte/Sequenz sendet geht der AVR in Konfigurationsmodus. Dort kann der Master mit bestimmten Kommandos den EEPROM lesen und schreiben. Ganz simpel. Dann kann der AVR per SPI neu gestartet werden und fertig.

Da wir nur einen 4 Level Stack haben (eine Rücksprungaddresse hat 16bit?) und garkeinen RAM für Variablen haben muss die Programmierung in Assembler erfolgen. RAM und EEPROM mäßig bringen wir den AVR ans Limit.

Als Anschluss für den Programmer würde ich einen 4Pin .5 Pitch FPC Connector nehmen. Die sind winzig. Außerdem kann man den AVR gleich über den Connector programmieren, nur Reset muss man noch von Hand hinhalten oder so. Da wir eh 6 IOs brauchen deaktivieren wir den Reset Pin nach dem Programmieren und sparen uns auch gleich den Pullup.

Ansonsten braucht der AVR einen Abblock-C, da nimmt man normalerweise 100nF. An die 6 IOs muss jeweils ein Widerstand, vllt 100 Ohm und ein Pad für die LED. Das Pad vom Reset Pin kann gleich fürs Programmieren genutzt werden.

Zuletzt braucht man noch einen Boost Converter, am besten mit Fixed Output Voltage, da spart man sich einen Spannungsteiler = 2 Rs. Außerdem wählt man am schlausten einen, der keine externe Diode braucht. Und keinen externen Switch. Braucht man also nurnoch eine Induktivität und 2 Cs.

Und der Programmer, naja, da hab ich mir noch keine großen Gedanken gemacht. Haben FTDIs nen SPI ausgang? Falls ja, FTDI ran. Ansonsten FTDI+AVR oder AVR+VUSB. Alles kein Problem.

Mal ein wenig Pseudocode:
Register:
- MUL: Zu erreichender Multiplizierer (siehe oben)
- PER: Zu erreichende Periode (siehe oben)
- MUL_CNT: Aktueller MUL
- PER_CNT: Aktuelle PER
- DATA[6]: Ein Byte aus dem EEPROM für jeden Kanal
- DATA_MASK: Aktuelles Bit
- MODE: Aktueller Modus
- RW_CNT: Anzahl Gelesener Zeichen
- TEMP: Braucht man immer
- Z[2]: Speicherzeiger
=> Macht 16 Register, sprich die sind voll. Wenn man n zweites TEMP braucht (braucht man immer) muss man eben DATA[6] in die ersten 16 Register laden und dann immer umkopieren. Wär auch ok.

Konstanten:
- mn1r: Erstes Magic Number Byte, um in den SPI Mode zu kommen
- mn1t: Antwort auf mn1r
- mn2r: 2. MN Byte
- mn2t: Antwort auf mn2r
- SPI1: Erstes MN empfangen
- SPI2: Zweites MN empfangen
- SPIr: PC will lesen
- SPIw: PC will schreiben
- BLINK: Normaler Modus
- read: Befehl zum Lesen
- write: Befehl zum Schreiben
- reboot: Befehl zum Neustart

Startup:
- Stack initialisieren
- IOs initialisieren
- 120Bytes aus dem EEPROM in den RAM laden
- 2 Bytes (MUL+PER) aus dem EEPROM in Register laden
- SPI initialisieren, slave, receive interrupt, mn1t in SPI TX
- Timer compare interrupt einrichten, 1ms tick
- Interrupts starten

Main:
- Sleep Mode starten (immer wenn der Controller aufwacht wird der Sleep Mode neu gestartet)

Timer CMP Interrupt: (hier passiert die Hauptarbeit)
- Wenn MODE!=BLINK dann reti
- Wenn (++MUL_CNT)<MUL dann reti
- wenn (DATA_MASK<<=1)==0 dann
- - DATA_MASK=1
- - DATA neu aus dem RAM holen
- Für alle DATAi in DATA
- - Wenn (DATAi&DATA_MASK)==0: Pin aus, sonst Pin an
- Wenn (++PER_CNT)<PER dann reti
- PER_CNT=0
- DATA neu aus dem RAM holen
- reti

SPI RX Interrupt:
- Wenn SPI RX==mn1r && MODE==BLINK: SPI TX=mn2t, MODE=SPI1 reti
- Wenn SPI RX==mn2r && MODE==SPI1:MODE=SPI2 reti
- Wenn MODE==SPI2C:
- - Wenn SPI RX==read: MODE=SPIr, SPI TX=Erstes EEPROM Byte
- - Wenn SPI RX==write: MODE=SPIw
- - Wenn SPI RX==reboot: rjmp RESET
- Wenn MODE==SPIr
- - Wenn SPI RX!=read: rjmp RESET, sonst SPI TX=nächstes EEPROM Byte
- - Wenn (++RW_CNT)==120: MODE=SPI2, RW_CNT=0
- Wenn MODE==SPIw
- - Nächstes EEPROM Byte = SPI RX
- - Wenn (++RW_CNT)==120: MODE=SPI2, RW_CNT=0

RESET:
- CLI
- Watchdog aktivieren
- Warten
Man sieht, ich brauche eigentlich keine Unterfunktionen. Naja, vllt noch EEPROM Write/Read. Die Interrupts schieben ihre Addresse auf den Stack, aber da läuft ja nur immer einer. Das einzige Unterprogramm ist RESET, und weils da eh schon egal is kann man das auch per jmp anfahren. Maximale Stack Auslastung ist also 2 Addressen.

Achso, und zur Vorsicht, dass hier keiner auf dumme Gedanken kommt:
Diese(s) Werk bzw. Inhalt von TokyoDrift steht unter einer Creative Commons Namensnennung-Nicht-kommerziell-Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz.
Über diese Lizenz hinausgehende Erlaubnisse können Sie unter http://tokyodrift-dev.info erhalten.

Maese

Re: Neues Blinkmuster der Blaulichter

Beitrag von Maese » Sonntag 24. Juli 2011, 16:47

Hallo "TokyoDrift"

Das sind interessante Überlegungen.
Zurzeit verfolge ich ein ähnliches Projekt für die Lichtsteuerung auf meiner Modelleisenbahnanlage. Wobei es nur um die Beleuchtung von statischen Objekten geht.
Eine Beschreibung zu meinem Projekt, findet man auf der Internetseite http://www.marthaler-online.ch/railway/ ... uerung.php.

Viele Grüsse
Mäse

TokyoDrift

Re: Neues Blinkmuster der Blaulichter

Beitrag von TokyoDrift » Sonntag 24. Juli 2011, 19:45

Code: Alles auswählen

TIMER_CMP_INT:
	--IF(MODE!=BLINK)return;
	cp MODE, BLINK
	brne TIMER_CMP_INT_END

	--IF((++MUL_CNT)<MUL)return;
	inc MUL_CNT
	cp MUL_CNT, MUL
	brne TIMER_CMP_INT_END
	--MUL=0;
	ldi MUL_CNT, 0

	--IF((DATA_MASK<<=1)==0)DATA_MASK=1;
	lsl DATA_MASK
	brne TIMER_CMP_INT_MAIN
	ldi DATA_MASK, 1
	inc DATA_ADR

TIMER_CMP_INT_MAIN:
	--TEMP1=1, TEMP2=0, Y=DATA_ADR
	ldi TEMP1, 1
	ldi TEMP2, 0
	ldi YL, DATA_ADR
	ldi YH, 0
TIMER_CMP_INT_LOOP:
	--DATA = (*Y)&DATA_MASK
	ld DATA, Y
	and DATA, DATA_MASK
	--IF(DATA!=0)TEMP2|=TEMP1
	cpse DATA, 0
	or TEMP2, TEMP1
	--Y+=20
	add YL, 20
	adc YH, 0
	--IF((TEMP1<<=1)!=0b00100000)goto LOOP
	lsl TEMP1
	cpi TEMP1, 0b00100000
	brne TIMER_CMP_INT_LOOP
	--LEDPORT=TEMP2
	out LEDPORT, TEMP2

	--IF((++PER_CNT)!=PER)reti
	inc PER_CNT
	cp PER_CNT, PER
	brne TIMER_CMP_INT_END
	--PER_CNT=0, DATA_ADR=0, DATA_MASK=1
	ldi PER_CNT, 0
	ldi DATA_ADR, 0
	ldi DATA_MASK, 1
	
TIMER_CMP_INT_END:
	reti
Hab bissl was vom Konzept geändert.

Diese(s) Werk bzw. Inhalt von TokyoDrift steht unter einer Creative Commons Namensnennung-Nicht-kommerziell-Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz.
Über diese Lizenz hinausgehende Erlaubnisse können Sie unter http://tokyodrift-dev.info erhalten.

Benutzeravatar
hendrik.s
Forumane
Beiträge: 304
Registriert: Sonntag 16. September 2007, 19:31

Re: Neues Blinkmuster der Blaulichter

Beitrag von hendrik.s » Montag 25. Juli 2011, 12:35

Hallo,

so hier mal ein Video von meinem Quadroblitz: http://www.youtube.com/watch?v=ZQOAMGa7GHA

Viele Grüße

Hendrik


Benutzeravatar
Mr. E-Light
Forumane
Beiträge: 5631
Registriert: Dienstag 24. Februar 2004, 16:17

Re: Neues Blinkmuster der Blaulichter

Beitrag von Mr. E-Light » Dienstag 26. Juli 2011, 21:47

Niedlich! 8)

Wenn man das Teil auch für verkabelte Standmodelle benutzen könnte (u.a. Anschluss an einen Lichtstromtrafo sollte irgendwie möglich sein), dann könnte ich auch eventuell Interesse daran bekommen (hängt natürlich letztlich auch vom Preis ab). ;-)
Gruß
Ralf

Babbi

Re: Neues Blinkmuster der Blaulichter

Beitrag von Babbi » Mittwoch 27. Juli 2011, 10:35

Hi,

also das sind ja schon echt richtig gute ergebnisse!!! Und das video ist auch beeindruckend!!!bin gespannt wies weiter gehen wird...:D

gruß

bastian

Benutzeravatar
Harry
Forumane
Beiträge: 2912
Registriert: Dienstag 4. Februar 2003, 12:27
Wohnort: Mache gern Urlaub an der NordOstsee
Kontaktdaten:

Re: Neues Blinkmuster der Blaulichter

Beitrag von Harry » Mittwoch 27. Juli 2011, 11:48

Zur Info.
Hab ich letzte Woche neu entdeckt: ein AVR Programmer für 20 Euro bei Reichelt.

Viele Grüße
Harry

http://www.reichelt.de/Programmer-Entwi ... ROVID=2402

Benutzeravatar
hendrik.s
Forumane
Beiträge: 304
Registriert: Sonntag 16. September 2007, 19:31

Re: Neues Blinkmuster der Blaulichter

Beitrag von hendrik.s » Mittwoch 27. Juli 2011, 12:29

Hallo alle zusammen,

der Programmer sieht ja klasse aus! Vor allem für kleines Geld :wink: .

@ Tokyodrift: Die Größe ist ja super! Mit was für einer Oberfläche wird der Tiny dann am PC konfiguriert werden?

Viele Grüße

Hendrik

TokyoDrift

Re: Neues Blinkmuster der Blaulichter

Beitrag von TokyoDrift » Mittwoch 27. Juli 2011, 12:58

So. Find ich cool dass sich hier mal was regt. Habe leider gerade ein kleines Problem. Genauer gesagt ein größeres. Ich hab den RESET pin als IO eingeplant. Eigentlich ist das legitim. Allerdings gerade im Datenblatt gelesen dass Reset ein "weak" IO ist. Das heißt der kann keine LED sourcen. Ich versuche gerade einen Transistor draufzuklatschen, möglicherweise wird das aber nichts. Dann hätte man nur 5 Kanäle. Wäre das OK? Ansonsten müsste man das ganze von vorne mit nem MLF/BGA machen, das ist dann aber nicht mehr handlötbar, also auch problematisch.

Der Programmer ist ein ISP Programmer. Das heißt der ist gut, um den Tiny zu programmieren. Die Konfiguration würde aber über eine SPI Schnittstelle laufen, und vorallem bräuchte man einen FPC Stecker (son folien-flachbandkabel Zeug) am Konfigurationsgerät. Das müsste man eben selber machen. Trozdem bin ich zuversichtlich, dass das Preislich auch in dem Rahmen bleiben würde.

Wie das am PC läuft weiß ich noch nicht. Bin leider nicht so der Freund von dem ganzen GUI Zeug. Evtl. wird das am Anfang bisschen Gefrickle. Muss ich mal mit nem Kumpel reden.

Benutzeravatar
Harry
Forumane
Beiträge: 2912
Registriert: Dienstag 4. Februar 2003, 12:27
Wohnort: Mache gern Urlaub an der NordOstsee
Kontaktdaten:

Re: Neues Blinkmuster der Blaulichter

Beitrag von Harry » Mittwoch 27. Juli 2011, 13:06

TokyoDrift hat geschrieben:...Der Programmer ist ein ISP Programmer. Das heißt der ist gut, um den Tiny zu programmieren. Die Konfiguration würde aber über eine SPI Schnittstelle laufen, und vorallem bräuchte man einen FPC Stecker (son folien-flachbandkabel Zeug) am Konfigurationsgerät. Das müsste man eben selber machen. Trozdem bin ich zuversichtlich, dass das Preislich auch in dem Rahmen bleiben würde.
...
Andere Idee: verschiedene Softwareversionen bereitstellen, die wären alle mit dem Programmer flashbar. Verschieden EEPROM Files bereitstellen, wären ebenfalls flashbar. Die könnte man bei Bedarf direkt im hex-File ändern, wenn es dazu eine gute Anleitung gibt.

Damit reduziert sich der materielle Aufwand auf den ISP Programmer. Allerdings wäre der Reset Pin nicht als Output nutzbar.

MLF Gehäuse wären noch handlötbar, der ATtiny24 hätte genug Pins, nur mal so in den Raum geworfen.

Viele Grüße
Harry

TokyoDrift

Re: Neues Blinkmuster der Blaulichter

Beitrag von TokyoDrift » Mittwoch 27. Juli 2011, 13:15

Also ICH kann kein MLF handlöten. Und selbst wenn man das hinkriegt, das macht man 1, 2 mal, dann hat man echt kein Bock mehr drauf. Außerdem kann man die Lötstellen kaum noch prüfen. Einen ISP Programmer wollte ich nicht für die Konfiguration benutzen, weil ich dann den RESET Pin auch ausführen müsste. Außerdem wäre er dann nich als IO nutzbar, dass sich das eh erledigt hat wusste ich ja bis dato nicht. Ja, den ATTiny24 habe ich angeschaut, im MLF halt, wäre dann ein wenig schwieriger zu routen und so.
Achso, zum Thema ISP Programmer: Da fehlt der FPC Anschluss. Das heißt man müsste sowieso ne Adapterplatine machen.

Benutzeravatar
Harry
Forumane
Beiträge: 2912
Registriert: Dienstag 4. Februar 2003, 12:27
Wohnort: Mache gern Urlaub an der NordOstsee
Kontaktdaten:

Re: Neues Blinkmuster der Blaulichter

Beitrag von Harry » Mittwoch 27. Juli 2011, 13:24

MLF klappt, wenn die Pads lang genug sind, so dass der Lötkolben sowohl Pad als aus Pin berührt. Dazu noch etwas Lötwasser (Kolophonium in Brennpspiritus), das ist nicht schwer. Die Pads werden nicht einzeln verlötet, sondern mit einem dicken Klecks Zinn. Den Rest nimmt man dann ab.

Keine Ahnung wie groß die Platine werden darf. Bei Reichelt gibt es Buchsenleisten im 1.27 mm Raster. Daraus mache ich mir Programmierstecker, Pads sind auf den Leiterplatten vorgesehen, den Platz gönne ich mir. Dann genügt auch der ISP Programmer.

Das nur so als Ideen. Da ich sie nicht selbst realisieren muss, hab ich's natürlicht gut ;-)

Viele Grüße
Harry

TokyoDrift

Re: Neues Blinkmuster der Blaulichter

Beitrag von TokyoDrift » Mittwoch 27. Juli 2011, 13:27

MLF klappt, wenn die Pads lang genug sind
Ja, dann wird das ganze aber schon wieder recht groß.
Keine Ahnung wie groß die Platine werden darf. Bei Reichelt gibt es Buchsenleisten im 1.27 mm Raster.
2x3 bräuchte man da. Das wären 2.5x3.8mm. Das ist schon fast 30% der aktuellen Platinenfläche. Die große Frage ist im moment nur ob 5 Kanäle reichen.

Benutzeravatar
Harry
Forumane
Beiträge: 2912
Registriert: Dienstag 4. Februar 2003, 12:27
Wohnort: Mache gern Urlaub an der NordOstsee
Kontaktdaten:

Re: Neues Blinkmuster der Blaulichter

Beitrag von Harry » Mittwoch 27. Juli 2011, 13:53

TokyoDrift hat geschrieben:
MLF klappt, wenn die Pads lang genug sind
Ja, dann wird das ganze aber schon wieder recht groß.
Na ja, ich dachte an wenige 1/10mm...

Leiterplatte 2x3mm? Wie soll der Tiny denn überhaupt geflasht werden, in einem Adapter? Danach auflöten? Dann wäre eine Möglichkeit immer noch, den Reset Pin als Debug Wire zu nehmen und einen Satz verschiedener Softwareversionen bereitzustellen. Ok, der Reset Pin ist dann kein IO. Aber drei Kabel dranlöten und los gehts mit Neuprogrammierung.

Ich habe immer noch das Gefühl, dass die Sache mit der SPI Schnittstelle unnötig aufwändig sei. Soweit ich verstehe ist der einzige Grund dafür, dass der Reset Pin als Output verwendet werden soll?

Viele Grüße
Harry
Zuletzt geändert von Harry am Mittwoch 27. Juli 2011, 14:02, insgesamt 1-mal geändert.

TokyoDrift

Re: Neues Blinkmuster der Blaulichter

Beitrag von TokyoDrift » Mittwoch 27. Juli 2011, 14:01

ISP läuft ja über die SPI Schnittstelle + RESET. Somit kann ich den FPC Stecker zum Programmieren verwenden, muss dafür nur RESET hinhalten/anlöten. Später kann der Nutzer den FPC Anschluss gleich noch hernehmen um das Ding zu konfigurieren. Ja, ein UART wäre platzsparender. Möglicherweise könnte man das ganze sogar über einen Draht machen. ABER dann muss das ganze asynchron laufen. Das geht im Sommer gut und im Winter ist der interne RC Oszillator abgedriftet und das ganze geht nicht mehr. Und einen Quarz draufbasteln ist größer als die 4Pin Schnittstelle. Hab nun nen Transistor drauf. Leider ist das ganze mit 12x6mm bisschen größer geworden.
Ich meinte 2x3 Pins bräuchte man ;)

Antworten