Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Forum der DL-QRP-AG für QRP und Selbstbau im Amateurfunk. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Samstag, 26. Mai 2012, 09:39

Embedded Linux und die Verwendung in QRP Geräten

Das Thema bezieht sich auf ein anderes Thema hier im Forum: "Das nächste Projekt?" - Ab Beitrag 41 wird über die Usability und den Preis solcher Teile diskutiert. Vielleicht auch mal etwas realisiert?

Zitat

Interessanter wird die Frage nach AD (oder bei diesem Board unnötig) DA Wandlern.

Nein. Das wird geradezu langweilig. Soundchips werden normalerweise per I2S oder ähnlichem angesprochen. Zumindest ist das bei Mikrocontrollern so!

Zitat

Leider habe ich noch keine riesen Ahnung.. aber falls der 700MHZ ARM es schaffen sollte mit einer Samplefrequenz von fast 1MHZ aus zu kommen (700Khz), dann kann das ganze 20m Band (oder andere) komplett im ARM verarbeitet werden.

Nein, auch das ist viel zu viel für den ARM. 700khz Bandbreite bei einer halbwegs hohen FFT Auflösung schafft kein ARM! Das schaffen vielleicht gerade mal Quadcore Prozessoren oder FPGA.

Womit wir beim Thema wären: Ein digitales System hat durch die Fouriertransformation immer eine gewisse Latenz gegenüber den auf die Sprungantwort direkt antwortenden analogen Filtern. Diese Latenz lässt sich durch den Einsatz einer parallelen Implementation und damit einer kürzeren FFT Stage bis auf 1-2 ms herunter drücken, was so ziemlich unhörbar ist. Eine eingebettete CPU hat allerdings nur einen Kern, weshalb hier eine parallele Abarbeitung unmöglich wird. Ich weiß auch nicht, ob die Rechenpower ausreicht um ein halbwegs brauchbares Spektrum hinzubekommen. Bei meinem ExoPC hat es auf jeden Fall nicht gereicht (Atom CPU).

Weiterhin steht die Usability im Vordergrund. Hierzu empfehle ich euch diesen vortrag vom 28c3. Wer ihn nicht sehen will und nur die Quintessenz möchte: Sobald man einen ARM hat, auf dem ein Linuxsystem läuft, ist die Box offen für Spielereien, die der Support vllt gar nicht will. Auf der anderen Seite hat Linux den großen Vorteil, ein ruhiges Gewässer für andere Programmierer darzustellen: Programme und Scriptspracheninterpreter lassen sich sehr leicht auf ein Linuxsystem portieren und man kann bereits fertige Programme kompillieren und sehr schnell nutzen. Bibliotheken gibt es auch genug.

Am Ende bleiben also nur zwei Möglichkeiten: Ein eigenes Embedded System zu entwickeln (Sehr kleine Kosten im GGsatz zum BeagleBoard) oder einen FPGA mit DA Wandler dafür herzunehmen (superviel Entwicklungsaufwand!).

2

Samstag, 26. Mai 2012, 14:18

Hallo Jan!

Hast Du Dir schon einmal den Parallax Propeller angesehen?

http://www.parallax.com/Default.aspx?tabid=407


http://de.wikipedia.org/wiki/Parallax_Propeller


73 und ein schönes Pfingswochenende!
de Nico DD6VFS

3

Samstag, 26. Mai 2012, 14:36

Hallo Nico,


der Propeller ist absolut nicht geeignet, leider. Die Prozessorkerne, die "Cogs" erhalten nacheinander Zugriff auf den Hauptspeicher. Der RAM ist neben Rechenleistung einer der kritischen Punkte einer FFT. Willst du eine FFT implementieren musst du folgendes tun:

  • Werte Samplen und in den Speicher ablegen
  • Von der Zeit in die Frequenzdomäne springen
  • (Evtl Filter applizieren)
  • Inverse Fouriertransformation über den Frequenzbereich laufen lassen
  • Samples nacheinander an den DA Wandler geben


Jeder Schritt benötigt einen Puffer, der - ob man es will oder nicht - nur im RAM liegen kann, weil der RAM der einzige Speicher ist, der schnell genug schreiben und lesen kann. Wenn man nun das ganze Sample auf 8 CPU Kerne aufteilt muss jeder Kern mindestens seinen Samplespeicher haben, den Zwischenspeicher für die Fourierkoeffizienten und den Ausgabespeicher. Wenn man einen Filter darauf anwendet kommt noch einer hinzu.

Nun müssen die Kerne aber immer warten, bis sie wieder an der Reihe sind, was den Vorteil einer Parallelisierung zunichte machen würde.

Ein anderer Ansatz ist es, eine CPU zu nutzen, die schneller als Echtzeit vom Zeit in den Frequenzbereich umsetzt, Filter appliziert und dann wieder in den Zeitbereich umsetzt. Das ist der Ansatz, der bei "normalen" SDR's benutzt wird: Das eigentliche SDR sampelt nur die Werte und schiebt sie über USB (oder wie der Harzburg: setzt sie in ein IQ Signal um) an den Rechner, der dann mit seinem riesigen Hauptspeicher und der schnellen CPU in "schneller als Echtzeit" (dh mehr Werte/s berechnen kann, also gemessen werden) den Output berechnet. Da stellt sich die Frage, ob der OMAP auf dem Beagleboard schnell genug ist. Vom Raspberry PI wissen wir leider auch noch nichts.

4

Samstag, 26. Mai 2012, 15:09

Hallo Jan!

Vielen Dank für Deine erläuterne Antwort. DSV haben wir nur im Studium angerissen da das Spektrum da sehr groß ist. Ich habe mich danach auch nicht weiter beschäftigt. Momentan arbeiten wir in meiner Fortbildung noch etwas damit, da aber mehr auf händischen Rechenweg sowie mit Labview.

In meiner Freizeit arbeite ich mich im Moment in das "Gnublin"-Board ein. Das hat auch einen ARM-Prozessor unter Linux. Aber meiner bescheidenen Meinung nach ist es für DSV gar nicht geeignet. Mann müsste ihm da erst einmal einen DAU und ADU spendieren und diese per SPI oder I²C ansprechen. I²C kann nur maximal 1MBit die Sekunde und für SPI hab ich im Moment keine Daten zur Hand. Also nix mit hoher Datenübertragungsleistung.

Ein anderer Gedanke wäre es mehrere µC zu nutzen und diese per Dual-Port-RAM zu verbinden. Da wäre aber der Aufwand wahrscheinlich zu groß.

In diesem Sinne

73 de Nico
DD6VFS

5

Samstag, 26. Mai 2012, 15:35


In meiner Freizeit arbeite ich mich im Moment in das "Gnublin"-Board ein. Das hat auch einen ARM-Prozessor unter Linux. Aber meiner bescheidenen Meinung nach ist es für DSV gar nicht geeignet. Mann müsste ihm da erst einmal einen DAU und ADU spendieren und diese per SPI oder I²C ansprechen. I²C kann nur maximal 1MBit die Sekunde und für SPI hab ich im Moment keine Daten zur Hand. Also nix mit hoher Datenübertragungsleistung.

Ich habe mich letzte Woche einmal darüber informiert. Aus der Reihe gibt es den LPC3250, den du dir mal angucken könntest: http://www.nxp.com/documents/data_sheet/LPC3220_30_40_50.pdf
Der wäre wohl schnell genug. Ein dicker Nachteil ist das BGA mit dem er angeschlossen wird. Das macht selbst eine Einmalbestückung unmöglich. Da steigen die Kosten für's bestücken lassen in schwindelerregende Höhen. Vielleicht habe ich aber auch die Möglichkeit, das im Reinraum der Hochschule zu machen. Da steht eine Maschine, mit der Man BGA und wesentlich kleinere Bausteine (die ohne Package) platzieren kann. Da könnte ich mal nachfragen, wenn wir uns auf das festlegen.



Ein anderer Gedanke wäre es mehrere µC zu nutzen und diese per Dual-Port-RAM zu verbinden. Da wäre aber der Aufwand wahrscheinlich zu groß.

Nein, das ist auch wieder unpraktikabel. Der beste Ansatz ist meiner Meinung nach ein einzelner Prozessor, der die komplette FFT macht oder ein FPGA. Wobei ich bei beidem relativ wenig Erfahrung im programmieren habe. Da müsste man sich mit den Softwarejunkies auseinander setzen.

Auch eine Möglichkeit wäre dieser Chip hier, den man wenigstens noch selbst löten könnte: http://www.youtube.com/watch?v=zY9aEIHem-4
Das Board selbst ist günstig und ein ADC mit ein paar MSPS lässt sich sicher noch finden. Dazu müsste dann noch eine schnelle UART zum embedded System implementiert werden, was normalerweise kein Problem ist, mit dessen Hilfe dann ein Wasserfalldisplay angesteuert wird.

Ideen?

6

Samstag, 26. Mai 2012, 17:07

Hallo Jan!
Der wäre wohl schnell genug. Ein dicker Nachteil ist das BGA mit dem er angeschlossen wird. Das macht selbst eine Einmalbestückung unmöglich. Da steigen die Kosten für's bestücken lassen in schwindelerregende Höhen.
Ich denke mal das das mit dem Löten vom BGA weniger das Problem ist, nur brauchst du für das Teil eher eine Mehrlagenleiterplatte. Diese lässt sich nur in großen Stückzahlen zu einem vernünftigen Preis herstellen.

Auch eine Möglichkeit wäre dieser Chip hier, den man wenigstens noch selbst löten könnte: http://www.youtube.com/watch?v=zY9aEIHem-4
Das Board selbst ist günstig und ein ADC mit ein paar MSPS lässt sich sicher noch finden. Dazu müsste dann noch eine schnelle UART zum embedded System implementiert werden, was normalerweise kein Problem ist, mit dessen Hilfe dann ein Wasserfalldisplay angesteuert wird.

Ein STM-32 wäre schon interessant zumal sich der im LQFP "noch" löten lässt. Das Board ist wirklich günstig ca. (12,60€). Der STM32F407VG hat ja auch sehr vieles nützliches als I/O vorhanden. Ich schaue mir mal heute Abend oder morgen früh die Datenblätter an.

73 de Nico
DD6VFS

7

Samstag, 26. Mai 2012, 17:25

TI Ticker

Hallo,

das kam diese Woche über den TI Ticker:

Zitat

Ultra-High Speed ADCs Revolutionize Radio ArchitecturesPin-compatible 10-bit, 12-bit, and RF-Sampling ADCs from 500 MSPS to 3.6 GSPS
Increasing system capacity while reducing board size, weight, area, and cost are familiar challenges for any radio designer. Texas Instruments' portfolios of 10- and 12-bit GSPS and RF-sampling analog-to-digital converters (ADC) deliver an integrated solution that solves all of these design challenges.

TI's breakthrough ADC12Dxx00RF ADCs are the industry's first direct RF-sampling ADCs that can directly sample frequencies beyond 2.7 GHz at up to 3.6 GSPS with excellent dynamic performance. The ADC12Dxx00RF replaces multiple analog components with a single chip, allowing radio designers to increase system capacity and flexibility while reducing board size, weight, and cost and simplifying the design process.

Featured Products
* ADC12Dxx00RF – Industry's first 12-bit direct RF-sampling GSPS ADC family
* ADC12D1x00 – Industry's fastest 12-bit ADC GSPS family
* DAC3482 – 16-bit 1.25 GSPS digital-to-analog converter (DAC)

73 de Uwe
DC5PI

8

Samstag, 26. Mai 2012, 18:28

Zitat

ob die Rechenpower ausreicht um ein halbwegs brauchbares Spektrum
hinzubekommen. Bei meinem ExoPC hat es auf jeden Fall nicht gereicht
(Atom CPU).
Äh... welche Software nutzt Du ?
Also FLDIGI läuft selbst auf dem kastrierten EEEPC 701 (533MHZ).
SSB habe ich noch nicht getestet..

Zitat





Weiterhin steht die Usability im Vordergrund. Hierzu empfehle ich euch diesen vortrag vom 28c3.
Wer ihn nicht sehen will und nur die Quintessenz möchte: Sobald man
einen ARM hat, auf dem ein Linuxsystem läuft, ist die Box offen für
Spielereien, die der Support vllt gar nicht will. Auf der anderen Seite
hat Linux den großen Vorteil, ein ruhiges Gewässer für andere
Programmierer darzustellen: Programme und Scriptspracheninterpreter
lassen sich sehr leicht auf ein Linuxsystem portieren und man kann
bereits fertige Programme kompillieren und sehr schnell nutzen.
Bibliotheken gibt es auch genug.
Ähmm... genau deswegen würde ich offenes Linux-System Bevorzugen ? Amateurfunk ? Nicht kommerzielle angelegenheit ? Basteln ?
Bei all den SDR-Zeugs ist basteln nicht mehr nur Hardware, sondern auch Software.
Eine Technologie, die auch für andere Zwecke (QRL) von nutzen sein kann. Also nichts was nur den reinen Zeitvertreib darstellt.
1920 war es noch so, das Amaterfunk gerade mal war : 3 Röhren unter misachtung sämtlicher VDE Richtlinien verbauen, und dann mit CW versuchen über den Acker zu kommen (zuvor hat man festgestellt das funkensender zu sehr nerven)
Heute ist das Feld weiter. Mann kann zwar immer noch Röhren unter Mißachtung sämtlicher Normen verbauen.. aber man kann auch nen DSP + Mosfet einsetzen. Oder ne Kiste kaufen, oder oder oder...
Auch das mit dem Netzwerk, was um die Jahrundertwende noch händisch gemacht wurde, kann man heute in Technik giesen.

Und Wenn irgendein Hersteller etwas nicht supporten will, was er nicht verbrochen hat, dann muss er das auch nicht.
Hash des Images ? Aha.. tut mir leid.. wir supporten nur unveränderte Images..
Ach.. das Gerät funktioniert wieder, wenn sie unsere originale SD-Karte reinstecken ? Prima ! Dann schönen Tag noch.

Zitat


Am Ende bleiben also nur zwei Möglichkeiten: Ein eigenes Embedded System
zu entwickeln (Sehr kleine Kosten im GGsatz zum BeagleBoard) oder einen
FPGA mit DA Wandler dafür herzunehmen (superviel Entwicklungsaufwand!).
Also nachdem D05PI diese netten Chips vorstellte.. musste ich an den Pactor Controller denken :
CPU + DSP.

Also erst mal ein ARM Board so hinbiegen, das es die Grundlegenden Dinge für einen HAM kann...
Damit man schon mal spass hat.
.. und später nen DSP mit AD/DA Wandler drantütteln.
Dieser braucht dann auch kein Flash, er bekommt sein Programm immer frisch vom ARM.
Und der ARM weis auch genau was er von dem DSP will.
Und der DSP liefert dem ARM dafür, fein zurrechtgeschnittene Rohdaten.. z.B. nen kleinen Audio-Stream, mit SSB oder PSK31 signalen..

lg JAn

9

Samstag, 26. Mai 2012, 19:43

Hey Jan,


ich nutze fldigi - Die CPU überhitzt alle paar Minuten und schaltet ab.


Ich sehe bei einem ARM Board das Problem, dass man die beiden Komponenten später einfach nicht mehr zusammenbringt. Ein direkt auf der HF sampelnder ADC erzeugt einen Datenstrom, der nurnoch mit einem FPGA/DSP gebändigt werden kann. Wenn die höchste Empfangsfrequenz 30 Mhz beträgt, dann muss mit mindestens 60MSPS gesampelt werden (Nyquist - Shannon Theorem) das macht 60M Werte bei beispielsweise 14bit Auflösung -> 100MB/s. Nicht falsch verstehen, mich macht das als Funkamateur total heiß, aber ich bin mir als Nachrichtentechniker leider auch der Risiken, bzw der Probleme viel zu bewusst. :(

Zitat

Also erst mal ein ARM Board so hinbiegen, das es die Grundlegenden Dinge für einen HAM kann..

Was stellst du dir genau vor? :)


Zitat

Also nachdem D05PI diese netten Chips vorstellte.. musste ich an den Pactor Controller denken :
CPU + DSP.


Da hätte ich absolut Lust drauf, doch in der Hochschule habe ich mitbekommen, wie schwer es ist einen DSP zu programmieren. Drei Leute saßen mehrere Monate an einem einfachen Kammfilter.

10

Samstag, 26. Mai 2012, 21:26

Zitat

ich nutze fldigi - Die CPU überhitzt alle paar Minuten und schaltet ab.

Ok.. sprich weiter.
Ich habe hier einen EEEPC 701Ĝ und einen Samsung NC10. An jeweils nur den eigenen Monitoren. Beides verdammt coole Kisten.
Das einzigste was ich am NC10 doof finde, ist das sich der Akku seit anfang 2010 nun verabschiedet hat.
Wo ich erwartet hatte, das durch die niedrige Temp, der Akku länger halten müsste, als bei einem Hitzköpfigen Notebook...
Bei anderen NC10 Usern soll der Akku aber schon seit 2009 noch nahezu die volle leistung bringen...

Achja.. und Compiz bei Ubuntu abgeschaltet.
Also "Gnome Classic ohne effekte". Mit Compiz, schafft es selbst mein X2 mit nigelnagelneuer 60EUR Graka auf meinem Samsung 2343 Monitor ein Video ruckelfrei in Vollbild darzustellen.

Eine überhitzte CPU hatte ich zuletzt bei einem Medion Notebook das nen 2,4GHZ P4 intus hatte. Der lüfter lief so stark, das der Kühlkörper immer schnell verdreckt war.
Dann wurde alles instabil. Ausserdem haben die Elkos gelitten.
Austausch der defekten Bauteile + Runtertakten auf 1,6 GHZ brachte dann brauchbares Notebook zum vorschein.
Das war mir wichtig.

Zitat

Was stellst du dir genau vor? :)

PSK31.. RTTTY... also alles das was man mit der Soundkarte auflesen kann..
Ax25 wird schon sowieso vom Kernel unterstützt..

Zitat

Da hätte ich absolut Lust drauf, doch in der Hochschule habe ich mitbekommen, wie schwer es ist einen DSP zu programmieren. Drei Leute saßen mehrere Monate an einem einfachen Kammfilter.

Erst mal keine Angst . Angst tötet den Geist.
Kann ja immer noch sein, das die 3 Leute nur so getan haben, und in Wahrheit im Biergarten waren. Und damit keiner doofe fragen stellt, gestöhnt haben, das das sooo schwierig sei. ;-)
Was ich an DSP's gesehen habe, ist das das einfach nur spezialisierte Controller sind.
Ich habe mal ein wenig nach den Algos der Weaver Methode ( SSB ) umgeschaut ,und gemerkt, das das so schwehr gar nicht mal ist.
Aber das wäre wieder ein viel weiterer Schritt...

z.B. frage ich mich immer noch, welches Display vernünfig ist.
Ich Idiot habe eben verpennt, als ich beim strahlenden Sonnenschein im Baumarkt war(strippen für Hühnerleiter kaufen) mein Blackberry mitzunehmen.
Dann hätte ich ja sehen können, ob so ein Display für sowas taugt.
Also die grösse von meinem Blackberrydisplay finde ich, bei entsprechender Zeichengrösse für sehr gut ablesbar. Nur der in der Sonnetest, fehlt noch.

Wegen der Usability, kam mir gerade in den Sinn, wenn man z.B. für PSK31 2 Fliegen mit einer klappe erschlagen möchte, nämlich lesbarkeit, und Wasserfall, dann könnte man ja 2 umschaltbare "Fenster" haben.
1. mal nur Text (empfang und gesendet) und einmal nur Wasserfall + emfpang.

lg JAn

11

Sonntag, 27. Mai 2012, 15:46

Hallo liebe Mitleser und -schreiber!

Um noch einmal auf das ursprüngliche Thema zurückzukommen, ich habe mir mal das Datenblatt vom STM32F405XX angesehen. Ich bin am überlegen, ob ich mich damit auch etwas näher beschäftige. Von der Grundidee würde ich einen µC mit Embedded Linux oder einem RTOS benutzen. Zur Signalverarbeitung könnte man einen DSP nehmen der auf einer Zwischenfrequenz arbeitet. Das arbeiten auf der Empfangs-/Sendefrequenz denke ich wäre zu aufwendig. Als Display würde ich ein normales nehmen und die Tastatur extra ansteuern (nicht als Touchpad). Der erste Schritt wäre erst mal ein Board mit dem µC, DSP und Peripherie zu entwickeln. Das sollte man dann erst einmal versuchen zum laufen zu bekommen.

Was meint Ihr dazu?

73 de Nico
DD6VFS

12

Sonntag, 27. Mai 2012, 20:40

Hi.

Das Thema reizt mich auch immer mehr, obwohl ich wirklich nicht im sommer programmieren wollte.
Wegen dem Board :
http://www.olimex.com/dev/index.html
bzw http://www.olimex.com/dev/imx233-olinuxino-maxi.html

Lies mal ganz genau : Alles ist hier GPL ! Selbst das Board. (Was übrigens auch bedeutet, das sämtliche änderungen auch darunter fallen. )
Das einzigste was ich noch nicht weis, aber da lese ich mich gerade ein, ist, wie man ein xxx*xxx Pixel Display ansteuert.
Aber es scheint, als würde da schon was in richtung Framebuffer gehen.
Dann kann man schon fast auch X Applikationen andenken.
z.B. ein abgespecktes FL-DIGI.
Gui anpassen, kein Window-Manager... könnte klappen.
Mein erster Linux-Rechner hatte auch nur 48MB... und da war ein vollständiges X drauf.

DSP würde ich wirklich erst im 3. Schritt als Modul andenken.
So könnte man im ersten schritt relativ schnell ein Digitales Modul entwickeln, was die Grundlegenden Funktionen beherscht, was ggf weitere zum mitmachen anregt, was wesentlich günstiger wird als das NUE PSK aber dafür mehr leistet !
Und die Hardcore-SMD-ler können sogar dieses Board sogar selbst bestücken.

Wobei .. so ein DSP könnte natürlich noch viel bewegung in noch ganz andere dinge bringen : z.B. breitband Datenfunk (hamnet userzugang) auf 70cm. Also auf 5 GHZ gewinne ich bei meinem QTH dort keinen Blumentopf.... :-(
Aber wie gesagt, ein DSP als optionaler "CO-Prozessor"... wäre schon ein ding. Direkt via Netzwerk Programmierbar..(Für die Spielkinder unter uns... )

lg JAn

13

Dienstag, 29. Mai 2012, 08:35

Hallo zusammen

Ich habe gerade gesehen dass ihr einen neuen Thread auf gemacht habt.....

wir verwenden für unsere Linux basierten Firewalls diese kompletten Mini-ITX Boards
http://www.pcengines.ch/alix1d.htm

Laufen mit verschiedenen Linux Versionen oder auch Windows XP, haben einen I2C Bus, Audio, CF, TFT LCD Buchse, etc.
und eine RS232 um den TX zu steuern, brauchen aber ca. 4 Watt im Betrieb
73 de Thomas
HB9RML

14

Dienstag, 29. Mai 2012, 09:09

Mal ne ganz blöde frage zu dem Board :
Wieviel kostet das ?
Lässt sich der Stromverbrauch eventuell durch runtertakten noch reduzieren ?
Oder durch nicht aktivieren von nicht benötigten komponenten ?

Wenn es nur klein sein soll, habe ich schon Atom-Boards der 50Eur klasse gesehen : http://www.hiq24.de/products/Mainboards/…D425-18GHZ.html

Aber ein günstiger Preis wäre mir da schon wichtig. Sosnt würde ich weiterhin auf meinen EEEPC 701 schwören (11Watt mit LCD und Backlight, Wlan, etc.. ) und lieber ein paar Akkus mehr dran machen.

lg Jan

15

Dienstag, 29. Mai 2012, 09:33

Die Frage, die ich mir stelle ist: Passen diese Boards wirklich in einen Transceiver?

Eine weitere Frage ist: Wollen wir versuchen, etwas selbst zu bauen? Wie wollen wir es angehen? Großer DSP mit A/D Wandler und lediglich ein ARM zur Steuerung und zur Anzeige des ganzen (Display, DAC)?
Oder lieber doch ein komplettes Linux auf dem ARM und ein kleiner DSP/Tayloe Detektor, der lediglich das Signal in ein IQ Signal umsetzt, welches dann per I2S zum Linuxsystem durchgeroutet wird?

Ein ARM braucht definitiv weniger als 1Watt. Mit der ganzen Peripherie sind wir optimistisch geschätzt bei 4 Watt (incl ADC + evtl DSP).

(Man merkt schon - Ich bin heiß auf DIY. Alleine kommt man da aber keinen Meter weit :))

16

Dienstag, 29. Mai 2012, 09:46

Variante 2 gefällt mir am besten : Denn hier kann man ganz in ruhe Schritt für Schritt arbeiten :
1. mal board ans laufen kriegen...
2. Display dran tütteln..
3. X (frambuffer) zum laufen kriegen..
4. Fldigi oder andere Software so abändern, das sie mit dem kleinen Display harmoniert..
... ab hier wäre schon ein wichtiger Meilenstein erreicht : Ein System das PSK und andere Betriebsarten(CW.. SST.V.. zu dem Bruchteil der kosten von Nuepsk beherscht. )
5. sich langsam gedanken über DSP machen...
6. ...
7 ...
8 ...
9 ...
Modul an bieten, das z.B. 400KHZ direkt verarbeiten kann.

Die Lösung hat sogar den vorteil, das man über das Netzwerk mal eben neuen Code testen kann.
Also sehr elegant.

Also ich habe beschlossen nachdem ich hier ein paar kleinere projekte fertig habe, mir so ein OpenSource ARM Board zu holen, und in der zwischenzeit überlege ich mir gelegentlich welches Display wohl am vernünftigsten wäre...
Und wie man das ansteuert.
Und diese überlegung sollte wirklich mit sorgfalt geschehen. Doof wird es nämlich wenn jeder OM eine andere Pixelanzahl hat.
Das macht das Programmieren, dann noch umständlicher.

lg Jan

17

Dienstag, 29. Mai 2012, 10:08

Bevor wir das dann tun, sollten wir uns auf ein Board einigen, das sich jeder beschafft!

Andere Boards, andere Verbinder und Standards. Ich habe hier ein Board, das ein LVDS Interface hat, welches ich locker mit Linux ansteuern kann. Andere Boards haben vllt ein anderes Interface.

Möglichkeiten sind:
  • VGA
  • DVI
  • LVDS
  • Generisches LCD Interface #1 oder #2
  • Oder eine der folgenden Prozessorinterfaces die nach aussen geführt wurden:
    • Intel StrongARM/XScale
    • Motorola MX1 Dragonball
    • Motorola MC68K
    • Motorola DragonBall MC68EZ328/MC68VZ328
    • Hitachi SH-3
    • Hitachi SH-4

Habe ich was vergessen?

sollte das Beagleboard die Wahl der Qual sein könnte man dieses hier nutzen: http://www.chalk-elec.com/?page_id=1280#…product=7703686

So schaut das Addon Board für VGS Output vom P3 aus: http://www.elecraft.com/P3/p3_svgapcb.jpg

Erkennen kann man einen Spartan FPGA (VGA Output), einen ROM, um das Programm in den FPGA zu laden und einen dsPIC zur Kontrolle mit einem DSP (AD6620)für die 2048pt FFT.

Der P3 nutzt als Display das http://www.hantronix.com/files/data/1278363262s430-3.pdf
Und als Display Controller den SSD1906.

Keine schlechte Kombination - Und das alles ohne Linux :)

18

Dienstag, 29. Mai 2012, 10:48

Also ich persönlich finde ja das hier sehr interessant : http://www.olimex.com/dev/imx233-olinuxino-maxi.html
Das kann man auch mal eben kommerziell vertreiben, und daran was abändern.(opensource)
Sogar es komplett selbst bauen.
Nur, wie man dort am besten ein Display anschließt weis ich noch nicht... noch nicht.
Aber möglich ist das bestimmt.

Aber von der Leistung und vom Preis her, ist das wirklich top !
z.B. würde das http://www.olimex.com/dev/imx233-olinuxino-mini.html
je nach stückzahl unter 30 Eur kosten.

Soundkarte mit Ein und Ausgang ist für den "ersten meilenstein" und für den zweiten (ssb) schon drin.
wieder ein problem weniger.(rasperry hat nur ausgang.)

lg JAn

19

Dienstag, 29. Mai 2012, 11:03

Der Controller hat laut Datenblatt lediglich ein 8 bit LCD Interface. Soweit ich weiß braucht ein 8080 oder M68K Interface aber 16 bit. Das heißt, ein Display auf diesem Board fällt flach.

20

Dienstag, 29. Mai 2012, 11:17

Du, bei den Displays, habe ich nun gar keine Ahnung... aber Datasheet meint : www.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf

Zitat

Supports full 24-bit system mode (8080/6080/VSYNC/WSYNC). Read-mode is not supported.