Hallo Leute,
Sorry, z.Z. komme ich nur an den Wochenenden dazu, im Forum zu schreiben. Der Thread
ist ja explodiert in der Zeit wo ich nicht hier war ;o)) Hier und da etwas OT, aber okay...
Ich fasse mal meine Antworten und Kommetare personenbezogen zusammen. Das machts
für den einen oder anderen evtl etwas leichter.
@Winfried:
>erst mal danke für Deinen ausführlichen Bericht und die Anregungen.
Gerne geschehen.
>Frage: besitzt Dein USB progger ein config file für den AT89S8252 und ist er umschaltbar
>auf active high reset?
Den Myavr nutze ich hauptsächlich um bei meinen Atmel AVR Projekten den Chip zu
programmieren. Ich habe allerdings noch einige andere JTAG progger hier. Dazu auch
noch einen ISP via Parallelschnittstelle (mit Buffer und polyfuses um den LPT Port
zu schützen). Letzeren kann ich (u.a.) via Ponyprog ansprechen. Dafür gibt es ein
Config-File für den AT89S8252. Dort kann ich auch alle Leitungen einzeln invertieren.
Zusätzlich läßt sich bei Ponyprog die Zeit zwischen Reset und Zugriff auf die ISP
Ports eine Delayzeit einstellen. Gerade beim AT89S8252 scheint das recht kritisch zu
sein, hier min 500mS verstreichen zu lassen bevor man auf die eigentlichen ISP Pins
zugreift (Errratasheet von Atmel).
>Das mit den 9600 bit/s hat andere Gründe:
Aha. Vielen Dank für die Erklärung! Die 9600 reichen ja auch für den Datentransfer zum PC
völlig aus. Es stand halt in der BA, daß der SALT auch 19200 kann.
>- der SALT sendet nach dem Start die A/D-Werte über Funk (diese Funktion ist in den
>ausgegebenen Geräten nur zum Teil implementiert) - siehe Reichweite.
Da würde ich gerne mehr drüber erfahren. Siehe unten.
>Hardware:
>den Piepser könnte man natürlich bei Kommunikation einfach abschalten, so wie ich das für die Bauzeit
>und das Morsen auch mache, aber ich möchte den Zustand akustisch gemeldet bekommen.
Hmm. Das verstehe ich jetzt nicht ganz. Es geht nur um die Zeit während der Programmierung
und der Auswertung. Beim ständigen PIEP .. PIEP...PIEP kann man (okay, ich) nur schwer
konzentrieren ;o))
>Ich klebe ein kleines Stück Tesa auf den Piepser, dann hört man ihn nur noch sehr leise.
Fatal ist es aber, wenn man dann in der Hektik vergißt das Tesa wieder zu entfernen.
Dann wird der Ortungspiepser aber keinerlei Hilfe sien ;o))
>Der Pegelwandler würde nicht 3g wiegen
Ja, war auch eine Übertreibung meinerseits ;o))
>aber er braucht ca. 3-4 mal soviel Strom wie der SALT. Das konnte ich nicht akzeptieren.
Okay, das verstehe und akzeptiere ich durchaus.
>Die ungefilterten A/D-Werte (immer 2 Byte) stehen in der .AL4 Datei. In den oberen 4
>Bit können Marken kodiert sein.
Die .AL4 Datei kann man aber doch nicht mit einem Texteditor öffnen. Die Daten sind ja
dort nicht im Textformat abgespeichert.
>Der Zünder geht auf den externen! ADC, sondern zieht nur den internen Pull Up eines
>Prozessor-Ports auf Low.
Ah so. Du prüfst also nur einen digitalen (true/false) Zustand? Das erklärt warum meine
Finger als "heile" Zünder gelten ;o))
>einstellbare Bauzeit hatten wir auch schon diskutiert, aber nicht für nötig empfunden.
>Modelle, die die LCD Version tragen können, sollten eigentlich so konstruiert sein, daß sie
>weder Bauzeit noch Pyroauslösung benötigen.
Ich bin persönlich kein Freund von Servo Auslösung. Ganz besonders nicht, wenn man dadurch
die strukturelle integrietät des Rohres schwächt. Pyroauslösung halte ich (für mich) die beste
Lösung und ist schon 100,000 fach bewährt. Ich kenne Deine Argumente (zumindest zum Teil ;o))
gegen die Pyroauslösung, da ich sämtliche Threads über alle Salt Generationen mir von a-z
durchgelesen habe. Ich verstehe also Deine Abneigung gegen Pyroauslösung, werde aber
für meine Rocks weiterhin damit arbeiten. Ich weiß nicht, ob Du auch schon mit PyroFLOCKEN
gearbeitet hast (dazu hatte ich mal einen längeren Thread im IMR Forum vor ca. 1,5-2 Jahren
geschrieben). Flocken lassen sich gut dosieren, sind recht alterungbeständig und lange nicht
so gefährlich wie SP. Louis Schreyer hat hierzu auch einige Experimente gemacht und nutzt
sie, so weit ich weiß, nur noch (als Ausstoßladung). Ich habe mit Mitgliedern der ERIG ein
interessantes Gespräch in Bezug auf rein mechanische Auslösung geführt. Mehr als einmal
hat die Mechanik versagt, weil die Zugkräfte am Vorschirm so groß waren, daß der Main nicht
raus kommen konnte. Auch eine Mechanik hat ihre Grenzen (gemeint in Bezug auf sichere
Auslösung).
>und Löcher in Fallschirmen und verdreckte Innenräume gehören der Vergangenheit an.
Die Hitzeentwicklung bei Pyroflocken ist V*I*E*L niedriger als bei SP z.B. Und Verunreinigungen
sind (weil es ein NC Derivat ist) so gut wie keine vorhanden.
>die Periodendauer der Piepstöne zu ändern, halte ich nicht für sehr sinnvoll, da es sich um eine
>charakteristische Kennung handelt.
Wenn aber 3 Rocks mit einem SALT auf ihren Rampen warten, kann man sie so eben NICHT
unterscheiden ;o))
>Ereignis 2:
>In der Bedienanleitung steht, daß das erste Ereignis, das kommt, die Auslösung bewirkt. Da es nur
>einen Zünder für Ereignis 2 gibt, werden die anderen Ereignisse nicht mehr abgefragt. Also kommt
> auch kein 2. Puls wenn schon einmal ausgelöst wurde und es wird auch keine Marke mehr gesetzt.
Okay. letzeres war (für mich) nicht so klar in der Bedienungsanleitung.
>Willst Du einen 3. Fallschirm? 2 Auslösungen für Fallschirme gibt es doch schon - reichen die nicht?
Nein, mir würde es um ein System gehen, welches ein unabhängiges Bergungssystem im Notfall
von einer eigenständigen Elektronik, via einer Salt "Meldung" getriggert, aktiviert werden kann.
Will heißen, gibt mir der Salt einen okay, daß der Vorschirm gekommen ist, wird dieses System
gar nicht erst aktiviert. Sagt mir der Salt, Housten, we have a problem, kann ich einen Schrim
auswerfen, der die Rock abbremst. Der Salt wird ja von den meisten so genutzt, daß am Gipfelpunkt
der Drogue rauskommt und in einstellbarer Höhe der Main. Da ist aber kein Notsystem mit drin
Gut, der Variometer, aber der kann nur entweder Drogue oder Main auswerfen.
>Für zukünftige Anwendungen werde ich ein Erweiterungsboard mit eigenem Prozessor in die serielle
>Schnittstelle einschleifen. Damit kann ich vom SALT aus beliebig viele Kanäle ansteuern und auch
>externe Geräte anschließen. Das ist einfacher, als eine Kodierung über Impulslängen und im Prinzip
>schon verfügbar. In meiner speziellen Version (für Telemetrie) könnte ich dann natürlich auch alle
>Ereignisse melden.
So, und da hast Du mein echtes Interesse geweckt. Was bisher noch kein Altimeter (R-DAS kommt
nahe dran, aber nicht ganz), etc bietet, sind D & A Ein und Ausgänge. Ich plane eine Messelektronik
zu bauen. Hier soll z.B.
- Temperatur
- Leuftfeuchte
- Beschleunigung
- Geschwindigkeit
- Kameraauslöser (Video & Bild)
- Frei programierbare digitale I/Os
- Frei programierbare analoge I/Os
- GPS Sender
- Telemetrie
- LDR (Drehung der Rakete während des Fluges)
- ... usw.
mit rein. Da gäb es z.B. die Möglichkeit, via analogem Eingang einen Dehnungsmeßstreifen
anzuschliessen, um z.B. zu sehen, wie sich das Rohr, die Fins, etc beim Flug verwinden.
Im Ursprung wollte ich eine komplette Elektronik entwerfen, d.h. inkl Bergungselektronik,
aber es gibt schon so viele auf dem Markt, das hier das Rad neu zu erfinden eher eine
Zeitverschwendung wäre
)) Deshalb allerhöchstens ein Notsystem fürs bergen.
@Peter:
Ich verstehe (in Grenzen ;o)) Deine Einwände gegen zu vieles Einstellen. Ich bin allerdings
auch jemand, der gerne alles einstellbar haben möchte. Warum? Nur so gibt es für mich
die Möglichkeit, den SALT (oder was auch immer) mit der für mich optimalen Config auszurüsten.
Ich verstehe durchaus, daß einige Leute mit so etwas überfordert sind (oder es einfach
nicht möchten), Kleines Beispiel aus meiner Berufpraxis in der Schweisstechnik: Ich kann jede
Machine nehmen (egal ob WIG, Elektrode, MAG oder Widerstand oder Bolzenschweissen) und
damit schweissen. Auch dort werden mittlerweile Programme hinterlegt. Diese sind aber in einem
Schweisslabor entworfen und haben NIX mit der Praxis zu tun. Bestimmte Hersteller erlauben es
einem aber sehr tief in das Programm einzugreifen (meistens mit Passwort geschützt) und wirklich
jeden Paramter einzustellen. Durch meine Erfahrung, kann ich an diversen Parametern drehen
und hole IMMER ein (bzw Kundenspezifisches) besseres Ergebniss heraus, als mit den standard
Werten. Die wenigsten Kunden trauen sich da selber was zu machen. Dazu muß ich sagen, daß
ich schon über 35 Jahren mit Elektronik zu tun habe und mich seit 1981 mit Computern beschäftige.
Mich hat auch noch nie ein "geht nicht" vom Hersteller davon abgehalten es doch zu realisieren ;o))
Kurzum, was ich gerne vorschlagen würde, wäre ein Duales System. D.h. der standard SALT
Nutzer hat weiterhin seine normale Oberfläche, aber via (z.B.) Passcode kann man in den
Expertmodus schalten, um dort weitere Möglichkeiten zu konfiguieren. Damit wäre der normale
User nicht überfordert, aber dem Poweruser stehen die Türen weiter offen. Für mich kann eine
Software nie zu komplex werden, WENN die Software alle Fehleinstellungen abfangen kann. Banales
Beispiel beim SALT: Wenn ich bei einer Hardware zwischen Servo und Zünder wählen kann, und ich
mich für Zünder entscheide, dann muß die Software alle Einstellmöglichkeiten für Servo sperren
(tut sie ;o)).
>Es ist auich eine Frage der Produktphilosophie und der Benutzerfreundlichkeit. Welcher normale
>Anwender gibt sich schon gerne mit Firmware und Bootloader ab?
Okay, ich bin vielleicht nicht normal, aber ich würde ein Produkt eher selber Updaten, als alles
ausbauen, einpacken zu müssen, wegschicken, warten, auspacken, checken und wieder einbauen
zu müssen. Für mich ist daß so ähnlich wie die Entscheidung Aerotech oder CTI. Eindeutig für
mich Aerotech. CTI ist klar einfacher, aber auch wie die RTF kits von Estes(usw). Ich würde
auch nie eine Levelprüfung auf CTI Motoren akzeptieren. (bischen OT, ich gebe es zu).
>Ich halte es für fragwürdig, wenn der Benutzer ein Firmware Punktrelease nach dem anderen laden
>muß, um dem Entwickler beim Nachbessern einer unfertigen Software helfen zu müssen.
Hmm. Darum geht es hier nicht. Keiner (besonders nicht ich;o) sagt der SALT ist ein unfertiges
Produkt. Nein, es geht mehr darum, daß eine Vorschlag gemacht wird und viele bzw. auch der
Entwickler sagt "gute Idee" und es wird umgesetzt. Dann ist es schön, wenn man die neuen
Features "gleich" testen kann. Es entlastet doch Winfried auch, wenn er nicht 20 SALTs einer
nach dem anderen Updaten muß, verschicken muss, usw. Das heißt NICHT, daß diese Möglichkeit
weiterhin für Leute, die es nicht können, wollen, oder das Equipment nicht haben, zur Verfügung
stehen soll bzw kann.
>nur sehr selten eine neue Firmware braucht. Idealerweise eigentlich nie.
Richtig, ABER gerade Du als Programmierer weißt doch, daß man eine Bugfree Software
fast nicht rausbringen kann, schon alleine weil es nazu unmöglich ist, zu erproben, zu
was der Endkunde alles fähig ist (sprich DAU-Testing). Ich kenne es von meiner Programmierung
(sei es BASIC, C, SPS, etc), daß man sehr oft auch einfach etwas "liest" in einem
Programm, was man selber geschrieben hat, was gar nicht da ist (ähnlich wie das Korrekturlesen
von eigenen Schriftstücken) bzw. so gar nicht funzen kann.
>Gleiches gilt übrigens auch für die Auswertungssoftware. Ich bringe demnächst eine Verson 3.2
>heraus und greife darin die Anregungen auf, die z.B. hier von Reinhard kamen und auch neulich
> in einem anderen Thread.
Das finde ich gut! Es würde weder mir noch jemanden anderes zustehen, zu sagen da haste
aber Mist programmmiert. Du machst ja effektiv was wir wollen ;o)) Bug und Feature
korrektur bzw. Erweiterung.
>Aber auch da vermeide ich es, mich mit neuen Versionen zu überschlagen.
Klar, daß verstehe ich 100%. Nur es gibt (als Gegenbeispiel) auch nichts schlimmeres,
wenn die Arbeit stagniert und keine Anregungen bzw Korrekturen angenommen bzw
gemacht werden. Von solchen Herstellern nehmen die Leute schnell abstand. Ich glaube
auch nicht, daß die Leute von Dir oder Winfried jedes 2te Wochenende eine neue
Software erwarten ;o)) Außerdem (mir geht es jedenfalls so) ist es doch schön, wenn man
vorhandene Soft oder Hardware so erweitern kann, wie man selber, als Entwickler, nicht
drauf gekommen wäre.
Zu "Zitat":
"Aber der SALT ist ausdrücklich auch als Sportgerät konzipiert, und da ist das nicht empfehlenswert.
Denn da wäre dem Mißbrauch Tür und Tor geöffnet. Darum ist diese Funktion blockiert"
Ist das (ich weiß es ehrlich nicht) wirklich ein Thema? Wenn ich es richtig verstehe, geht es
hierbei um Betrug bei Wettbewerben. D.h. man ändert die Software so, daß der SALT eben
ein paar Meter "dazu schmuggelt" Wenn es darum geht, könnte ein echter Hacker, die original
Firmware auch so manipulieren, daß sie sich wie eine originale gibt, aber eben gehackt ist. Die
Frage ist, macht so etwas jemand? Es ist ja nicht so, daß man bei Wettbewerbsflügen Geldmachen
kann
). Wenn ich den Chip (mit Fuse & Lockbits) so dicht mache, daß es keinem mehr möglich
ist, den Chip zu manipulieren, kann ich auch keine Updates (egal wie) anbieten, es sei den ich
löte jedesmal einen neuen Chip auf. Und AUCH dann, was hindert den Betrüger, den Chip
ebenfalls zu tauschen und dort eine modifizierte FW vom eigenen Typus einzubauen? Da geht
dann wirklich nur die verschweisste Black-Box.
@Louis:
Ich habe zwar (noch ;o) keinen Altimax, aber ich verfolge natürlich Deine Entwicklungen und auch
die Soft (so weit sie sich ohne Altimax nutzen läßt ;o)). Ich begrüsse es sehr, daß Du Userwünsche
so schnell umsetzt. Vor allem gratuliere ich Dir zu der Entscheidung, daß man die FW jetzt vom PC
aus installieren kann. So wie Du es im Ursprung gemacht hast (runterladen und direkt drauf) fand
ich gar nicht gut, da ich hier nicht die Kontrolle habe, wenn ich die neuste Version nicht so gut
finde. Ich sehe Deinen Altimax auch nicht als unfertiges Produkt an. Eher das Gegenteil. Du
bietest dem User die Möglichkeit der Weiterentwicklung an.
In Bezug auf den Bootloader, es könnte sein, daß Reinhard (der Namesvetter aus Östereich) recht
hat und dies mit dem AT89S8252 nicht geht, obwohl ich schwören könnte so etwas im Netz schon
mal gelesen zu haben. Ich habe aber auch keine "Angst" einen µ-Proc zu flashen.
>Die Empfindlichkeit der Zünderprüfung hat bei mir auch schon einmal zugeschlagen, Russ von SP an den
>Klemmen reicht aus für einen erfolgreichen Zünderdurchgang. Das wäre wirklich super, wenn die
>Empfindlichkeit etwas geringer wäre, 1 mA Strom kann man getrost durch einen Brückenzünder geben
Meinst Du jetzt beim SALT oder beim Altimax? Ich würde es nie rein digital prüfen, sondern via A/D
und über einen Meßwiderstand. Den A/D Eingang kann man dann auch noch gegen Gnd Shunten
(einfacher R). Eine analoge Zustandsabfrage rot/gelb/grün (nicht IO / fraglich / okay) ist in meinen
Augen besser, zumal man den Schwellwert jederzeit (also auch nachträglich) verändern kann. Gerade
die digitalen I/O sind (ohne Shunts) sehr empfindlich.
>Es gibt bei derlei Geräten zwei Möglichkeiten:
>Nehmen wir folgenden Fall an:
>Ein Anwender fragt: "Du, kannst Du mir evtl. den Zündertest ganz an den Anfang der Startsequenz
>legen, dann mus sich nicht warten, bis die Zusammenbauzeit abgelaufen ist."
>1. Das wird als sinnvoll erachten, man ändert es in der Software, sammelt aber weitere ein oder zwei
>Jahre lang Änderungen die einem so auffallen oder die von Anwendern gewünscht werden. Dann packt
>man die in ein Update und bietet des den Anwendern an: "Seht her, bei uns ist alles solide, deshalb
>dauert es ein Jahr bis wir Updates machen."
>2. Man ändert das, und packt es 1 Tag später als neue Firmwareversion ins Netz, wer es haben will
>kann es installieren, 10 Sekunden und alle sind glücklich.
>Ich persönlich favorisiere Fall 2.
Es gibt auch noch die Version 2.5 ;o)) Und zwar, daß es eben einstellbar gemacht wird. Der eine
möchte es so, der andere anders. Man kann es NIE für alle unter einen Hut bekommen. Deshalb
mein Vorschlag, macht so viel wie Möglich einstellbar. Meinentwegen unter dem Aspekt Normal
und Expertuser. Damit werden Anfänger nicht verwirrt und Experten können nach Lust und Laune
konfigurieren. Nur so wird eine Hardware WIRKLICH universell einsetzbar.
@Fabian:
>Und wenn du hinter den Schrirm eine Feder machst, die den Schirm noch rausdrückt wenn die Klappe
>offen ist?
Wenn könnte man höchstens die Klappe unter Federdruck setzen. Damit ist aber nicht 100%
gewährleistet, daß der Fallschirm vollständig rauskommt und sich nicht verheddert. Eine Feder
hinter einen "weichen" Schirm zu setzen, halte ich, in Hinsicht auf Ausstoßsicherheit, für nicht
praktikabel.
@Neil:
>Ich kann mir auch vorstellen das es den Entwickler / Servicetechniker Peter Q. entlasten wird. Ich
>sehe ihn auf Flugtagen immer nur hinter seiner Theke Updates durchführen. Er soll auch mal fliegen
>gehen. Ein schöner Nebeneffekt wäre noch, das die aktuellste Software Version schneller real getestet
>werden kann.
Das sehe ich zu 100% genau so wie Du. Es ist ja auch keiner gezwungen die Updates selber zu
machen.
@Tom:
>man kann die Sache auch anders sehen:
Natürlich.
>Ich als Anwender will damit überhaupt nichts zu tun haben.
Es soll ja auch NICHT so sein, daß DU es machen MUßT. Es kann ja auch
weiterhin über Peter oder Winfried gemacht werden. Aber es wäre doch
genauso toll, wenn Dir einer auf dem Flugtag (wo nicht unbedingt Winfried
oder Peter anwesend sind), Deinen SALT mit neuen Features oder Updates
aufpeppt. Das eine schließt das andere doch NICHT aus. Irgendwie habe ich
das Gefühl, als ob dieser Eindruck entstehen soll.
>Vgl. das mal mit dem Steuergerät in meinem Auto. Was juckt mich die Bohne
>ob das Ding nen Bootloader hat oder nicht ? Das Teil soll das tun für das es
>konzipiert wurde. Nicht mehr nicht weniger.
???? Aber wenn Dir jemand sagt. Hey mit diesem Update kannst Du 10%
Spritsparen bei gleicher Fahrweise, dann wäre es für Dich doch auch
interessant oder? Wenn Du aber jetzt Dein Steuergerät ausbauen mußt, und
somit zunächst nicht mit dem Auto fahren kannst, dann zur Werkstatt ABC-Tuning
in Wasweissichhausen fahren (oder die Box hinschicken) mußt, dann
machst Du es (wahrscheinlich) eher nicht. Wenn aber jetzt Dein Nachbar sagt,
hey das kann ich Dir in 10 Minuten machen, dann wärst Du ja blöd (nicht so
gemeint!) es nicht zu tun, oder?
>Sicherheitsupdates sollte es (vgl. Microsoft) eher nicht geben.
Boah, warum Update immer mit Microsoft verglichen wird, ist mir echt
schleierhaft. Auch Linux hat Sicherheits und Memoryleaks (schau Dir die
Forumssoftware an). Da ist es aber "völlig normal" zu sagen release early,
release often. Microsoft ist kein Schrottunternehmen! Nur ist das OS und
die Programme mittlerweile so umfangreich und es wird von 100(!)ten von
Leuten programmiert und da gibt es nunmal Fehler.
>Die Bordelektronik bekommt eine Funktion die in langen Testreihen erst
>mal verifiziert wird, ehe die Elektronik auf den Markt kommt.
??? Und trotzdem gibt es Rückrufe und Updates. Ein Navisystem wird doch
auch upgedatet.... Ich kann ja verstehen, daß jemand keine Updates
machen möchte oder kann oder Angst hat etwas kaputt zu machen,
aber Updates zu verteufeln ist auch nicht richtig. Wenn man das so
liest ist es ja fast wie die Hexenjagd von früher.
>Wenn ich jedoch eine neue Funktionalität haben möchte, dann lasse ich das
>"Upgrade" gerne vom Hersteller machen. Denn nur er kann mir mit Sicherheit
>sagen: Es geht oder es geht nicht. Er hat die Erfahrung,
Nicht böse sein, aber das ist Blödsinn. Entweder funzt das Update (FW brennen),
dann funzt auch der Rest oder es klappt eben nicht, dann geht auch der
Rest nicht. Es kann nicht sein, daß Du eine neue (funktionierende) FW brennst
und plötzlich löst der SALT nicht mehr bei eingestellten +100m aus, sondern
erst bei -100m, weil Du die neue FW nicht richtig geflasht hast.
Und wenn Du so argumentierst, dann darfst Du gar kein Update (also auch
keine Software) machen. Im Grunde genommen, darfst Du KEINEN Altimeter,
Hersteller egal, nutzen. Es können IMMER Fehler drin sein. Hier kann Peter
z.B. (Peter nicht böse sein ;o)) einen Programmierfehlermachen (nur
Vorzeichen) und schon löst, um beim Beispiel von oben zu bleiben, Dein
SALT nicht bei +100m, sondern bei -100m erst aus (OHNE an der FW
etwas zu ändern!).
JEDE Art von Bergung birgt Risken. Eine Motorausstoßladung kann vorher
oder garnicht losgehen. Der Fallschirm kann klemmen, er kann aus der
Verankerung reissen, Batterien können bei zig G's aufhören zu arbeiten,
ein G-switch kann den Start verpassen, und, und und...
>nicht ich, da ich die neue Software ja noch gar nicht kennen kann.
Richtig, aber nur durch das Testen von sehr vielen Leuten, werden Bugs
sichtbar und können beseitigt werden.
>Weshalb also einen Bootloader einbauen, wenn er im Fall des SALT nicht
> nötig ist ? Ich sehe da keinen Mehrwert, eher eine Fehlerquelle (wenn das
>Update nicht richtig durchlief).
FALSCH! Wenn ein Bootloader eingebaut ist, verhindert dieser ein Fehlschreiben
des µ-Proc. Klappt das Update nicht, dann bleibt die FW unverändert.
@Reinhard
>Mir ist es öfters nicht gelungen den SALT auszulesen. Mit ein bisschen Herumspielen glaube ich
>rausgefunden zu haben dass der SALT keine serielle Kommunikation akzeptiert so lange er die Höhe
>auspiepst. In dem Fall gibt der Piepser beim Verbindungsversuch einen Klicklaut von sich und die
Das ist mit der FW 47 swiw behoben. Ich konnte diesbezüglich nichts festellen. Hattest Du
evtl noch eine ältere FW drauf?
>Außerdem habe ich den Eindruck dass die serielle Kommunikation manchmal Fehler zulässt.
>Der "Klassiker" in dieser Hinsicht ist der USB-RS232 Wandler mit einem Prolific Chipsatz (afaik PL-2303).
>Wenn man mit diesem versucht den SALT auszulesen werden ca. die Hälfte der Felder in der PC
>Software ausgefüllt. Die restlichen bleiben leer, ohne dass ein Fehler gemeldet wird.
Mein USB "Wandler" ist gar keiner in dem Sinn, sondern ein ISP Progger auf Basis eines
ATMEL Mega-8. Er emuliert einen USB nach RS-232 Wandler. Benutzt aber für die
Kommunikation zum SALT (oder was man auch immer daranpappt) die Atmel SPI
Hardwarepins direkt. D.h. ich spare mir, dort wo es kritisch ist, einen Wandler.
Aber ich habe (bei korrekt eingestellter Baudrate, Stoppbits, usw) noch keine
Leerfelder gehabt. Der Adapter kostet so um die 30 Ocken und kann eben auch
als Progger genutzt werden. Der Datamode ist sozusagen eine Zugabe (ähnlich
wie den "Rettemich" Modus, wo man verfuste Controller wiederbeleben kann.
>Inwiefern wird bei der Kommunikation zwischen SALT und PC die Korrektheit der
>übertragenen Daten verifiziert?
WISSEN tue ich es nicht, aber ich würde vermuten, daß eine Checksum gebildet
wird. Da kann Peter sicher mehr zu sagen.
Portal > Forum > Raketen Technik > Nutzlasten & Bergungssysteme > LCD SALT Fragen, Fehler und Wünsche
11. Juli 2008 um 00:38]
