TCP oder UDP

xorg1990 · 30. Sep. 2017

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.

mikdoe · 01. Okt. 2017

xorg1990 schrieb:
https://www.youtube.com/watch?v=v3tpLiSJuLo

dessen stimme hört sich zum verwechseln ähnlich wie die von koitec ahrens an. ist er das?

xorg1990 · 01. Okt. 2017

mikdoe schrieb:
zum verwechseln ähnlich wie die von koitec ahrens an. ist er das?

Nein eher nicht. Bin selber erst auf das Video aufmerksam geworden als ich nach diesem IAMBIC begriff gesucht habe.

xorg1990 · 03. Okt. 2017

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.

tsseh · 04. Okt. 2017

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

warum nicht ein zeichen?

xorg1990 schrieb:
Ich kann mir vorstellen das sich bei TCP was aufstaut und der ESP den Watchdog wirft. Bei UDP weiß ich nicht was passiert.

ob tcp oder udp sollte egal sein. ich würde tcp nehmen, weil du dir dann keine gedanken um die reihenfolge machen musst.

xorg1990 · 04. Okt. 2017

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 · 04. Okt. 2017

xorg1990 schrieb:
Ä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

xorg1990 schrieb:
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 · 07. Okt. 2017

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 · 14. Okt. 2017

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

@tsseh, hast du noch eine Idee

tsseh · 16. Okt. 2017

xorg1990 schrieb:
aber if (data == 1) wird nie true, da data immer -1

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 · 16. Okt. 2017

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??

tsseh · 16. Okt. 2017

xorg1990 schrieb:
Ok, also komplett anders debuggen.

xorg1990 schrieb:
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

xorg1990 schrieb:
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.

xorg1990 schrieb:
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

xorg1990 schrieb:
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

xorg1990 schrieb:
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

xorg1990 schrieb:
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

xorg1990 · 18. Okt. 2017

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

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

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 · 19. Okt. 2017

auf die schnelle erst mal nur dazu:

xorg1990 schrieb:
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 - - -

xorg1990 schrieb:
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 - - -

xorg1990 schrieb:
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 - - -

xorg1990 schrieb:
Code:

ets_timer_arm_new(&symbolEndTimer, ditLength, false, false);

das ist wieder ein µs-timer

xorg1990 · 19. Okt. 2017

tsseh schrieb:
echo -ne "\x01"

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 · 19. Okt. 2017

xorg1990 schrieb:
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

xorg1990 schrieb:
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

xorg1990 schrieb:
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 · 19. Okt. 2017

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 · 20. Okt. 2017

xorg1990 schrieb:
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

xorg1990 schrieb:
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

xorg1990 schrieb:
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 · 20. Okt. 2017

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:
echo -ne "\x01"

Da kommt auch nur \x01
Ergo ein string

tsseh · 22. Okt. 2017

xorg1990 schrieb:
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.

die zeit ist ja nur von bedeutung um . von - zu unterscheiden, wenn du schon . und - hast interessiert die zeit nicht mehr

TCP oder UDP

New member

Moderator

New member

New member

Lounge-Member

New member

Lounge-Member

New member

New member

Lounge-Member

New member

Lounge-Member

New member

Lounge-Member

New member

Lounge-Member

New member

Lounge-Member

New member

Lounge-Member