Wer meinen Artikel Fledermausdetektor gelesen hat, wird sicher den Unterton mitbekommen haben, dass ich nicht ganz zufrieden war mit dem Ergebnis. Das Gerät funktioniert zwar grundsätzlich, ist aber zu unempfindlich. Das hat mich bewogen das ganze noch mal aufzubauen, diesmal mit Digitaltechnik, die der Aufgabe besser gewachsen ist. Zentrales Bauteil ist ein dsPIC33E, ein Mikrocontroller mit DSP-Funktionen von Microchip.
Das Ziel
Die Idee ist, das Ultraschallsignal mit Mikrofonen aufzunehmen, die in dem Bereich empfindlich sind. Das verstärkte Signal wird mit einem AD-Wandler mit mindestens 300kHz Samplingrate eingelesen. Nach einer Spektralanalyse mit FFT wird das Spektrum zunächst auf einem Display ausgegeben. Wenn möglich wird es mit einer inversen FFT und nach Anpassung der Samplingrate wieder hörbar gemacht. Soweit die grobe Idee und wenn das Projekt mit aller Hardware, Software und Mathematik weiter gediehen ist, gibt es hier sicher einen Artikel dazu.
Das Experiment
Zunächst benötige ich also ein kleines System zur digitalen Signalverarbeitung. Am Eingang ein Vorverstärker, AD-Wandler, DSP bzw. schneller Mikrocontroller und am Ausgang wieder ein DA-Wandler. Ein kleines Display sollte auch nicht fehlen. Schön wäre eine Stromversorgung per Batterie, alternativ USB.
Bauteilrecherchen
Ein solches Projekt fängt immer mit Recherchen zu den verwendeten Bauteilen an. Welcher Mikrocontroller wird gewählt, welche Wandler, Stromversorgung usw. usf. Aus diesen Überlegungen und nach einiger Suche ist dann schon ein recht detailliertes Blockschaltbild entstanden wie oben zu sehen.
Leider sind einige spezielle Bauteile nicht mehr im Handel für Amateure zu bekommen. Den DSP z.B. gibt es nur bei großen überregionalen Distributoren mit ziemlich hohen Versandkosten oder direkt beim Hersteller. Insgesamt waren glaube ich 3-4 Bestellungen nötig, um alle Teile zu besorgen und wegen der modernen Gehäusebauformen muss man die meisten ICs auf eine kleine Adapterplatine löten, um sie zu einer Lochrasterkarte passend zu machen.
Prototyp
Einige Bastelabende nachdem die Bestellungen da waren, war der Prototyp soweit fertig, dass ich anfangen konnte, die einzelnen Schaltungsteile zu testen.
Es ging los mit dem Oszillator, dann der I2C Bus, Display und AD/DA-Wandler. An der Stelle kam ich etwas ins Stocken. Es ist jedes Mal ziemlich knifflig, eine SPI (synchron serielle Schnittstelle) mit hohen Datenraten zum Laufen zu bekommen. Ich musste mir noch einen neuen Logikanalysator mit 100MHz Auflösung anschaffen, um das Problem zu lösen. Der Grund war, dass der AD-Wandler noch ein Signal /CONVST (conversion start) benötigt, was die CPU nicht schnell genug und vor allem nicht synchron generieren kann. Als Ausweg habe ich das Signal /SS (slavesync) der SPI invertiert und als /CONVST verwendet. Die AD-Wandlung soll ohnehin synchron zur SPI Schnittstelle erfolgen was bedeutet, dass je eine Übertragung auf der SPI-Schnittstelle (/SS) auf eine AD-Wandlung (/CONVST) folgt.
Für die Analyse der Datenübertragung verwende ich PulseView, eine tolle Open Source Software für einige vorwiegend günstige Logikanalysatoren.
Nachdem ich die Schwierigkeiten mit einigen Hard- und Software-Änderungen umschifft hatte, war es ein toller Moment, den ersten verzerrungsfreien synthetisch erzeugten Sinus-Ton zu hören.
Software
Die Software habe ich zunächst vorwiegend in C geschrieben. Vom Prozessor-Hersteller gibt es eine tolle Entwicklungsumgebung, „MPLAB® X„, die frei verfügbar ist. Leider hat die freie Version einige Einschränkungen bei den Compileroptionen. Mehr als ein „-o1“ ist nicht erlaubt, was zu relativ langsamem Code führt. Das ist hier aber kein Problem, zeitkritische Dinge werden einfach in Assembler implementiert.
Das auch als Tipp an alle Nutzer von GCC, AVR-GCC etc: Es ist ziemlich einfach, Assembler in C zu integrieren. Man muss lediglich eine Datei mit der Endung „.s“ oder „.S“ dem Projekt hinzufügen. Dabei wird die Datei mit dem großen S noch vom Preprozessor verarbeitet.
Die jeweils aktuelle Software habe ich unter meinem Github-Account zur Verfügung gestellt.
Hardware
Die Hardware ist noch nicht perfekt, aber ganz gut geeignet für weitere Experimente. Immerhin sind mit dem System 16bit mit 384kHz Mono bzw. 192kHz Stereo Samplingrate als Input möglich und 24bit bei 192kHz Stereo als Output. Dabei ist die CPU mit dem Datentransfer zu nur wenigen Prozent ausgelastet dank DMA-Transfers.
Trotzdem würde ich beim nächsten Prototyp einiges verbessern, vor allem, um die SPI Programmierung einfacher zu machen.
- dsPIC mit I2S Schnittstelle
- dsPIC mit mindestens 3 SPI Schnittstellen und mehr IO Ports
- ein größeres Display in Farbe
- zusätzlicher RAM, evtl. an SPI Schnittstelle
Mehr RAM wäre prima. Das Maximum on Chip für dsPIC33 CPUs sind ca. 50kByte. Ein dsPIC33EP512GP806 im TQFP64 Gehäuse wäre gut geeignet vielleicht aber auch ein 32bit Controller wie der PIC32MZ1024EFH100.
