Hallo zusammen, es soll ein Programm für einen Microcontroller (Atmel AVR o.Ä.) mit passender Schaltung entwickelt werden. Beim Einschalten (sobald die Versorgungsspannung anliegt) soll eine MP3 (start.mp3) abgespielt werden. Über einen Beschleunigungssensor (z.B. MMA2241KEG) soll je nach Bewegung eine MP3 abgespielt werden. (bewegung.mp3, stillstand.mp3) Über einen Touch-Sensor (AT42QT1012) kommt ein weiteres Signal. Bei Berührung soll eine weitere MP3 (touch.mp3) abgespielt werden. Die MP3-Files sollten von einem USB-Stick, alternativ von einer SD-Karte kommen. Benötigt werden die Programmdateien für den IC sowie die Beschaltung mit dem Beschleunigungssensor, Tochsensor und Speichermedium. Die Verwendung des Touch-Sensors ist festgelegt, Controller und Beschleunigungssensor können (nach Rücksprache) frei gewählt werden. Gibt es hier evtl. Menschen, die das gegen Bezahlung Umsetzen können? Wenn nicht, an wen kann ich mich wenden? Mit welchen Kosten muss gerechnet werden?
:
Verschoben durch Moderator
Klingt nach Museum oder so was ähnlichem. "Bewegung" muss aber genau definiert werden. Das Abspielen von MP3 über Hardwaredecoder ist zwar kein Problem allerdings das wechseln des Files. Mögliche Latenz 1-2 sec bevor das neue File zu hören ist. Ich ahne das dies schneller gehen soll und das die Files gleichzeitig abgespielt werden bzw. überblendet. Gegen einen Raspberry spricht bestimmt wieder die Ausschreibung ? Denn mit dem wäre das recht einfach mit Hausmitteln + zusätzlicher Hardware lösbar. Entwicklungskosten sind schwer ab zu schätzen rechne für alles 500€ netto damit lässt sich das schon realisieren.
@ Ric R. (der_ric) >Beim Einschalten (sobald die Versorgungsspannung anliegt) soll eine MP3 >(start.mp3) abgespielt werden. >Über einen Beschleunigungssensor (z.B. MMA2241KEG) soll je nach Bewegung >eine MP3 abgespielt werden. (bewegung.mp3, stillstand.mp3) >Über einen Touch-Sensor (AT42QT1012) kommt ein weiteres Signal. >Bei Berührung soll eine weitere MP3 (touch.mp3) abgespielt werden. >Die MP3-Files sollten von einem USB-Stick, alternativ von einer SD-Karte >kommen. Dafür gibt es fertige MP3-Module für wenig Geld, die werden mittels Mico SD-Karte gefüttert. >Benötigt werden die Programmdateien für den IC sowie die Beschaltung mit >dem Beschleunigungssensor, Tochsensor und Speichermedium. Und einen aufgebauten Prototypen, denn ohne den kannst du rein gar nichts testen. >Gibt es hier evtl. Menschen, die das gegen Bezahlung Umsetzen können? Sicher. >Wenn nicht, an wen kann ich mich wenden? Profis kannst du nicht bezahlen, außerdem ist dieses Projekt für solche uninteressant. Hobbybastler und Studenten sind deine Zielgruppe. >Mit welchen Kosten muss gerechnet werden? Tja, gute Frage. Wenn man mal ganzu grob 10 Euro/h ansetzt und vielleicht mal 3 Tage a 8h bist du bei 240 Euro. Mods, das sollte man ins Forum "Markt" verschieben.
Die Projekte von Studenten kenne ich, auch Firmen die Code aus dem Netz saugen. Treten dann Probleme auf sind die mit ihren Latein am ende oder haben keine Lust mehr. Gibt es dazu noch eine Deadline wird es um so problematischer und er zum Risiko. Für 10€ in der Stunde wird es relativ schwierig werden jemanden zu finden der nachweislich an Referenzen solche Dinge macht und auch noch zuverlässig Liefert. Diese Player mit Verstärker kosten nicht viel Geld 20-70€. Module mit Sensoren gibt auch wenn man sucht. So könnte sich der Hard und Software Aufwand deutlich verringern.
Falk B. schrieb: > Tja, gute Frage. Wenn man mal ganzu grob 10 Euro/h ansetzt und > vielleicht mal 3 Tage a 8h bist du bei 240 Euro. Bist du vom Stamm der Ausbeuter & Lohndrücker?
Hallo Ric, um ein ernsthaftes Angebot machen zu können wäre es schön wenn du noch ein paar Rahmenbedingungen erwähnen könntest: Soll das Projekt gemeinnützigen Zwecken dienen oder kommerziell verwertet werden? Als Einzelstück oder für die Serienfertigung? In Sicherheitskritischen Bereichen? Soll im Anschluß an das Projekt noch Support geleistet oder die Firmware weiterentwickelt werden? PS: Fall es tatsächlich für ein Museum o.ä. ist und die Hardware ohnehin noch nicht feststeht, dann wäre ein STM32 Discovery Board (z.B. STM32F407) vielleicht eine Alternative, da ist bis auf den Touchsensor und den Lautsprecher schon alles fertig drauf was man braucht. Die Software schreibt dir dann vielleicht sogar jemand nettes für lau.
@ Belch (Gast) >> Tja, gute Frage. Wenn man mal ganzu grob 10 Euro/h ansetzt und >> vielleicht mal 3 Tage a 8h bist du bei 240 Euro. >Bist du vom Stamm der Ausbeuter & Lohndrücker? Nein, aber so realistisch, als daß der OP keinen Profi bezahlen kann/will. Das Projekt läuft eher unter dem Motto, Just for Fun für den Ausführenden + Taschengeld und Materialkosten. Darum auch mein expliziter Verweis auf Bastler und Studenten. Hab ich auch schon mehrfach gemacht, auch für deutlich weniger Geld und DEUTLICH mehr Zeitaufwand. Aber nur, weil ich das Projekt interessant fand.
@Bachelorsklave (Gast) >(Nur so am Rande, die oben genannten 240 Euro sind ein netter Witz, Nö, eine von vielen Sichtweisen. >dafür liest sich aber kein Entwickler dein Lastenheft durch. Genau wie du nicht die Beiträge anderer Leute! "Profis kannst du nicht bezahlen, außerdem ist dieses Projekt für solche uninteressant." > Hänge eine >Null dran, dann findest du vielleicht nen Bachelorstudenten der das >macht, vorausgesetzt du übernimmst das Gerät wie bei einem kurzen Test >besehen und verzichtest auf jedwede Gewährleistung.) Jajaja, wir nähern uns realsozialistischen Verhältnissen. Da wird dann nur noch geredet und kein Handschlag mehr getan . . . :-(
Mal so als Konzept. http://www.elv.de/audio-shield-fuer-arduino-asa1-bausatz.html Dazu einen Arduino Uno, wenn es sein muss aus China für 5 Euro oder aus Europa für 10-20 Euro. Den Beschleunigungssensor + Touchsensor kann man auf eine kleine Lochrasterplatine löten, fertig. Dann noch die Software.
Vielen Dank für die Antworten... Um etwas präziser zu werden: es geht um ein Soundmodul für Spielzeug, welches vorerst in einer Auflage von ca. 100 Stück produziert werden soll. Die Platine, Gehäuse etc. stelle ich selber her. Es geht vor allem darum jemanden zu finden, der später auch softwareseitige Änderungen bzw Erweiterungen durchführen kann. Es geht nicht darum, den letzten Cent dafür rauszuholen. Ich habe keine Ahnung, wie viel Zeit für die Entwicklung benötigt wird. Um ein Gefühl dafür, richtige Denkansätze und eventuell den entsprechenden Kontakt zu bekommen, melde ich mich hier. >Das Abspielen von MP3 über Hardwaredecoder ist zwar kein Problem >allerdings das wechseln des Files. >Mögliche Latenz 1-2 sec bevor das neue File zu hören ist. >Ich ahne das dies schneller gehen soll und das die Files gleichzeitig >abgespielt werden bzw. überblendet. das sollte tatsächlich etwas schneller gehen. Das File beim Betätigen des Touchsensors sollte eventuelle andere Sounds überlagern. Rührt das Problem von den MP3s? Wären unkomprimierte WAV-Dateien hier besser? Gegen Raspberry, Arduino & Co. sprechen meiner Meinung nach (man möge mich berichtigen): Bootdauer, Preis pro Stück, Baugröße, Stromverbrauch (Die ganze Geschichte wird mit Akkus betrieben), Viele Grüße Ric
In etwa so was als Grundlage zur Steuerung eines Pollin-Modul zur MP3-Ausgabe ? Beitrag "[Bascom/AVR] Pollin-MP3-Modul steuern"
@Ric R. (der_ric) >Um etwas präziser zu werden: es geht um ein Soundmodul für Spielzeug, >welches vorerst in einer Auflage von ca. 100 Stück produziert werden >soll. Aha. >Die Platine, Gehäuse etc. stelle ich selber her. Trotzdem brauchst du erstmal jemenden, der dir den Prototypen fix und fertig macht! >Es geht vor allem darum jemanden zu finden, der später auch >softwareseitige Änderungen bzw Erweiterungen durchführen kann. >Es geht nicht darum, den letzten Cent dafür rauszuholen. Es geht auch um Hardwareentwicklung! >Das File beim Betätigen des Touchsensors sollte eventuelle andere Sounds >überlagern. Schon mal schwierig, denn dann hat man effektiv 2 Soundkanäle! >Rührt das Problem von den MP3s? Auch. >Wären unkomprimierte WAV-Dateien hier besser? Teilweise. Aber für Spielzeug kann man auch mit reduzierter Samplerate etc. arbeiten. >Gegen Raspberry, Arduino & Co. sprechen meiner Meinung nach (man möge >mich berichtigen): >Bootdauer, Nur beim Raspberry Pi. Arduino ist auf Knopfdruck da. > Preis pro Stück, Baugröße, Stromverbrauch (Die ganze >Geschichte wird mit Akkus betrieben), Stimmt, aber dafür sind sie nicht gebaut. Naja, jetzt wissen wir mehr. Vor allem daß du eine schon recht angepaßte Lösung haben willst. Dann wird das definitiv nix mit drei Tagen ;-) Eher 3 Wochen++. Schaltungsentwurf, Schaltplan, Layout, Bestücken, Programmieren, Inbetriebnehmen, Debuggen. Das dauert alles seine Zeit.
Hmm also für Spielzeug kann man auch Samplechips benutzen, bei reduzierte Samplerate dürft der Sound nicht sehr groß sein. Für den Modellbau gibt es etliche solcher Sample Chips. MP3 ist an sich ein $(Geld) Problem. Um wave zu mischen dürfte ein AVR er ungeeignet sein. Ein ARM packt das ewt. muss man probieren. Alternativ auf herkömmliche weise Analog mischen. Mitunter braucht man nicht einmal einen µP. Es gibt auch einfache Bewegungssensoren mit Kugel drin etc. Mit einen ARM und passender DMA Routinen lässt sich das auch per PWM erzeugen. Wäre auch eine billige Möglichkeit. Da kein HIFI gefordert ist kann der Filter recht einfach ausfallen.
:
Bearbeitet durch User
Ric R. schrieb: > Gegen Raspberry, Arduino & Co. sprechen meiner Meinung nach (man möge > mich berichtigen): > Bootdauer Da wirft du sehr verschiedene Dinge in einen Topf. Kennst du irgendeinen Arduino Board, auf dem ein Prozessor sitzt, der erst irgendein Betriebssystem booten muss, bevor er richtig loslegen kann?
Also ich würde das so machen: * WAV-Files auf SD-Karte. USB ist zu kompliziert und schränkt die Auswahl des Controllers ein. Der uC muß dann mindestens ein USB OTG Interface haben. Eine SD-Karte läßt sich über SPI ansteuern, das bringt fast jeder uC mit. Das reine Abspielen eines Stero-Streams bekommt ein einfacher 8Bitter (z.B. Arduino) hin. Schwieriger wird das Mischen von diversen Sound-Files. Dazu braucht man dann schon etwas mehr Rechenpower. Das genannte STM32F4 Discoveryboard reicht dazu von der Rechenpower aus. Man kann das System damit als Prototy aufbauen. Den uC mit den benötigen Bauteilen dann auf ein eigenes Board zu nageln ist auch nicht das Problem. Schau mal hier, das ist genau das was du suchst (ich hoffe der Link ist OK): http://www.midibox.org/dokuwiki/doku.php?id=midibox_sd_card_sample_player Bernd
>Hmm also für Spielzeug kann man auch Samplechips benutzen, bei >reduzierte Samplerate dürft der Sound nicht sehr groß sein. Für den >Modellbau gibt es etliche solcher Sample Chips. Das Problem ist dann aber, dass ich die Sounddatei nicht einfach tauschen kann. >Es gibt auch einfache Bewegungssensoren mit Kugel drin etc. Wenn es eine einfachere Lösung als den o.g. Beschleunigungssensor gibt, ist mir das nur recht. anscheinend ist das Mischen von Sounds eine größere Hürde... Würde es die Sache vereinfachen, den eventuell gerade abgespielten Sound zu pausieren? benötigt wird übrigens nur Mono. Der Verstärker ist ein TDA7267. Viele Grüße Ric
Die Frage wäre in wie weit das tauschen für den Anwender zumutbar wäre. Die Files müssten hierzu markiert sein oder es muss eine Playliste geben. Man kann ja nicht Raten für was welches File ist. Auch das Pausieren ist schon etwas knifflig. Man muss sich merken bei welchen Frame man gerade war und dann wieder dort aufsetzten. Hmm SD und SPI ist nicht sehr performant. Bei vielen ARM ist ein HSMCI (SDIO/SD/MMC) Controller mit drauf. Per DMA kann man damit ohne die CPU zu belasten die Daten hin und her schieben. Wie gesagt per PWM wäre die Sache auch mit mehreren Kanälen lösbar.
:
Bearbeitet durch User
Bachelorsklave schrieb im Beitrag #4604265: > Was zur Hölle willst du eigentlich? Du glaubst wohl Studenten sind nur > zum Ausbeuten da und müssen auf jede soziale Absicherung pfeifen, nur > damit irgendwelche Pfeifen wie Ric R., die nichts weiter können als ihre > weltfremden Vorstellungen, wie sie mit einer Entwicklung absahnen > wollen, möglichst stümperhaft wie ein Hobbyprojekt aussehen lassen, > damit es ihnen jemand für lau baut. Lieber Kollege! Dein Ton lässt zu Wünschen übrig. Wenn du den großen Reibach machen willst, melde ein Gewerbe an und mach ein Angebot. Allerdings lässt der Ton hier schon erahnen, das du bei einer Reklamation aus der Haut fährst.
Ric R. schrieb: > Das Problem ist dann aber, dass ich die Sounddatei nicht einfach > tauschen kann. Hmm, da stellt sich mir gerade die Frage ob der Anwender die Sounddaten auswechseln können soll oder nur DU das einmalig vor der Auslieferung machst? In letzterem Fall könnte man mal überlegen ob man das nicht auch ohne MCU (und somit ohne Software) leicht hinbekommt. Spontaner Ansatz: - Sampledaten im EEPROM/FlashROM - Aufwärtszähler am Adressbus - die obersten Bits des Adressbus wählen das Musikstück aus - DAC/Widerstände am Datenbus - ggf. ein EOF-Byte definieren (z.B. 0xff), das liesse sich am Datenbus leicht mit &-Gattern erkennen - Fensterkomparator am Beschleunigungssensor um ein digitales Signal zu bekommen - Kontrolllogik mit ein paar Flipflops und Logikgattern Damit hätte man sich den ganzen aufwendigen Kram (SDC, FAT, MP3) samt eventuellen Lizenzgebühren gespart.
Habe mal mit einem STM32F030 so einem Werbeartikel "Buzzer" ein neues Innenleben verpasst (zum Originalchip hatte ich keine Infos) mit einem STM32F030 und einem kleinen Verstärker IC LM4991, das Ganze läuft an 3V (2x 1.5V Batterien). Mein Resümee: Lesen der Sounddaten von Micro-SD Karte (FAT code von elm-chan) ist kein Problem über SPI. Allerdings habe ich NICHT MP3 sondern unkomprimierte WAV Files (8 Bit PCM, 44.1 KHz Samplingfrequenz, gespeichert mit Audacity) verwendet. Ausgabe der Samples per PWM ist möglich wenn man keine großen Anforderungen an die Soundqualität hat. Einen LC-Tiefpass sollte man dann aber an den Ausgang vom Controller hängen. Ich denke besseren Sound kann man mit einem Controller mit integrierten D/A-Wandler bekommen. Die Zugriffszeiten bis zum Start eines Samples sind auf jeden Fall unter 1s. Ob die verfügbare CPU und I/O-Zeit (SD-Karte) noch reicht um zwischen zwei Files hin und her zu springen und diese zu mischen bin ich mir nicht sicher. Evtl. müsste man dann mit der Samplingfrequenz runtergehen.
Markus M. schrieb: > Habe mal mit einem STM32F030 so einem Werbeartikel "Buzzer" ein neues > Innenleben verpasst (zum Originalchip hatte ich keine Infos) mit einem > STM32F030 und einem kleinen Verstärker IC LM4991, das Ganze läuft an 3V > (2x 1.5V Batterien). Yep, der STM32F030 wäre auch meine Wahl gewesen. Billiger geht's fast nicht - gerechnet für Gesamtkosten über genannte Stückzahl. > Lesen der Sounddaten von Micro-SD Karte (FAT code von elm-chan) ist kein > Problem über SPI. Allerdings habe ich NICHT MP3 sondern unkomprimierte > WAV Files (8 Bit PCM, 44.1 KHz Samplingfrequenz, gespeichert mit > Audacity) verwendet. WAV-> Genau unser Ansatz. Wobei man, ggf. aus Kostengründen auf SDcard verzichten kann, und je nach geforderter Tonqualität und -dauer internen Speicher FLASH verwenden, bzw. EEPROM oder Dataflash verbauen kann. > Ausgabe der Samples per PWM ist möglich wenn man keine großen > Anforderungen an die Soundqualität hat. Einen LC-Tiefpass sollte man > dann aber an den Ausgang vom Controller hängen. Oder RC und nachverstärken. Oder, wie im Industriebereich üblich - PWM und eine digitale Ausgangsstufe (hat jemand "ein Transistor" gesagt?) ;) > Ich denke besseren Sound kann man mit einem Controller mit integrierten > D/A-Wandler bekommen. DAC ist einfacher. Aber sowohl PWM als auch DAC kann man per DMA bedienen. Die billigsten F0 haben keinen DAC - deswegen PWM. > Die Zugriffszeiten bis zum Start eines Samples sind auf jeden Fall unter > 1s. Ob die verfügbare CPU und I/O-Zeit (SD-Karte) noch reicht um > zwischen zwei Files hin und her zu springen und diese zu mischen bin ich > mir nicht sicher. Evtl. müsste man dann mit der Samplingfrequenz > runtergehen. Unter den o.g. Randbedingungen würde selbst mit einem AVR die Zugriffszeit im 10er Millisekundenbereich liegen. Und "mischen problemlos possible" ;)
> Um etwas präziser zu werden: es geht um ein Soundmodul für Spielzeug,
Ein Barbie Klon : Wääääääää ... Rabääääääää
Oh D. schrieb: > Ein Barbie Klon : Wääääääää ... Rabääääääää Richard B. schrieb: > Wer von euch will das jetzt übernehmen? Odie kann ja schonmal anfangen, die Demo-Sounds aufzunehmen...
Es wurde ja schon fast alles erörtert, ein "Code Monkey" wird sich ja wohl irgendwo finden? :-) Eigentlich fehlt nur noch der Beschleunigungs-und Touchsensor. Die sollten übrigens so angebunden werden, dass sie im Zweifelsfall den Controller auch aus dem (Tief-)Schlafmodus aufwecken können (ich denke wenn es ein Spielzeug ist wird es über Batterie gespeist), d.h. also über einen externen Interrupt o.ä.
Unter der Voraussetzung, dass alle Anforderungen, die nicht entweder funktional, finanziell oder rechtlich begründet sind, d.h. etwa die Forderung nach bestimmtem Touch oder die Forderung nach Rücksprache wg. verwendetem Controller etc., fallengelassen werden und ggf. durch die entsprechenden oben erwähnten Kriterien ersetzt werden, würde ich mir das Lastenheft gerne mal ansehen. Falls kein Lastenheft existiert, würde ich anbieten auch das, gegen Bezahlung, zu erstellen. Ich weise aus gegebenen Anlass (es gibt hier öfter solche Anfragen) darauf hin, dass die bisher gemachten Angaben die Anforderungen an ein Lastenheft definitiv nicht erfüllen. Das Problem ist, dass solche konkreten Forderungen nach bestimmten Bauteilen den Entwickler zu sehr einschränken um eine technisch gute Lösung auszuwählen. Das aber ist genau die Aufgabe eines "Entwicklers". Alle anderen bauen nach fertigem Schaltplan auf oder schreiben Code nach Vorgabe. Da die Auftraggeber das meist nicht beurteilen können, wollen sie ihre eigenen Vorstellungen einbringen, die aber eigentlich meist auf finanziellen oder rechtlichen Vorgaben gründen. Wenn das so ist, sollten genau diese finanziellen und rechtlichen Vorgaben Teil des Lastenheftes sein, nicht die Forderung nach einem bestimmten Bauteil. Das ist jedenfalls meine, auf Erfahrung gegründete, Meinung. Analoges gilt für Forderungen nach bestimmten Dateiformaten etc. wie sich hier im Thread zeigt. Erstmal ist von MP3 die Rede, dann aber relativiert sich das auf WAV, nachdem technische Einwände hervorgebracht wurden. Hier sollte der Auftraggeber sich immer auf das beschränken, was aus seiner Sicht als Verkäufer notwendig ist und er ebenso aus dieser Sicht beurteilen kann; also "ein Sound soll wiedergeben werden". Das technische regelt dann der Entwickler. Das ist sein Fach. Und als Selbstständigem sind ihm finanzielle und rechtliche Aspekte in der Regel auch geläufig. Wenn es aber tatsächlich zwingende Gründe für ein bestimmtes Bauteil oder ein bestimmtes Dateiformat gibt, die weder finanzieller, noch rechtlicher noch technischer Natur sind, dann sollten diese im Lastenheft klargestellt werden. Es gilt allgemein, dass alle nicht-technischen Vorgaben ausdrücklich genannt werden müssen. Zweckmäßig sind oft auch Abgrenzungen, was ausdrücklich nicht festgelegt werden soll. Solltest Du, Richard, gegen diese meine Ansichten und die daraus folgende Vorgehensweise nichts einzuwenden haben, dann schicke mir doch bitte mal das Lastenheft (falls vorhanden) per PM.
Michael D. schrieb: > Solltest Du, Richard, gegen diese meine Ansichten und die daraus > folgende Vorgehensweise nichts einzuwenden haben... Du/Ihr hast/habt mich falsch verstanden. Die Situation (Vorgehensweise) hast du sehr gut erfasst. Ich bin offen für alles und bin definitiv kein Klotz am Bein. Der TO soll aber am Boden und vor allem ehrlich bleiben. Das hier immer gestritten wird (Schwarzarbeit, zu billig/teuer), kommt bei mir als mitleser nicht so gut an. Freundliche Grüße, Richard
Richard B. schrieb: > Michael D. schrieb: >> Solltest Du, Richard, gegen diese meine Ansichten und die daraus >> folgende Vorgehensweise nichts einzuwenden haben... > > Du/Ihr hast/habt mich falsch verstanden. Mein Fehler. Ich meinte natürlich den TO, der "Ric" heisst, nicht Richard, der mir ja das Lastenheft ohnehin nicht schicken könnte, der er ja gar keinen Auftrag vergeben will. Nun ja. Anscheinend geht Ric aber mit meinen Ansichten ohnehin nicht konform. Jedenfalls ist bis jetzt nichts bei mir angekommen. Oder er hat "Richard" gelesen und sich nicht angesprochen gefühlt.
Michael D. schrieb: > Solltest Du, Richard, gegen diese meine Ansichten und die daraus > folgende Vorgehensweise nichts einzuwenden haben Das habe ich jetzt auch als Seitenhieb gesehen ;) Michael D. schrieb: > Oder er hat "Richard" gelesen und sich nicht angesprochen gefühlt. Das könnte durchaus stimmen. Mal sehen...
Nachdem sich einige Rückfragen und Einwände ergeben haben, hier eine genauere Beschreibung, um was es geht: Gefordert ist die Entwicklung eines Soundmodules (Schaltplan und Programmierung) für ein Spielzeugauto. Da die Schaltung Teil einer bestehenden Platine wird, ist ein Layout nicht erforderlich. Das mache ich selbst. gegebene Soundfiles: start.wav, Dauer ca. 3s fahrt.wav, Dauer ca. 20s stand.wav, Dauer ca. 10s hupe.wav, Dauer ca. 5s Beim Format der Audio-Dateien richte ich mich danach, was für die Schaltung am zweckmäßigsten ist. Ich habe herausgehört, dass sich Wave-Dateien wohl am besten eignen, deshalb nenne ich hier .wav-Dateien. Die Soundfiles sollten einfach auf einen integrierten Flash Speicher aufgespielt oder über SD-Karte zur Verfügung gestellt werden. Die Soundfiles müssen einfach austauschbar sein. Beim Einschalten (Anlegen der Versorgungsspannung) soll das Soundfile "start.wav" abgespielt werden. Fahrgeräusche: Sobald sich das Fahrzeug in Bewegung setzt soll das Soundfile "fahrt.wav" abgespielt werden. Wenn das Fahrzeug vor Ablauf von "fahrt.wav" stehen bleibt, soll bei Stillstand das Soundfile "stand.wav" abgespielt werden. Wenn sich das Fahrzeug länger als "fahrt.wav" bewegt, soll das Soundfile "stand.wav" abgespielt werden, unabhängig davon ob sich das Fahrzeug weiter in Bewegung befindet. Wenn sich das Fahrzeug nach Ablauf von "stand.wav" immernoch in Bewegung befindet, soll kein Soundfile mehr abgespielt werden. Sobald das Fahrzeug aus dem Stillstand heraus wieder bewegt wird, sollen die Fahrgeräusche von vorne beginnen, unabhängig davon ob das eventuell laufende "stand.wav" noch abgespielt wird. Bewegung bedeutet in jedem Fall eine Bewegung in irgend eine Richtung, die länger als 2s andauert. Bewegungen unter 2s Dauer werden als Stillstand bezeichnet. Hupe: Über einen Touchsensor (AT42QT1010) wird eine Hupe gesteuert. Sobald der Touchsensor berührt wird, soll "hupe.wav" abgespielt werden, solange der Touchsensor aktiv ist. Wird der Touchsensor vor Ablauf von "hupe.wav" losgelassen, soll "hupe.wav" unterbrochen werden. Das Soundfile "hupe.wav" soll eventuell andere, im Moment abgespielte Soundfiles unterbrechen. Vor Ablauf abgebrochene wav-Dateien starten immer wieder am Anfang. Eine Versorgungsspannung (5V, Li-Akku mit Step-Up Regler) ist vorhanden. Der gegebene Touchsensor (AT42QT1010) sollte verwendet werden, Bewegungssensor und eventuelle Controller/ICs können frei gewählt werden. Sämtliche Bauteile sollten konventionell (mit normalem Lötkolben) lötbar sein, kein BGA etc. Die Quelltexte werden mit übergeben. Ich bitte um Angebote
Kannst auch einen Raspberry Zero dafür nehmen, Beschleunigungssensor modul gibts bestimmt fertig. Mit Touchsensor meinst du Taster/Bumper ? Und mehre Soundfiles gleichzeitig abspielen dürfte auch gehen.
Das fertige Modul darf vermutlich max. 5 € kosten ;)
Ric R. schrieb: > Wenn sich das Fahrzeug länger als "fahrt.wav" bewegt, soll das Soundfile > "stand.wav" abgespielt werden, unabhängig davon ob sich das Fahrzeug > weiter in Bewegung befindet. Diese Anforderung erscheint mir auf Anhieb nicht sinnvoll. Wäre es nicht besser, fahrt.wav so lange zu wiederholen, wie sich das Fahrzeug bewegt? Und erst bei Stillstand wieder zu stand.wav zu wechseln? So ist das zumindest bei meinem Auto ;-)
Richard B. schrieb: > Das fertige Modul darf vermutlich max. 5 € kosten ;) Also wenn das einer mit Stundenlohn macht dann wird das sicher viel teurer =) Für 3 Euro gibts Soundmodule aus China, da muss man ja echt nur Taster auswerten und play(datei) aufrufen.. Also fassen wir mal zusammen, Arduino Clone und Soundmodul für ~6 Euro.. :O
Nur als Hinweis: für (dein) Spielzeug gilt neben der EMV-Richtlinie auch die CE-Spielzeugrichtlinie (mal die Normen recherchieren), und da hört der Spass u.U. ganz schnell auf.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.