• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

Reaktives Licht mit Attiny13V in C

thomas_st

Geowizard
Hallo zusammen,

hier kommt meine Variante des Reaktivlichtes – basierend auf dem im Nachbartread Reaktives Licht mit Atmel AVR entwickelten Schaltung und den dort gemachten Überlegungen, wie das Ganze möglichst stromsparend zu realisieren ist.

Reaktivlicht in C – Teil 1: Schaltung und Programm

Die verwendete Schaltung entspricht der aus Abbildung 5 des Kochbuches, nutzt also einen digitalen Ausgang des Attiny als ein- und ausschaltbare Spannungsquelle für den Spannungsteiler LDR/R2.
schaltungrlv0na2.gif

Der Grund hierfür ist der relativ niederohmige Spannungsteiler – den Widerstandswert für R2 hatte ich so optimiert wie im Ursprungstread angedeutet: maximale Spannungsdifferenz zwischen Hell und Dunkel.
Zwei LEDs hatte ich jetzt nur genommen, weil es einfach "schöner" ist – später könnte es dazu dienen (und ist momentan auch im Programm so realisiert), dass die eine LED den Nordwert morst und die andere gleichzeitig den Ostwert – ja ich bin fies ;) Ach so, die unterschiedlichen Vorwiderstände der LEDs sollen nur die unterschiedlichen Helligkeiten der verwendeten roten und blauen LED ausgleichen.
Das Ganze sieht dann auf dem Board folgendermaßen aus (die Tiefenschärfe ist jetzt nicht so prickelnd, aber ich hoffe, dass man es dennoch erkennt):

Ach übrigens: wer findet die Abweichung zum obigen Schaltplan?

Das Programm habe ich in C geschrieben, da ich mit dieser Programmiersprache einfach vertauter bin. Dani_B hatte ja vor ca. 1 Jahr schon das Originalprogramm - noch mit der LED als Lichtsensor – in C "übersetzt; jetzt kommt also die Variante für den LDR. Das Programm setzt auf den Watchdog timer (WDT) interrupt, was dazu führt, dass das "Hauptprogramm" eigentlich keines mehr ist. Die Hauptarbeit liegt jetzt in der interrupt service routine (ISR) des WDT.
Leider ist der Code etwas länger geworden, was aber auch an einer etwas umfangreichen Kommentierung liegen kann. Der Code gefällt mir insofern noch nicht, dass er mit Konstanten arbeitet, die in die Register geschrieben werden (insbesondere in initChip(); ). Das macht zwar einerseits den HEX-Code kleiner, andererseits aber das Ganze auch unflexibel und schwer zu warten. Nun aber der Code:
Code:
/*
 * -------------------------------------------------------------------------
 * Reaktivlicht für Nachtcaches mit Atmel ATTINY 13V
 * Version 0.4 für Schaltung RL_V0.3
 * -------------------------------------------------------------------------
 *
 * entstanden im Elektronik-Unterforum auf http://www.geoclub.de
 * (http://www.geoclub.de/ftopic5753.html)
 *
 * Umsetzung des Reaktivlichtes mit LDR wie von windi entworfen
 * in C, wobei die Stromaufnahme so weit als möglich minimiert wurde.
 *
 * Thomas Stief <[email protected]>
 */

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/sleep.h>
#include <avr/wdt.h>
#include <avr/pgmspace.h>
#include <stdint.h>

/* =================================================================
   Deklarationen
   ================================================================= */

typedef uint8_t BYTE;
typedef int8_t SBYTE;
typedef uint16_t WORD;
typedef int16_t SWORD;

typedef int8_t BOOL;

#define TRUE (0==0)
#define FALSE (0!=0)

void doBlink(void);

/* =================================================================
   Globale Variable des Zustands
   ================================================================= */

WORD wLetzteHelligkeit;	// Zwischenspeicher des letzten Helligkeitswerts
BOOL fNachtMode;  		// == TRUE wenn der Nachtmodus aktiv ist
BOOL fBlinkMode;		// == TRUE wenn die LED blinken soll
BOOL fPrepareTag;		// == TRUE wenn im Tagmodus die Versorgung des LDR 
						//    aktiviert ist und die Abfrage erfolgen kann
WORD wTagCounter;		// Zähler wie oft "Tag" gemessen wurde

WORD wBlinkCounter;		// Zähler für den Blinkgenerator

/* =================================================================
   Initialisierung des Chips
   
   In: nix
   Out: nix
   ================================================================= */
void initChip(void)
{
	// ADC
	// ------------------------------------------------------
											
	// Aktivieren ADC2 (Pin 3)				// xxxxxx10
	// Vcc als Referenzspannung				// x0xxxxxx
	// Ergebnisse nach Rechts ausgerichtet 	// xx0xxxxx
	ADMUX = 0x02;							// 00000010

	// Digital IO
	// ------------------------------------------------------
	// Erstmal alles auf Eingang 
	// außer für LED1, LED2, die ADC_VERSORGUNG 			// xx001011
	DDRB = 0x0b;											// 00001011
	// Pullup-Widerstände für alles, außer für die
	// digitalen Ausgängen und dem analogen Eingang ADC2 
	// (PB4) aktivieren										// xx100100
	//   => Soll Strom sparen
	PORTB = 0x24;											// 00100100
	// Die nicht gebrauchten Digitalen Eingänge deaktivien
	//   => spart Strom
	// es werden keine Digitalen Eingänge gebraucht			// xx111111
	DIDR0 = 0x3F;											// 00111111
}

/* =================================================================
   Einlesen des analogen Eingangs
     die Funktion startet die Erfassung des Analogsignals und
	 gibt den aktuellen Wert zurück
   
   In: nix
   Out: (WORD) Aktuelles Analogsignal
   ================================================================= */
WORD readADC(void)
{
	WORD wValue;
	
	// Vorbereitung des Schlafenlegens des Prozessors
	//  --> Prozessor in den ADC Noise reduction mode schicken: 
	//      tiefster Schlafmodus, der ein Erwachen durch ADC gestattet
	set_sleep_mode(SLEEP_MODE_ADC);
	sleep_enable();
	sei();

	// ADC einschalten,				// 1xxxxxxx
	// ADC starten					// x1xxxxxx
	// kein AUTO Trigger			// xx0xxxxx
	// ADC Interrupt aktivieren		// xxxx1xxx
	// Teiler des ADC-Taktes (1:2)	// xxxxx000
	
	ADCSRA = 0xc8;					// 11001000
   							// Fehlerkorrektur (danke NC666):
							// der ursprüngliche Wert 0xd8 ist falsch, da er auch ADIF setzt
	//ADCSRA = 0x88;				// 10001000
   							// Vorschlag NC666: es geht wohl auch ohne gesetztes Bit ADSC
							// dann startet die ADC im Ruhemodus automatisch - habe ich noch nicht getestet

	// Prozessor schlafen schicken
	sleep_cpu();
	// Guten Morgen, Prozessor! Gut geschlafen ...
	// ... und damit du nicht wieder einschläft:
	sleep_disable();
	cli();

	// Einlesen des Wertes (die unteren zwei Bit von ADCH 
	// (um 8 bit nach links geschoben) + ADCL
	wValue = ((WORD)ADCL + (((WORD)(ADCH))<<8)) & 0x03ff;
	
	// ADC ausschalten
	ADCSRA = 0x00;					// 00000000
	
	return wValue;
}

/* =================================================================
   Interrupt service routine für die Beendigung der AD-Wandlung
		sie macht eigentlich gar nichts
   ================================================================= */
ISR(SIG_ADC)
{
}

/* =================================================================
   Werte auf den digitalen Ausgängen ausgeben
	 mögliche Zustände:
		ON     (= 1)  LED wird eingeschaltet (auf Vcc gezogen)
		OFF    (= 0)  LED wird ausgeschaltet (auf Masse gelegt)
		TOGGLE (= 2)  Zustand der LED wird gewechselt
   
   In: (SBYTE) sbLedID
	   (SBYTE) sbLedChange
   Out: nix
   ================================================================= */

#define LED1 PORTB0
#define LED2 PORTB1
#define ADC_VERSORGUNG PORTB3

#define ON 1
#define OFF 0
#define TOGGLE 2

void controlDO(SBYTE sbLedID, SBYTE sbLedChange)
{
	switch (sbLedChange)
	{
		case ON:	// Einschalten
			PORTB |= _BV(sbLedID);
			break;
		case OFF:	// Ausschalten
			PORTB &= ~_BV(sbLedID);
			break;
		case TOGGLE:// Zustand tauschen
			PORTB ^= _BV(sbLedID);
			break;
		default:
			break;
	}
}

/* =================================================================
   Initialisierung des Watchdogtimers und setzen des 
     Auswachintervalls
     er wird auf den Interruptmode gesetzt
   
   In: (BYTE) bTimeConst
   Out: nix
   ================================================================= */
void setWD(BYTE bTimeConst)
{
	// Interrupt ausschalten
	cli();
	// Zeit setzen
	wdt_enable(bTimeConst);
	// Watchdog-RESET deaktivieren (wir wollen nur den Interrupt)
	//   erst das entsprechende Bit im MCUSR löschen, sonst hat die Änderung
	//   im WDTCR kein Effekt
	MCUSR &= ~_BV(WDRF);
	// Watchdog Timer Interrupt einschalten 					WDIE -> 1
	// um den Reset auszuschalten, muss das "Sicherungsbit"
	//   WDCE muss gesetzt sein									WDCE -> 1
	// Reset ausschalten										WDE  -> 0
	WDTCR = (WDTCR & ~_BV(WDE)) |_BV(WDCE) |_BV(WDTIE);
	// Interrupt einschalten
	sei();
}

/* =================================================================
   Interrupt service routine zur Bearbeitung des Watchdog interrupts
        =>	eigentlich das Hauptprogramm
   ================================================================= */
#define SCHWELLE_NACHT       (WORD)500
#define SCHWELLE_TAG         (WORD)530
#define SCHWELLE_TAG_COUNTER (WORD)64
#define SCHWELLE_BLINKMODE   (SWORD)1
#define WARTEZEIT_NACHT      WDTO_120MS
#define WARTEZEIT_TAG        WDTO_8S

ISR(SIG_WATCHDOG_TIMEOUT)
{
	WORD wHelligkeit;
	SWORD swDeltaHelligkeit;
	
	if(!fNachtMode && !fPrepareTag)	  // Wenn Tag ist und die Versorgung des
	{								  // LDRs deaktiviert ist anschalten und
		controlDO(ADC_VERSORGUNG,ON); //  etwas warten; erst dann abfragen
		fPrepareTag = TRUE;
		setWD(WARTEZEIT_NACHT);
	}
	else
	{
		wHelligkeit = readADC();
		swDeltaHelligkeit = wHelligkeit - wLetzteHelligkeit;
		wLetzteHelligkeit = wHelligkeit;

		if(!fNachtMode) 			  // Alles was am Tage zu machen ist
		{	// --> Testen ob's inzwischen dunkel ist und der Nachtmodus 
			//aktiviert werden kann
			if(wHelligkeit < SCHWELLE_NACHT)    // Wenn es dunkel ist
			{									// => ab in den Nachtmodus
				fNachtMode = TRUE;
				setWD(WARTEZEIT_NACHT);
			}
			else							// Wenn es immer noch hell ist 
			{								// => in 8s nochmal testen
				controlDO(ADC_VERSORGUNG,OFF);
				fPrepareTag = FALSE;
				setWD(WARTEZEIT_TAG);
			}
		}
		else 				// Alles was in der Nacht zu erledigen ist
		{
			if(swDeltaHelligkeit > SCHWELLE_BLINKMODE
				&& !fBlinkMode)	// Wenn die Helligkeit in letzten Zyklus
			{					// angestiegen ist => etwas rumblinken
				wBlinkCounter = 0;		// Blinkgenerator initialisieren
				fBlinkMode = TRUE;		// und Blink-Flag setzen
			}
			
			if(fBlinkMode)			// Wenn Blinkmodus aktiv
			{						// => rumblinken und EXIT
				doBlink();
				setWD(WARTEZEIT_NACHT);
			}
			else			// Wenn Blinkmodus nicht aktiv
			{				// => testen ob es inzwischen hell geworden ist
				if(wHelligkeit > SCHWELLE_TAG)	
				{ // Helligkeit übersteigt den Tagwert => ab in den Tagmodus
					wTagCounter++;						// aber nicht sofort
					if(wTagCounter > SCHWELLE_TAG_COUNTER)	
					{                       // sondern erst wenn es mehr als 
						fNachtMode = FALSE; // SCHWELLE_TAG_COUNTER x so war
						wTagCounter = 0;
						controlDO(ADC_VERSORGUNG,OFF);
						fPrepareTag = FALSE;
						setWD(WARTEZEIT_TAG);
					}
					else
					{
						setWD(WARTEZEIT_NACHT);
					}
				}
				else				// Wenn es immer noch dunkel ist	
				{					// => den Zähler wieder auf Null setzen
					wTagCounter=0;
					setWD(WARTEZEIT_NACHT);
				}
			}
		}
	}
}

/* =================================================================
   Blink-Routine - wird von der ISR des Watchdog aufgerufen
   
   In:  nix
   Out: nix
   ================================================================= */
// Morsecode für "N 50 12 345"
const BYTE bSequenz1[] PROGMEM = { 	0xe8, 0x0a, 0xa8, 0xee, 
									0xee, 0xe0, 0x2e, 0xee, 
									0xe2, 0xbb, 0xb8, 0x0a, 
									0xbb, 0x8a, 0xae, 0x2a, 
									0xa0, 0x00, 0x00, 0x00 };
// Morsecode für "E 008 54 321"
const BYTE bSequenz2[] PROGMEM = { 	0x80, 0xee, 0xee, 0xe3, 
									0xbb, 0xbb, 0x8e, 0xee, 
									0xa0, 0x2a, 0xa2, 0xab, 
									0x80, 0xab, 0xb8, 0xae, 
									0xee, 0x2e, 0xee, 0xe0 };
void doBlink(void)
{
	BYTE bByte,bBit;
	
	if(wBlinkCounter < 128)
	{
		// Byte aus dem Flashspeicher lesen (alles ab Bit 3 des Blinkzählers
		// bestimmt die Position des Bytes
		bByte = pgm_read_byte(&bSequenz1[(BYTE)(wBlinkCounter>>3)]);
		// Bit 0:2 bestimmen die Bit im Datenbyte, aber in umgedrehter
		// Reihenfolge
		bBit = 7 - (BYTE)(wBlinkCounter&7);
		// Testen ob das Bit gesetzt ist dann ...
		if((bByte&(1<<bBit)) != 0)
			controlDO(LED1,ON); // ... LED an
		else					// sonst ...
			controlDO(LED1,OFF);// ... LED aus

		// Das Ganze noch für die andere LED
		bByte = pgm_read_byte(&bSequenz2[(BYTE)(wBlinkCounter>>3)]);
		if((bByte&(1<<bBit)) != 0)
			controlDO(LED2,ON);
		else
			controlDO(LED2,OFF);
	}
	else	// Wenn die Sequenz zuende ist: LEDs ausschalten
	{
		controlDO(LED1,OFF);
		controlDO(LED2,OFF);
	}
	
	if(wBlinkCounter++ > 130) // Noch zwei Zyklen warten, dann ist die 
		fBlinkMode = FALSE;	  // Sequenz zu Ende und das Flag wird gelöscht
}


/* =================================================================
   Hauptprogramm
        => eigentlich macht es kaum etwas, außer den Prozessor zu
           initialisieren, den Watchdog zu starten und in eine
           Endlosschleife einzutreten
   ================================================================= */
int main (void)
{
	// Chip initialisieren
	initChip();
	// Zustand initialisieren
	fNachtMode = FALSE;
	wLetzteHelligkeit = 0;
	fBlinkMode = FALSE;
	wTagCounter = 0;
	fPrepareTag = FALSE;
	controlDO(ADC_VERSORGUNG,OFF);

	wBlinkCounter = 0;
	// Watchdog aktivieren und zwar für den Tagmodus
    setWD(WARTEZEIT_TAG);
	// Endlosschleife, die den Prozessor immer wieder schlafen schickt
    while(1)
	{
		set_sleep_mode(SLEEP_MODE_PWR_DOWN);
		sleep_enable();
		sleep_cpu();
	}
        
    return (0);
}
Die Aufgabe des Hauptprogramms liegt in der Initialisierung des Chips, der Zustandsvariablen und der Initialisierung des WDT auf den Tagmodus. Ab dann beschränkt es sich darauf, in einer Endlosschleife den Prozessor immer wieder schlafen zu schicken. Die Hauptarbeit hat die ISR des WDT. Diese wird am Tag vom WDT alle 8s und in der Nacht alle 120ms aufgerufen (siehe Konstanten). Ok, das ist auch nur die halbe Wahrheit: nach den 8s Schlaf im Tagmodus, wird erstmal die Spannungsversorgung des LDR eingeschaltet und anschließend der Prozessor für die "Nachtzeit" wieder schlafen geschickt. Erst dann erfolgt die Abfrage des analogen Eingangs. Was jetzt abläuft ist ähnlich dem BASIC Programm von windi: Abfrage of es dunkel ist => ab in den Nachtmodus.
Im Nachtmodus wird bei jedem Aufruf der ISR getestet, ob der Helligkeitspegel seid dem letzten Aufruf angestiegen ist -> blinken und ob die Helligkeit wieder über die Tagschwelle gestiegen ist -> Tagmodus.
Zum Blinken wird von der ISR eine separate Funktion (doBlink();) aufgerufen, in der alles weiter implementiert wird. Ich habe bei dem Programm allgemein auf Funktionen gesetzt, soweit ich es als sinnvoll erachtet habe -> der Code wird übersichtlicher. Die damit notwendigen Funktionsaufrufe kosten allerdings Zeit und auch Programmspeicher -> eventuell die Funktionen, die nur von einer Stelle aus aufgerufen werden, als INLINE deklarieren.
Den Programmcode habe ich mit WinAVR compiliert und mit PonyProg auf den Attiny gebrannt. Letzteres kam bei mir zum Einsatz, da es auch meinen exotischen seriellen Programmer kennt. Allerdings sollte der mit WinAVR mitgelieferte AvrDude des auch können, aber eine grafische Benutzerschnittstelle hat schon was ;)

So damit bin ich am Ende des 1. Teils und

to be continued ....

Edit: Code entsprechend Hinweis von NC666 korrigiert.
 
OP
T

thomas_st

Geowizard
Reaktivlicht in C – Teil 2: Reichweiten- und Stromverbrauchstests

Den Reichweitentest habe ich letzten Montag gegen 18:00 Uhr in den Oberräder Feldern gemacht, dort ist es relativ dunkel und das Ganze ist nicht so weit von meiner Wohnung weg.;) Also die Schaltung mit dem Experimentierboard am Wegesrad an eine Lenkertasche gelehnt, Position mit dem GPS markiert und dann in 50m Schritten von der Schaltung weg bewegt und überprüft, ob ich sie mit der Fenix L2D in der untersten Stufe (45Lumen) noch antriggern kann: bis 200m Entfernung ging das problemlos. Ab diesem Punkt gab es dann aber einige Probleme:
- das Antriggern ging in der untersten Stufe der Fenix nicht mehr problemlos; in der nächst höhere (60Lumen) war es dann aber wieder problemlos möglich
- die am Wegesrand stehende, blinkende Lenkertasche erregte doch leichtes Aufsehen, bei den erstaunlich häufig dort verkehrenden Radfahren ;)
- der Weg machte einen Knick – hätte ich wohl vorher mal überprüfen sollen
- es fing an zu regnen (mieses Timing)
- ich hatte arge Probleme, die LED des Boards noch zu erkennen (obwohl es eigentlich eine superhelle LED sein soll). @windi: was hast Du denn für eine LED bei deinem 650m Test gehabt. Auf dieser Entfernung hätte ich die LED mit Sicherheit nicht mehr erkennen können. Insbesondere der letzte Punkt hat mich dann zum Abbruch des Tests bewogen.
Also das Fazit: bis 200m geht es problemlos, größere Strecken muss ich an geeigneterer Stelle, geeigneterer Zeit und mit einer besseren LED auf dem Board nochmal überprüfen.

Nun zum Stromverbrauchstest. Hier muss ich gestehen, dass mich der Ehrgeiz gepackt hat und ich versucht habe, den Stromverbrauch so weit als möglich herunterzudrücken. Wobei ich noch ein paar Ideen hätte, wie er noch weiter gesenkt werden kann: die Zeit, die die LDR-Stromversorgung eingeschaltet wird, kann reduziert werden; möglicherweise bringt so etwas auch im Nachtmodus etwas, ... . Ob das sinnvoll ist, sein mal dahingestellt.
Zum Messen des Stromverbrauchs bin ich meiner Neugierde und der Empfehlung meines Kollegen gefolgt und habe diese mit einem Oszi aufgezeichnet (Spannungsabfall über einen 1kOhm Widerstand). Die Screenfotos kann man hier sehen:

Tagmodus (leider unscharf)

Nachtmodus
Man kann deutlich die sehr unterschiedlichen Stromaufnahmen über der Zeit erkennen. Teilweise werden bis zu 650µA aufgenommen (meine Vermutung: bei der Abfrage des ADC), dann haben wir da noch 200µA, 50µA und die Schlafphasen mit beinah 0. Auf was will ich hinaus: mit einem normalen Multimeter und insbesondere mit so einem Billigteil wie ich es habe, ist hier nichts zu wollen. Ich habe daher einen anderen Weg beschritten: Verwendung eines 4700µF Kondensators als Stromquelle und Messung dessen Spannung in Abhängigkeit von der Zeit. Das sieht dann für den Tagmodus so wie hier gezeigt aus:
stromflusstagmodusvm9.gif

Der Stromfluss lässt sich dann über I = C * DELTA U / DELTA t bestimmen.
Das Ganze habe ich dann 1.) für den nur mit dem Messgerät belasteten Kondensator, 2.) dem mit einem bekannten Widerstand und Messgerät belasteten Kondensator, 3.) für die Schaltung im Tagmodus + Messgerät und 4.) die Schaltung im Nachtmodus + Messgerät gemacht. Da die Spannung bei diesem Test sinkt, wird bei einer ohmschen Belastung auch der Stromfluss sinken. Daher die linearen Regressionen des Stromflusses, mit der dieser für U = 3V interpoliert werden kann. Folgende Stromflüsse ergeben sich:
1.) 3,0µA – das ist also der Verbrauch, der alleine auf Kosten des Messgerätes geht (1MOhm Eingangsimpedanz)
2.) 13,0µA – die gemessenen 16,0µA abzüglich der 3,0µA des "Leertests" aus 1.)
Da der Widerstand einen Wert von 215kOhm hatte (gemessen), hätte ich hier eigentlich 14,0µA bestimmen sollen => ca. 1µA Fehler
3.) Tagmodus: 4,1µA (gemessene 7,1µA abzüglich Nullwert)
4.) Nachtmodus: 8,4µA (gemessen 11,4µA abzüglich Nullwert)
Der Fehler der in Messung 2 deutlich wird, kann auf einen Fehler in der Kapazität des Kondensators zurückgeführt werden.
Es ist (glaube ich) sehr deutlich geworden, dass der Stromfluss (ohne LED) sehr weit nach unten zu drücken ist. Er liegt hier in einem Bereich, mit der die Schaltung mit einer 2000mAh Batterie für 320000 Stunden bzw. mehr als 36 Jahre laufen würde. Das Ganze wird also nur noch von der Selbstentladung der Batterien limitiert. Selbst das gelegentliche Blinken der LEDs sollte hier nicht mehr ins Gewischt fallen (besonders bei den superhellen LEDs, die ja im einstelligen mA-Bereich ziehen.

So damit bin ich erstmal am Ende. Das Ganze wird jetzt zusammengelötet – wenn ich viel Lust und Muse habe wird es wohl eine Leiterplatte geben; ansonsten wird es wohl nur die bei mir nicht so beliebte Lochrasterplatte – und dann kommt es zusammen mit zwei AA-Zellen in einen großen Petling oder mit einer CR123 in einen kleinen und das Ganze dann raus in den Wald.
So nun würde ich mich über viele Kommentare zu diesem Programm, der Schaltung und den Testmethoden freuen.

Viele Grüße,
Thomas(_st)
 

upigors

Geowizard
Ich hab das jetzt erstmal nur überflogen, jedoch das Problem mit der Sichtbarkeit der LED ab ca 400m hatte ich, trotz ultraheller LED, auch. Hab dann sone einfache Fassung aus Edelstahl genommen und obwohl mans nicht glauben mag, die wirkt wie ein Reflektor und erhöht die Sichtbarkeit um einiges.....


Gruß Uwe
 

stonewood

Geowizard
Hallo,

zwei Sachen fallen mir an der Schaltung auf:
- der LDR hängt zwischen '+' bzw. PB3 und dem ADC an PB4. Sinnvoller wäre es den LDR und den Widerstand zu tauschen, also LDR an GND und PB4, den Widerstand zwischen PB3 und PB4. Dann ist auch sichergestellt daß die Spannung am ADC <2,54V ist (zumindest im dunklen). Der ADC wirft darüber einfach nur die Maximalspannung raus. Effekt ist dann daß bei voller Beleuchtung (Tag) des LDR dann die Spannung bei 3V liegt, und im interessanten Bereich (Dunkel) die Spannung dann von 0 bis z.B. 1,5V liegt.
- 200 und 300 Ohm an der LED mögen vielleicht für 5V Spannungsversorgung gut sein, aber ich hab mit um 56 Ohm viel bessere Erfahrungen gemacht. Die LED ist dann wirklich 'Hell', sollte damit aber noch im 20mA-Bereich bleiben. Dann ist die sicherlich 1km zu sehen, eher mehr.

Ansonsten: Wie programmierst Du eigentlich die Atmels? Bascom nimmt einem ja da einiges ab, aber wie funktioniert das mit einer C-Umgebung?
 
OP
T

thomas_st

Geowizard
upigors schrieb:
Hab dann sone einfache Fassung aus Edelstahl genommen und obwohl mans nicht glauben mag, die wirkt wie ein Reflektor und erhöht die Sichtbarkeit um einiges.....
Ok, gerade mal bei Conrad vorbei gesehen (schließlich fahre ich ja 2x pro Tag unter dem Geschäft durch) und solche Fassungen besorgt ... mal sehen ob’s klappt.

stonewood schrieb:
zwei Sachen fallen mir an der Schaltung auf:
- der LDR hängt zwischen '+' bzw. PB3 und dem ADC an PB4.
Das war die ursprüngliche Variante, die hatte ich beibehalten.

stonewood schrieb:
Sinnvoller wäre es den LDR und den Widerstand zu tauschen, also LDR an GND und PB4, den Widerstand zwischen PB3 und PB4.
Probiere ich mal aus - wer es nachmachen möchte: hier sind einige Änderungen am Quelltext nötig, da nunmehr der Messwert des ADC mit steigender Helligkeit ab nimmt.


stonewood schrieb:
Dann ist auch sichergestellt daß die Spannung am ADC <2,54V ist (zumindest im dunklen). Der ADC wirft darüber einfach nur die Maximalspannung raus.
Irgendwie stehe ich auf dem Schlauch: warum sollte der ADC bei Werten über 2,54V in Overload gehen? Ich dachte, indem ich die Referenzspannung des ADC auf Vcc setze (Initialisierung des ADCs in initChip()) wird der Maximalwert 1023 erst bei ADC=Vcc also ca. 3V ausgegeben.

stonewood schrieb:
- 200 und 300 Ohm an der LED mögen vielleicht für 5V Spannungsversorgung gut sein, aber ich hab mit um 56 Ohm viel bessere Erfahrungen gemacht. Die LED ist dann wirklich 'Hell', sollte damit aber noch im 20mA-Bereich bleiben. Dann ist die sicherlich 1km zu sehen, eher mehr.
Schiebe es auf meine Vorsicht: ich wollte die LEDs nicht grillen. Aber stimmt: 20mA ziehen die bei Weitem nicht: die Rote am 330 Ohm zieht 3,3mA; die Blaue am 220 Ohm zieht 1,3 mA)

stonewood schrieb:
Ansonsten: Wie programmierst Du eigentlich die Atmels? Bascom nimmt einem ja da einiges ab, aber wie funktioniert das mit einer C-Umgebung?
WinAVR beinhalte den Compiler, eine Editor mit einer Schnittstelle zu make, die includes und libraries sowie avrdude. Was man machen muss, ist ein Makefile schreiben: meines habe ich irgendwo her - eigentlich dachte ich, dass ich es im Ursprungstread gefunden hatte (von Dani_B?); aber ich finde es dort nicht mehr. Ich vermute mal, dass hier keine Copyrights verletzt werden, wenn ich es hier nochmal rein setze - lösche es aber bei Bedarf wieder raus:
Code:
#Minimal Makefile für ein einfaches avr-gcc Projekt
#Getestet mit der WinAVR (http://winavr.sourceforge.net/) Distribution vom 22.01.07

#Die folgenden 3 Make Targets sind definiert
# - make all: compiliert den Sourcecode, erzeugt das .hex file
# - make clean: löscht alle Files, die beim compilieren generiert wurden
# - make program: überträgt das generierte .hex file in den Mircocontroller über den einfachen seriellen Programmieradapter

#Achtung: Eigene Anpassungen  sollten normalerweise nur in 1.) und 2.) nötig sein

# 1.) Microcontrollerspezifisches
MCU            = attiny13
F_CPU          = 128000

# 2.) Target und Source Files
TARGET         = RL
SRC            = $(TARGET).c

# 3.)  Compilerflags
# implizite Regel: n.o is made automatically from n.c with a command of the form '$(CC) -c $(CPPFLAGS) $(CFLAGS)'. 
OPT    = -O1 -gdwarf-2
CDEFS  = -DF_CPU=$(F_CPU)UL
CFLAGS = -Wall $(OPT) -mmcu=$(MCU) $(CDEFS)

# 4.)  Linkerflags
LDFLAGS = -Wl,-Map,$(TARGET).map
LIBS    =

# 5.) Define programs and commands.
CC = avr-gcc
OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump

# 6.) Regeln
OBJ = $(SRC:%.c=%.o)

%.elf: $(OBJ)
	$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)

%.lss: %.elf
	$(OBJDUMP) -h -S $< > $@

%.hex: %.elf
	$(OBJCOPY) -j .text -j .data -O ihex $< $@


# 7.) Make Targets
.PHONY : all clean program

all: $(TARGET).elf $(TARGET).lss $(TARGET).hex

clean:
	rm -rf *.o *.elf *.hex *.map *.lss *.lst

program: $(TARGET).hex
	avrdude -q -q -p $(MCU) -c ponyser -P com1 -U flash:w:$(TARGET).hex:i
Man drückt dann im Editor einfach nur noch "make all" und erhält ein *.hex file. Dieses kann man entweder per avrdude auf den Atmel schieben oder wie ich per Ponyprog. Letzteres biete auch die Möglichkeit die Fusebits zu setzen.

stonewood schrieb:
thomas_st schrieb:
Ach übrigens: wer findet die Abweichung zum obigen Schaltplan?

Äh - der LDR hängt nicht wirklich an Pin 1? Das ist doch Reset?!? Was hast Du mit den Fuses angestellt?
Bingo! Doch, er hängt an Pin 1 und zwar zum Zeitpunkt wo ich das Foto gemacht habe auch mit voller Absicht. Ich war der Meinung, dass der Reset-Pin (PORTB5) als ganz normaler digitaler Ausgang zu nutzen ist und nur bei einem digitalen Eingang Probleme auftreten. Das Ganze funktionierte auch relativ gut, liegt doch der Reset-Pin auf 2,8 V - also ausreichend für den LDR. Was aber nicht klappt, ist das Strom sparen. Und so wunderte ich mich, dass ich im Tagmodus Ströme im Bereich von 15µA hatte - mehr als im Nachtmode.

Meine Fusebits sehen übriges so aus (gerade frisch aus dem Atmel gezogen):
fuseew8.jpg


Viele Grüße,
Thomas(_st)
 

stonewood

Geowizard
thomas_st schrieb:
stonewood schrieb:
zwei Sachen fallen mir an der Schaltung auf:
- der LDR hängt zwischen '+' bzw. PB3 und dem ADC an PB4.
Das war die ursprüngliche Variante, die hatte ich beibehalten.

stonewood schrieb:
Sinnvoller wäre es den LDR und den Widerstand zu tauschen, also LDR an GND und PB4, den Widerstand zwischen PB3 und PB4.
Probiere ich mal aus - wer es nachmachen möchte: hier sind einige Änderungen am Quelltext nötig, da nunmehr der Messwert des ADC mit steigender Helligkeit ab nimmt.


stonewood schrieb:
Dann ist auch sichergestellt daß die Spannung am ADC <2,54V ist (zumindest im dunklen). Der ADC wirft darüber einfach nur die Maximalspannung raus.
Irgendwie stehe ich auf dem Schlauch: warum sollte der ADC bei Werten über 2,54V in Overload gehen? Ich dachte, indem ich die Referenzspannung des ADC auf Vcc setze (Initialisierung des ADCs in initChip()) wird der Maximalwert 1023 erst bei ADC=Vcc also ca. 3V ausgegeben.
Tja, das kommt drauf an: Ich hatte gerade den ATMega im Kopf, der hat auch 2.56V als Vref. Aber in der anderen Richtung kannst Du dann auch 1,1 V als Vref nehmen, vielleicht wird das ganze dann noch etwas empfindlicher?

Ups, hab ich schon wieder falschrum gedacht? 1,1V geht ja auch nicht ... :(
thomas_st schrieb:
Schiebe es auf meine Vorsicht: ich wollte die LEDs nicht grillen. Aber stimmt: 20mA ziehen die bei Weitem nicht: die Rote am 330 Ohm zieht 3,3mA; die Blaue am 220 Ohm zieht 1,3 mA)
Hmm, dann brauchst Du ja schon eine low-power LED mit 2 mA: Mit 1,3 mA ist die zwar blau, aber nicht wirklich hell. Und nicht umsonst steht auf den Beuteln mit den High-Power LEDs ja ab und an drauf daß man nicht reinsehen soll: Die Dinger können ziemlich hell werden, und da ist sogar noch die Reflektion an 'ner weißen Wand hell.
thomas_st schrieb:
WinAVR beinhalte den Compiler, eine Editor mit einer Schnittstelle zu make, die includes und libraries sowie avrdude. Was man machen muss, ist ein Makefile schreiben: meines habe ich irgendwo her - eigentlich dachte ich, dass ich es im Ursprungstread gefunden hatte (von Dani_B?); aber ich finde es dort nicht mehr. Ich vermute mal, dass hier keine Copyrights verletzt werden, wenn ich es hier nochmal rein setze - lösche es aber bei Bedarf wieder raus:
Ah, OK. Braucht man also nichts weiter als WinAVR und PonyProg. Dachte man braucht da noch nen eigenen Compiler. Muß ich bei Gelegenheit auch mal ausprobieren, insbesondere da man auf den Megas ja schnell an die 4K Codegrenze vom Bascom kommt. Und C ist eh besser. :wink:
thomas_st schrieb:
Bingo! Doch, er hängt an Pin 1 und zwar zum Zeitpunkt wo ich das Foto gemacht habe auch mit voller Absicht. Ich war der Meinung, dass der Reset-Pin (PORTB5) als ganz normaler digitaler Ausgang zu nutzen ist und nur bei einem digitalen Eingang Probleme auftreten. Das Ganze funktionierte auch relativ gut, liegt doch der Reset-Pin auf 2,8 V - also ausreichend für den LDR. Was aber nicht klappt, ist das Strom sparen. Und so wunderte ich mich, dass ich im Tagmodus Ströme im Bereich von 15µA hatte - mehr als im Nachtmode.
Ah, OK, sieht schon etwas merkwürdig aus. Man kann ja per Fuse auch den Reset-Pin als normalen I/O-Pin definieren - dann braucht man aber auch einen High Voltage Programmer der dem Atmel auch ein neues Programm aufbrennen kann. Das einfache Parallelkabel funktioniert dann nicht mehr, da ja eben ein 'Reset-Pin auf LOW' keinen Reset mehr auslöst und damit die Programmierung nicht mehr freischaltet. Deshalb auch die Frage nach den Fuses. Wenn Du da nichts geändert hast ist eben der Reset-Pin auch nur dafür zu gebrauchen.
 
OP
T

thomas_st

Geowizard
stonewood schrieb:
Ah, OK. Braucht man also nichts weiter als WinAVR und PonyProg. Dachte man braucht da noch nen eigenen Compiler. Muß ich bei Gelegenheit auch mal ausprobieren, insbesondere da man auf den Megas ja schnell an die 4K Codegrenze vom Bascom kommt. Und C ist eh besser. :wink:
Einen Compiler bedarf es nicht mehr: WinAVR beinhaltet den gcc für die AVRs. Ponyprog bräuchte man eigentlich auch nicht, da AvrDude das genauso kann. Das gepostete Makefile beinhaltet ja auch ein Target, welches das Programmieren des Chips via AvrDude durchführt (make program), das habe ich aber nicht getestet und kann dazu also auch nichts sagen.

stonewood schrieb:
[Reset-Pin belegt]
Ah, OK, sieht schon etwas merkwürdig aus. Man kann ja per Fuse auch den Reset-Pin als normalen I/O-Pin definieren - dann braucht man aber auch einen High Voltage Programmer der dem Atmel auch ein neues Programm aufbrennen kann.
PonyProg gestattet so per se gar nicht, dass man das Bit programmiert - siehe die ausgegraute Checkbox "RSTDISBL" neben "BODLEVEL1". Aber wie geschrieben: ich dachte, dass man ihn als Ausgang nutzen kann.

Viele Grüße,
Thomas(_st)
 

Windi

Geoguru
Ich würde empfehlen nur Vcc als Refernzspannung zu verwenden.
Somit ist es dem Programm nämlich egal wie hoch die Batteriespannung ist. Es funktioniert über den gesamten Spannungsbereich gleich gut da die sich das Teilungsverhältnis über den Spannungsteiler nicht ändert. Bei einer vorgegebenen Referenzspannung verschenkt man u. U. einen Teil der ADC-Auflösung.

Du könntest mal nachmessen wie groß der Unterschied in der Strom ist wenn man den Spannungsteiler ständig mit Strom versorgt oder nur dann wenn man eine ADC-Messung macht.
Soweit ich weiß benötigen die andauernden Schaltvorgänge (Pin Ein/Aus) auch Strom und somit dürfte es (besonders bei einem hochohmigen Spannungsteiler) energetisch günstiger sein den Spannungsteiler direkt an + zu hängen.

Ich bin aber noch nicht dahintergestiegen warum man den LDR und den Widerstand vertauschen sollte.
 

stonewood

Geowizard
Windi schrieb:
Ich würde empfehlen nur Vcc als Refernzspannung zu verwenden.
[..]
Ich bin aber noch nicht dahintergestiegen warm man den LDR und den Widerstand vertauschen sollte.

Hmm, im nachhinein frage ich mich das auch gerade ... :wink:
 
OP
T

thomas_st

Geowizard
Windi schrieb:
Ich würde empfehlen nur Vcc als Refernzspannung zu verwenden.
Wobei ich mich frage, ob man mit einer niedrigeren Referenzspannung, nicht eventuell den für die Nacht relevanten Bereich des LDR-Widerstands etwas dehnen könnte und damit die Empfindlichkeit erhöhen könnte. Das der ADC am Tag dann in den Overload geht, wäre eigentlich egal.

Windi schrieb:
Du könntest mal nachmessen wie groß der Unterschied in der Strom ist wenn man den Spannungsteiler ständig mit Strom versorgt oder nur dann wenn man eine ADC-Messung macht.
Habe ich gemacht und hier sind die Ergebnisse
Code:
Leertest: 3,1 µA
Test an 216kOhm: 13,1µA	(Soll: 13,9µA) 

                         Abschaltung der LDR-Versorgung	
                               JA               NEIN
Tagmodus (R2 = 220kOhm)       5,5µA (4,1µA)    18,8µA
Nachtmodus (R2 = 220kOhm)     8,0µA (8,4µA)     8,2µA
Tagmodus (R2 = 2,2MOhm)       4,0µA             6,9µA
Nachtmodus (R2 = 2,2MOhm)     7,3µA             7,7µA

Das Messverfahren ist das selbe, wie oben beschrieben. Die Werte
in den Klammern sind die damaligen Messwerte
Zunächst erstmal: warum ist da jetzt ein anderer Widerstandswert für R2? Ich bin nochmal in mich gegangen, und habe erkannt, das nicht der Unterschied zwischen Hell- und Dunkelwiderstand des LDRs für den optimalen Wert für R2 relevant ist, sondern der Unterschied zwischen dem Widerstandswert bei Dunkel und der bei "mit Lampe angeleuchtet". Der Widerstandswert des von mir verwendeten LDRs ist irgendwo jenseits von 40MOhm (=R1') und der Wert für "mit Lampe beleuchtet" habe ich mal mit 5MOhm (=R1'') angenommen. Der optimale Wert für R2 ist dann R2 = sqrt(R1' * R1'') = 14MOhm. Leider erkannt die Schaltung mit R2=10MOhm im Frankfurter Nachthimmel ein stahlenden Sommertag und bleibt im Tagmodus :roll: . Hier muss ich wohl noch mit der Tag/Nacht-Schwelle experimentieren. Mit 2,2MOhm klappte es dann aber.
Also für den neuen und den alten Widerstandswert für R2, jeweils Tag- und Nachtmodus und jeweils mit und ohne Abschaltung der LDR-Versorgung die Experimente gemacht.
Relativ unbeeinflusst zeigt sich der Nachtmodus - wunder über wunder - während der Tagmodus deutlich beeinflusst wird. Mit Abschaltung der Versorgung des LDRs ist der Stromverbrauch deutlich bis gravierend geringer.

Windi schrieb:
Soweit ich weiß benötigen die andauernden Schaltvorgänge (Pin Ein/Aus) auch Strom und somit dürfte es (besonders bei einem hochohmigen Spannungsteiler) energetisch günstiger sein den Spannungsteiler direkt an + zu hängen.
Das Schaltvorgänge Strom verbrauchen liegt daran, dass man nur endlich schnell schalten kann. Im Zwischenzustand zwischen An und Aus hat der Transistor einen Widerstand über den Leistung verbraten wird - das ist ja das Problem, was Intel und Co. bei den Milliarden Transistoren in deren Prozessoren haben.
Die Messungen deuten darauf hin, dass es hier eher keine Rolle spielt.

Neben den Messungen zur Stromaufnahme, habe ich auch nochmal Reichweitentests gemacht. An der Stelle habe ich mit dem Wert für "SCHWELLE_BLINKMODE" rumgespielt - also dem Wert, um den der Analogwert ansteigen muss, dass das Programm ein Anleuchten erkennt. Windi hat in seinem Programm einen Wert von 50 verwendet (erscheint mir sehr hoch - war der auch beim 650m Test so gesetzt?) während ich dort eine 1 hatte (ist nun wieder sehr niedrig). Also drei Attiny mit 1, 5 und 50 für diesen Wert programmiert und raus auf die Felder. Der mit 1 wollte gar nicht mehr aufhören zu blinken, also die Messungen nur mit den anderen beiden gemacht. Dabei muss ich schon sagen: es macht echt Spaß im Dunkeln auf den Oberräder Feldern, bei nasskaltem Wetter, mit vor Kälte steifen Fingern Prozessoren zu wechseln :twisted: . Aber hier die Werte, wieder mit der Fenix L2D gemacht.
Code:
SCHWELLE_BLINKMODE
       =5    =50

 50m   45     45
100m   45     60
150m   45     90 (schwierig)
200m   45    135
250m   45    kein Auslösen mehr möglich
300m   60
350m   60
400m   90
450m  135
500m  der Weg war zu Ende 

Die Werte geben die Schaltstufe der Fenix an, mit der ein
Auslösen möglich war.
Man erkannt gut, dass 300m relativ problemlos zu realisieren sind; darüber wird es dann zunehmend schwieriger. Allerdings hatte ich kein 100% freies Sichtfeld, so dass hier Bewuchs gestört haben kann. Auch war es eben nicht ganz dunkel. Mit dem hohen Wert für SCHWELLE_BLINKMODE ging es zwar kaum Fehlauslösungen aber die Empfindlichkeit geht dann gravierend in den Keller.

So weit die aktualisierten Messungen und noch eine gute Nacht,
Thomas(_st)
 

Windi

Geoguru
thomas_st schrieb:
Windi hat in seinem Programm einen Wert von 50 verwendet (erscheint mir sehr hoch - war der auch beim 650m Test so gesetzt?)
Ja, war er.
Ich habe damals auch mit niedrigeren Werten experimentiert. Dabei kam es immer wieder zu Fehlauslösungen so dass ich diesen Wert schrittweise erhöht habe. Ich glaube bei 30 war es dann o.k. Nochmals 20 als Sicherheitszuschlag und so war ich bei 50. Ich habe seitdem auch keinen anderen Wert mehr versucht da ich mit der damaligen Reichweite bereits sehr zufrieden war.
Eventuell habe ich auch einen anderen LDR im Einsatz der empfindlicher ist. Ich verwende immer den A906014 von Reichelt. Der hat einen sehr hohen Dunkelwiderstand und einen sehr niedrigen Hellwiderstand. Für unseren Anwendungsfall also ideal.
 

chr2k

Geomaster
Windi schrieb:
Eventuell habe ich auch einen anderen LDR im Einsatz der empfindlicher ist. Ich verwende immer den A906014 von Reichelt. Der hat einen sehr hohen Dunkelwiderstand und einen sehr niedrigen Hellwiderstand. Für unseren Anwendungsfall also ideal.

Du hattest in dem Reaktivlicht Thread auch mal gesagt das du den von Conrad (183563) im Einsatz hast.
Abgesehen vom Preis scheint der von Reichelt noch bessere Widerstanddswerte zu haben als der von Conrad, sehe ich das richtig? Reagiert der Reichelt LDR noch besser/empfindlicher als der von Conrad?

Danke

Christian
 

Windi

Geoguru
chr2k schrieb:
Du hattest in dem Reaktivlicht Thread auch mal gesagt das du den von Conrad (183563) im Einsatz hast.
Das muss aber schon sehr sehr lange her sein.

chr2k schrieb:
Abgesehen vom Preis scheint der von Reichelt noch bessere Widerstanddswerte zu haben als der von Conrad, sehe ich das richtig? Reagiert der Reichelt LDR noch besser/empfindlicher als der von Conrad?
Mit dem Reichelt-Teil habe ich die 650 Meter geschafft.
 
OP
T

thomas_st

Geowizard
Windi schrieb:
[Schaltschwelle Blinkmodus = 50]
Ja, war er.
Ich habe damals auch mit niedrigeren Werten experimentiert. Dabei kam es immer wieder zu Fehlauslösungen so dass ich diesen Wert schrittweise erhöht habe.
Fehlauslösungen hatte ich bei 5 nicht mehr, allerdings bei 1 naturgegeben schon - irgendwann muss es ja mal heller werden ;) Mir fehlt die Möglichkeit doch sehr, den aktuellen ADC-Wert irgendwie abzulesen (eine Schaltung, wie von Ralf am 16.Dez.'06 vorgestellt und mit den Worten "Dinge, die die Welt nicht braucht oder Wie hell ist denn jetzt meine Nacht?" beworben, fehlt mir halt noch - na ja die Attiny 2313 sind bestellt, dann baue ich sie mir selbst ;).

Windi schrieb:
Eventuell habe ich auch einen anderen LDR im Einsatz der empfindlicher ist. Ich verwende immer den A906014 von Reichelt.
Könnte sein. Meiner ist von Conrad, und dort nur als A9060 bezeichnet - die folgenden Ziffern sind nicht angegeben.

Noch eine kleine Story von den Reichweitentests gestern Abend. Die Schaltung hatte ich N50°06.155' E008°43.995' aufgebaut, auf einem asphaltieren Weg der durch die Oberräder Felder führt und bin dann nach und nach in westlicher Richtung weg. Dieser Weg wird anscheint von den Anwohnern als mehr oder weniger offizielle Straße für ihre PKW genutzt. Es war schon recht lustig zu sehen, wie die Autofahrer reagierten, als sie mit ihren Scheinwerfern die Schaltung antriggerten und auf einmal rote und blaue LEDs aus der Dunkelheit ihnen entgegen blinkten :twisted:

Viele Grüße,
Thomas(_st)
 
OP
T

thomas_st

Geowizard
chr2k schrieb:
Windi schrieb:
Ich verwende immer den A906014 von Reichelt. Der hat einen sehr hohen Dunkelwiderstand und einen sehr niedrigen Hellwiderstand.

Du hattest in dem Reaktivlicht Thread auch mal gesagt das du den von Conrad (183563) im Einsatz hast.
Abgesehen vom Preis scheint der von Reichelt noch bessere Widerstanddswerte zu haben als der von Conrad, sehe ich das richtig? Reagiert der Reichelt LDR noch besser/empfindlicher als der von Conrad?
Der mit der Bestellnummer 183563 (Typ:A1060) hat aber durch die Bank kleinere Widerstandswerte als der A9060 (Bstellnummer: 145475): im Dunkeln fast um den Faktor 4.

Viele Grüße,
Thomas(_st)
 

Windi

Geoguru
thomas_st schrieb:
Es war schon recht lustig zu sehen, wie die Autofahrer reagierten, als sie mit ihren Scheinwerfern die Schaltung antriggerten und auf einmal rote und blaue LEDs aus der Dunkelheit ihnen entgegen blinkten :twisted:
Das ist mir bei meinen Versuchen auch passiert.
Ich habe meine Versuche an einer Allee durchgeführt auf der so gut wie nie ein Auto fährt. Wie es der Teifel will kamen natürlich doch 2 Wägen.
Die haben bestimmt auch recht dumm geschaut als es auf dem Dach meines Autos plötzlich zu blinken angefangen hat.

Zur "Grundlagenforschung" habe ich übrigens ein Board von http://www.myavr.de mit einem Mega8 drauf verwendet.
LC-Display angesteckt uns dann hab ich mir den LDR-Wert direkt anzeigen lassen. Und dann so lange rumexperimentiert und Bauteile getauscht bis das Ergebnis zufriedenstellend war.
 

waste1

Geocacher
thomas_st schrieb:
Relativ unbeeinflusst zeigt sich der Nachtmodus - wunder über wunder - während der Tagmodus deutlich beeinflusst wird. Mit Abschaltung der Versorgung des LDRs ist der Stromverbrauch deutlich bis gravierend geringer.
Das ist kein Wunder, weil nachts der LDR hochohmig ist und deswegen kein Querstrom fließt.

Ein Schwellwert von 1 ist viel zu unsicher. Da gibt es prinzipbedingt schon Fehlauslösungen, weil der ADC immer um 1 schwanken kann.

Waren die Reichenweitenversuche jetzt mit 220kOhm oder mit höherem Widerstand?

Gruß
Waste1
 
Oben