Licht auf bestimmte Musik !!!

uwefed:

lgrube96:

...

void loop()
{  // 7 channels are coming in to the Arduino
  if (Serial.available() >= 7) {
   // read the oldest byte in the serial buffer:
   for (int i=0; i<8; i++) {
     // read each byte
     incomingByte[i] = Serial.read();
   }    
  }  
}

MIt " for (int i=0; i<9; i++) {" liest Du aber 9 Byte ein nicht 8 und hast einen Array-Überlauf.

Grüße Uwe

ich dachte ich müsste das auch ändern weil der code für 7 LEDs ja so aussieht:

// Output
int Chan1 = 22;  
int Chan2 = 24;  
int Chan3 = 26;  
int Chan4 = 28;  
int Chan5 = 30;  
int Chan6 = 32;
int Chan7 = 34;



int i = 0;     // Loop counter
int incomingByte[7];   // array to store the 7 values from the serial port

//setup the pins/ inputs & outputs
void setup()
{
  Serial.begin(9600);        // set up Serial at 9600 bps

  pinMode(Chan1, OUTPUT);   // sets the pins as output
  pinMode(Chan2, OUTPUT);
  pinMode(Chan3, OUTPUT);
  pinMode(Chan4, OUTPUT);
  pinMode(Chan5, OUTPUT);
  pinMode(Chan6, OUTPUT);
  pinMode(Chan7, OUTPUT);
  
  
  
}

void loop()
{  // 7 channels are coming in to the Arduino
   if (Serial.available() >= 8) {
    // read the oldest byte in the serial buffer:
    for (int i=0; i<8; i++) {
      // read each byte
      incomingByte[i] = Serial.read();
    }
    
    analogWrite(Chan1, incomingByte[0]);   // Write current values to LED pins
    analogWrite(Chan2, incomingByte[1]);   
    analogWrite(Chan3, incomingByte[2]);   
    analogWrite(Chan4, incomingByte[3]);   
    analogWrite(Chan5, incomingByte[4]);   
    analogWrite(Chan6, incomingByte[5]);
    analogWrite(Chan7, incomingByte[6]);
    
    
    
    
   }
   
}

und dann dachte ich, wenn man die 7 zu einer 8 umändert dann muss man die 8 auch dort einen erhöhen ! :smiley:

danke dafür ! aber es ändert sich leider nichts !

mkl0815:

MIt " for (int i=0; i<9; i++) {" liest Du aber 9 Byte ein nicht 8 und hast einen Array-Überlauf.

Gut aufgepasst Uwe :slight_smile:
Der Punkt im neuen Code war mir gar nicht aufgefallen, da er ja vorher schon richtig war und erst im neuen Code falsch. :slight_smile:
Anstatt ein Byte zuwenig zu lesen, wird nun ein Byte zuviel gelesen, das dann noch nicht mal verwendet wird.
Zumindest sollte sich aber die Blinksequenz geändert haben. :wink:

Achso, das wäre im übrigen eine "einfache" Methode zum debuggen. Erzeuge eine Sequenz in Vixen die immer nur eine LED eine Sekunde schaltet. Die Sequenz sollte bei der ersten LED starten und bis zur letzten durchlaufen. Anhand der "fehlenden" LEDs die nicht leuchten, kann man dann zumindest vermuten wo ein Fehler sein könnte. Nicht schön, aber besser als nix.

Es funktioniert aber leider immer noch nicht und es hat sich auch nichts an der blinksequenz geändert.

ja mit der "einfachen" methode könnte ich das mal testen...mal schauen was dabei rauskommt :wink:

so hab das mal gerade fix ausprobiert, aber es gibt keine gute nachricht:
keine einzige led geht in der richtigen rheinfolge an !

Dann hast Du ein grundsätzliches Problem. Tritt das nur auf, wenn Du mehr als 7 LEDs betreibst, oder ist es egal wieviele LEDs angesteuert werden.
Um dem Problem auf die Schliche zu kommen, würde ich schrittweise vorgehen.
Also erstmal nur eine einzige LED ansteuern mit einer bestimmten Blinksequenz, die Du auch prüfen kannst. (z.b. 1 sekunde an, 1 sekunde aus, 0,5 sekunden an, 0.5 sekunden aus -> langes blinken, kurzes blinken)
Dann siehst Du, das die Sequenz korrekt übertragen wird. Das Ganze dann mit unterschiedlichen LEDs und Channel probieren. Wenn das einzeln auf allen Channels klappt, dann mit 2 LEDs weitermachen.

mkl0815:
Dann hast Du ein grundsätzliches Problem. Tritt das nur auf, wenn Du mehr als 7 LEDs betreibst, oder ist es egal wieviele LEDs angesteuert werden.
Um dem Problem auf die Schliche zu kommen, würde ich schrittweise vorgehen.
Also erstmal nur eine einzige LED ansteuern mit einer bestimmten Blinksequenz, die Du auch prüfen kannst. (z.b. 1 sekunde an, 1 sekunde aus, 0,5 sekunden an, 0.5 sekunden aus -> langes blinken, kurzes blinken)
Dann siehst Du, das die Sequenz korrekt übertragen wird. Das Ganze dann mit unterschiedlichen LEDs und Channel probieren. Wenn das einzeln auf allen Channels klappt, dann mit 2 LEDs weitermachen.

Also bei 7 leds funktioniert noch alles einwandfrei jedoch wenn ich dann 8 anschließe dann spielen alle leds verrückt !
Und das mit dem durchspielen jeder led hab ich mal gerade gemacht (mit 8leds) ,aber das problem is halt keine einzige led geht so an wie man es festgelegt hat !
Ist schon irgendwie merkwürdig ?!

hier bin ich wieder....
Also ich hab mich in den letzten vier tagen nochmal dem problem mit vixen und arduino gewidmet.
Jedoch komm ich auf keinen einzigen lösungplan.
mittlerweile denke ich schon, es würde überhaupt keine Lösung dafür geben !! ( oder ist das vielleicht so???, ich hoffe nicht)

ich will schließlich irgendwann mit der ansteuerung fertig werden damit ich dann mit meinem eigentlichen projekt endlich fortfahren kann....

Ich habe mein bestes gegeben, aber ich glaube weiter komm ich einfach nicht ;( das wirrt mir schon die ganzen tage im kopf herum, wie ich es denn lösen kann !

Weiß hier wirklich keiner wie man das bewältigen kann ???

vielen dank schonmal für die weiteren hilfreichen antworten...

Lorenz

Mit 7 LEDs klappt es doch bereits, also musst Du nur das Problem Lösen, warum es bei mehr als 7 LEDs nicht klappt. Leider kennt keiner Deine Einstellungen in dem Programm das die Daten an denArduino schickt. Evtl. ist da ja schon das Problem. Wie wäre es, wenn Du mit dem Arduino die Daten die da kommen mal mitloggst und ggf. auf einer weiteren Seriellen Schnittstelle ausgibst? Hattest Du nicht einen Mega, oder verwechsel ich da was?
Mario.

mkl0815:
Mit 7 LEDs klappt es doch bereits, also musst Du nur das Problem Lösen, warum es bei mehr als 7 LEDs nicht klappt. Leider kennt keiner Deine Einstellungen in dem Programm das die Daten an denArduino schickt. Evtl. ist da ja schon das Problem. Wie wäre es, wenn Du mit dem Arduino die Daten die da kommen mal mitloggst und ggf. auf einer weiteren Seriellen Schnittstelle ausgibst? Hattest Du nicht einen Mega, oder verwechsel ich da was?
Mario.

Das wüsst ich auch gern :smiley:

Mitloggst ?! Was soll das sein ? ( kenn mich jetzt nciht soo gut aus mit allem)
Kann ich euch dadurch zeigen was bei mir abläuft ? Wie stell ich das denn an ? Sowas habe noch nie gemacht -_-
Ja da liegst du richtig mit dem mega.

Lorenz

Der Mega hat mehr als eine serielle Schnittstelle. Damit kannst Du die zweite Serielle Schnittstelle auch per USB (entspr. Adapter mußt Du aber kaufen) mit dem PC verbinden. Damit kannst Du alles was vom Vixen an den Arduino übertragen wird wieder auf eine serielle Konsole zurückschreiben und Die anschauen ob das was Vixen da schickt auch das ist was Du erwartest. Das meine ich mit "loggen".
Zusätzlich würde ich einfach mal ohne das die Daten von extern kommen alle LEDs geordnet der Reihe nach schalten. Damit kannst Du schon mal sicher sein, das die Zuordnung in Deinem Programm stimmt.

mkl0815:
Der Mega hat mehr als eine serielle Schnittstelle. Damit kannst Du die zweite Serielle Schnittstelle auch per USB (entspr. Adapter mußt Du aber kaufen) mit dem PC verbinden. Damit kannst Du alles was vom Vixen an den Arduino übertragen wird wieder auf eine serielle Konsole zurückschreiben und Die anschauen ob das was Vixen da schickt auch das ist was Du erwartest. Das meine ich mit "loggen".
Zusätzlich würde ich einfach mal ohne das die Daten von extern kommen alle LEDs geordnet der Reihe nach schalten. Damit kannst Du schon mal sicher sein, das die Zuordnung in Deinem Programm stimmt.

Könntest du mir vielleicht einen link schicken wo ich die bekomme ? Ich weis nämlich genau wonach ich da suchen soll ! (gibt es die bei conrad)
Kann man denn damit dann auch wirklich das problem lösen ???

Das Problem wirst Du nicht mit Hardware lösen, sondern durch Analysieren und Beheben des Fehlers. Der USB-Adpater kann Dir helfen, Dein Problem zu analysieren. Wenn Du keine Hardware kaufen willst, kannst Du auch weiter ohne testen, allerdings mit größerem Aufwand.
Du hattest ja schonmal einzelne LEDs getestet und es funktionierte alles mit bis zu 7 LEDs. Kannst Du den Code mal posten mit dem Du getestet hast? Gut wäre auch, wenn Du einmal grob beschreiben könntest (evtl. noch Screenshots) wie Du die Ansteuerung mit Vixen machst. Ich denke die wenigsten hier kennen dieses Programm.
Welche Daten werden gesendet?
Desweiteren fällt mir auf, das Du analogWrite() in Deinem Code verwendest, die LEDs aber nicht an PWM-Ausgängen angeschlossen sind.
Mario.

mkl0815:
Das Problem wirst Du nicht mit Hardware lösen, sondern durch Analysieren und Beheben des Fehlers. Der USB-Adpater kann Dir helfen, Dein Problem zu analysieren. Wenn Du keine Hardware kaufen willst, kannst Du auch weiter ohne testen, allerdings mit größerem Aufwand.
Du hattest ja schonmal einzelne LEDs getestet und es funktionierte alles mit bis zu 7 LEDs. Kannst Du den Code mal posten mit dem Du getestet hast? Gut wäre auch, wenn Du einmal grob beschreiben könntest (evtl. noch Screenshots) wie Du die Ansteuerung mit Vixen machst. Ich denke die wenigsten hier kennen dieses Programm.
Welche Daten werden gesendet?
Desweiteren fällt mir auf, das Du analogWrite() in Deinem Code verwendest, die LEDs aber nicht an PWM-Ausgängen angeschlossen sind.
Mario.

Ja das wär auch zu gut ! :smiley: also bis jetzt lass ich das erst mal mit dem adapter (kommt drauf an wie viel denn so einer kostet?)

also irgendwie hab ich auch in erinnerung das das mit 7 leds geklappt hat, aber ich habe das jetzt noch mal ausprobiert und es funktioniert aus irgendeinem grund nur mit 5...naja...immerhin...also ich habe das jetzt mal nur mit digitalen pins gemacht (aber ändert leider auch nichts;()
also hier der code:

/*
The purpose of this code is to allow the Arduino to use the 
generic serial output of vixen lights to control 5 channels of LEDs. 
Author: Matthew Strange
Created: 14 October 2010
Modifier: Ben Towner
Modified: 19-OCT-2010
Changes: Addition of 20 Digital On/Off Channels - Setup for Arduino Mega 2560

*/

// Digital Output - ChanX=Digital Pin
int Chan1 = 48;  
int Chan2 = 46;  
int Chan3 = 44;  
int Chan4 = 42;  
int Chan5 = 40;  



int i = 0;     // Loop counter
int incomingByte[5];   // array to store the 25 values from the serial port

//setup the pins/ inputs & outputs
void setup()
{
  Serial.begin(9600);        // set up Serial at 9600 bps

  pinMode(Chan1, OUTPUT);   // sets the pins as output
  pinMode(Chan2, OUTPUT);
  pinMode(Chan3, OUTPUT);
  pinMode(Chan4, OUTPUT);
  pinMode(Chan5, OUTPUT);
  
}

void loop()
{  // 25 channels are coming in to the Arduino
   if (Serial.available() >= 5) {
    // read the oldest byte in the serial buffer:
    for (int i=0; i<6; i++) {
      // read each byte
      incomingByte[i] = Serial.read();
    }
    
    digitalWrite(Chan1, incomingByte[0]);   
    digitalWrite(Chan2, incomingByte[1]);   
    digitalWrite(Chan3, incomingByte[2]);   
    digitalWrite(Chan4, incomingByte[3]);   
    digitalWrite(Chan5, incomingByte[4]); 
      
   
   }
}

Wegen Screenshots: ich weiß jetzt nicht genau was ich da zeigen soll...?! also das programm an sich ? wie die benutzeroberfläche aussieht ??
also hier schon mal nen bild davon...(anhang)

Woher soll ich herausfinden welche daten gesendet werden ? brauch man denn da nicht den adapter ?
Wenn du noch weiteres benötigst, dann meld dich einfach...

Ich hoffe das bringt was.

Lorenz

Das Problem ist, das Du nicht weisst, was Vixen da genau schickt. Du schreibst einfach die ankommenden Daten auf das entsprechende Pin. Die Funktion digitalWrite() ist so programmiert, das sie bei einem Wert von "0" den Ausgang auf LOW schaltet und bei allen anderen Werten ungleich Null auf HIGH. Damit sollte es eigentlich klappen. Der Code sieht für 5 LEDs auch erstmal OK aus. Jetzt geht es halt darum herauszufinden, wie das Daten-Protokoll von Vixen aussieht. Das ist aus meiner Sicht die wahrscheinlichste Fehlerquelle. Es reicht ja, wenn zusätzlich zu den Channel-Daten noch irgendwas anderes mitgeschickt wird. Ein zusätzliches Byte bringt automatisch die Sequenz durcheinander.
Hast Du evtl. Zugriff auf ein LCD-Shield, oder irgendwas mit dem man die seriell gelesenen Daten ausgeben könnte?
Welches Plugin für die Ausgabe in Vixen verwendest Du? "Generic Serial protocol"?
Einen interessanten Beitrag habe ich im Vixen-Forum gefunden:

Hi guys, I've been working to integrate Vixen to Arduino for the past few week (using 2.1.1.0 and Arduino ATmega 1280)
I have the common configuration working easily - multiple channels, software PWM = lots of blinky lights, but I know this is where this integration is going wrong. One lost bit or byte and the whole display would be corrupted.
So I though I'd use the tools given.

  • Limit serial channel brightness values to 196 steps, reserving 197 - 255 for control codes (or header / footer for now) (step up the values on the Arduino end)
  • Thus I limited the Max Illumination to 196 (aka 3/4 brightness) - ugly but I can live with that.
  • I then defined the header to use a single byte (255) and footer to use a single byte (254)
  • Sketched up some code in the Arduino to look for these control codes before allowing the 'channel buffer' to be filled, and then expecting the 'footer' code when the buffer was full (and if it wasn't Huston we have a problem)
  • Sounded right, I then proceeded to spend several hours debugging on the Arduino -- grrrr
  • Gave up on the Arduino and began to monitor the com port (sysinternals portmon) - and this was when I discovered that somewhere in the generic serial plug-in it has been decided that the header and footer can only use 'printable ascii' codes (tracked down to Encoding.ASCII.GetBytes piece of code) - if the codes are even accepted, they come out at the other end as '?' or code 063
  • Thus currently we cant 'reserve' any high or low ascii codes to use in the header / footer (aka cant use 0 – 32, or 127 – 255)
    Anyone know how we can amend the source to cater for this?
    Be good to be able to translate the 256 steps of illumination to 196 in the plug-in, and use the remaining bytes as channel markers.
    Or maybe this is already accomplished in another serial based output plugin - I just need to translate the protocol into Arduino Code.
    On an interesting note - the generic serial will not send data when the state of the channels doesn’t change between 'events'
    Been following ctmals videos about how to build a plugin + searching through the MSDN website , just need to change Encoding.ASCII to Encoding.UTF8 and we should be away laughing :slight_smile:

Spannend ist dabei folgendes:

On an interesting note - the generic serial will not send data when the state of the channels doesn’t change between 'events'

Das könnte ein Problem sein, bei Deinen Sequenzen.
Dazu kommt wohl, das nicht alle Werte zwischen 0 und 255 vom "Generic serial plugin" korrekt übertragen werden.
Der Poster verwendet ein Tool "sysinternals portmon", um den seriellen Port zu überwachen, evtl. solltest Du das auch mal machen. Wichtig ist halt, das Du herausbekommst was genau gesendet wird.
Mario.

mkl0815:
Das Problem ist, das Du nicht weisst, was Vixen da genau schickt. Du schreibst einfach die ankommenden Daten auf das entsprechende Pin. Die Funktion digitalWrite() ist so programmiert, das sie bei einem Wert von "0" den Ausgang auf LOW schaltet und bei allen anderen Werten ungleich Null auf HIGH. Damit sollte es eigentlich klappen. Der Code sieht für 5 LEDs auch erstmal OK aus. Jetzt geht es halt darum herauszufinden, wie das Daten-Protokoll von Vixen aussieht. Das ist aus meiner Sicht die wahrscheinlichste Fehlerquelle. Es reicht ja, wenn zusätzlich zu den Channel-Daten noch irgendwas anderes mitgeschickt wird. Ein zusätzliches Byte bringt automatisch die Sequenz durcheinander.
Hast Du evtl. Zugriff auf ein LCD-Shield, oder irgendwas mit dem man die seriell gelesenen Daten ausgeben könnte?
Welches Plugin für die Ausgabe in Vixen verwendest Du? "Generic Serial protocol"?
Einen interessanten Beitrag habe ich im Vixen-Forum gefunden:

Hi guys, I've been working to integrate Vixen to Arduino for the past few week (using 2.1.1.0 and Arduino ATmega 1280)
I have the common configuration working easily - multiple channels, software PWM = lots of blinky lights, but I know this is where this integration is going wrong. One lost bit or byte and the whole display would be corrupted.
So I though I'd use the tools given.

  • Limit serial channel brightness values to 196 steps, reserving 197 - 255 for control codes (or header / footer for now) (step up the values on the Arduino end)
  • Thus I limited the Max Illumination to 196 (aka 3/4 brightness) - ugly but I can live with that.
  • I then defined the header to use a single byte (255) and footer to use a single byte (254)
  • Sketched up some code in the Arduino to look for these control codes before allowing the 'channel buffer' to be filled, and then expecting the 'footer' code when the buffer was full (and if it wasn't Huston we have a problem)
  • Sounded right, I then proceeded to spend several hours debugging on the Arduino -- grrrr
  • Gave up on the Arduino and began to monitor the com port (sysinternals portmon) - and this was when I discovered that somewhere in the generic serial plug-in it has been decided that the header and footer can only use 'printable ascii' codes (tracked down to Encoding.ASCII.GetBytes piece of code) - if the codes are even accepted, they come out at the other end as '?' or code 063
  • Thus currently we cant 'reserve' any high or low ascii codes to use in the header / footer (aka cant use 0 – 32, or 127 – 255)
    Anyone know how we can amend the source to cater for this?
    Be good to be able to translate the 256 steps of illumination to 196 in the plug-in, and use the remaining bytes as channel markers.
    Or maybe this is already accomplished in another serial based output plugin - I just need to translate the protocol into Arduino Code.
    On an interesting note - the generic serial will not send data when the state of the channels doesn’t change between 'events'
    Been following ctmals videos about how to build a plugin + searching through the MSDN website , just need to change Encoding.ASCII to Encoding.UTF8 and we should be away laughing :slight_smile:

Spannend ist dabei folgendes:

On an interesting note - the generic serial will not send data when the state of the channels doesn’t change between 'events'

Das könnte ein Problem sein, bei Deinen Sequenzen.
Dazu kommt wohl, das nicht alle Werte zwischen 0 und 255 vom "Generic serial plugin" korrekt übertragen werden.
Der Poster verwendet ein Tool "sysinternals portmon", um den seriellen Port zu überwachen, evtl. solltest Du das auch mal machen. Wichtig ist halt, das Du herausbekommst was genau gesendet wird.
Mario.

Erstmal vielen vielen dank für deine ganze mühe und so !!!
Also ein LCD-shield habe ich jetzt leider noch nciht hier rumliegen...
Das plugin das ich da von dem programm benutze heißt auch "generic serial", wie du schon meintest.
Ich bin jetzt zwar nicht zu wirklich der beste in englisch, aber in dem beitrag geht irgendwie auch um ein problem mit der ausgabe das da was verrückt spielt und so...richtig ? :smiley:
Ich hab mir dann mal dieses Tool "sysinternals portmon" heruntergeladen, aber bis jetzt funktioniert da noch nichts wirklich weil der den port irgendwie nicht wahrnimmt..aber ich werde schauen ob ich das noch geändert bekomme (hoffe ich!!!)

könntest du mir vielleicht mal ein link von diesem adapter zum loggen geben ?

Lorenz

Ich denke dieser Adapter sollte verwendbar sein:
http://www.komputer.de/zen/index.php?main_page=product_info&cPath=22&products_id=83

@All: Bitte mal einen Kommentar abgeben, ob ich damit richtig liege. Theoretisch sollte man den ja auch an eine der anderen Seriellen Schnittstellen des Mega anklemmen können? RX an RX,TX an TX und GND auf GND, das sollte reichen.

Mario.

mkl0815:
Ich denke dieser Adapter sollte verwendbar sein:
http://www.komputer.de/zen/index.php?main_page=product_info&cPath=22&products_id=83

@All: Bitte mal einen Kommentar abgeben, ob ich damit richtig liege. Theoretisch sollte man den ja auch an eine der anderen Seriellen Schnittstellen des Mega anklemmen können? RX an RX,TX an TX und GND auf GND, das sollte reichen.

Mario.

Okaaay...ich hab mir den adapter ein bischen anders vorgestellt...

Und ich hab nochmal bischen mit diesem programm probiert, aber es wird wahrsheinlich nicht funktionieren. Ich habe daher noch ein paar andere programme für das auslesen wie das hier zB FREE Serial Port Monitor RS232 Communication Software Data Sniffer Analyzer. Aber das hat auch nciht funktioneirt weil da steht immer was port already in use...aber ich such noch weiter und es gibt ja reichlich zu finden.

Lorenz

Softwareseitig wirst du das vermutlich nicht herausfinden können, was da übern Äther geschickt wird. Eine zweite serielle Schnitstelle ist erforderlich, daher auch die Idee mit dem Adapter.
Die andere Möglichkeit wurde schon angefragt: hast du ein LCD, auf dem man die empangenen Daten anzeigen kann?

sth77:
Softwareseitig wirst du das vermutlich nicht herausfinden können, was da übern Äther geschickt wird. Eine zweite serielle Schnitstelle ist erforderlich, daher auch die Idee mit dem Adapter.
Die andere Möglichkeit wurde schon angefragt: hast du ein LCD, auf dem man die empangenen Daten anzeigen kann?

Asoo hab mich nämlich schon gewundert....
Ja ein LCD hab ich jetzt nicht aber könnte ich mir eventuell zulegen oder halt diesen adapter.
Aber ich weiß halt nicht ob man dann das problem zu 100% lösen kann, wenn ja würd ich mit aufjedenfall das irgendetwas von holen.

Lorenz

sth77:
Softwareseitig wirst du das vermutlich nicht herausfinden können, was da übern Äther geschickt wird. Eine zweite serielle Schnitstelle ist erforderlich, daher auch die Idee mit dem Adapter.
Die andere Möglichkeit wurde schon angefragt: hast du ein LCD, auf dem man die empangenen Daten anzeigen kann?

Ich denke schon, das es funktioniert, das legt ja auch der Forenpost nahe. Aber wie kann ich nicht sagen, denn als MAC User kann ich das auch nicht testen, ebensowenig wie das Programm Vixen.
Der Trick wird vermutlich sein was man in welcher Reihenfolge startet. Ich könnte mir auch vorstellen, das das Monitoring Programm eine virtuelle serielle Schnittstelle zur Verfügung stellt, mit der man das Vixen verbindet und sich dann selbst mit der tatsächlichen Schnittstelle koppelt und damit dann in der Mitte sitzt. Aber das ist nur eine Vermutung.

Da das Programm ja kostenlos zu haben ist, könnte jemand auch mal deine Testdatei ausprobieren, um das Protokoll zu entziffern. Gibt hier bestimmt Leute, die (mindestens) zwei FTDIs rumliegen haben. :wink:

sth77:
Da das Programm ja kostenlos zu haben ist, könnte jemand auch mal deine Testdatei ausprobieren, um das Protokoll zu entziffern. Gibt hier bestimmt Leute, die (mindestens) zwei FTDIs rumliegen haben. :wink:

Ja da hast du allerdings recht, aber ich weiß nicht ob da jemand interesse hat das mal auszuprbieren....verschwendet ein bischen zeit so ca. 10 dann läuft das eig.
Mal schauen wer das für mich testet !? :wink: