RN-Speak - Knacken und Pause vor der Meldung

Ich verwende RN-Speak Version 1.3.

Wenn der RS-232-Modus aktiv ist jedes mal beim Drücken des Reset-Knopfes eine kurzes Knacken im Lautsprecher zu hören.

Diese Knacken ist auch jedes mal zu hören wenn über den I2C-Bus eine Meldung aufgerufen wird.

Haben auch andere User dieses Problem?

Die Jumper sind genau so gesetzt wie in der Doku beschieben..

Nach dem Knacken folgt in Abhängigkeit der Meldungsnummer eine Pause, bevor die eigentliche Meldung ausgesprochen wird. Ich habe ca. 130 Meldungen gespeichert. Wenn ich z.B. die Meldung 130 abgerufe beträgt die ungewollte Pausenzeit ca 1. Sekunde. Haben andere User ähnlich lange Zeitverzögerungen?


Gruß Claus

Hi Claus!
Vielleicht änderst Du mal den Titel Deines Threads von "RN-Speak - Kacken und Pause vor der Meldung" auf "RN-Speak - Knacken und Pause vor der Meldung"!
Man könnte es missverstehen! *ggg*

Das "knacken" hab ich mal im Betreff geändert ;-) Knacken tut normalerweise nix, das klingt ein wenig so als seien deine Jumper an JP1 nicht richtig gesteckt (dann kanns zu knacken kommen). Am besten mal mit aktueller Anleitung vergleichen. Falls du nicht alle 3 ISD Sprachbausteine bestücken willst (sind gerade im Preis herabgesetzt bei robotikhardware.de) musst du eventuell 1 oder 3 Widerstände einstecken, siehe dazu die aktuelle Anleitung im Download-Bereich.
Im übrigen ist nun auch die Firmware 2.0 zu empfehlen, siehe https://www.roboternetz.de/phpBB2/viewtopic.php?t=1770

Also inzwischen habe ich die Version 2.0 eingespielt.

An den oben genannten Problemen hat sich aber leider nichts geändert. Es ist immer noch ein Knacken beim Druck auf die Reset-Taste, und damit auch vor jeder Message die über den I2C-Bus aufgerufen wird, zu hören. Die Jumper sind exakt so gesetzt wie in der aktuellen Doku vorgeschieben.

Die Pause zwischen der Anforderung der Message und dem tatsächlichen Abspielen ist leider noch viel länger geworden. Die Pause vor Message 130 beträgt ca. 10 Sekunden. Was für die praktische Anwendung inakzeptabel lange dauert.

Beim Druck auf die Reset Taste kommt auch ein kleines Knacken, das ist aber normal.
Nun 130 Messages ist natürlich extrem viel, bislang hab ich es nur bis ca. 60 Messages geschafft. Da hatte ich eigentlich nur eine Verzögerung von ca. einer halben Sekunde.
Wieviel Sprachchips hast du denn, alle 3? Auch auf die Widerstände geachtet falls du keine 3 hast? Das ist wichtig weil sonst die END OFF Message Nachricht nicht immer gemeldet wird und es auch längere Verzögerungen gibt (nämlich bis Time Out).

Hallo Frank,

wenn man sich ein wenig mit dem ATMega8 auskennt liegt die Lösung ganz nah, da das bei mir leider nicht der Fall gewesen war hat es einen ganzen Tag Frust ](*,) und Sucherei gekostet, bis ich das richtige Bit gefunden habe.

Der ATMega8 verfügt ja über jede Menge Fuse-Bits. Vier davon sind zum Einstellen der Clock Source. Standardmäßig ist der interne Resonator mit 1 MHz aktiviert. Der 8 MHz Quarz war also gar nicht angeschwungen, was die elendig langen Pausenzeiten erklärt.

Du solltest auf jeden Fall in die Doku einen Hinweis auf die richtig einzustellenden Fuse-Bits geben.

In der Doku sind mir noch zwei kleine redaktionelle Fehler aufgefallen:
Auf Seite 6 im vorletzten Ansatz steht 9800 Baud.
Auf Seite 9 ist in der Tabelle beim Punk rnb x ein falsches Beispiel angegeben.

Mit dem Knacken muss ich denn wohl erstmal leben.

Gruß Claus

Na fein das das geklärt ist. Allerdings damit hatte ich nicht gerechnet da ja normalerweise immer ein bereits programmierter Chip mitbestellt wird. Da sind dann die Fusebits immer schon korrekt gesetzt. Und wenn man neue Firmware drauf spielt brauchen Fusebits ja auch nicht geändert werden. Du hast vermutlich einen ganz neuen Mega8 genutzt.

Danke für Hinweis bezüglich der Doku!

:-& Wie geht das nun weiter mit dem Knacken und der längeren Pause vor Ausgabe von Texten? Mich würde das auch mal interessieren! Ich habe das RNSPEAK - Board als Ergänzung zum Hauscomputer vorgesehen, Das aktuelle Datum, sowie die Zeit spricht er schon, allerdings durch die Pausen und Knaksgeräusche in unerträglicher Qualität - trotz richtiger Jumper und Widerstände. Kommt irgendwann nochmal ein Softwareupdate der das Problem behebt? Die Aneinanderreihung von Phonemen setzt einen zügigen Ablauf ohne Pausen vorraus! Frank, hast du da einen Draht zum Entwickler?

Hallo Nikolaus,
so recht kann ich das garnicht nachvollziehen. Ich finde nicht das es übermäßig hörbar knackt oder Pausen vorhanden wären. Bei Claus73 lag das doch an den falsch eingestellten Fusebits, siehe oben.
Hast du auch mal die aktuelle Anleitung geladen und die Widerstände in den Fassungen eingesetzt falls du das Board nicht komplett mit Sprachchips bestückt hast. Das ist wichtig, da ansonsten tatsächlich Pausen entstehen.

Für die Aneinanderreihung von Phonemen ist eigentlich RN-Speak nicht unbedingt gedacht. Einzelne Worte oder Wortteile können gut kombiniert werden, aber wenn es um Phomemen geht dan solltest du dir mal das IC SpeakJet als Alternative anschaun. Das ist speziell für die Sprachausgabe gedacht, klingt zwar etwas amerikanisch aber durchaus brauchbar.

](*,) Tja, da stecke ich wohl in einem Dilemma: Ich nutze die Firmware 1.1 und die 5k Widerstände haben keinerlei Einfluss auf das Knacken und die Pausen. Den Umstieg auf 2.0 scheue ich, da dann die 4fache Anzahl Bytes über den Bus laufen muss - bei meinem Projekt ist das Busprotokoll so stark verlangsamt um auch Entfernungen über 100m zu erreichen - da ist einfach keine Zeit mehr, Speakjet benötigt RS232 und fällt damit für mich aus. Sind die Pausen bei der Firmware 2.0 kleiner als bei der alten 1.1? Muss ich unbedingt bei 2.0 für jede Message immer wieder "rnmX" senden oder reicht ein kürzerer Befehl?
Dank im Vorraus

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.

:arrow: 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

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