Hallo.

Im Anhang befindet sich eine Entwicklung, mit der Bilddateien auch über
GSM übertragen werden können.

Die Erklärungen sind recht umfangreich gehalten.

Behandelt wird:

- Platinenerstellung doppelseitig im Tonerätzverfahren
- IQP 500 Ansteuerung
- Datenübertragung über CSD/ GSM

Grüße
Niels

Auf Grund einiger Nachfragen, werde ich demnächst ein vollständiges
Anwendungsbeispiel aus dem Bereich der GSM-Anwendung hochladen.

Mittlerweile konnte ich den Bug bei der fehlerhaften Kommunikation bei
der Verwendung von Delphi finden - daher kann nun alles bequem über die
EXE gesteuert werden.

Im Beispiel wird folgendes enthalten sein:
Die EXE (PC) eröffnet die Datenverbdindung mit der entfernten
Hauptplatine.

Die Hauptplatine nimmt den Anruf an.

Die EXE (PC) fordert ein Bild an.

Das Bild wird vollautomatisch übertragen, gespeichert und darsgestellt.

Ich habe die Software nun so weit überarbeitet, dass man diese auch als
Nichtentwickler verstehen kann. Kurz ein paar Worte dazu:

- Zur Verwendung der Software wird ein PC mit serieller Schnittstelle
benötigt. Diese kann auch durch einen USB-Seriell-Wandler gestellt
werden. Weicht der COM-Port von COM1 ab, so ist dieser im Programm unter
"Aufnahme" - "COM-Einstellungen" zu setzen. Die Einstellungen gehen nach
Programmende verloren.

- Im Programmablauf wird die Telefonnummer des mobilen Geräts
eingegeben. Durch Klick auf Datenverbindung aufbauen, wird eine
Verbindung hergestellt. Anschließend kann ein Bild übertragen werden.
Dieses Bild wird dann automatisch mit einem Zeitstempel versehen und mit
dem Namensprefix, der frei wählbar ist, im Programmordner gespeichert.

- Die Bildaufnahmeprozeduren sind als Batch ausführbar. Es können
beliebig viele Bilder hintereinander aufgenommen werden. Außerdem ist
die Zeit zwischen den Aufnahmen frei wählbar (2-oo Minuten). Dabei kann
ein Reconnect zum Mobiltelefon durchgeführt werden (Kosten...).

- Unterstützt wird das große (640x480) und das kleine (160x120) Format.
Ferner kann der Blitz verwendet werden und die Daten direkt oder
gepuffert ausgegeben werden.

- Es ist unbedingt das neue HEX-File auf die Hauptplatine zu flashen, da
die PC-Software nur mit dieser angepassten Firmware funktioniert.

Das Programm PC und uC darf keinen kommerziellen Einsatz finden.

Im Anhang ist eine Zeitrafferaufnahme von 2 Stunden als Video zu sehen.
Die Bilder wurden mit dem Programm aufgenommen und mit
WindowsMovie-Maker zu einer Videodatei gewandelt.

Video vergessen ;-O

Hallo Niels,
jetzt weiss ich wo du wohnst ;-).
Spass beiseite, tolles Projekt was du da auf die Beine gestellt hast.
Ich überlege mir schon ob ich die Platinen machen soll nach deiner
Anleitung.
Wenn dieses "Hindernis" nicht wäre hätte ich es schon aufgebaut.
Es reizt mich immer mehr.

Gruß

Andreas

gs schrieb:
Hallo Gerhard. Bedauerlich, dass die Schaltung nicht auf Anhieb
funktioniert. Ich versuche jetzt mal eine Ferndiagnose.

Fehlerquelle No 1:
Der verwendete Quarz stimmt nicht mit 11059200 Hz überein. Lösung:

> 4. wie hast Du die FuseBit gesetzt?
Die Fusebits sind auf einen externen Quarz gesetzt. BOOTSZ1=1,
BOOTSZ0=1, SUT0=1 (Alle anderen auf 0) 0=programmed, 1=unprogrammed

> 1. Nach dem Anlegen der Spannung an der Schaltung (AtMega 8 und Kamera)
> erfolgt keine Meldung über die serielle Schnittstelle?
Unabhängig welche der beiden Softwareversionen Du verwendest, erscheint
eine Meldung auf der softwarebasierten seriellen Schnittstelle. Dabei
ist unbedingt zu beachten, dass Du den Pegelwandlerausgang in Richtung
PC auf Pin D.7 legst. Der Eingang aus Richtung des PCs ist auf Pin B.1
zu setzen.

> 2. wie soll sich die LED am Pin23 (PC0) nach dem Einschalten verhalten?
Das ist abhängig von der Softwareversion. Nach dem Einschalten ist die
LED aber in jedem Fall aus. Erst nach Senden eines Zeichens über den
Softwareuart erleuchtet diese.

> 3. wird TXD (ATmega) mit TX Kamera und RXD mit RX verbunden?
Nein. Das würde ja auch keinen Sinn ergeben. TXD (Atmega) geht natürlich
auf RXD (Kamera).


Andere Fehlerquellen: Spannung ist zu hoch/ niedrig. Minimal sind 3,7
Volt, maximal aber 4,5 Volt an der Versorgung der Kamera. Strom liegt
bei guten 60-80 mA.

Hoffe, ich konnte helfen. Bei Fragen einfach melden.

gs schrieb:

> der Wert des Quarzes ist mir voll durchgegangen. Diesen muss ich mir
> erst besorgen. Im Schaltplan stand 16MHz und diesen habe ich genommen.

Ja der Wert ist da irgendwie stehen geblieben. Im Grunde könnte es auch
mit einem 16Mhz Quarz funktionieren. Ich habe hier die aktuelle Version
mit 16Mhz kompiliert. Probiere es einfach mal aus. Kaputt kannste da
nicht viel machen. Das Hexfile ist übrigens zur Software kompatibel,
daher auch ohne Hyperterminal verwendbar.

gs schrieb:
> Nachdem ich festgestellt habe,
> dass die Übertragungsrate 9600 und nicht 19200 kann ich den Datenverkehr
> auch lesen. Leider hängt sich aber anscheinend die Kommunikation auf.

Hallo Gerhard,
die aktuelle Version ist ja die fürs Mobiltelefon und arbeitet daher
auch mit 9,6 kBps. Bis auf wenige Aussnahmen macht die Version auch das,
was der bereits gepostete zweite Code (also der fürs Mobiltelefon) auch
macht.

Wenn Du also eine höhere Datenrate am Ausgang erzielen möchtest, musst
Du den Bascomquelltext ändern und auf die gewünschte Baudrate setzen.

Allerdings sollte die Parametriesierung der Kamera auch mit dem 16 Mhz
Quarz gehen. Das tut sie aber laut Deinem Plot nicht. Die Kamera wird
vermutlich gar nicht erkannt, denn sonst müßte man noch folgende
Statuszeilen sehen:

ATE0
AT+CMEE=1
AT^SACD=1
AT^SACD=2,"17"
AT^SACD=2,"17,00,2,IQP5 01.05"
AT^SACD=2,"17,04,2,3"
AT^SACD=2,"17,04,OK"
AT^SACD=2,"17,04,2,1"
AT^SACD=2,"17,04,2,2,4897,3545
AT^SACD=2,"17,01,OK"
Wechsele die Datenrate ...

Wo liegt nun das Problem?
1. Untersuche, ob die Versorgungsspannung der Kamera einbricht.
2. Leuchtet die grüne LED der IQP?
3. Blinkt die grüne LED der IQP?
4. Wie schaltest Du den CTS und RTS Kanal. Möglicherweise vertauscht?
5. Hast Du einen Transistor für den RTS Kanal. Der ist unbedingt nötig,
da hier die Kamera einen nicht unerheblichen Stromanteil bezieht.
6. Sind TX und RX der Kamera richtig mit dem UC verbunden?

Viel Erfolg beim Finden des Problems...
Viele Grüße
Niels

Schön zu hören.

Zur "Geschwindigkeit":
Die Datenübertragung kann auf zwei Arten erfolgen. Die schnellste Art
ist es, die Daten direkt auszugeben. Dabei ist der Haken bei "Direkt" zu
setzen. Dadurch werden die Daten nicht im EEPROM gepuffert.

Du musst Dir das so vorstellen: Jedes Byte, das von der Kamera an den UC
gesendet wird, wird über I2C an den EEPROM gesendet. Da die
Schreibgeschwindigkeit des EEPROMs pro Byte aber bei rund 10ms liegt,
dauert die Übertragung in den Speicher recht lange (5000
Byte*10ms/Byte=50000ms=50 Sekunden).

Wenn Du die Kamera ohnehin "nur" am PC betreiben willst, solltest Du die
Baudrate im Bascomquelltext höher ansetzen und die Daten direkt
ausgeben. Aber im Grunde wären das "Perlen für die Säue", der Sinn der
ganzen Anlage ist es schließlich Datensätze zu normieren, zu paketieren
um diese an beliebige Folgeinstanzen weiterleiten zu können. So ist es
z. B. möglich - neben CSD - die gesamte Datenflut via DTMF zu
übertragen, z. B. im CB-Funk-Bereich (vgl. freie Datenkanäle). RFM
Anwendungen sind ebenfalls denkbar.

Kleiner Anhaltspunkt:
Wenn Du die Bilddaten (640x480, ca. 37 kBytes) auf einer SD-Karte
ablegst:
* 10 Sekunden bei einem Kaltstart
* alle weiteren Bilder ca. 7 Sekunden

Ja das ist klar. Die SD-Karte ist aber nicht mit einem EEPROM
vergleichbar. Schon von der Speicherkapazität unterscheiden sich diese
doch ganz erheblich ...

Spaß beiseite. Natürlich wäre eine MMC-Karte als Speichermedium das
Mittel der Wahl - gerade wenn es um permantentes Aufnehmen von Bildern
ginge. Der EEPROM ist auch mehr aus einer Laune heraus mit in die
Zeichnung aufgenommen worden, und wo er schon mal da war ...

Wenn es um Performance geht, dann empfehle ich ohnehin die Kamera direkt
an den PC anzuschließen. Das Schalten der Steuerleitungen kann man auch
mit Delphi sehr einfach umsetzen. Man braucht dann wirklich nur einen PC
und keinen weiteren Aufbau.

Mir ging es aber eher um die Fernbildübertragung im Rahmen eines SMS
Fernschalters. Daher auch der etwas umständlich anmutende Umweg über die
Platinen (vgl. Ausführungen im PDF).

Ab dieser Version überarbeiteten Version 0.2 sind nun auch alle – bisher
noch nicht beschriebenen – Befehle im „GSM Fern Bild Logger“
funktionsfähig.

·  Bild aufnehmen (Softwareunterstützung)
·  Bildaufnahmeparameter ändern (Softwareunterstützung)
·  Guthabenabfrage (Terminal)
·  Guthabenstand per SMS versenden
·  Guthabenstand aus Speicher auslesen
·  Guthaben automatisch aufladen (nur für ALDI-Karten) (Terminal)
·  Anruf bei frei programmierbarer Nummer (Terminal)
·  Nachrichten auf Display des Mobiltelefons ausgeben
·  Automatisches Einschalten des Mobiltelefons

Nach einiger Zeit des aktiven Testens des am 13.12. geposteten Codes
sind mir bei der Bildausgabe einige "Suboptimalitäten" ;-) aufgefallen.

Bei der direkten Verwendung von Hyperterminal kam es vor, dass zu Beginn
einer Übertragung die serielle Schnittstelle mit den ankommenden
Datenfluten "überfordert" war. Sollte dies der Fall sein, so ist

ab Zeile 327 folgendes einzufügen.

If Eepromspeicherung = 0 Then
Print #1 , "Beginne mit Datenausgabe (D)..."
Print #1 , "CAM_B"
waitms 50
If Ausgabeformat = 1 Then
Print #1 , Chr(255);
End If

Außerdem ab Zeile 391:

If Eepromspeicherung = 1 Then
Print #1 , "Beginne mit Datenausgabe (E)..."
Print #1 , "CAM_B"
waitms 50 
Hoechste_adresse = E_addr
E_addr = &H0010

einzutragen. Damit sollten mögliche Fehler behoben sein.

Als Anregung zum Zusammenbau, liegt im Anhang ein Demobild, das den
Aufbau in einem Vogelhaus zeigt. Keine Sorge: Diese Version kam nie über
eine Betaversion hinaus, da die Energieversorgung, auf Grund des
verwendeten Spannungsreglers, den Akku (Bleigel 4,2 Ah/ 13,2 V) sehr
schnell entludt. Das kleine Bild, ist ein Bild, in einen Spiegel hinein
fotografiert.

Die Guthabenaufladeprozeduren konnte ich bisher 3 Mal nutzen. Sie
funktionieren selbst bei wechselnden Ansagetexten variabler Länge
einwandfrei. Nur beim automatischen Auflegen nach dem Aufladen scheint
es nicht so klappen zu wollen - es erfolgt aber eine Trennung von Seiten
der Kontonummer nach rund 2 Minuten Inaktivität (und damit ist die
Leitung auch wieder frei).

Mehmet Kendi schrieb:
> Wenn Du die Bilddaten (640x480, ca. 37 kBytes) auf einer SD-Karte
> ablegst:
> * 10 Sekunden bei einem Kaltstart
> * alle weiteren Bilder ca. 7 Sekunden

Habe es mittlerweile auf SD-Karte umgestellt - Werte konnten erreicht
werden - allerdings nur fürs Speichern. Das Ausgeben (nach Aufnahme)
dauert abhängig von der Baudrate (gewählt 57,6bps HEXDUMP) direkt zum
PC, also ohne Mobiltelefon, rund 30 Sekunden. Mit SD-Karte geht es aber
wirklich um Längen besser als mit dem EEPROM.


--> Werde die Kiste so umbauen, dass sie in Kombination mit einem
GPS-Logger in regelmäßigen Abständen ein Bild macht, die Position
abspeichert. Platinen dafür sind schon fertig. Fehlt nur noch die
Programmierung. Kommt vermutlich mit eigenem Dateisystem, welches eine
TOC mit 10000 Einträgen umfassen wird. Das entspricht in etwa 500 MByte
bei großen Bildern bzw. 50 MByte bei kleinen Bildern - was wiederum rund
500 km bei Fahrtem mit dem Rad mit einem Bild pro 50 Metern (25km/h-->
1/8Bilder/s) entspricht.

Im Anhang ist ein Teil der überarbeiteten Platinen. Es handelt sich
hierbei um die RS232-I/O-Adapterplatine. Diese Platine, die der
Kommunikation mit dem PC dient, musste dringend erneuert werden, da die
dünnen Leiterbahnen (gerade da im Tonerätzverfahren gefertigt) den
harten Umgebungsbedingungen auf meinem Schreibtisch nicht gewachsen
waren. Die Leiterbahndicke wurde deutlich erhöht, die Platinenabmaße
reduziert. Falls es jemand nachbauen möchte, empfehle ich diese
überarbeitete Version 1.1 zu nehmen. Anbei die Druckdateien und einige
Bilder der bestückten Platine. Gefertigt wurde wie im PDF beschrieben.

Druckgroesse:
Breite: 100 mm
Hoehe: 63.5 mm

Mittlerweile geht die Entwicklung mit der SD-Karte in die Endphase über
- anbei ein Video, dass mit hoher Auflösung (also für die Verhältnisse
der Kamera hoch ;-)) aus insgesamt 280 Einzelbilder zusammengesetzt
wurde.

Durch den Einsatz der SD-Karte wird das Gerät auch für den stationären
Einsatz mit gelegentlicher Abfrage einiger Bilddaten interessant. Der
Vorteil liegt darin, dass nicht permanent eine Datenverbindung
hergestellt sein muss und dadurch Zeiten ohne Aktivität zum
Datenaustausch genutzt werden können.

Ein paar Vorabinformationen zur neuen Version an deren Handbuch ich
gerade arbeite. Es wird sich um eine Kombination fast aller hier bisher
vorgestellten Geräte handeln. Es vereint die Vorteile eines GPS-Loggers,
mit denen eines nicht ortsgebundenen Fotoapparats.

Das Gerät verfügt über ein grundlegend neu entwickeltes Dateisystem auf
der SD-Karte, einen Kameraanschluss, einen Anschluss für externe
serielle Peripheriegeräte, wie z. B. PC oder Mobiltelefon, einen
Anschluss für eine GPS-Maus, sowie einen zusätzlichen Wannenstecker zu
Adapterplatinen, auf denen Schaltelemente untergebracht werden können.

Die Software auf PC-Seite ist in Delphi geschrieben. Im Anhang ein
Screenshot, auf denen man im Groben erkennen kann, was alles möglich
sein wird, u.a. Imageerstellung von eingelegten SD-Karten, direkte
GPX-Datenerzeugung. Export zu bereits entwickelten und vorgestellten
Matlabkomponenten, Bild/ Positionszuordnung mit interaktiver Führung.
Klickt der Benutzer beispielsweise, auf der sich aufbauenden Karte, auf
einen Punkt, so wird das passende Bild zur Position angezeigt.

Weiterhin lassen sich alle Mobiltelefonfunktionen nutzen. Die
Bildqualität (Komprimierung) kann nun von Stufe 2 auf Stufe 3 und 1
gestellt werden.

Anbei ein paar Bilder der neuen Software (Ansicht wird noch optimiert
...), Ausschnitt aus GoogleEarth an der Position - die in der Software
angezeigt wird - und ferner ein Bild der Prototypenplatine (die
Endversion liegt erst im PC vor).

Fazit: Interessante Kombination mit universellen Einsatzgebieten in
modularer Bauweise.

Anbei noch der Link zur neuen Version:
Beitrag "Universelles vollautomatisiertes Foto System (GPS GPX BILD SMS GSM)"