AIN als Langzeit-"Audio-Pegelschreiber"?

[audioworld]

Liebe Leute,

in meinem Hauptberuf bin ich Systemtechniker beim Radio. Nun stehen wir vor der Aufgabe, 32 Sendewege bezüglich Ausfällen zu überwachen (UKW, DAB, Satellit, Internet-Livestream etc..).

Wir haben zwar Audio-Mitschnitte und Modulationswächter für akute Alarme, doch geht es um langfristige Bebobachtungen über mehrere Wochen mit Statistik.

Alle bisher gefundenen Audio-Logger machen echte Audio-Aufnahmen, das ist aber nicht sinnvoll, da die einzelnen Audiofiles (jeweils eine Stunde) in einen Audio-Editor gezogen und optisch kontrolliert werden müssten. Wir benötigen eigentlich nur eine Abtastung pro Sekunde oder eine pro 10 Sekunden, das reicht, um längere Ausfälle (von einigen Minuten) gut verfolgen zu können.

Da ist mir aufgefallen, dass man ja mit einer MB und den AIN genau sowas machen könnte, die MIDI-Control-Codes sind dann ja sehr Dateneffizient, und könnten von einem Textfile leicht in eine Grafik umgewandelt werden, 7 bit Pegel-Auflösung reicht auch vollkommen.

Drei Fragen nun:

- könnte man den Timer der AIN-Abfrage wesentlich verlangsamen, so bis auf 1Hz oder 0,1Hz herunter?

- könnte man ein analoges Line-Audio-Signal (ca. 2,5V spitze-spitze maximal) direkt an die AIN legen oder empfiehlt sich da ein Buffer und/oder ein Tiefpass davor?

- kennt jemand eine MIDI-Logger-Applikation, die über mehrere Tage durchgehend die vom USB kommenden MIDI-Controllerdaten in ein Text-File schreibt (MIDIOX habe ich schon probiert, der MIDI monitor ist zwar super, doch konnte ich diese Daten nicht fortlaufend in ein File schreiben)?

An sich wäre die Lösung dann sehr elegant, da man mit einem Core, zwei AIN-Modulen, einem MIDI INterface und einer kleinen Applikation 64 Audiokanäle überwachen könnte... Auch macht es eigenartige Freude, meine private Musikleidenschaft in den Job hineinnehmen zu können-)

danke vielmals für eure meinungen dazu,

karl.

[nILS]

* AIN-Abfrage verlangsamen: Sicherlich geht das. Eventuell einfach wäre aber einfach nur jeden x-ten Wert zu verwenden.

* Mit einem Pegel von 0..5V kommen die AINs an sich klar, ob ein Buffer jedoch sinnvoll wäre kann ich Dir leider nicht sagen

* MIDI Logger Applikation: Da würde ich einfach mal sagen "selber schreiben". Das ist eine Sache von ca. 50 Zeilen Quellcode. Ich hab so was in der Art glaub ich auch noch irgendwo rumliegen. Könnte ich bei Gelegenheit mal raussuchen, wenn Du das brauchst.

Hoffe das hilft Dir schon mal weiter!

[Pascal]

Was mir da am einfachsten zu einfällt, und sicher auch wesentlich einfacher zu realisieren wäre, wäre folgendes:

Atmel Prozessor (Atmega 8 ) mit jeweils 8 oder mehr AD-Wandlern.

Da kann man direkt mit den 2,5V drauf. 2,5V als Referenzspannung drauf geben.

Dadurch hast du eine recht große Auflösung, ob die nun gebraucht wird oder nicht, spielt ja erstmal keine Rolle.

Dann den Atmega noch mittels MAX232 eine Serielle-Schnittstelle aufbauen. Dann an den PC.

Auf dem PC dann die Software "LogView" verwenden. Die kann alles mitloggen und ist Kostenfrei! Das Format wie die Daten über die RS232 kommen müssen, liegt offen.

Habe damit schon öfter solche Log Projekte gebaut. Und ist sehr günstig und funktioniert!

Mit den AIN Modulen geht das sicher auch, dürfte aber mehr Aufwand sein das alles so umzubauen nd umzuprogramieren  als mal schnell ein paar Zeilen C-Code und nen kleiner Atmel.

[nILS]

Was mir da am einfachsten zu einfällt, und sicher auch wesentlich einfacher zu realisieren wäre, wäre folgendes:

Wesentlich einfacher? Nur bedingt, weil:

und umzuprogramieren als mal schnell ein paar Zeilen C-Code und nen kleiner Atmel.

* ??? Das fertige MIOS C skeleton nehmen + 15 Zeilen Quellcode schreiben kannst Du unterbieten?

[Pascal]

Ok. das sicher nicht. Aber mir ist keine Anwendung bekannt, die MIDI-Daten loggt und auswertet. Wieso auch!?!?! MIDI ist für soetwas denkbar eine schlechte Lösung. Bestenfalls ein Work arround, aber keine Lösung. RS232 ist da wesentlich besser gedacht, und man kann drüber schieben was man will.

Ein Core-Modul inkl. Pic kostet ca. 20€ plus die AIN Module, da bist du bei ca. 30€.

Ein Atmega 8 kostet ein paar € und du brauchst kaum noch zusätzliche Teile. Ist also schonmal auf jeden Fall günstiger.

15 Zeilen nicht ganz, aber viel mehr ist das auch nicht. Wenn ich da an meinen letzten Aufbau denke, war ein Ladestandsanzeiger für Akkus, hat Spannung, Ladestrom und geladenen Strom angezeigt, war recht simpel zu lösen. Und das sage ICH! *lach*

Wenn ich daran denke, immer SysEx oder CC Daten zu prüfen würde mir schlecht werden *lach*

Wie gesagt, kann gehen, aber wie sage ich immer: Es ist in den meisten fällen einfacher eine Software neu zu schreiben als sie um zu schreiben. Ok, beim MIOS trifft das nicht ganz zu, aber wie gesagt, einen MIDI Logger!?!?

[nILS]

Midi Logger (hab meine alte Kommandozeilenversion gestern rausgekramt): 35 Zeilen. ;-)

So, audioworld - jetzt haste schon 2 Ansätze und musst Dich auch noch entscheiden ;D

[audioworld]

nILS und Pascal,

das ist ja wunderbar freundlich von euch, mir so ausführlich zu antworten, und, ja, das sind beides sinnvolle Lösungen!

An sich sehe ich ein, dass RS232 die Methode der Wahl ist in diesem Industrie-Logging Segment. MIt dem ATMEL müsste ich mich aber wieder neu beschäftigen (Instruction set, Register.. ein wenig kenne ich das noch aus meiner 8051-Programmier-Urzeit: EEPROM UV-Licht-Löscher! wer hat sowas noch???).

Da ich zwei ungenutzte MB-Cores und ein AIN-Board herumliegen habe, werde ich aber doch die MB-Variante aufbauen. Sonst muss ich wieder was beim Elektronik-Versand bestellen, und das wird dann immer wieder recht teuer..--)))

Ich mach mal die Hardware fertig und beobachte, was sich mit Audio-Signalen zu tut wenn man diese an einen AIN legt. Einen Tiefpass werde ich sicher davor legen (R-C glied), dann schaue ich mir im MIDI-OX mal die Werte an.

Ich denke MIDI ist als Protokoll für diese Anwendung garnicht mals so abwegig. Einfach 32 unterschiedliche CC, die ihre werte anliefern, Sysex denke ich brauche ich nicht.

UND, BONUS-HINTER-GEDANKE: wenn ich diese MIDI-Daten in einem normalen Sequencer (Cubase etc.) auf 32 Spuren lege, schaut das dann beinahe wieder wie die Audio-Spuren parallel aus, nur eben mit wesentlich verringerter Datenmenge.

Frage an nILS:

Ich will garkeinen fertigen Code, kannst du mir aber bitte als stichwort einen tipp geben, wie ich da Anfangen würde, die MIDI-Daten vom USB kommend abzufangen?

Ich schrecke mich immer so bei C++ applikationen, den ganzen Header und die Deklarationen einzutragen, der Code macht dann ja spaß, doch das drumherum..

danke sehr herzlich,

gruß aus Wien, karl.

[nILS]

Naja, meine Version hatte ich damals mit Delphi geschrieben, weil's einfach am schnellsten ging. ;) Verwendet hab ich eine Klasse mit dem klingenden Titel TMIDIIn, die mir per Event Handler mitgeteilt hat, wenn und was ankam... Wenn Dir Delphi auch weiterhilf, kann ich Dir gerne die Midi-Klasse zukommen lassen.

[TK.]

Ok. das sicher nicht. Aber mir ist keine Anwendung bekannt, die MIDI-Daten loggt und auswertet. Wieso auch!?!?! MIDI ist für soetwas denkbar eine schlechte Lösung. Bestenfalls ein Work arround, aber keine Lösung. RS232 ist da wesentlich besser gedacht, und man kann drüber schieben was man will.

Ein Core-Modul inkl. Pic kostet ca. 20€ plus die AIN Module, da bist du bei ca. 30€.

Ein Atmega 8 kostet ein paar € und du brauchst kaum noch zusätzliche Teile. Ist also schonmal auf jeden Fall günstiger.

Generell habe ich nichts an AVRs auszusetzen, doch in diesem Fall stimmt die Rechnung nicht.

• MIDI ist eine sehr elegante Loesung, denn die Daten werden kompakt in einem standardisierten Format versendet.
  
• wenn es unbedingt RS232 sein muss: MIOS kann auch ASCII versenden. Mit dem MBHP_LTC Modul ist man RS232 konform
  
• ein PIC kostet nicht 20 EUR, und 8x4051 kosten nicht 10 EUR
  
• RS232 ist obsolet, PCs werden heutzutage nicht mehr mit dieser Schnittstelle ausgeliefert. Stattdessen benoetigt man einen Serial->USB Converter (bspw. FT232)
  

Doch wenn man schon einen Converter Chip fuer USB benoetigt, warum nicht gleich einen Mikrocontroller mit integriertem USB hernehmen, so wie bspw. PIC18F4550 oder PIC18F2550 - das waere dann wirklich eine kostenguenstige Loesung, erfordert jedoch ein bisschen mehr Programmieraufwand (MIOS wird nicht supported, aber man koennte die MBHP_USB_PIC Firmware hernehmen, und dort eine ADC Konversionsroutine einbauen), doch den haette man ja auch mit der AVR Loesung.

Ich habe hier uebrigens noch einige PIC18Fx550 mit EUSART bug herumliegen, mit denen ich nichts anfangen kann. Ich koente Dir 1 oder 2 Chips zuschicken. :)

Gruss,

Thorsten.

[Pascal]

Hey TK ;-)

Ich sprach nur von Atmel, weil ich darin eigene Erfahrung habe was die Programmierung angeht. Ich bin mir sicher ein PIC kann das genau so, nur habe ich darin keine Erfahrung.

Aber das es PICs mit USB gibt finde ich ja klasse.

Ich sprach bei den Preisen auch eher von ganzen Modulen. Also PCB, Teile, Pic. Nicht von dem PIC selber ;-)

So nu hab ich mich aber genug gerechtfertigt.

Wieder zum Thema:

Na wenn du die Teile eh zuhause hast, dann ist es was anderes.

Aber irgendwie kann ich mich trotz standart nicht mit MIDI als Loggingmethode anfreunden. Hat schon ein Grund wieso das MIDI heißt und nicht USB ;-)

[Screaming_Rabbit]

Warum so komliziert?

32 Sendewege = Öffentlich rechtlicher Rundfunk = Moneten spielen keine Rolle  ;)

Nimm doch einfach 4 billigst "8 Ananalog zu USB"-Interfaces & Samplitude SE.

In MidiYoke vier "virtuelle" MackieControls einbinden, Level von den 32 MixerInputs empfangen und die Daten von MidiYoke wieder weiterleiten, dahin wo Du sie aufnehmen/loggen willst.

Ich weiss nicht, wie lange (Zeit) ein Projekt in Samplitude sein darf. Falls unlimitiert, kannst Du die Daten gleich wieder an SAM zurück senden und darin in 32 Sequenzer Spuren einzeln aufnehmen.

Greets, Roger

[audioworld]

Pascal:

der Punkt für mich ist sicher, dass ich mit MIDI messages seit (ja, wirklich) 22 Jahren vertraut bin. soeben schaue ich auf mein Buchregal: da stehen das originale "MIDI Implementation Book" und das "MIDI Sysex Book" von Steve de Furia und Joe Scacciaferro, die ich im Jahre 1986 mit erheblichem Aufwand (pre-Internet-Zeit) aus den USA importiert hatte... Ich sehe das MIDI-Protokoll so wie TK als recht elegante Konvention, lernen muss ich "nur" den Teil, wie ich die MIDI-Kommandos aus dem Windows-Buffer abhole und in eine Datei schreibe.

TK:

Danke für den Hinweis, sicher ist die direkte Ausgabe über USB robuster als da noch ein Interface dazwischen zu hängen. Bezüglich PIC18Fx550 sende ich ein PM, danke für das Angebot.

Screaming:

ja, öffentlich-rechtlich stimmt, doch leider (oder besser: gut so) sind in den letzten Jahren sämtliche budgets minimiert worden, speziell in der Technik sind "kleinprojekte" immer schwerer zu organisieren. Wie bei den Banken: wen man einige Millionen benötigt, findet sich über Connections ein Weg (siehe HDTV-Investitionen), wenn aber ein "kleiner Techniker" etwas verbessern will und dafür 500€ benötigt, kommt das einer Ochsentour gleich.

Außerdem zeigt meine Erfahrung, dass man beim Zukauf ohnehin wieder MIddleware/Interface Probleme lösen muss, mit dem gleichen Aufwand will ich das gerne selbst machen, und wir haben dann eine LÖsung, bei der wir uns wirklich gut auskennen.

die MIIDI-Daten mit einem Sequencer zu loggen habe ich schon versucht, bei CUbase und Samplitude war das aber nicht erfolgreich, die sind beide nach 2-3 Tagen stehen geblieben. Ansehen und Auswerten möchte ich die Daten in einem Sequencer, doch die Rohdaten sollen möglichst direkt vom USB in ein Textfile kommen.

Randnotiz: 32 Sendewege kommen aber auch bei einem Privatsender schnell zusammen. Heute spielt man ja nicht nur auf UKW, sondern aben auch auf DAB, satellit, DVB-T, DVB-H (machen wir ab Juni), Internet... Das ist nur EIN Radioprogramm!!! Dann ist fpr die Fehlereingrenzung immer wichtig, WO ein Ausfall war. Schon für UKW bedeutet dies, dass man 4-5 Punkte in der Signalkette monitoren muss, um im nachhinein wirklich herausfinden zu können, wo wann was passiert ist. Beim Internet-Stream muss man unbedingt ZWEI Punkte monitoren: den echten Encoder-PC, und dann den "Publishing Point", also den Streaming Server der das zum Hörer ausliefert.

nILS:

danke für das Delphi-Angebot. Ich habe in den letzten Wochen aber recht viel in ECLIPSE angeschaut, in diesen IDE kann man Java, C++, PHP, Ruby etc.... gut schreiben und testen, ich hoffe ich kann da nun konkret was programmieren damit.

Vielen herzlichen Dank erstmal,

ich freue mich, wenn ich bei erfolgreicher Umsetzung auch mal was in die Community zurückspeisen kann, anstatt nur zu fragen.

[Screaming_Rabbit]

Randnotiz: 32 Sendewege kommen aber auch bei einem Privatsender schnell zusammen. Heute spielt man ja nicht nur auf UKW, sondern aben auch auf DAB, satellit, DVB-T, DVB-H (machen wir ab Juni), Internet... Das ist nur EIN Radioprogramm!!! Dann ist fpr die Fehlereingrenzung immer wichtig, WO ein Ausfall war. Schon für UKW bedeutet dies, dass man 4-5 Punkte in der Signalkette monitoren muss, um im nachhinein wirklich herausfinden zu können, wo wann was passiert ist. Beim Internet-Stream muss man unbedingt ZWEI Punkte monitoren: den echten Encoder-PC, und dann den "Publishing Point", also den Streaming Server der das zum Hörer ausliefert.

... weiss schon. - War ja auch 8 Jahre ÖR-Rundfunk Tontechniker.