Forum: Mikrocontroller und Digitale Elektronik AtMega für SSTV System?


von Voltage (Gast)


Lesenswert?

Hallo.

Wollte mal fragen, ist ein System aus 2 AtMegas für SSTV ausreichend?

Sendeseite:
PAL Framegrabber IC mit SPI Ausgang (Sollte es wohl geben, muss mal 
schauen)
AtMega, der das Bild vom Framegrabber IC einließt, verarbeitet und als 
analoges NF Signal über den DA Port oder R2R ausgibt (Vgl. SSTV)

Empfangsseite:
Ein Mega, der aus dem analogen Signal wieder ein Bild decodiert, und es 
auf einen TFT Display mit integiertem Speicher schreibt.
(Oder es an einen PAL Bildencoder Chip weiter reicht, ka ob es sowas 
gibt)

Außerdem soll der Empfänger die decodierten Bilddaten via RS232 
rechnertauglich ausgeben. Er muss das Bild aber nicht am Stück via RS232 
ausgeben, sondern "RS232 Streaming der auf das Display geschriebenen 
Daten" reicht. Im Rechner kann man das dann als BMP auf die Platte 
speichern für die weitere Verarbeitung.

Denkt ihr, ein ATMega reicht für SSTV?
Gibt es PAL Framegrabber / Encoder IC's? Wenn ja, wie ist die genaue 
Bezeichnung?


Oder wäre ein digitales System mit 1k2 AFSK (Packet Radio) 
besser/einfacher? Müsste dann halt zwei TNC2 irgendwo her bekommen und 
die dann verwenden. Werden glaub nicht mehr gebaut.

Es soll alles via CB-Funk laufen.

von Voltage (Gast)


Lesenswert?

Mit Wlan oder 2,4 GHz Videosendern schaffe ich leider die Distanz nicht.
Mit CB Funk gehts. 1 Bild pro Minute oder noch weniger ist ausreichend 
für eine Webcam.
UMTS Flat für ein Webcam Project ist mir zu teuer.

von Voltage (Gast)


Lesenswert?

Ich bin grade dabei für unsern Obst+Gartenbau und Angelverein eine 
Webseite zu machen und möchte gerne ein Live Bild vom Vereinsgelände mit 
Fischweiher und Grillhütte auf der Webseite haben.

von Lars S (Gast)


Lesenswert?

müsste gehen.
Am einfachsten wäre aber wahrscheinlich, Du nimmst ein Kameramodul mit 
einer RS232 Schnittstelle, dann kannst Du dir den PAL Framegrabber 
sparen.

von Lars S (Gast)


Lesenswert?

Nachtrag: Du könntest sogar ein Modul mit JPG Bilddaten nehmen. Einen 
JPG 8x8 Pixel Block dekodieren, den übertragen. Dann den nächsten. Dann 
bräuchtest Du im Atmel nur die 64 Bytes Bilddaten zwischenspeichern.

von Voltage (Gast)


Lesenswert?

Man könnte wohl hin gehen und die digitalen Daten bei einem JPG 
Kameramodul direkt per AFSK verschicken. Ohne irgend ein Protokoll. 
Einfach nur Checksume. Das reduziert den Overhead. Nach jeder 
Übertragung wird dann die Checksumme geprüft und eventuell neu 
angefordert.

So ein 640x480 Jpg ist, sagen wir mal 40 kB groß.
Würde man mit 2 kbit/s AFSK senden, (2000 Hz=low, 2600 Hz=High könnte 
man z.B. machen) bräuchte man ca 160 Sekunden für ein Bild. Noch ein 
bisschen Overhead eingerechnet, 3 Minuten.
Selbst wenn wegen Fehlern 10 Minuten gebraucht werden, für ne Webcam ist 
das immer noch ausreichend.

von Voltage (Gast)


Lesenswert?

Wie berechnet man eigentlich Checksummen?
Sagen wir, man sendet 200 Byte Nutzdaten, und dann eine Ckecksumme.
Dann wartet der Sender, bis die Gegenstelle entweder "ok" oder "nicht 
ok" sendet und widerholt das Paket gegebenfalls.
Ist das Paket, sagen wir nach 20 Versuchen, immer noch nicht erfolgreich 
bestätigt, wird das ganze Bild abgebrochen.

AFSK müsste eigentlich reht einfach machbar sein. Da kann man sich den 
ganzen KRam wie Bitstuffing, NRZ/NRZI usw sparen.
AFSK könnte man sogar noch diskret aufbauen mit 2 
Tongenerator/Tondecoder.
gibt auch Chips dafür, z.B. FX614. Man muss nur noch den Chip mit Daten 
füttern/Auslesen.
Damit spart man sich, die Codierung/Decodierung im AVR und z.B. die 
Programmierung einer Digital-PLL (Fourier braucht man für die Detection 
von 2 Frequenzen wohl noch nicht).

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.