Dann schmeiss den Kommentar weg und las Dir ständig -1 ausgeben.
Wäre der Wertebereich richtig, könntest Du die -1 merken und hättest das erschlagen.
Aber von mir aus.
18:36:37.382 -> und go
18:36:40.694 -> Neuer Wert auf rc pin=2 ist 0
18:36:40.694 -> pin=4 fire
18:36:40.694 -> pin=4 state=2
18:36:40.879 -> Neuer Wert auf rc pin=2 ist 2
18:36:40.879 -> pin=6 fire
18:36:40.879 -> pin=6 state=2
18:36:40.924 -> Neuer Wert auf rc pin=2 ist 5
18:36:40.924 -> pin=9 fire
18:36:40.924 -> pin=9 state=1
18:36:41.674 -> pin=4 state=3
18:36:41.909 -> pin=6 state=3
18:36:41.909 -> pin=9 state=0
Der serielle Monitor zeigt jetzt nur noch diese Zeilen beim einschalten und diese beim ausschalten an:
18:38:03.922 -> Neuer Wert auf rc pin=2 ist 0
18:38:03.922 -> pin=4 fire
18:38:03.969 -> pin=4 state=0
18:38:04.156 -> Neuer Wert auf rc pin=2 ist 4
18:38:04.156 -> pin=8 fire
18:38:04.156 -> pin=8 state=1
18:38:04.156 -> Neuer Wert auf rc pin=2 ist 5
18:38:04.156 -> pin=9 fire
18:38:04.156 -> pin=9 state=1
18:38:05.136 -> pin=8 state=0
18:38:05.183 -> pin=9 state=0
ok dann lassen wir es oder?
Wenn du eine "Kanalnummer" zur Visuellen Ausgabe wie auf der Funke brauchst, dann nimm einfach die Index-Nummer+1. Ist jedenfalls im letzten Code schon weg 
Ich ahbe gerade noch zwei Ausgange angeschlossen. Dabei habe ich gesehen das wenn ich Kanal 2 betätige, auch teilweise Kanal 4 auf pin 7 mit anspreche. Das scheint wirklich mit einem unsauberen einlesen der Werte zu tun zu haben.
Und jetzt schalte ich pin 3 mit scharf?
mit der Seriellen Ausgabe müsstest du erkennen obs von der Funke schon so kommt. Ich wette ja.
Zusatzfrage: kannst damit leben oder willst daran arbeiten?
eigentlich eher daran arbeiten. Das unsaubere Signal hat in der Vergangenheit leider schon öfters dumme Sachen gemacht 
ich versuche gerade wieder die pwm Signale auf den seriellen auszugeben. Der Wert steht doch in der pulselength oder?
ja da soll das Rohe Ergebnis drinnen sein.
Mein Ansatz wäre folgender: Das Signal muss mindesetens 300ms anliegen, bevor es als gültig erkannt wird.
Dann sollten kurzzeitige Ausreißer nicht ins gewicht fallen. Passt das mit deinen Erkenntnissen aus der Seriellen Schnittstelle überein?
Erklär mir noch wie du eigentlich auf der Funke aus den 8 "Subkanälen" auswählst? du musst da einen Poti ca in den jeweiligen Bereich stellen oder wie sieht das aus?
ich muss kurz meine Kids fertig fürs Bett machen, dann schreibe ich das ausführlich.
ich fang mal hinten herum an
Meine Funke hatte 2 Kanäle an dem je ein Poti hing ( Kanal 5 und 6 an der Funke). Das Poti ist bzw war ein 5k wenn ich mich recht erinnere. Die beiden Potis habe ich rausgeworfen. Dann habe ich mir je vier 1-0-1 Taster in Reihe gebaut und diese mit wiederständen ähnlich diesem Bericht bestückt:
Da ich ja zwei Kanäle mit einem Poti hatte sind eben 2x4 Taster draus geworden. Vier hängen an dem Kanal 5 und 4 an dem Kanal 6. Diese Werte sind mein PWM1 und PWM2. Es werden Werte in ms gesendet. Mit einem Gasknüppel verglichen sendet er in Mittelstellung 1500us, in Vollgas 2000us und in Vollgas zurück 1000us. Beim drücken der Taster hat so jeder seinen eigenen Wertebereich, das sind die Werte im switchcase. Ich habe den Bereich um +/-50ms erweitert, da das Signal nie ganz konstant kommt. in Nullstellung sendet er meistens von 1480 bis 1520 irgendwas. In meinem anderen Prog hatte ich da noch eine Korrektur drinnen. Also wenn er 1480 beim einschalten erhält, rechnet er auf die 1500 und korrigiert jeden weiteren gelesenen Wert mit +20. Davon wurde mir aber abgeraten.
Tatsächlich scheint es so zu sein, das das einlesen mit pulsein nicht wirklich genau ist und noch dazu wie delay bremst. Das bessere einlesen ist wohl mit einem interrupt. Das sind aber auch noch böhmische Dörfer für mich.
Es gibt eine bestehende Lib, die wohl gut funktioniert und mit einem Interrupt arbeitet. Diese ist von Wilfried Klaas und nennt sich RCReceiver. Dort gibt es 2 Beispiele, die mit int im Namen funktioniert wohl mit interrupts. Sie gibt allerdings etwas andere Werte zurück als ich gedacht habe, dafür sind diese Werte augenscheinlich sehr stabil. Vom Zeitstempel her wohl auch ziemlich schnell wenn ich das richtig interpretiere.
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
20:53:12.914 -> PWM CH1: 126
20:53:12.914 -> PWM CH1: 0
Das wäre ein Ansatz der recht einfach funktionieren könnte und, zumindest meiner Auffassung nach auch keine großen Programmänderungen bedeuten würde.
Nachtrag. Wieso ich das noch nicht selbst probiert habe ist recht simpel. Ich bekomme das Prog nicht so umgeschrieben das er 2 Eingänge einlesen kann .
Nachtrag 2: Leider musste ich gerade feststellen, das auch diese Werte nicht von z.B 233 direkt auf die 126 zurück gehen sonden 233 211 190 usw.
Ich hab mal in der Simulation mit einem Poti versucht eine RC Wert zu generieren.
wenn du das mit deiner Funke probierst, musst du meine pulseInSimu deaktivieren und wieder die Zeile aktivieren:
uint16_t pulseLength = pulseIn(rc[i].pin, HIGH, 20000); // Read PWM pulseEin Link dorthin erhöht die Wahrscheinlichkeit, dass sich das jemand ansieht.
kann aber nur den Github Link zeigen:
Nebenschauplatz:
Man sieht dort aber auch diese Wechsel von 126/0 ... der gleiche Quargel wie aktuell das -1.
Aus meiner Sicht brauchst du einen definierten "toten" Bereich - der für "alle Taster losgelassen" gilt. Dann kannst du genau unterscheiden zwischen
"Ungültiger Bereich" (außerhalb der Bereichsgrenzen)
"ein bestimmter Bereich ist gewählt" (innerhalb einer Bereichsgrenzen)
"alle Tasten sind losgelassen" (neuer definierter Bereich!)
"die Funke sendet zwischendurch den Wert 0"
... und dann kann man auch ein wiederholtes "drücken" eindeutig erkennen.
Ja sowas in der Art hab ich in meinen früheren Versuchen verwendet:
if (pwm1 > 950 && pwm1 < 1050 && (stat1 == LOW) && (mem1 == 0))
{
digitalWrite (CH1, HIGH);
delay(10);
do {
pwm1 = pulseIn(2, HIGH, 20000);
delay(50);
}
while (( pwm1) < 1050 );
digitalWrite(CH1, LOW);
Ich hab so lange das Signal wieder eingelesen bis es aus dem Wertebereich war. Dadurch konnte ich mir einigermaßen sicher sein das der Taster jetzt losgelassen wurde. nur durch das delay und das ewige pulsin wurde es sehr langsam. Aber sowas in der Art meinst du oder? Warten bis die Werte in einem Bereich von 1480 bis 1520 (neutral) liegen und erst dann wieder abfragen.
Eigentlich sollte die Funke keine 0 senden, denn es liegt ja immer ein Signal zwischen 1000 und 2000 an
nicht ganz und sicher ohne do/while .
brauchst ja eigentlich nur den Bereich in int8_t pulseToChannel () aufnehmen,
übergibst eine neue Magic Number (127 ?) für den Totpunkt.
Evtl. musst du dann diese 127 auch noch extra behandeln.
Und bevor die Mitleser drüber fallen für -1 und 127 Konstanten einführen
Also ehrlich gesagt habe ich das ganze in der ReadRCinput in keinster Weise verstanden 
void readRCinput()
{
int PWM1IN = pulseIn(PWMPin1, HIGH ); //Read PWM Pulse
if (PWM1IN > 900 && PWM1IN < 2100)
{
PWMEingang1 = PWM1IN;
}
int PWM2IN = pulseIn(PWMPin2, HIGH ); //Read PWM Pulse
if (PWM2IN > 900 && PWM2IN < 2100)
{
PWMEingang2 = PWM2IN;
}
}
void checkRCSwitch1()
{
switch (PWMEingang1)
{
case 950 ... 1050:
kanal[0].fire();
break;
case 1950 ... 2050:
kanal[1].fire();
break;
case 1100 ... 1200:
kanal[2].fire();
break;
case 1800 ... 1900:
kanal[3].fire();
break;
case 1240 ... 1340:
kanal[4].fire();
break;
case 1350 ... 1450:
kanal[5].fire();
break;
case 1530 ... 1630:
kanal[6].fire();
break;
case 1660 ... 1760:
kanal[7].fire();
break;
default:
break;
den alten Code konnte ich zumindest irgendwo nachvollziehen. Den ungültigen Bereich filtert er ja quasi schon raus bevor er den Wert übergibt
... ich hab auch länger als 5 min dafür benötigt. Wir lesen einander morgen.
Alles klar,
dann dir noch einen schönen Abend und Danke für deine Hilfe.
Gruß Thomas
Servus,
ich habe noch die Beobachtung gemacht, das beim betätigen eines Tasters die Signale eigentlich sofort auf den neuen Wert gehen, nur beim loslassen braucht er mehrere Einlesevorgänge bis er wieder in neutral ist. Sinnbildlich so:
8:27:06.291 -> PWM CH1: 1491 PWM CH2: 1489
18:27:06.338 -> PWM CH1: 1491 PWM CH2: 1489
18:27:06.338 -> PWM CH1: 1491 PWM CH2: 1489
18:27:06.384 -> PWM CH1: 1989 PWM CH2: 1489
18:27:06.431 -> PWM CH1: 1989 PWM CH2: 1488
18:27:06.478 -> PWM CH1: 1989 PWM CH2: 1489
18:27:06.523 -> PWM CH1: 1989 PWM CH2: 1495
18:27:06.570 -> PWM CH1: 1989 PWM CH2: 1495
18:27:06.616 -> PWM CH1: 1989 PWM CH2: 1495
18:27:06.616 -> PWM CH1: 1989 PWM CH2: 1495
18:27:06.663 -> PWM CH1: 1989 PWM CH2: 1495
18:27:06.710 -> PWM CH1: 1989 PWM CH2: 1495
18:27:06.757 -> PWM CH1: 1989 PWM CH2: 1495
18:27:06.804 -> PWM CH1: 1995 PWM CH2: 1489
18:27:06.850 -> PWM CH1: 1989 PWM CH2: 1489
18:27:06.896 -> PWM CH1: 1989 PWM CH2: 1489
18:27:06.896 -> PWM CH1: 1989 PWM CH2: 1489
18:27:06.943 -> PWM CH1: 1604 PWM CH2: 1488
18:27:06.990 -> PWM CH1: 1508 PWM CH2: 1489
18:27:07.037 -> PWM CH1: 1495 PWM CH2: 1495
18:27:07.085 -> PWM CH1: 1486 PWM CH2: 1495
18:27:07.133 -> PWM CH1: 1486 PWM CH2: 1495
18:27:07.180 -> PWM CH1: 1486 PWM CH2: 1495
18:27:07.180 -> PWM CH1: 1486 PWM CH2: 1494
18:27:07.226 -> PWM CH1: 1486 PWM CH2: 1495