Sound Trigger als Auslöser

[TaiJiGong]

Hallo Rawe,

Danke für die schöne Darstellung der verschiedenen Funktionen. Ich interressiere mich dafür wie die Kammera extern steuerbar ist um damit Bildanalysen durchführen zu können, eine Bildaufnahme innerhalb von 17 ms ist da schon mal nicht schlecht (Da die Reaktionszeit auch rel. konstant ist) .

Prinzipell gibt es für mich 2 Probleme, Daten zur Kammera senden und Daten von der Kamera zu lesen. Das lesen der Daten läst sich wohl mit einer Eye-fi Wlan SD-Card realisieren. Aber für das Senden von Daten an die Kamera habe ich noch nichts brauchbares gefunden (PTP ist evtl. eine Möglichkeit, aber da geht wohl auch noch nicht viel). Über diesen Weg mit USB Auslöser (wenn man nicht auslöst sonden nur schaut was da am USB sich was tut) könnte man schon mal ein paar Byte übertragen. Dann könnte man schon mal ein bestimmtes script auswählen usw....

Eye-fi SDCARD http://forum.chdk-treff.de/viewtopic.php?t=1843

Interressanter ist wenn das interne Mikrofon benutzt werden könnte, dann könnte man so was wie eine Modem-Verbindung realisieren.

Zum internen Mikrofon:

Die Kamera sollte irgendeine interne Variable besitzen welche den gain des Mikrofons bestimmt (wird ja während dem Video dynamisch lauter und leiser gemacht). In den propcases ist diese nicht zu finden. Das dumpen des gesamten Ram brachte mir zwar schöne Grafiken wie folgende, allerdings bin ich aufgrund mangelnder Kenntnis der Architektur trotzdem nicht wirklich schlauer. Gibt es sowas wie eine MemoryMap?

Zusätzlich sollte doch wohl auch ein Port (oder Speicherbereich) existieren wo die Daten des Mikrofons ankommen. Dein Ansatz mit dem Auslesen des RAM sollte da schon brauchbar sein. Nur wie finden wir die entsprechenden Ports ?

- Erst mal sollte man alle Bereiche ausschießen wo bekannt ist für was sie Verandwordlich sind.
- dann könnte man ein Geräusch (Sinus xxx HZ) erzeugen und das RAM auslesen. (sollte vielleicht ein bestimmtes Muster im RAM erzeugen)
- als nächstes ein Geräusch (Sinus yyy HZ) erzeugen und das RAM auslesen. Vielleicht kann man dann den Bereich schon besser lokalisieren.

Wenn man an das Mikrofon der Kamera drankommt, gibt es sicher viele Dinge die man realisieren kann.

mfg TaiJiGong

[rawe]

Die einfachste Möglichkeit wäre der Kamera über den USB-Port befehle zuzumorsen (Pulsdauer in 10mS schritten lässt sich ja in Scripten auslesen).

Zum Mikrofon:
Um Veränderungen im Speicher zu lokalisieren habe ich mir ein kleines tool gebastelt welches zwei Binärdateien (Ramdumps) miteinander vergleicht und eine genausogroße "Maske" erzeugt welche bei identischem Inhalt pro Byte 0x00, ansonsten 0x01 ist. Wird eine "Eingangsmaske" übergeben werden deren Werte bei gleichheit belassen und bei Differenz um 1 erhöht. Alle "neuen" (d.h. vorher 0x00) differenzen werden auf der Konsole ausgegeben.

So kann man erstmal mehrere Dumps erstellen bei denen man weiß dass die gesuchte Größe sich nicht geändert hat und aus diesen eine Maske erzeugen. Vergleicht man nun einen der "alten" Dumps mit Maske mit einem neuen Dump sollte relativ schnell ersichtlich sein wo sich was geändert hat.

Durch anhängen eines Bitmap-Headers und entsprechender Formatierung des Inhalts (BB,GG,RR) lässt sich das dann auch schön veranschaulichen (siehe Bild von letzter Seite). Sowas hier geht natürlich auch:

(erste 32MB Ram, verkleinert)


Das Problem ist dass die eingebaute Dump-Funktion die ersten 32 MB dumpt, die Kamera aber wesentlich mehr Adressieren kann. Beispielsweise befindet sich bei 0xfffff000 und 0xFFFFE004 der Zeitpunkt des letzten Software-Crashs. Der Kameralog beginnt bei 0xfffffe174, die Firmware bei 0xffc00000 etc... Die im Speicherbrowser angezeigten Adressen stimmen wohl auch nicht mit denen im Dump überein (???) Zwischendrin gibts immer wieder Speicherbereiche bei denen die Kamera einfach ausgeht, wohl weil nichts dahintersteckt. Der Ram ist je nach Kameramodell (Prozessor und OS-Version) sicherlich nicht identisch.

[msl]

Hallo,

klasse, dass du dich so in die Interna von CHDK und der Kamera vertiefst.

Die Speicherauswertung ist immer so eine Sache, da kann man selten allgemeine Rückschlüsse für alle Kameras ziehen. Deshalb ist auch der RAM-Dump auf die genannten 32 MB begrenzt. Aber vielleicht findest du einen Dreh, das interne Mikro auszunutzen. Schön wäre eine allgemeine Lösung.

Für neue CHDK-Funktionen wird in erster Linie nach einheitlichen Funktionsalgorithmen in den Firmware-Dumps gesucht. Und da wurde bisher im Zusammenhang mit dem Mikrofon nicht viel gefunden.

Zur USB-Steuerung:

Das Morsen kannst du dir ersparen.

Für einige Kameras, u.a. die A590, gibt es ein erweitertes CHDK mit Zugriff auf die PTP-Verbindung. Mehr dazu hier und hier. Damit kannst du die Kamera vollständig per Lua-Skript vom PC aus steuern.

Gruß msl

[rawe]

Weil es ja irgendwie nicht sein kann dass niemand weiß wie das mit dem Speicher aussieht habe ich den Speicher in 8MB-Schritten "durchgepiepst". Dazu kam folgendes Script zum einsatz:

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Lua Syntax Highlighting

i=0x0

while 1 do

  name=string.format("A/q/0x%08x",i)

  print(name)  

  afile=io.open(name,"r")

  if afile then

    afile:close()

  else

    afile=io.open(name,"wb")

    afile:close()

    value = peek(i,1)  

    afile=io.open(name,"wb")

    io.output(afile)

    io.write(value)

    afile:close()  

  end

  sleep(1)

  i=i+1024*1024*8 -- 8mb step

end

Erstellt in 0.007 Sekunden, mit GeSHi 1.0.8.9

Es wird eine Art Datenbank auf der SD-Karte über die Verfügbarkeit von Speicherbereichen angelegt. Dazu wird das Dateisystem missbraucht: Der Dateiname repräsentiert die Speicheradresse. Ist die Datei 0 Byte groß ist der Speicherbereich nicht lesbar. Ist die Datei >0 Byte ist er lesbar. Existiert eine Datei mit dem Namen der Speicheradresse bereits wird dieser übersprungen. Mit dem Script im Autostart bleibt folgendes zu tun: immer fein auf den Einschalter der Cam drücken wenn sie ausgeht. 512 mal einschalten geht grade noch so manuell, trotzdem wird da wohl irgendwann mal eine automatisierte Lösung gebastelt...

Ein dir /ON liefert folgendes in der Windows-Kommandozeile (Auszug):

Code: Alles auswählen

01.01.2000  00:00                 3 0x03900000
01.01.2000  00:00                 3 0x03a00000
01.01.2000  00:00                 3 0x03b00000
01.01.2000  00:00                 3 0x03c00000
01.01.2000  00:00                 3 0x03d00000
01.01.2000  00:00                 3 0x03e00000
01.01.2000  00:00                 3 0x03f00000
01.01.2000  00:00                 0 0x04000000
01.01.2000  00:00                 0 0x04100000
01.01.2000  00:00                 0 0x04200000
01.01.2000  00:00                 0 0x04300000
01.01.2000  00:00                 0 0x04400000
01.01.2000  00:00                 0 0x05000000
01.01.2000  00:00                 0 0x06000000
01.01.2000  00:00                 0 0x07000000

Somit ist es jetzt möglich eine memory map über alle 4GB zu erzeugen. So konnte ich bisher orten:

Code: Alles auswählen

0x00000000   0x03ffffff   RAM (64MB)
0x10000000   0x13ffffff RAM ohne Cache(64MB)
0x40000000   0x40000fff   ?? (4KB)
0xc0000000   0xc000ffff   mmio (LEDs, ...) (64KB)
0xffc00000   0xffffffff   ROM (4MB)

Interessant sind vorallem die 3 kleinen Bereiche in der Mitte. Blöd nur dass hier der kleinste Block 4KB groß ist - muss ich hier annehmen dass Startadressen sich durch n*4096 berechnen lassen? In den Zwischenräumen könnten sich ja noch massig irgendwelche Speicherbereiche verstecken.


Edit:
Das dumpen beliebiger Speicherbereiche ohne dabei chdk komplett neuzukompilieren und den Bereich im Dump-algo anzupassen geht auch mit folgendem lua-script:

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Lua Syntax Highlighting

function dump(i,j,n)

    print(n)

    afile=io.open(n,"w+b")

    k=i

    while i<=j do

        if i%1024==0 then

            print((i-k)/1024)

        end

            x = peek(i,1)

            s = ''

            s = s .. string.char(x)

            afile:write(s)     

        i=i+1

    end

    afile:close()  

    print("done")

end



dump(0x40000000,0x40000fff,"A/d/4kb___u.dmp")

dump(0xc0000000,0xc000ffff,"A/d/64kb_io.dmp")

dump(0xffc00000,0xffffffff,"A/d/4mb_rom.dmp")

Erstellt in 0.006 Sekunden, mit GeSHi 1.0.8.9

etwas tricky ist die automatische Typkonvertiertung, deshalb dieses merkwürdige Konstrukt mit dem string. Die Geschwindigkeit ist eher mau - 2-3kb/sec dürften mit dem script drin sein. Die 64KB gehen noch, die 4MB Rom ziehen sich doch ziemlich.

Edit2: Vergleich Rom dump von ( http://chdk.wikia.com/wiki/SX110IS ) vs. meine Kamera:

(4096x4096 Pixel/4MB; rot = differenz; total 11350 unterschiedliche Bytes; los gehts bei 3997698 dez.)

gleiches spielchen für den 64KB block zischen zwei kurz hintereinander liegenden dumps:

der übersichtlichkeit halber einmal mit und einmal ohne differenz-maske (rot). Die Werte scheinen 4Byte groß zu sein (sieht man am Muster)

und für den 4KB block:

dieser ist nicht ganz so sehr in Bewegung wie der 64k block

jetzt stellt sich natürlich die Frage was konkret hinter den Speicherblöcken steckt. In dem 64KB block befinden sich zumindest die LEDs. Da weiß nicht zufällig irgendein chdk-pro etwas genaueres?

[TaiJiGong]

Hallo Rave,

In dem Sourcecode platform/sx110is/boot.c

Code: Alles auswählen

#define DP (void*)0xC02200C4               // direct-print (blue)
#define LED_PR   0xc02200C4
#define LED_RED 0xc02200C8
#define LED_GRN   0xc02200CC
#define LED_PWR   0xc02200D0


Bei meiner Camera platform/ixus100_sd780/lib.c:

Code: Alles auswählen

#define LED_PR 0xC0220128


Scheint immer im Bereich 0xC022.... zu liegen.

Das sind wohl die addressen für die LED(s) ?

Zusätzlich zu dem Mikrofon (Eingang), gibt es auch Lautsprecher und HDMI (Ausgang).

Vielleicht ist das auch interressant http://chdk.wikia.com/wiki/PropertyCase

228 RW Audio channels (0=1ch, 1=2ch). Right channel mute if 2ch selected.
229 RW Audio sample rate (0=11025, 1=22050, 2=44100)
230 RW Audio sample format (0=u8, 1=s16le). U8 gives "Unidentified Image" in Play mode but works with other players.

Habe noch was gefunden: The Magic Lantern firmware for Canon EOS 5D Mark II cameras. http://bitbucket.org/hudson/magic-lantern/src/tip/audio.h

uint32_t *audio_level = (uint32_t*)( 0xC0920000 + 0x110 );

Dann hat meine Kamera auch noch 1 x Composite-Video/Audio-Ausgang. Da gibt es ein Kabel mit UDB (?) und 2 ChinchStecker wohl Video und Audio. Aber ich habe keine Geräte wo ich sie anschließen kann.

[rawe]

Hallo TaiJiGong,
richtig - das sind die LED-Adressen.

Habe mir zu der ganzen Thematik Gedanken gemacht, leider war keine Zeit um großartig das Internet zu durchwühlen und offene Fragen zu beantworten - also alle folgenden Überlegungen ohne Garantie auf Richtigkeit.

hmm... ich fürchte so generalisieren lässt sich das nicht. Video- und Audio-Out werden sicherlich nicht gesondert über 0xC... (nennt sich btw. memory mapped input/output ; mmio) ansprechbar sein. Die Property Cases bilden ja sowas wie firmwareweite globale Variablen, in den Audio-Werten steht bei meiner Kamera überhaupt nichts drin, die Werte lassen sich auch nirgends übers Menü (Canon) verstellen.

Dass der A/D-Wandler bei der EOS 5D MkII seinen Pegel auf einen mmio port liefert macht es möglich dass Canon das bei anderen Kameras nicht anders gemacht hat. Was sein könnte wären nur noch A/D-Wandler welche ihren input gain automatisch justieren sodass der Digic-Prozessor nur noch die fertigen Audiodaten abbekommt.

Das mmio-Layout ist zwischen den Kameramodellen verschieden. Dass sich die mmio-Region in der Größe zwischen verschiedenen Kameras mit DigicIII-Prozessor unterscheidet ist aber eher unwahrscheinlich.

Es kann gut sein dass der A/D-Wandler vom Mikrofon erst im Video- oder Notizmodus über einen Pin/Kommando aktiviert wird. Es wundert mich dass die mmio-Region so sehr und gleichmäßig rauscht... da müssen wohl mehr dumps her damit eine Häufigkeitsverteilung der Änderungen sichtbar wird.

Angenommen der mmio-Bereich ist 64KB groß und jeder i/o wert hat 4Byte Abstand (ist bei den LEDs so, sieht auch in meinem visualisierten dump so aus), ergeben sich daraus 16384 i/o Adressen zum suchen.

Hier ist mir auch noch nicht klar ob hinter einer Adresse ein getrennter Eingang / Ausgang liegen oder ob eine mmio-Adresse nur Eingang oder Ausgang sein kann... welche Adressbereiche wären dann Eingänge, welche Ausgänge? Ersteres sollte sich durch das setzen der LEDs und auslesen der Speicheradresse überprüfen lassen. Entspricht der ausgelesene dem geschriebenen Wert wird eine Adresse wohl nur ein Ein- bzw. Ausgang sein.

(Ggf. besteht der mmio-Bereich ja auch aus 2 Input- und 2 Output-Bytes abwechselnd?)

Der Adressbereich ab 0x1... ist mir jetzt klar: dahinter verbirgt sich so wie es aussieht der ungepufferte Ram (also identisch mit dem Inhalt ab 0x0...).

mfg rawe

[TaiJiGong]

Hallo Rave,

Ich denke das Ganze ist erst mal nicht so leicht lösbar, Es sollet wohl schon eine addresse findbar sein wo man das Micro eine/aus schalten kann, Dann müsste man den Bereich wo die Audiodaten geschrieben werden lokalisieren, das Format bestimmen, usw...

Vielleicht lassen wir das erst mal soweit, bis wir uns ein bisschen besser Auskennen. Die Ideensammlung ist ja schon mal nicht schlecht. (Kommt Zeit kommt Rat). Aber Deine Schaltung werde ich bei Gelegenheit mal nachbauen, und dann wohl auch Fragen haben. Prinzipell möchte ich für HW-Lösungen einen "Arduino" microprocessor einsetzen.

Interressanter finde ich den PTP-Mode der Kammeras, vielleicht können wir mit etwas Anleitung von CHDK-Kenneren da mehr helfen.

mfg TaiJiGong

[rawe]

Hallo TaiJiGong,
sollte es Fragen zu meiner Schaltung geben beantworte ich diese natürlich gerne.

Schreiben in den mmio bereich (also z.B: das mic muten) möchte ich nur sehr ungern - falscher output könnte unbekannte ggf. ungesunde folgen haben.

Irgendwie verstehe ich den Arduino-Hype nicht, letztendlich tuts da der kleinste Attiny. Momentan baue ich an einem Servo-Stativ bzw. Panohead der von der Kamera gesteuert werden kann... wenn der fertig ist gibts den Quellcode / Schaltplan.

Eine USB-Umsetzung auf AtMegas gibt es ja bereits - hier sollte es möglich sein den Rechner zu ersetzen und so mit der Kamera zu kommunizieren.

Edit: http://www.arduino.cc/cgi-bin/yabb2/YaB ... 1065918/30