Also wirklich störendes Knacken kann ich auch bei V 1.1 nicht feststellen. Das ändert sich in V 2.0 sicher auch nicht. Prüfe mal ob bei dir wirklich alle Jumpe rgenau wie in der ANleitung beschrieben stecken. 100% genau vergleichen!
Ich würde dir dennoch die V2.0 Fiirmware empfehlen. Die paar Bytes mehr bei einem Befehl dürften nun wirklich nicht den Bus gravierend belasten. Zudem gibt es da kein Clockstretching, so das alles recht fix abgeht.
Die Pausezeiten sind eigentlich ähnlich wie bei der alten Firmware, aber es gibt eben wichtige Funktionen um die Aussprache besser mit dem Programm zu synchronisieren
J1 und J3 sind nicht bestückt, J2 musste ich aber setzen, da sonst keine Aufnahme auf den Sprachchip erfolgt. Kann ich in diesem Forum eine Datei ranhängen? Dann würde ich das Ganze mal aufnehmen.. Anstelle von einem 4 Bytes zu senden ist wirklich an der Grenze der Machbarkeit: Ich betreibe 16 PCF- ICs mit einer Taktrate von ca. 6,2 kHz in Echtzeit! Da geht es wirklich um jede Millisekunde.
Dateien kann man mit Attachement unter dem Eingabefeld bei Beitrag anhängen.
Wichtig ist vorallem das die JUMPER bei JP1 stimmen. Mal in aktuelle Doku schaun und Positionen genau abzählen.
Hier nun mal eine Hörprobe - aufgenommen mit Mikrofon vom frei herumliegenden Original Lautsprecher. Die Ansteuerung erfolgt vollautomatisch über I2C. Das Knacken entspricht dem Resetknacken bei Handbetätigung. Die Jumper bei JP1 sind lt. Anleitung und lt. Bild in der Anleitung!
Hmm, in der Tat bei Dir scheint mir das klicken deutlich stärker als bei mir zu sein. So recht weiss ich allerdings dann auch nicht warum. Hast du die Sprache vielleicht manuell mit Taster draufgesprochen?
Wenn ja, dann würde ich es mal mit der Steuersoftware automatisch bespielen lassen. Vielleicht ergibt sich dadurch ein Unterschied.
Kannst du anhand der Sample-Länge feststellen, ob die Pause eine ReaktionsZeit ist oder ob die Pause Teil des Samples ist ?
Edit: Sprich: ist es ein Aufnahmeproblem oder ein Wiedergabeproblem
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Es ist nur ein Wiedergabeproblem über I2C. Die Samples sind als waves auf 50ms genau geschnitten und mit ausklingenden Phasenverlauf versehen. Bei wiederholter Wiedergabe mit der Taste "play" ist weder eine Pause, noch ein Knacken zu hören.. Allerdings ist das Geräusch, das bei Betätigung von "Reset" entsteht verdammt ähnlich dem Knacken im Hörbeispiel. Die Phrasen sind natürlich mit der Software eingespielt (bei 62 Phrasen auch nicht anders möglich). Das Ganze ist zur Zeit nur ein Technologieexperiment. Die Stimme muss noch perfektioniert werden und die "sechzehn" bzw. "siebzehn" anders programmiert werden. Das hat allerdings nur Sinn, wenn es sich natürlich anhört. Es wäre soooo genial, mit einem Byte auf dem Bus nebenbei einen begrenzten Wortschatz zu realisieren - bis hin zum automatischen Telefonanruf des Hauscomputers bei Brand oder Überschwemmung.
Ich kann mir einfach nicht vorstellen das die paar Byte so schlimm in deiner Anwendung sind. Es wird doch nicht am laufenden Band gesprochen, oder?
Wenn du noch die Firmware 1.1 hast, das gibt es da eventuell sowieso eine kurze Verzögerung durch Clockstretching weil das noch die Software I2C Firmware ist. Die wurde ja später durch die 1.3 Hardware I2C ersetzt. Wenn du die noch nicht hast, dann sende mir kurzes Mail mit Realnamen dann kann ich dir die schicken.
Das es ein "leichtes" Knacken durch RESET gibt ist schon denkbar, da bei jeder Message-Anwahl der Pointer durch RESET zurückgestellt werden muss, ganz wird man das wohl nicht weg bekommen. Aber ich fand´s bei mir nicht so störend. Ich werde bei Gelegenheit nochmal die Chip-Doku durchwälzen ob es noch irgend einen Trick gibt.
Die 1 Byte Befehle haben halt den Nachteil das es nur 255 Bytes gibt. Die Befehle gingen auf Kosten der Message-Anzahl. Zudem könnte es bei Busfehler (I2C oder RS232) zu einer falschen Interpretation kommen. Daher bin ich auch von abgegangen
Selbstverständlich soll der dusselige Hauscomputer am laufenden Band quatschen - ich will doch was hören, wenn ich den Fernseher anmache! Im Ernst, die bereits programmierte ständige Laufschrift im Bild soll mit Sprache unterlegt werden und im Bedarfsfall (bei Telefonanrufen) in einen anderen Modus umschalten. Clockstretching spielt absolut keine Rolle - am Oszi ist alles eindeutig sauber.
Die paar Bytes sind aber schon entscheidend, im Moment kann ich die Sprachausgabe mit 18 Bytes je Sekunde abdecken, bei Version 2.0 nur noch mit 4 Bytes je s. Das ist dann schon ganz schön knapp, wenn man bedenkt, dasss die Sprachausgabe nur da an die PCFs "angepfropft" wurde, wo noch ein Byte Platz war. Gleichzeitig muss ich den Takt verdoppeln, wodurch die Reichweite halbiert wird bzw. die Fehlerrate sich erhöht... Einen ATMEGA habe ich übrigens noch nie programmiert, das Board ist der Original Bausatz, daher habe ich auch noch nie ein Terminalprogramm benötigt. Gruss
Berechtigungen
Zitieren
Lesezeichen