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

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.

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.

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 ;-)

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.

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.

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.

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...

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

> 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.

> 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. .-)

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!

Du kannst auch einfach einen Artikel hier im (Foren)Wiki erstellen.

Genau das meinte ich damit auch ;-)

Kai G. aus B. bei H. ????

Falls ja, dann meld dich mal wieder.

Gruß virus

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

> 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 ;-)

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...

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

> 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/sh72...

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...

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

> 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.

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

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!

Hallo,
das Wiki ist online, und unter http://osar.it-livetalk.de erreichbar!

Harry

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

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...

Ich denke auch das es sich langsam eher in 2 Projekte entwickelt.

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

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.d...
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.d...
> 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.).

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/...

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/...
>
> 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.

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.

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.

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 ;-)

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

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.

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).

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!

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.

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.

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

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?

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

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_ca...
> 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

Sven H. schrieb:
> 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 ;-)

Die "Selbstprogrammierer" müssen das RAM ja nicht bestücken...

Für Linux ist das Vorraussetzung.

Harry

Sven H. schrieb:
>> 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 ;-)

Mit Linux scheinbar schon ;-)
Wenn man sagen wir mal so etwa 128KB RAM hat braucht man keine
Kunstgriffe mehr, ohne Linux.

Patrick Weinberger schrieb:
> 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.

Ob ich mit einem Kernel header file arbeite oder mit einem
spi.h/i2c.h/xyz.h von "irgendwoanders" ist doch kein großer Unterschied.

Die Build Umgebung und das nötige Wissen um mit Linux was zu machen ist
doch viel komplexer. Für jemand der seit Jahren nichts anderes macht
gut, aber für den normalen 0815-WinAVR Programmierer dürfte die andere
Lösung deutlich einfacher sein.

> 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.

Ein HAL reicht schon voll und ganz und den würde man so oder so bauen.
Ich brauch keinen echten Treiber mit Device handles und co.

Kai G. schrieb:
> Sven H. schrieb:
>>> 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 ;-)
>
> Mit Linux scheinbar schon ;-)
> Wenn man sagen wir mal so etwa 128KB RAM hat braucht man keine
> Kunstgriffe mehr, ohne Linux.

Ich glaube nicht, daß ich der Einzige bin der so denkt, aber ohne die
Möglichkeit ein Linux auf das Radio zu bringen, wär das Projekt für mich
absolut uninteressant. Ich seh da keinen Mehrwert zu käuflichen
Lösungen.

Ausserdem ist die Hardware inzwischen so billig geworden, daß es
ohneweiteres vertretbar ist, die Hardware deutlich überzudimensionieren.

Son Radio ist ohnehin nicht in ein paar Monaten aufgebaut. Das wird ne
grössere Baustelle.

Daher meine ich, daß man sich auch bei den Möglichkeiten (Software) eher
am "Morgen", als am "Heute" orientieren sollte. Ansonsten laufen wir
Gefahr, daß das Gerät schon veraltet ist, bevor der 1. Prototyp läuft.

Harry

Warum immer lang alles neu machen ?
Man kann ja mal bei anderen Projekten fragen wegen unterstützung.
Mir fällt da das Beagleboard ein.
Gibt sicher noch andere...

Für die ohne Linux:
Bevor wir jetzt noch mal alle unsere Wunschliste posten, sollten wir
eine wiki Seite anlegen (intern/extern), wo alles aufgelistet wird und
anschließend mit Strichen gewählt wird. Sonst verlieren sich die Wünsche
im Sande.

Für die Leute mit Linux gibt es schon eine: http://osar.it-livetalk.de,
die sollten ebenso wählen

Ich denke, das wichtigste ist im Moment, sich auf eine Hardwareplatform
zu einigen, mit der beide Fraktionen leben können.

Sowas wie das Beagleboard find ich gar nicht so übel, und als "Overkill"
seh ich das auch nicht. Reserven zu haben kann ganz sicher nicht
schaden.

Aber in dem Punkt will ich mich nicht festlegen, solange Linux darauf
läuft ohne grosse Verrenkungen machen zu müssen.

Hi, was mir gerade noch bzgl. der Bedienung einfällt:

Die Bedienung mit zwei Drehgebern gefällt mir, warum nicht den
nicht-Lautstärke-Drehgeber mit einem Steuerkreuz erweitern?

Also ähnlich wie die Mittelkonsolenbedienung in verschiedenen Audis,
also:

- Drehen
- Drücken
- Schieben (oben, unten, rechts, links)

Wo es solche Bedienelemente zu kaufen gibt, weiß ich nicht. Allerdings
kann ich mir mit etwas Geschick auch einen Eigenbau vorstellen:

Drehgeber auf eine Platine, die mit einer weiteren mit einem flexiblen
Element verbunden (Sandwich) ist. Dort befinden sich 4 Taster, die je
nach Kippen geschlossen werden. Problematisch: Durch hineindrücken
können bei druckelastischer Verbindung die Taster fehlerhaft ausgelöst
werden.

Um das Problem zu umgehen (und wahrscheinlich auch einen besseren
Druckpunkt zu bekommen) könnte man die Taster stehend an einer Platine
befestigen, die auf die Achse des Drehgebers angebracht wird, also in
etwa so:

+-----+
|  #  |
|# o #|
|  #  |
+-----+

#: Taster
o: Achse des Drehgebers

Bei der Bedienung könnte ich es mir wie folgt vorstellen:
Drehen: (fällt mir gerade nix ein)
Rechts/Links: Titel vor/zurück
Oben/Unten: Album vor/zurück
Drücken: Titelmenü

im Titelmenü, Beispiel Titelsuche:
Drehen: Buchstabe auswählen
Rechts/Links: Position
Oben/Unten: Suchart (Titel, Interpret, Album, Genre)
Drücken: Suche starten

Noch ein Einfall:

Anbindung an den Infotainment-Bus?
Sprich: Anbindung an die Lenkradfernbedienung und das Infodisplay (oder
HUD ;)) zwischen den Tachos, haben ja mittlerweile nahezu alle Autos
(zumindest als Sonderausstattung)

Aber OMAP ist für die Firmware bastler nicht wirklich was weil er schon
komplex wird, aber ich finde das ist die beste MPU mit echt Zukunft für
so ein Projekt.

MFG

Patrick Weinberger schrieb:
> Aber OMAP ist für die Firmware bastler nicht wirklich was weil er schon
> komplex wird, aber ich finde das ist die beste MPU mit echt Zukunft für
> so ein Projekt.
>
> MFG

ACK

Ich muss ehrlich zugeben ich hab mal nach einer alternative zum OMAP
gesucht aber das lässt sich ned viel finden.
Entweder man muss min 5000 Prozessoren nehmen oder teure Software dafür.
Von Renesas gibts was in die Richtung und die anderen ähnlichen
verdächtigen.
EMV mäßig haben sie auch Vorteile mit der PoP technologie. Wo direkt
über dem Prozessor der RAM montiert wird. Der Flash kann dann langsamer
getaktet werden.

MFG

Wie wärs denn, wenn man eine "kleine" CPU mit den Abmessungen und
Anschlüssen des Beagleboard (identische Abmessungen und Lage der
Stecker) designen würde, was dann Huckepack auf die Hauptplatine kommt.
Dann kann jeder selbst entscheiden, ob er ein Beagleboard, oder eine
einfachere CPU haben möchte.

Das würde ja dem Modul-Gedanken auch sehr entgegen kommen.

Harry

Naja Beagleboard selbst ist in meinen Augen ungeeignet. Weil es nicht
für Audio ausgelegt ist. Daher würd ich mich mal eher mit den
Entwicklern des Beagleboards zusammenschließen. Denn da ist das Know-How
für so ein vorhaben da (erfahrung mit dem Layout für so ein Monster).
Alternativ würde vielleicht das IGEPv2 gehen. Das Problem ist das nur 2
I2S Schittstellen zur verfügung stehen bei dem Beagleboard oder IGEPv2.
Wobei die OMAP Serie 5 zur Verfügung stellt.

Mal ein Beispiel:

Bluetooth einen I2S
Verstärker einen I2S
LineIn/AUX und Cinch Ausgang einen I2S
dann vielleicht noch ein oder 2 Mikrofone einen I2S
dann will noch einer SPDIF bedeutet auch wieder einen I2S


also würden Fast alle I2S benötigt

MFG

Patrick Weinberger schrieb:
> Bluetooth einen I2S

Die Bluetoothmodule die ich so gesehen habe haben alle einen rein
analogen Eingang. Das vereinfacht den Entwicklern der Module so einiges,
denn Sie müssen keinen Samplerateconverter entwickeln, erst recht keinen
der verschiedene Sampleraten und UP/Down conversion unterstützt.

> Verstärker einen I2S

Verstärker sind normalerweise analog. Selbst neuere Sigma-Delta
Verstärker (Class D) haben nur einen analogen Eingang.

> LineIn/AUX und Cinch Ausgang einen I2S

LineIn/Aux und Chinch Ausgang ist auch etwas rein analoges, wieso sollte
man den Umweg über AD/DA gehen?

Patrick Weinberger schrieb:
> Naja Beagleboard selbst ist in meinen Augen ungeeignet. Weil es nicht
> für Audio ausgelegt ist. Daher würd ich mich mal eher mit den
> Entwicklern des Beagleboards zusammenschließen. Denn da ist das Know-How
> für so ein vorhaben da (erfahrung mit dem Layout für so ein Monster).

es muss ja nicht das Beagleboard sein.
Ausserdem hatten wir bereits diskutiert, daß wir die Audiofunktionen
nicht in der HauptCPU machen, sondern für die HiFi-Freaks optional ein
DSP-Modul vorsehen.
Die von der Firmware-Fraktion bevorzugten CPUs wären damit sicher
überfordert.

> Alternativ würde vielleicht das IGEPv2 gehen. Das Problem ist das nur 2
> I2S Schittstellen zur verfügung stehen bei dem Beagleboard oder IGEPv2.
> Wobei die OMAP Serie 5 zur Verfügung stellt.
>
> Mal ein Beispiel:
>
> Bluetooth einen I2S
> Verstärker einen I2S
> LineIn/AUX und Cinch Ausgang einen I2S
> dann vielleicht noch ein oder 2 Mikrofone einen I2S
> dann will noch einer SPDIF bedeutet auch wieder einen I2S
>
>
> also würden Fast alle I2S benötigt

Das wäre aber auch das KO-Argument für Linux. Ich stell es mir schwierig
vor, in einer selbstgeschriebenen Firmware 5 Audiostreams(alle
mehrkanalig) zu bedienen.

Die Audio-Möglichkeiten liessen sich auch noch ganz anders erweitern:
Würde ich mir heute an so einem Radio einen Zusatzverstärker
anschliessen wollen, würde ich mir ein USB-Kabel in den Kofferraum
legen, und dort einen USB_Audio-Stick verwenden. Das ergibt kurze
Audio-Leitungen, und wenig Störungen. (Ich liebe die Dinger, und
verwende die auch, um meinen PC-Sound über die HiFi-Anlage wiederzugeben
- Der hat sogar S/PDIF)

Harry

Also, meine Meinung um eine Lösung für die 2 Lager zu finden:

Ich denke man wird nicht so einfach alles unter einen Hut bekommen, das
haben auch schon viele andere hier gesagt.

Meiner Meinung nach sollte man ein Basis Autoradio entwickeln das sich
über eine API steuern lässt (z.B. über RS232) und auch ohne
Display/Tasten arbeitet. Dazu kann in die echte linuxfreie
Autoradiofirmware ein startup check erfolgen der testet ob ein
Display/TastenuC angeschlossen ist und wenn nicht, dann arbeitet es in
einem reinen API Modus.

Basierend auf dem System kann die Car-PC Fraktion das Multimediasystem
entwickeln. Man kann von mir aus z.B. vorsehen ein vorgegebenes Modul in
die Platine des Basis Autoradio zu stöpseln, wenn es nicht gerade die
Ausmasse von einem A5 Blatt oder so hat. Wobei das Radio an sich flach
sein wird und der Platz nicht so sehr begrenzt ist, abgesehen von der
Endstufe und der Spannungsversorgung.

Da sich das Autoradio auch ohne Display/Tasten betreiben lässt bleibt
dann den Leuten die Linux + Touch panel haben wollen etwas nach eigenen
Vorstellungen zu entwickeln ohne die Möglichkeit zu rauben von dem
Autoradio an sich zu profitieren.

Das entkoppelt die Arbeit immens und generell entspricht das doch auch
eher der angesprochenen Modulbauweise. In einen PC steckt man doch auch
eine TV-Tunerkarte. OK, hier ist es umgekehrt, aber im Prinzip ist es
doch wieder dasselbe.

Zu der Featureliste:
Ich würde 2 getrennt Featurelisten vorschlagen, daher hatte ich im Wiki
schon eine Trennung vorgenommen. Es wäre wirklich gut wenn man eine Art
Strichliste machen könnte, bzw. Features hinzufügen (keine löschen und
JEDER NUR 1 KREUZ, äähhhh STRICH PRO FEATURE!).

Hier noch mal die URL von Harald:
http://osar.it-livetalk.de/index.php/Hauptseite

Zum Namen:
OSCAR ist evtl. auch nicht schlecht als Name. Open source CAR radio. Ist
so schön rekursiv...

@Kai

Einverstanden!!!!
allerdings gehört MP3 dann auch auf ein separates Modul (was ein Linuxer
ja gar nicht benötigt)

Harry

Ich finde dieses Projekt echt super, auch wenn ich noch kein Auto fahre,
dauert leider noch 1-2 Jahre. Ein wichtiger Aspekt ist auch der Preis,
denn so etwas wie das Beagleboard, kann man sich als Schüler nicht mal
eben so leisten. Ich persönlich finde auch die Linux Variante besser,
weil ich mir überlegt habe man könnte das Radio ja auch als HTPC
benutzen. man würde nur eine kleine Grafikkarte bauen um z.B. einen
Fehrnseher anschließen kann und dann nen Ethernet anschluss dran, dann
kann man nen Video Player (VLC?) drauf installieren, dann hat man ein
System, mit dem Man übers Netzwerk Filme gucken kann.

@Harald
MP3 können die Anti-Linuxer auch in Software machen, AT91SAM7S64 is zu
50% mi tMP3 ausgelastet, ein etwas größeres Modell und das Thema hat
sich erledigt.

Viele Grüße

Der OMAP hat zusätzlich noch eine DSP integriert (für non Comercial
gibts die IDE von TI + Codec dings gratis).
Das wär die schönste Lösung.

Aber wie schon mal erwähnt wär sowas wie redmine (www.redmine.org)
praktisch zu Verwaltung des Projektes.


MFG

@Kai es ist Standart das man nur mehr mit I2S sprich Soundstreams
arbeitet im Audio-Bereich. Es außerdem gut für die Qualität.

Hallo,

ja, finde auch dieser Vorschlag (von Kai um 20:27) hört sich gut an!
(inklusive der Ergänzung von Harald, dass MP3 nicht unbedingt mit dem
Tuner auf eine Platine muss)

Ist im Grunde auch das was ich oben meinte, nur wohl etwas
unverständlich/knapp ausgedrückt hatte ;-)  (da keiner drauf eingegangen
ist...)


Gruß,
Mathias

Patrick Weinberger schrieb:
> Der OMAP hat zusätzlich noch eine DSP integriert (für non Comercial
> gibts die IDE von TI + Codec dings gratis).
> Das wär die schönste Lösung.

Ich kann warscheinlich nen OMAP kostenlos bekommen.

> Aber wie schon mal erwähnt wär sowas wie redmine (www.redmine.org)
> praktisch zu Verwaltung des Projektes.

Das ist eine Super Idee von dir, damit habe ich auch schon gearbeitet.

Wie wäre es mit einem IRC Channel für dieses Projekt?

Viele Grüße

@programm-noob

Das mit der Grafikkarte geht ned, ich wüsste nicht wirklich wie man das
mit wenig Aufwand realisieren soll wenn man mit so vielen Modulen
arbeitet. Man braucht dann wieder eine DSP oder HW-Video-Decoder usw


Preis ist immer so eine Sache zB die Produkte die zB eine DSP drin haben
bei Autoradios kosten gleich mal über 300€. Bei geringer Stückzahl kommt
nie unter 100€ (das wird wahrscheinlich platine + Dsiplay alleine
kosten).

Harald L. schrieb:
> @Kai
> Einverstanden!!!!

Super <freu> ;-))

> allerdings gehört MP3 dann auch auf ein separates Modul (was ein Linuxer
> ja gar nicht benötigt)

Linuxer brauchen MP3 von dem Autoradio ja nicht nutzen (vereinfacht die
API auch stark). Wenn wir uns wirklich für eine reine MP3 decoder uC
Variante entscheiden kann man ja drüber nachdenken das ganze so zu
machen, das die Linuxer den MP3 decoder uC nicht bestücken brauchen.
Wenn alles im selben uC sitzt ist es sowieso egal.

Bleibt auch noch die Frage wer wäre dabei, wo liegen die Interessen. Ich
bin gerade dabei dafür eine Seite im Wiki fertig zu machen.

Ich möchte nochmal Kais Vorschlag aufgreifen: Wenn man wirklich ein
Basisgerät mit "ordentlichem" Tuner (am besten 2), vernünftigen
Endstufen, ordentlicher Stromversorgung, und einem ordentlichen API hat,
ist das schonmal die halbe Miete.

Ob man das dann hinterher mit einer Atmel oder OMAP-CPU ansteuert ist
für diesen Teil doch erstmal völlig zweitrangig. Gleichzeitig hätte man
die übelsten Hürden beim Bau eines Autoradio schonmal aus dem Weg
geräumt.

Jetzt müssen wir uns als nächstes über die Schnittstellen verständigen.
(elektrisch, mechanisch und logische)

Wenn wir Verkehrsnachrichten zwischenspeichern wollen, ist eine
I²S-Schnittstelle im Tuner allerdings schon fast wieder Pflicht ;)

Harry

Ok wär ist der server Admin beim wiki ?


I2S ist Pflicht! Ich will ned interchip komminukation mit analogsignalen
machen!

Hallo nochmal,

wie würde eigentlich der FM-Tuner dann genau arbeiten? hat der direkt
ein Interface (I2C?) mit dem er gesagt bekommt auf welche Frequenz usw.
er sich einstellen soll und auf dem er RDS-Daten abliefert, oder muss
man da noch mehr selbst machen?
Audiodaten kommen dann denke ich einfach analog heraus, oder?
habe mich mit sowas noch nie näher beschäftigt...

Gruß,
Mathias

> @Kai es ist Standart das man nur mehr mit I2S sprich Soundstreams
> arbeitet im Audio-Bereich. Es außerdem gut für die Qualität.

Naja, das mag sicher korrekt sein, für Autoradios kann ich das aber
nicht 100%ig unterstreichen. Da Audioverstärker einen analogen input
haben wird man sowieso ab einem gewissen Punkt analog arbeiten müssen.
Unnötig über einen D/A und A/D Wandler zu gehen nur um ein bißchen
Signale zu multiplexen oder ein klein bißchen zu filtern bringt auch
nicht gerade eine Qualitätsverbesserung mit sich.

Lasst uns doch später genau schauen was man für einen AutoRadioIc nimmt
und basierend darauf entscheiden wie man das mit dem Audio alles lösst.

Patrick Weinberger schrieb:
> I2S ist Pflicht! Ich will ned interchip komminukation mit analogsignalen
> machen!

Interchipkommunikation würd wohl eher über sowas wie SPI, I2C, Uart
laufen.
Und warum bitte meinen alle Analog = schlecht?!?

Wo I2s sinnvoll ist, kann man was machen, aber wo es keinen Sinn macht
und das ist z.B. der Audiosignalpfad vom Radio selbst würd ich es auch
nicht machen.

Ausserdem sollt man erstmal mit nem Blockdiagram oder sowas anfangen
bevor man sofort erstmal auf sowas schiesst. Sonst reden wir alle leicht
aneinander vorbei und keine hat nachher mehr lust überhaupt was zu
machen.

Patrick Weinberger schrieb:
> Ok wär ist der server Admin beim wiki ?

Wiki: Kai & Ich
Server: Ich

Harry

Ich würde sagen, das Interface zwischen dem Basissystem und dem
eigentlichem Hirn sollte was selbsgemachtes sein , z.B. ein Bus mit
RS232(2), I²C(2) I²S(3), SPI(4), Strom(GND, 3,3V, 5V) Das wären dann 14
Pins also eine 2*7 Stiftleiste.
Dann hätten wir eine gute Verbindung zwischen den beiden Hauptelementen
Worüber alles an Daten ausgetauscht werden kann.


Viele Grüße

Mathias A. schrieb:

> wie würde eigentlich der FM-Tuner dann genau arbeiten? hat der direkt
> ein Interface (I2C?) mit dem er gesagt bekommt auf welche Frequenz usw.
> er sich einstellen soll und auf dem er RDS-Daten abliefert, oder muss
> man da noch mehr selbst machen?

So ein Auto "FM Tuner" besteht eigentlich aus mehreren Komponenten.
1.) Tuner (meist integriert in einem IC, ab und zu auch als extra IC)
2.) Der "FM Empfänger" an sich (komplexe Sache, selbst nach der FM
Demodulation, demultiplexen und co wird noch viel gemacht, z.B. weak
signal handling, d.H. je nach Empfangsbedingungen wird z.B. die FM
Bandbreite (ein Filter bei der ZF) angepasst oder ähnliches.
3.) Ein bißchen Audio "processing", d.H. Multiplexer (z.B. um zwischen
mehreren Signalquellen zu wählen wie CD, Radio, ...), einstellbare
audiofilter, ...

Kommunikation läuft in 99% der Fälle über I2C.

Für RDS Daten gibt es verschiedene Konzepte, z.B. einfach ein Bitstrom,
ein gepufferter Bitstrom, oder ein paar I2C Register die man auslesen
kann.

> Audiodaten kommen dann denke ich einfach analog heraus, oder?

Bei den einfachen tunern wie dem oben erwähnten JA, weil halt der ganze
signalpfad analog ist. Bei "großen" Autoradio DSPs die schwer zu
beschaffen und zu teuer sein dürften auch digital über I2S.

@Mysth

Kannst dir mal http://www.redmine.org/ ansehen. Dabei handelt es sich
auf ein Webbasierendes Projektmanagment system mit noch ein paar
Feautures.

Patrick Weinberger schrieb:
> @Mysth
>
> Kannst dir mal http://www.redmine.org/ ansehen. Dabei handelt es sich
> auf ein Webbasierendes Projektmanagment system mit noch ein paar
> Feautures.

Ganz nett....aber, meinst du nicht, daß das etwas overdosed ist?

Nen SVN sollte doch reichen....Wiki und Forum haben wir bereits.

Harry

Harald L. schrieb:
> Ganz nett....aber, meinst du nicht, daß das etwas overdosed ist?

Denk ich auch. Es soll spaß machen und das macht es nicht wenn wir 20
Milestones definieren, Stress und Zeitdruck machen.

> Nen SVN sollte doch reichen....Wiki und Forum haben wir bereits.

Sollen wir das µC.net SVN nutzen?

Es gubt immer 2 Seiten der Medaille.
Einer Seits kann dies für manche eine Art überwachung bedeutung wer wann
was macht.
Andererseits kann man sich so etwas synchronisieren wenn zB neue Leute
dazu kommen kann man mal schauen wo Not am man ist oder einmal jemand
auf wem warten muss und sich fadisiert kann dann einfach mal schaeun was
noch zu machen ist usw.

Außerdem gibt es möglichkeiten Abstimmungen zu machen usw

Ich finde Redmine Gut, is halt alles drinnen, was man braucht. Das Wiki
können wir ja ins neue eintargen. Das sollte nicht das Problem sein.

Kai G. schrieb:
>> Nen SVN sollte doch reichen....Wiki und Forum haben wir bereits.
>
> Sollen wir das µC.net SVN nutzen?

Ja!