Lieber Besucher, herzlich willkommen bei: RCLine Forum. 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.

moelski

RCLine User

Wohnort: Brilon / HSK

Beruf: IT Welt

  • Nachricht senden

781

Mittwoch, 16. Februar 2005, 13:16

Moin Thomas & Christian & Rest!

Ich bin hier eben mal durch Zufall vorbeigekommen und lese das es weitergeht. Das freut mich zu hören.

Bei LogView (ihr habt es ja evtl gelesen) geht es auch in großen Schritten vorran, wenn auch im Moment an einer anderen Front. ;) Wir haben jetzt eine wissenschaftliche Grafikkomponente gekauft, die uns in vielen Breichen bessere und ausgereiftere Funktionen bietet. Aber das nur am Rande ...

Wie schaut es denn nun mit der Implementierung einer seriellen Schnittstelle? Das war doch mal im Gespräch. Weil wenn die käme, wäre es ein leichtes, den Logger wieder einzubinden.
Mit dem I2C Interface ist das im Moment etwas problematisch.

Wäre nett wenn ihr euch mal bei mir (oder hier) meldet.
Greetz Dominik

[SIZE=4]LogView - Datenvisualisierung für Modellbauer[/SIZE]
Besucht mal unsere Webseite oder schaut mal ins Forum.

782

Dienstag, 22. Februar 2005, 20:29

ich kann leider nichts zur weiterentwicklung beitragen - jedoch bin ich dabei den minilogger ein bisschen abzuändern und für eine wettermessstation zu verwenden.
da ich aber keine ahnung vom modellbau (außer H0 Modellbahn) habe komm ich schon nicht mehr weiter:
Was soll ich an die anschlüsse des JP2 hängen? eine servoanschlusskabel hab ich in meiner station nicht. Also ich schätz mal eine spannung (wieviel eigentlich?) muss ich dazu hernehmen, aber was nehm ich für RX_in? kann ich nen taster einbauen?

joeloebig

RCLine User

Wohnort: Freigericht

  • Nachricht senden

783

Donnerstag, 24. Februar 2005, 14:34

Hi Schoell13,
so einfach ist es nicht....
Der Logger will auf den Eingang eine Frequenz haben die bei uns in den Empfängern erzeugt wird.
Das ist ein Signal mit min 0.5 ms und max 1.5 ms.
Du hast 2 Möglichkeiten:
Source code umschreiben
eine Servotester anschliessen (sowas gibt es überall im Interenet als Bauplan)

Gruss

Achim

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »joeloebig« (24. Februar 2005, 14:35)


784

Freitag, 25. Februar 2005, 18:24

danke,
das heißt ich schließe einfach so was wie das hier:
http://www.malo-web.de/basteln/servo1/start.htm
dran und das funktioniert auch - oder?

joeloebig

RCLine User

Wohnort: Freigericht

  • Nachricht senden

785

Freitag, 25. Februar 2005, 18:26

jepp

Achim

moelski

RCLine User

Wohnort: Brilon / HSK

Beruf: IT Welt

  • Nachricht senden

786

Montag, 7. März 2005, 13:31

Moin !

Zum MiniLogger gibt es auch hier einen Fred:
http://www.logview.info/phpBB2/viewtopic.php?t=7

Vielleicht können Chris oder Thomas ja dort mal was zu den Fragen schreiben.
Greetz Dominik

[SIZE=4]LogView - Datenvisualisierung für Modellbauer[/SIZE]
Besucht mal unsere Webseite oder schaut mal ins Forum.

thmarx

RCLine User

Wohnort: D-06108 Halle

  • Nachricht senden

787

Montag, 7. März 2005, 14:40

Halllo Dominik,
ich habe Dir was in Dein Forum geschrieben...

@all:

Zitat

Dietrich Meissner:
Ganz am Anfang der Diskussion hatte ich mal geschrieben, dass es vielleicht gut währe wenn ihr euch an das gleiche Protokoll halten würdet, was ich auch für meine Datenlogger verwende.

Ich kann es hier nur nochmal wiederholen. Es gibt bereits funktionierende Software für Palms, PC und vielleicht auch bald für WinCE-Pockets.
3-4 zusätzliche Befehle im Logger würden viele Tage/Wochen sparen die für Softwareentwicklung für Palm usw. sinnlos aufgewendet würden.

Nach längerer Suche habe ich Dein Protokoll bei Yahoo gefunden. Leider sehe ich keine Chance das im Mini-Logger unterzubringen (zumindest mit AVR-Basic als Programmmiersprache, aber der Code ist schon recht effizient).

Zitat

Christian Petry:
Gibts eigentlich auch Verbesserungen beim Drehzahlmesser mit Lichtschranke? (sprich Vermeidung von Peaks?) (sorry falls dazu schon was gepostet wurde, hab die letzen Posts nur überfliegen können)

Nö, ich benutze einen SBL-Mega BL-Controller (Selbstbau ist was feines), der hat einen Impulsausgang zur Drehzahlmessung. Den habe ich über einen Optokoppler mit dem Logger verbunden. Jetzt gibts nur noch peaks wenn auch der Controller nicht weiss wie hoch die Drehzahl ist :nuts: .

Die Erweiterungsplatine befindet sich gerade in der Testphase, sieht aber bisher gut aus. Ich melde mich auf jeden Fall wenns fertig ist.
Kann mir jemand evtl. einen Unitest oder besser Unitest2 leihen, damit ich die Messungen verifizieren kann?


Gruss
Thomas
Thomas Marx

schneemann

RCLine User

Wohnort: 84137 Vilsbiburg

Beruf: EDV´ler

  • Nachricht senden

788

Montag, 7. März 2005, 17:25

zu den Peaks beim Drehzahlmessen:

Ich benutze meinen Logger stationär. Peaks treten nur auf, wenn der der Sensor bewegt wird. Ich hab den mit Kabelbindern festgezurrt und bekomme zu 90% einwandfreie Daten. Leicht Vibrationen vom Motor und der Propellerwind haben noch keinen Einfluss.
Liegt also meiner Meinung nach nicht prinzipiell an der Schaltung, ich werde als nächstes mal eine geschirmte Zuleitung und fest verlötete Anschlüsse verwenden.

789

Montag, 7. März 2005, 21:55

Hallo Thomas,

Das Protokoll was ich in meinem Logger benutze, ist einfacher als Du denkst.
Folgend noch mal ein paar Bemerkungen:

Die Daten sollten prinzipiell bei Telemetrie nicht einfach nur so gesendet werden.
Zwei Dinge wirst Du sowieso machen müssen:

1. Der Empfänger braucht normalerweise etwas Zeit, um sich auf ein Datenpaket einzustellen.
Deshalb sollten vor den eigentlichen Daten erst mal ein paar Bytes gesendet werden die keine wirkliche Information in sich tragen (Header).
Am Ende dieser Bytes muß dann irgend ein vereinbartes Zeichen stehen um zu kennzeichnen, dass folgend die Nutz-Daten kommen.

2. Um Datenfehler erkennen zu können, sollten die Daten mit einer Prüfsumme oder ähnlichem versehen werden.

Wenn Du nun über ein eigenes Protokoll nachdenkst, wird es sicherlich wie folgt aussehen.
1. Sende Header (z.B. AAh, AAh, AAH, AAh)
2. Sende Startzeichen (z.B. 01h)
3. Sende Nutzdaten (z.B. Strom, Spannung, Drehzahl: 0135h, 0047h, 1234h)
4. Sende Prüfsumme (z.B. a3h)

Mein Protokoll hat eigentlich nur eine Ergänzung:
Nach dem Startzeichen sende ich zusätzlich eine Information, um der Bodenstation zu sagen, welche Daten gesendet werden.
Das hat den Vorteil, dass der Logger dann nicht unbedingt ein festes Datenformat verwenden muß.

Folgend ein Beispiel:
Jemand will Höhe, Speed und Spannung am Boden angezeigt bekommen.
Mein Datenlogger läßt sich genau für diese Aufgabe konfigurieren.
Er sendet dann:
1. Header
2. Startinfo
3. Konfiguration (in dem Fall Höhe/Speed/Spannung benutzt)
4. Daten (in dem Beispiel: Höhe/Speed/Spannung)
5. Checksumme

Ein anderer Datenlogger welcher vielleicht von vorn herein nur Spannung, Strom und Drehzahl messen kann, kann natürlich dieses Protokoll genauso verwenden.
Er muß halt nur sagen, welche Daten gesendet werden. Die Palm und PC Programme sollten damit dann klar kommen.

Meine Palm und PC Programme würden z.B. auf folgende Telemetriedaten genauso reagieren, als ob mein eigenen Logger senden würde:
1. Header: ein paar beliebige Bytesn
2. Startkennzeichen: AA 05
3. Config1/Config2: 0B 00 (Strom+Kapazität, Spannung, Drehzahl ein)
4. Daten: Strom / Stromintegral / Spannung / Drehzahl (je 16Bit)
5. Checksumme: 1Byte

Gruß Dietrich

thmarx

RCLine User

Wohnort: D-06108 Halle

  • Nachricht senden

790

Montag, 7. März 2005, 23:37

@all:
Schaltplan und Layout für die Erweiterung sind in der Zusammenfasssung.

@Dietrich:
Ich denke, Deine Ausführungen sind mir soweit klar. Ich versuche mal zusammenzufassen:
Header 5Byte FF 00 03 AA AA (lt. Dokument bei Yahoo)
Start 1Byte 05
Config 2Byte
Strom+Kapazität 4Byte
Spannung 2Byte
Drehzahl 2Byte
Höhe 2Byte
Temperatur 2Byte
Checksumme 1Byte

macht 21Byte, bei 4800 Baud dauert das über den Daumen gepeilt 44ms. Könnte gehen (Der Tiny26 hat kein UART, deshalb muss die serielle Ausgabe in die Hauptschleife passen, Minimal 250ms).

Frage: Wenn der Empfänger eine 05 erkennt, woher weisst er das es sich um ein Start-Byte handelt und nicht einen normalen Wert?

Mein Ansatz sieht/sah etwas anders aus:
alles Manchester codiert,
am Anfang eine Präambel/Header zum Einschwingen des Empfängers:
&B01010101 (ein oder mehrere Byte)
dann ein Start Byte:
&B00101010 -> das ist eigentlich keine gültige Manchester Codierung und wird deshalb als Start erkannt
danach die restlichen Daten wieder in Manchester, (bisher) keine Checksumme

Ich werde mal sehen, was sich machen lässt.

Gruss
Thomas
Thomas Marx

791

Dienstag, 8. März 2005, 14:05

Ups, aber der hat doch ein USI!

ich benutze nur:

Quellcode

1
2
3
Open "comb.1:9600,8,n,1" For Output As #2                   'seriellen Port auf Pin B.1 für Ausgabe öffnen
Print #2 , S                                                'und String ausgeben
Close #2

um meine erhobenen Daten per serielle Schnittschnelle zum Laptop zu Übertragen.
Mehr ist gar nicht nötig.

Ich finde nur gar nicht nötig alle Daten, wie in eurer Firmware, gleichzeitig zu erheben. Den genauen Zeitpunkt kannste eh nicht angeben weil du nicht weisst wie schnell die Drehzahlmessung abgeschlossen ist bzw. wie der Zeitpunkt relativ zur Strom- und Spannungsmessung liegt.
Ich beschränke mich da auf schnell nacheinander und das geht ganz gut, jedenfalls zu meiner Zufriedenheit. Allerdings habe ich auch einen ganz anderen Anwendungsfall da ich nur Daten von einem Motorenmessstand erheben will.

Ich weiss jetzt gar nicht was ich mit dem restlichen Platz im ATtiny26 machen soll....
"Die Deutsche Rechtschreibung ist Freeware, du kannst sie kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
Quelle: GBO

thmarx

RCLine User

Wohnort: D-06108 Halle

  • Nachricht senden

792

Dienstag, 8. März 2005, 15:06

So, ich habs getan! Mit einiger Mühe hat die Telemetrie-Ausgabe kompatibel zum Logger von Dietrich in den Speicher gepasst. Funktioniert auch ganz gut mit dem TelePC -Programm. Heute Abend werde ich mal mit dem Palm probieren.
@Dietrich:
Für Deinen Logger der ersten Generation gibt es ein Palm-Programm extra für Hubschrauber, ist das Datenformat identisch?

Zitat

Ups, aber der hat doch ein USI!
ich benutze nur:




Open "comb.1:9600,8,n,1" For Output As #2 'seriellen Port auf Pin B.1 für Ausgabe öffnen
Print #2 , S 'und String ausgeben
Close #2


Ja, aber den USI musst Du "zu Fuß" programmieren. Bascom benutzt einen Software-UART, d.H. der Controller kann nichts anderes machen während die Zeichen ausgegeben werden. Bei einem Hardwar-UART ist das anders, dem sagst Du nur "sende Zeichen x", dann macht er das im Hintergrund und der Controller kann schon im Programm weitermachen.

Zitat

Ich finde nur gar nicht nötig alle Daten, wie in eurer Firmware, gleichzeitig zu erheben.

??? Gleichzeitig kann ich die Werte sowieso nicht messen, sondern nur nacheinander. Aber ich will die Messungen natürlich nach einem bestimmten Intervall wiederholen, und bis dahin müssen halt alle anderen Sachen in der Hauptschleife (Speichern im EEProm, serielle Ausgabe) fertig sein.

Zitat

Ich weiss jetzt gar nicht was ich mit dem restlichen Platz im ATtiny26 machen soll....

;) einen MP3-Player? oder ein LCD-Display? oder eine Art Servotester zum Ansteuern des Motorreglers?

Gruss
Thomas
Thomas Marx

793

Dienstag, 8. März 2005, 16:21

Zitat

Ja, aber den USI musst Du "zu Fuß" programmieren. Bascom benutzt einen Software-UART, d.H. der Controller kann nichts anderes machen während die Zeichen ausgegeben werden. Bei einem Hardwar-UART ist das anders, dem sagst Du nur "sende Zeichen x", dann macht er das im Hintergrund und der Controller kann schon im Programm weitermachen.


Hmm, könnte schon sein aber eigentlich müsste der Programmoverhead dann doch ein grösserer sein. Bekommt man das auf einfache Weise raus?

Aber egal, was sonst soll der Kontroller denn so tun während er sich langweilt? Wie oft pro Sekunde erhebst du denn einen Datensatz?

LCD hatte ich schon dran aber wozu? Die Daten die ich bekomme sind Rohdaten. Wenn ich die im ATtiny umrechnen will komme ich in arge Bedrängnis mal davon abgesehen das ich das arme Teilchen dauernd neu programmieren müsste nur weil ich an der externen Beschaltung was geändert habe.

Bei mir herrscht strikte Trennung. Der ATtiny ist nur dazu da die Daten zu erheben und der Empfänger dieser Daten muss sie dann interpretieren.

Servotester wäre eine Idee. Ist aber auch nicht gerade das was ich brauche. Eher wohl sowas wie Motor langsam auf max. drehzahl hochlaufen lassen, vom PC gesteuert Kennlinie aufnehmen, Motor wieder anhalten.

Naja, Hälfte Platz hab ich ja noch. Vielleicht bekommt er auch noch ein paar
Lauflichter... ;)


P.S. wie lange dauert es etwa bis du diesen Datensatz im EEprom abgelegt hast?

P.P.S. zu den Lauflichtern kommt mir eine Idee... ;) ich könnte ja, so wie bei den Leuchtstäben die man hin und her schwenken muss, ein paar LEDs auf den Propeller kleben und die Daten sozusagen Live ausgeben. :D
"Die Deutsche Rechtschreibung ist Freeware, du kannst sie kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
Quelle: GBO

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »sidigonzales« (8. März 2005, 16:27)


thmarx

RCLine User

Wohnort: D-06108 Halle

  • Nachricht senden

794

Mittwoch, 9. März 2005, 07:15

Guten Morgen,

zuerst die schlechten Nachrichten: Die Telemetrie-Übertragung zum Palm klappt leider (noch) nicht. Auf meinen Handspring kriege ich die Programme von Dietrich nicht zum laufen, und auf einem Palm III bekomme ich keine Verbindung.

Zitat

Wie oft pro Sekunde erhebst du denn einen Datensatz?
wie lange dauert es etwa bis du diesen Datensatz im EEprom abgelegt hast?

Unterschiedlich, die Zykluszeit ist einstellbar zwischen 0.25 und 4Sekunden. Im EEProm speichern dauert im Moment 40-50ms, hier könnte man die Routinen noch optiemieren bis auf 10ms.



Übrigens, Dominik hat in seinem Logview-Forum auch einen Bereich für den Mini-Logger eingerichtet. Schaut ruhig mal rein, hier gehts gerade um die Zukunft vom Mini-Logger und einem möglichen Nachfolger. Vielleicht sollten wir die Diskussion auch hierher verlagern, dann kann man vielleicht die Übersicht wieder ein bisschen herstellen (getrennte Diskussion Hardware, software, ...)

Gruss
Thomas
Thomas Marx

795

Mittwoch, 9. März 2005, 10:54

Hmm, ist Firmware zur Hardware gehörig oder Software?

Ich finde es eigentlich schade wenn ich 3 oder mehr Foren besuchen muss um die erforderlich Infos für ein und das selbe Projekt zu bekommen.

Aber gut....
"Die Deutsche Rechtschreibung ist Freeware, du kannst sie kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
Quelle: GBO

thmarx

RCLine User

Wohnort: D-06108 Halle

  • Nachricht senden

796

Mittwoch, 9. März 2005, 11:24

Zitat

Hmm, ist Firmware zur Hardware gehörig oder Software?

Firmware ist Software, die zu einer bestimmten Hardware gehört. :nuts:

Demnächst gibts neue Firmware in der Zusammenfassung.

Das mit den verschiedenen Foren stimmt schon, ich wollt's nur mal gesagt haben...

Gruss
Thomas
Thomas Marx

thmarx

RCLine User

Wohnort: D-06108 Halle

  • Nachricht senden

797

Donnerstag, 10. März 2005, 16:43

Zur Auflockerung mal ein kurzes Diagramm, welches ich mit dem Mini-Logger mit ext. Stromverstärker in meinem LMH aufgenommen habe. Aufzeichnungsintervall 0.5Sekunden.

Zur Erklärung:
Die gelbe Linie R stellt die Stellung das Gasknüppels (RC-Kanal) dar, H - Höhe, I und U sollten klar sein. Die Höhenwerte (linke Y-Achse) sind die Rohdaten vom Sensor, stellen also nicht die Höhe in m dar.
Die ersten 15 Sekunden steht der Heli nur am Boden, dann wird der Motor gestartet. Da es sich um einen Dirketantrieb handelt, hat der Regler einige Mühe den Motor zu starten und zieht ordentlich Strom. Auffällig dabei sind die starken Schwankungen am Höhensensor.
Danach steht der Hubi bis etwa Sekunde 60 mit laufendem Motor am Boden. Der Strom ist jetzt ziemlich konstant, der Höhensensor auch wieder.
Danach wird gestartet und erst ein bisschen in ca. 2m Höhe geschwebt (bis Sekunde 90). Da es recht windig war musste ich ziemlich viel mit dem Gasknüppel arbeiten, man sieht gut die Stromspitzen, die mit dem RC-Kanal korrelieren. Die Schwankungen vom Höhensensor sind jetzt wieder stärker! Danach ein kurzer Steigflug (bis Sekunde 120), dann wieder runter und etwas Rundflug (bis Sekunde 230). Ab etwa Sekunde 230 bis Sekunde 260 maximaler Steigflug. Interessant hier das die Stromspitze am Anfang fehlt! (zufällig nicht mit erfasst?) Dann wieder runter und Rundflug. Ab Sekunde 360 bis 380 nochmal "Vollgas" aber diesmal kein Steigflug sondern Speedflug. Deshalb auch kein Höhengewinn. Danach noch Rundflug und irgendwann gelandet.

Was mir auffällt:
[list]
Obwohl der Durchschnittsstrom nur 20-25A beträgt erreichen die Spitzen beim Beschleunigen des Motors fast den doppelten Wert.
Die starken Schwankungen im Höhensensor im Zusammenhang mit den Stromspitzen. Entweder wird der Sensor/Verstärker durch die relative Nähe zu den "Starkstromkabeln" gestört, oder die BEC-Spannung schwankt auch und verfälscht damit die Messungen. Was dazu nicht ganz passt ist, dass die Spannung am Anfang der Beschleunigungsphasen nicht so stark einbricht. Um das zu klären werde ich demnächst eine Aufzeichnung mit einem externen Akku für den Logger durchführen.[/list]
»thmarx« hat folgendes Bild angehängt:
  • Unbenannt.gif
Thomas Marx

thmarx

RCLine User

Wohnort: D-06108 Halle

  • Nachricht senden

798

Donnerstag, 10. März 2005, 17:25

Neue Software (V 2.01) steht in der Zusammenfassung, wäre schön wenn sich jemand meldet ob alles funktioniert.
Thomas Marx

799

Donnerstag, 10. März 2005, 20:39

Boah ey, die Firmware hat sich ja ganz schön verändert seit der 1.x Version.

Machst du die Mittelwertbildung beim ADC weil es bei dir so stark jittert? Ich habe bei meiner Hardware, und natürlich Firmware, nur so ein leichtest schwanken im LSB also voll akzeptabel.
Die 150µS Beruhigungszeit nach dem Umschalten vom ADC haste jetzt auch drinnen.

Was mir aufgefallen ist ist das sich ADC und ACI ziemlich gegenseitig beeinflussen wenn sich einer der Eingänge in der Nähe von einer Begrenzung, also 0 oder 5V, befindet.

Das Konstrukt um den Überlaufzähler vom Timer und den Timer selbst zusammenzufassen hab ich ganz einfach und pragmatisch dadurch gelöst das ich den Überlaufzähler als Long definiert habe, dann 8 mal nach links schiebe und dann dazu den Timerwert, ist ja ein Byte, addiere.
Ist dann natürlich 16bit + 8bit - 4bit also 20bit Auflösung aber das hat sich so ergeben weil ich auch ganz langsame Umdrehungen auflösen muss.
Gut, ich muss dann noch 4 mal nach rechts schieben weil ich den Mittelwert über 16 Hell- Dunkelwechsel bilde... ich muss ja auch nicht alle 0,256S einen Wert ablegen.

Das funktioniert eigentlich zuverlässig.

P.S. ich habe jetzt selbst herausgefunden wie man sich den umgesetzten Quelltext angucken kann. Die serielle Ausgabe ist ziemlich effektiv.
"Die Deutsche Rechtschreibung ist Freeware, du kannst sie kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
Quelle: GBO

Holger Hemmecke

RCLine User

Wohnort: D - Arnstadt

Beruf: Entwicklungsingenieur

  • Nachricht senden

800

Freitag, 11. März 2005, 10:37

Hallo Thomas,

Zitat

Aufzeichnungsintervall 0.5Sekunden.

Zitat

Interessant hier das die Stromspitze am Anfang fehlt! (zufällig nicht mit erfasst?)
Bei der ersten Version meines Loggers habe ich die Werte vom Heli noch im Takt von 50ms erfaßt und zum PC gesendet. Dadurch habe ich auch Regelschwingungsvorgänge sehr gut sehen können, vor allem bei der Antriebskombination Beat 55 und Flyware MaxHeli12 und bestimmten Drehzahlen (siehe Bild).
Die Datenmenge, die dabei anfällt, ist aber schon ganz ordentlich.
Danach habe ich auf 100ms umgestellt und das erscheint mir für meine Anwendungen eigentlich ein ganz ordentlicher Kompromiß zu sein.

Es kann also gut sein, daß Du bei nur zwei Abtastungen pro Sekunde die eine oder andere Spitze nicht siehst.

Gruß, Holger
»Holger Hemmecke« hat folgendes Bild angehängt:
  • LogUI50ms.png
[SIZE=4]LogView - Datenvisualisierung[/SIZE]
Besucht mal unsere Webseite oder schaut mal ins Forum.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Holger Hemmecke« (11. März 2005, 11:16)