Entwicklung eines Steuergeräts zur automatischen Antennenabstimmung

von Nico Schmidt DD6VFS

Dieser Artikel nimmt am Artikelwettbewerb Infineon XMC Design Contest 2014 teil.

Ich besitze für meine Amateurfunkaktivitäten auf den Kurzwellenbändern eine selbstgebaute Magnetic-Loop. Was mich dabei stört ist dass die Neuabstimmung immer sehr umständlich ist, da meine Funk- und Bastelecke (der sogenannte Shack) und der Standort der Antenne räumlich auseinanderliegen. Dafür sollte nun Abhilfe geschehen. Der Aufbau sollte größtenteils mit noch vorhandenen Bauelementen erfolgen. Zunächst soll ein Prototyp zum Verständnis der Arbeitsweise des XMC1100 entstehen der nach Bedarf ausbaufähig ist. Weiterhin soll die fehlerfreie Zusammenarbeit der Komponenten erprobt und optimiert werden.

Einleitung

Eine Antenne sollte bei ihrer Benutzung auf der benutzten Frequenz abgestimmt sein. Dieses wird als Resonanz bezeichnet. Nur so wird die optimale Leistung von der Antenne aufgenommen bzw. abgegeben (Leistungsanpassung). Um die Resonanz einer Antenne zu bestimmen gibt es mehrere Möglichkeiten. Bei diesem Projekt wird die Resonanz über das Stehwellenverhältnis (englisch standing wave ratio, SWR) ermittelt.

Hardware

Die Hardware besteht aus hauptsächlich aus einem SWR-Koppler, einem Prozessorboard mit dem XMC 2Go Board und einer Motoransteuerung. Um das Projekt erweitern und auch an eigene Ideen anpassen zu können, ist die Hardware modular ausgeführt. Die Schaltung und das Layout für Hardware wurde mit der Software Eagle 6.4 in der Freeware-Version erstellt. Das übertragen des Layouts auf die Leiterplatten erfolgte im Tonertransfer-Verfahren, geätzt wurde mit CuCl₂.

SWR-Messkoppler

Der SWR-Messkoppler basiert auf einer Standardschaltung, zu finden bei Volker, SM5ZBS, und anderen. Er befindet sich, um Störungen an der anderen Hardware zu vermeiden, komplett in einem Weißblechgehäuse. Aus diesem werden nur die gemessene Vorwärts- und Rückwärtsleistung (über die jeweiligen Spannungen) sowie die Koaxialkabelanschlüsse für Sender und Antenne herausgeführt.

Prozessorboard

Auf dem Prozessorboard befindet findet das XMC 2Go. Als zentrale Schaltstelle des Systems sind auf ihm die Verbindungen zum SWR-Messkoppler, zur RS232-Schnittstelle, zur Motoransteuerung und eine SPI-Schnittstelle herausgeführt. Es sind Anschlüsse zum für Taster manuellen Rechts-/Linkslauf sowie eine Weiterhin befinden sich dort die 3,3V Spannungsregelung und Anschlüsse für die Bedienelemente. Auf dem XMC 2Go sollte zum Schutz zwischen der Spannungsversorgung über USB und der Spannungsversorgung vom System die 3,3V Verbindung unterbrochen werden. Dieses geschieht am besten in der Nähe von C1/C2. Die gewandelten Spannungen vom SWR-Messkoppler werden über Schutzdioden an den Ports P2.8/P2.9 zum XMC 2Go geführt. Über P0.0 und P0.5 werden die Signale zur Motoransteuerung herausgeführt. Weiterhin sind an P2.10 und P2.11 die Anschlüsse für den manuellen Rechts-Linkslauf. Auf der 2. Anschlussleiste des XMC 2Go befindet sich an P0.6/P0.7 die serielle Schnittstelle. An P0.8, P0.9, P0.14 und P0.15 befindet sich die SPI-Schnittstelle. Über P2.0 wurde ein Anschluss für die „SWR Ok“-Signalisierung vorgesehen.

Motoransteuerung

Als Motor ist bei diesem Projekt ein modifizierter Modellbauservo mit den Kenndaten 4,8V/150mA vorgesehen. Die Ansteuerung des Motors erfolgt über eine Halbbrücke L293D. Die Umschaltung der Drehrichtung erfolgt über Logikgatter SN74LS00 die auch für die Anpassung CMOS-TTL sorgen. Als Signale vom Prozessorboard genügen damit nur ein Richtungs- und das PWM-Signal. Aufgrund des Langsamlauf des Motors und des nachgeschalteten Schneckengetriebes wird der Bremsmodus des L293D nicht benötigt. Zusätzlich wird der Motor über Pulsweitenmodulation angesteuert.

RS232 Schnittstelle

Um die Anzeige der aktuellen Parameter und ggf. Steueranweisungen über zu ermöglichen ist eine RS232-Schnitstelle mit MAX232 implementiert. Diese kann durch die modulare Bauweise bequem durch andere Schnittstellenbausteine (z. Bsp. FT232) ersetzt werden.

SPI-Schnittstelle

Für spätere Erweiterungen, z. Bsp. eine Ethernetanbindung oder ein EEPROM, wurde ein SPI-Schnittstelle herausgeführt. Diese ist beim momentanen Ausbaustand aber noch nicht in Benutzung.

Netzteil

Als Netzteil wird ein einfaches 5V-Netzteil auf Basis eines Low-Drop-Reglers L4950V mit Standardbauelementen benutzt. Aus dieser wird dann auf dem Prozessorboard die 3,3V Spannung erzeugt.

Software

Die Softwareentwicklung erfolgte mit unter DAVE3 von Infineon und Keil µVision 5. Mit DAVE3 wurden die DAVE-Apps eingerichtet und mit µVision erfolgte die Programmierung der Funktionen und Threads. Um meine im Studium gesammelten Kenntnisse zu festigen und neue Erfahrungen zu sammeln ist das Programm für die Steuerung RTOS-basiert. Durch die Firmen Keil und Infineon wird bei ihren Entwicklungsumgebungen ein frei benutzbares Echtzeitbetriebssystem mit. Auch ist die Implementierung neuer Funktionen so um einiges leichter.

CMSIS RTOS RTX

Ein großer Vorteil von Echtzeitbetriebssystemen ist, neben der zeitlichen Vorhersagbarkeit und der Prioritätensteuerung, die Möglichkeit Funktionen in eigenständige Threads auszulagern. Es gibt weitere Vorteile, die hier aber nicht weiter betrachtet werden. Der Nachteil ist das durch das Betriebssystem mehr Flash-Speicher und mehr internes RAM verbraucht wird. Einen neuen Thread anzulegen ist relativ einfach

#include <DAVE3.h>					// für DAVE3-Funktionen

void test(void const *arg);				// Prototype für Thread „test“

osThreadDef (test, osPriorityNormal, 1, 0);		// Definition von Thread "test"

int main(void)
{
	DAVE_Init();					// Initialisation der DAVE Apps

	osThreadCreate (osThread (test), NULL);		// Anlegen von Thread "test"
	osKernelInitialize();				// RTX-Kernel initialisieren
	osKernelStart ();				// RTX-Kernel starten

	while(1);			 		// Endlosschleife
}
																								
void test(void const *arg)				// Thread „test“
{
}

Dieser Thread kann dann wie gewohnt mit unser while(1)-Endlosschleife gefüllt werden. Wichtig ist dabei in dieser Schleife das im Thread mit einer wait-Funktion ist da andernfalls der Thread die komplette Rechenleistung des Controllers komplett für sich in Anspruch nimmt und andere Threads mit gleicher oder niedriger Priorität nicht mehr ausgeführt werden können. Von diesen wait-Funktionen gibt es mehrere. Näheres dazu in der Onlinedokumentation sowie in meinem Quelltext.

void test(void const *arg)
{
	while(1)					// Endlosschleife	
	{	
		IO004_TogglePin(IO004_Handle0); 	// Pin umschalten
		osDelay(500);				// 500ms warten
	}
}

Die Kommunikation zwischen den einzelnen Threads habe ich per Mailbox gelöst. Solch eine Mailbox einzurichten ist relativ einfach

#include <DAVE3.h>	

typedef struct	               		       // Struktur der Mailbox festlegen
{
	char Message[16];												
	uint8_t	Lenght;													
} Mail_Queue_struct;

osMailQId Mail_Queue;	                       // Definition der Mailbóx
osMailQDef(Mail_Queue, 16, Mail_Queue_Struct); // Definition der Parameter für Mailbox

int main(void)
{
   ...
   Mail_Queue = osMailCreate(osMailQ(Mail_Queue), NULL); // Mailbox anlegen  	

   osKernelInitialize();         		// RTX-Kernel initialisieren
   osKernelStart ();				// RTX-Kernel starten

}

Die Mailboxen können dann mit osMailPut() gefüllt werden. Mit osMailGet() können die Nachrichten vom Empfänger wieder abgeholt werden. Näheres dazu in der Dokumentation und in meinem Quelltext.

Thread system_running()

Gerade in der Entwicklungsphase und auch später ist es wichtig zu überwachen ob das Betriebssystem noch läuft oder irgendwo "hängt". Dazu habe ich einen separaten Thread geschrieben, in dem nur die LED 1 auf dem XMC 2Go blinkt. Bei der Fehlersuche kann man so leicht feststellen ob das Betriebssystem noch läuft oder ein Lock aufgetreten ist.

Thread uart_transmit()

Um aktuelle Messwerte ausgeben zu können ist eine Möglichkeit Daten zum PC zu senden implementiert. Momentan ist dieses über den Debugger des XMC 2Go aktiviert, kann aber durch Pinänderung in DAVE3 leicht in die implementierte serielle Schnittstelle umgeschaltet werden. Die Sendedaten erhält der Thread per Mailbox.

Thread swr_messung()

Im Thread swr-messung() werden ca. alle 100ms die analogen Messwerte an Pin P2.8 und P2.9 eingelesen. Bei Überschreiten eines Schwellwertes der Vorwärstsspannung sorgt für die Berechnung des SWR. Das Stehwellenverhältnis ist durch die Formel

[math]\displaystyle{ \text{SWR} = \frac{V+R}{V-R} }[/math]

definiert und wird berechnet. Nach der Berechnung wird das SWR per Mailbox an den Thread control() gesendet.

Thread control()

In diesem Thread werden die Steueraufgaben des Systems abgearbeitet. Bei per Mailbox eintreffenden SWR über einem bestimmten Schwellwert wird der Motor am Abstimmkondensator so lange gedreht bis das SWR unter den Schwellwert gefallen ist. Da im momentanen Ausbauzustand noch kein Drehwinkelgeber und keine Frequenzanalyse implementiert ist, hat der Motor bei Automatikbetrieb noch keine Drehrichtungsvorwahl. Bei unterschreiten eines SWR von 2.0 wird der Motor auf die hälfte der Geschwindigkeit reduziert um eine feinere Abstimmung zu ermöglichen. Weiterhin werden in diesem Thread die beiden Taster zur manuellen Abstimmung abgefragt. Hier ist eine Richtungsvorwahl bei niedriger Geschwindigkeit möglich.

Fazit

Es macht immer wieder Spaß sich in neue Prozessoren einzuarbeiten. Sehr nützlich ist dabei wenn auch mal andere Personen ihre Ideen und Einfälle dazu beitragen. Auch bringt ein solches Projekt Erfahrungen in vorher nicht angeschnittenen Themengebieten. Momentan liegt die Steuerung als Prototyp in der Erprobungsphase vor und ist auch als solche zu betrachten. Ich übernehme keine Haftung für Schäden an anderen und anderen Geräten. In meiner knapp bemessenden Freizeit werde ich das Projekt weiter vervollständigen und diesen Artikel von Zeit zu Zeit aktualisieren. Ein aktueller Stand ist immer auf meiner Homepage zu finden. Ich möchte mich bei allen bedanken die mir bei diesem Projekt mit Rat und Tat zur Seite standen. Inbesondere sind hier zu nennen Frau Katja Koller von der Firma Infineon, Volker SM5ZBS und mein Vater.