Embedded Linux und die Verwendung in QRP Geräten

Du.. wegen der Kohle : Die ist bei mir natürlich auch immer ziemlich knapp.
Deswegen werde ich erst mal das Board heute abend oder morgen bestellen, und dann wenn ich die ersten Pings durchgelaufen sind,
und ich das erste AFU-Prog dort kompilieren konnte, dann werde ich hingehen, und wahrscheinlich ein 4,3" Display bestellen. Einfach deshalb, weil ich KPSK für das erste erreichbare Ziel halte.
Aber ohne Display z.b. kann ich ja schon mal erste erfahrungen sammeln, ob z.b. SDR mit der vollen bandbreite (40kHz) läuft.
Jetzt rächt es sich, das ich schon seit Jahren keinen TV mehr besitze... denn den Videoausgang, hätte ich gern mal getestet...

Später dann, werden auch eventuell die kleineren Display's interessant..
z.B. um meine Olle Seefunke zur Smart-Funke umzurüsten.. mit Faullenzer-CQ-Rufer, Packetradio... und das ganze dann mit einem sehr günstigen 320*240 Display, und nen 20Eur Mini-Board.

lg JAn

Hallo,
irgendwie weiß ich nicht so recht, was ihr für ein Board bestellen wollt. Könnt ihr hier mal eine Zusammenfassung geben. Ich überlege ob ich da mit machen soll. Habe ja von euch gelesen, dass Linux nicht so schwer ist. Welche Version nutzt ihr dafür?

Jubel !
Noch einer ! Ich glaub, das wird noch ziemlich lustig !
Kurz : Die OLinuXino Boards von http://www.olimex.com/dev/ sind angedacht.
Ich habe übrigens schon angefangen mal eine Zusammenfassung und Strukturierung von dem ganzen Threat, Mails, etc.. zu schreiben.
Aber lass mir noch ein paar Stunden oder ein paar mehr Stunden Zeit. (Gerade kam ein Anruf von wo ganz anders)
Jedenfalls will ich das so Struckturieren, das man zu Unterthemen direkt schnell stellung beziehen kann.

lg Jan

Ich bin auch noch dabei und lese mich gerade in QT ein...

LG Nico

Die Leute, die hier die ganze Zeit von Framebuffer und Stromverbrauch und miesen Auflösungen reden, schauen sich mal bitte kurz an, wie hochauflösende 3D-Grafik auf Tablets aussehen kann.

DD1TS : Es sprichts nichts dagegen das Modul via WLAN an ein X-Beliebiges Tablet dranzutütteln..
Deswegen z.B. war ich auch auf der Suche nach einem Toolkit das die Apps sowohl resourcensparend auf einem Display zaubern kann, das nicht primär dazu geeignet ist Weibchen zu beindrucken,
Aber auf Wunsch in der Lage ist, das via Netzwerk (X) zu tun. Dann kann man im gegensatz zu einem Tablet dort immer noch Hardware drantütteln....
(Total witzig wie sich im Sommer sich manche Jungs mit ihren Spielzeugen im Park/Stadt sichtbar positionieren... )

Ok.. ich poste mal die Zusammenfassung.

lg JAn

Kleine VORLÄUFIGE Zusammenfassung von vielen externen Anregungen(von wem was genau, da habe ich den überblick verloren..

Meta-Projekt "AC2" (Ich nenne es dreist wie ich bin, einfach mal so, als Hommage an den AC1) Soll eine Energiesparende, günstige, Opensource Plattform werden, die den grundlegendsten Anforderungen von Funkamateuren gerecht wird.
z.B. ganz wichtig : EMV.
Aber auch eine gewisse Zukunfsicherheit, Robustheit, Erweiterbarkeit, flexibel... kurzum, die Eierlegende Vollmilchsau für die meisten Anwendungen im Amateurfunk.
Damit das ganze alles irgendwie machbar bleibt, wird bei Hard und Software auf vorhandene Opensource-Geschichten zurückgegriffen.
z.B. ist das ARM-Board komplett mit Schaltplan und Layout Opensource. Vorhandene Opensource Programme oder Routinen übernehmen und portieren.
Möglichst einheitliche Plattform haben, damit nicht 10 Hacker an 10 verschiedenen Hardwareplattformen arbeiten. So das Software oder Softwaremodule untereinander austauschbar bleiben.
Das soll der ganze Trick bei der Sache sein.
Oder anders gesagt : Ein PC-Standard auf ARM Basis, speziell für Funkamateur belange.

Zukunftssicherheit z.B. wird durch folgende Faktoren gewährleistet :
Freescale gewährleistet mindestens 10 Jahre Lieferbarkeit des übrigens noch lötbaren Chips.
Layout vom Board ist Opensource, und kann von jedem Hersteller, Distributer, oder von noch echten Männern(hi) in Handarbeit nachgebaut werden.
Ansonsten ist die ARM Plattform mindestens so zukunftssicher wie die X86er Plattform, und weil alles in Sourcecode vorliegt, kann später immer noch zur not das ganze auf eine andere Hardware anpassen.
Das zugrundeliegende Betriebssystem wird wahrscheinlich auch noch weitere 20 Jahre weiterentwickelt werden...
Also kann es gut sein, das die einmal hier reingesteckte Arbeit auch noch in xx Jahren vorhanden sein wird.

Bei der nachverfolgenden Strukturierung bin ich so vorgegangen : 3 Hardware Subprojekte (HW-App 1-3) und darunter Ideen (I1...IXX) danach mögliche Anwendungs- und Softwareideen.
Danach ein paar grobe Allgemeine Ideen bezüglich Software/Entwicklungsplattform...

Da wäre z.B als Applikationen denkbar :
I1 Hardware App 1 : Ein Standalone Rechner mit LCD und USB, für Outdooraktionen mit Amateurfunksoftware für PSK/SSTV/RTTY/CW... etc. (HW-App1).
I2 Oder als Zusatzgerät wie z.B. die Wasserfallanzeige von Elcraft (P3). (HW-App1.1)
I3 Hier ist vor allem die Hardware von der EMV her so in ein Gehäuse zu quetschen,
das man es problemlos an 13,8 +- 20% ZUSAMMEN mit einem TRX an EINER Batterie anschließen kann. Also das dieses gerät keine Störungen verursacht.
Es wäre schön wenn man aber ein wenig Platz für mögliche Erweiterungen lässt (optionales DSP Board, Wlan ).

I4 Als Hardware würde später das iMX233-OLinuXino-Mini in Frage kommen, das 34,95 Eur pro Stück ohne MwSt (hier 19% in Bulgarien 20%) kostet.
(Ab 50 stk, nur noch 27,95) Aber erst in den nächsten Monaten verfügbar ist.
I5 Als Display schlage ich als Kompromiss von Preis, Stromverbrauch, und Ansteuerbarkeit ein 4,3" Display vor. (TFT-Display 10,9cm (4,3) ohne Touch Panel, 480x272 WQVGA farbig natürlich)
I6 Für den Standalone Rechner, schlage ich 2 Eingabemethoden vor :
I7 HW-App1 :. Nur USB-Keyboard und eventuell Maus. (Die Software sollte also so geschrieben sein, das sie benutzerfreundlich ist, und nur mit Tastatur bedienbar ist. Maus/Touchscreen sollte immer optional sein.)
I8 HW-App1.1 : Ein paar Tasten und einen Rotary Encoder (z.b. für Zusatzgeräte wie die Wasserfallanzeige,damit die keine Tastatur benötigen.
Wie man die Taster und Rotary Encoder jetzt am schlauesten anschließt, so das man sie leicht via Software abfragen kann, muss man sich noch genauer anschauen.
z.B. wäre es immer möglich via V-USB aus einem AVR(was immer) einen echten USB-Tastaturcontroller oder ne Maus zu machen.
I9 Bezüglich Tochscreen, würde ich Klärungsbedarf anmelden.
Weil Kapazitive Touchscreens können wahrscheinlich durch einen Sendenen TRX gestört werden.
Bei Resistiven, bin ich mir absolut nicht sicher. Testen, bewerten, entscheiden, ob man das in Zukunft unterstützt.
I10 Beide Geräte würden sich durch ein Wlan-Modul netzwerkfähig machen lassen.
z.b. könnte man dann beide Geräte via Netzwerk mit einem größeren Rechner/Laptop/Tablet ansprechen.
z.b. kann man einen Outdoorrechner auch als Intelligentes Modem benutzen.
I11 Der iMX233 Chip kann übrigens auch direkt von Lithium Batterien versorgt werden ,und könnte diese sogar laden.
Nur habe ich gelesen (hoffentlich richtig) das die Ladefunktion auch zum Teil softwaregesteuert ist ,und das man hier auf 4,2V Systeme beschränkt ist.
Auch wird der Chip dadurch mehr abwärme abführen müssen, und ist auf 500mA beschränkt.
Um z.B. auch LiFePO4 zu unterstützen ,und um mehr "Sicherheit" zu haben, würde ich wenn, dann auf eine externe Ladeschaltung gerne zurückgreifen wollen.
Bei LiFePO4 besteht nämlich die Chance, das die Hersteller recht behalten, und der Akku auch noch in 5-10 Jahren benutzbar ist.
Während all die anderen LiIon Technologien auch gerne mal einfach so rumoxidieren. Wie viele schon sicherlich bemerkt haben.
I12 Der iMX233 kann übrigens auch ein Video Signal bereitstellen. d.H. auch ein noch größeres Video TFT Display liese sich ansteuern, aber nicht HD. Genau Pixelzahlen muss ich nachlesen.

Mögliche Anwendungszenarien in Abfolge der Realisierbarkeit oder was interessant sein könnte :
PSK31 (KPSK das QT-Basierend ist, etwas anpassen und neu kompilieren)
Reine, Logbuch Software.
Wasserfall Display als Zusatz zu einem vorhanden TRX wie den P3. (Wasserfall aus KPSK klauen, und erweitern)
RTTY
SSTV
WeFAX
CW Decoder + Keyer
Packet-Radio Terminal (total simple zu realisieren.. einfach neu kompilieren, fertig.
SDR
SAT-Tracker
APRS
Fonie-CQ-Rufer (noch einfacher zu realisieren. Wie man einen CQ-Rufer programmiert in QT, wäre z.B. ein Tutorial zum einstieg wert. Das ist unter Linux wirklich einer leichtesten Übungen. )
Sprachkompressor..

I 13 : Nur kurz zu den Anwendungen (Apps). Am besten wahrscheinlich in guter alter Unix-Tradition : Mache eine Sache aber die richtig.
Viele kleine separate Apps die sich ähnlich bedienen lassen, eventuell gemeinsame Module nutzen (Logbuch) sind resourcenfreundlicher und wahrscheinlich auch bedienerfreundlicher als eine große.
I 14 : Wenn I-13 gut, dann das später genauer noch mal in einem Usability Konzept spezifizieren.
I 15 : Wenn die Anwendungen "harmonieren" lass die sich später leichter zu einer "Distribution" zusammenfassen, und diese per SD-Kartenimage verteilen. Also mehr ein "freiwilliger Standard".

Also insgesamt, soll so ein Standalone Afu Rechner : Energiesparender, problemloser, flexibler und billiger sein, als ein käufliches fertiges Smartfone für 100Eur.
Problemloser könnte das für Nutzer deshalb werden, weil man z.b. das Teil direkt an den TRX anschließt, und via Netzwerk keine weitere Software auf dem Hauptrechner braucht.
d.H. die Amateurfunksoft läuft auf Modem, der PC ist nur noch ein dummes Anzeigegerät, mit großem Monitor, und Tastatur/Maus.
Viele Treiberprobleme, wie sie mit Windows auftreten können ,würden sich dadurch in Luft auflösen. Pegeleinstellungen würden nur einmal gemacht werden müssen.
Für die Enduser würde man einfach nur noch fertige Images auf SD-Karte anbieten, die man dann nur noch konfigurieren muss. (Call, etc.. ) Ziel : Reinstecken, einschalten, Spass haben.
Aber man könnte das System dank optimalen Netzwerk direkt auch programmieren. Auf ne SD-Karte passt schließlich ne Menge.

Hardware App 2 : Einbaumodul (Vorsicht : Jetzt wirds cracy )

I1 : Natürlich auch so EMV gehärtet, das es zusammen mit einem TRX verbaut werden kann.
I2 : Als Hardware schlage ich hier das iMX233-OLinuXino-Mini oder gar das iMX233-OLinuXino-Micro vor, das 19,95 oder 15,96 ab 50stk erhältlich ist (ohne MwSt siehe oben).
I3 : Als Display könnte wahrscheinlicher ein kleineres Display mit 320*240 pixel geeigneter sein, wenn man z.B. darüber nachdenkt, eine vorhandene Funke "tieferzulegen".
I4 : Als Benutzereingaben, ein paar Taster, und einen Rotaryencoder. Gleiche Fragestellung wie bei HW-App1.1 I8
I5 : Via USB wäre auch wieder WIFI möglich.

Folgendes wäre damit möglich, wenn man etwas Grips in Quellcode umwandelt :
Frequenzanzeige. Mit hilfe von Softwaremodule können DDS, und PLL's angesprochen werden.
+ Optional Bandplanhinweise
+ Optional anzeige eines Wasserfalls.(Welcher Kommerzielle TRX hat da schon ? )
DTMF und CTSS
CQ-Rufer (CW und Fone), man nimmt auf, kontrolliert, und danach lässt man stundenlang den TRX erfolglos CQ-Rufen...
CW-PSK.. Decoder..
SSTV.. (mal eben ein Bild vom Setup über den Äther jagen).
AX25 / APRS.
Oder Keyer-Einstellungen für CWisten..
usw...
SDR! Eventuell kann das Board schon ohne DSP aus einem SDR wie Lima-Harzburg-etc.. einen vollwertigen (T)RX machen.

Hardware App 3 : Intelligentes Modem
Also nur einer von den Olimex Boards als TNC oder Router für Digitale Betriebsarten, (Echolink) Repeater, Hamnet.. etc.
Das tolle an diesen Teilen : Sehr weiter Temperaturbereich, geringer Stromverbrauch.
Je nach Board : Unschlagbar günstig im Vergleich zu X86 Hardware.
Achja.. Video-Signal und RS232, für nicht nur Debug Zwecke, haben die iMX233 alle an board.

Teil 2 :

Software :
Bis jetzt zeichnet sich ab, das das QT-Framework folgende Vorteile bietet :
Vorhandene QT-Basierende Software wie KPSK kann leicht portiert werden.
Man kann 2 Versionen Kompilieren : Eine die das Display ohne einen X Server via Framebuffer ansteuert.
Und eine die mit den X-Libs arbeitet, damit man die Software auch über das Netzwerk fernbedienen kann.
Außerdem entstehen so dutzende kleine spezialisierte Apps, die auch auf normalen PC's laufen können.
Es scheinen auch bis jetzt mehr Leute QT-Programmieren können, als Andtroid Apps.
Ob Android-Apps auch über das Netzwerk sich benutzen lassen, weis ich nicht.
Ob es überhaupt Sinn macht Android bei 64MB laufen zu lassen, wage ich zu bezweifeln.
Ob es möglich ist eine QT-Applikation auf einem Android Smartfone zu betreiben.. weis ich nicht.
Es ist von der Programmiererseite möglich, das einzelnen Softwareprojekte einer alleine oder mehrere Zusammen
arbeiten und oder sich gegenseitig helfen können.

Wahrscheinlich haben aber die Programmierer und Entwickler den größten nutzen :
Ein paar die bis jetzt nur Windows kannten, können die vorzüge von /dev/* kennenlernen..
Für andere ist es der erste nicht X86 Prozessor..
Für andere wiederum das erste Embeddet-Projekt überhaupt.
Andere wiederrum könnten auf den Gedanken kommen auch mal in die RealTime-Liga einzusteigen.
usw...
Kurzum, eine Spielwiese in der es viel zu lernen gibt, das man nicht nur im Amateurfunk einsetzen kann.
(z.B. Kommunikation Nutzer->Programmierer (wird meistens durch Pizzagutscheine oder einfach mal Konstruktive Kritik etc.. leichter)).

Ich hoffe, nichts von Euren Ideen-Input vergessen zu haben.. und sorry, wegen der Rechtschreibfehler..
Aber bitte : Gerade jetzt : Immer weiter spinnen. Gerade was die Hardware anbelangt.
Nicht fragen ob man mitmachen kann, einfach mitspielen. Das ist Opensource LadyÅ› and Gentlemen !

Klingt gut: AC2, ein Computer für den Amateurfunk. Für PSK und Co: Einmal Pegel einstellen und fertig. Und dabei preiswert und unkompliziert. Toll! Auf meinem Laptop ist mindestens einmal im Jahr eine neue Distribution drauf (Ubuntu). Danach sind erst einmal alle Afu-Programme nicht mehr richtig installiert. Die Alternative Afu-Knoppix ist zwar super, aber nach ein oder zwei Jahren habe ich dann wieder neue Hardware und alles muss angepasst werden. Mit einem AC2 könnte ich das einfach trennen.

73 Daniel DM3DA

Noch ein paar Eigenschaften dazugesponnen: Ich fände eine Hellschreiberfunktion gut. Feldhell würde reichen. Außerdem wäre es super, einen portablen Speicher zu haben: wie zu Beispiel ein USB-Stick, so dass ein geschriebenes Log leicht gesichert werden kann. Oder in einen anderen Rechner übertragen werden kann.

Nur der Vollständigkeit halber: Wir sollten spätestens bei der Projektbeschreibung zweisprachig werden, also die wichtigsten Sachen auf Deutsch und Englisch beschreiben. Dann bekommen wir vielleicht noch andere Entwickler ins Boot. Wie z. B. Ladislav OK1ZIA. Schau Dir mal die Screenshots von Tucnak an: http://tucnak.nagano.cz/wiki/Main_Page#Screenshots. Das läuft auch völlig ohne X und ist eins der besten UKW-Kontest Logs überhaupt. Vielleicht lässt sich das ja auch auf den AC2 portieren?

73 Daniel DM3DA

Ich bin dabei... AC2 ist ein guter Name für das Projekt. Nun sollten wir uns mal Gedanken machen wer was übernimmt damit nicht alles quer läuft.

Lg Nico

kpsk.... das waren noch Zeiten War mein C++/QT/Kdelibs Lernprojekt, hat aber zum teil um, verbesserungswürdige programmierung. Heutzutage würde ich die fldigi modem Klassen verwenden, und mir ne qt oberfläche davor basteln...

Luc

DM3DA: Was Englisch Deutsch anbelangt, bin ich bei Dir.
Ich werde gleich mal einen Account bei Git-Hub anlegen, auch damit wir demnächst die Olimex Boards günstiger bekommen.
Ich habe mit denen ein paar Mails gewechselt (auf Englisch)... und deswegen :
Nur bei einer Englischen Projektbeschreibung muss ich passen..
Lesen ist kein Problem.. aber schreiben ? z.B. wie Linux Torvalds berühmte Mail :
"Trauerst Du den Tagen von minix-1.1 nach, als Männer noch Männer waren und ihre Gerätetreiber selbst schrieben? [...] Dann ist dieser Post womöglich genau etwas für Dich :-)".
Also im kleineren Rahmen kriege ich noch ne Mail verfasst, und zu 90% weis der dann auch, was ich meinte.. aber mehr traue ich mir da nicht zu.
Meine Rechtschreibung ist schon in Deutsch eine Katastrophe..

dd6vfs : Gute frage .. Also ob wir jetzt schon einen Maintainer(Moderator) brauchen ? Von mir aus.. also wenns nicht zu viel wird, am anfang.. kann ich das versuchen.
Wobei : wichtiger ist es eher, das man jetzt "Step by Step" arbeitet.

z.B. überlege ich mir, wie man am besten einen Standard und dadurch Applikationen ohne Maus hinkriegt.
Folgende Überlegung : Wenn man hingeht, und von HW-App1.1 und HW-APP2 ausgeht, das ein paar Knöpfe und nen Drehencoder besitzt.
Dann wäre folgendes Günstig : Die Knöpfe kann man auch via Tastatur bedienen. z.B. ein Drehencoder der nichts anderes macht wie ein TAB z.B. auf die tasten Bild hoch, Bild runter zu legen, und so das man wie beim Blackberry die Funktionen schnell erreichen kann.
Die idee dahinter ist das "Custom Keyboard mit Rotary encoder" mit V-USB http://www.obdev.at/products/vusb/hidkeys.html zu realisieren.
Das würde aus nutzersicht, die ganze sache sehr vereinfachen, wenn sich alle Programme irgendwie gleich bedienen lassen würden.
Hier meine ersten Gedanken zu dem Thema :
Bild hoch, Bild runter (Rotary-Encoder)= Eingabefelder/Buttons Wechseln.
Enter = Enter..
Pfeiltasten=Pfeiltasten.
Entfernen = Zurrück oder Entfernen.
ESC= App Beenden und rückkehr zum Hauptprogramm.
Also diese Tasten auch als "Mini-Tastatur" für HW-APP1.1 und HA-APP2 nehmen.
Irgendwelche anderen besseren ideen ?

LX2GT : Jubel ! Willkommen am board ! Wenn nicht vorhast mitzumachen : Wir sind die Borg. Widerstand ist zwecklos !
Mal im ernst : KPSK habe ich deswegen erwähnt, weil ich hoffte das am schnellsten unter dem ARM am laufen zu kriegen.
Die Oberfläche braucht nicht viel Platz, und alles basiert auf QT.
Beim ersten durchsehen, habe ich keine KDE-Libs gefunden.. oder war ich blind ?
Die Idee FLDigi in viele kleine Apps zu zerpflücken hatte ich übrigens auch schon. Hatte halt nur gedacht, für eine erste PSK31 App als "Demo" wäre KPSK am schnellsten zu realisieren ?
Ausserdem finde ich das Dein altes Werk schon als Referenz herhalten kann : Mache eine sache, die aber richtig.
Dadurch braucht man nur die "Knöpfe" und Informationen auf dem zu klein geratenen Bildschirm die auch wirklich für die Betriebsart vonnöten sind.

Übrigens : Für mich ist vieles hier Neuland ! OOP nutze ich zwar gerne, aber eigene Klassen zu designen wird mir immer wieder mal gerne verboten, weil die anderen lieber prozeduren haben.
ok.. für meine Webbasierten Datenbanken ist das auch nicht das problem...
Aber QT und C++ das sind dinge in die ich mich wieder reindenken muss. (C++ habe ich schon seit jahren nicht mehr programmiert. C gelegentlich).

lg JAn

Hallo,

Ich frage mal nach.
Für welches Board und das Drumrum hat man sich entschieden?
Welche Entwicklungssoftware wird benutzt?
Welche Funk-Hardware soll benutzt werden?
Wenn man mitmachen soll, wie fange ich womit an?
Sicher habt ihr passende Link jeweils parat.
Jan bist du der ständige Ansprechpartner?

Vielleicht ist es auch zu früh danach zu fragen, dann sag es einfach. Ich warte dann.

Zitat

Für welches Board und das Drumrum hat man sich entschieden?

Also wenn sich die ersten Positionen dieser Preisliste ansieht, zu den iMX233-OLinuXino Boards und mal duchklickt :
http://www.olimex.com/dev/pricelist.html
Dann merkt man, das nur das "teuerste" maxi-Board erst mal verfügbar ist.
Das "mini-Board" finde ich persönlich für verschiedene Projekte ausreichend und ideal.
Von dem her kann es sich lohnen zu warten.
Auch weil die Olimex Leute von den "kostenlosen" Boards für Opensourceprojekte abgerückt sind, weil in den meisten fällen ausser ankündigungen nichts übriggeblieben ist.
Dafür aber haben die versprochen, sobald das hier halbwegs was wird, alles interessierten Entwicklern rabatt zu gewähren.
Und das könnte z.B. die Paypal-Gebühren und einen Teil der Umsatzsteuer ausmachen.

Ich persönlich habe wegen dem Board leider etwas mist gebaut : Die letzten 2 Tage war ich tagsüber ausgenoggt..und konnte es nicht über eine befreundete Firma bestellen.
(Frei nach dem Motto : Habe hier so viel Opensource Software eingesetzt.. jetzt ist es zeit was zurrückzugeben.. *grins*)
Ausserdem meint DHL in Aachen, die sachen nicht immer ausliefern zu müssen, sondern in ihren Packetzentren JWD (Janz Weit Drausen ) bunkern zu müssen.

Drumherum : Also LCD Display muss für den iMX233 einen 8bit Port haben. Reichelt hat zufällig solche im Angebot.
Was ich aber nur dadurch erfahren habe, das ich den eigentlichen Display-Controller nachgegoogelt habe, und mir dessen Speks angesehen habe.

Ich würde empfehlen, hier auch noch zu warten, bis einer der experimentierfreudig genug ist, so ein Display erfolgreich in betrieb genommen hat.
Also ich z.B. bestelle das Display erst, wenn ich ein paar andere Tests am Board abgeschlossen habe.

Andererseits würde ich auch hingehen, und die ersten Erfahrungen dokumentieren.
z.B.
Wie kriege ich ein ganz einfaches Programm kompilliert.
Ob der Prozessor mit SDR prinzipiell zurrecht kommt, und wenn ja, wie gut.
Genau Messung der Stromaufnahme..

Zitat

Welche Funk-Hardware soll benutzt werden?

Für was konret ? Also mich persönlich interessieren 2 Dinge :
1. Einen ultra sparsamen Rechner für PSK und ähnliches.
2. Einen Steuerungsrechner, um aus einer alten Seefunke eine "Smartfunke" zu machen.

Zitat

Welche Entwicklungssoftware wird benutzt?

Bis jetzt scheint es wirklich so, das wir auf QT geinigt haben :
http://qt.nokia.com/
Der rest werden ganz normale gcc comiler sein, die code für den ARM bereitstellen können.

Zitat

Wenn man mitmachen soll, wie fange ich womit an?

Wobei : Jetzt kann man schon mal loslegen : Mit dem QT-SDK lassen sich schon mal programme schreiben, und diese über einen "Virtuellen Framebuffer" auf dem PC testen.
Also wer hingehen möchte um z.B. aus FLDIGI ein PSK/SSTV/oder sonstwasprogramm zu zaubern, der kann jetzt schon anfangen.
Dabei am besten noch die verwendeten Libs aufzählen, und dann später einfach für den ARM compillieren.

Zitat

Jan bist du der ständige Ansprechpartner?

Ich hoffe, das andere auch hilfsbereit sein werden..
Ich denke ich bin eher als klassischer "moderator" gut. Also versuchen aus Bedürfnissen Ideen/Lösungen zu entwickeln, oder entwickeln zu lassen.Ausserdem bin ich um so entspannter und kreativer wenn ich gar nicht mal so "wichtig" bin.

Deswegen nehme ich gerne auch jede Idee auf, und lasse die Diskutieren. Wenn z.B. ein paar leute der Meinung sind QT macht aus LOGISCHEN gründen mehr sinn als Android (anfangs war ich da sehr offen für beides), dann bin ich für QT.
z.B. das Projekt eignet sich sehr gut dafür aufgesplittet zu werden.
z.B. jemanden der sich um eine PSK31 App kümmert.. etc.. etc..

Ig Jan

Hallo Jan,

mit dem Englisch kann ich vielleicht aushelfen, wenn das Volumen nicht zu hoch wird. Wir können ja auch erst einmal sehen, wie weit wir auf Deutsch kommen.

Was mich jetzt interessiert: Was brauchen wir für AC2 Version 0.1? Also, was sind die Mindestfunkionen, die ein AC2 können muss? Stand-alone KPSK? Weniger? Mehr?

73 Daniel DM3DA

Ah.. gut.. Mutter hat sich übrigens, gerade bereiterklärt von der ferne aus mein Deutsch aufzubessern..

Wegen dem ersten Meilenstein :
Ich denke eine Einfache PSK-Standalone-Applikation die also auf einem Display läuft, wie Du vorgeschlagen hast, dürfte für die meisten sogar Optisch "zeigen" :

HEY, da geht was !!!

Ein paar Bilder sagen manchmal echt mehr als 1000 Worte..

Ich bzw mein Freund haben gestern 2 Boards bestellt. Bin mal gespannt, wie lange das ganze dauert, bei der billigsten Lieferoption (AIRMAIL für 5,50).
Leider muss ich auch sagen, das meine Zeit z.Z. arg begrenzt wird. Also in den nächsten Wochen wird das besser.
Aber ich bin dabei mich in GIT einzuarbeiten, studiere Datenblätter zu LCD's, räume meine Bastelecke auf... und mache die letzten Restaurierungsarbeiten an einer CB-Funke für einen bekannten... (Damit das weg vom Tisch ist. )
Aber z.Z. kann ich gerade mal 2 Stunden für das Projekt erübrigen.

Ich freue mich schon aber tierisch auf das Board, und bin mal gespannt, ob man nicht halbe Entwicklungsumgebung direkt dort laufen lassen kann.
(also GUI-Entwicklung unter Linux/Windoof und compilieren, testen direkt auf dem iMX Board. ).

Ein paar interessante Dinge habe ich schon herausgefunden : Das Board hat schon einen "Amtlichen" DC-DC Wandler an Board, so das man es direkt an einer bis zu 16V Quelle betreiben kann.
d.H. damit die geschichte Störungsfrei zusammen mit einem TRX an EINER Bat funktioniert, braucht man nur noch einen Amtlichen Tiefpass.
Also im besten falle, braucht man nur ein paar Kondensatoren, und rund 2-3 Induktivitäten, und dieses Thema ist gefrühstückt.

In den nächsten 3-4 Tagen werde ich allerdings so gut wie keine Zeit haben, da mich meine Eltern sehr in beschlag nehmen werden.

Und übrigens : Olimex hat endlich angefangen, einen Shop einzurichten. Wahrscheinlich werden andere demnächst noch einfacher zu den Boards kommen.
Es wird sich also noch was tun.

lg JAn

Zitat von DG0JAZ

Das Board hat schon einen "Amtlichen" DC-DC Wandler an Board, so das man es direkt an einer bis zu 16V Quelle betreiben kann.
d.H. damit die geschichte Störungsfrei zusammen mit einem TRX an EINER Bat funktioniert, braucht man nur noch einen Amtlichen Tiefpass.

Man braucht wohl eher einen amtlichen DC-DC-Wandler am TRX, damit auch dieser unabhängig von Störungen und Schwankungen arbeitet. Diese Billigsender mit vorsinntflutlichen Anforderungen an die Spannungsquelle gehen mir langsam ziemlich auf den Wecker.

So eine ähnliche Überlegung hatte ich auch mal vor ein paar Jahren..
.. dann allerdings kam ich auf den LiFePO4 tripp, bin darauf hängen gegeblieben, und seitdem ganz zufrieden.
Hintergrund bei mir ist, das ein Schaltwandler der 200 Watt Klasse nicht ganz einfach wird zu realisieren.
Besonders nicht, wenn man auch noch rund 95% Wirkungsgrad haben möchte. (Sonst wirds einfach ZU warm. )
Erst recht nicht, wenn diese dann noch ein Buck-Boost Wandler werden soll. Und diesen Wandler muss man dann noch mit Dicken L und C's ruhigstellen..
Das würde in jeder Hinsicht in eine verdammt interessante Materialschlacht ausarten. Erst recht preislich.
Nur um einen Bleiakku ganz auslutschen zu können...
Und der Bleiakku dankt mir das dann noch mit weniger Nutzbarer Kapazität (da gibts nen netten effekt) und verminderter lebenerwartung, wenn man ihn zyklisch betreibt.
(wenn man nicht gerade einen Akku aus nem Gabelstabler gemopst hat, die sind vom aufbau her wesentlich robuster)
Nicht mit mir.

Mein 16AH LiFePO4 hat eine Entladekurfe wie ein guter alte NiCD d.H. ich habe ne ziemlich lange zeit lang 13,2 V konstant, und erst gegen ende hin, fällt diese ab.
Er ist fast so anspruchslos wie ein Bleiakku, aber weil er mich ein wenig mehr gekostet habe, habe ich ihm einen Balancer spendiert. (ok, wenn ich gegenrechne, gegen rund 24 AH oder mehr AH Bleiakku, eventuell Schaltwandler.. wars gar nicht mal teuerer)
Laut Hersteller könnte man aber auch darauf verzichten.. Weil der Akku ein wenig Überladung abkann.

Und den einzigen Wandler den ich nur ruhig stellen musste, ist dann also der vom Netbook. Und das war mit Schrott aus der Bastelksite zu bewerkstelligen.
Das ganze hat übrigens noch einen Vorteil : Mein Netbook kommt also so nicht auf die Idee über die Zuleitung noch (Stör-)Strahlen zu wollen.
Denn was bringt ein "entstörter" TRX wenn er über die Antenne den ganzen Rotz aufnimmt? Nichts.
Kennst Du diese wunderbaren Computernetzeile, die nichts verbaut haben, was nicht primär dazu dient aus 230V entsprechende Niedervoltspannungen zu machen ?
Also die Netzteile die im ganzen Raum den UKW-Empfang (an Batteriegeräten) zunichte machen ?
Wenn ja, weist Du was ich meine.

Apropo ruhiger Wandler : Der Wandler, der meinen LiFePO4 Akku in der Funkbox lädt, ist ein Sepic Wandler, der angesichts des großen Akkus nicht entstört wurde.
(Ausserdem musste die Kiste einfach mal fertig werden. )
Dafür kann er aber den Akku an Quellen zwischen 5 und 24V (Hatte keine besseren Kondensatoren mehr in der Bastelkiste) Laden(d.H. er spukt konstant 14,4V aus).
Aber irgendwann wird dieser Sepic durch einen wesentlich interessanteren und dann auch ruhigeren ersetzt.
Vorher werde ich den aber noch gegen nen Zeta-Wandler antreten lassen.
Gegenüber den Buckboost mit 4 Fets (Aktive Gleichrichtung) habend diese beiden Wandlertypen übrigens den Vorteil, das sie im Fehlerfalle durch den Koppel-C kein Strom durchlassen.
Ein defekter Buck oder umschaltbarer Buck-Boost mit aktiver Gleichrichtung würde im Worst case fall, die gesamte Eingangsspannung der Schaltung übergeben..

Also : Nicht mosern.. Querdenken.

lg JAn