Dynamische Blinker

Yes. I saw this video in 1st post. I'm only mentioning this to show, what I mean.
You told, that FRM shuts the current, what if You connect additional capacitor parallel to blinker circuit to keep current flow little longer? :) :-)
 
The relay is not necessary, just put capacitor parallel into circuit just before Your Dynamic turn signal module (to keep him in power little longer) and do test.
 
Yes, but It will allow to start blink ealier, and last longer (after complete fill-up), so It will lit little longer. (it will depend, how big capacitor will You choose to test).

IMHO it worth to test, if it will working ok or not.
 
It had been already mentioned al lot earlier in one of the threads that in principle the sequencer may be powered from T.30 (the switched one, preferably, for idle current reasons, it is easily available from different sources in the trunk area). Then the sequence is only triggered by the FRM's output but the duration of the on-phase is completely free to choose. Robert is anyway right that the periodicity is fixed by FRM.

There is a legal range of turn signals frequency, with BMW's period being as people are used to since decades. But Audi selected a slower repeat to have more time for the effect.

Theoretically the period may be a coding parameter of FRM, but it is also likely that it is fixed in the firmware of FRM.
 
Wenn du die Versorgung bereits vom FRM-Takt unabhängig gemacht hast (das macht Experimente mit Stützkondensatoren obsolet, aber das funktioniert dann doch nicht bei Warnblinker ohne Schlüssel im Schloss, weil die Rücklichter aus sind - oder?), genügt es doch, das Lauflicht zu starten - die fallende Flanke des FRM bzw. deren Zeitpunkt ist doch an sich egal.

Das Lauflicht müsste dann noch in einen One-Shot-Modus versetzt werden. Entweder kann es das eh schon (als Konfiguration), oder man müsste es mit Zusatzhardware erzwingen. Somit würde die Dunkelphase leicht variieren, aber das merken allenfalls Schlagzeuger.

Oder man setzt das ganze neu auf mit einem Arduino :D.
 
MiSt schrieb:
Wenn du die Versorgung bereits vom FRM-Takt unabhängig gemacht hast (das macht Experimente mit Stützkondensatoren obsolet, aber das funktioniert dann doch nicht bei Warnblinker ohne Schlüssel im Schloss, weil die Rücklichter aus sind - oder?), genügt es doch, das Lauflicht zu starten - die fallende Flanke des FRM bzw. deren Zeitpunkt ist doch an sich egal.
Das Lauflicht müsste dann noch in einen One-Shot-Modus versetzt werden. Entweder kann es das eh schon (als Konfiguration), oder man müsste es mit Zusatzhardware erzwingen. Somit würde die Dunkelphase leicht variieren, aber das merken allenfalls Schlagzeuger.
Oder man setzt das ganze neu auf mit einem Arduino :D.
Zum Vergrößern anklicken....
Alles korrekt :D

Mein Konzept mit der Trägerplatine (Lochraster) basiert darauf, daß bei Ausfall meiner Komponenten oder der von mir genutzten Stromversorgung (eingeschaltetes Rücklicht) die Blinker im BMW-Modus laufen. Zu diesem Zwecke befindet sich das schwarze Relais auf der Zusatzplatine, das bei Störungen (= Relais stromlos) die Blinker wieder in den Originalmodus schaltet.

Das Relais zieht übrigens softwaregesteuert erst dann an, wenn alle meine Initialisierungen im Code erfolgreich durchgelaufen sind. Da ist also noch mehr Absicherung als nur gegen Powerfail. :) :-)

index.php


Damit funktionert auch der Warnblinker ohne Schlüssel "normal" wie immer. Genauso wie die Warnblinker beim Öffnen oder Verschließen des Fahrzeugs. Bei AUDI gibts auch dann ein Lauflicht, bei meiner Variante Standard-BMW.

Den Rest Deiner Überlegungen hatte ich oben mit der Aufzählung der "Verbesserungen" beschrieben.
Ich muß mich softwareseitig von dem CONRAD-Konzept des immer laufenden Rundum-Lauflichts lösen und einen rein triggerbasierten 6-Schritte-Modus aufbauen.
Das gibt's bisher nicht. Und ob ich das für den ARDUINO oder den CONRAD ATMEL neu schreibe, ist aufwands- und codeseitig gleich. :) :-)

Bei der C-Programmierung der CONRAD Platine bin ich absolut frei und unterliege keinerlei Einschränkungen.
Oh Mann, was für ein Aufwand für so ein bescheuertes Lauflicht.:g Aber eine nette Spielerei. :@
 
Zuletzt bearbeitet:
Im E85 konnte man im GM5 (=FRM) den Blinkerintervall durch Codierung in 5 Stufen leicht ändern - bis zum Doppelimpuls (US) beim Warnblinker. Das geht im E90 auch, also scheint es da evtl. eine Lösung zu geben.
 
Benster schrieb:
Im E85 konnte man im GM5 (=FRM) den Blinkerintervall durch Codierung in 5 Stufen leicht ändern - bis zum Doppelimpuls (US) beim Warnblinker. Das geht im E90 auch, also scheint es da evtl. eine Lösung zu geben.
Zum Vergrößern anklicken....
Den Doppelimpuls kann man auch per CARLY einstellen, aber ich benötige meeeeehr Zeit, also ausnahmsweise mal "langsamer". ;)

Ich werde mich mal mit Rhein.gold an den Zetti hängen und ins FRM rein schauen...
 
RobbiZ4 schrieb:
Den Doppelimpuls kann man auch per CARLY einstellen, aber ich benötige meeeeehr Zeit, also ausnahmsweise mal "langsamer". ;)

Ich werde mich mal mit Rhein.gold an den Zetti hängen und ins FRM rein schauen...
Zum Vergrößern anklicken....

Wir können ja mal mit den Parametern spielen und schauen was passiert. ;)
 
@MiSt
Gibt es bei den ATMEL CPUs eigentlich einen echten Trigger, der auf eine steigende oder fallende Flanke reagieren kann?
Bisher werden meine IRQ'S durch kurze Timerintervalle angestoßen, bei denen ich dann einen Status abfrage oder eine Aktivität ausführe.
 
Zuletzt bearbeitet:
Gute Lösung mit dem Powerfail-Fallback auf normales Blinken :) :-)

Verstehe ich das richtig, dass du in einer schnellen Schleife aktuell den Trigger pollst?

Ja, bei den ATMELs gibt es Pin-Interrupts, die sind beim Arduino auch einfach nutzbar, habe ich z.B. mal für einen Servotester/Servopulsanalyzer gemacht:

#define PulsInPin 2 /* 2 oder 3 vom Chip her (Arduino Uno) möglich */
#define PulsInt PulsInPin-2 /* gemapped auf Int0 oder Int1 */

void setup()
{
pinMode(PulsInPin, INPUT_PULLUP);
attachInterrupt(PulsInt, PulsIsr, CHANGE); // gibt weitere Optionen, CHANGE reagiert auf beide Flanken

upload_2018-8-28_16-6-38.png

....
 
MiSt schrieb:
Gute Lösung mit dem Powerfail-Fallback auf normales Blinken :) :-)
Zum Vergrößern anklicken....
Danke, das war mir wirklich wichtig. ;)

MiSt schrieb:
Verstehe ich das richtig, dass du in einer schnellen Schleife aktuell den Trigger pollst?
Zum Vergrößern anklicken....
Ja, ziemlich blöd! :confused:
So war das Prüfen eines Eingangssignals in der CONRAD Originalsoftware gelöst. Da ich zu Beginn keine Ahnung hatte und nur Bahnhof beim Code-Lesen verstanden habe, ist das bis heute drin geblieben. :roflmao:
MiSt schrieb:
Ja, bei den ATMELs gibt es Pin-Interrupts, die sind beim Arduino auch einfach nutzbar, habe ich z.B. mal für einen Servotester/Servopulsanalyzer gemacht:
#define PulsInPin 2 /* 2 oder 3 vom Chip her (Arduino Uno) möglich */
#define PulsInt PulsInPin-2 /* gemapped auf Int0 oder Int1 */
void setup()
{
pinMode(PulsInPin, INPUT_PULLUP);
attachInterrupt(PulsInt, PulsIsr, CHANGE); // gibt weitere Optionen, CHANGE reagiert auf beide Flanken
index.php

....
Zum Vergrößern anklicken....
Stimmt, da hatte ich schon mal was gelesen. Das werde ich mir umgehend anschauen. Allerdings sind bei der speziellen CONRAD-Platine nicht alle CPU-Pins mit Lötanschlüssen versehen. Daher verwende ich von deren Lauflicht-Lösung den TC1 Input Capture Pin, in meiner nachfolgenden Tabelle auf Zeile 19 beschrieben:

ATMega32_CControl_Pins.jpg

Code: 
void BlinkerSignal_ISR (void)
{

    if(Port_ReadBit(PORT_RC)) // check RC port for blinker signal (PD6, port RC)
 
Zuletzt bearbeitet:
Naja, bis auf die kleine Unschärfe im Start-Timing ist das doch nur unelegant, aber unproblematisch.

Was die Sache verbessern würde im jetzigen Stand - ohne Umbau - wäre eine Codeänderung, dass das Lauflicht eben nicht rund läuft, sondern am Ende eines Zyklusses stehen bleibt und erst beim nächsten Trigger wieder vorne losläuft. Das vermeidet zuverlässig diese Überschneidungsblitzer.

Die fraglichen Pins sind die "externen Interrupts" INTx. Der Arduino macht davon nur zwei einfach zugänglich, welche das physikalisch sind, müsste man reverse-engineeren
 
MiSt schrieb:
Naja, bis auf die kleine Unschärfe im Start-Timing ist das doch nur unelegant, aber unproblematisch.
Zum Vergrößern anklicken....
Genau! Und deswegen ist es eine :poop: und muß wech.... :roflmao:

Und ... ich würde gerne verstehen, wie es richtig zu machen ist. Da bin ich derzeit noch auf der Suche nach der richtigen Ansteuerung...

MiSt schrieb:
Was die Sache verbessern würde im jetzigen Stand - ohne Umbau - wäre eine Codeänderung, dass das Lauflicht eben nicht rund läuft, sondern am Ende eines Zyklusses stehen bleibt und erst beim nächsten Trigger wieder vorne losläuft. Das vermeidet zuverlässig diese Überschneidungsblitzer.
Zum Vergrößern anklicken....
Korrekt. Aber dafür muß ich in dem bisschen Code doch soviele Stellen anpassen, daß ich auch noch den IRQ korrigieren kann. :thumbsup:

MiSt schrieb:
Die fraglichen Pins sind die "externen Interrupts" INTx. Der Arduino macht davon nur zwei einfach zugänglich, welche das physikalisch sind, müsste man reverse-engineeren
Zum Vergrößern anklicken....
Genau, da war was mit INTx:
INT0 - Zeile 15 - Verbunden mit Taster SW2 auf der CONRAD Platine
INT1 - Zeile 16 - CPU Pin 12, muß ich checken, ob der per Leiterbahn zugänglich ist: [NEIN]
Nur diese beiden stehen zur Verfügung.

INT0 / SW2: Diesen nutze ich für diverse Nebenfunktionen, wie
- Programmwechsel
- Änderung der Geschwindigkeit
- Speichern von gewähltem Programm und aktueller Geschwindigkeit im internen EEPROM
- Reset aller gespeicherten Parameter auf Dummy-Werte
Die Unterscheidung der gewählten Funktion wird anhand der Dauer des Drucks auf SW2 getroffen.

20180828_174524_small.jpg

Schade, der INT1 (Pin 12) ist nur angeheftet, keine Leiterbahn angeschlossen.

Wenn ich also nur über diesen nicht wirklich zugänglichen INT1 flankenbasiert triggern kann, dann ...
... muß ich bei der Polling-Lösung bleiben.

Links ist der mit "RC" markierte Lötanschluß, an den ich derzeit das Blinkersignal anlege. Dieses Portbit (PD6) kann ich aber m.W. nur pollen.
 
Zuletzt bearbeitet:
C-Control Doku:
http://www.c-control-pro.de/documentation/interrupt.htm

Dort werden 3 externe Interrupts erwähnt. Wo befindet sich INT2 an der CPU?

upload_2018-8-28_18-6-30.png


Ok, habe ich nun auch gefunden:
Die obige CPU-Tabelle habe ich aktualisiert und gegen eine besser formatierte ausgetauscht. Dort ist ersichtlich, daß der Pin für INT2 eine Mehrfachfunktion hat, die bereits von der CONRAD-Platine genutzt wird. Dokumentiert in Zeile 46: Port PB2 wird für einen der 4 Leistungstreiber genutzt, die 2A schalten können. Auf obiger Platine wird damit der S3 Anschluß angesteuert, der durch das 8-polige IC rechts unten versorgt wird.
 
Zuletzt bearbeitet:
Ein Input Capture hat eine andere Zielrichtung. Man wird nicht über das Ereignis des Pegelwechsels informiert, das muss man pollen. Aber zum Ereignis des Pegelwechsels wird ein Timerstand abgespeichert (im Capture-Register des Timers). Das heißt, man kann durch letztlich immer nachträgliches Pollen eines Pins mit aktiviertem Capture den präzisen Zeitpunkt des Pegelwechsels ermitteln.

Das braucht man durchaus, aber eher in früheren Zeiten, als viele Interfaces zwischen Geräten über Pulsbreiten liefen und man diese ausmessen musste. Dazu gehörten früher z.B, auch Temperaturregelsysteme und insbesondere auch die Geschwindigkeitspulse in Autos für den Speedo (darum kümmert sich heutzutage das ABS-Steuergerät ...). Übrig ist davon "gefühlt" in der Jetztzeit (in der man zur Kommunikation digitale Bussystem einsetzt) eigentlich nur noch das Servoprotokoll von Fernsteuerungen ... :whistle:

... anyway hilft dir das hier nicht weiter. Du weißt dann zwar, wann genau der Pegelwechsel war, aber besser wäre gewesen, den Zyklus genau dann zu starten. als der Pegelwechsel war ...

Letztlich bleibe ich dabei, es würde reichen, die Endlosschleife aus dem Lauflichtcode rauszunehmen. Das bisschen Startzeit-Unsicherheit durch Polling spielt letztlich keine Rolle.
 
Zuletzt bearbeitet:
Dieses Wochenende habe ich einen Clone von @germinator's genialem Rücklicht-Testgerät aufgebaut.

Original & Clone:
20180901_194610_small.jpg

Innereien für Nachbauwillige :) :-):
20180901_080159_small.jpg

20180901_184440_small.jpg

Und leuchten kann's auch: :@
20180901_190522_small.jpg

Nun kann ich ihm sein Exemplar endlich wieder zurückgeben, daß er mir selbstlos und ohne zu zögern bereits beim Zetti-Treffen 2017 in Sinsheim überlassen hatte! ;)

Danke Jürgen! :thumbsup:
 
Zuletzt bearbeitet:
cra3y schrieb:
Dynamische Blinker
IMHO, the turn signals should stay on little longer (0.2-0.4s), when the whole led line lit. It disappears too quickly.
It looks good, when the full line lit time is not shorter than on this video
Zum Vergrößern anklicken....
Yesterday I've updated the software to keep the ON phase a little bit longer.

Video of the former version V9.3
index.php


Until this software version I've switched off all 6 blinker LED groups a little bit before the FRM control unit switches off the blinker signal. This is the reason, why I've used the possible FRM time frame of about 320 milliseconds only by 45% up to 49.9%. A visible flickering at the end of this period is the result.


Video of the current version V12.1
upload_2018-9-12_10-57-34.png

Right now the ON phases will be kept until the FRM cuts the power supply of the blinker unit. With this software version the complete FRM time frame of about 320 milliseconds is used (50% ON of a period of 640 mS). The flickering at the end of this period has disappeared.

BMW Definition:
upload_2018-9-12_10-46-15.png

Well, the above differences are so small, that nobody will remark it on a driving car. :D
 
Zuletzt bearbeitet:
BlackZZZZ schrieb:
Einfach klasse :) :-)!
Sieht so einfach aus und steckt doch so viel Arbeit drin :kniefall
Zum Vergrößern anklicken....
Wohl wahr.
Ich hatte im vergangenen Jahr auch nicht gedacht, daß ich mich am Ende (dieses Jahr) mit Millisekunden-Zählerei und µSekunden-Berechnungen (Basis: 17,36 µS) beschäftigen werde. ;)


(FRM = FussRaumModul, das den Blinkertakt erzeugt)

Auszug aus dem Change Log:
Code: 
[...]
V 11.00                    06.09.2018 RE New interrupt handling, triggered by FRM signal
                                         several Msg_WriteText() included to display activities and timings,
                                         when sketch will be started by the C-CONTROL Pro IDE
                                         #define TIMER_256_ON
                                         #define TIMEPrescaler    PS0_256 // PS0_256=17,36 µS
                                         #define TIMEPrescaler    PS0_1024 // PS0_1024=69,44 µS

                                         - standard delay with prescaler PS0_256 is 26 cycles
                                         - standard delay with prescaler PS0_1024 is 8 cycles

V 12.00                    11.09.2018 RE LED groups & array extended from 6 to 7 (CNTLEDSTEPS)
                                         Last copied value (7) keep the LED groups switched on until the FRM disables the signal
V 12.01                    11.09.2018 RE Msg_WriteText() added to interrrupt handler

Im Quellcode laufen parallel 2 Timer, die beim Erreichen eines definierten Ereignisses einen Interrupt auslösen.
  • 1 Timer ISR wertet nur das Blinker An/Aus-Signal des FRM Steuergerätes aus
  • 1 Timer ISR sorgt für die zyklische und µSekunden genaue Aktualisierung der anzuzeigenden LED's

Auszug aus dem Quelltext für die Ereignisbehandlung des FRM-Interrupts, aufgerufen alle 10 Millisekunden.
Code: 
/*------------------------------------------------------------------------------
name:           FRMSignal_ISR
description:    this routine detects the blinker signal on the RC port (FRM signal)
------------------------------------------------------------------------------*/
void FRMSignal_ISR (void)
{
    if(Port_ReadBit(PORT_RC)) // check RC port for FRM trigger (blinker signal on PD6, port RC)
    {
        if (!FRMisActive)
        {
#ifndef DEBUG_ON
          SwitchCurrencyByPassS4 (true);  // lustig: verbrate ab jetzt ordentlich Strom, damit das FRM-Steuergerät von einer brennenden Blinker-Glühbirne ausgeht und keine Fehlermeldung liefert!!
#endif
          FRMisActive = true;
          FRMcycle++;
        }
    }
    else
    {
        FRMisActive = false;
        if (BlinkerIsActive)
        {
          SET_LEDS_OFF(true); // switch off all LED groups
          BlinkerIsActive=false;
        }
        BlinkerCycle=FRMcycle;
        SwitchCurrencyByPassS4 (false); // lustig: schalte den unsinnigen Stromverbrauch wieder ab
    }
#ifdef DEBUG_ON
//  Str_Printf(str, " FRMSignal_ISR: FRMcycle, BlinkerCycle, FRMisActive, BlinkerIsActive, timeticks: %d %d %d %d %d\r", FRMcycle,BlinkerCycle,FRMisActive, BlinkerIsActive, timeticks);
//  Msg_WriteText(str);  // Wert ausgeben
#endif
  Irq_GetCount(INT_TIM2COMP); // finish irq
}

Verrückt, oder?
Wir reden hier schließlich nur über einen Blinker im Auto!
 
Zuletzt bearbeitet:
Na, is es schon bereit zum vervielfachen oder ist es bisher nur für den Eigengebrauch?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten