TCP oder UDP

xorg1990

New member
Hi, habe da mal eine kleine Frage.

Ich bin gerade dabei eine Funk Morse Taste zu entwickeln über WLAN. Einen ESP8266 als Sender und eine als Empfänger.

Übertragen möchte ich jeweils nur ein byte 0 für AUS, 1 für EIN soweit so gut.

Was die vor und nachteile von UDP und TCP sind weiß ich selber.

Bei TCP kann es passieren da die Ein/aus schalt Zeiten verschoben werden aber das Morsezeichen wäre ist immer valide.

Bei UDP kann alles passieren von nicht ankommende Pakete, bis invalide oder zwei mal das selbe gesendet etc.
Das kann man aber alles Evaluieren. Problematisch wird es nur wenn das letzte Symbol auf "ein" geht und das "aus" Packet kommt nicht an, dann geht der Sender nicht mehr aus. Wäre aber auch nicht das Thema Weil, wenn nach 200ms nichts mehr kommt, kann ich auch ab schalten.

Aber UDP ist dafür schneller.

Da sich die Übertragungsstrecke meist auf 5Meter bezieht, wird die Signalstärke nicht das Problem sein.
Aber hat jemand Erfahrung wie verlustbehaftet UDP ist und wie so das delay beim Senden/Empfangen von TCP ist? Das kann ich im WWW nicht finden.

Bei TCP ist das noDelay auf ein.

Zum Thema Morse Geschwindigkeit.
https://www.youtube.com/watch?v=q_ZEwZzuqW0
Oder:
https://www.youtube.com/watch?v=b9S-NzsUD5w
Man könnte meinen da schreibt jemand mit der Schreibmaschine und 10 Fingern:abnormal:


Ich kann mir vorstellen das sich bei TCP was aufstaut und der ESP den Watchdog wirft. Bei UDP weiß ich nicht was passiert.
Allerdings hat man auch ein Wahnsinns Bandbreite für nur ein byte.
Vielleicht passiert einfach nix weil, Audio und Video wird ja auch übertragen via TCP, zwar mit delay aber immerhin.



Wenn es interessiert so funktionieren die Taster:
https://www.youtube.com/watch?v=v3tpLiSJuLo
Es gibt da noch IAMBIC_A und IMABIC_B aber das wird zu speziell.
 

xorg1990

New member
Hm, also TCP scheint nicht so recht zu klappen, auf dem server kommt zwar was an aber read() spuckt immer -1 aus.
Habe nach diesem beispiel gearbeitet.
https://github.com/esp8266/Arduino/...WiFiTelnetToSerial/WiFiTelnetToSerial.ino#L73

- - - Aktualisiert - - -

Ok, wer lesen kann -1 bedeutet Puffer leer:
https://www.arduino.cc/en/Reference/WiFiClientRead

Aber warum ist der Puffer an dieser stelle leer???
Da die while "while(serverClients.available())" ja feuert muss also was übertagen worden sein da aber nichts kommt kann es nur NULL sein.

tsseh wüsste das bestimmt.
 

xorg1990

New member
tsseh schrieb:
warum nicht ein zeichen?

Irwie habe ich geahnt das die Frage kommt. Ich habe noch einen 2ten Sender, der an den Com Port von computer hängt.
Da es zig Text zu Morse Programme da draußen gibt. Was die Programme aber alle machen ist nur DTR oder RTS Toggeln. Man könnte auch ein Tool Programmieren was den Com Port überwacht und dann per WLAN gleich zum Empfänger sendet.
Ändert aber nix das nur 0 und 1 Übertagen werden kann.

Jedenfalls kommt beim Empfänger(TCP Server) nur eine leeres TCP Paket an (Wenn sowas überhaupt möglich ist).


Beim Sender habe ich noch eine Begleitton via Tone() am laufen. Irwie muss man hören was man gibt.
tone() nutzt wider den Timer 2 vom esp. Mein verdacht ist das da wider was schief geht. Die duration gebe ich nicht an, rufe nachdem ein Symbol zu ende ist NoTone auf.


Das kriege ich aber erst am WE raus weil am Freitag habe ich noch eien Prüfung zu bestehen. *Nerf.

Ps, was ich dir per PN geschickt habe hat sich erledigt, das lag an der Entprellung.
 

tsseh

Lounge-Member
Ändert aber nix das nur 0 und 1 Übertagen werden kann.
aber nicht bei tcp, da willst du ja immer ein byte übertragen(wobei bei tcp sogar mehrere pakete zusammengefasst werden können), da passt mehr rein als 0/1, mindestens ein zeichen

Jedenfalls kommt beim Empfänger(TCP Server) nur eine leeres TCP Paket an (Wenn sowas überhaupt möglich ist).
nein, ein leeres kommt nicht an, da dann read nicht aufgerufen wird (wie du selbst sagtest)
 

xorg1990

New member
da passt mehr rein als 0/1, mindestens ein zeichen
Du hast anscheint noch nicht so richtig verstanden wie das mit der Elbug (Morsetaste funktionert).
Wenn du ein Zeichen übertragen möchtest (Ich gehe davon aus du meinst dit oder dah) dann muss der Empfänger wissen wie schnell die zu Morsende Geschmeidigkeit ist, das wird mittels Drehgeber am Sender geregelt. Ok ,man kann die Geschwindigkeit an den Empfänger übertragen.

Dann müsste man aber übertragen ob ein Paddle gedrückt und Gehalten wird oder nur angetippt wurde oder Beide gedrückt werden.
Wen beide Gedrückt werden muss unterschieden werden welches zuerst gedrückt wurde.
Siehe:
xorg1990 schrieb:
Wenn es interessiert so funktionieren die Taster:
https://www.youtube.com/watch?v=v3tpLiSJuLo

Am ende wird auch nur 0und1 übertragen.


Aktuell bin ich noch nicht weiter mit dem Debuggen ich wollte mit 2 Rechnern arbeiten um zu sehn was am Sender und Empfänger passiert.
Aber unter Windows kann ich de Esp nicht beschreiben da kommt immer:
warning: espcomm cmd: wrong direction/command: 0x00 0x08, expected 0x01 0x08
trying to connect

Wenn ich an den Baudraten rumstelle meint er zwar das er Fertig ist mit beschrieben, aber er schreibt nur bis ca 70% vernünftig. Dann kommt mit Einmal 100% Fertig. Starte ich den ESP dann kommen hintarnender Watchdog Resets.

Was hat es damit auf sich???

Der Upload wird Kommandozeilen basierend mit dem ESP Tool erliegt.

Die serielle Ausgabe funktioniert aber.

- - - Aktualisiert - - -

Ok, ich glaube der Adapter ist schrott, unter Linux passiert das:
Code:
............................................................................... [ 34% ]
................................................................................ [ 69% ]
....................................................................error: failed sending 0xC0
warning: espcomm_send_command: didn't receive command response
warning: espcomm_send_command(FLASH_DOWNLOAD_DATA) failed
error: failed sending 0xC0
error: failed sending 8 bytes
error: failed sending 4 bytes
error: failed sending 0xC0
warning: espcomm_send_command: didn't receive command response
closing bootloader
error: espcomm_upload_mem failed
error: espcomm_upload_mem failed
 

xorg1990

New member
Ich komme einfach nicht weiter mit der TCP Verbindung.

Ich habe folgenden Server Code:
Code:
#include <ESP8266WiFi.h>
extern "C" {
#include "user_interface.h"
#include "ets_sys.h"
}

#define statusLed LED_BUILTIN
#define pttPin 0
#define keyPin 2
#define MAX_TCP_SRV_CLIENTS 2
#define ssid "DL3ARM_CW_KEYER"
#define password ""

const bool low = HIGH;
const bool high = LOW;
volatile byte PTT_Delay = 10;//einschaltverzögerung in ms
bool isPTTon = false;
volatile unsigned long txOnTime = 0;
volatile unsigned long txOffTime = 0;
const long interval = 500;
volatile unsigned long previousMillis = 0;
bool ledState = low;             // ledState

WiFiServer server(4231);
WiFiClient serverClients[MAX_TCP_SRV_CLIENTS];
IPAddress APlocal_IP(192, 168, 4, 1);
IPAddress APgateway(192, 168, 4, 1);
IPAddress APsubnet(255, 255, 255, 0);


void setup() {
  //  Serial.begin(115200);
  delay(10);
  pinMode(statusLed, OUTPUT);
  pinMode(keyPin, OUTPUT);
  pinMode(pttPin, OUTPUT);
  digitalWrite(pttPin, LOW);
  digitalWrite(keyPin, LOW);
  // wifi_set_sleep_type(NONE_SLEEP_T);//maximale sendleistung
  //wifi_set_phy_mode(PHY_MODE_11G);
  //  WiFi.setAutoConnect(false);
  //  WiFi.disconnect(true);
  //  WiFi.persistent(false);
  //  WiFi.mode(WIFI_AP);
  WiFi.softAPConfig(APlocal_IP, APgateway, APsubnet);
  WiFi.softAP(ssid, password);
  WiFi.softAPIP();
  server.begin();
  server.setNoDelay(true);
  //Serial.println("started");
  digitalWrite(statusLed, low);
}

void loop() {
  unsigned long currentMillis = millis();
  byte i;
  //check if there are any new clients
  if (server.hasClient()) {
    digitalWrite(statusLed, low);
    for (i = 0; i < MAX_TCP_SRV_CLIENTS; i++) {
      //find free/disconnected spot
      if (!serverClients[i] || !serverClients[i].connected()) {
        if (serverClients[i]) serverClients[i].stop();
        serverClients[i] = server.available();
        //Serial.println("New client: "); Serial.println(i);
        continue;
      }
    }

    //no free/disconnected spot so reject
    WiFiClient serverClient = server.available();
    serverClient.stop();
  }


  //check clients for data
  for (i = 0; i < MAX_TCP_SRV_CLIENTS; i++) {
    if (serverClients[i] && serverClients[i].connected()) {
      if (serverClients[i].available()) {
        //get data from the telnet client and push it to the UART
        while (serverClients[i].available()) {
          int data =  serverClients[i].read();
          //Serial.println("data");
          //Serial.println(data);
          if (isPTTon == false) {
            digitalWrite(pttPin, HIGH);
            isPTTon = true;
            txOnTime = currentMillis + PTT_Delay;
          }
          if (isPTTon && currentMillis >= txOnTime) { //beginne zu senden
            txOffTime = currentMillis + PTT_Delay;
            if (data == 1) {
              digitalWrite(keyPin, HIGH);
            } else {
              digitalWrite(keyPin, LOW);
            }
          }

        }
      }
    } else {
      //no clinet connectetd
      //blink led
      if (currentMillis - previousMillis >= interval) {
        previousMillis = currentMillis;
        if (ledState == low) {
          ledState = high;
        } else {
          ledState = low;
        }
        digitalWrite(statusLed, ledState);
      }
    }
  }


  if (isPTTon == true && currentMillis >= txOffTime) {
    digitalWrite(keyPin, LOW); // sicherheitshalber
    digitalWrite(pttPin, LOW);
    isPTTon = false;
  }
}


Beim Client baue ich die Verbindung einmalig in der Setup Funktion auf
Code:
if (hasWIFI == true) {
    if (!TCP_client.connect(host, port)) {
      isClientConnected = false;
      Serial.println("no connection");
      digitalWrite(ledPin, HIGH);
    } else {
      digitalWrite(ledPin, LOW);
      isClientConnected = true;
      Serial.println("connected");
        TCP_client.setNoDelay(true);
    }
  } else {
     isClientConnected = false;
    Serial.println("no WIFI");
  }

Möchte ich jetzt einen einschalt befehl übertragen passiert nix außer einem Watchdog Reset:
Code:
  if (isClientConnected) {
    TCP_client.write((byte)1);
  }

Beim server macht aber aber die PTT noch ein, also hier geht er noch hin:
Code:
if (isPTTon == false) {
            digitalWrite(pttPin, HIGH);
            isPTTon = true;
            txOnTime = currentMillis + PTT_Delay;
          }
aber if (data == 1) wird nie true, da data immer -1:confused:

@tsseh, hast du noch eine Idee
 

tsseh

Lounge-Member
aber if (data == 1) wird nie true, da data immer -1:confused:
also immer noch der selbe fehler, da lohnt es sich doch nicht weiterzumachen.

du musst erst mal sehen, wo das problem ist. z.b. mit wireshark den netzwerkverkehr untersuchen.
oder netcat erst mal als server laufen lassen und sehen was ankommt oder auch als client mal deine 1 senden
 

xorg1990

New member
tsseh schrieb:
du musst erst mal sehen, wo das problem ist. z.b. mit wireshark den netzwerkverkehr untersuchen.
oder netcat erst mal als server laufen lassen und sehen was ankommt oder auch als client mal deine 1 senden
Ok, also komplett anders debuggen.

Ich baue gerade alles um auf eine TCP Socket klasse.
Aber ein par dinge verstehe ich nicht

1tens, in der send Methode steht was von Client id:
https://github.com/i-n-g-o/esp-socket/blob/master/src/ESP8266TCPServer.cpp#L122

Aber woher bekomme ich die id, oder besser gesagt ist die id ein byte (uint8_t) oder wie habe ich die zwichen zu speichern?
Eigentlich sollte die id mit dem connect CB kommen aber ich blicke da nicht durch:
https://github.com/i-n-g-o/esp-socket/blob/master/src/ESP8266TCPServer.cpp#L312

2tens beim Data Callback, ist da data ein array?
https://github.com/i-n-g-o/esp-socket/blob/master/src/ESP8266TCPServer.cpp#L295
Bzw. wenn Data eine Zeiger auf ein array ist, dann brauche ich ja nur in einer Schleife ja nur den Zeiger inkrementieren also data++.


3tens was ist mit dem Nagle Algorithmus ist der abgeschaltet oder wie ist das??
 
Zuletzt bearbeitet:

tsseh

Lounge-Member
Ok, also komplett anders debuggen.

Ich baue gerade alles um auf eine TCP Socket klasse.
wenn du ständig alles änderst kommst du doch nie zu nem ergebniss, versuch doch erst mal das problem zu finden

Aber woher bekomme ich die id, oder besser gesagt ist die id ein byte (uint8_t) oder wie habe ich die zwichen zu speichern?
das ist in der tat murks. die clientid ist ein index in ein array aus dem sdk,
espconn_get_connection_info gibt ein array von struct remot_info zurück,
https://github.com/espressif/ESP8266_RTOS_SDK/blob/master/include/espressif/espconn.h#L139
für alle clients die mit dem server verbunden sind.
unter dem index clientid ist dann dein client gespeichert. allerdings sehe ich jetzt nicht, wie du an den index kommst ohne ihn in diesem array zu suchen.

Eigentlich sollte die id mit dem connect CB kommen aber ich blicke da nicht durch:
sehe ich nicht, dass du die (überhaupt irgendwo von dieser klasser) bekommst[/QUOTE]
genau, ich auch nicht

2tens beim Data Callback, ist da data ein array?
ich sage mal ja, in c/c++ ist ein array ja nur ein stück zusammenhängender speicher, ob der als array angelegt wird oder mit malloc/new nur ein stück speicher geholt wird ist in der anwendung ja egal

Bzw. wenn Data eine Zeiger auf ein array ist, dann brauche ich ja nur in einer Schleife ja nur den Zeiger inkrementieren also data++.
genau

3tens was ist mit dem Nagle Algorithmus ist der abgeschaltet oder wie ist das??
der interessiert dich als anwender nur, wenn dein client/server unter einem bs läuft welches ihn unterstützt, der esp wird das vermutlich nicht tun
 
Zuletzt bearbeitet:

xorg1990

New member
tsseh schrieb:
wenn du ständig alles änderst kommst du doch nie zu nem ergebniss, versuch doch erst mal das problem zu finden
Eien Sache habe ich schon ausprobiert und zwar ein Byte via netcat an des esp zu senden. Aber ich werde aus der Sache nicht schlau.

Ich habe diesen bash befehl: echo -n 0x01 | nc X.X.X.X 1234
Aber beim esp passiert das:
Code:
New client: 
0
New client: 
1
data
48
data
120
data
48
data
49
Ist schon mal Eigenartig das sich 2 Clients verbinden:confused:

Zudem ist es egal was ich übertrage, es kommt immer 48,120,48,49 raus.


tsseh schrieb:
der interessiert dich als anwender nur, wenn dein client/server unter einem bs läuft welches ihn unterstützt, der esp wird das vermutlich nicht tun
Doch das ist beim esp sdk auch vorgesehen, noDelay schimpft sich das meistens: https://github.com/esp8266/Arduino/...WiFiTelnetToSerial/WiFiTelnetToSerial.ino#L44

- - - Aktualisiert - - -

Okay, das mit dem 2 Clients hat seiene Richtigkeit. Und die Willkürliche Ausgabe kam daher, das ich read() mit int gecasted habe. Mit char passiert nun dies:
Code:
data
0
data
x
data
0
data
1
:confused::confused::confused:

Ja schön aber ich erwarte ein byte also 1. und nicht ein HEX wert. Sende ich nur einen Buchstaben spuckt er mir auch nur diesen Buchstaben aus.

Beim sender ist der Software Timer für die Abstürze verantwortlich. Warum weiß ich nicht.
Ich lasse pro DIT oder DAH eine Begleitton via Buzzer los, damit man auch weiß was man gibt, denn Morsen geht wie Klavierspielen nach Gehör.
Code:
void ICACHE_RAM_ATTR symbolEnd(void* pArg) {
  //Serial.println("ende");
  symbolEndTime = micros() + ditLengthPause;
  isPlaySymbol = false;
  if (isClientConnected) {
    TCP_client.write((byte)0);
  }
  noTone(buzzerPin);

}


void DIT() {
  if (mem && ditIndex++ > 7) {
    ditIndex = 0;
    return removeLetter();
  }
  Serial.println("DIT");
  vTime = micros() + ditLengthPause + ditLength;
  isPlaySymbol = true;
  if (isClientConnected) {
    TCP_client.write((byte)1);
  }
  tone(buzzerPin, buzzerFrequency);
  ets_timer_arm_new(&symbolEndTimer, ditLength, false, false);//void ets_timer_arm_new(ETSTimer *cbFunc, delay, repeat, isMstimer);
  lastSymbol = 0;
  if (mem) { //nur relevant wenn im speicher modus
    evalSymbol(false);
  }
  return;
}

Kommentiere ich den ets_timr aus funktioniert es einfach nur. TCP_client.write((byte)0); und noTone(buzzerPin); habe ich schon überprüft, daran liegt es nicht, es ist tatsächlich der Timer.

- - - Aktualisiert - - -

Asso und wenn ich in der DIT Funktion das TCP_client.write((byte)1); auskommentiere geht es auch. Also irwie wollen der Timer und das Senden nicht zusammen harmonieren.
 

tsseh

Lounge-Member
auf die schnelle erst mal nur dazu:
Ja schön aber ich erwarte ein byte also 1. und nicht ein HEX wert. Sende ich nur einen Buchstaben spuckt er mir auch nur diesen Buchstaben aus.
echo -ne "\x01"

- - - Aktualisiert - - -

Doch das ist beim esp sdk auch vorgesehen, noDelay schimpft sich das meistens: https://github.com/esp8266/Arduino/...WiFiTelnetToSerial/WiFiTelnetToSerial.ino#L44
dann musst du entscheiden, ob du damit leben kannst odern nicht. ich würde vermuten dass es für deine anwendung, besser wäre den nagle-algorithmus auszuschalten - musst du aber mal testen, ob es mit sonst zu verzögerungen kommt die stören

- - - Aktualisiert - - -

Kommentiere ich den ets_timr aus funktioniert es einfach nur. TCP_client.write((byte)0); und noTone(buzzerPin); habe ich schon überprüft, daran liegt es nicht, es ist tatsächlich der Timer.
warum nutzt du nicht einfach die tone(pin, frequency, duration) funktion?
warum sendest du in DIT() eine 1 über tcp und nicht eine 0?
warum sendest du in symbolEnd() eine 0 über tcp? wozu soll das gut sein?

- - - Aktualisiert - - -

Code:
ets_timer_arm_new(&symbolEndTimer, ditLength, false, false);
das ist wieder ein µs-timer
 

xorg1990

New member
tsseh schrieb:
ok, probiere ich aus.
tsseh schrieb:
warum nutzt du nicht einfach die tone(pin, frequency, duration) funktion?
Kann ich auch machen, bringt halt nix, da ich die symbolEnd() Funktion ehe brauche.

tsseh schrieb:
warum sendest du in DIT() eine 1 über tcp und nicht eine 0?
warum sendest du in symbolEnd() eine 0 über tcp? wozu soll das gut sein?
Habe ich doch gesagt 1 zum Transceiver einschalten 0 für aus. Kann auch 'E' und 'A' sein. Von mir aus auch ein String "Jetzt an" und "Jetzt aus"

tsseh schrieb:
das ist wieder ein µs-timer
Ja und? Der Timer hat hatte keine Abstürze verursacht, er war ja nur etwas Ungenau ich weiß allerdings nicht mehr wie sehr ungenau, Du hattest das irwie ermittelt.

Du hast bei einer Zeichengeschwindigkeit [G in WPM] 1 eine dit länge von 1200ms. Bei 60 WPM sind das 20ms... Einige freaks Morsen bis 80 WPM.

Die typische Geschwindigkeitsangabe Wörter pro Minute (WpM) bezieht sich auf das
Wort PARIS mit insgesamt 50 Ditlängen. Wird das Wort PARIS zehnmal pro Minute
gegeben, so ergibt sich eine Geschwindigkeit von G = 10 WpM.

Meine Bedenken sind das es mit einem MS timer zu ungenau wird.

Die TCP Verbindung muss nun schnell genug sein um um die "Ein" und "Aus" in der gewünschten Geschwindigkeit zu übertragen.
 

tsseh

Lounge-Member
Habe ich doch gesagt 1 zum Transceiver einschalten 0 für aus. Kann auch 'E' und 'A' sein. Von mir aus auch ein String "Jetzt an" und "Jetzt aus"
ähhh, ich dachte 1 für - und 0 für .
alles andere macht keinen sinn und wird nicht funktionieren, da wifi nicht echtzeitfähig ist, sprich durch die übertragung verkürzen oder verlängern sich deine zeiten zw. 1 und 0

Ja und? Der Timer hat hatte keine Abstürze verursacht, er war ja nur etwas Ungenau ich weiß allerdings nicht mehr wie sehr ungenau
sagen wir er hat nicht funktioniert was das alles verursacht, keine ahnung

Du hattest das irwie ermittelt.
wollte ich, bin dann aber davon abgekommen, weil die diskussion immer weiter ging in andere richtungen

- - - Aktualisiert - - -

jetzt verstehe ich auch die frage nach dem nagle-algorithmus, klar, damit kannst du auf ne 0-time kommen wenn 1 und 0 zu einem paket zusammengefasst werden
 

xorg1990

New member
Also die abstürze hängen irwie mit dem Zeiten zusammen, bei <10wpm bekomme ich nix gesendet, sobald die DIT Funktion kommt stürzte der ESP ab. Bei >50 WPM geht es, aber auch nicht stabil nach einer weile stürzt er dann trotzdem ab.

Millisekunden Timer scheint zu gehen.

Dann ist noch was komisch, wenn ich dit gedrückt halte müsste er hintereinander dit's senden, macht er aber nicht er beliebt einfach stehen.
Das ist in der loop verlogikt

Code:
void loop() {
  unsigned long currentMillis = micros();
  //Gehe nur rein wenn irgednwas gedrückt worden ist und gehalten und die Zeit abgelaufen ist
  if ((isDitPressed != isDahPressed) && currentMillis >= vTime) {
    if (isDitPressed) {
      if (sendOpposite) {//punk strich Speicher wurde aktiv sende das Gegenteilige von dem was gedrückt ist
        DAH();
        sendOpposite = false;
      } else {
        DIT();
      }
    } else { //DahPressed
      if (sendOpposite) {//punk strich Speicher wurde aktiv sende das Gegenteilige von dem was gedrückt ist
        DIT();
        sendOpposite = false;
      } else {
        DAH();
      }
    }
  }
Kommentiere ich das tcp.write in Dit() aus geht es. Wiederum, "wenn ich wie ein dummer junge" auf den dit paddle rumhämmere, das überträgt er. Da ich ja noch eine Pin change isr habe, für die Paddles, wo ebenfalls Dit() gefeuert wird.

Da kann ja nur die loop stehen bleiben. Jetzt bin ich erst mal platt.

tsseh schrieb:
ähhh, ich dachte 1 für - und 0 für .
alles andere macht keinen sinn und wird nicht funktionieren, da wifi nicht echtzeitfähig ist, sprich durch die übertragung verkürzen oder verlängern sich deine zeiten zw. 1 und 0
Es macht auch keinen sinn . oder - zu übertragen, da der Empfänger esp die Morse Zeiten nicht kennt wie schon mehrmals erwähnt.
Das mit der echtzeitfähigkeit ist so ein sache. Wie sehr sich die Übertragung verkürzt oder verlängert gilt es heraus zu finden.

Deswegen war meine ursprüngliche frage TCP oder UDP. Oder halt eine "raw übertragung". Doch dazu müsste man wissen wie der ESP das WIFI moduliert.
 

tsseh

Lounge-Member
Dann ist noch was komisch, wenn ich dit gedrückt halte müsste er hintereinander dit's senden, macht er aber nicht er beliebt einfach stehen.
Das ist in der loop verlogikt

vermutlich wird isDitPressed irgendwo zurückgesetzt

Es macht auch keinen sinn . oder - zu übertragen, da der Empfänger esp die Morse Zeiten nicht kennt wie schon mehrmals erwähnt.
wozu braucht er die morse-zeiten, wenn er schon -/. bekommt

Deswegen war meine ursprüngliche frage TCP oder UDP. Oder halt eine "raw übertragung". Doch dazu müsste man wissen wie der ESP das WIFI moduliert.
da ist es aber egal ob TCP oder UDP weil schon ethernet bzw. wifi nicht echtzeitfähig sind.
das sollte aber in deinem fall nicht stören, weil ich nicht sehe, dass du eine isochrone übertragung benötigst
 

xorg1990

New member
tsseh schrieb:
vermutlich wird isDitPressed irgendwo zurückgesetzt
Nope, mach ja kein sinn wenn ich den tcp write auskommentiere geht es, ich verändere ja nichts anderes weiter.

tsseh schrieb:
wozu braucht er die morse-zeiten, wenn er schon -/. bekommt
Versteh ich nicht, wenn Du . - als char übertragen möchtest, musst du ja den nach einer dit/dah länge wider abschalten. Oder wie hast du das gedacht.


tsseh schrieb:
das sollte aber in deinem fall nicht stören, weil ich nicht sehe, dass du eine isochrone übertragung benötigst
Nö brauch ich auch nicht, nur sollte das delay der Übertragung nicht all so lange dauern.

- - - Aktualisiert - - -

tsseh schrieb:
Da kommt auch nur \x01
Ergo ein string
 
Zuletzt bearbeitet:
Oben