Das geteilte Reaktivlicht

[thomas_st]

Hier jetzt zu viele Befürchtungen und was währe wenns zu äußern könnte ihm auch den Spaß daran rauben.

Mach Dir keine Sorgen - ich habe diese Diskussion ja gewünscht Irgendwann wird man betriebsblind und erkennt Schwierigkeiten oder unlogische Rätsel nicht mehr. Daher ja die Frage ... Aber ich denke, dass ich die Probleme / Schwierigkeiten jetzt erkannt habe ... und nun muss es sich erstmal beweisen

Ich denke, das ist auch alleine zu lösen - so dass in diesem Fall nur noch ein Cacher pro RL nötig ist

Das klingt gut, zählen klappt noch

... noch alle Finger dran

- aber was soll ich sagen. Batterien richtig herum angeschlossen, zusammengebaut und es funktioniert alles ... und kühlt langsam wieder ab *uff*

Tip: Wenn man Pfostenfeldstecker für die Stromversorung verwendet: Einen Dreipoligen verwenden, außen minus und innen plus.
Dann ist es egal, wie rum man ihn steckt, solange alle drei Pins verbunden sind.

Nur leider liegen auf diesem Postenstecker ja auch noch die ISP-Pin. Aber trotzdem Danke für den Tipp, den ich aber so schonmal realisiert habe (mit 5 Pins: Vcc - Mitte; 2xGND - außen; und den beiden Pins des I²C-Busses dazwischen). Beim RL werde ich den jetzt nicht umsetzen, denn an den Batterien bzw. ISP-Pins werde wohl nur ich mich vergreifen ... und die Batterien werde ich bestimmt nicht mehr verpolen :kopfklatsch:

Viele Grüße und vielen Dank,
Thomas(_st)

 

[waste1]

Hallo Thomas,

das wäre ja doch zu schade, wenn das schöne Teil nicht zum Einsatz kommen würde, jetzt da es schon fertig entwickelt ist. Den Schwierigkeitsgrad kannst Du dadurch variieren, indem die Suchzeit für das 2. RL länger oder kürzer wählst. Muss man für das 2. RL lange suchen, dann kann das schon recht schwierig werden. Findet man aber das 2. RL innerhalb der Zeit, in der das 1. RL noch morst, dann ist es relativ leicht, finde ich. Ein Kompromiss dazwischen wird wohl die richtige Lösung sein. Ich denke, da hat man genügend Gestaltungsmöglichkeiten um es nicht allzu schwierig werden zu lassen. Außerdem gibt es noch die Möglichkeit in der Beschreibung einige Hinweise zu geben.

Das Problem mit der 100ms Sendezeit solltest Du noch lösen, denn zum Einen kostet das Strom und zum Anderen wäre eine möglichst kurze Sendezeit und dem gegenüber eine lange Empfangszeit für eine schnelle Erkennung gut. Z.B. Sendezeit ca. 2 bis 5ms und Empfangszeit ca. 100ms. Und wichtig: keine gleichen Zeiten bei beiden RLs, sonst könnte es passieren dass beide immer zur gleichen Zeit senden.

Bei den LED-Strömen kann man ruhig bis auf 2mA runter gehen, wenn man Ultrahelle verwendet. Das sieht man auch noch auf 100m und spart dann nochmal Strom.

Ja, Hochfrequenz ist sehr kompliziert. Bevor Du die Antenne in den Petling hinein knüllst, lieber etwas kürzen als zusammen knüllen. Für gute Reichweiten sollten die beiden Antennen gleiche Ausrichtung haben (waagrecht oder senkrecht), aber nicht gegenseitig zueinander oder auseinander zeigen.

Viel Grüße
Waste1

 

[Sushkin]

Sehr sehr geile Idee!
Meine bescheidenen Gedanken zum Thema Kollisionsvermeidung: Stelle den Gesamtzyklus "Senden-Warten" auf eine Gesamtdauer ein, deren Länge (in Sekunden oder Millisekunden) zwei unterschiedlichen Primzahlen entspricht (z.B. beim einen Modul 51ms, beim anderen 29). Damit ist gewährleistet, dass wenn es mal zu einer Überschneidung kommt (beide senden gleichzeitig), danach möglichst lange wieder eine überschneidungsfreie Zeit folgt - kein Witz.
Außerdem sollten die Empfangszeiten deutlich über den Sendezeiten liegen (vielleicht 1:20 oder so).

 

[waste1]

Hallo Thomas,

zum Thema Reichweite ist mir noch was aufgefallen. Gestern war es schon so spät, hatte es ganz vergessen zu schreiben..

Die Parameter sind hierbei Modul spezifisch und haben im einzelnen folgende Bedeutung:
1600: Sende- und Empfangsfrequenz: 434,0000MHz (siehe Frequency Setting Command)
16: Baudrate: 20,3 kbaud (siehe Data Rate Command)
6: Frequenzverschiebung: 105kHz (Parameter M des TX Configuration Control Command)
0: rel. Sendeleistung: 0dB (Parameter p des TX Configuration Control Command)
6: Level des Data quality detectors (Parameter f des Data Filter Command)
5: Empfängerbandbreite: 134kHz (Parameter i des Receiver Control Command)
1: Eingangsverstärkung: -6dB (Parameter g des Receiver Control Command)
4: Schwelle der Eingangsfeldstärke: -79dB (Parameter r des Receiver Control Command)

Mit den jetzigen Einstellungen gibt es noch Potential zur Reichweitenverbesserung:
Die Eingangsverstärkung könntest Du noch auf 0dB stellen und
die Empfängerbandbreite auf 67kHz und Frequenzverschiebung auf 45kHz stellen.
Das ergibt zusammen eine Verbesserung der Empfindlichkeit von theoretisch 9dB.

Viele Grüße
Waste1

 

[thomas_st]

Hallo zusammen,

bin mal ein bisschen auf Suche gegangen (nach Bugs im Programm ), habe ein mini Video gedreht und habe insgesamt etwas den Stromverbrauch gedrückt. Das hat etwas gedauert, daher erst jetzt meine Antworten

Das Problem mit der 100ms Sendezeit solltest Du noch lösen, denn zum Einen kostet das Strom und zum Anderen wäre eine möglichst kurze Sendezeit und dem gegenüber eine lange Empfangszeit für eine schnelle Erkennung gut. Z.B. Sendezeit ca. 2 bis 5ms und Empfangszeit ca. 100ms.

Leider bin ich beim Timing auf den Watchdog angewiesen - und der hat als kleinstes Intervall die 16ms - da komme ich also nicht drunter.

Die 100ms haben mich stutzig gemacht, da ich mir irgendwie nicht erklären konnte, wo die herkommen - das passt nun so überhaupt nicht in das 16ms Raster. Also erstmal getestet, ob der Sender während dieser 100ms wirklich sendet, oder ob etwas anderes den Strom zieht. Wie aber das folgende Bild zeigt, empfängt das andere RL synchron zu dieser Phase der hohen Stromaufnahme etwas.


Zeitliche Abhängigkeit Stromaufnahme (RL-A) und Empfangsfeldstärke (RL-B)

Also warum sendet das RL so lange? Und da sollte ich doch vielleicht meine eigenen Texte lesen :kopfklatsch: :

Das geht dann so lange, bis das Modul durch die Funktion "rfm12_stopTX" angehalten wird.

Tja, wenn man die Funktion "rfm12_stopTX" halt nie aufruft, dann hört das Modul eben auch nicht auf zu senden (warum es das nach 100ms eigenmächtig doch gemacht hat ... will ich jetzt auch irgendwie nicht mehr wissen ).

Also das Programm so angepasst, das nunmehr der Sender ausgeschaltet wird, bevor der Empfänger eingeschaltet wird:

ISR(WDT_vect)
{
[...]
	if(fTransceiverOn)			// Transceiver ist an, dann senden/empfangen
	{
		if(u8Count>1 && u8BlinkSequenz != 1)	// Es wurde was empfangen: das andere
		{										// Reaktivlicht ist auch an
			u16BlinkCounter = 0;	// Blinkgenerator initialisieren (damit wir wieder von vorne beginnen)
			u8BlinkSequenz = 1;		// und auf die andere Blinksequenz umschalten
		}

		u8Count= 0;					// Empfangszähler initialisieren

		if((u8TXRXCounter++)%4 == 0)
		{
			rfm12_stopRX();				// erstmal in die Welt rausschreien
			rfm12_startTX();			// dass wir am blinken sind
		}
		else
		{
			rfm12_stopTX();				// Sender aus!
			rfm12_startRX(&u8Count);	// Empfänger an
		}
	}
[...]
}

Das geänderte Programm habe ich diesem Posting als Zip-File beigefügt.

Damit sieht das mit der Stromaufnahme jetzt schon etwas besser aus => nur noch 13mA für das Transceivermodul (und damit gute 2 Jahre Betrieb mit den kleinen AAAA-Zellen):

Stromaufnahme während des Senden (Programmversion 3.0.4)

Und wichtig: keine gleichen Zeiten bei beiden RLs, sonst könnte es passieren dass beide immer zur gleichen Zeit senden.

Habe ich gemacht (ist im Programm nicht zu erkennen): das eine RL hat 3 Zyklen lang empfangen, das andere 4 Zyklen lang => einfach die 4 in dieser Zeile durch eine 5 ersetzen: if((u8TXRXCounter++)%4 == 0)

Bei den LED-Strömen kann man ruhig bis auf 2mA runter gehen, wenn man Ultrahelle verwendet. Das sieht man auch noch auf 100m und spart dann nochmal Strom.

Und nicht zu knapp! Allerdings müsste ich da nochmal zum Lötkolben greifen und andere Vorwiderstände den LEDs verpassen. Was aber problemlos ginge, ist das Dimmen der LEDs per PWM: es fließt dann zwar immer noch ca. 20mA - aber eben nur noch für einen Bruchteil der Zeit.

Ja, Hochfrequenz ist sehr kompliziert.

Jep.

Bevor Du die Antenne in den Petling hinein knüllst, lieber etwas kürzen als zusammen knüllen.

Für die Antenne habe ich ein kleines Loch im Petlingdecke - die kuckt also hinten raus. Das einzige was passiert: wenn ich den Petling zuschraube wickelt sich die Antenne einmal um die Batterien ...

Sehr sehr geile Idee!

;D

Meine bescheidenen Gedanken zum Thema Kollisionsvermeidung: Stelle den Gesamtzyklus "Senden-Warten" auf eine Gesamtdauer ein, deren Länge (in Sekunden oder Millisekunden) zwei unterschiedlichen Primzahlen entspricht (z.B. beim einen Modul 51ms, beim anderen 29). Damit ist gewährleistet, dass wenn es mal zu einer Überschneidung kommt (beide senden gleichzeitig), danach möglichst lange wieder eine überschneidungsfreie Zeit folgt - kein Witz.

Das Problem ist nur, das ich an das Zeitintervall des Watchdogs gebunden bin (um da raus zu kommen, müsste ich das Programm grundlegend umstellen) und der hat als minimales Zeitintervall 16ms.

zum Thema Reichweite ist mir noch was aufgefallen. Gestern war es schon so spät, hatte es ganz vergessen zu schreiben..

?

Mit den jetzigen Einstellungen gibt es noch Potential zur Reichweitenverbesserung:
[...]
Die Eingangsverstärkung könntest Du noch auf 0dB stellen und
die Empfängerbandbreite auf 67kHz und Frequenzverschiebung auf 45kHz stellen.
Das ergibt zusammen eine Verbesserung der Empfindlichkeit von theoretisch 9dB.

Das mit der Eingangsverstärkung ist einleuchtet - warum ich da nicht auf 0dB gegangen bin: Das einzige was sein könnte: der Einfluss erschien mir als eher gering und in diesen Fällen tendiere ich eigentlich dazu, nicht an die Grenzen zu gehen.
Zur Empfängerbandbreite / Frequenzverschiebung wie kommst Du da auf weiter 3dB? Bzw. anders gefragt: ich verstehe ehrlich gesagt nicht so ganz, wie beide Werte einen Einfluss auf die Empfindlichkeit haben. ... und wenn sie einen haben, hätte ich erwarte, dass die Empfindlichkeit mit größere Empfängerbandbreite und stärkerer Frequenzverschiebung zunehmen sollte - schließlich wird der Sender ja nun stärker "verstimmt", was doch vom Empfänger besser "verstanden" werden sollte.

Ansonsten habe ich vorhin bei Youtube ein Video eingestellt, bei dem man das geteilte RL in Aktion sehen kann - da kann man auch erkennen, wann und wie das mit dem Morsecode gedacht war.

http://de.youtube.com/watch?v=0ebX1_32Zds

Das ganze ist natürlich ein stark vereinfachter Aufbau - die beiden RL liegen ja nur wenige Meter auseinander. Ansonsten sieht es etwas ulkig aus, das die RL schon anfangen zu blinken, bevor die Lampe eigentlich hinleuchtet - was man aber auf dem Video nicht erkennen kann, ist der Lichtkegel um den eigentlichen Spot herum, der hier die RL triggert. Achso: die Blinksequenzen habe ich etwas gekürzt, damit das Video keine 3 Minuten lang wird

Viele Grüße,
Thomas(_st)

 

[wenzelbub]

Sehr coole Idee!

Hab mir grad das Video angesehen (und nicht das Programm weiter studiert) und hätte einen kleinen Verbesserungsvorschlag:

So wie es aussieht, beginnt das "farbige" Morsen, sobald das zweite Rea aktiviert wird. Ich würde da noch eine Pause von 1-2 sec bis zum "farbigen Morsen einbauen, damit nicht die Taschenlampe die ersten 1 oder 2 Aufleuchten noch überstrahlt. Und man kann sich so leichter auf das Morsen konzentrieren und ist nicht noch mit der TaLa beschäftigt.

 

[movie_fan]

Freak
wo kann man das testen?!?
geniale idee muss ich schon sagen!

wobei ich sagen muss, ich hab schon befürchtet das die infos von der blauen/roten led parallel zu dem text mit der weißen led gemorst werden, sowas is ja immer etwas schwieriger zu entziffern hab ich mir sagen lassen

so klingt das durchaus fair.. und hints o.ä. würde ich weglassen, dafür lieber nen d sternchen rauf
wenn man in nem grüppchen unterwegs ist, denke ich schon, das zufällig mal beide gleichzeitig ausgelöst werden. selbst wenn man nicht sofort peilt was da dann los ist, weis man schonmal wie man in etwa die dinger andersfarbig zum leuchten bekommt

 

[waste1]

Allerdings müsste ich da nochmal zum Lötkolben greifen und andere Vorwiderstände den LEDs verpassen.

Das ist doch nicht so schlimm, 2 Widerstände umzulöten. Ist doch in 5 Minuten erledigt. Du musst bedenken, dass so eine Morsesequenz bestimmt 5 oder noch mehr mal aufgerufen werden muss, um von Laien dekodiert werden zu können. Ich habe auch morsende RLs im Wald hängen. Bei meinen müssen aber nur Zahlen dekodiert werden, was leichter ist als Text zu dekodieren. Meine Stationen morsen sogar langsamer (300ms) als deine mit 250ms. Als weitere Erleichterung habe ich als Buchstabenabstand 4 dits anstatt üblicherweise 3 dits genommen. Trotzdem jammern einige ziemlich über diese Stationen, manche scheitern ganz.

Für die Antenne habe ich ein kleines Loch im Petlingdecke - die kuckt also hinten raus. Das einzige was passiert: wenn ich den Petling zuschraube wickelt sich die Antenne einmal um die Batterien ...

Da würde ich lieber ein Loch seitlich im Petling machen, direkt über dem RFM12-Modul. Dann muss die Antenne nicht so dicht an der Batterie vorbei, was nicht so optimal ist.

Das mit der Eingangsverstärkung ist einleuchtet - warum ich da nicht auf 0dB gegangen bin: Das einzige was sein könnte: der Einfluss erschien mir als eher gering und in diesen Fällen tendiere ich eigentlich dazu, nicht an die Grenzen zu gehen.

Kann schon sein, dass es in der Praxis keine 6dB bringt. Aber wenn es gar nichts bringen würde, dann hätten sie die Einstellmöglichkeit auch nicht angeboten. Also irgendwas wird es schon bringen.

Zur Empfängerbandbreite / Frequenzverschiebung wie kommst Du da auf weiter 3dB? Bzw. anders gefragt: ich verstehe ehrlich gesagt nicht so ganz, wie beide Werte einen Einfluss auf die Empfindlichkeit haben. ... und wenn sie einen haben, hätte ich erwarte, dass die Empfindlichkeit mit größere Empfängerbandbreite und stärkerer Frequenzverschiebung zunehmen sollte - schließlich wird der Sender ja nun stärker "verstimmt", was doch vom Empfänger besser "verstanden" werden sollte.

Der Zusammenhang zwischen Empfängerbandbreite, Frequenzhub und Datenrate ist sehr kompliziert, eine Erklärung würde den Rahmen hier sprengen. Aber im Datenblatt zum IA4421 findest Du auf Seite 31 einige BER-Kurven und ganz unten eine Tabelle mit den optimalen Einstellungen für verschiedene Datenraten.

Da Du sowieso an den 16ms Zyklus gebunden bist, könntest Du sogar noch die Datenrate senken (5 - 10kBaud). Das würde dann nochmal eine Verbesserung bringen, wie man aus den BER-Kurven sieht.

Noch was zur Reichweite. Im Wald wird die Reichweite nicht mal die Hälfte von der im Freien sein. Hängt stark von der Dichte der Bäume und Vegetation ab. Wenn Du also im Winter den Nachtcache anlegst, ist es nicht unbedingt sicher, dass er auch im Sommer bei voller Vegetation funktioniert. Aber das gilt auch für Nachtcaches mit reinen Reflektoren.

Viele Grüße
Waste1

 

[thomas_st]

So wie es aussieht, beginnt das "farbige" Morsen, sobald das zweite Rea aktiviert wird. Ich würde da noch eine Pause von 1-2 sec bis zum "farbigen Morsen einbauen, damit nicht die Taschenlampe die ersten 1 oder 2 Aufleuchten noch überstrahlt.

Jep. Das ist sinnvoll - werde ich machen auch wenn ich den "Code" (was richtiges ist es ja noch nicht: 1-2-3-4-5) eigentlich 3x hintereinander blinken lasse (nicht beim RL im Video - das hatte ich ja etwas eingekürzt, damit das Video nicht zu lang wird).

Freak

wo kann man das testen?!?

Ich habe eigentlich vor nächste Woche zum DA-Stammtisch zu kommen (da unten soll es komischen Nanos geben, davon muss ich einen suchen - damit ich mitreden kann ) da bringe ich es mit. ... oder vorher steht noch ein NC auf dem Programm, dann könnte man es auch live im Wald testen - Reichweite mit Bäumen und so ...

wobei ich sagen muss, ich hab schon befürchtet das die infos von der blauen/roten led parallel zu dem text mit der weißen led gemorst werden, sowas is ja immer etwas schwieriger zu entziffern hab ich mir sagen lassen

Ja., habe ich auch gehört - wo dann aus rot und blau ein pink wird Dies soll aber angeblich auch etwas weiter weg hängen

wenn man in nem grüppchen unterwegs ist, denke ich schon, das zufällig mal beide gleichzeitig ausgelöst werden. selbst wenn man nicht sofort peilt was da dann los ist, weis man schonmal wie man in etwa die dinger andersfarbig zum leuchten bekommt

Na ich erinnere da nur an den ... - Cache, bei dem das RL regelmäßig /nicht/ gefunden wird - warum auch immer. Also eine "Finde"- und vor allem "Zufällig Finde"-Garantie gibt es nicht.

Allerdings müsste ich da nochmal zum Lötkolben greifen und andere Vorwiderstände den LEDs verpassen.

Das ist doch nicht so schlimm, 2 Widerstände umzulöten. Ist doch in 5 Minuten erledigt.

Bei den SMD-Widerständen bin ich "etwas" dünner ausgestattet - eigentlich habe ich nur die auf den Platinen im Moment verbauten Werte. Da müsste ich also vorher noch zum großen C rennen ...
Ok, das ist jetzt keine richtige Ausrede, ich will damit auch nur zeigen, das der Aufwand auch in diesem Fall etwas größer werden kann ... denn in der Zeit die ich bis zum großen C und zurück gebraucht hätte, habe ich das Programm umgebaut und eine PWM eingebaut (siehe angehängtes Listing). Nun kann man durch ändern eines Wertes im Programm die LEDs dunkler dimmen ...

Als weitere Erleichterung habe ich als Buchstabenabstand 4 dits anstatt üblicherweise 3 dits genommen. Trotzdem jammern einige ziemlich über diese Stationen, manche scheitern ganz.

Das könnte man machen - momentan habe ich mich an die "normalen" Konventionen gehalten: dat = 3xdit; Zeichenabstand: dit; Buchstabenabstand: dat; Wortabstand: 7xdit

Da würde ich lieber ein Loch seitlich im Petling machen, direkt über dem RFM12-Modul. Dann muss die Antenne nicht so dicht an der Batterie vorbei, was nicht so optimal ist.

Jep, das ist besser.

Kann schon sein, dass es in der Praxis keine 6dB bringt. Aber wenn es gar nichts bringen würde, dann hätten sie die Einstellmöglichkeit auch nicht angeboten. Also irgendwas wird es schon bringen.

Ok, ich muss gestehen, dass ich diese Test etwas "hemdsärmlig" gemacht habe: Antenne soweit "zusammengeknüllt", bis die Reichweite nur noch wenige Meter betrug und dann an den Parametern gespielt und überprüft, wie sich die Reichweite ändert ...

Da Du sowieso an den 16ms Zyklus gebunden bist, könntest Du sogar noch die Datenrate senken (5 - 10kBaud). Das würde dann nochmal eine Verbesserung bringen, wie man aus den BER-Kurven sieht.

Das ist ulkig - das hatte ich schon getestet, aber hatte damals eine /geringere/ Reichweite erhalten - warum auch immer. Dann bin ich von den ursprünglich 16kBaud auf die ca. 20kBaut hoch gegangen und hatte eine besser/sichere Verbindung Hochfrequenz / Funktechnik ist schon etwas

Noch was zur Reichweite. Im Wald wird die Reichweite nicht mal die Hälfte von der im Freien sein.

Oh, mach mir Hoffnung ...

Viele Grüße,
Thomas(_st)

 

[waste1]

Deine "hemdsärmeligen" Tests mit zusammengeknüllter Antenne und vermutlich innerhalb eines Gebäudes sind nicht sehr aussagekräftig. Durch Reflexionen gibt es da Auslöschungen (Funklöcher). Das elektromagnetische Feld nimmt da nicht kontinuierlich mit der Entfernung ab, wie es im Freifeld wäre. Um herauszufinden, welche Einstellung die beste Reichweite ergibt, muss man eine Freifeldmessung durchführen, also ohne störende Häuser oder Bäume in der Nähe. Dabei kann man den Testsender mit kleinerer Leistung laufen lassen (-12 oder -18 dB), dann muss man nicht so weit laufen.

Die Höhe der Antenne über Grund spielt auch noch eine Rolle bei der Reichweite. Je höher, desto weiter. Deshalb bei den Tests darauf achten, dass die Antenne immer gleich hoch gehalten wird.

Viele Grüße
Waste1

 

[thomas_st]

Deine "hemdsärmeligen" Tests mit zusammengeknüllter Antenne und vermutlich innerhalb eines Gebäudes sind nicht sehr aussagekräftig. Durch Reflexionen gibt es da Auslöschungen (Funklöcher). Das elektromagnetische Feld nimmt da nicht kontinuierlich mit der Entfernung ab, wie es im Freifeld wäre.

ps: Na, deshalb habe ich ja schon "hemdsärmeligen" geschrieben.

Um herauszufinden, welche Einstellung die beste Reichweite ergibt, muss man eine Freifeldmessung durchführen, also ohne störende Häuser oder Bäume in der Nähe. Dabei kann man den Testsender mit kleinerer Leistung laufen lassen (-12 oder -18 dB), dann muss man nicht so weit laufen.

Oh, ja - ich sehe mich schon mit Notebook und Programmer bei Nacht und Nieselregen auf den Oberräder Wiesen stehen und RL programmieren - ich glaube ich werde einfach dem gesunden Menschenverstand vertrauen und die Parameter nach diesen einstellen und überprüfen wie weit ich komme - ist ja eigentlich nur noch die Eingangsverstärkung und die Baudrate.

Die Höhe der Antenne über Grund spielt auch noch eine Rolle bei der Reichweite. Je höher, desto weiter. Deshalb bei den Tests darauf achten, dass die Antenne immer gleich hoch gehalten wird.

Ok. Das habe ich natürlich nicht beachtet - das eine RL lag (wie im Video) auf dem Boden ...

Viele Grüße und bis bald,
Thomas(_st) - momentan ist das RL aber so umprogrammiert, das es die ADC-Werte sendet ... man erinnert sich: "Wie hell ist denn nun meine Nacht?"

 

[thomas_st]

Mahlzeit zusammen,

da hat sich doch tatsächlich noch ein Fehler ins Programm geschlichen ps: - bzw. einen von den x habe ich gefunden . Dieser hängt mit der Taktfrequenz zusammen - die habe ich ja auf 8MHz erhöht.

Nun bilde ich den Takt für den ADC-Wandler aus diesen 8MHz durch eine 1:2 Teilung (siehe Markierung im Programmcode)

U16 rl_readADC(void)
{
	U16 u16Value;

	// AD-Wandlung starten
	ADCSRA = 1<<ADEN | 	// ADC an
			 1<<ADSC |	// ADC starten
			 0<<ADATE |	// kein Auto trigger
			 0<<ADIE |	// ADC Interrupt aus
			 0<<ADPS0;	// Teiler des ADC-Taktes: 1:2      <= da ist der Fehler !!!!
	
	// Warten bis die AD-Wandlung beendet ist
	while(ADCSRA&_BV(ADSC));

	// ADC-Wert einlesen und auf 0x3ff trunkieren
	u16Value = ADC & 0x03ff;
	
	// ADC ausschalten
	ADCSRA = 0x00;
	
	return u16Value;
}

Folglich läuft der ADC mit 4MHz und damit eindeutig außerhalb der Spezifikation:

By default, the successive approximation circuitry requires an input clock frequency between 50 kHz and 200 kHz to get maximum resolution. If a lower resolution than 10 bits is needed, the input clock frequency to the ADC can be higher than 200 kHz to get a higher sample rate. It is not recommended to use a higher input clock frequency than 1 MHz.

Tja und das wirkt sich dann folgendermaßen aus. Ich habe momentan eine Programmversion im geteilten RL, welches jeden vom ADC stammenden Wert in die Welt hinaus sendet. Dieser wird dann durch einen als "Funk zu RS232"-Wandler arbeitender ATmega 48 per serieller Schnittstelle zum Rechner übermittelt, wo dieser Wert dann aufgezeichnet wird (also nochmal kurz: RL -- Funk --> ATmega 48 -- RS232 --> Rechner --> File). Dabei fällt dann auf, dass der ADC einige Werte einfach "überspringt": siehe Bild (im Beispiel tauchen die Werte zwischen 911 und 920 überhaupt nicht auf).

Der Grund liegt im zu schnellen ADC-Takt. So bald dieser per Teiler 1:64 auf annehmbare 125kHz gebracht wird, läuft der ADC wunderbar und liefert schöne, saubere Werte (und wenn mir nicht gerade eben dieses hterm abgestützt wäre, könnte ich sie auch zeigen ... )

Neuer Code:

U16 rl_readADC(void)
{
    U8 u8sreg; // Lokale Sicherungskopie von SREG
	U16 u16Value;

	// AD-Wandlung starten
	ADCSRA = 1<<ADEN | 	// ADC an
			 1<<ADSC |	// ADC starten
			 0<<ADATE |	// kein Auto trigger
			 0<<ADIE |	// ADC Interrupt aus
			 6<<ADPS0;	// Teiler des ADC-Taktes: 1:64
	
    u8sreg = SREG;	// SREG sichern
	sei();			// Interrupts wieder freigeben
	// Warten bis die AD-Wandlung beendet ist
	while(ADCSRA&_BV(ADSC));
    SREG = u8sreg;	// alten Zustand des SREG wieder herstellen

	// ADC-Wert einlesen und auf 0x3ff trunkieren
	u16Value = ADC & 0x03ff;
	
	// ADC ausschalten
	ADCSRA = 0x00;
	
	return u16Value;
}

Ach so, eine kleine Änderung habe ich bzgl. der Warteschleife noch eingebaut: vorher schalte ich die Interrupts wieder ein (wir befinden uns ja innerhalb einer ISR - der µC löscht hier selbständig das Interruptflag) damit diese (jetzt 1600 Takte bzw. 0,2ms lange) Schleife eventuell von einem weiteren Interrupt unterbrochen werden kann (hier z.B. irgend eine Aktion des Funkmoduls).

Warum schreibe ich das eigentlich alles? Ich will darauf hinweisen, dass man sich mit einem einfachen Raufsetzen des µC-Taktes Probleme einhandeln kann. Im obigen Beispiel hätte jedes hin- und herspringen des ADC-Wertes zwischen 911 und 920 die LEDs getriggert (Blinkschwelle = 5)

Viele Grüße,
Thomas(_st)

PS: das aktuelle Programm hängt mal wieder als ZIP-File an

 

[thomas_st]

Ergänzung zur Funkreichweite

So dann führe ich mal mein Selbstgespräch weiter . Nachdem ja vor längerer Zeit waste1 darauf hingewiesen hat, wie ich die Reichweite erhöhen könnte, habe ich das jetzt mal ausgeführt (ja, ja, die RL hängen noch nicht im Wald (habe noch keinen Platz gefunden) sondern stehen immer noch für Experimente zur Verfügung ).

- Als erstes habe ich die Eingangsverstärkung auf 0dB gesetzt - das war echt ein Lapsus in der ursprünglichen Realisierung.

- Desweiteren habe ich die Baudrate runter gesetzt. Ich versuche innerhalb der 16ms Sendephase mehrere Datenframes bestehend aus 3 Bytes Präambel (0xaa), den beiden Magic Bytes (0x2d, 0xd4) und min. 1 Datenbyte zu senden. D.h. bei 2 Datenframes müssen 11 Bytes (88Bit) über den Äther und bei 3 Datenframes 16Bytes (128Bit). Mit der Zeitspanne von 16ms ergibt sich daraus eine Baudrate von 5,5kBaud bzw. 8kBaud. Ich bin auf eine Datenrate von 8,02kBaud gegangen.

- Die Frequenzverschiebung beim Senden (45kHz) und die Empfangsbandbreite (67kHz) habe ich dann entsprechend der Tabelle aus dem Datenblatt angepasst.

Soweit entspricht das Ganze den Vorschlägen von waste1. Der entsprechende Funktionsaufruf sieht jetzt folgendermaßen aus:

rfm12_activateModul(1600, 42, 2, 0, 6, 6, 0, 4);	// dazu: RMF-Modul einschalten
	// 1600: Sende- und Empfangsfrequenz: 434,0000MHz (siehe Frequency Setting Command)
	// 42: Baudrate: 8,02 kbaud (siehe Data Rate Command)
	// 2: Frequenzverschiebung: 45kHz
	// (Parameter M des TX Configuration Control Command)
	// 0: rel. Sendeleistung: 0dB (Parameter p des TX Configuration Control Command)
	// 6: Level des Data quality detectors (Parameter f des Data Filter Command)
	// 6: Empfängerbandbreite: 67kHz (Parameter i des Receiver Control Command)
	// 0: Eingangsverstärkung: 0dB (Parameter g des Receiver Control Command)
	// 4: Schwelle der Eingangsfeldstärke: -79dB (Parameter r des Receiver Control Command)

Ja und was soll ich sagen: bisher hatte ich das Funkmodul wohl mit angezogener Handbremse gefahren :/

Reichweite
Versuch 1: volle Sendeleistung, direkte Sichtverbindung, RL1 auf ca. 9m Höhe / RL2 auf ca. 1,5m Höhe
Damit war problemlos eine Reichweite von 500m möglich. :schockiert: Weiter reichte die direkte Sichtverbindung nicht. Ausgehend von dem mitgeführten RL scheint aber eine Reichweite von ca. 750m möglich zu sein (in diesem Fall stand dann ein Hochhaus zwischen den beiden Sendern).

Ok. das wollte ich überprüfen, daher:

Versuch 2: auf ca. 3% gedrosselte Sendeleistung (rel. Sendeleistung: -15dB), direkte Sichtverbindung, RL1 auf ca. 9m Höhe / RL2 auf ca. 1,5m Höhe
Ausgehend von einem isotropen Kugelstrahler ohne Richtwirkung sollte in diesem Fall eine auf ca. 18% reduzierte Reichweite möglich sein. Experimentell bestimmt habe ich für diese Bedingungen eine Reichweite von ca. 100m -> das passt relativ gut mit den 500m aus Versuch 1 zusammen.

Mit 500m Reichweite bei direkter Sichtverbindung könnte ich mit

Im Wald wird die Reichweite nicht mal die Hälfte von der im Freien sein.

problemlos leben. Aber ich wollte das doch etwas genauer überprüfen, daher:

Versuch 3(a, b und c): auf ca. 18% gedrosselte Sendeleistung (rel. Sendeleistung: -7,5dB), Wald
Ich habe drei Reichweitentests im Wald durchgeführt. Hierbei war die Sendeleistung au 18% reduziert, was bei einem Kugelstrahler eine Reduktion der Reichweite auf ca. 42% bedeutet. Bei den ersten beiden Tests war das eine RL einfach nur auf den Waldboden bzw. in eine Jhemry gelegt. Ich bin dann mit dem zweiten RL den relativ zugewachsenen und Knicke machenden Weg weiter und kam auf Reichweiten von 150m bzw. 170m.
Für den letzten Test hatte ich das RL in ca. 40cm Höhe in einen Baumstumpf gelegt und bin mit dem zweiten RL los um die Reichweite zu bestimmen. In diesem Fall war ein sehr dichte Neuanpflanzung von Bäumen zwischen den beiden Sendern - also wahrscheinlich funktechnisch der Worst Case. In diesem Fall war eine Reichweite von 190m möglich. Es scheint also so zu sein, das man im Wald problemlos Reichweiten von 300m erzielen kann.

Solche Reichweiten werde ich vermutlich nicht nutzen, aber sie gestatten einem doch eine schöne Flexibilität bei der Suche des Standorts. Wenn die Reichweite nicht so groß sein muss, kann man dann ja mit der Sendeleistung runter gehen - ist sowieso besser, wenn die RL sich normal unterhalten und nicht rumschreien.

Achso, da ja der Morsecode auf etwas Widerwillen gestoßen ist (kann ich ja verstehen): was ist von folgendem zu halten: solange nur ein RL ausgelöst wird, blinkt dieses die KOs des jeweils anderen RL und erst wenn beide gleichzeitig ausgelöst werden, blinken beide die KOs der nächsten Stage?

Viele Grüße,
Thomas(_st)

 

[kirby27b]

Ergänzung zur Funkreichweite

Achso, da ja der Morsecode auf etwas Widerwillen gestoßen ist (kann ich ja verstehen): was ist von folgendem zu halten: solange nur ein RL ausgelöst wird, blinkt dieses die KOs des jeweils anderen RL und erst wenn beide gleichzeitig ausgelöst werden, blinken beide die KOs der nächsten Stage?

Viele Grüße,
Thomas(_st)

HI,

also diese Idee finde ich prima, so sollte selbst dem "partiell geistig unbedarften" nach spätestens zwimal hin und her auffallen das es da wohl noch etwas anderes zu machen gibt als nur eines der Lichter an zu leuchten. Weil man kann sich ja nächtens schon mal sehr stoffelig anstellen, aber wenn man mal die Koord's des einen und dann wieder die des anderen bekommt sollte Cacher stutzig werden und nach einer weitergehenden Lösung suchen.

Grüße Olaf

 

[nanonase]

Saucoole Idee Thomas_st!
Seit dem letzten Thread oder wie Du es genannt hattest

Selbstgespräch

ist schon einige Zeit vorbei. Gibt es da schon ein Update??

Gruß

 

[thomas_st]

Gibt es da schon ein Update??

Jain

Nein: Zum vorgestellten geteilte RL gibt es nichts Neues - war soweit auch fertig Ich muss mich nur noch durchringen den Cache mal zu legen

Ja: Das geteilte RL hat einen großen Bruder bekommen. Allerdings ist dieser ein Mutant und seine RL-Funktionen sind zu einem "normalen" Klingelknopf mutiert. Auch die LEDs haben sich vermehrt - es sind jetzt 392 und nicht mehr 2, die eine LED-Matrix bilden. Leider passt der Brocken nicht mehr in einen Petling und ich musste / bzw. muss ein "Vogelhaus" drumherum bauen.

Die Vorstellungsrunde des "großen Bruders" werde ich dann demnächst mal machen ...

Viele Grüße,
Thomas(_st)

 

[WernerSnow]

Kompliment ! Hört sich echt genial an