Hallo! Ich wollte mal vorsichtig fragen ob es Leute gäbe die prinzipiell Interesse daran hätten an einem noch nicht existierenden Open source Projekt teilzunehmen bei dem es darum geht ein komplettes Autoradio zu entwickeln. Ich habe soetwas schonmal auf professioneller Ebene gemacht (Komplette Software und Teile der Hardware) und es hatte mir verdammt viel Spaß gemacht. Allerdings hatte ich nicht die Möglichkeiten das Radio genau so zu implementieren wie ich es gerne gehabt hätte. Was mir vorschwebt: - Optik: Das Radio sollte nicht wie ein "Ufo" aussehen - Größe: Single DIN - Evtl. eine Gehäusevariante für ein Stand alone radio (AKA Küchen/Kofferradio) - Es soll möglich sein eine komplette MP3 Sammlung inkl. Cover zu speichern - Farbdisplay (soll auch MP3 cover anzeigen können) - 2*Rotary button bedienung (Ähnlich Becker Grandprix) + ein paar feste Funktionstasten - Radio features: * FM only (Mittelwelle/Langewelle und co ist denk ich heutzutage nicht mehr echt interessant) * Frequency diversity zur Empfangsverbesserung mit einer Antenne wäre schön * evtl. DRM (?) * RDS, inkl. Follow me, Radio text (+), TA, EON * Evtl. TIM (Aufzeichnung von Verkehrsnachrichten wenn das Radio eigentlich aus ist und wiedergabe wenn das Auto das nächste mal gestartet wird). * search tuning up/down * automatische Suche nach den aktuell stärksten Sendern (inkl. Aussortierung von dubletten auf Basis von RDS Infos) * Der Empfang sollte wirklich sehr gut sein. Gutes Groß- und Kleinsignalverhalten. * Abschaltbare Phantomspeisung (wichtig für "moderne" Autos, sonst ist der Empfang sehr besch§$%) * nur wenn Platz im Display ist: Senderlogogs sollten angezeigt werden - "MP3"-funktion: * MP3 Wiedergabe (alle Bitraten/VBR/ID3V1 und ID3V2 support) * MP3s, evtl. andere codecs (OGG, FLAC, ... ?) * Einfache und schnelle (!) Navigation durch große MP3 Sammlungen (Evtl. Hierachie Artist/Album/Track) * Datenspeicher: z.B. SDHC Karten. Es wäre auch denkbar mehrere Karten gleichzeitig zu unterstützen um den Speicher zu erweitern. Alternativ: Ein USB OTG Host mit Mass storage support. - Audio Optionen: * 4 Kanal Verstärker (Evtl. Class-D) * Fade / Balance * Einfacher Equalizer - Evtl. Bluetooth Hands free option - Design Grundsätze: * Funktionen sollten leicht erreichbar sein (keine 3 fach Shiftfunktionen auf Buttons, etc...) * Die Reaktion auf Benutzerfunktionen sollten schnell erfolgen. Wenn eine Funktion länger dauert sollte sie vor Beendigung schon eine Reaktion auf dem Display zeigen. - Sehr schön wäre auch die Möglichkeit um den CAN Bus von Autos mit einzubinden um Sonderfunktionen wie z.B. PDC auf dem Radio anzuzeigen. Sowas ist Herstellerspezifisch, man kann es jedoch in der Hardware vorsehen und in Software auswählbar gestalten. - Evtl. Optionen um andere selbst entwickelte Boards einfach in die Hard- und Softwareumgebung einzubinden, z.B. Amateurfunk transceiver, Datenlogger, ... - OBD2 Diagnose Option / Anzeigen oder Loggen von Sensordaten? Was haltet Ihr davon? Die Liste ist nur als Vorschlagliste zu verstehen und natürlich nicht 100% fest. Als CPU schwebt mir etwas in der Richtung Arm9E, evtl. auch etwas Cortex-mäßiges vor (NXP hat hier unter den LPCs z.B. einige Kandidaten). Das Decoding von MP3 kann man in der CPU machen, da gibt es einige Open source projekte die fertigen code anbieten der schon auf ARM7 controllern gut läuft. Da ich sowas ähnliches schon gemacht habe weiß ich sicher das solch ein Projekt definitiv auch mit wenig Leuten (2) machbar ist, allerdings würde ich sowas gerne mit mehreren Leuten zusammen machen. So kommt man sicher auch noch auf andere gute Ideen und Sachen sind einfacher zu realisieren weil man einfach nicht auf allen Gebieten ein Experte ist. Ich würde übrigens auch gerne wirklich alles Quelloffen machen, inkl. der Hardware. Viele Grüße, Kai
Ein Kopfhörerausgang fehlt noch und ein Eingang für Kassettenrekorder! Den Tuner willst Du auch bauen oder hast Du ein fertiges Modul?
Tropenhitze schrieb: > Ein Kopfhörerausgang fehlt noch und ein Eingang für Kassettenrekorder! > > Den Tuner willst Du auch bauen oder hast Du ein fertiges Modul? Kopfhörer im Auto ist verboten - jedenfalls für den Fahrer. Klar, Anschluss für Kasettenrecorder, Plattenspieler mit RIAA Entzerrung und ein Laufwerk für Original Edison-Wachswalzen. ;) Mal im Ernst, weiss jemand wie lang es analoges FM-Radio noch gibt ?
Tropenhitze schrieb: > Ein Kopfhörerausgang fehlt noch und ein Eingang für Kassettenrekorder! Dual MP3 playback wäre wirklich interessant. Einer zum Hörbuch hören über Kopfhörer für den Nachwuchs und einer zum Musik hören über Lautsprecher. Line-in fehlt auch noch auf der Liste. > Den Tuner willst Du auch bauen oder hast Du ein fertiges Modul? Fertige Chipsets nehmen und an Herstellervorbild halten was Layout und Bauteile betrifft. Da kenn ich mich zufällig mit aus :-)
Ohforf Sake schrieb: > Mal im Ernst, weiss jemand wie lang es analoges FM-Radio noch gibt ? Warum nicht Modulbauweise? Kommunikation per I²C und Sound per I²S. Was m.M. schön wäre: Doppeltuner Einer ist fürs aktive Hören zuständig, der andere scannt das Band um aktuell empfangbare Sender zu ermitteln. Sendertasten sind IMO obsolet. Ähnlich wie bei BMW: Im Display sind nur Sendernamen zu lesen, evtl. als "Cloud" (je besser der Empfang, desto größer) Was m.M. auch wichtig wäre: kontrastreiches Display und Lichtsensor. Was hilft einem das farbenfrohste Display, wenn man es bei Tag nicht lesen und man bei Nacht davon geblendet wird.
> Kopfhörer im Auto ist verboten - jedenfalls für den Fahrer. > Klar, Anschluss für Kasettenrecorder, Plattenspieler mit RIAA Entzerrung > und ein Laufwerk für Original Edison-Wachswalzen. ;) :-) Es gab mal fürs Auto Abspielgeräte für Singles die nicht unähnlich der CD Player von heute waren. > Mal im Ernst, weiss jemand wie lang es analoges FM-Radio noch gibt ? Da in Deutschland kaum jemand die einzige momentan valide Alternative (DAB[+]) "behört", wird es wohl ähnlich laufen wie bei DVB-T. DRM ist noch immer eher im Testbetrieb und qualitativ kein echter ersatz für FM, DAB(+) hat ein recht schlechtes Angebot (sowohl content als auch Empfänger) und viel anderes neueres zu FM gibt es hier nicht. Ich prophezeie FM noch ein langes leben.
Wirklich ne coole Idee! Man könnte ja ein Display wie im ipod touch verwenden. Ähm aber hey ich will ja nix miesmachen hier aber wie issn des mitti ABE bei so selbstbastelkram? :-/
Chris R. schrieb: > Ohforf Sake schrieb: >> Mal im Ernst, weiss jemand wie lang es analoges FM-Radio noch gibt ? > > Warum nicht Modulbauweise? > > Kommunikation per I²C und Sound per I²S. Ich wäre für FM fest einbauen und sonst eine Möglichkeit für Alternative analoge und digitale (I²S) Eingänge. > Was m.M. schön wäre: Doppeltuner > Einer ist fürs aktive Hören zuständig, der andere scannt das Band um > aktuell empfangbare Sender zu ermitteln. Sowas hat z.B. Becker (Living band oder so ähnlich heißt das). Keine schlechte Funktion. Um nur zu schauen wie gut Sender auf anderen Frequenzen empfangbar sind (RDS-AF) braucht man übrigens keinen 2. Tuner. > Sendertasten sind IMO obsolet. Ähnlich wie bei BMW: Im Display sind nur > Sendernamen zu lesen, evtl. als "Cloud" (je besser der Empfang, desto > größer) Stimmt, man kann durch Sender auch wie durch eine MP3 Sammlung navigieren. Man muss auch darauf achten das man keine Patente verletzt. > Was m.M. auch wichtig wäre: kontrastreiches Display und Lichtsensor. Was > hilft einem das farbenfrohste Display, wenn man es bei Tag nicht lesen > und man bei Nacht davon geblendet wird. Ja, auf jeden fall. Zur not würde ich auch ein S/W Display vorziehen. Aber bitte kein Oled. Die sind sehr schön und Kontraststark aber brennen ein und sind nach ein paar wochen Dauerbetrieb nur noch halb so hell.
> Ähm aber hey ich will ja nix miesmachen hier aber wie issn des mitti ABE > bei so selbstbastelkram? > :-/ Kann mir nicht vorstellen das ein Autoradio eine ABE braucht, lass mich aber gerne eines besseren belehren. Werde mich mal schlau machen.
Kai G. schrieb: > Was mir vorschwebt: > - Größe: Single DIN Heutzutage ist doch Doppel-DIN angesagt > - Farbdisplay (soll auch MP3 cover anzeigen können) mit Touchfunktion
G. L. schrieb: >> Was mir vorschwebt: >> - Größe: Single DIN > Heutzutage ist doch Doppel-DIN angesagt Bei Doppel din ist die Blende meist Herstellerspezifisch. Single DIN passt überall. Für Single DIN gibt es von fast jedem Hersteller Blendensätze. >> - Farbdisplay (soll auch MP3 cover anzeigen können) > mit Touchfunktion Ist Touch im Auto nicht unpraktisch weil man kein taktiles Feedback hat? Außerdem wäre das Display ständig mit Fettfingern begrabbelt und dann gerade bei Sonne schlecht ablesbar (wenn ich so an mein Telefon/Navi denke). Das Radio wird kein Navi oder ähnliches beinhalten für die man ein großes Display mit vielen Menüpunkten bräuchte.
Integrierter Speicher (SSD so ab 30GB) und WLAN zur automatischen Synchronisierung mit der heimischen Musiksammlung, sobald sich das Auto in Reichweite (m)eines Access-Points befindet.
Tobi schrieb: > Integrierter Speicher (SSD so ab 30GB) Ich verstehe unter SSD eine Pseudo-Festplatte mit IDE/SATA oder PCIe Anschluss (letzteres ist irrsinnig schnell und teuer). All das lässt sicht so einfach anschliessen. SD/SDHC, am besten mehrere, ist preiswert, klein und leicht machbar.
Tobi schrieb: > Integrierter Speicher (SSD so ab 30GB) und WLAN zur automatischen > Synchronisierung mit der heimischen Musiksammlung, sobald sich das Auto > in Reichweite (m)eines Access-Points befindet. Ja, wäre sehr interessant. Ich hab noch keine Erfahrung mit WiFi in selbstbauprojekten, sprich was und ob es da was bezahlbares gibt. Ich stelle mir das Handling von den ganzen Sicherheitsprotokollen und so kompliziert vor und evtl. wäre es am einfachsten für solch einen fall ein (uC)Linux zu benutzen, was ich für ein reines Autoradio allerdings wieder für Overkill halten würde. TCP/IP an sich (direkt im uC, ohne großes Betriebssystem) wäre ja heutzutage kein Problem mehr.
Ohforf Sake schrieb: > Ich verstehe unter SSD eine Pseudo-Festplatte mit IDE/SATA oder PCIe > Anschluss (letzteres ist irrsinnig schnell und teuer). > All das lässt sicht so einfach anschliessen. > SD/SDHC, am besten mehrere, ist preiswert, klein und leicht machbar. Ja, deswegen wäre ich auch für SD(HC). Viele Controller bringen auch schon eine echte SD Schnittstelle mit sich, sodass man nicht mal das langsamere SPI bemühen müßte. Das Feature mehrere Slots zu unterstützen ist denk ich besonders interessant.
Sehr interessantes Projekt! Das Display sollte im Dunkeln wirklich dunkel sein! Ich hatte nun schon 3 Autoradios die wunderschön blau leuchteten aber im Dunkeln unerträglich sind. Bluetooth als Freisprecheinrichtung ist ein Muß, aber das wird qualitativ wirklich schwierig. Mit Fahrgeräuschunterdrückung für den Gesprächspartner und dann noch Fahrgeräuschminderung per Gegenschall im Fahrzeug. Sollte doch per DSP zu machen sein. ODB2-Bordanzeigen und und und :-) Und das alles in einem einzigen DIN-Schacht ohne das es vor Hitze zerfliesst.
Beagleboard mit Android + Touch-TFT + USB-Tuner + Amp, fertig ist der erste Prototyp.
> Beagleboard mit Android + Touch-TFT + USB-Tuner + Amp, fertig ist der > erste Prototyp. Dürfte nen Grottenempfang haben und nicht gerade sehr stabil laufen. Aber für einen Quick & Dirty Demonstrator sicher nicht schlecht ;-)
Oliver Stellebaum schrieb: > Sehr interessantes Projekt! > Das Display sollte im Dunkeln wirklich dunkel sein! Ich hatte nun schon > 3 Autoradios die wunderschön blau leuchteten aber im Dunkeln > unerträglich sind. Mit einem Lichtsensor sollte das einfach machbar sein. > Bluetooth als Freisprecheinrichtung ist ein Muß, aber das wird > qualitativ wirklich schwierig. Mit Fahrgeräuschunterdrückung für den > Gesprächspartner und dann noch Fahrgeräuschminderung per Gegenschall im > Fahrzeug. Ja, ich würde auch ungern auf eine Freisprecheinrichtung verzichten. Gegenschall ist denk ich nicht nötig, aber man kann mit ein paar einfachen Maßnahmen die viel Experimente benötigen sowas realisieren. Der große Vorteil gegenüber anderen Systemen ist, das man Signalpausen (=Sprechpausen) hat mit denen man Störgeräuche abschätzen kann und zusätzlich noch ein Referenzsignal hat das bekannt ist und mit überlagertem Störsignal über das Mikro "zurückgehört" wird. > Sollte doch per DSP zu machen sein. Ja, und ein paar Monate Entwicklung und Tests für die Software für den DSP. Ein Arm9E ist zwar kein DSP, sollte aber genug Leistung für sowas mitbringen (Arm9E hat ein paar DSP instructionen wie MAC, ...). Man kann es ja so bauen, das man Software für sowas schreiben könnte, aber prinzipiell wäre es wahrscheinlich einfacher etwas fertiges zu benutzen. > ODB2-Bordanzeigen und und und :-) > Und das alles in einem einzigen DIN-Schacht ohne das es vor Hitze > zerfliesst. Da zerfliesst nix, OBD2 und Co machen keine Hitze (ausser beim Programmierer während er die Software schreibt) ;-) Die meiste Wärme macht die Sonne.
Kai G. schrieb: > Ist Touch im Auto nicht unpraktisch weil man kein taktiles Feedback hat? Wenn das System entsprechen flott reagiert denke ich nicht - zumal für die wichtigsten Bedienpunkte ja HW-Knöpfchen vorgesehen wären. > Außerdem wäre das Display ständig mit Fettfingern begrabbelt und dann > gerade bei Sonne schlecht ablesbar (wenn ich so an mein Telefon/Navi > denke). Würde aber von Display u. Einbauposition abhängen. > Das Radio wird kein Navi oder ähnliches beinhalten für die man ein > großes Display mit vielen Menüpunkten bräuchte. Die Anpassbar-/Erweiterbarkeitkeit würde sich aber drastisch erhöhen - erst dadurch würde ein solches Gerät breiteres Interesse wecken. http://www.car-pc.info/ kennst Du?
Jop das mit dem Beagleboard is find ich ein guter Ansatz. Damit haette man eine Leistungsstarke und bereits Standardisierte Plattform an die man nurnoch einzelne Stuecke anbauen muss. Eventuell waehre aber ein igepv2 besser geeignet da das noch mehr Schnittstellen onboard hat und das gleiche kostet.
G. L. schrieb: > Wenn das System entsprechen flott reagiert denke ich nicht - zumal für > die wichtigsten Bedienpunkte ja HW-Knöpfchen vorgesehen wären. > Würde aber von Display u. Einbauposition abhängen. > Die Anpassbar-/Erweiterbarkeitkeit würde sich aber drastisch erhöhen - > erst dadurch würde ein solches Gerät breiteres Interesse wecken. > > http://www.car-pc.info/ > kennst Du? Ich finde auch das touch panel cool aussehen, so ist es ja nicht... Ich stehe solchen Touchgeschichten immer negativ gegenüber weil ich finde das sie zu schlecht durchdachten Bedienkonzepten führen. Man macht mal hier, mal da einen Button hin statt sich vernünftig Gedanken über eine einfache und intuitive Bedienung zu machen. Wir hatten mal ein Demoradio mit einem Bildschirm der Ausfuhr, ähnlich dieser DVD Player für Autos. Das hatte sogar ein taktiles Feedback, vermutlich ein Elektromagnet oder ähnliches der auf die Displayscheibe wirkte (sicher mit 20 Patenten abgesichert). Es sah unheimlich toll aus und es machte spaß auf dem Display rumzudrücken, allerdings war es während der Fahrt praktisch nicht zu bedienen, mal abgesehen von ziemlich vielen anderen qualitativen Mängeln wie schlechte RDS Implementierung, schlechter Empfang, ... Wenn die Mehrheit ein Touch panel haben wollte würde ich mich evtl. umstimmen lassen, ist halt nur meine bescheidene persönliche Meinung ;-)
Ein Autoradio sollte man bedienen können, ohne hinzugucken. Vor langer, langer Zeit war links Lautstärke, rechts Sender und unten vielleicht paar Stationstasten. Das war idiotensicher und der Fahrer guckte, wo er hinfährt. Ich stelle mir ein Radio mit 4 Encodern vor (die sind billig und einknopfbedienung ist ein Irrweg). Etwa so : links unten drücken: Ein/Aus, drehen : Lautstärke links oben drücken : Menü für diversen Schnickschnack den man nie braucht, drehen : MP3 Ordner (Album) rechts unten drücken : Radio, drehen : Senderwahl rechts oben drücken : MP3, drehen : Titelwahl so kommt man schnell an die wichtigsten Funktionen und wird nicht abgelenkt... aber es geht sicher noch besser
Die Dicke wäre für mich wichtig. Wenn es nur 1-2cm tiefgang hat, könnte man es auch ohne Loch irgendwo anpappen. (oder über das bestehende drüberkleben... ;-) Wenn man eine größere Leistung haben will nimmt (baut) man sowiso noch einen extra Versärker.
ohforf schrieb: > Ein Autoradio sollte man bedienen können, ohne hinzugucken. > Vor langer, langer Zeit war links Lautstärke, rechts Sender und unten > vielleicht paar Stationstasten. Das war idiotensicher und der Fahrer > guckte, wo er hinfährt. Genau meine Rede :-) Ich denke man kann die Anzahl der Knöpfe noch auf 2 reduzieren ohne echt Komfort zu verlieren, allerdings müßte man dann einige Funktionen als normalen Druckknopf realisieren (z.B. Taste "Radio", "MP3", "AN/AUS"). Das 4-Knopf Konzept find ich aber echt nicht schlecht, wenn man das Designmäßig einigermassen hübsch hinbekommt, die Knöpfe nicht zu klein und noch gut bedienbar wären.
Hallo Ihr, die Idee finde ich super. Daher gleich mal eine Frage zum Empfangsteil: Das soll ja sicherlich nicht selbst neu entwicket werden? Hat Du da schon was im Auge? habe mal gegoogled und bin auf ein Modul namens RS500 von der Fa. Radioscape gestossen. Technisat verwendet das wohl auch in einem ihrer Empfänger. Auch die Elektor hat mal auf das Teil hingewiesen. Aber der Fa. Radioscape ging es wohl mal nicht so gut. Auf deren Homepage findet man keinen Hinweis auf das Modul. Aber unter http://www.ok1mjo.com/all/ostatni/t-dab_dvb-t_drm/Radioscape/RS500_Overview_High_Res.pdf habe ich eine Beschreibung gefunden. Das Modul kann alles, was wir brauchen. Walter.
Hallo! Das hört sich ja schon mal sehr interessant an. Hier mal ein paar Kriterien die ich an solch ein Gerät hätte (ein paar davon wurden ja schon angesprochen): - Einfache Bedienung (also extra Tasten für Lied vor/zurück sowie Ordner vor/zurück und vielleicht Pause) - Gut ablesbares Display, sowohl bei direktem Sonnenlicht als auch in der Nacht, nicht zuviel Grafik-Schnickschnack wie Videos etc. - USB-Anschluss für Stick oder externes CD-Laufwerk - Bluetooth-Freisprecheinrichtung - Remote-Ausgang für externe Endstufen So, und jetzt kommts ;) - 3x Preout mit hohem Ausgangspegel (ca. 4V) - Laufzeitkorrektur für die einzelnen Kanäle - Aktivweichen (Hochpass, Tiefpass, Bandpass) mit 6, 12, 18 und 24dB Flankensteilheit pro Kanalpaar - Kanalgetrennte Pegelregelung - parametrischer Equalizer - hohe Klangqualität (Wie man sehen kann bin ich Car-Hifi Fan...) Die Geräte von Alpine find ich vom Bedienkonzept her klasse, daran könnte man sich evtl. orientieren... MfG Stefan
Also das mit der Helligkeit, kann man echt schön mit einem Sensor machen, bei unserem letztem Leasing Wagen (Mercedes E Klasse) war vorne einer, wenn es hell war, hatte die Anzeige eine Weiß bis Besche Grundfarbe, sonst ehr dunkel Grau bis schwarz...
Laufzeitkorrektur? bei 2m Lautpsrecher-Abstand? und dann solche steilen Filter? Meinst du nicht, mit dem Phasendreck, der da kommt macht man mehr kaputt als man mit der Laufzeitkorrektur ausgleichen kann? :D Naja ich denke, man muss immer Aufwand und Nutzen abwägen. Wann man für so etwas eine Community aufbaut, findet sich später sicher jemand, der diese Spielereien umsetzt. Im ersten Anlauf wärs wohl geschickt, sich auf das Wesentliche zu beschränken und nur die Möglichkeiten im Hinterkopf zu behalten. Konkret: Schnittstellen in Hard- und Software vorsehen. Vielleicht ist es ja tatsächlich der richtige Weg, dafür ein Website-Portal aufzumachen mit Forum, Artkeln, Kommentargedöns,... So wie das bei manchen anderen DIY-Projekten auch der Fall ist. Ich will hier keine Werbung machen ;) Die Resonanz ist auf jeden Fall da und das Projekt ist umfangreich. Wenn's nur schon fertig wär, mein Radio is kabutt!
Armin schrieb: > Laufzeitkorrektur? bei 2m Lautpsrecher-Abstand? > und dann solche steilen Filter? Meinst du nicht, mit dem Phasendreck, > der da kommt macht man mehr kaputt als man mit der Laufzeitkorrektur > ausgleichen kann? :D Ok, ich versuch das mal etwas zu erklären: Normale Musik ist in Stereo aufgenommen. Um die Musik also genau so zu hören wie sie aufgenommen wurde, werden die Lautsprecher in einem gleichseitigen Dreieck auf den Hörplatz ausgerichtet, das nennt man Stereodreieck. In meinem Auto befinden sich die Hochtöner an den A-Säulen, die Tiefmitteltöner in den Vordertüren und der Subwoofer im Kofferraum. Das ist der Grundaufbau einer "richtigen" Car-Hifi Anlage, dazu kommt natürlich noch eine Dämmung der Türen, um den Tiefmitteltönern ein richtiges Gehäuse zu bieten und peinliche Klappergeräusche zu vermeiden. ;) Da nun jeder Lautsprecher unterschiedlich weit weg ist, ergeben sich am Fahrersitz logischerweise sowohl Laufzeit- als auch Pegelunterschiede. Und diese führen dann zu Auslöschungen und Überhöhungen im Gesamtfrequenzgang am Fahrersitz. Um die Lautsprecher also dazu zu bringen, so zu spielen als wären sie alle gleich weit weg, benötigt man sowohl Laufzeitkorrektur als auch Pegelanpassungen. Und natürlich auch die Möglichkeit, jeden Lautsprecher nur die Frequenzen spielen zu lassen, für die er gedacht ist. Da ein Auto aber auch je nach Modell einen typischen "Fahrzeugfrequenzgang" hat, benötigt man noch einen Equalizer um solche Buckel und Täler auszugleichen. Wenn das alles richtig eingestellt ist, hat man eine richtige "Bühne" im Auto, so als ob die Band schön verteilt auf der Motorhaube sitzt wie im Studio auch. Hast du schon mal eine gut eingestellte Car-Hifi Anlage gehört? Damit meine ich nicht diese Proleten-Kisten, bei denen nur möglichst viel Bumm-Bumm in den Kofferraum geschmissen wurde... Dann weißt du was ich meine, denn das ist als ob die Sonne aufgeht. ;) Wenn man allerdings nur ein bisschen Hintergrund-Gedudel an den Werkslautsprechern haben will, ist der Aufwand natürlich zu hoch...
Stefan B. schrieb: > Da nun jeder Lautsprecher unterschiedlich weit weg ist die LS schallen von unterschiedlichen Winkeln an dein Ohr, mit LZ-Korrektur kann man das nicht ändern. Der Abstand zum Ohr ist hingegen fast identisch, da kommt man höchstens mal auf 10cm Unterschied. Die Schallgeschwindigkeit beträgt 343m/s, oder anders 2,9ms/m. Für 10cm würde die Differenz also 0,3ms Zeitdifferenz betragen. Ob den Unterschied auch von geschulten Ohren erkennbar ist, mag ich zu bezweifeln. Wie Armin bereits sagte, denk ich auch dass man beim Versuch so kleine Differenzen ausgleichen zu wollen mehr Schaden anrichtet als korrigiert...
Ich bin keiner dieser Voodoo-Anhänger die 5000 Euro nur für ein Super-Hyper-Netzkabel ausgeben, keine Angst. Und auch niemand, der irgendwelche zusammengeschusterten pseudo-physikalischen Beweise für die haarsträubendsten Produkte für bare Münze nimmt. ;) Ich bin ein technisch und physikalisch veranlagter Mensch. Also bitte spart euch die herablassende Art. Die Hochtöner sind direkt auf mich ausgerichtet, die sind das wichtigste. Denn die Hochtöner haben eine gewisse Richtcharakteristik. Diese Charakteristik ist von Membranfläche und Frequenz abhängig, aber das wisst ihr ja sowieso :P Bei den Tiefmitteltönern ist das nicht mehr ganz so wichtig, die Abstrahlung vom Subwoofer ist sowieso kugelförmig, und er gibt auch nur den Frequenzbereich wieder, den man nicht mehr orten kann. Die Differenz der Abstände der beiden Hochtöner beträgt bei mir übrigens ca. 50cm, und diesen Unterschied hört man. Auch ein nicht "geschultes" Ohr merkt das einwandfrei. Nimm ein Radio mit Laufzeitkorrektur, lass nur die vorderen Lautsprecher spielen und leg eine CD mit einer guten Aufnahme ein. Dann geh in das Menü der Laufzeitkorrektur, schließe die Augen und drehe nach Gefühl am Regler. Irgendwann wirst du merken, dass auf einmal der Klang räumlich abgebildet wirkt. Die Instrumente rücken aus dem diffusen Brei voneinander weg und stehen einzeln gestaffelt vor dir auf der Motorhaube. Und wenn du dir dann den Verzögerungswert ansiehst merkst du, dass der Wert ziemlich genau mit dem berechneten übereinstimmt. Ich behaupte nicht, dass meine Anlage perfekt abgestimmt ist, denn um das alles perfekt einzustellen benötigt man viel Erfahrung. Aber trotzdem haben auch Leute mit normaler Werksanlage eindeutig einen Unterschied festgestellt. Aber wahrscheinlich kann ich hier erzählen was ich will, bei so vielen Vorurteilen hat es einfach keinen Sinn...
Also, Hardwaretechnisch die Möglichkeit der Laufzeitkorrektur vorsehen, wenn die Kiste dann man läuft, kann das ein Profi einproggen...
GGast schrieb: > Also, Hardwaretechnisch die Möglichkeit der Laufzeitkorrektur vorsehen, > wenn die Kiste dann man läuft, kann das ein Profi einproggen... Ich denke auch das sollte machbar sein, zumindest als option der man sich "nachher" widmen kann. Da man in diesem Fall (jumperoption oder so) das Audio-signal vom radio durch den uC schleusen muss sollte man aufpassen das man snr und co. nicht zu sehr negativ beeinflusst. Oder man nimmt direkt einen digitalen Empfänger mit integriertem audio dsp. Von einem der 2 Marktführer weiss ich sicher das er eine Laufzeitkorrektur mitbringt, die man aber AFAIR mittels zu kaufenden code freischalten musste...
>(jumperoption oder so)
Oder so einen 4051 Analog-Multiplexer oder so... (Die modernen Typen
haben nur 6Ohm Innenwiderstand, wie geeignet diese für Audiosignale sind
weiß ich nicht)
Eine Laufzeitkorrektur für MP3 Playback wäre übrigens sehr einfach zu realisieren, auch ohne zusätzliche Hardwareoption. Was die Filter betrifft, da bin ich sehr skeptisch. Der Hardwareaufwand wäre immens und die Phasengänge der Filter machen sicher mehr kaputt als das sie helfen, gerade wenn man über Filter 4. Ordnung spricht.
Einen DSP kann man sinnvollerweise als Option (Aufsteckplatine auf Pfostenleisten) vorsehen, wenn es denn mehr als einen Nutzer gibt, der das braucht. Gast
Hallo ich habe mir hier alles durchgelesen und muss sagen es hört sich alles sehr interessant an. An DAB scheint aber keiner mehr interessiert zu sein, zur Zeit werden noch Programme in diesen Mode ausgesendet und wer zur der (kleinen ?) Minderheit gehört die DAB nutzen wissen das es sich deutlich besser anhört als FM, mann muß es nur mal vergleichen, aber leider will sich ja die Masse darauf nicht einlassen. Gegen einen Punkt möchte ich aber energisch Wiedersprechen " * FM only (Mittelwelle/Langewelle und co ist denk ich heutzutage nicht mehr echt interessant)" Wer schon mal im weiter entfernten Ausland mit den Auto unterwegs war und sich nicht nur durch Musik berieseln lassen wollte wird erkannt haben wie wichtig LW und MW heute noch sein kann. Gerade auf LW werden noch die Programme ausgestrahlt die "Radio zum Hinhören" sind, ich denke dabei an den DLF, Deutschland Radio Kultur und BBC 4, alles bei Internetzugang ohne Probleme zu "Empfangen" aber bei Mobilbetrieb im Auto ? Ich hoffe das ich nicht zu weit vom Thema abgedriftet bin. Mit freundlichen Grüßen "Radio Freund"
Kai G. schrieb: > Gegenschall ist denk ich nicht nötig, aber man kann mit ein paar Du kennst mein Auto nicht ;-) Vielleicht geht es ja den Gegenschall zu berechnen indem man einige Kalibrierungsfahrten macht, bei 50, 100, 130km/h oder so. Sicher, damit bekommt man nur gleichmäßige Motorgeräusche weg und Fahrtwind, würde vielleicht schon was nützen. > Da zerfliesst nix, OBD2 und Co machen keine Hitze (ausser beim Momentan habe ich so ein billiges Chinaradio, da ist hinten ein kleiner Lüfter drin und der rappelt nun auch noch. Während der Fahrt hört man das nichtmal selber, aber wenn man per Bluetooth telefoniert kann es das andere Ende sehr gut hören. > Programmierer während er die Software schreibt) ;-) > Die meiste Wärme macht die Sonne.
Ich hab jetzt nicht alles durchgelesen, aber wo wohnst du denn? Ich frage, weil ich glaube, dass man sich schon ab und zu treffen sollte um das weitere Vorgehen zu planen oder Prototypen zu testen oder so. Prinzipiell bin ich auf jeden Fall interessiert.
Hallo zusammen, erstmal find ich die Idee prinzipiell richtig gut! Wie man an den bisherigen Beiträgen erkennen kann, gibt es hier scheinbar 2 Fraktionen: Die HiFi-Freaks, und die Radio-Höhrer (zu letzteren zähl ich mich). Die Hifi-Freaks bauen Zusatzverstärker und -Lautsprecher ein, und legen im allgemeinen keinen Wert auf einen integrierten Verstärker. Hier ist dann Platz für einen DSP oder was auch immer. Als Radio-Höhrer hab ich hingegen absolut keine Lust, an meinem Auto rumzuschrauben, und Lautsprecher und/oder Verstärker einzubauen. Ich würde also grossen Wert darauf legen, mein bisheriges Radio ohne grosse Umbauten ersetzen zu können. Da wo bei den HiFi-Freaks der DSP sitzt, brauch ich also einen simplen (4-Kanal) Verstärker. Vielleicht kann man das modular gestalten, für den Fall, daß es mal einem dieser Hifi-Verrückten gelingen sollte, mich von der Sinnhaftigkeit einer solchen "Klangverschlimmbesserung" zu überzeugen. Zum Betriebssystem: ich würde klar für Linux plädieren! Wenn ohnehin ein Beagleboard o.Ä. verwendet wird, bietet sich das geradezu an! Auch die bereits weiter oben angesprochene WLAN-Anbindung ist damit direkt erschlagen. Diese Anbindung betrachte ich im Übrigen als extrem wichtig. Bis so ein Projekt wirklich rund läuft, und keine täglichen Updates mehr erfordert dürfte erstmal eine ganze Zeit vergehn....und wer hat schon Lust, für jede Kleinigkeit zum Auto zu rennen? Harry
Sven schrieb: > Ich hab jetzt nicht alles durchgelesen, aber wo wohnst du denn? Ich > frage, weil ich glaube, dass man sich schon ab und zu treffen sollte um > das weitere Vorgehen zu planen oder Prototypen zu testen oder so. Meine PLZ ist 47506. Klar, wenn das ganze konkreter wird wäre es sicher interessant sich auch mal zu treffen! > Prinzipiell bin ich auf jeden Fall interessiert. Klasse, das hört man gerne!
Harald L. schrieb: > Vielleicht kann man das modular gestalten, für den Fall, daß es mal > einem dieser Hifi-Verrückten gelingen sollte, mich von der > Sinnhaftigkeit einer solchen "Klangverschlimmbesserung" zu überzeugen. Ja, in gewissen Grenzen ist eine Modularität sicher nicht schlecht! > Zum Betriebssystem: > ich würde klar für Linux plädieren! Ich bin absolute überzeugt davon das man sowas komplexes wie Linux besser nicht auf einem Autoradio hat. Wenn man vorhätte ein Multimediasystem mit DVD, etc. zu implementieren wäre das sicher von Vorteil aber durch die Komplexität des ganzen schleichen sich unheimlich viel Fehlerquellen ein die man durch eine schlanke firmware die man komplett selbst geschrieben hat und man die komplette Übersicht hat vermeiden kann. Ich hab mit beidem Erfahrung und weiss wie einfach es ist ein deterministisisches und stabiles System mit einer von 0 auf selbst geschriebenen Firmware ist und wie kompliziert mit uCLinux/Busybox und Konsorten. > Auch die bereits weiter oben angesprochene WLAN-Anbindung ist damit > direkt erschlagen. Hat das Beagleboard Wlan on board? Wie ist es angebunden? Über einen internen USB-Bus? > Diese Anbindung betrachte ich im Übrigen als extrem wichtig. Bis so ein > Projekt wirklich rund läuft, und keine täglichen Updates mehr erfordert > dürfte erstmal eine ganze Zeit vergehn....und wer hat schon Lust, für > jede Kleinigkeit zum Auto zu rennen? Wie wäre ein Update über SD Karte über einen Bootloader. Beim einschalten checkt das Radio ob eine neue Firmware auf der Karte ist und programmiert sie "nebenbei" neu. Naja, Wlan wäre wirklich schon nicht uninteressant...
>Wie wäre ein Update über SD Karte über einen Bootloader. Beim >einschalten checkt das Radio ob eine neue Firmware auf der Karte ist und s/einschalten/einschalten mit gedrueckter Tastenkombination/ Gast
Kai G. schrieb: >> Zum Betriebssystem: >> ich würde klar für Linux plädieren! > > Ich bin absolute überzeugt davon das man sowas komplexes wie Linux > besser nicht auf einem Autoradio hat. Wenn man vorhätte ein > Multimediasystem mit DVD, etc. zu implementieren wäre das sicher von > Vorteil aber durch die Komplexität des ganzen schleichen sich unheimlich > viel Fehlerquellen ein die man durch eine schlanke firmware die man > komplett selbst geschrieben hat und man die komplette Übersicht hat > vermeiden kann. > Ich hab mit beidem Erfahrung und weiss wie einfach es ist ein > deterministisisches und stabiles System mit einer von 0 auf selbst > geschriebenen Firmware ist und wie kompliziert mit uCLinux/Busybox und > Konsorten. > bin ich völlig anderer Meinung! Ich hab auch mit beiden Varianten Erfahrung. Aber spätestens, wenn du einen TCP/IP-Stack implementierst, ist es mit dem Determinismus ohnehin vorbei. Wenn man Linux auf das wirklich Notwendige zurechtstutzt, ist das ein excellentes und stabiles Framework für so ein Vorhaben. OpenWrt ist z.B. eine ausgezeichnete Ausgangsbasis! > > Hat das Beagleboard Wlan on board? Wie ist es angebunden? Über einen > internen USB-Bus? > Stick per USB...der kann dann ggf auch an empfangsgünstiger Stelle installiert werden. > > Wie wäre ein Update über SD Karte über einen Bootloader. Beim > einschalten checkt das Radio ob eine neue Firmware auf der Karte ist und > programmiert sie "nebenbei" neu. > Naja, Wlan wäre wirklich schon nicht uninteressant... Genau! Wenn das Auto im Carport steht, kann ich per WLAN & SSH drauf zugreifen, und an dem System arbeiten. (Auch hier hilft uns Linux, weil auch SSH hier nicht neu geschrieben werden muss) Ach ja....und unterwegs kann darüber in Verbindung mit dem Mobiltelefon der Stick als AP arbeiten, und man kann per Laptop ins Netz. Harry
Als Teilzeit-Hifiverstärker-Hobbybastler kenne ich von da vor allem ein Problem: Es gibt keine Zigarrenkisten mehr ;-) Und vor allem niemanden, der noch Zigarrenkisten als wohnzimmergeeignetes Gehäuse akzeptiert. Software lässt sich beliebig komplex und in professioneller Qualtät gestalten, Platinen ebenso, aber bei den popeligen Dingen wie Gehäusen, Steckverbindern, Schalter, Blenden und Knöpfen hat man als Hobbyist keine Chance. Entweder man findet ein fertiges Gerät als Basis für die Entwicklung, oder es finden sich so viele Mitstreiter, daß man mal eben ein paar Spriztgußwerkzeuge in Auftrag geben kann, oder es sieht am Ende immer aus wie selbstgebastelt. Oliver
> bin ich völlig anderer Meinung! > Ich hab auch mit beiden Varianten Erfahrung. Aber spätestens, wenn du > einen TCP/IP-Stack implementierst, ist es mit dem Determinismus ohnehin > vorbei. > Wenn man Linux auf das wirklich Notwendige zurechtstutzt, ist das ein > excellentes und stabiles Framework für so ein Vorhaben. Ja, allerdings arbeitet man an 5 verschiedenen Baustellen (Scripts, deamons, Treiber, ...) statt an einer einzigen Firmware. Alles was ich so kenne mit Linux arbeitet auch nicht stabil. z.B. mein Chumby oder auch alle Fritz!boxen die ich so hatte (7050, 7270), Belkin router, etc... Ich nicht das jetzt ein Linux flamewar entsteht, aber wenn Wlan das einzige ist was einen zu Linux drängt, dann gibt es doch sicher noch andere Alternativen, oder?
> Software lässt sich beliebig komplex und in professioneller Qualtät > gestalten, Platinen ebenso, aber bei den popeligen Dingen wie Gehäusen, > Steckverbindern, Schalter, Blenden und Knöpfen hat man als Hobbyist > keine Chance. Entweder man findet ein fertiges Gerät als Basis für die > Entwicklung, oder es finden sich so viele Mitstreiter, daß man mal eben > ein paar Spriztgußwerkzeuge in Auftrag geben kann, oder es sieht am Ende > immer aus wie selbstgebastelt. Man könnte ein Front aus Kunststoff fräsen lassen (http://www.schaeffer-ag.de???). So ein Radio Chassis an sich ist wiederum nur ein Stück gestanztes Blech das an einigen Stellen gebogen ist. Irgendwo hatte ich vor ein paar Tagen eine Webseite gesehen mit einer Firmwa die genau sowas (blech biegen/ausbrüche machen/...) preisgünstig anbot. Ich denke auch das ein schönes Frontpanel die größte Herausforderung ist. Aus einem Schwarzem Stück Plastik sollte sich da eigentlich was fräsen lassen, vor allen dingen wenn es eben nicht wie alle anderen Autoradios aussehen soll (Transformer/Ufo mässig) und sich dezent in ein bisheriges Fahrzeug integrieren lassen soll. Ich weiß nicht wie utopisch es ist evtl. sogar einen Sponsor zu finden, oder eine Firma die kostenlos die mechanischen Teile erstellen würde wenn man etwas vorzuweisen hat und es wirklich so aussieht als ob man in der Lage ist ein echtes "Produkt" zu machen. Ein anderes Problem wäre noch das Platinenlayout an sich. Ich nutze für Hobbysachen eigentlich immer Eagle, allerdings ist das wie bekannt ist auf eine halbe Eurokarte begrenzt und ein Autoradio doch ein bißchen größer...
WLan in einem Auto? Wozu das denn? Abgesehen davon, das man die Antenne dann auch noch rausführen müsste, finde ich die "Synchronisation" per USB-Stick um Welten praktikabler und schneller. Meine Wunschliste - DAB+ - UKW - MP3 - Audio-CD (ergo: CD-Laufwerk) - USB-Anschluss für Stick - alternativ SD-Slot? - Bluetooth/Freisprecheinrichtung - 4-6 Stationstasten, im CD/Mp3-Modus gerne auch mit anderen Funktionen - Lautstärke & Titel/Ordnerwahl als echte Tasten. - direkter Anschluss für Lautsprecher. Also eigentlich gar nicht soo viel ;)
Kai G. schrieb: > Ja, allerdings arbeitet man an 5 verschiedenen Baustellen (Scripts, > deamons, Treiber, ...) statt an einer einzigen Firmware. > Bei so einem Projekt ändert das auch nix, wenn man das in einer Software macht...wird auf deine Art eher unübersichtlicher. > Alles was ich so kenne mit Linux arbeitet auch nicht stabil. z.B. mein > Chumby oder auch alle Fritz!boxen die ich so hatte (7050, 7270), Belkin > router, etc... Wenn die Hardware in Ordnung ist, laufen meine Router absolut stabil. Bes. Fritz-Boxen sind nicht gerade eben für ihre Stabilität bekannt. Und die Teile, wo die Probleme auftreten sind auch nicht Open-Source, sondern was propiätäres von AVM. Abstürze in embedded linux-Geräten würde ich zu >50% auf Hardwareprobleme zurückführen (Überhitzung etc..) Ich selbst betreibe einen Linksys WRT54g in einem wetterfesten Gehäuse auf der Spitze meines Antennenmast hier auf dem Haus. Das läuft mittlerweile seit >4j und ich kann mich an keinen einzigen Absturz erinnern. > > Ich nicht das jetzt ein Linux flamewar entsteht, aber wenn Wlan das > einzige ist was einen zu Linux drängt, dann gibt es doch sicher noch > andere Alternativen, oder? die da währen???? WLAN erfordert zwingend ein Netzwerkprotokoll. Was ausser TCP/Ip würdest du vorschlagen? Ich versteh vollkommen, wenn im kommerziellen Bereich für solche Projekte "selbstgestrickte" Software zum Einsatz kommt. Wenn das Gerät auf den Markt kommt, wird da i.d.R. auch nichts mehr verändert. Das Ziel hier ist allerdings nicht ein Produkt, sondern ein höchst exclusives und individuelles Gerät. Das heist aber auch, daß die Softwareentwicklung niemals einen wirklichen Endpunkt erreichen wird. Aus diesem Grund wünsche ich mir bei der Software (noch mehr als bei der Hardware) Modularität! Linux bringt die von Haus aus mit. Von den vielen Rädern, die man damit eben NICHT neu erfinden muss, will ich hier gar nicht reden. Harry
Ich finde die Idee echt klasse! Mein Wunschliste: - UKW - MP3 - USB-Anschluss für Stick - SD-Slot - Bluetooth/Freisprecheinrichtung - Lautstärke & Titel/Ordnerwahl als echte Tasten - Farbdisplay - Touchscreen mit Forcefeedback (nicht zwingend) Wlan halte ich nicht für sinnvoll und könnte deshalb auch gerne auf ein emb. Linux im Autoradio verzichten. Ein CD-Fach brauche ich auch nicht, wenn ein interner Speicher vorhanden ist. Die CDs würden nur mein Handschuhfach zumüllen. Ein schönes Frontpanel finde ich sehr wichtig
Ich hab das hier mal überflogen, baut ihr hier grade eine Eierlegende Wollmilchsau oder ein Autoradio?
Hallo zusammen, ich finde das auch interessant! Vor allem dieses: Kai G. schrieb: > Was mir vorschwebt: > - Optik: Das Radio sollte nicht wie ein "Ufo" aussehen > - Größe: Single DIN > - 2*Rotary button bedienung (Ähnlich Becker Grandprix) + ein paar feste > Funktionstasten ja, also von der Optik und Bedienung her würde mir auch sowas wie die Becker-Radios vorschweben. Wobei mir da die aktuellen Traffic-Pro eigentlich schon zu "bunt" wären, also von mir aus dürfte es auch gerne ein Monochromdisplay sein (nett wäre eines mit heller Schrift auf schwarzem Grund wie es früher bei Becker mal gab). Aber gegen ein Farbdisplay hätte ich auch nichts wenn die Software offen ist, könnte es ja dann bei Bedarf auch einfarbig ansteuern ;-) > * Einfache und schnelle (!) Navigation durch große MP3 Sammlungen > (Evtl. Hierachie Artist/Album/Track) > * Datenspeicher: z.B. SDHC Karten. Es wäre auch denkbar mehrere Karten > gleichzeitig zu unterstützen um den Speicher zu erweitern. Alternativ: > Ein USB OTG Host mit Mass storage support. SDHC fände ich auch sehr gut geeignet. Vor einigen Jahren (ca. 2002) habe ich mir einen MP3-Player fürs Auto gebaut, mit Festplatte allerdings, da ich >=30GB speichern wollte und damals selbst Notebook-HDs gerade mal diese Größe hatten; an Flashspeicher war daher nicht zu denken. Aber heute ist das ja zum Glück anders. Ein optisches Laufwerk bräuchte ich dabei nicht. > - Design Grundsätze: > * Funktionen sollten leicht erreichbar sein (keine 3 fach > Shiftfunktionen auf Buttons, etc...) > * Die Reaktion auf Benutzerfunktionen sollten schnell erfolgen. Wenn > eine Funktion länger dauert sollte sie vor Beendigung schon eine > Reaktion auf dem Display zeigen. > - Sehr schön wäre auch die Möglichkeit um den CAN Bus von Autos mit > einzubinden um Sonderfunktionen wie z.B. PDC auf dem Radio anzuzeigen. > Sowas ist Herstellerspezifisch, man kann es jedoch in der Hardware > vorsehen und in Software auswählbar gestalten. > - Evtl. Optionen um andere selbst entwickelte Boards einfach in die > Hard- und Softwareumgebung einzubinden, z.B. Amateurfunk transceiver, > Datenlogger, ... > - OBD2 Diagnose Option / Anzeigen oder Loggen von Sensordaten? und auch das wäre mir letztendlich wichtig: > Ich würde übrigens auch gerne wirklich alles Quelloffen machen, inkl. > der Hardware. Zu der Linuxfrage noch etwas (ich hoffe es kommt zu keinem Flamewar...): also nach den Erfahrungen mit der Entwicklung meines Players hatte ich mir eigentlich schon länger gedacht, dass ich wenn ich ihn nochmal aufbauen würde auch lieber Linux als Basis verwenden würde. Ich habe damals einen IPC@CHIP von Beck verwendet (kennt wahrscheinlich keiner, ist ein kleiner x86-Rechner auf dem ein DOS-kompatibles RT-OS läuft). Das Gerät läuft zwar nach wie vor ohne (oder fast ohne, wie das eben so ist findet man immer noch was zu verbessern daran ;-) ) Probleme, aber softwaretechnisch musste man doch einiges selbst machen was bei Linux eben schon mit dabei wäre (fing z.B. schon bei FAT32 und FTP an; rsync und SSH hätte ich mir noch gewünscht, usw...). Wobei mir aber Stabilität letztendlich wichtiger ist als Features. Und da Linux sicherlich komplexer ist als ein komplett eigenes System und somit auch potenziell mehr Fehler hat. Andererseits dürfte es aber gerade in den Basisfunktionen (Dateisystem, Netzwerk, Scheduler etc.) wieder besser durchgetestet sein... Gruß, Mathias
Mathias A. schrieb: > aufbauen würde auch lieber Linux als Basis verwenden würde. Ich habe > damals einen IPC@CHIP von Beck verwendet (kennt wahrscheinlich keiner, > ist ein kleiner x86-Rechner auf dem ein DOS-kompatibles RT-OS läuft). son IPC liegt bei mir auch noch rum...war mir aber für weitere Projekte zu teuer. > Wobei mir aber Stabilität letztendlich wichtiger ist als Features. Und > da Linux sicherlich komplexer ist als ein komplett eigenes System und > somit auch potenziell mehr Fehler hat. Andererseits dürfte es aber > gerade in den Basisfunktionen (Dateisystem, Netzwerk, Scheduler etc.) > wieder besser durchgetestet sein... > Ich möchte wetten, daß die Anzahl der Bugs / Zeile Quellcode deutlich niedriger ist, als dieser Wert bei den allermeisten Selbstbau-Projekten in diesem Forum! Die Kernfunktionen bei Linux sind tausendfach getestet, und zum Teil sogar in kritischen Bereichen im Einsatz. (Bsp.: SE-Linux-Erweiterung: wurden von den freundlichen Schlapphutträgern vom NSA beigesteuert...würden die sicher nicht tun, wenn Linux nicht ohnehin die beste Basis für so ein Projekt gewesen wäre) Ausserdem wiederstrebt es mir, Code, der bereits existiert UND getestet ist neu zu schreiben. Wovor die meisten Schiss haben: "das Schreiben von Devive-Treibern" ...auch das ist keine Kunst, wenn man bereit ist, sich da ein kleinwenig einzuarbeiten. Beispielcodes für "einache" Device-Treiber gibts ja genug im Kernel. (I²C Bitbanging-Treiber z.b.) Ich glaube nicht, daß es gelingt, die vollständige Software für so ein Projekt "from scratch" aus dem Boden zu stampfen, und das ganze dann auch noch so fehlerfrei, daß es mit einem Linux-System konkurrieren kann. Und jetzt möchte ich mal noch ein weiteres Argument ins Spiel bringen: Alle Welt redet über heim/haus/hof/auto-vernetzung.....als (einheitliches) Protokoll kristallisiert sich immer mehr TCP/IP heraus...über welches Medium auch immer. Jedoch wird es sich dabei in Zukunft sicher nicht mehr um IP v4, sondern um IP v6 handeln. Einen IPv4-Stack hab ich zu DOS-Zeiten gemeinsam mit einem Freund programmiert....bei einem v6-stack hätte ich grosse Bedenken, das zu stemmen... Wozu das Ganze? Wie ich bereits oben geschrieben hab, interessiert mich der eigentliche HiFi-Aspekt weniger. Was ich mir allerdings vorstellen könnte, wäre, eine Netzwerkleitung in den Kofferraum zu legen, und dort einen weiteren Car-PC anzubinden. Die Ideen gehen da in Richtung Navigation (Ja1!...auch da tut sich was in der Open-Source-Scene) Ich denke, daß man sich (zumindest hinsichtlichtlich der Software) nicht am Heute, sondern am Morgen orientieren sollte. Mobile Breitbandzugänge sind zukünftig auch für jedermann bezahlbar. Um diese Dienste sinnvoll nutzen zu können, bedarf es genormter Protokolle und eine zuverlässige Implementierung derselben. Linux leistet das, und ist extrem skallierbar. Harry
Die Idee eines Open Source Autoradios ist schon mal super. Meine Meinung im Einzelnen: - HiFi Qualitäten brauche ich nicht. Hab genug Störgeräusche im Auto. - WLan finde ich extrem sinnvoll. Ich möchte eben nicht eine Synchronisation mit meinem MP3 Bestand per Hand (resp. USB-Stick) vornehmen müssen. Das kann ich jetzt schon (ja, es gibt schon Autoradios, die MP3s vom USB-Stick lesen). Der Mehrwert dieses Projektes wäre für mich, dass man die interne Speicherkapazität so auslegen kann, dass meine komplette Sammlung in das Auto passt und dann auch automatisch bein Stehen im Carport mit dem MP3-Server im Haus synchronisiert wird. So ca. 50 Gbyte würden übrigens für mich reichen. Und der zweite große Vorteil wäre der Einfluss auf die Front-Gestaltung. Ich bin auch für so wenig Interface-Elemente wie möglich (gab oben schon gute Vorschläge) und keine Farbe oder so was. Dezent und schlicht und bedienbar ohne hinzukucken! Normalerweise schreibe ich mir auch für alles Selbstgebastelte ein eigens Mini- (eher Mikro-) Betriebssystem, dann weiß ich was es macht. Aber das WLan ==> Linux Argument is absolut überzeugend. Und stabil ist Linux auf der richtigen Hardware allemal (Linksys WRTG, Buffalo NAS etc pp). Beitragen könnte ich wohl (in kleinem Umfang) bei der Software (in C). Bei Hardware stümpere ich nur so rum.
Hifi im Auto ? Das Auto ist einfach ein scheiß Resonanzkörper also hifi nein danke. Elektronische Frequenzweiche usw ist da schon interessanter. Naja linux wär ned schlecht aber 300MHz und linux + noch ein paar Spielereien ? Geht ned. Wie schon erwähnt wär der OMAP (L)xxx eine gute Basis. Die Bedeinung ist so eine Sache morgens zur arbeit will ich nur meinen Ö3 hören sonst nix und beim heimfahren auch. Dann am Wochenende steigen die Ansprüche die Freundin will die MP3 Sammlung durchhören :-( da ist dann ein Touch praktisch. Aber warum macht man die bedienung nicht gleich freiprogrammierbar. SQLite DB rein um Favoritenliste usw anzulegen. Also als HW basis: TI OMAP als MPU einen fertigen Audio IC von TI, AD usw dran platinen intern wird Sound via I2S und Daten über SPI übertragen. Extern CAN + I2C Wo kann ich helfen ? Mich nerven die ganzen Wunschlisten, wünsche hat jeder ! Dies Projekt ist auch ned in ein bis zwei Monaten fertig ! Ich kann dich unterstützen bei der Firmware und (Kernelprogrammierung bin noch beim einarbeiten), minimal HW, Testen und Projektmanagment. Was wird gebraucht ? 1. Kleine Website mal. 2. Ein Kern-Entwicklerteam welche dauerhaft an dem Projekt arbeiten und nich wie andere einfach abspringen. 3. Obwohl es Opensource ist werden auch Geld und andere Ressourcen benötigt. (gründung Verein oder so in die Richtung) 4. Viel Kaffee und eine Mailingliste
> Ich wollte mal vorsichtig fragen ob es Leute gäbe die prinzipiell > Interesse daran hätten an einem noch nicht existierenden Open source > Projekt teilzunehmen bei dem es darum geht ein komplettes Autoradio zu > entwickeln. Ich halte das grundsatzlich fuer eine gute Idee, sogar so gut das sie mir selber bereits vor 5-6Jahren gekommen ist. (Leider bin ich aber nie dazu gekommen das fertigzustellen) Und grundsatzlich ist es ja auch mal eine nette Idee ein groesseres Project mit ein paar Leute durchzuziehen. Allerdings sehe ich etwas Konfliktpotential. :-) So halte ich z.b TouchLCD fuer den groessten Unsinn seit der Erfindung des Fuchschwanzes an Autoantennen. Und auch deine Idee mit den Encodern mag ich nicht so weil sie keine direkte Rueckmeldung erlauben. Man muss zur Bedienung auf ein LCD schauen um zu wissen was man da macht. Ich wuerde eher moeglichst viele Tasten gut finden weil deren Position und Bedeutung nach kurzer Zeit auswendig weiss und man sie dann einfach druecken kann ohne zu schauen. > - Größe: Single DIN Halte ich fuer sehr vernuenftig. Zumal das ja eine Menge Platz ist wenn man keine Mechanik fuer Kasette oder CD unterbringen muss. > * evtl. DRM (?) Halte ich fuer Unsinn. Wird sich eh nicht Durchsetzen und der Empfangsteil fuer Kurzwelle/Mittelwelle wo ja gesendet wird, wuerde dir in der mit Stoerungen verseuchten Umgebung im Auto graue Haare bereiten. Und die implementierung der Decodierung ist ja auch nicht ohne. Also ein riesen Aufwand ohne grossen Nutzen. > * RDS, inkl. Follow me, Radio text (+), TA, EON > * Evtl. TIM (Aufzeichnung von Verkehrsnachrichten wenn das Radio > eigentlich aus ist und wiedergabe wenn das Auto das nächste mal > gestartet wird). Halte ich alles fuer Unsinn. Aber das schoene an solchen Projekten ist ja das jeder seine eigene Firmware haben kann. :-) Ich wuerde es aber fuer wichtig halten das ein Radio keinen Strom verbraucht wenn das Auto aus ist. Es gibt ja Leute die benutzen ein Auto auch mal laengere Zeit nicht. > * Der Empfang sollte wirklich sehr gut sein. Gutes Groß- und > Kleinsignalverhalten. Dir ist klar das dies dann ein hoellischer Aufwand wird wenn du den Tuner nicht zukaufen willst? Es hat ja Gruende warum auch gestandene Hersteller von Audio/Videokram Tuner lieber kaufen. > * 4 Kanal Verstärker (Evtl. Class-D) Halte ich nichts von. Gelegenheitshoerer brauchen nur eine Endstufe fuer zwei Lautsprecher. Wer Ansprueche stellt will sowieso mehr Leistung haben und schliesst dann immer eine externe Endstufe an. Was du aber unbedingt vermeiden musst sind so miess designte Rotzkisten die einen eigenen Luefter brauchen und wo schon beim Einbau klar ist das sie 2-3Jahre spaeter kaputt sind weil dann der Luefter tot ist und die ELektronik kurz darauf folgt. Man sollte also nicht viele Waermequellen haben. Oh..und Class-D wiederum passt nicht sorecht in deine Wunschliste mit einem moeglichst guten Tuner. > * Funktionen sollten leicht erreichbar sein (keine 3 fach > Shiftfunktionen auf Buttons, etc...) Da haette ich kein Problem mit. Es ist einfacher sich drei Belegungen zu merken, mein Taschenrechner hat IMHO sogar sechs Belegungen, als jedesmal zu gruebeln in welchem Untermenue irgendeine Funktion jetzt ist. * Die Reaktion auf Benutzerfunktionen sollten schnell erfolgen. Ist das keine Selbstverstaendlichkeit? Nein, im Zeitalter von Pfusch und Billig wohl nicht mehr, seufz. > Was haltet Ihr davon? Die Liste ist nur als Vorschlagliste zu > verstehen und natürlich nicht 100% fest. Du musst die Hardware modularisieren. Also im Prinzip eine Art kleines Mainboard mit der CPU. Darauf dann Slots wo man Zusatzkarten reinsteckt. Denkbare Karten waren dann: 1. Tunermodul. 2. Bluetoothmodul 3. Spezialmodule fuer Tasten am Lenkrad bestimmter Autos 4. Spezialmodul um die Fehlercodes meiner ECU auszulesen und anzuzeigen. usw.... Auch die Rueckseite sollte modular sein. Das haette den Vorteil das du relativ leicht etwas aendern koenntest ohne jedesmal gleich die gesamte Platine neu machen zu muessen. Oder glaubst du das dein PCB des Tuners beim ersten Versuch laufen wird? Ausserdem kann man so den Entwicklungsaufwand auf mehrere Leute aufteilen. Dann wollen wir mal nicht vergessen das so ein Project fett ist und lange dauern wird. Man muss moeglichst schnell zu einer Hardware kommen mit dem jeder erstmal was rumspielen kann. > Als CPU schwebt mir etwas in der Richtung Arm9E, evtl. auch etwas > Cortex-mäßiges vor (NXP hat hier unter den LPCs z.B. einige > Kandidaten). Ich will dich da nicht missionieren, aber ich hab mir gerade in Japan mal wieder eine Elektronikzeitung gekauft wo Renesas eine Platine mitliefert. Da ist eine SuperH-2A CPU drauf SH7262. Datenblatt ueber 2000Seiten. Speziell fuer Audiodevices gedacht, SPDIF integriert, I2S integrierst, I2C integriert, CAN, SD-Karte mit 1Bit und 4Bit integriert, 1MByte internes Ram in der CPU. AUsserdem Fliesskomma-DSP der sicher genug Power fuer MP3 hat ohne auch nur einen Muskel anzuspannen. :-) USB2.0 integriert, DMA, usw usw. Wirf mal einen Blick drauf. > Ich würde übrigens auch gerne wirklich alles Quelloffen machen, inkl. > der Hardware. Das ehrt dich natuerlich. Ich haette damit eigentlich auch kein Problem, auch wenn mich die ganzen Mitlaeufer die immer nur haben wollen ohne jemals selber etwas zu leisten, langsam nerven. Soll heissen Wunschlisten darf nur einreichen wer auch etwas zu dessen verwirklichung beitragen kann! Allerdings frage ich mich ob das etwas bringt. In so einem Design waeren sicherlich einige spezielle Bauteile drin. (CPU, TunerIC, LCD, Bedienungselemente, Mechanik, ISO-Steckverbinder) Die kann man sich nicht alle bei Maxim zusammenschnorren. Und die wird man auch nicht alle problemlos in Einzelstueckzahlen bekommen, jedenfalls nicht ueber einen laengeren Zeitraum. Jetzt aber zu meinem Hauptproblem. Wie willst du die Mechanik machen so das es auch nur halbwegs brauchbar aussieht. Du kannst schliesslich keine Plastikteile spritzen lassen. Und alles was du selber machen kannst sieht selbst bei groesster Muehe immer mehr oder weniger Hingebastelt aus. Als ich deshalb mein Autoradio angefangen habe, da habe ich mir ein altes Autoradio bei Ebay gekauft (SOny oberklasse Baujahr 1989) das meinen Wuenschen am naechsten kam und es entkernt. So haette ich Tasten und LCD, also die ganze Front weiterverwenden koennen. Der Kassettenschacht wird zugemacht und bietet die Moeglichkeit eine SD-Karte einzuschieben oder aehnliches, ist ja noch Platz. Dieser Ansatz sieht vernuenftig aus! Ist aber nur schwer zu realisieren wenn sich viele Leute ein Radio bauen wollen. Oder die Preise bei Ebay werden explodieren. Dann mal zu den Kosten. Ich glaube nicht das soetwas unter 500Euro an Kosten pro Radio machbar ist. Wieviele Leute sind jetzt noch dabei und nicht in Ohnmacht gefallen? :-) Es ist aus finanziellen Gruenden eigentlich Unsinn sowas zu machen, kaufen ist immer billiger. Die Sache ist nur die, ich habe eines der teuersten Autoradios die es gibt und aerger mich jeden Tag aufs neue ueber die hirntote Firmware. Daher kommt meine Motivation fuer die Sache. Oh..und du kannst und willst anderen sicher nicht die Arbeit abnehmen indem du ihnen Bausaetze verkaufst. Gerade in Autobastlerkreisen gibt es viele Leute deren Ambitionen groesser als ihre Faehigkeiten sind. Wenn da einer sein Auto abfackelt oder gegen seinen finalen Baum faehrt dann koennte es sonst Erklaerungbedarf geben. Zusammengefasst wuerde ich sagen, man ueberzeuge mich davon das die Optik des Radios hinterher stimmt und ich bin dabei. Ich moechte aber nicht das es in meinem Auto so aussieht wie auf meinem Etechnik-Schreibtisch oder wie etwas das man mit 15 in eine Zigarrenkiste eingebaut hat. Es bringt nichts hier ellenlang ueber Wunschtraeume zu debatieren die sich letztlich alle mit ein paar ICs und etwas Programmierung erfuellen lassen, wenn das Konzept der Mechanik nicht stimmt. Wie willst du z.b das Gehaeuse mit den Nasen zum reinschieben ins Auto realisieren? Im Prinzip waere es wohl am einfachsten wenn man ein neues Autoradio der Luxusklasse kauft, und die Firmware darin durch etwas eigenes ersetzt. Also so aehnlich wie Rockbox bei den MP3-Playern. > Wer schon mal im weiter entfernten Ausland mit den Auto unterwegs war > und sich nicht nur durch Musik berieseln lassen wollte wird erkannt > haben wie wichtig LW und MW heute noch sein kann. Ich bin oefter im entfernten Ausland unterwegs und habe keinerlei Bedarf an deutschen Radiosendern und schon garnicht auf Langwelle oder Mittelwelle. Pfui Deibel. Die paar Leute die es da noch gibt sind den Entwicklungsaufwand nicht wert. Gerade in dem Frequenzbereich hast du doch am ehesten Stoerungen. Selbst die arevierten Hersteller von Autoradios tun sich damit extrem schwer! Aber wer das wirklich will kann es sich ja selber nachruesten. Das ist einer der Gruende warum ich ein Steckkartenprinzip fuer wichtig halte. > Alles was ich so kenne mit Linux arbeitet auch nicht stabil. Das stimmt so allgemein nicht. Solche Projecte auf Linuxbasis sind nicht stabil weil dort Linux verwendet wird um sich Arbeit zu sparen. Die klauen sich also ueberrall rumliegende Source zusammen und modeln da in moeglichst kurzer Zeit was draus zusammen. Das ist einer der Gruende warum Linux nicht geeignet ist! Diejenigen die das hier propagieren, wollen sich damit Arbeit sparen und glauben sich so jeden Firlevanz in das Projekt holen zu koennen. Da kommt dann am Ende wackeliger Murks raus. Deshalb bin auch ich gegen Linux! > z.B. mein Chumby Du hast auch einen? Man muss nur die Flashscheisse komplett loeschen und alles mit Qt programmieren, dann macht das Dingen Spass. .-) > So ein Radio Chassis an sich ist > wiederum nur ein Stück gestanztes Blech das an einigen Stellen gebogen > ist. Irgendwo hatte ich vor ein paar Tagen eine Webseite gesehen mit > einer Firmwa die genau sowas (blech biegen/ausbrüche machen/...) > preisgünstig anbot. Mach das doch mal oder erkundige dich was sowas kostet. :-) Es waere dann sicher billiger im naechsten Geizladen ein Billigradio zu kaufen und das Blech von dort weiterzuverwenden. Wie ich schon sagte, so ein Projekt haengt zu 100% an der Mechanik, der Etechnikkram ist dagegen relativ einfach zu schaffen und vor allem zu finanzieren. > ja, also von der Optik und Bedienung her würde mir auch sowas > wie die Becker-Radios vorschweben. Und da kommen wir an die Stelle wo die Probleme anfangen. Ich finde das minimalistische Design von Becker und Blaupunkt einfach nur schlim und wuerde es niemals akzeptieren. Wobei ich natuerlich Verstaendnis dafuer habe das es da andere Meinungen gibt, aber wie will man das unter einen Hut bringen. Ich will Tasten. Je mehr desto besser! > Naja linux wär ned schlecht aber 300MHz und linux + noch ein paar > Spielereien ? Geht ned. Das ist eine Meinung die ich zu 100% Teile. Und auf meinen Rechner laeuft zu 99% der Zeit Linux seit 0.95a. .-) Jedes Betriebsystem wuerde zuviel Rechenzeit brauche und das Zeitverhalten komplizieren. Ich weiss man kann das mit viel Aufwand hinbekommen, aber das was einem Linux schenkt, einfacher Zugriff auf viele treiber ist unnoetig. Ich brauche auch gewiss kein WLAN im Auto. Sonst verlange ich als naechstes einen Newserver damit ich usenet unterwegs lesen kann. BTW: Wer sowas sucht soll sich einen Chumby aufs Armaturenbrett schrauben. Da ist schon alles drin. :-D Mir wuerde als System eher soetwas wie bei den alten Palmpiloten vorschweben. Jetzt nicht die Optik, aber ein Eventbasiertes System wo kein Programmteil dauerhaft Rechenzeit an sich ziehen darf. Einfach durchschaubar und schnell. > Mich nerven die ganzen Wunschlisten, wünsche hat jeder ! Dies Projekt > ist auch ned in ein bis zwei Monaten fertig ! Das habe ich auch so gedacht. Viele hier machen sich garnicht die Vorstellung was da fuer ein Aufwand drin steckt! Wenn ich z.B DAB lese! Nicht nur das diese Pferd bereits tod ist und anfaengt zu riechen. Diskret aufgebaute DAB-Tuner waren Zusatzgeraete fuer den Kofferraum und die Chipsaetze die es vielleicht dafuer gibt kann man garantiert nicht einfach so kaufen und mit Opensource wird es dann auch vorbei sein da ich nicht glaube das man da ohne NDA ran kommt. > 3. Obwohl es Opensource ist werden auch Geld und andere Ressourcen > benötigt. (gründung Verein oder so in die Richtung) Oh Gott, sobald sich mehr als drei Deutsche zusammenfinden muessen sie einen Verein gruenden, einen Kassenwart waehlen und auf die anderen herabsehen oder sie ausschliessen? Ich denke man kann sich entweder so zusammenraufen oder man laesst es. Olaf p.s: Mist, jetzt musste ich doch von meinen ewigen Grundsaetzen abweichen und mich hier anmelden weil ich sonst nicht posten darf. Seufz. ps2: Dieser Text wurde in einem externem Editor geschrieben und hier reinkopiert weil es in dieser Grafikusenetkopie keinen Emacsmode zu geben scheint. Ich hoffe es kommt daher alles vernuenftig rueber. .-)
Das Frontpanel könnte man evtl. per Rapid-Prototyping erstellen lassen. Ich denk dabei nicht an das Lasersinterverfahren, sondern an die thermoplastische Schichtung. Was die Kosten sind, weiß ich allerdings nicht. /Offtopic: @Olaf: Warum musst du dich anmelden? Wenn ich im Studentenwohnheim bin, kann ich auch nur angemeldet schreiben. Im Institut geht's unangemeldet...
Hallo zusammen! Auch ich bin von der Idee gnadenlos begeistert! Vielleicht sollten wir, um die Ideen zu sammeln, eine Wiki-Seite in Anspruch nehmen, das ist übersichtlicher als der Thread (den man ja für Diskussionen verwenden kann). VG
Florian Th. schrieb: > Auch ich bin von der Idee gnadenlos begeistert! Vielleicht sollten wir, > um die Ideen zu sammeln, eine Wiki-Seite in Anspruch nehmen, das ist > übersichtlicher als der Thread (den man ja für Diskussionen verwenden > kann). Ich denke auch. Ich werde ein Wiki / Mailingliste oder Forum auf die Beine zu stellen!
Olaf Kaluza schrieb: > Ich haette damit eigentlich auch kein > Problem, auch wenn mich die ganzen Mitlaeufer die immer nur haben > wollen ohne jemals selber etwas zu leisten, langsam nerven. > Soll heissen Wunschlisten darf nur einreichen wer auch etwas zu > dessen verwirklichung beitragen kann! open source ist opden source. Nutzen darf jeder, wünschen sowieso jeder, aber solange keiner was macht, passiert sowieso nichts. open source funktioniert nicht mit Wunschlisten. open source funktioniert nur dann, wenn sich da einer oder einige hinsetzen, und was machen, nicht wünschen. Und das speziellen (Noch-Nicht)-Projekt hier hat dazu das Problem, daß es noch zu schaffende Hardware benötigt, ohne die alle Softwareträume Träume bleiben. Oliver
Oliver schrieb: > open source ist opden source. Nutzen darf jeder, wünschen sowieso jeder, > aber solange keiner was macht, passiert sowieso nichts. > open source funktioniert nicht mit Wunschlisten. open source > funktioniert nur dann, wenn sich da einer oder einige hinsetzen, und was > machen, nicht wünschen. Und das speziellen (Noch-Nicht)-Projekt hier hat > dazu das Problem, daß es noch zu schaffende Hardware benötigt, ohne die > alle Softwareträume Träume bleiben. ja, allerdings muss man erstmal mit einer Basis anfangen und dementsprechend die Hardware designed. Wenn man vorher nicht wenigstens ein paar der Wünsche berücksichtigt dann fehlen von Anfang an viele Features und keiner hat noch wirklich interesse an der Sache.
Virus 744 schrieb: > Kai G. aus B. bei H. ???? > Falls ja, dann meld dich mal wieder. Ne, eher Kai G. aus N.-V. bei D :-)
Ich finde die Idee eines OS Radios cool. Meine Frage wäre aber: warum muss es eine Eierlegendewollmilchsau Lösung sein? Ich fände eine modulare Bauweise besser (also eine Trennung Empfangsteil -> Verstärker), da in den Einbauschächten bedingt durch die Nähe zur Heizung oft hohe Temperaturen herrschen und ein Verstärker ja nun mal Abwärme produziert... Zudem kann Derjenige, der eine Laufzeitanpassung der Boxen u.a. braucht, die in welcher Form auch immer bereitgestellte "NF" entsprechend aufbereiten und wer das nicht braucht ebend nicht. Der eine braucht Krach mit mindestens 8*1000W und extra "Bumsbox" ( ;-)), dem Anderen reichen 2*9 Watt auch. Es soll ja nicht so unüblich im Kfz-Bau sein, Vorne nur noch das Bedienteil zu haben... Zudem fände ich es praktisch, zusätzliche Funktionen anzudenken, wie z.B. einen Timer, der meine (Stand-)Heizung steuert. Ist bei Webasto ja nur ein High-Side Switch erforderlich und da an einem Radio ja immer 12v anliegen (Kl. 30) auch nicht schwer zu implementieren. LG Elux
Oliver Stellebaum schrieb: > Kai G. schrieb: > >> Gegenschall ist denk ich nicht nötig, aber man kann mit ein paar > > Du kennst mein Auto nicht ;-) > Vielleicht geht es ja den Gegenschall zu berechnen indem man einige > Kalibrierungsfahrten macht, bei 50, 100, 130km/h oder so. > Sicher, damit bekommt man nur gleichmäßige Motorgeräusche weg und > Fahrtwind, würde vielleicht schon was nützen. Was ich mich immer gefragt habe: Würde das funktionieren, wenn man ein 2tes Mikro irgendwo verbaut, das beim Sprechen nicht direkt beschallt wird und dessen Signal man vom Sprachmikro abzieht? Man könnte ja auch dem 2ten Mikro ein paar Filter spendieren, die die typischen Sprachfrequenzen durchlassen. Schon klar dass man die Phasenlage der Signal aneinander anpassen müsste. Aber würde das prinzipiell funktionieren? Ansonsten bin ich auch ein Verfechter von schlichtem Design. Lieber weniger, aber das durchdacht. Für mich wichtig: Freisprech über Bluetooth. Nach Möglichkeit sollte die auch mit 3 oder 4 Handys gleichzeitig klarkommen. (Meiner kann nur eines. Ist immer lustig, wenn die Holde mit im Auto ist. Welches Handy krallt sich die Freisprech) HiFi ist für mich nicht so die Priorität. Mein Auto muss nicht zum Konzertsaal werden. Touch-Panel: Bitte nicht.
> @Olaf: Warum musst du dich anmelden? Weil ich gerade Auslaender bin. Nur Inlaender duerfen als Gast schreiben. > Und das speziellen (Noch-Nicht)-Projekt hier hat > dazu das Problem, daß es noch zu schaffende Hardware benötigt, ohne die > alle Softwareträume Träume bleiben. Das ist natuerlich richtig. Was ich meinte das es nervt wenn Leute mit Forderungen kommen die sich nicht vorstellen koennen was fuer ein Aufwand in der Realisierung steckt. Nimm z.B mal den Empfang von Lang und Mittelwelle. Jeder hier der schonmal ein Radio fuer diese Frequenzen in die naehe seines ersten Mega8 gehalten hat wird wissen das dies nicht so einfach ist. Ich meine ein Hobbyproject ist was anderes als die Entwicklungsabteilung von Blaupunkt. Letzere hat naemlich den Vorteil bei jedem neuen Radio 100Mannjahre Erfahrung und 50% der Schaltungstechnik vom letzten Project verwenden zu koennen. Aber wie schon gesagt, deshalb halte ich es fuer sehr wichtig so ein Project zu modularisieren. Man muss erstmal ein Mainboard habe wo im Prinzip nur Display, Tastatur, zwei SD-Slots (intern, extern) und ein Audioausgang dran ist. Das hat zum einen den Vorteil das einige Leute schonmal programmieren koennen, waerend andere an der Hardware basteln. Und vor allem hat es den Vorteil das die schwierigste Arbeit, naemlich Design und Mechanik da bereits weitestgehend erledigt sind. Jede Aenderung an letzerem ist naemlich teuer. > Ich fände eine modulare Bauweise besser (also eine Trennung Empfangsteil > -> Verstärker), da in den Einbauschächten bedingt durch die Nähe zur > Heizung oft hohe Temperaturen herrschen und ein Verstärker ja nun mal > Abwärme produziert... Das ist absolut richtig. Es braucht nur einen kleinen Verstaerker im Radio selber. Sagen wir mal die ueblichen 2x12W. Es gibt viele Leute denen reicht soetwas. Diejenigen die mehr wollen werden immer einen externen Verstaerker verwenden. Ich habe z.b immer die 2x12W fuer die Frontspeaker verwendet und dann meist 2x50 oder 2x100 fuer die hinteren Lautsprecher. BTW:Ein Subwoofer ist immer ein Zeichen von schlechtem Design. .-) > Zudem kann Derjenige, der eine Laufzeitanpassung der Boxen u.a. braucht, > die in welcher Form auch immer bereitgestellte "NF" entsprechend > aufbereiten und wer das nicht braucht ebend nicht. Ich halte soche Laufzeiten zwar auch fuer Unsinn, allerdings nicht weil sie sich nicht auswirken, sondern weil normale Menschen auch mal Beifahrer im Auto haben. Technisch ist sowas aber nur ein entsprechend grosser Pufferspeicher. Also programmiertechnisch ein Witz. > Zudem fände ich es praktisch, zusätzliche Funktionen anzudenken, wie > z.B. einen Timer, der meine (Stand-)Heizung steuert. Sowas halte ich in der Tat fuer eine gute Idee. Genauso wie mein Wunsch meine ECU auslesen zu koennen. Aber das sind dann wohl Sachen die jeder fuer sich privat auf die Beine stellen muss. Olaf
> Und grundsatzlich ist es ja auch mal eine nette Idee ein groesseres > Project mit ein paar Leute durchzuziehen. Allerdings sehe ich etwas > Konfliktpotential. :-) Klar, das hat man in jedem Projekt, oder? :-) > So halte ich z.b TouchLCD fuer den groessten Unsinn seit der > Erfindung des Fuchschwanzes an Autoantennen. Und auch deine Idee > mit den Encodern mag ich nicht so weil sie keine direkte Rueckmeldung > erlauben. > Man muss zur Bedienung auf ein LCD schauen um zu wissen > was man da macht. Ich bin auch ein großer Unterstützer der einfachen Bedienung (und zur not mehr tasten unterzubringen), aber das stimmt denk ich nicht ganz: Lautstärke = Rückmeldung (Lauter/leiser) Sender wechseln = Audio Rückmeldung (anderer Content) auf MP3 Umschaltung = Audio Rückmeldung (Mp3 wird abgespielt) MP3 Track ändern = Rückmeldung (anderes MP3 wird abgespielt) ... Nicht so viel anders als bei Tasten. Natürlich etwas Verstand bei der Umsetzung vorrausgesetzt. Und um so Sachen wie Bass zu ändern oder so muss man auch bei Tasten auf das Display schauen, weil man sowas bestimmt nicht vom Top level aus änderbar macht weil man es nicht oft braucht. >> * RDS, inkl. Follow me, Radio text (+), TA, EON Hier hab ich noch RDS-ClockTime als Feature vergessen... >> * Evtl. TIM (Aufzeichnung von Verkehrsnachrichten wenn das Radio >> eigentlich aus ist und wiedergabe wenn das Auto das nächste mal >> gestartet wird). > Halte ich alles fuer Unsinn. Aber das schoene an solchen Projekten ist > ja das jeder seine eigene Firmware haben kann. :-) RDS unsinn? Staumeldungen sind doch nicht gerade uninteressant... TIM kann man mit einem Stromverbrauch <2 mA umsetzen. Ich finde sowas sollte man wenigstens im Powerkonzept mit Berücksichtigen zumal man evtl. auch noch etwas anderes im Hintergrund wenn das Radio aus ist machen können will und sei es nur die Uhr am Laufen zu lassen > Ich wuerde es aber fuer wichtig halten das ein Radio keinen Strom > verbraucht wenn das Auto aus ist. Es gibt ja Leute die benutzen ein > Auto auch mal laengere Zeit nicht. Ja, allerdings kann man den Stromverbrauch wirklich SEHR gering halten. >> * Der Empfang sollte wirklich sehr gut sein. Gutes Groß- und >> Kleinsignalverhalten. > Dir ist klar das dies dann ein hoellischer Aufwand wird wenn du > den Tuner nicht zukaufen willst? Es hat ja Gruende warum auch > gestandene Hersteller von Audio/Videokram Tuner lieber kaufen. Ich hatte beruflich damit zu tun (hab bei einem Tuner IC Semi gearbeitet) und das ist echt kein Hexenwerk. >> * 4 Kanal Verstärker (Evtl. Class-D) > Halte ich nichts von. Gelegenheitshoerer brauchen nur eine Endstufe > fuer zwei Lautsprecher. Die meisten Autos haben 4 Lautsprecher, die möchte ich auch gerne hören können. Zumal es fertige schöne Integrierte Verstärker mit 4 Kanälen gibt, teils sogar direkt mit integrierten Spannungsreglern. > Wer Ansprueche stellt will sowieso mehr > Leistung haben und schliesst dann immer eine externe Endstufe an. > Was du aber unbedingt vermeiden musst sind so miess designte > Rotzkisten die einen eigenen Luefter brauchen und wo schon beim Einbau > klar ist das sie 2-3Jahre spaeter kaputt sind weil dann der Luefter > tot ist und die ELektronik kurz darauf folgt. Man sollte also > nicht viele Waermequellen haben. Ein Lüfter gilt es auf jeden fall zu vermeiden. Wenn es im Auto knallheiß ist, nützt der eh nicht mehr.. > Oh..und Class-D wiederum passt nicht sorecht in deine Wunschliste > mit einem moeglichst guten Tuner. Ist möglich, schon getan, selbst mit guter Empfindlichkeit in den ganzen AM Bändern. Man kann z.b. die Class-D Verstärker abhängig von der getunten Frequenz takten (uC PWM Ausgang). >> * Funktionen sollten leicht erreichbar sein (keine 3 fach >> Shiftfunktionen auf Buttons, etc...) > > Da haette ich kein Problem mit. Es ist einfacher sich drei Belegungen > zu merken, mein Taschenrechner hat IMHO sogar sechs Belegungen, als > jedesmal zu gruebeln in welchem Untermenue irgendeine Funktion jetzt > ist. Du hast doch selbst geschrieben Du willst viele Tasten. > * Die Reaktion auf Benutzerfunktionen sollten schnell erfolgen. > Ist das keine Selbstverstaendlichkeit? Nein, im Zeitalter von > Pfusch und Billig wohl nicht mehr, seufz. Ja, leider. Sowas ist heutzutage absolut nicht (mehr) selbstverständlich. Wenn es z.B. 2 Sekunden (übertrieben) dauert die Wiedergabe von einem MP3 zu starten möchte ich noch immer die Möglichkeit haben auch während dieser 2 Sekunden durch die MP3 Trackliste zu scrollen um mich umzuentscheiden... > Du musst die Hardware modularisieren. Also im Prinzip eine Art kleines > Mainboard mit der CPU. Darauf dann Slots wo man Zusatzkarten > reinsteckt. Ich wäre für ein Basissystem aus: - Tuner - uC - Stromversorgung / Verstärker - Bluetooth slot - mind 1 universeller Erweiterungsslot mit Stromversorgung, interner I2C Bus, I2S, Audio in/out (durchschleifbar), ... > Das haette den Vorteil das du relativ leicht etwas aendern > koenntest ohne jedesmal gleich die gesamte Platine neu machen > zu muessen. Oder glaubst du das dein PCB des Tuners beim ersten > Versuch laufen wird? Ja, das denke ich schon, zumindest in großen Teilen. Optimierungen kann man immer noch vornehmen. Ich hab auch noch kein System gesehen das auf Anhieb 100% lief und man nicht noch irgendwelches HW-patches auf der Platine machen musste. > Ausserdem kann man so den Entwicklungsaufwand > auf mehrere Leute aufteilen. Deswegen mein Aufruf :-) > Dann wollen wir mal nicht vergessen das so ein Project fett ist und > lange dauern wird. Man muss moeglichst schnell zu einer Hardware kommen > mit dem jeder erstmal was rumspielen kann. Genau. 1.) Mechanik klären (Bedienkonzepte, Wie wird es gefertigt...) 2.) Hardware fertig machen, evtl. parallel schon Softwareentwicklung mit testboards o.ä. starten 3.) Software programmieren ... > Ich will dich da nicht missionieren, aber ich hab mir gerade in Japan > mal wieder eine Elektronikzeitung gekauft wo Renesas eine Platine > mitliefert. Da ist eine SuperH-2A CPU drauf SH7262. > Datenblatt ueber 2000Seiten. Speziell fuer Audiodevices gedacht, > SPDIF integriert, I2S integrierst, I2C integriert, CAN, SD-Karte > mit 1Bit und 4Bit integriert, 1MByte internes Ram in der CPU. > AUsserdem Fliesskomma-DSP der sicher genug Power fuer MP3 hat > ohne auch nur einen Muskel anzuspannen. :-) > USB2.0 integriert, DMA, usw usw. Wirf mal einen Blick drauf. Werd ich machen, klingt interessant. Gibt es auch bezugsquellen und nicht-BGA Gehäuse? > Dann mal zu den Kosten. Ich glaube nicht das soetwas unter 500Euro > an Kosten pro Radio machbar ist. Wieviele Leute sind jetzt noch > dabei und nicht in Ohnmacht gefallen? :-) Ich :-) Wäre auch durchaus bereit mehr auszugeben, ist schließlich Hobby... > Ich bin oefter im entfernten Ausland unterwegs und habe keinerlei > Bedarf an deutschen Radiosendern und schon garnicht auf Langwelle > oder Mittelwelle. Pfui Deibel. Die paar Leute die es da noch gibt > sind den Entwicklungsaufwand nicht wert. Gerade in dem Frequenzbereich > hast du doch am ehesten Stoerungen. Selbst die arevierten Hersteller > von Autoradios tun sich damit extrem schwer! > Aber wer das wirklich will kann es sich ja selber nachruesten. > Das ist einer der Gruende warum ich ein Steckkartenprinzip fuer > wichtig halte. Reine FM Tuner sind eh kaum zu finden, dann kann man von mir aus auch noch AM integrieren, OK? :-) Ich hab nur festgestellt das die Antennen, oder deren Verstärker in den Autos heutzutage oft Taub für AM sind. >> Alles was ich so kenne mit Linux arbeitet auch nicht stabil. > Das stimmt so allgemein nicht. Solche Projecte auf Linuxbasis sind > nicht stabil weil dort Linux verwendet wird um sich Arbeit zu sparen. Ich sag ja nicht, das es nicht stabil geht, die Praxis hat mich nur eines anderen belehrt, wie Du es auch schreibst... >> z.B. mein Chumby > Du hast auch einen? Man muss nur die Flashscheisse komplett loeschen > und alles mit Qt programmieren, dann macht das Dingen Spass. .-) Ich wollte einfach nur ein cooles shoutcast Küchenradio haben und nicht noch selber die Software entwickeln :-)
Ich würde auf jeden Fall ein CAN vorsehen, in den ganzen neueren Autos kommen viele benötigte Signale über CAN und nicht mehr diskret. KL S, KL 15, Licht, Geschwindigkeit usw.
Olaf Kaluza schrieb: >> Alles was ich so kenne mit Linux arbeitet auch nicht stabil. > > Das stimmt so allgemein nicht. Solche Projecte auf Linuxbasis sind > nicht stabil weil dort Linux verwendet wird um sich Arbeit zu sparen. > Die klauen sich also ueberrall rumliegende Source zusammen und modeln > da in moeglichst kurzer Zeit was draus zusammen. Das ist einer der > Gruende warum Linux nicht geeignet ist! Diejenigen die das hier > propagieren, wollen sich damit Arbeit sparen und glauben sich so jeden > Firlevanz in das Projekt holen zu koennen. Da kommt dann am Ende > wackeliger Murks raus. Deshalb bin auch ich gegen Linux! > Das passiert bei selbstgestrickter Software ebenfalls, und ist nicht Linux anzulasten, sondern der Sorgfalt bzw. den Fähigkeiten des Anwendungsentwicklers. >> z.B. mein Chumby > > Du hast auch einen? Man muss nur die Flashscheisse komplett loeschen > und alles mit Qt programmieren, dann macht das Dingen Spass. .-) > was hat QT und/oder Flash mit Linux zu tun???? > >> Naja linux wär ned schlecht aber 300MHz und linux + noch ein paar >> Spielereien ? Geht ned. absoluter Blödsinn! Es geht mit deutlich weniger, wenn der Kernel vernünftig auf das absolut notwendige abgespeckt wurde. > > Das ist eine Meinung die ich zu 100% Teile. Und auf meinen Rechner > laeuft zu 99% der Zeit Linux seit 0.95a. .-) > > Jedes Betriebsystem wuerde zuviel Rechenzeit brauche und das > Zeitverhalten komplizieren. Ich weiss man kann das mit viel Aufwand > hinbekommen, aber das was einem Linux schenkt, einfacher Zugriff auf > viele treiber ist unnoetig. Ich brauche auch gewiss kein WLAN im > Auto. Sonst verlange ich als naechstes einen Newserver damit ich > usenet unterwegs lesen kann. > > BTW: Wer sowas sucht soll sich einen Chumby aufs Armaturenbrett > schrauben. Da ist schon alles drin. :-D > So einen Blödsinn liest man sonst nur im Heise-Forum! Warum kaufst du dir nicht ein normales Autoradio, wenn du all die angedachten Inovationen nicht brauchst??? Mir scheint es, als ob du gar nicht wüsstest, was ein Embedded-Linux von einem Desktop-Linux unterscheidet. Ach ja...ich verwende Linux auch seit dem 0.95pl-irgendwas-Kernel. Harry
Wenn MP3 dekodierung + Grafikdisplay und noch so ein paar kleinigkeiten. Da wird dann doch so ein ARM Cortex M3 zu lahm weil dieser schon mit dem MP3 dekodieren und Speicherverhaltung beschäftigt ist (soll ja alles flüssig laufen). Für so sachen wie Geräuschkompensation für die Bluetooth Freisprechanlage is dann der M3 zu lahm. Bei solchen Sachen kommt dann auch schon ARM926 an seine Grenzen. Daher das mit den 300Mhz ggg
> RDS unsinn? Staumeldungen sind doch nicht gerade uninteressant... Soll ich dir was verraten. Ich hab bis vor einem Jahr mit einem Sony Autoradio gehoert das ich mir so um 1985 gekauft habe. (damals 999DM) Erst vor kurzem habe ich modernisiert weil das alte Sony doch etwas in die Jahre kam und ich gerne eine Bluetoothverbindung mit meinem Handy wollte. Und seitdem muss ich mich immer ueber den modernen Kram aufregen, seufz. Daher brauch ich kein RDS. Ich kenn die Frequenzen der Radiosender auswendig und das reicht mir. Und Staumeldungen interessieren mich auch nicht. Nicht das ich sowas fuer mich ein Ausschlusskriterium waere, aber ich messe dem halt selber keinen Wert zu. > machen können will und sei es nur die Uhr am Laufen zu lassen Die muss dann aber abschaltbar sein da ich es auch nervig finde wenn man eine Uhr im Auto hat (normalfall) und dann noch eine im Radio. Und dann noch eine am Arm und dann noch eine im Handy. Und dann kommt der Supergau (Sommerzeit) > Wenn es z.B. 2 Sekunden (übertrieben) dauert die Wiedergabe von einem > MP3 zu starten möchte ich noch immer die Möglichkeit haben auch während > dieser 2 Sekunden durch die MP3 Trackliste zu scrollen um mich > umzuentscheiden... Nein, argh! Er hat es gesagt. Mein Blutdruck..oh Gott.... Mein aktuelles Luxusradio braucht jedesmal echte 20-30s, also gefuehlte 1000Jahre wenn man auf DVD schaltet, und zwar JEDESMAL nicht nur wenn man die DVD wechselt. Und es gibt nur eine Taste um zwischen Radio, DVD, USB-Stick, Handy, HandyAudio und Aux umszuschalten. Also jedesmal einmal die ganze Reihe durch. Wenn eines Tages mal die Entwicklungsabteilung von JVC brennt dann bin ich der Hauptverdaechtige.... > Ich wäre für ein Basissystem aus: > - Tuner > - uC > - Stromversorgung / Verstärker > - Bluetooth slot > - mind 1 universeller Erweiterungsslot mit Stromversorgung, interner I2C > Bus, I2S, Audio in/out (durchschleifbar), ... Ich wuerde den Tuner auch auslagern wollen, aber wenn du sagst du bekommst das so hin ohne allzu viele Muster zu verhauhen. <BG> Ist vermutlich fuer die Anbindung der Antenne besser wenn es nicht ueber einen Stecker laeuft. Anonsten denke ich das man mehre Slots fuer Erweiterungen haben sollte. Wenigstens drei. Zumindest einer, besser alle sollten auch eine Verbindung zum Anschluss an der Rueckwand haben. > Werd ich machen, klingt interessant. Gibt es auch bezugsquellen und > nicht-BGA Gehäuse? http://shop.cqpub.co.jp/hanbai/books/MIF/MIF201006l.jpg Hmm..ich hab obige Zeitschrift gekauft. Da ist die Platine mit dabei. Das Dingen ist in einem 176Beinigen Standardgehaeuse. Leider ist meine nicht angetraute Uebersetzerin etwas zickig wenn es an die Uebersetzung von Texten geht die sie nicht versteht. :-D Aber soweit ich das bis jetzt verstanden habe hat das Teil fuer die meisten Leute hier einen dicken Nachteil so toll es sonst auch sein mag. Zum brennen benoetigt man normalerweise einen Renesas E10 Debugger. Weil den auch in Japan nicht jeder Bastler hat, haben die sich von der Zeitung etwas einfallen lassen. Auf dem Board ist ein Programm drauf das sich mit dem PC und der Entwicklungsumgebung von Renesas ueber USB unterhaelt. Der Prozessor selber enthaelt uebrigends kein Flashrom! Er liesst beim einschalten sein Programm aus einem externen seriellen 8Beiner in sein 1MByte Ram ein und startet es dann. Ich vermute mal das Flashrom zu langsam ist um bei der Geschwindigkeit noch mithalten zu koennen. Das laeuft also im Prinzip so wie bei einem FPGA Jedenfalls ist das ganze relativ aufwendig in Betrieb zu nehmen. Im Prinzip koennte man nur die japanische Loesung kopieren wenn man den Debugger verwenden will und darauf wuerde ich nur ungern verzichten. Ich weiss jetzt nicht wie die Programmiergeraete fuer die hier sonst vorgeschlagenen CPUs aussehen. Fuer Nichtprogrammierer ist das ja kein Problem, da ich denke mit das erste das man programmieren muesste ist ein Firmwareloader der ein Update ueber USB hinbekommt damit man sein System auch im Auto updaten kann ohne dort jedesmal mit dem Laptop rumhampeln zu muessen. > Ich hab nur festgestellt das die Antennen, oder deren Verstärker in den > Autos heutzutage oft Taub für AM sind. Das meinte ich. Und ich glaube das war auch noch nie wirklich gut. Andererseits ist B.Kainka ja ein Freund von mir und der freut sich immer wenn er ein AM-Radio bauen darf. Ich muss ihm nur klarmachen das er diesmal keine Roehre verwenden darf! :-D > Ich wollte einfach nur ein cooles shoutcast Küchenradio haben und nicht > noch selber die Software entwickeln :-) Das ist doch total verschwendet. Das Dingen soll mein neuer Laborrechner werden. I2C-Zugriff geht mit Testprogramm schon. Fehlt nur noch die GPIB Anbindung und ich kann mein Oszi ueber WLAN Fernbedienen. Olaf
seennoob schrieb: > Wenn MP3 dekodierung + Grafikdisplay und noch so ein paar kleinigkeiten. > Da wird dann doch so ein ARM Cortex M3 zu lahm weil dieser schon mit dem > MP3 dekodieren und Speicherverhaltung beschäftigt ist (soll ja alles > flüssig laufen). > Für so sachen wie Geräuschkompensation für die Bluetooth > Freisprechanlage is dann der M3 zu lahm. Bei solchen Sachen kommt dann > auch schon ARM926 an seine Grenzen. Daher das mit den 300Mhz *ggg* Warum sollte das denn alles die Haupt-CPU machen? MP3-Decoder gibt es als 1-Chip Lösung....Bluetooth-Freisprechen wird es sicherlich auch als fertigen Chip oder Modul geben. Ein Grafik-Display in einem DIN-Schacht kann auch nicht so riesig werden, daß eine aktuelle CPU da ins straucheln käme, und 3D brauch ich nicht wirklich. Harry
Eine Sache noch für die Wishlist: DCF77-Empfänger mit automatischer Umstellung Sommer-/Winterzeit Dass sowas bei einem Auto BJ 2009 nich Standard ist, ist mir ein Rätsel... VG
> Soll ich dir was verraten. Ich hab bis vor einem Jahr mit einem Sony > Autoradio gehoert das ich mir so um 1985 gekauft habe. (damals 999DM) Wow, in der Zeit wurden mir 2 Radios geklaut :-) > Daher brauch ich kein RDS. Ich kenn die Frequenzen der Radiosender > auswendig und das reicht mir. Und Staumeldungen interessieren mich auch > nicht. Nicht das ich sowas fuer mich ein Ausschlusskriterium waere, > aber ich messe dem halt selber keinen Wert zu. Es gibt einige Gegenden in Deutschland das willst Du ohne RDS-Follow me nicht freiwillig Radio hören. Wenn man dann noch über dual tuner Konzepte mit RDS basiertem frequency diversity nachdenkt dann kann man (mit etwas fleissarbeit) echt gute Empfangsqualitätsverbesserungen (tm) erreichen. > Die muss dann aber abschaltbar sein da ich es auch nervig finde wenn man > eine Uhr im Auto hat (normalfall) und dann noch eine im Radio. Und dann > noch eine am Arm und dann noch eine im Handy. Und dann kommt der > Supergau (Sommerzeit) Die im Radio würde zumindest automatisch upgedatet werden (RDS). > Nein, argh! Er hat es gesagt. Mein Blutdruck..oh Gott.... Sorry, es tut mir Leid ;-) Wenn ich sowas lese dann frag ich mich immer wie es möglich ist das Entwickler so wenig Enthusiasmus und Energie in Ihre Produkte setzen, wenigstens wenn es um Consumer Produkte geht. > Ich wuerde den Tuner auch auslagern wollen, aber wenn du sagst du > bekommst das so hin ohne allzu viele Muster zu verhauhen. <BG> Ist > vermutlich fuer die Anbindung der Antenne besser wenn es nicht ueber > einen Stecker laeuft. Habe vertrauen, das klappt schon :-) > Anonsten denke ich das man mehre Slots fuer Erweiterungen haben sollte. > Wenigstens drei. Zumindest einer, besser alle sollten auch eine > Verbindung zum Anschluss an der Rueckwand haben. Ja, evtl. ähnlich den PCI slots. > Der Prozessor selber enthaelt uebrigends kein Flashrom! Er liesst beim > einschalten sein Programm aus einem externen seriellen 8Beiner in > sein 1MByte Ram ein und startet es dann. Ich vermute mal das Flashrom zu > langsam ist um bei der Geschwindigkeit noch mithalten zu koennen. Das > laeuft also im Prinzip so wie bei einem FPGA Ja, das ist man sonst auch von vielen DSPs gewohnt. > Ich weiss jetzt nicht wie die Programmiergeraete fuer die hier sonst > vorgeschlagenen CPUs aussehen. Für denjenigen der erstmal die Harte Arbeit macht ein Grundgerüst an Software ans laufen zu kriegen reicht ein FTDI basierter Jtag debugger (z.B. Olimex OCD), ansonsten bringen z.B. die NXP LPCs fast alle einen UART basierten Bootloader mit der prima klappt und selbst für die meisten Softwareentwickler reicht (einen guten Debugoutput vorrausgesetzt). > Fuer Nichtprogrammierer ist das ja kein Problem, da ich denke mit das > erste das man programmieren muesste ist ein Firmwareloader der ein > Update ueber USB hinbekommt damit man sein System auch im Auto updaten > kann ohne dort jedesmal mit dem Laptop rumhampeln zu muessen. ACK! > Das ist doch total verschwendet. Das Dingen soll mein neuer Laborrechner > werden. I2C-Zugriff geht mit Testprogramm schon. Fehlt nur noch die GPIB > Anbindung und ich kann mein Oszi ueber WLAN Fernbedienen. Naja, warum nicht einfach ein GPIB interface mit USB Schnittstelle basteln/kaufen und die energie in ein cooles Autoradio stecken? :-)
Florian Th. schrieb: > DCF77-Empfänger mit automatischer Umstellung Sommer-/Winterzeit > Dass sowas bei einem Auto BJ 2009 nich Standard ist, ist mir ein > Rätsel... Über RDS wird die Uhrzeit, Datum und Zeitzone des Senders ausgesendet (ClockTime), zumindest bei den überregionalen sendern. Man braucht für eine aktuelle Uhrzeit also keine extra Hardware. Die Umstellung auf Sommer/Winterzeit geht darüber auch automatisch.
Kai G. schrieb: > Über RDS wird die Uhrzeit, Datum und Zeitzone des Senders ausgesendet > (ClockTime), zumindest bei den überregionalen sendern. Dann hab ich nix gesagt ;-)
Ich bin ein absoluter feind von diesen "Ein Chip MP3 dekoder" weil sie schluss und endlich zum Flaschenhals werden. Es soll ja eine Basisplatform werden welche ein guter Anlaufpunkt für einen eigenen Radio ist! Also lieber eine eigene DSP für das Audiozeugs, dann kann man sie auch auf andere Formate erweitern. Warum redet jeder immer von einer fertigen Lösung ? Das Gehäuse ist ja nur ein "Nebenprodukt". Zuerst geht es mal darum eine HW zu entwickeln das Gehäuse ist Schluss und endlich jedem selbst überlassen. Ein DIN Referenzdesign ist ned schlecht aber man muss sich ja ned darauf versteifen.
seennoob schrieb: > Ich bin ein absoluter feind von diesen "Ein Chip MP3 dekoder" weil sie > schluss und endlich zum Flaschenhals werden. Es soll ja eine > Basisplatform werden welche ein guter Anlaufpunkt für einen eigenen > Radio ist! > Also lieber eine eigene DSP für das Audiozeugs, dann kann man sie auch > auf andere Formate erweitern. ACK! ...aber bitte nicht die Haupt-CPU mit Aufgaben zumüllen, für die sie eigentlich nicht gemacht ist. > Warum redet jeder immer von einer fertigen Lösung ? Das Gehäuse ist ja > nur ein "Nebenprodukt". Zuerst geht es mal darum eine HW zu entwickeln > das Gehäuse ist Schluss und endlich jedem selbst überlassen. Ein DIN > Referenzdesign ist ned schlecht aber man muss sich ja ned darauf > versteifen. weil hier viele "Träumer" sind, die ein cooles Radio haben wollen, aber von den eigentlichen Problemen bei der Entwicklung keinen Schimmer haben. Harry
Harald L. schrieb: >> Ich bin ein absoluter feind von diesen "Ein Chip MP3 dekoder" weil sie >> schluss und endlich zum Flaschenhals werden. Es soll ja eine >> Basisplatform werden welche ein guter Anlaufpunkt für einen eigenen >> Radio ist! >> Also lieber eine eigene DSP für das Audiozeugs, dann kann man sie auch >> auf andere Formate erweitern. > ACK! Auch ACK. Das entkoppelt auch schön die Softwareentwicklung. Irgendwelche Vorschläge was für ein DSP/Controller? Schön fänd ich - Firmware upload über Hauptcontroller möglich (Damit man immer nur 1 Firmware image hat und keine komischen Versionskonflikte bekommt) - Kein externer Ram/Flash - Kein BGA Ich hätte erstmal nen Arm genommen, aber so richtig das wahre ist das nicht wenn man vorhat wirklich nur reines Signalprocessing zu machen. Aber bevor man irgendeinen exotischen DSP nimmt...
Das ist das Anfägerproblem! Man sieht das etwas voran geht aber man ist sich nicht bewusst das man in der Kindergartenliga arbeitet. Viele denken sich hmm Display haben ich schon angesteuert ist ned viel dabei und MP3 codecs gibts fertig also doch kein so großes Problem so ein MP3 Player! Wenn man aber erst mal das ganze wo neuimplementiert, wirds anstrnegend. Also sowas wie OMAP da kann man sich auch mit den Entwicklern vom Beagleboard zusammensetzen. Dann hat man schon mal ein gutes Hardware Grundgerüst und dann gehts weiter.... MFG Patrick
seennoob schrieb: > Das ist das Anfägerproblem! Man sieht das etwas voran geht aber man ist > sich nicht bewusst das man in der Kindergartenliga arbeitet. Viele > denken sich hmm Display haben ich schon angesteuert ist ned viel dabei > und MP3 codecs gibts fertig also doch kein so großes Problem so ein MP3 > Player! Hey, Kindergartenliga hab ich mal überhört ;-) Ich hab fast all das hier schon mal realisiert (auch from scratch) und bin mir durchaus der Komplexität bewusst.
> Das Gehäuse ist ja nur ein "Nebenprodukt". Das ist es leider nicht. Oder sagen wir mal so, das ist es bei vielen Bastlern schon und genau so sehen dann aber die Kisten aus! > Zuerst geht es mal darum eine HW zu entwickeln > das Gehäuse ist Schluss und endlich jedem selbst überlassen. Ein DIN > Referenzdesign ist ned schlecht aber man muss sich ja ned darauf > versteifen. Das ist natuerlich auch eine Loesung. Haette ich auch kein Problem mit. Wuerde aber wohl wieder einige Leute abschrecken. Schliesslich muesste dann ja jeder die endgueltige Platine passend zu seinem Gehaeuse anpassen. Mir ist gerade noch was zum Bedieninterface eingefallen das ich mal zur Diskussion stellen wollte. Man nimmt ein Encoder mit integrierter Taste auf der einen Seite um sich damit durch die Menues zu arbeiten, auf der anderen Seite kommt ein Motorpoti. So kann man dann z.b Lautstaerke ganz normal mit dem Poti einstellen und sie vor allem absolut-winkelabhaengig veraendern. Und wenn man jetzt im Menue auf Bass oder Fader schaltet dann dreht das Radio den Knopf schnell auf die aktuelle Ist-Position bevor man einen neuen Sollwert durch drehen einstellt. BTW: Wie gross, von den Massen her muesste das LCD eigentlich sein. Mein aktuelles Radio hat ein LCD fast so gross wie die Front weil es darauf auch Video darstellen kann. Da aber niemand im Auto Videos kucken will und hier auch noch keiner darueber gesprochen hat, gehe ich mal davon aus das dies nicht gewuenscht ist. Dann sollte doch eigentlich auch ein kleineres LCD reichen. So haette man vielleicht unter dem LCD Platz fuer eine Reihe von Knoepfen zur Direktanwahl von Senderspeichern und aehnlichem. > weil hier viele "Träumer" sind, die ein cooles Radio haben wollen, aber > von den eigentlichen Problemen bei der Entwicklung keinen Schimmer > haben. Meine Berufserfahrung als Hardwareentwickler sagt mir aber das da die Probleme liegen. Du kannst niemanden anrufen und sagen das du 10000Stk Bleche gelasert und gebogen haben willst. Wenn du sagst du brauchst nur 10Stk dann lacht der dich aus. Und alles was bei einen normalen Autoradio aus Spritzguss besteht kannst du auch vergessen. Du kannst vielleicht noch eine Aluplatte fraesen lassen, bekommst sie irgendwo eloxiert und kannst sie eventuell noch mir siebdruck beschriften lassen. Aber auch das sieht dann mehr nach einem Labornetzteil von Conrad als nach einem Autoradio aus. Es waer doch irgendwie doof wenn man sich erst die ganze Arbeit macht, dann ein Referenzdesign im Form einer Europlatine auf dem Tisch liegen hat und dann darauf stoesst das man es nirgendwo einbauen kann das einen WAF groesser 0.1 hat. Olaf
@darkover Wenn mal alles läuft kann man noch immer an einem Gehäuse arbeiten, außerdem wer will etwas kaufen was schön ist aber noch ned funktionsfähig ? MFG
> Man nimmt ein Encoder mit integrierter Taste auf der einen Seite um sich > damit durch die Menues zu arbeiten, auf der anderen Seite kommt ein > Motorpoti. So kann man dann z.b Lautstaerke ganz normal mit dem Poti > einstellen und sie vor allem absolut-winkelabhaengig veraendern. Und > wenn man jetzt im Menue auf Bass oder Fader schaltet dann dreht das > Radio den Knopf schnell auf die aktuelle Ist-Position bevor man einen > neuen Sollwert durch drehen einstellt. Eigentlich nicht schlecht. Man raubt sich nur die möglichkeit den linken Knopf für etwas komplett anderes benutzen zu können (Menüscrollen). Aber die Frage ist natürlich ob man das überhaupt wollte. Ein gutes Bedienkonzept zu haben ist wohl mit eines der wichtigsten Dinge, weil davon viele andere entscheidungen abhängen. > BTW: Wie gross, von den Massen her muesste das LCD eigentlich sein. Mein > aktuelles Radio hat ein LCD fast so gross wie die Front weil es darauf > auch Video darstellen kann. Da aber niemand im Auto Videos kucken will > und hier auch noch keiner darueber gesprochen hat, gehe ich mal davon > aus das dies nicht gewuenscht ist. Dann sollte doch eigentlich auch ein > kleineres LCD reichen. So haette man vielleicht unter dem LCD Platz fuer > eine Reihe von Knoepfen zur Direktanwahl von Senderspeichern und > aehnlichem. Ich schmeisse hier mal so ca. 10 * 3cm in den Raum mit der Bitte um Kommentare :-) > Meine Berufserfahrung als Hardwareentwickler sagt mir aber das da die > Probleme liegen. Du kannst niemanden anrufen und sagen das du 10000Stk > Bleche gelasert und gebogen haben willst. Wenn du sagst du brauchst nur > 10Stk dann lacht der dich aus. Und alles was bei einen normalen > Autoradio aus Spritzguss besteht kannst du auch vergessen. Ist das nicht so in etwa dasselbe Problem das Mechaniker haben wenn Sie über Elektronik sprechen, weil Sie einfach nicht die Möglichkeiten kennen. Ich gehe davon aus das es nicht so teuer ist eine Frontplatte fräsen zu lassen. Evtl. findet sich hier sogar jemand der eine Fräse hat und sich zutraut eine "Kleinserie" zu machen. Schöne Dreh- und Druckknöpfe die auch nicht so aussehen als ob man sie aus dem letzten Elektor selbstbauprojekt entwendet hat findet man zuhauf bei Farnell und Co., wenn man will sogar mit mehrfarh LEDs beleuchtete... Wie es hinten aussieht ist recht egal, solange es mechanisch stabil ist. Man kann auch z.B. ein paar mm dicke Aluminiumteile nehmen die man auf Länge sägt und an die Platine und untereinander verschraubt. > Du kannst vielleicht noch eine Aluplatte fraesen lassen, bekommst sie > irgendwo eloxiert und kannst sie eventuell noch mir siebdruck > beschriften lassen. Aber auch das sieht dann mehr nach einem > Labornetzteil von Conrad als nach einem Autoradio aus. Klar, es sollte schon nach etwas aussehen, allerdings möchte ich auch nicht unbedingt das es wie das letzt 5 farb China Transformer radio aussieht, sondern dezent bleibt, so wie mein altes Becker Radio.
> Aber bevor man irgendeinen exotischen DSP nimmt... Ich denke die Auswahl des Prozessors muss ueber die Entwicklungsumgebung erfolgen. Soll heissen es muss da was fuer umsonst geben. Schliesslich will hier wohl kaum einer erstmal ein paar kEuro nur dafuer ausgeben. Und nach meinem Kenntnisstand sieht es da fuer die meisten (alle?) DSPs schlecht aus. Vermutlich ist es da wirklich am besten wenn man mehrere Prozessoren nimmt. Sozusagen multitastking fuer Anfaenger. :-) > Ich hab fast all das hier schon mal realisiert (auch from scratch) und > bin mir durchaus der Komplexität bewusst. Ich auch, allerdings fuer Messgeraete und nicht fuer Autoradios. Daher meine Paranoia bei der Mechanik. Ich weiss halt wo die Probleme bei kleinen Stueckzahlen liegen. Dafuer musste ich noch nie einen Gedanken daran verschwenden ob ein Platine jetzt einen Euro teurer ist oder nicht. :-P > - Kein externer Ram/Flash Das ist in der Tat nicht so schoen weil es Platz braucht und mehr EMV erzeugt. Ich sehe aber keinen weg daran vorbei. Wenn man wirklich mit Audiodaten rumspielen will dann braucht man mehr als 10k Ram. Und wenn hier Leute das Inhaltsverzeichnis dicker SD-Karten einlesen wollen dann braucht auch das seinen Platz. Es ist ja kein Zufall das der von mir erwaehnte Audioprozessor von Renesas soviel internes Ram hat. Die haben sich da schon was bei gedacht. Schaut euch doch mal das Datenblatt an... http://www.renesas.com/products/mpumcu/superh/sh7260/sh7262/sh7262_root.jsp Wie gesagt, ich will den hier keinen aufschwatzen, dazu kenn ich das Teil selbst zu wenig. Aber man bekommt schonmal einen ungefaehren Eindruck was man so braucht. Denn die Teile sind ja fuer Grossserie gedacht. Da ist nicht ein Stueck mehr Silizium drin als man braucht weil das sonst nur unnoetig Geld kostet. Olaf
Olaf Kaluza schrieb: > Mir ist gerade noch was zum Bedieninterface eingefallen das ich mal zur > Diskussion stellen wollte. > > Man nimmt ein Encoder mit integrierter Taste auf der einen Seite um sich > damit durch die Menues zu arbeiten, auf der anderen Seite kommt ein > Motorpoti. So kann man dann z.b Lautstaerke ganz normal mit dem Poti > einstellen und sie vor allem absolut-winkelabhaengig veraendern. Und > wenn man jetzt im Menue auf Bass oder Fader schaltet dann dreht das > Radio den Knopf schnell auf die aktuelle Ist-Position bevor man einen > neuen Sollwert durch drehen einstellt. > > BTW: Wie gross, von den Massen her muesste das LCD eigentlich sein. Mein > aktuelles Radio hat ein LCD fast so gross wie die Front weil es darauf > auch Video darstellen kann. Da aber niemand im Auto Videos kucken will > und hier auch noch keiner darueber gesprochen hat, gehe ich mal davon > aus das dies nicht gewuenscht ist. Dann sollte doch eigentlich auch ein > kleineres LCD reichen. So haette man vielleicht unter dem LCD Platz fuer > eine Reihe von Knoepfen zur Direktanwahl von Senderspeichern und > aehnlichem. öh, bis auf das Motorpoti beschreibst Du damit doch gerade das Becker-Design was Du oben noch verschmäht hattest...oder? jedenfalls geht das ziemlich in die gleiche Richtung wie das Bedienkonzept was ich mir vorstellen würde ;-) denke gerade z.B. an ein Becker Mexico Pro, das hat in der Mitte ein relativ großes Pixeldisplay, je einen Drehencoder rechts (Menüs) und links (Lautstärke), darunter 10 Tasten die je nach Betriebsart belegt sind und darüber ein paar um Quellen umzuschalten usw. > Es waer doch irgendwie doof wenn man sich erst die ganze Arbeit macht, > dann ein Referenzdesign im Form einer Europlatine auf dem Tisch liegen > hat und dann darauf stoesst das man es nirgendwo einbauen kann das einen > WAF groesser 0.1 hat. sehe ich auch so. Das Gehäuse muss natürlich nicht als erstes fix und fertig sein, aber ich wüsste zumindest gerne vorher schon dass überhaupt die Chance besteht etwas ansprechendes hinzubekommen. Ich selbst hätte da nämlich wenig Möglichkeiten. Für meinen MP3-Player damals hab ich ein Gehäuse bei Schaeffer fräsen lassen, aber der ist auch nicht sichtbar montiert. Dafür ist das noch ok, aber im Armaturenbrett?? ich weiß nich so recht...
Ich sehe gerade die Vorteile eines Motorpotis ggü. einem Inkrementalgeber nicht. Kann mich kurz jemand aufklären?
Tobi schrieb: > Ich sehe gerade die Vorteile eines Motorpotis ggü. einem > Inkrementalgeber nicht. Kann mich kurz jemand aufklären? Die Relation zwischen Position des Potis und Lautstärke/Bass/... ist absolut und nicht relativ. Ausserdem hat man einen Anschlag => bis zum Anschlag nach links drehen = ganz leise.
> Ich gehe davon aus das es nicht so teuer ist eine Frontplatte > fräsen zu lassen. Das haengt von der Maschinenlaufzeit ab. Ausserdem auch von so Details ob man umspannen muss oder wieviele unterschiedliche Fraeser man braucht. Und natuerlich ganz entschieden von der Stueckzahl. Du hast relativ hohe Einricht/Programierkosten. Ich wuerde mal schaetzen das eine Frontplatte mit eloxieren und siebdruck irgendwo zwischen 100 und 200Euro liegen duerfte wenn du mindestens 10Stueck abnimmst. Aber das ist eine Schaetzung und ich kann da auch schnell danebenliegen. Und nebenbei gesagt, die weisst nicht wie oft man bei der 0-Serie erleben kann das da was schiefgeht. Was das selbermachen angeht habe ich so meine bedenken. Ich habe eine Fraese (nur Handbetrieb, Proxxon-Level) zuhause (bin ja nicht nur ET-Ing sondern noch Schlosser, da braucht man das <BG>) Ich weiss nicht ob man da vernueftige Oberflaechengueten hinbekommt. Aber immerhin koennte ich vernuenftige 3D-CAD Zeichnungen erstellen. Olaf
>Ich sehe gerade die Vorteile eines Motorpotis ggü. einem >Inkrementalgeber nicht. Kann mich kurz jemand aufklären? Es ging dabei (wurde weiter oben genannt) um die Absolutposition des Stellers. Da könnte man eher einen Slider auf einem Touchscreen basteln... Ich hätte hier noch ein Ford-Cassetten-Radio abzugeben... ;-)
> Da könnte man eher einen Slider auf einem Touchscreen basteln...
NEIN! Genau das will man nicht haben. Du kannst kein Touchscreen
bedienen ohne draufzuschauen und wenn ich Autofahre dann schaue ich
lieber auf die Strasse.
Es ist okay wenn seltene Sachen wie z.b das einprogramieren eines neuen
Senders etwas komplizierter sind, aber Sachen die man bei der Fahrt
aendern will muessen ganz einfach und mit taktiler Rueckmeldung
geschehen.
Olaf
Olaf Kaluza schrieb: > Es ist okay wenn seltene Sachen wie z.b das einprogramieren eines neuen > Senders Das geht ja nun tierisch einfach, einfach die gewünschte Stationstaste lange drücken. Sofern es Stationstasten gibt... > etwas komplizierter sind, aber Sachen die man bei der Fahrt > aendern will muessen ganz einfach und mit taktiler Rueckmeldung > geschehen. Aber will man den Bass-Level/Höhen/ähnliches während der Fahrt ändern? Lautstärke okay, aber das Ergebnis hört man ja.
>Die Relation zwischen Position des Potis und Lautstärke/Bass/... ist >absolut und nicht relativ. Ausserdem hat man einen Anschlag => bis zum >Anschlag nach links drehen = ganz leise. Das wäre sinnvoll, wenn der Knopf eine Skala hätte, die man während des Einstellens abliest. Bei Dingen wie Lautstärke, Bass usw. sind absolute Werte aber eher uninteressant. Ich höre ja das Ergebnis während des Einstellens - dazu brauche ich kein taktiles oder optisches Feedback.
Olaf Kaluza schrieb: >> Ich gehe davon aus das es nicht so teuer ist eine Frontplatte >> fräsen zu lassen. > > Das haengt von der Maschinenlaufzeit ab. Das hängt vor allem von den Ansprüchen ab, die man ans Design hat. Eine gefräste Fromtplatte von schaeffer-apparatebau.de kostet in der Größe tatsächlich nur ein paar Euro - und sieht dann aus, wie Apparatebau. Wenn dann die Frontplatte mal da ist, braucht es auch noch Knöpfe, für manchen hier möglichst viele. Wer schonmal versucht hat, so etwas anderes als 70er-Jahre-Hameg-Oszi-Design zu bekommen, weiß, was das bedeutet: Gibts nicht. Entweder auch aus dem vollen fräsen, oder in 1000 Stückzahlen in Kunststoff anfertigen lassen. Daher kommt der nicht ganz unvernünftige Vorschlag, alles per touchscreen zu lösen. Ist zwar von der Bedienung her scheixxe, vereinfacht dafür die Mechanik und damit die Probleme einer Realisierung ganz erheblich. Aber der Trend geht ja zur Zeit eher zur universell verwendbaren modularen Hardwareplattform, die das Gehäuse als kleines Problemchen dem Einzelnutzer überlässt. Mein Vorschlag dazu wäre dann noch ein Emulator für den PC, dann kann man das alles virtuell laufen lassen (als Real-Player-Alternative). Oliver
Wir haben aber schon festgestellt das so ein Radio einiges an Kosten bedeutet und ohne Zweifel noch mehr an Arbeit. Sowas wird man, ich auf jedenfall, dann sicher fuer viele Jahre verwenden. Und ich moechte nicht die naechsten 10 Jahre auf Schaeffer Apparatebau kucken. Und ich moechte mich auch nicht 10Jahre mit einem TouchLCD rumaergern! Wenn ich mich aergern will kann ich auch bei meinem aktuellen Radio bleiben. Ich will etwas das zum vornehmen Ambiente meines Lancia Kappa passt [mit Fuss aufstampf] :-) BTW: Wie lange haelt so ein TouchLCD eigentlich? Noch dazu in einem Auto wo es im Sommer auch mal 60Grad und im Winter -20 haben kann? Nachdem was ich so bei Palmpiloten beobachten konnte ist gerade die Touchfolie immer der Grund fuer den Muelleimer. Bei Handys die eh alle zwei Jahre weggeworfen werden natuerlich kein Problem. Und man muss natuerlich ein Display haben das fuer den Temperaturbereich im Auto geeignet ist. Olaf
Hallo, ich habe zwar keinen Bedarf nach einem neuen Autoradio, aber vielleicht solltet Ihr das Projekt in verschiedene Teilprojekte aufteilen, so dass sich Leute gezielt den jeweiligen Gruppen zuordnen können. - Gehäuse (DIN-Schacht, Frontpanel, Display, Knöpfe) - Hardware (Basisplatine, Anbindung I/O, Erweiterungskarten) - Software (Linux, Anwendungen) Damit das Ganze nicht in zwei Monaten wieder vergessen ist, wird man auch nicht drumherum kommen, ein bisschen was schriftlich festzuhalten. Gruss Micha PS: Wenn, dann würde ich auf jeden Fall was Linux-basiertes nehmen.
Micha C. schrieb: > Damit das Ganze nicht in zwei Monaten wieder vergessen ist, wird > man auch nicht drumherum kommen, ein bisschen was schriftlich > festzuhalten. > Das seh ich genauso! ich währe bereit, ein Wiki dafür einzurichten, falls Interesse besteht. Harry
Harald L. schrieb: > Das seh ich genauso! > ich währe bereit, ein Wiki dafür einzurichten, falls Interesse besteht. Wenn Dir das einfach von der Hand geht und nicht zu umständlich ist, sehr gerne. Das ich mit Webservern und co hantiert habe ist ein paar Jahre her und würde sicher 2* so lange dauern als wenn es jmd. macht der ein bißchen "fitter" ist. Wenn nötig, kann ich Dir auch gerne einen Zugang zu meinem momentan ungenutzten webserver geben, hätte noch ne MySQL Datenbank und ne Menge webspace "frei".
Kai G. schrieb: > Harald L. schrieb: >> Das seh ich genauso! >> ich währe bereit, ein Wiki dafür einzurichten, falls Interesse besteht. > > Wenn Dir das einfach von der Hand geht und nicht zu umständlich ist, > sehr gerne. > Das ich mit Webservern und co hantiert habe ist ein paar Jahre her und > würde sicher 2* so lange dauern als wenn es jmd. macht der ein bißchen > "fitter" ist. Geht klar! Mach ich im Lauf des Tages fertig. Heute Abend sollte das laufen. Da du ja der Initiator dieses Projekt bist, richte ich dich da als Admin ein, und schick dir die Zugangsdaten via PN. Harry
Dann sollten wir trotzdem noch eine Seite im Wiki hier platzieren, als Statusseite.
Harald L. schrieb: > Geht klar! > Mach ich im Lauf des Tages fertig. Heute Abend sollte das laufen. > Da du ja der Initiator dieses Projekt bist, richte ich dich da als Admin > ein, und schick dir die Zugangsdaten via PN. Klasse!
Ich bin ja mal gespannt wie viele Leute von denen, die angekündigt haben zu helfen, am Ende tatsächlich mitarbeiten oder sogar investieren. Bis jetzt sieht es ja so aus als könnte man ja mit einer interessanten Idee schnell Leute zusammen trommeln!
Noch was zum vorgeschlagen reneseas controller under development also scheidet schon aus. Aber warum nicht echt einen Prozessor mit CPU + DSP nehmen ?
wäre nett, wenn jemand ein Logo für dieses Projekt entwickeln könnte!!! Harry
Der Link scheint nicht zu funktionieren? Ich finde das Projekt aber sehr interessant! Vielleicht könnte man es auch als normales Radio umfunktionieren? mit freundlichen Grüßen, Valentin Buck
Valentin Buck schrieb: > Der Link scheint nicht zu funktionieren? kann sein, daß die Domain bei deinem Provider noch nicht im DNS-Cache angekommen ist. Die URL hab ich eben erst in den DNS eingetragen. Innerhalb der nä. paar Stunden sollte die Seite allgemein erreichbar sein. Harry
Hallo, Sven schrieb: > Ich bin ja mal gespannt wie viele Leute von denen, die angekündigt haben > zu helfen, am Ende tatsächlich mitarbeiten oder sogar investieren. Bis > jetzt sieht es ja so aus als könnte man ja mit einer interessanten Idee > schnell Leute zusammen trommeln! ja, der Bedarf nach so einem Radio ist offenbar da (und bei dem was so an Fertiggeräten angeboten wird finde ich das nicht sehr überraschend ;-) ) -- nur wie es dann aussieht wenn es an die Umsetzung geht ist natürlich eine berechtigte Frage... Dazu kommen dann noch die verschiedenen Zielsetzungen wie sie hier im Thread ja schon vorkamen: * "erstmal die Hardware ans Laufen bekommen, das Gehäuse wird dann schon" vs. "ohne Gehäuse brauchen wir gar nicht erst anfangen; die restliche Hard- und Software kriegen wir dann schon hin wenn das erstmal steht" * Eierlegende Wollmilchsau mit WLAN und Pipapo oder "nur" ein Radio mit MP3 * und schließlich Linux: ja unbedingt, oder: nein, bloß nicht! die man wohl schwer unter einen Hut bringen kann... Von Fragen wie Touchscreen ja/nein oder Drehencoder/Motorpoti mal zu schweigen, aber sowas ist denke ich auch nicht soo tragisch, ändert ja an der Plattform nicht (viel). Also für mich ist wie gesagt die Mechanik auch erstmal k.o.-Kriterium, da ich da bisher keine brauchbare Lösung kenne. Bei allem weiteren kann man ja dann noch diskutieren, da mache ich mir jedenfalls weniger Sorgen... Gruß, Mathias
@Kai G. (xyphro), noch eine Frage am Rande: kann es sein, dass Du einmal für den Beck IPC@CHIP einen FAT32-Treiber portiert hast, oder verwechsle ich Dich da mit jemand?
DAs Hauptproblem ist glaub ich, aber, dass es bei modernen Autos kaum möglich ist, das Autoradio gegen ein beliebiges auszutauschen, da die so fix integriert sind, dass sie komplett an die Formen der Kosnole angepasst sind und 2. das Display ganz woanders ist als das Radio.
Mathias A. schrieb: > @Kai G. (xyphro), noch eine Frage am Rande: kann es sein, dass Du einmal > für den Beck IPC@CHIP einen FAT32-Treiber portiert hast, oder verwechsle > ich Dich da mit jemand? jep, genau der bin ich :-)
seennoob schrieb: > Hab mal mit den Feautures auf Wiki angefangen. ..und ich hab ein wenig Formatierung hinzugefügt ;) Hier: http://meta.wikimedia.org/wiki/Hilfe:Textgestaltung gibts ne ganz brauchbare Anleitung, wie man den Text formatiert. Harry
seennoob schrieb: > Danke Mysth ich hab zu danken! ;) immerhin bist du der erste, der meine Installation testet. Du willst ja sicher noch mehr dazu beitragen, daher fänd ich es nett, wenn du dich auch als User dort anmelden würdest. (re. oben auf "anmelden" klicken und neuen Account anlegen) Harry
Browser lässt darauf schließen, dass jetzt doch Linux verwendet wird? Eine wie ich finde gute Entscheidung, da es unter anderem dem Hobby-Nutzer die Meisten Erweiterungsmöglichkeiten bietet.
Ich will jedem Hobby Programmierer das Hardware gefrickel ersparen auch wenn das 20% Leistungsverlust bedeutet ! Wenn dann wird was gscheids verbaut sowas in die Richtung OMAP. Wer mich noch die Tage mit der Beagleboard Community zusammenschließen und mal schauen was sie sagen wegen Hardware anpassung usw. Da ist auch Erfahrung da wenns um die Entwicklung von so sachen geht. MFG PAtrick
Olaf Kaluza schrieb: > Andererseits ist B.Kainka ja ein Freund von mir und der freut sich > immer wenn er ein AM-Radio bauen darf. Ich muss ihm nur klarmachen das > er diesmal keine Roehre verwenden darf! :-D Ach, wenn er ein Hybrid-Auto fährt, warum eigendlich nicht ? Beim Prius III die 650 Volt Batteriespannung als Anodenspannung verwendet, da kommt sogar ordentlich Leitung im echten Röhrensound bei raus. Die Ausgangsübertrager könnten etwas schwer werden. 12 Volt zum Heizen (z.B. RV12P2000) sind ja sowieso da... ;-) Man sollte bedenken, daß viele Fahrzeuge über Lenkradbedienungen verfügen, die z.T. unterschiedlich angesprochen werden -> per CAN oder auch spannungscodiert. Bei CAN kommt noch das Problem der unterschiedlichen Identifiers dazu. Möglicherweise ein externes Modul zum Anpassen ? LG Elux
Also ich bin nach wie vor strickt gegen Linux. Ich bin davon überzeugt das es kein stabiles Gesamtsystem gibt und in einem großen Gefrickel endet. So Sachen wie UMTS und WLAN würde ich auch rauslassen, schließlich soll es ein Autoradio werden und kein mobiles entertainmentsystem. Dann würd ich lieber gleich nen Mini ITX board benutzen...
word! Ich bin auch gerne dabei solch ein radio zu realisieren, aber ohne linux! Auch wenn ich dadurch nie nen browser im radio haben werde. Vielleicht sollten zwei projekte gestartet werden
Linux ist in meinen Augen fast Pflicht. Aber der Kernel muss angepasst werden auf die Anwendung als Radio ! Ein RT-Kernel wär vielleicht ganz cool aber muss nicht sein. Wenns aber Richtung multitasking geht ist Linux die beste Wahl.
seennoob schrieb: > Linux ist in meinen Augen fast Pflicht. Aber der Kernel muss angepasst > werden auf die Anwendung als Radio ! > Ein RT-Kernel wär vielleicht ganz cool aber muss nicht sein. Wenns aber > Richtung multitasking geht ist Linux die beste Wahl. ...den part würde ich gerne übernehmen! Harry
Über die Suche nach einem geeigneten Autoradio-Empänger-IC bin ich auf den TEF6901 (Integrated car radio) von NXP gestossen und auf diesen Thread: http://www.car-pc.info/phpBB2/viewtopic.php?t=22498. Dort ist man seit ca. 1 1/2 Jahren mit einem ähnlichen Projekt beschäftigt. Den TEF6901 gibt es auch auf einer fertigen Platine bei http://www.techdesign.be/projects/041/041.htm für 106€. Ist zwar ne Menge Geld, dafür aber eine sehr gute Lösung. Walter
Ohne Linux kannste aber sowas wie OMAP3 vergessen - sonst ist man ja monatelang damit beschäftigt nur die ganzen Hardwaremodule ans laufen zu bringen. Ist ja schon was anderes als nen AVR oder nen kleiner ARM7... Man könnte ja evtl. ein Basisboard bauen wo man optional nen Beagleboard anschließen könnte ODER alternativ irgendwas anderes ohne Linux. Also einfach alles Modular gestalten - evtl. auch den Audioteil dann kann man das auch leichter upgraden, so wie mans braucht. Nur so ne Idee.
rakkatakka schrieb: > Ohne Linux kannste aber sowas wie OMAP3 vergessen - sonst ist man ja > monatelang damit beschäftigt nur die ganzen Hardwaremodule ans laufen zu > bringen. Ich sag ja auch nicht das man dem OMAP3 nehmen muss. Ein Arm9, nein selbst ein größerer Arm7 würde alle Sachen aus der Feature list erledigen können (OK, jetzt mal echo cancelation aussen vor gelassen). > Also einfach alles Modular gestalten - evtl. auch den Audioteil dann > kann man das auch leichter upgraden, so wie mans braucht. > Nur so ne Idee. Zu Modular ist auch nicht gut, dann brauchst Du für nen Grundsystem mit Basisfunktionen schon 5 Platinen. Daher hatte ich vorgeschlagen ein Grundsystem zu machen mit allen Basisfunktionen für ein Radio + "Erweiterungsslots".
walter schrieb: > Über die Suche nach einem geeigneten Autoradio-Empänger-IC bin ich auf > den TEF6901 (Integrated car radio) von NXP gestossen und auf diesen > Thread: > http://www.car-pc.info/phpBB2/viewtopic.php?t=22498. Dort ist man seit > ca. 1 1/2 Jahren mit einem ähnlichen Projekt beschäftigt. Den TEF6901 > gibt es auch auf einer fertigen Platine bei > http://www.techdesign.be/projects/041/041.htm für 106€. Ist zwar ne > Menge Geld, dafür aber eine sehr gute Lösung. Die TEF690x Reihe ist für low cost Radio gedacht, aber qualitativ echt nicht schlecht. Viele Features von echten Radio DSPs fehlen halt, aber alles was man in einem einfachen Radio braucht ist enthalten. Ich dachte auch von Anfang an an sowas wie den TEF6903. 106 EURO ist echt ein stolzer Preis!!
walter schrieb: > Den TEF6901 gibt es auch auf einer fertigen Platine bei > http://www.techdesign.be/projects/041/041.htm für 106€. Ist zwar ne > Menge Geld, dafür aber eine sehr gute Lösung. Der Chip kostet bei Digikey nur 9,30$. http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=TEF6901AH/V5S,518-ND Und die Platine wollen wir wenn dann ja selber machen. Richtig kompliziert sieht die auch nicht aus.
> Der Chip kostet bei Digikey nur 9,30$. > http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=TEF6901AH/V5S,518-ND > Und die Platine wollen wir wenn dann ja selber machen. Richtig > kompliziert sieht die auch nicht aus. Wenn ich die Platine sehe, bezweifel ich erlich gesagt das viel über das Layout nachgedacht wurde. Ich seh auch nirgendwo Messergebnise (SINAD, Empfindlichkeit, Intermodulation und co.).
Ich bin auf jedem Fall für einen Linuxkernel, würde jedoch Browser, GPS und co weglassen.
Browser halte ich ebenfals für überflüssig, und GPS wäre sogar mit nem ATTiny zu erschlagen ;) Harry
seennoob schrieb: > Wie ist das jetzt zu verstehen ? > > MFG Ich würde mich um den Kernel kümmern. Das Thema ist mir nicht fremd. Harry
> Noch was zum vorgeschlagen reneseas controller under development also > scheidet schon aus. Ich will es nicht ausschliessen, aber die verschenken den hier im Japan als Beigabe zu einem Elektronikheft und es gibt auch bereits einige Applikationen zu diesem Prozessor bei Renesas zum download. Ich glaube nicht das noch viel dran entwickelt wird. Es gibt ausserdem die Entwicklungsumgebung von Renesas mit Compiler von Renesas, nach 60Tagen auf maximal 256k Codegroesse beschraenkt. Und es gibt den gcc auch dafuer. Ich will aber nicht ausschliessen das die Beschaffung in Deutschland schwieriger sein koennte! > DAs Hauptproblem ist glaub ich, aber, dass es bei modernen Autos kaum > möglich ist, das Autoradio gegen ein beliebiges auszutauschen, Das Problem umgehe ich dadurch das ich beim kauf darauf achte das dies bei meinen Autos kein Problem ist! Ansonsten meine ich das das die Protokolle bei ein paar Autos fuer die externen LCDs auch schonmal analysiert wurden. Wer sowas braucht kann es sich dann ja auch nachprogrammieren. > Also ich bin nach wie vor strickt gegen Linux. Ich bin davon überzeugt > das es kein stabiles Gesamtsystem gibt und in einem großen Gefrickel > endet. Ich ebenfalls! > So Sachen wie UMTS und WLAN würde ich auch rauslassen, Ich auch. Das braucht man in einem Radio nicht. Und es wuerde die Sache nur unnoetig kompliziert machen. > Wenns aber > Richtung multitasking geht ist Linux die beste Wahl. Ich will kein echtes Multitasking in einem System das in Echtzeit Audiodaten verschiebt. Das ist unnoetiger Aufwand! Man kaempft dann an der einen Front mit der Zuverlaessigkeit und an der anderen damit das System ausreichend schnell zu halten damit der Nutzer nicht gaehnen muss. > Also ich bin nach wie vor strickt gegen Linux. Ich bin davon überzeugt > das es kein stabiles Gesamtsystem gibt und in einem großen Gefrickel > endet. Ich habe noch nie was mit Arm gemacht, in den letzten Jahren nur Renesas, aber wenn die schnell genug sind dann unterstuetze ich das. Im Zweifel lieber das fetteste Teil das man bekommen kann solange es kein BGA ist. BTW: Was ist eigentlich mit dem Prozessor der im Chumby ist? Das ist doch auch ein ARM und ich fand da den integrierte Analogteil und den Spannungswandler ganz interessant. Ich weiss aber nicht wie Motorola so mit Kleinmengen rueberkommt. Glyn/Renesas war da bisher immer sehr entgegenkommend! Ich denke das dieser Prozessor sich um SD-Karte und Audio kuemmern sollte. Fuer die Bedieneinheit sollte es einen zweiten Prozessor geben. So koennte man da halt relativ einfach was umdesignen wenn einer eine andere Front mit einem anderen Interface moechte. Olaf
Aechz! Ich hab mir gerade mal die Featurelist auf der OSCAR Seite durchgelesen. Wenn ihr das alles einbauen wollt dann wird das nie fertig. Das halte ich fuer ein 3-4Personen-basteln-nach-Feierabend Project fuer eine Groessenordnung zu fett. Mich wundert fast das noch keiner eine IRFB haben wollte. War bei meinem aktuellen Autoradio dabei und es gibt fast nichts wobei man sich noch bescheuerter fuehlt als wenn man im Auto 40cm vom Radio entfernt sitzt und das mit einer FB bedient. Aeh..und wo ich schonmal am meckern bin. Was soll denn ein zweites LCD und Spiele? Wenn den Kroeten auf der Ruecksitzbank langweilig ist dann sollen sie halt aus dem Fenster schauen und Nummernschilder zaehlen. Hat fuer uns doch auch gereicht. Und wenn sie meckern dann macht man ihnen klar das dad naechste Auto das Papa sich kauft ein Sportwagen ohne Ruecksitzbank sein koennte. :-) Und wenn ich auf dem Campingplatz ins Internet will dann verbindet sich mein Laptop ueber Bluetooth mit dem Handy in meiner Tasche und auch nur weil mein Laptop schon so alt ist das da kein UMTS eingebaut ist. Aber wegen so einem Firlefanz einen UMTS-WLAn Router entwickeln zu wollen? Da frage ich mich wirklich ober der Wuenscher eine Vorstellung von der Komplexizitaet hat. Olaf
Olaf Kaluza schrieb: > Aechz! Ich hab mir gerade mal die Featurelist auf der OSCAR Seite > durchgelesen. Wenn ihr das alles einbauen wollt dann wird das nie > fertig. Das halte ich fuer ein 3-4Personen-basteln-nach-Feierabend > Project fuer eine Groessenordnung zu fett. Ich habe das ganze mal etwas umgestrickt und ein neuen Unterpunkt "Basis Features" gemacht. Weil ich denke das sich die 2 unterschiedlichen Ansätze sowieso nicht so ohne weiteres unter einen Hut bekommen lassen werden. Diese "Basisfeatures" sind leicht in Hardware implementiert und in Software muss man nicht alles sofort implementieren. z.B. kann man erstmal ein 1 Tuner System nur mit RDS Radiotext und MP3 Wiedergabe bauen und dann Schritt für Schritt erweitern. => Gerne weiter editieren, z.B. features hinzufügen/ändern oder Prioriäten hinzufügen oder so. > Aeh..und wo ich schonmal am meckern bin. Was soll denn ein zweites LCD > und Spiele? Wenn den Kroeten auf der Ruecksitzbank langweilig ist dann > sollen sie halt aus dem Fenster schauen und Nummernschilder zaehlen. Hat > fuer uns doch auch gereicht. Und wenn sie meckern dann macht man ihnen > klar das dad naechste Auto das Papa sich kauft ein Sportwagen ohne > Ruecksitzbank sein koennte. :-) LOL ;-) Meine Eltern hatten mich auch noch mit tollen Spielen wie "zähl mal die roten Autos" beschäftigt und ich hoffe mit unserem kleinen bekommen wir das auch noch auf die Variante hin ;-) > Ich will kein echtes Multitasking in einem System das in Echtzeit > Audiodaten verschiebt. Das ist unnoetiger Aufwand! Man kaempft dann an > der einen Front mit der Zuverlaessigkeit und an der anderen damit das > System ausreichend schnell zu halten damit der Nutzer nicht gaehnen > muss. Man kann noch weiter gehen und sich Fragen ob man überhaupt Tasks und einen Scheduler braucht. Viele Sachen haben schon so harte Echtzeitbedingungen (z.B. RDS) das man mit Tasks schon nicht mehr so ohne weitere arbeiten kann.
Kai G. schrieb: > Dann > würd ich lieber gleich nen Mini ITX board benutzen... Das ist natürlich auch eine Idee, wieso kein x86? Datasheet für Pico-ITX-Board: http://www.spectra.de/produkte/124083/web/spectra/Datasheet-LP-170.pdf Im 3,5"-Format gibts auch einiges. Problematisch stellt sich für mich die Bauteilhöhe (Platz?) und der Preis dar ;)
Olaf Kaluza schrieb: > Mich wundert fast das noch keiner eine IRFB haben wollte. War bei meinem > aktuellen Autoradio dabei und es gibt fast nichts wobei man sich noch > bescheuerter fuehlt als wenn man im Auto 40cm vom Radio entfernt sitzt > und das mit einer FB bedient. Es gibt nix sinnvolleres als eine Fernbedienung. Wenn sie nicht im Lenkrad integriert ist, dann muss es eben eine IRFB sein. Während der Fahrt am Radio rumzuspielen ist kreuzgefährlich, die IRFB bedient man blind und v.a. ohne sich vorbeugen zu müssen. Der Abstand von 40cm ist vollkommen irrelevant.
Dann bevorzuge ich allerdings die Lenkradfernbedienung; die hab ich im aktuellen PKW und möchte sie wirklich nicht mehr missen. Sprich es müsste eine entsprechende Schnittstelle eingeplant werden. IRFB sind meiner Meinung nach obsolet. VG
Kai G. schrieb: > Also ich bin nach wie vor strickt gegen Linux. Ich bin davon überzeugt > das es kein stabiles Gesamtsystem gibt und in einem großen Gefrickel > endet. Also wir setzen Debian Stable in embedded Systeme bei unseren Kunden ein. Die laufen dort bereits seit Jahren ohne Probleme oder Unterbrüche. Eine Instabilität können wir überhaupt nicht feststellen. Das Basissystem (ohne X-Windows Server) ist extrem stabil und sehr resourcenschonend. Zudem setzen wir Asterisk auf eine angepasste Linux-Distro ein. Die läuft auch schon seit zwei Jahren ohne Unterbruch und steuert alle unsere Telefonate. Ausserdem laufen bei uns im Unternehmen auch alle Router und Telefone unter Linux, bisher auch fehlerfrei. Von Seiten der Wartbarkeit hat sich die Modularität für uns sehr positiv ausgewirkt. An einer grossen monolythischen Firmware ist die Wartung und Pflege eine Sache, die zumeist von einem Spezialisten duchgeführt werden muss, der die gesamte Firmware kennt. Mit modularen Systemen können unterschiedliche Entwickler an verschiedenen Komponenten arbeiten. Aus meiner Sicht spräche aber vor allem der Punkt, dass man auf bereits entwickelte, sehr stabile Komponenten setzen kann und nicht alles neuentwickeln muss, für den Einsatz eines embedded Linux. Zudem können Nutzer recht einfach weitere Komponenten für sich hinzunehmen. Just my 2c. Michael
Reinhard S. schrieb: > Kai G. schrieb: > >> Dann >> würd ich lieber gleich nen Mini ITX board benutzen... > > Das ist natürlich auch eine Idee, wieso kein x86? > > Datasheet für Pico-ITX-Board: > http://www.spectra.de/produkte/124083/web/spectra/Datasheet-LP-170.pdf > > Im 3,5"-Format gibts auch einiges. Problematisch stellt sich für mich > die > Bauteilhöhe (Platz?) und der Preis dar ;) Falls wirklich ein x86, dann würde ich eher ein alix3 (www.pcengines.ch) nehmen. Die Leistung mit 500 MHz reicht allemal aus für selbst die grössten Spielereien. Eine WLAN-Karte kann eingesteckt werden (für die, die das brauchen), und auch eine CF-Karte für die Firmware. Der Stromverbrauch mit 2-5 Watt typ. ist angenehm, ebenso wie der Preis von weniger als 100 Euro. Die Grösse ist deutlich kleiner als Mini-ITX und sollte eigentlich problemlos in den DIN-Rahmen passen.
Soll das ein Car PC werden oder ein Radio? Ich bin auch stark für nen Arm7 oder Arm9 ohne Linux. Für ein richtigen Computer mit WLAN und sonstigem Schnick Schnack reicht's dann natürlich nicht aus. Aber für ein bisschen Radio, USB und sd Karten und mp3 Funktionalität(was wohl sowieso ausgelagert wird) sollte das wohl reichen, oder nicht?
Harald L. schrieb: > Wenn das Auto im Carport steht, kann ich per WLAN & SSH drauf zugreifen, > und an dem System arbeiten. > (Auch hier hilft uns Linux, weil auch SSH hier nicht neu geschrieben > werden muss) > Ach ja....und unterwegs kann darüber in Verbindung mit dem Mobiltelefon > der Stick als AP arbeiten, und man kann per Laptop ins Netz. Und während der Fahrt kann das AR mit seinesgleichen Musikdateien tauschen, mit anderen Fahrzeugen in der Nähe eine VoIP-Verbindung aufbauen, um sich gegenseitig mal so richtig anschnauzen zu können ;-), während Staus kann man damit Nothilfe an Verdurstende organisieren, Kinder können die auf anderen ARs gespeicherten Spiele spielen für etwas mehr Abwechslung, und wenn einer seinen USB-UMTS-Router ansteckt, kann der ganze Stau E-Mails an die jeweiligen Großomas und den ADAC mit den Positionsdaten schicken usw. Und die verrücktesten Freaks können sich dabei dann gegenseitig beim Direkt-Tunen ihrer Motoren über CAN unterstützen. Nun, man sollte wohl nicht alles davon tun, aber coole Möglichkeiten gäbe es schon.
Michael B. schrieb: >> Also ich bin nach wie vor strickt gegen Linux. Ich bin davon überzeugt >> das es kein stabiles Gesamtsystem gibt und in einem großen Gefrickel >> endet. > Also wir setzen Debian Stable in embedded Systeme bei unseren Kunden > ein. Die laufen dort bereits seit Jahren ohne Probleme oder Unterbrüche. > Eine Instabilität können wir überhaupt nicht feststellen. Das > Basissystem (ohne X-Windows Server) ist extrem stabil und sehr > resourcenschonend. > Zudem setzen wir Asterisk auf eine angepasste Linux-Distro ein. Die > läuft auch schon seit zwei Jahren ohne Unterbruch und steuert alle > unsere Telefonate. Ausserdem laufen bei uns im Unternehmen auch alle > Router und Telefone unter Linux, bisher auch fehlerfrei. Ich sag ja nicht das Linux generell instabil ist, ich bin eigentlich pro-Linux. Aber in einem Autoradio finde ich hat es nichts zu suchen. Ich will mich nicht ärgern wenn jemand irgendwo in einem Script beim parsen mit grep vergessen hat eine Rückgabe zu berücksichtigen oder weil er benutzte Komponenten nicht im Detail kennt etwas wichtiges vergessen hat was dann z.B. zu sowas führt wie das die dann evtl. benutzte WLAN Verbindung nicht wieder automatisch aufbaut wenn Sie wegfällt, oder was weiss ich. Ich sehe auch keinen Vorteil. Wenn man kein Multimediasystem mit Mplayer und co. machen will dann kann man in einem System ohne Linux genauso code "recyclen". Mal ganz abgesehen von dem Speicherbedarf, der Tatsache das man eine dynamische Speicherverwaltung braucht (was man meiner Meinung nach in kleinen embeddedsystemen sowieso vermeiden sollte), ... Wie gesagt, ich bin nicht contra linux und auch kein Windows jünger, ich finde es einfach nur sehr unpassend für solch ein einfaches System. > Aus meiner Sicht spräche aber vor allem der Punkt, dass man auf bereits > entwickelte, sehr stabile Komponenten setzen kann und nicht alles > neuentwickeln muss, für den Einsatz eines embedded Linux. Zudem können > Nutzer recht einfach weitere Komponenten für sich hinzunehmen. Ich behaupte genauso einfach, wenn nicht sogar einfacher geht es wenn man ohne Linux arbeitet. Eine saubere und modulare Software vorrausgesetzt. Die Build- und Testumgebung ist deutlich schlanker und übersichtlicher. Wer nicht viel Ahnung hat muss sich nicht erst in Linux einarbeiten und man hat evtl. eine chance auch als reiner Windows-user mal etwas an dem Radio zu ändern ohne in die Tiefen von Linux, Cygwin oder so abzutauchen.
didadu schrieb: > Und die verrücktesten Freaks können sich > dabei dann gegenseitig beim Direkt-Tunen ihrer Motoren über CAN > unterstützen. Oder den Motor eines "Rivalen" beim Straßenrennen einfach mal ausschalten...
Sven schrieb: > Soll das ein Car PC werden oder ein Radio? > > Ich bin auch stark für nen Arm7 oder Arm9 ohne Linux. Für ein richtigen > Computer mit WLAN und sonstigem Schnick Schnack reicht's dann natürlich > nicht aus. Aber für ein bisschen Radio, USB und sd Karten und mp3 > Funktionalität(was wohl sowieso ausgelagert wird) sollte das wohl > reichen, oder nicht? Klar würde das auch reichen, ich als µC-Laie dachte mir aber, das man das evtl. auch mit x86 hinbekommt, was aus meiner Sicht den Vorteil von leichterer Entwicklung hätte. Wäre dann zwar klar ein Car-PC, der aber nur Audio-Sachen managen soll/kann. Bin grad bissel am stöbern zwecks passender Boards, aber problematisch ist für mich immer wieder der Audio-Ausgang, der, wenn überhaupt, nur als 3,5mm-Klinke da ist. Ich persönlich hätte ja gern S/PDIF, aber gibts für S/PDIF auf Lautsprecher überhaupt kleine & ordentliche Verstärker? Also jetzt für die 12-24 W im Auto.
Kai G. schrieb: > Wer nicht viel Ahnung hat muss sich nicht erst in Linux einarbeiten und > man hat evtl. eine chance auch als reiner Windows-user mal etwas an dem > Radio zu ändern ohne in die Tiefen von Linux, Cygwin oder so > abzutauchen. Dem stimme ich zu. Ich hab (fast) keine Ahnung von Linux, kann aber unglaublich gut Controller programmieren ;-) Sicherlich gibts noch die Leute, die genau anders herum gepolt sind. Das ist dann mehr die CarPC Fraktion...
dito Um diesen Thread nicht noch unübersichtlicher zu machen und weiter über die Verwendung von Linux oder nicht zu diskutieren, sollten ernsthaft zwei Projekte daraus werden. Dafür sollte ein extra Thread entstehen und dieser eher für Grundlagen benutzt werden. Auch würde ich eher dieses wiki hier im Forum benutzen, um möglicherweise mehr Leute für dieses Projekt zu begeistern. Ich finde nämlich, dass es ein wirklich interessantes Projekt ist.
So. Jetzt bin ich auch mal angemeldet :-) Also wird jetzt ein CarPC und ein Radio gebaut? Das mit dem Wiki ist so ne Sache. Die Frage ist, was bringt ein externes Wiki für Vorteile? Ist da eventuell das Rechtemanagement besser zu gestalten? Mit einem internen Wiki werden sicherlich mehr Leute erreicht. Aber sollte nicht sowieso eine Seite hier entstehen, auf der der Status verfolgt werden kann? Man kann ja die Diskussion auslagern und hier die Ergebnisse präsentieren..
Sven H. schrieb: > So. Jetzt bin ich auch mal angemeldet :-) > > Also wird jetzt ein CarPC und ein Radio gebaut? > Beides? > Das mit dem Wiki ist so ne Sache. Die Frage ist, was bringt ein externes > Wiki für Vorteile? Ist da eventuell das Rechtemanagement besser zu > gestalten? Bzgl. der Rechteverwaltung hast du natürlich Recht. Aber jeder kann sehen, was eine andere Person geändert hat und ggf. zurücksetzen. Soweit ich beurteilen kann, funktioniert es in diesem Portal ganz gut, auch ohne die Rechte großartig einzuschränken. > Man kann ja die Diskussion auslagern und hier die Ergebnisse präsentieren.. Für die Diskussionen gibt es pro Wikiseite immer eine Diskussionsseite.
Sven H. schrieb: > So. Jetzt bin ich auch mal angemeldet :-) Prima :-) > Also wird jetzt ein CarPC und ein Radio gebaut? Ich denke man sollte 2 Projekte starten und evtl. Teile austauschen, wie z.B. Tuner. Ich wäre dann eher in dem nicht-Linux, nicht-Wlan Projekt. > Das mit dem Wiki ist so ne Sache. Die Frage ist, was bringt ein externes > Wiki für Vorteile? Ist da eventuell das Rechtemanagement besser zu > gestalten? Mit einem internen Wiki werden sicherlich mehr Leute > erreicht. Aber sollte nicht sowieso eine Seite hier entstehen, auf der > der Status verfolgt werden kann? Man kann ja die Diskussion auslagern > und hier die Ergebnisse präsentieren.. Hier gibts ein Wiki? :-)
Sven H. schrieb: > Also wird jetzt ein CarPC und ein Radio gebaut? Wieso muß man hier so stark differenzieren? Ich denke auch das so ein mini-itx/mini-.... Board eine gute Grundlage wäre. Ob man das nun PC nennt oder einen ARMxyz der "nur" ein µP ist ist doch egal. Man hätte auf jedenfgall eine Platform auf der man vieles einfach aufsetzen kann (USB-Reciver/TV-Karte) und zu basteln gibt es noch genug (Display, Schnittstellen nach außen, Stromversorgung) als das es "langweilig" werden würde.
Kai G. schrieb: >> Also wird jetzt ein CarPC und ein Radio gebaut? > > Ich denke man sollte 2 Projekte starten und evtl. Teile austauschen, wie > z.B. Tuner. Ich wäre dann eher in dem nicht-Linux, nicht-Wlan Projekt. Dito. Drei mal ;-)
Sven H. schrieb: > Also wird jetzt ein CarPC und ein Radio gebaut? Ist doch gar nicht schlecht, dann muß aber jeder in einen einzel-DIN-Schacht passen, damit ich beides im Auto haben kann :-)
Also das Alixboard würde schon passen (152.4 x 152.4 mm) Din-Schacht Breite etwa 178mm... Höhe scheint mir hauptsächlich durch die LAN Buchsen gegeben. Man könnte dan sogar als Datenspeicher ein NAS oder USB-Stick/HD ranhängen, oder wirklich einen WLAN-Router ;) I2C für erweiterungen ist auch dabei (optional) Spannungsbereich passt auch recht gut (7-20V) + ein echter Seriell-Port ggf. kann auch HW mittels mini PCI nachgerüstet werden :)
Läubi .. schrieb: > Wieso muß man hier so stark differenzieren? > Ich denke auch das so ein mini-itx/mini-.... Board eine gute Grundlage > wäre. Ob man das nun PC nennt oder einen ARMxyz der "nur" ein µP ist ist > doch egal. Man hätte auf jedenfgall eine Platform auf der man vieles > einfach aufsetzen kann (USB-Reciver/TV-Karte) und zu basteln gibt es > noch genug (Display, Schnittstellen nach außen, Stromversorgung) als das > es "langweilig" werden würde. Mit dem USB Krams fängts doch schon an. Da ist so viel Software im Spiel (Firmware, Treiber, ...). Ich hab z.B. auch noch nie ein stabiles Mediacenter system gesehen (VDR eingeschlossen, der DSP auf den DVB Karten stürzt auch bei schlechtem Empfang mal gerne ab, besonders wenn in Richtung DVB-T was macht). Ich will im Auto nicht den selben Bastelkrampf haben wie am PC. Ich behaupte das viel consumer peripherie nicht dafür gemacht und auch nicht getestet um stabil zu laufen. Dann ist man bei solch einem Projekt mehr damit beschäftigt die halbwegs stabile TV/Tuner Karte zu finden als mit der eigentlichen Entwicklungsarbeit. Etwas zu machen das "nur funktioniert" ist einfach, aber etwas zu machen das gut und stabil funktioniert noch lange nicht, erst recht nicht mit so einem modularen System wie einem PC Board + aufgeblasenes Betriebssystem.
> Wie gesagt, ich bin nicht contra linux und auch kein Windows jünger, ich > finde es einfach nur sehr unpassend für solch ein einfaches System. Das sehe ich genauso, und ich waere sonst total fuer Linux. Lasst das erstmal ein normales Radio werden. Wer danach sich nicht ausgefuellt fuehlt kann ja immer noch weitermachen. > Mal ganz abgesehen von dem Speicherbedarf, der Tatsache > das man eine dynamische Speicherverwaltung braucht (was man meiner > Meinung nach in kleinen embeddedsystemen sowieso vermeiden sollte), ... Yep. Dynamische Speicherverwaltung ist kaese. Sobald sowas drin ist braucht man auch den Resetknopf auf der Front. Kennt einer sonst noch CPUs ausser der SuperH-2A die viel Speicher enthalten? Ich wuerde es naemlich auch sehr toll finden wenn man auf externen Speicher verzichten koennte. Ich habe gerade beruflich einen R32 mit externen Sram in Betrieb genommen und das ist vom Aufwand und dem Platinenplatz schon doof, da bei laeuft das der Speicher mit lahmen 25Mhz. Ich denke wenn man so eine moderne CPU mit SD-Ram hat dann steigt der Aufwand nochmal ganz erheblich. ich wuerde es z.b gut finden wenn man mit einer doppelseitigen Platine auskommen koennte. Irgendwo hab ich auch noch eine Multimedia-CPU von Fujitsu rumliegen die hatte auch so 512MB-1MB, aber die wird auch schwierig zu beschaffen sein. Was haben denn die ARMe so eingebaut. Vielleicht reichen ja auch erstmal 256k hin. Man muss ja nicht immer so uebertreiben. Eines ist mir bei dem Wikikram nicht ganz klar. Wenn ich jetzt hingehe und da was aendere und jemand anderes aendert das dann wieder nach seinen Vorstellungen und ich dann wieder zurueck usw... Gibt das dann nicht so eine Art Krieg? Ich habe den Eindruck als wenn diese Art Medium in der Anfangszeit eines Projektes wo es noch starke Aenderungen geben kann, nicht so geeignet. Wenn man sich jetzt mal darauf zu einigen schafft das wir erstmal ein normales Radio bauen, wer ist den wirklich ernsthaft dabei. Ich haette gerne mal eine Vorstellung ob am Ende 3 oder 15 Radios gebaut werden. Olaf p.s: Ich habe gerade meine Renesas SuperH dazu gebracht mit einer LED zu blinken. Unglaublich das so eine fette CPU das noch kann. ;-D
Zumindest WLAN scheint noch eine Marktlücke zu sein. Ich verstehe ja Leute, die als leidenschaftliche CD-Sammler gerne jede Original-CD zu Hause in ihrem Regal haben und in den Händen halten wollen. Aber warum schleppt man heute noch gerne Speichermedien von Gerät zu Gerät mit sich herum? Klar, die Gewohnheit stammt noch aus der Zeit, als nur eine kleine Anzahl Stücke auf ein Medium passten und es sich nicht vermeiden ließ. Oder bin ich einfach nur faul? Meine gesamten Musik-/Filmsammlungen liegen auf einem Server. Im Haus sind LAN/WLAN-Mediaplayer verteilt. Nur für's Auto scheint es da noch keine kaufbare Lösung zu geben. Es ist doch viel praktischer, abends von der Couch aus über den Laptop flott ein paar MP3s zum Auto zu schicken, als erst in die Garage laufen zu müssen, den USB-Stick auszustöpseln, zu bespielen und ihn am nächsten Morgen nicht zu vergessen - vom Brennen auf CDs/DVDs ganz zu schweigen. Alternativ könnte das Radio selber periodisch nachschauen, was auf dem Server neu hinzugekommen ist, und sich von allein eine Kopie davon ziehen. Dass ich für Linux bin muss da wohl nicht extra erwähnt werden :) Mir ist jetzt auch kein Embedded-Gerät bekannt, auf dem Linux unzuverlässig läuft. Selbst wenn zweimal am Tag ein Neustart erforderlich wäre - was nicht so sein wird - wär das bei einem Autoradio, das selten so lange an einem Stück läuft, durchaus kein Drama.
So jetzt muss ich mal als langjähriger Car-PC Bastler und Nutzer auch mal ein paar Worte dazu sagen. Hier wurde zuerst die Idee angeregt an ein Open-Source Radio zubauen und so sollte es vielleicht auch bleiben. Wer eine Eierlegende Wollmilchsau will sollte gleich direkt auf Car-PC einsteigen. Und jeder Car-PC ist Open-Source. ;) Ein Car-PC hat nur ein Problem. Es gibt derzeit keine wirklichen Alternativen zum Empfang von FM/DAB. Und hier könnte das Projekt voll einhaken. Das Radio sollte deswegen, wie weiteroben schon geschrieben, Modular aufgebaut sein. Grundplatine sollte im Grunde nur ein vollwertiges und gut funktionierndes RDS FM/DAB Radio sein. Jede Erweiterung, wie W-Lan, CD-Laufwerk, MP-3 ect. sollte dann über einen Zusatzslot verfügbar sein. Mit dem Verfahren könnte man viel mehr Leute begeistern. Mir persönlich würde nur ein RDS-Radio mit USB-Anbindung für den Car-PC reichen. ;) Zum Thema Touchscreen Bedienung: Das Touchscreen ist viel einfacher zu bedienen als man glaubt. Vorrausestzt ist ein gutes "Skin-Konzept" am Bildschirm. Wichtig sind große Bedienfelder und eine feste Belegung aller wichtigen Bedienelemente. So sollte die Lautstärkeregelung in allen Betriebsmodis (egal ob Radio, CD, ODB ect) an der gleichen Stelle sitzen. Innerhalb kurzer Zeit hat man sich dann daran gewöhnt und man muss nicht mehr zwingend auf den Monitor schauen. Ich persönlich hab zwar dutzende Versuche gebraucht um die richtige Aufteilung zufinden, aber jetzt ist es nahezu perfekt. Als Feedback benutze ich den Buzzer vom PC-Mainboard. Reicht völlig aus. Aufalle Fälle bahnt sich hier ein richtiges MEGA-PROJEKT an und ich bin voll begeistert davon. ;) Trotzdem sollten wir klein anfangen. Es wird nicht einfach einen guten Radioempfang im Auto zuerreichen. lg Pezi
Olaf Kaluza schrieb: > Lasst das erstmal ein normales Radio werden. Wer danach sich nicht > ausgefuellt fuehlt kann ja immer noch weitermachen. Full ack :-) > Kennt einer sonst noch CPUs ausser der SuperH-2A die viel Speicher > enthalten? Ich wuerde es naemlich auch sehr toll finden wenn man auf > externen Speicher verzichten koennte. Ich habe gerade beruflich einen > R32 mit externen Sram in Betrieb genommen und das ist vom Aufwand und > dem Platinenplatz schon doof, da bei laeuft das der Speicher mit lahmen > 25Mhz. Also etwas in der Größenordnung von 64/96 KB ist kein Problem und wäre erfahrungsgemäß genug für solch ein Radio. Allerdings wäre es schön doch noch etwas mehr zu haben. Wenn wir allerdings echt Codec/Radio in 2 uCs splitten würde etwas in der 64 KB Größenordnung sicher voll und ganz reichen. Die Idee mit dem extra Frontpanel uC würd ich übrigens auch voll unterstützen. Da reicht dann sicher was kleines (PIC/AVR oder so). > Ich denke wenn man so eine moderne CPU mit SD-Ram hat dann steigt der > Aufwand nochmal ganz erheblich. ich wuerde es z.b gut finden wenn man > mit einer doppelseitigen Platine auskommen koennte. ...mal ganz abgesehen von den schönen "Zaunpfosten" im Spektrum die mal durch den schnellen parallelen Bus bekommt. > Was haben denn die ARMe so eingebaut. Vielleicht reichen ja auch erstmal > 256k hin. Man muss ja nicht immer so uebertreiben. Also Flash in der Größenordnung ist kein Thema, aber RAM leider schon. 256K wäre echt mehr als perfekt. > Eines ist mir bei dem Wikikram nicht ganz klar. Wenn ich jetzt hingehe > und da was aendere und jemand anderes aendert das dann wieder nach > seinen Vorstellungen und ich dann wieder zurueck usw... > Gibt das dann nicht so eine Art Krieg? Probier einfach mal ;-) > Ich habe den Eindruck als wenn diese Art Medium in der Anfangszeit eines > Projektes wo es noch starke Aenderungen geben kann, nicht so geeignet. gibts andere Vorschläge (Kick off meeting? :-)) > Wenn man sich jetzt mal darauf zu einigen schafft das wir erstmal ein > normales Radio bauen, wer ist den wirklich ernsthaft dabei. Ich haette > gerne mal eine Vorstellung ob am Ende 3 oder 15 Radios gebaut werden. Also ich bin NATÜRLICH ernsthaft dabei! Würden eher 2 Radios werden (1 für Entwicklung, 1 fürs Auto). Das Entwicklungsradio kann breadboardmässig sein, braucht auch kein Gehäuse... > p.s: Ich habe gerade meine Renesas SuperH dazu gebracht mit einer LED > zu blinken. Unglaublich das so eine fette CPU das noch kann. ;-D Das erinnert mich an mein erstes Z80 board mit per Taster programmiertem Eeprom (ein LED Blink programm). Es funktionierte auf Anhieb und ich hab mich total gefreut, bis ich dann feststellte das die Blinkfunktion eher durch den 7805 kam, weil die POWER-LED auch blinkte, denn mein Z80 board mit RAM, IO Port IC und co hat zu viel Strom gezogen hat. Der 7805 wurde zu heiss => er schaltete ab => er kühlte ab => er schaltete sich an ;-)
> Mir persönlich würde nur ein RDS-Radio mit USB-Anbindung für den Car-PC > reichen. ;) Evtl. sollte man genau hier ansetzen. Das "Autoradio-projekt" stellt eine Schnittstelle für ein CAR-PC zur Verfügung. Sämtliche Funktionen des Radios können über eine API angesteuert werden. > Trotzdem sollten wir klein anfangen. > Es wird nicht einfach einen guten Radioempfang im Auto zuerreichen. Nicht mit einem full featured PC Board und 3 PCI Karten, stimmt. Einen guten Empfang in dem beschriebenen Autoradio-system zu erreichen ist nicht so schwer wenn man sich mit der Materie schonmal beschäftigt hat.
Hallo, ich werde zwar nicht zu den Projektbeteiligten gehören, lese aber sehr interessiert mit. Kann man das gesamte System nicht soweit modularisieren, so dass beide Fraktionen (Non-Linux, Linux) möglichst viel Überschneidungen haben? Wenn ich es richtig herauslese, gibt es ja Einigkeit darüber, dass der Radioteil (Tuner, RDS, ...) und die Bedieneinheit als eigene Module entwickelt werden sollen. Da sollte es doch möglich sein, die Schnittstellen so zu gestalten, dass die einen einen Mikrocontroller als Steuereinheit verwenden, während die anderen ein Linux-Embedded-System einsetzen. Gruss Micha
Kai G. schrieb: >> Was haben denn die ARMe so eingebaut. Vielleicht reichen ja auch erstmal >> 256k hin. Man muss ja nicht immer so uebertreiben. > > Also Flash in der Größenordnung ist kein Thema, aber RAM leider schon. > 256K wäre echt mehr als perfekt. Wir haben grade nen lpc2214 in Benutzung. Der hat intern 256k Flash und 16k Ram. An dem ist aber extern nochmal 2mb Ram dran gepömpelt und wir kommen locker mit einer zweilagigen Platine aus. Jetzt ist die Frage ob 45ns Ram reicht. Wenn mehr Flash gebraucht wird, könnte man auch externes Flash nehmen und den Krämpel daraus bei Systemstart ins externe Ram kopieren und das Programm von da aus laufen lassen. Meines Wissens nach gibt es aber auch LPCs mit mehr Ram und Flash und noch jeder Menge anderer Peripherie (i2c, can, usb, spi).
Silabs hat unter Si47xx einige AM/FM-Receiver, mit integr. DSP, die man vielleicht für Empfangsteil nehmen könnte. ------------------------------- RX-CPUs sind moment mit bis ca 2MB Flash zu bekommen. Und das bis echte 100MHz! (später sogar bis echte 200MHz). Bei den meisten anderen uCs ist das Flash wesentlich langsamer! Ich denke mit den RX kann man schon sehr viel machen. ..haben auch einige DSP-Befehle.
Sven H. schrieb: >> Also Flash in der Größenordnung ist kein Thema, aber RAM leider schon. >> 256K wäre echt mehr als perfekt. > Wir haben grade nen lpc2214 in Benutzung. Der hat intern 256k Flash und > 16k Ram. An dem ist aber extern nochmal 2mb Ram dran gepömpelt und wir > kommen locker mit einer zweilagigen Platine aus. Es gibt noch größere nicht-bga LPCs, mit bis zu 96 KB internen ram (64KB echten, 16 KB Ethernet, 16 KB USB, die man aber wenn z.B. ethernet nicht genutzt wird auch für andere sachen einsetzen kann). > Jetzt ist die Frage ob 45ns Ram reicht. Kann reichen. Stack würd sowieso besser im internen liegen und sachen die schnell sein müssen schiebt man eben auch ins interne. Wobei halt noch die Frage ist ob man überhaupt externen einsetzen sollten. > Wenn mehr Flash gebraucht wird, könnte man auch externes Flash nehmen > und den Krämpel daraus bei Systemstart ins externe Ram kopieren und das > Programm von da aus laufen lassen. Flash wird wahrscheinlich nicht das Problem sein. > Meines Wissens nach gibt es aber auch LPCs mit mehr Ram und Flash und > noch jeder Menge anderer Peripherie (i2c, can, usb, spi). z.B. LPC2388. Hat auch interessanterweise auch direkt I2s ports. Ist allerdings ein Arm7.
MCUA schrieb: > Silabs hat unter Si47xx einige AM/FM-Receiver, mit integr. DSP, die man > vielleicht für Empfangsteil nehmen könnte. Die Si47xx sind reine portable ICs für Handies und co. Die sind von den technischen Daten her her nicht mit einem Car-tuner vergleichbar. Dafür allerdings wirklich sehr einfach zu programmieren! > RX-CPUs sind moment mit bis ca 2MB Flash zu bekommen. Und das bis echte > 100MHz! (später sogar bis echte 200MHz). Bei den meisten anderen uCs ist > das Flash wesentlich langsamer! Ich denke mit den RX kann man schon sehr > viel machen. ..haben auch einige DSP-Befehle. Ich schau mir die Rx und S2h dinger mal genauer an!
Vielleicht wäre es sinnvoll vor die Si47xx bessere HF-Eing.stufen zu bauen, um die rel. hohe Komplexität der Si47xx's ausnutzen zu können. --------------------------- RX's sind krachneu, und weitere zukünftige Neuerungen werden wohl am ehesten dort rein gebaut. Es wird in Zukunft auch eine rel. grosses Spektrum dieser Chips geben, also auch von einigen EUR an.
MCUA schrieb: > Vielleicht wäre es sinnvoll vor die Si47xx bessere HF-Eing.stufen zu > bauen, um die rel. hohe Komplexität der Si47xx's ausnutzen zu können. Einige Sachen kriegt man durch Vorschalten von "Eingansstufen" nicht mehr geradegebogen oder es wäre aufwändiger als direkt einen vernünftigen CAR-Tuner zu benutzen. Ein car tuner wie die weiter oben erwähnten ist sicher einem Si47xx oder TEA5990 vorzuziehen. Die bringen meist auch noch einen Audio multiplexer und etwas Audiosignalprocessing (Equalizer, ...) oder ähnliches mit sich.
>Die bringen meist auch noch einen Audio multiplexer und etwas >Audiosignalprocessing (Equalizer, ...) oder ähnliches mit sich. Oder gleich HF-teil und ADC/DAC u. DSP u.s.w. diskret machen, dann ists auch universeller benutzbar, bzw kann auch individuell angepasst werden. (Was ja bei ner fertigen IC-Lösung nicht mehr geht)
MCUA schrieb: >>Die bringen meist auch noch einen Audio multiplexer und etwas >>Audiosignalprocessing (Equalizer, ...) oder ähnliches mit sich. > Oder gleich HF-teil und ADC/DAC u. DSP u.s.w. diskret machen, dann > ists auch universeller benutzbar, bzw kann auch individuell angepasst > werden. (Was ja bei ner fertigen IC-Lösung nicht mehr geht) Oha, das ist ein Projekt für sich und selbst nach der eigentlichen FM Demodulation noch lange nicht erledigt (weak signal handling, etc...);-) Einige Autoradio DSPs bieten allerdings auch die Möglichkeit das ZF-Spektrum nach aussen zu bringen und andere Spielereien.
Hallo, Kai G. schrieb: > Mathias A. schrieb: >> @Kai G. (xyphro), noch eine Frage am Rande: kann es sein, dass Du einmal >> für den Beck IPC@CHIP einen FAT32-Treiber portiert hast, oder verwechsle >> ich Dich da mit jemand? > > jep, genau der bin ich :-) ah, ja Dein Nick/Name kam mir gleich irgendwie bekannt vor, aber erst gestern abend kam ich drauf dass das dorther gewesen sein könnte. Ein Blick in die Sourcen (Kommentare) hat den Verdacht dann erhärtet -- also an dieser Stelle nochmal danke dafür :-) Hast Du damals eigentlich auch den Player von Thomas Kindler nachgebaut? falls ja, noch im Einsatz? Meiner läuft wie gesagt noch immer ziemlich gut, seit über 7 Jahren mittlerweile... hier mal noch ein Link dazu: http://www.adamis.de/prj/mp3/index.html ~~~ Zu dem OS-Radioprojekt noch: ich hab' jetzt noch nicht alles hier durchlesen können, aber so wie mir scheint läuft es ja auf eine Zweiteilung hinaus. Denke auch dass das das beste wäre, daher mein Vorschlag sich zunächst auf Tuner, Verstärker und Bedienteil&Gehäuse zu konzentrieren. Dafür müsste doch ein recht kleiner Controller reichen (PIC/AVR, jedenfalls ohne externen Speicher etc. sodass Hard- und Software dabei nicht soo aufwändig werden dürfte), der dann z.B. einen UART als Interface zum Rest hat. Dieser Rest könnte dann eben je nach Wunsch entweder ein größerer Controller ohne Linux, ein Linuxsystem, ein x86-PC oder was auch immer sein. Je nach dem mit im gleichen Gehäuse integriert oder nach außen verlegt (Car-PC). Was meint ihr dazu? Gruß, Mathias
Michael B. schrieb: > Kai G. schrieb: >> Also ich bin nach wie vor strickt gegen Linux. Ich bin davon überzeugt >> das es kein stabiles Gesamtsystem gibt und in einem großen Gefrickel >> endet. > > Also wir setzen Debian Stable in embedded Systeme bei unseren Kunden > ein. Die laufen dort bereits seit Jahren ohne Probleme oder Unterbrüche. > > Eine Instabilität können wir überhaupt nicht feststellen. Das > Basissystem (ohne X-Windows Server) ist extrem stabil und sehr > resourcenschonend. > 100% ACK > Von Seiten der Wartbarkeit hat sich die Modularität für uns sehr positiv > ausgewirkt. An einer grossen monolythischen Firmware ist die Wartung und > Pflege eine Sache, die zumeist von einem Spezialisten duchgeführt werden > muss, der die gesamte Firmware kennt. Mit modularen Systemen können > unterschiedliche Entwickler an verschiedenen Komponenten arbeiten. > > Aus meiner Sicht spräche aber vor allem der Punkt, dass man auf bereits > entwickelte, sehr stabile Komponenten setzen kann und nicht alles > neuentwickeln muss, für den Einsatz eines embedded Linux. Zudem können > Nutzer recht einfach weitere Komponenten für sich hinzunehmen. 100% ACK Harry
Kai G. schrieb: > (Firmware, Treiber, ...). Ich hab z.B. auch noch nie ein stabiles > Mediacenter system gesehen (VDR eingeschlossen, der DSP auf den DVB > Karten stürzt auch bei schlechtem Empfang mal gerne ab, besonders wenn > in Richtung DVB-T was macht). von wann stammen deine Erfahrungen mit VDR?....5J oder älter??? Sorry, aber, was du da schreibst, ist völliger Quatsch!!!! Mein VDR Mediacenter läuft hier seit Jahren absolut stabil! Stabilitätsprobleme gibt es beim Einsatz des Development-Branch oder bei defekter Hardware. Ein sauber aufgesetzter VDR läuft absolut stabil. Die Zeiten, wo die DSPs auf der DVB_Karte sassen ist eh vorbei. Harry
Harald L. schrieb: > Kai G. schrieb: > von wann stammen deine Erfahrungen mit VDR?....5J oder älter??? ca. 4 Jahre (DVB-T) + die Rückkehr vor ca. 1 Jahr (DVB-S) mit komplett anderer Hardware. > Sorry, aber, was du da schreibst, ist völliger Quatsch!!!! Mag sein. Es läuft aber bei mir halt nicht stabil (CTVDR und ein einziges Plugin für MediaMvp). Evtl. bin ich zu doof nen einfaches CTVDR zu installieren und es liegt an mir. Nach ein paar Wochen rumgebastel inkl. komplett neuaufsetzen auf einem echten Debian hab ich aufgegeben und jetzt schau ich halt mit meinem normalen SAT receiver fern, ohne aufzunehmen. > Mein VDR Mediacenter läuft hier seit Jahren absolut stabil! Dann sei froh! > Ein sauber aufgesetzter VDR läuft absolut stabil. Die Zeiten, wo die > DSPs auf der DVB_Karte sassen ist eh vorbei. Da fängts an: Was genau ist sauber aufgesetzt... Die DSPs sitzen bei den Full featured doch noch immer, oder vertu ich mich da?!
Harald L. schrieb: > Kai G. schrieb: >> (Firmware, Treiber, ...). Ich hab z.B. auch noch nie ein stabiles >> Mediacenter system gesehen (VDR eingeschlossen, der DSP auf den DVB >> Karten stürzt auch bei schlechtem Empfang mal gerne ab, besonders wenn >> in Richtung DVB-T was macht). > > von wann stammen deine Erfahrungen mit VDR?....5J oder älter??? > > Sorry, aber, was du da schreibst, ist völliger Quatsch!!!! > > Mein VDR Mediacenter läuft hier seit Jahren absolut stabil! > > Stabilitätsprobleme gibt es beim Einsatz des Development-Branch oder bei > defekter Hardware. > > Ein sauber aufgesetzter VDR läuft absolut stabil. Die Zeiten, wo die > DSPs auf der DVB_Karte sassen ist eh vorbei. > > Harry Ich glaube wir sollten auf weitere Diskussionen verzichten. Die einen haben gute, die anderen schlecht Erfahrungen gemacht. Jetzt wird es vermutlich zweigleisig laufen und somit m.E. ein guter Kompromiss gefunden.
> (Firmware, Treiber, ...). Ich hab z.B. auch noch nie ein stabiles > Mediacenter system gesehen (VDR eingeschlossen, der DSP auf den DVB > Karten stürzt auch bei schlechtem Empfang mal gerne ab, besonders wenn > in Richtung DVB-T was macht). Solche sachen werden über Car-PC's gesagt. Meiner läuft jedeoch seit über 4 Jahren Problemlos und Störungsfrei. Einzig die On-Screen-Tastatur (wird bei Navi-Eingabe oder bei MP3 Suche eingeblendet) macht hin und wieder Probleme. Wobei das eher nach einem Bug in der Front-End Software aussieht. Das wird schon. ;)
Kai G. schrieb: >> Ein sauber aufgesetzter VDR läuft absolut stabil. Die Zeiten, wo die >> DSPs auf der DVB_Karte sassen ist eh vorbei. > > Da fängts an: Was genau ist sauber aufgesetzt... keine unnötigen Dienste, nur stabile Plugin (da gibts leider einige Ausreisser) kein X...zuverlässige Hardware...etc...aber, ich geb auch zu, daß die meisten Anfänger damit überfordert sein dürften. > Die DSPs sitzen bei den Full featured doch noch immer, oder vertu ich > mich da?! Das ist zwar richtig, jedoch spielen diese Full featured Karten praktisch keine Rolle mehr, da heute jeder Single-Kern-Atom ausreichend Leistung hat, um selbst ein HD-Signal zu dekodieren. Harry
Hallo Zunächst einmal: Was immer Ihr auch macht, ob nun Linux oder nicht, ich find es klasse! Unsere Erfahrungen mit Linux sind eben (wie oben beschrieben) sehr positiv. Wichtig ist vor allem, keine exzentrische Hardware zu nehmen, da da vielleicht die erhältlichen Treiber nicht ausgereift sind. Das wird wohl auch der Grund für die Erfahrungen mit instabilen Mediacentern sein. Schlechte Treiber bringen aber auch einen Mikroprozessor zum Absturz. Da tut sich dazwischen nichts. Der Vergleich mit dem Mediacenter ist also eigentlich aussagelos. Für Linux gilt, dass das Basis-System, so wie es Harry beschrieben hat, EXTREM stabil ist. Je mehr Hardware man nun anfügt, desto mehr Treiber müssen entweder geschrieben oder aus dem bestehenden Repertoire genutzt werden, und desto höher ist das Risiko, Fehler im Treiber zu haben (die im unglücklichsten Falle zu einem Absturz führen können). Das gilt natürlich ebenfalls für ein reines Mikrocontroller-Board. Wenn Ihr da Treiber für den Screen, für das Radio, für WLAN, Bluetooth und TCP/IP-Stack schreiben wollt, dann können (und werden) sich da auch Fehler einschleichen, die auch zum Absturz des Systems führen können. Bei Linux ist eben der Vorteil, dass viele Komponenten bereits vorhanden sind und davon die meisten auch eine gute Qualität haben und ausgereift sind. Bei diesen schätze ich die Wahrscheinlichkeit eines Absturzes deutlich geringer ein, als wenn man die selber implementiert (auch auf einem Mikrocontroller). Was das Thema "Skripte etc" angeht: Das ist doch ein grosser Vorteil. Die Skript-Programmierung ist sehr viel einfacher als ein C-Compiler oder gar Assembler-Code. Damit können (einfache funktionale) Änderungen ohne viel Expertenwissen leicht vorgenommen werden. Viele unserer Systeme sind in Python programmiert. (Die Treiber im Kernel natürlich in C.) Aber die ganze Diskussion führt ja zu nichts. Es sind ja alle Vor- und Nachteile ausführlich diskutiert worden. Ich denke, es ist jetzt Zeit, dass eine Entscheidung getroffen wird und dann einfach in diese Richtung weiter gearbeitet wird. Da Kai der Initiator dieses Projektes ist, sollte er, meiner Meinung nach, diese Entscheidung treffen und dann geht es dahin weiter. Alle anderen Wünsche etc. sollten dann in ein anderes Projekt. Viele Grüsse Michael
> Also etwas in der Größenordnung von 64/96 KB ist kein Problem und wäre > erfahrungsgemäß genug für solch ein Radio. Allerdings wäre es schön doch > noch etwas mehr zu haben. Wenn wir allerdings echt Codec/Radio in 2 uCs > splitten würde etwas in der 64 KB Größenordnung sicher voll und ganz > reichen. Bist du da sicher? Mein Eindruck ist das gaengige MP3 Player alle ein Problem mit der maximal moeglichen Dateianzahl haben. Und die Ursache duerfte wohl im Ram liegen. Ich meine ich koennte vermutlich damit leben wenn man nur 1GB mit MP3 Dateien benutzen koennte. Aber hier waren doch Leute die wollten unheimlich total viele MP3s in so einer Kiste haben. Ausserdem waere es doch schon schoen wenn man wenigsten die komplette FAT der Speicherkarte im Ram halten koennte. Ich weiss es geht auch anders, waer IMHO netter. > Kann man das gesamte System nicht soweit modularisieren, so dass beide > Fraktionen (Non-Linux, Linux) möglichst viel Überschneidungen haben? Man kann es auf Schaltplanlevel und auf Firmwarelevel modularisieren. Aber Kai will ja eine Basisplatine auf der schon das Grundkonzept drauf ist. Was ich auch fuer vernuenftig halte. Wer also dann Teile fuer eine andere Sache braeuchte, der muesste sich dann eine FM-Radioplatine selber machen. > Es gibt noch größere nicht-bga LPCs, mit bis zu 96 KB internen ram (64KB > echten, 16 KB Ethernet, 16 KB USB, die man aber wenn z.B. ethernet nicht > genutzt wird auch für andere sachen einsetzen kann). Es gibt von Renesas IMHO auch schon recht schlichte M16er mit 128kb Ram. Und Flash ist sowieso kein Problem. Da hat man ja nie weniger als 256-512kb. Das bekommt nie voll. Allerdings sind das alles CPUs die fuer industrielle Steuerungen gedacht sind. (z.b Motorsteurung) Man brauchte aber eine CPU die schnell genug ist die Daten von SD zu lesen, MP3 zu dekodiern und mindestens noch ein I2S Interface hat um die Daten dann richtung DA-Wandler zu schubsen. Und dann haben wir noch keine Filtern, Mischung und aehnliches durchgefuehrt. BTW: Ich gehe mal davon aus das Balance, Faden, Bass usw in Software gemacht werden soll und nicht mit einem analogen AutoradioIC? Ich wuerde dann mal folgendes vorschlagen: 1. Ein spezieller Controller der sich um LCD, Tastatur, Encoder usw kuemmert. Leistungsklasse etwa M16C/29 oder was es da von AVR in der Liga geben mag. Der muss auch ein bisschen Ram haben weil er ja z.B Liedtitel darstellen muss und hier sollten auch Grafikelemente und aehnliches liegen. Dieser Prozessor redet mit dem Hauptprozessor ueber I2C, SPI oder RS232. Er ist der eigentlich Boss der entscheidet was jetzt gerade ablaeuft. Daher kann er auch einfach durch was ganz anderes ersetzt werden und man kann den ganzen Rest der Hardware durch was anderes ansteuern. 2a. Ein moeglicht potenter Hauptprozessor der die Daten von der SD holt und die MP3 dekodierung durchfuehrt. Frage: Ich gehe mal davon aus das die FM-Daten analog aus dem Tuner kommen. Dann muessten sie hier auch digitalisiert werden. Die Ausgangsdaten werden dann ueber I2S rausgeworfen. 2b. Ein durschnittlicher Prozessor der mit der SD Reden kann aber einen externen MP3-Decoder braucht. Spart vermutlich eine Menge Arbeit, aber nicht so elegant. 3. Ein weiterer Prozessor nimmt die I2S-Daten und kuemmert sich um Lautstaerke, Fading, Klangregelung und gibt es dann an die DA-Wandler. Fuer den Prozessor unter Punkt3 habe ich derzeit keine Vorstellung. Von der Idee her erwartet man da natuerlich als erstes einen DSP, aber es sollte halt eine brauchbare Entwicklungsumgebung mit C-Compiler fuer umsonst geben. Ist schon eine Weile her das ich einen DSP in Assembler programmiert habe und ich war nicht so angetan. :-) Auf diese Weise laesst sich alles in sechs getrennte Aufgaben aufteilen, die obigen drei und zusatzlich noch Tuner, Spannungsversorgung, Audioverstaerker. Olaf
Harald L. schrieb > Das ist zwar richtig, jedoch spielen diese Full featured Karten > praktisch keine Rolle mehr, da heute jeder Single-Kern-Atom ausreichend > Leistung hat, um selbst ein HD-Signal zu dekodieren. bei weitem nicht. wohl eher, das die GPUs mitlwerweile genug rechenleistung haben die CPU dabei zu unterstützen. Wobei man fährer weise auch sagen muss, es kommt immer darauf an wie HD codiert wird. bei h.264 mit einem sigelcore Atom aber sicher nicht. Mit ION board sicher machbar, nur das stabil stell ich mal in frage (c't hat das damals in einem test als nicht stabil bezeichnet, bzw mit viel aufand aufgesetzt werden muss) wenn doch bitte ich um den gegenbeweis mit link. grus
Hallo zusammen, vielleicht kann ich noch was zum Gehäuse beitragen. Schaut mal hier die CarPC's an. Die Gehäuse werden aus ganz normalen Belch gefertigt, gelasert und gebogen. http://www.delta-components.com/products/mobile_carpc_muenchen.htm Die Gehäuse werden in "kleinen" Serien gefertigt 100 Stück. Das kostet nicht die Welt. Meiner Meinung nach, sollte das "drum herum" als erstes entwickelt werden, sobald klar ist welche Funktionen integriert sein sollen. Für den DIN Schacht gibt es immer hin auch Vorschriften (Positionen von Steckern, Wärmeabfuhr vom Gehäuse, usw.). Mit dem Massen die das Gehäuse dann hat kann man die Platine, bzw. Platinen ableiten. Sonst hat man viel Zeit in ein Layout gesteckt und muss es dann noch mal machen weil nichts passt. Zudem sollte jemand mal eine "Projektplanung" machen, aufteilen der einzelen Schritte usw. Sonst stehen hier dann schluss endlich 1000 Beiträge und ein Radio gibts immer noch nicht.
Olaf Kaluza schrieb: > 2a. Ein moeglicht potenter Hauptprozessor der die Daten von der SD holt > und die MP3 dekodierung durchfuehrt. Vorteil: Man ist offen für zukünftige Standards oder auch aktuelles wie zum Beispiel Ogg. > Frage: Ich gehe mal davon aus das die FM-Daten analog aus dem Tuner > kommen. Dann muessten sie hier auch digitalisiert werden. Ist das notwendig? Am Ende muss es doch sowieso wieder Analog sein. Oder hast Du mit den Daten noch etwas spezielles vor?
... schrieb: > vielleicht kann ich noch was zum Gehäuse beitragen. > Schaut mal hier die CarPC's an. Danke;) Schöner kann man die Problematik wirklich nicht rüberbringen. Super Design, besonders der Drehknopf am Modell Berlin, der ist einsame Spitze. Oliver
Vielleicht könnte man sich dahingehend einigen, die Hardware ausreichend gross zu dimensionieren, um den Einsatz von Linux möglich zu machen. Es scheint ja wohl darauf hinauszulaufen, daß es 2 Software-Ansätze für diese Hardware gibt. Treiber könnten innerhalb einer gemeinsamen Code-Basis entwickelt werden. Ich denke, daß mit diesem Ansatz allen gedient währe. Harry
Audi macht das mit WLAN und Bluetooth neuerdings auch: http://www.basicthinking.de/blog/2010/05/25/audi-a8-auf-der-internet-ueberholspur-mit-wlan-ab-werk/
Olaf Kaluza schrieb: > Bist du da sicher? Mein Eindruck ist das gaengige MP3 Player alle > ein Problem mit der maximal moeglichen Dateianzahl haben. > Und die Ursache duerfte wohl im Ram liegen. Mit intelligenten Konzepten klappt es auch mit vielen Dateien. Ich kenne da 2: 1.) Wenn man eine sortiere Fileliste im Speicher halten will braucht man nicht den Dateinamen, sondern es reicht aus -FAT sei dank- den Startsektor zu speichern. Das ist eindeutig und lässt sich dann wieder in einen Dateinamen auflösen. Das klappt natürlich nur so lange, wie man die Möglichkeit hat an den Filesystem "Treibern" selbst zu basteln. 2.) Man kann einen Quicksort algorithmus implementieren und immer das aktuelle Verzeichnis nach dem nächst"höheren" oder nächst"kleineren" Dateinamen durchsuchen lassen. Das geht rasend schnell, auch mit langen Dateinamen. Die Optimierte Variante wäre immer eine Anzahl von z.B. 10 Dateinamen im Speicher zu halten. Vorteil: Absolut unbegrenzt in der Dateianzahl. Beides hab ich shcon mal realisiert und klappt echt prima. Selbst bei Variante 2 merkt man nicht das im Hintergrund verdammt viel I/O passiert. Parallel MP3 Abspielen ist auch noch mit Möglichkeit 2 Möglich. Ansonsten unterstütze ich aber stark den Drang nach mehr Speicher, solche Kunstgriffe sind nicht immer schön. Wenn sich also was schönes finden läßt (muss mir noch immer Deine vorgeschlagenen uCs anschauen, mach ich heute Abend)... > Ich meine ich koennte vermutlich damit leben wenn man nur 1GB mit MP3 > Dateien benutzen koennte. Aber hier waren doch Leute die wollten > unheimlich total viele MP3s in so einer Kiste haben. > Ausserdem waere es doch schon schoen wenn man wenigsten die komplette > FAT der Speicherkarte im Ram halten koennte. Ich weiss es geht auch > anders, waer IMHO netter. Ja, sicher schön, aber so eine FAT kann recht groß werden. Caching ist doch auch kein Problem, oder. Man kann im Filesystem treiber 2 caches implementieren. Einer für FATs, einer für anderen Kram. > Man kann es auf Schaltplanlevel und auf Firmwarelevel modularisieren. > Aber Kai will ja eine Basisplatine auf der schon das Grundkonzept drauf > ist. Was ich auch fuer vernuenftig halte. Wer also dann Teile fuer eine > andere Sache braeuchte, der muesste sich dann eine FM-Radioplatine > selber machen. Ja, in einem Autoradio den tuner modular zu machen hat denk ich nicht viel sinn weil ein FM Empfänger halt schon eine Grundfunktion von einem Autoradio ist. Selbigest trifft denk ich auch auf MP3 zu. > Es gibt von Renesas IMHO auch schon recht schlichte M16er mit 128kb Ram. > Und Flash ist sowieso kein Problem. Da hat man ja nie weniger als > 256-512kb. Das bekommt nie voll. Stimmt, solange man nicht 200 Icons mit ablegt ;-) > Allerdings sind das alles CPUs die fuer industrielle Steuerungen gedacht > sind. (z.b Motorsteurung) Man brauchte aber eine CPU die schnell genug > ist die Daten von SD zu lesen, MP3 zu dekodiern und mindestens noch ein > I2S Interface hat um die Daten dann richtung DA-Wandler zu schubsen. > Und dann haben wir noch keine Filtern, Mischung und aehnliches > durchgefuehrt. Mischen, Filtern und so kann der Car "tuner". > BTW: Ich gehe mal davon aus das Balance, Faden, Bass usw in Software > gemacht werden soll und nicht mit einem analogen AutoradioIC? Wäre machbar, allerdings würde das je nachdem welchen AuroradioIC man nimmt intern sowieso auch wieder digital laufen, also nicht viel anders. > 1. Ein spezieller Controller der sich um LCD, Tastatur, Encoder usw > kuemmert. Leistungsklasse etwa M16C/29 oder was es da von AVR in der > Liga geben mag. Der muss auch ein bisschen Ram haben weil er ja z.B > Liedtitel darstellen muss und hier sollten auch Grafikelemente und > aehnliches liegen. Evtl. wäre es sinnvoll (der Geschwindigkeit wegen) ein direktes Interface vom Haupt uC zum Display zu machen. > Dieser Prozessor redet mit dem Hauptprozessor ueber I2C, SPI oder RS232. > Er ist der eigentlich Boss der entscheidet was jetzt gerade ablaeuft. > Daher kann er auch einfach durch was ganz anderes ersetzt werden und man > kann den ganzen Rest der Hardware durch was anderes ansteuern. Prima! > 2a. Ein moeglicht potenter Hauptprozessor der die Daten von der SD holt > und die MP3 dekodierung durchfuehrt. > Frage: Ich gehe mal davon aus das die FM-Daten analog aus dem Tuner > kommen. Dann muessten sie hier auch digitalisiert werden. Digitalisieren ist nicht unbedingt nötig wenn man einen externen Audio-Multiplexer hat. > 2b. Ein durschnittlicher Prozessor der mit der SD Reden kann aber einen > externen MP3-Decoder braucht. Spart vermutlich eine Menge Arbeit, aber > nicht so elegant. Ein Arm7 mit 60 MHz würde reichen, wäre aber trotzdem für was Leistungsstärkeres. > 3. Ein weiterer Prozessor nimmt die I2S-Daten und kuemmert sich um > Lautstaerke, Fading, Klangregelung und gibt es dann an die DA-Wandler. > Fuer den Prozessor unter Punkt3 habe ich derzeit keine Vorstellung. Von > der Idee her erwartet man da natuerlich als erstes einen DSP, aber es > sollte halt eine brauchbare Entwicklungsumgebung mit C-Compiler fuer > umsonst geben. Ist schon eine Weile her das ich einen DSP in Assembler > programmiert habe und ich war nicht so angetan. :-) Ein DSP wäre evtl. auch wegen der Verfügbarkeit nicht gerade von Vorteil. Das ist meist recht exotisches zeugs. > Auf diese Weise laesst sich alles in sechs getrennte Aufgaben aufteilen, > die obigen drei und zusatzlich noch Tuner, Spannungsversorgung, > Audioverstaerker. ACK!
Mathias A. schrieb: > ah, ja Dein Nick/Name kam mir gleich irgendwie bekannt vor, aber erst > gestern abend kam ich drauf dass das dorther gewesen sein könnte. Ein > Blick in die Sourcen (Kommentare) hat den Verdacht dann erhärtet -- also > an dieser Stelle nochmal danke dafür :-) Schön zu sehen das mein Code noch aktiv benutzt wird ;-) Dann war die Arbeit nicht ganz umsonst. > Hast Du damals eigentlich auch den Player von Thomas Kindler nachgebaut? > falls ja, noch im Einsatz? Meiner läuft wie gesagt noch immer ziemlich > gut, seit über 7 Jahren mittlerweile... hier mal noch ein Link dazu: > http://www.adamis.de/prj/mp3/index.html Sieht nett aus. Ich hatte eine eigene Version von den KreaPC Player gemacht, die allerdings zwischendurch dem Bastelwahn zum Opfer gefallen ist und alle Teile mittlerwelie in anderen Projekten verbaut wurden ;-(
Harald L. schrieb: > Vielleicht könnte man sich dahingehend einigen, die Hardware ausreichend > gross zu dimensionieren, um den Einsatz von Linux möglich zu machen. Wie würden denn die Anforderungen an RAM/ROM ausshenen (mal z.B. einfach von einem ARM9 ohne MMU ausgegangen)? Ansonsten gäb es halt noch die erwähnte remote möglichkeit, 2 Projekte, CarPc steuert CarRadio fern.
... schrieb: > vielleicht kann ich noch was zum Gehäuse beitragen. > Schaut mal hier die CarPC's an. Die Gehäuse werden aus ganz normalen > Belch gefertigt, gelasert und gebogen. > http://www.delta-components.com/products/mobile_carpc_muenchen.htm > Die Gehäuse werden in "kleinen" Serien gefertigt 100 Stück. Das kostet > nicht die Welt. Gibts da evtl. Kontakte zu firmen? > Zudem sollte jemand mal eine "Projektplanung" machen, aufteilen der > einzelen Schritte usw. Sonst stehen hier dann schluss endlich 1000 > Beiträge und ein Radio gibts immer noch nicht. Vorher sollten wir grob abstecken wie das Interface zwischen den 2 Interessengruppen liegt, sofern es eins gibt.
Kai G. schrieb: > Harald L. schrieb: >> Vielleicht könnte man sich dahingehend einigen, die Hardware ausreichend >> gross zu dimensionieren, um den Einsatz von Linux möglich zu machen. > > Wie würden denn die Anforderungen an RAM/ROM ausshenen (mal z.B. einfach > von einem ARM9 ohne MMU ausgegangen)? > > Ansonsten gäb es halt noch die erwähnte remote möglichkeit, 2 Projekte, > CarPc steuert CarRadio fern. 2 Projekte halte ich nicht für sinnvoll. Eine Hardwareplattform und 2 alternative Software-Ansätze wär doch ok! ich will ja keinen kompletten Car-PC (dann wär ich auch in einem anderen Forum) - Ich will Linux in meinem Autoradio, um das nach meinen Vorstellungen anpassen zu können. Ohne die Möglichkeit Linux zu verwenden, wär das Projekt für mich uninteressant. HW-Vorraussetzung: * 32bit-CPU mit MMU GCC-Toolchain MUSS verfügbar sein; Windows-Tools vom Hersteller sind für mich absolut unbrauchbar, da ich meine Software unter Linux entwickel. Ausserdem wär das kein "OpenSource-Autoradio", wenn schon der Compiler nicht OpenSource ist. * 2 MB Ram * 16MB Flash Notfalls würde bei Ram und Flash auch die Hälfte reichen, aber so hätte man mehr Luft für zukünftige Entwicklungen. Mehr darf es natürlich immer sein. Harry
Harald L. schrieb: > 2 Projekte halte ich nicht für sinnvoll. > Eine Hardwareplattform und 2 alternative Software-Ansätze wär doch ok! Naja, wenn dann vorschläge wie externer Kopfstützenmonitor für Kinder kommt und so, dann wird aber auch die Hardwareplattform schon extrem anders aussehen. > * 32bit-CPU mit MMU > GCC-Toolchain MUSS verfügbar sein; Windows-Tools vom Hersteller sind für > mich absolut unbrauchbar, da ich meine Software unter Linux entwickel. > Ausserdem wär das kein "OpenSource-Autoradio", wenn schon der Compiler > nicht OpenSource ist. Klar, was sollte gegen gcc sprechen. Ist eine MMU wirklich unbedingt nötig? > * 2 MB Ram > * 16MB Flash > Notfalls würde bei Ram und Flash auch die Hälfte reichen, aber so hätte > man mehr Luft für zukünftige Entwicklungen. Mehr darf es natürlich immer > sein. Puh, das ist eine Menge und würd auf jeden fall Richtung externes Flash/Ram gehen. Ich dachte eher über kB, statt Mb nach...
Als Projektmanagmentsystem würde sich das webbasierte System Redmine anbieten. http://www.redmine.org/ Beide Fraktionen wollen das gleiche! Sauber programmierte Basissoftware die einen vor Problemen bewahren soll. Die Linux Seite hat den Vorteil das nach kleinen Anpassungen des Kernel eine gute Schnittstelle zur verfügung steht welche ein leichtes einarbeiten ermöglicht. Wenn man aber das Ganze auf mehrere Controller aufsplittet hat es den Vorteil es ist einfaches Layout möglich. (nur QFP Gehäuse)Die Software kann einfach auf mehrere Teilkomponenten aufteilen. Nachteil man muss die HW wirklich kennen für jede änderung außer man schreibt ein art OS -> mehr Aufwand als Kernel. Als DSP würden sich die Blackfins anbieten, sie werden vom GCC unterstützt und haben LQFP Gehäuse oder der kleinere Bruder ADSPxx . MFG Patrick
Kai G. schrieb: >> * 2 MB Ram >> * 16MB Flash >> Notfalls würde bei Ram und Flash auch die Hälfte reichen, aber so hätte >> man mehr Luft für zukünftige Entwicklungen. Mehr darf es natürlich immer >> sein. > > Puh, das ist eine Menge und würd auf jeden fall Richtung externes > Flash/Ram gehen. Ich dachte eher über kB, statt Mb nach... Da kann aber ein einsamer Programmierer lange dran rum programmieren ;-)
Kai G. schrieb: > Naja, wenn dann vorschläge wie externer Kopfstützenmonitor für Kinder > kommt und so, dann wird aber auch die Hardwareplattform schon extrem > anders aussehen. man wird ja wohl noch träumen dürfen ;)...aber andererseits reicht eine Ethernetschnittstelle um sowas nachzurüsten. Und Ethernet halte ich eh für Pflicht. > > Klar, was sollte gegen gcc sprechen. > Ist eine MMU wirklich unbedingt nötig? > >> * 2 MB Ram >> * 16MB Flash >> Notfalls würde bei Ram und Flash auch die Hälfte reichen, aber so hätte >> man mehr Luft für zukünftige Entwicklungen. Mehr darf es natürlich immer >> sein. > > Puh, das ist eine Menge und würd auf jeden fall Richtung externes > Flash/Ram gehen. Ich dachte eher über kB, statt Mb nach... Linux mit einigen kB geht nicht.....ohne MMU geht das zwar, ist aber ein extremer Krampf, und eigentlich auch nicht mehr zeitgemäss. Das Flash könnte man ggf. als CF-Kartenslot einbauen. Harry
Bitte 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.