Ich tippe jetzt stark auf ein Timing Problem, die Endlosschleife geht auch ohne Problemlos, nur es kommt keine Tonauswertung zustande. Ich werde das Ganze wohl "etwas" umbauen, muss mir da nur noch ein paar Details überlegen.
Ich hab mir alternativ auch überlegt, mal den ganzen Code in die Interruptroutine zu packen, vielleicht wirds dann besser (oder es dauert so lange, dass keine Auswertung mehr zustandekommt :-) )
27.09.2004, 18:04
chris.moe
Hi,
den Tip wollt ich auch gerade loswerden.
Auch wenn man komplett den UART weg lässt, ist ton immer ==f .
Ich denke mal durch das uart_puts wird die Endlosschleife etwas verzögert, so dass es klappt.
Aber wieso sollte es nicht gehen, wenn die Schleife schneller läuft?
Aber ich glaube, dass ist der richtige Weg!
Gruß,
chris
27.09.2004, 18:20
chris.moe
Hi,
hab nen Weg gefunden!
-Eine Variable i anlegen.
-In (SIG_INPUT_CAPTURE) i = 1 setzen.
-In der for Schleife um alles ein if(i==1) herum setzen
-Am Ende, da wo uart_puts hin mußte, i=0 setzen.
Es wird so der Code nur bei einer neu empfangenen Frequenz ausgeführt.
EDIT: Mit uart_putc('\r');
uart_putc('\n');
an den Anfang der nächsten Reihe springen.
Gruß,
chris
27.09.2004, 18:55
Grisuchris
Danke, werd ich nachher gleich mal testen.
Warum es hier überhaupt ein Timing-Problem gibt, kann ich (noch) nicht erklären, aber das will ich auch noch rausfinden. Die nächsen Tage wandert das Ganzte dann in nen Atmege 8 mit Display, dann gehts weiter.
!!!ACHTUNG: In der Software ist noch ein andere Bug: Es stimmt was mit dem Löschen des Strings nicht ganz, so dass bei unvollständigen Folgen böse Probleme auftreten. Wird morgen gefixt.!!!
27.09.2004, 20:27
Grisuchris
Großes Ups, das Problem mit unvollständigen Folgen besteht auch in der BASCOM Software. 854 wird z.B. als 85400 ausgewertet.
27.09.2004, 21:04
output
Hallo
"854 wird z.B. als 85400 ausgewertet"
Hmm, bei mir nicht...
Wann genau soll das passieren?
Gruß
Martin
27.09.2004, 22:06
Grisuchris
Ich hab deine Software gerade nochmal runtergeladen: Wenn ich direkt nach dem Programmieren eine zu kurze Tonfolge eingebe passiert nichts. Wenn ich danch eine normale Folge auswerten lasse geht es, wenn ich dann z.B. 123 abspiele wird sie als 1230w decodiert. Ich teste es morgen mal mit nem anderen 2313, nicht das der hier Probleme macht.
28.09.2004, 08:53
output
Hallo
Hab es gerade noch mal versucht wie Du es gesagt hast.
Ich kann keine Problemem feststellen.
Das Timeout sollte dies ja verhindern und ich kann mir auch nicht vorstellen, warum das nicht funktionieren sollte.
Gruß
Martin
28.09.2004, 11:53
Grisuchris
Problem gefunden: *Schäm* Es lag an meinem Tongäber, der hat automatisch ne 5-Ton-Folge gesendet, und fehlende Stellen mit 0 ergänzt.
28.09.2004, 19:08
chris.moe
Hi,
hab den Auswerter bei mir jetzt ca. einen Tag am laufen, mir ist dabei aufgefallen, dass es manchmal Fehlauswertungen gibt. Es wird aus der Sprache oder anderen Geräuschen eine Schleife erkannt.
Ich denke es müßte eine Längenüberprufung her.
Wie sieht es denn bei den Bascom Usern aus?
Habt Ihr da auch das Problem?
Vielleicht schon eine Lösung?
Und noch ne Frage, muss es unbedingt die AA112 Diode sein?
Welche Diode käme noch in Frage?
Gruß,
chris
28.09.2004, 19:24
Grisuchris
Längenüberprüfung ist schon in Arbeit ;-). Als Diode kann man eigentlich nehmen, was man gerade hat, da sie ja im Prinzip nur gleichrichtet. An der AA112 fällt nur besonders wenig Spannung ab, wenn man aber den zusätzlichen Kondensator einbaut, der im Threat mal angesprochen wurde, sollte dass aber auch kein Problem mehr sein.
EDIT: Vergesst es, ne andere Diode gibt Probleme
28.09.2004, 19:28
output
Hallo
Durch das Array ist eine Tonlängenkontrolle ralisiert.
Habe den Dekoder schon seit langen im realen Testbetrieb laufen und bei mir gab es noch nie eine Fehlauswertung durch Sprache.
Gruß
Martin
28.09.2004, 19:46
chris.moe
Hallo,
ich denke nicht, dass das Array für eine perfekte Tonlängenkontrolle ausreicht.
Kann sein, dass es bei mir nicht so gut läuft, weil mein AT90S8515 nur mit 4 Mhz läuft.
Zur Info:
Sendervorlauf 600ms +- 60ms
Ruftonfolge(5 mal 70ms +-2ms)
Pause 600ms +-60ms
Ruftonfolge(5 mal 70ms +-2ms)
Pause 600ms +-60ms
Weckton/Sirenentöne 5000ms +-250ms
Nachlauf 70ms +-2ms
Ich denke man sollte nen Timer nutzen, damit man nicht auf Programmlaufzeiten achten muss.
Den Sendervorlauf bekommt man sowieso nicht mit, vielleicht bekommt man auch nur eine Aussendung der 5-Ton Folge mit, also muss eigentlich nur überprüft werden, ob alle 5 Töne 70ms lang sind.
Was ist denn mit der Sirene, müsste man die nicht auch ganz einfach auswerten können? Irgendwie kann das ja kaum eine Software, wo liegen denn da die Probleme?
Gruß,
chris
28.09.2004, 20:00
Grisuchris
Mit dem Timer zur Tonlängenkontrolle bin ich, wie gesagt, schon am basteln.
Der Sirenenton ist ne andere Geschichte, da er ja aus zwei überlagerten Frequenzen zusammengesetzt ist. Da ist etwas mehr Aufwand nötig.
28.09.2004, 20:02
HFT Reichert
das problem bei der sirenen alarmierung ist, dass zwei Töne überlagert werden. Eine "einfache" Pulsweitenmessung ist hier nicht möglich.
Hilfe: Viele Filter oder spezial IC.