Hulp nodig bij programmeren Arduino

[pe1rdp]

Recent heb ik remote CW gebouwd, gebaseerd op het idee van iw7dmh en pe1glx.
Hiermee wordt er CW gestuurd via wired LAN (of WAN) naar een client waar een arduino de remote TX aanstuurt.
Er wordt gebruik gemaakt van UDP en ik wil er een wireless versie van maken.
Het is mij bekend dat UDP en wireless beperkingen kent en dat TCP beter is maar dit hem volgens mij niet het probleem.

Ik ben in eerste instantie aan de slag gegaan met een ESP8266 en de standaard UDP module. De serial monitor aan de remote kant liet niet de juiste data zien. Dit waarschijnlijk het gevolg van de beperkingen van de ESP8266 en UDP.
Vervolgens heb ik een ESP32 en AsyncUDP gebruikt en nu lijkt de data wel goed aan te komen en deze packets zijn dan ook zichtbaar in de serial monitor van de ESP32.

Zodra de packet als data KU bevat, dan volgt er een println commando met de tekst KeyUp. Is data gelijk aan KD, dan wordt er een println gestuurd met de tekst KeyDown.

Random gaat dit laatste verkeerd. Zie bijlage.
Println worden random overgeslagen. Ik heb het stukje al verplaatst naar het void loop() gedeelte en tevens de delay(D) aangepast maar dat gaf niet het gewenste effect.

Wie heeft er voldoende kennis om mij hiermee verder te helpen?

[pa1ivo]

Ik ken de ESP en de Arduino omgeving slechts heel (heel) beperkt......

Als ik het kleine deel van de code bekijk, kan het zijn dat de packet data ingelezen wordt via een interrupt routine, en het halverwege de code (tussen regel 57 en 59) aangepast wordt? Misschien eens proberen om packet.data() éénmaal in te lezen en in een variable te stoppen, in plaats van twee maal inlezen (in regel 57 en 59). Als dat niet helpt, dan was dat niet het probleem ....

En ik ken nog steeds de rest van de code niet , maar waarom zou de delay() de boel moeten verbeteren? Ga je door de delay() juist geen informatie missen?

Je mag ook de gehele code even naar mij sturen, misschien kan ik dan nog meer, of de juiste, suggesties doen.

Wat ik ook even zo snel vond op https://www.arduino.cc/reference/en/lan ... ial/write/ :
Notes and Warnings
Serial transmission is asynchronous. If there is enough empty space in the transmit buffer, Serial.write() will return before any characters are transmitted over serial. If the transmit buffer is full then Serial.write() will block until there is enough space in the buffer. To avoid blocking calls to Serial.write(), you can first check the amount of free space in the transmit buffer using availableForWrite().

Dit zou ook voor de writeln() gelden. Misschien dat dit van invloed kan zijn.

73, Ivo.

[PA3CQN]

Ik zie het zo:

Het gaat fout met de conversie van char* packet.data() naar String.
String als constructor converteert alles vanaf de pointer packet.data() tot de eerste null-terminator. Maar het staat niet vast dat na KD of KU ook daadwerkelijk een null terminator staat, er kan ook iets anders staan en de string wordt dan langer met willekeurige tekens aan het eind. Daarom heb je ook packet.length nodig om te weten hoeveel karakters er in de string staan. In de Serial.write regel zie je dat ook terug, er worden precies data.length() karakters geprint.

Als er geen null achter de data staat weet je dus niet wat myString is geworden. Je beide IF statements zijn dan niet geldig en er wordt niks geprint.

Je kunt dit eenvoudig controleren door de tweede IF te veranderen in ELSE IF en dan nog een ELSE blok erachter te plaatsen waar je gewoon myString print om te zien wat er in staat als je niet aan KD of KU voldoet.

Je zou het volgende eens kunnen proberen op de plaats van je huidige String = myString:

char* tussenstap= malloc(data.length() + 1 ) //reserveer lengte van data plus 1 voor de null terminator
memcpy(tussenstap, packet.data(), packet.length()); //kopieer de inhoud van data naar tussenstap
tussenstap[data.lenth()] = '\0'; // dit zet een null terminator op het eind van de character array
String myString = String(tussenstap);
free(tussenstap); // die tussenstap is nu niet meer nodig en kan opgeruimd

[PD5DJ]

Je zou voor de grap eens jouw code door ChatGPT kunnen halen, en dezelfde vraag stellen.
Je zult je verbazen

Hoe vaak ik via ChatGPT fouten heb weten te vinden.

[pe1rdp]

Dank voor jullie feedback. Ik ga het proberen.

[pe1rdp]

Henk, PA3CQN, ik heb je een e-mail gestuurd. Hopelijk kun je mij hiermee nog verder helpen.

[coolepascal]

Waarom doe je op regel 59 een cast naar een const char ?
Zowieso een constant initialiseren vanuit een (niet constante) functie is mij een beetje een vreemde gedachte.
Dit dan nog los van de vraag of gegeven de CPU architectuur een const feitelijk wel bestaat maar dat is natuurlijjk gezemel.

Ik ben niet al te bekend met de class String,
en ik zou het resultaat gewoon in een char array zetten en dan met strcmp vergelijken

ongeveer als volgt

Code: Selecteer alles

char msg[10];

strcpy(msg, packet.data);
if(!strcmp(msg, "KU"))
{
    // Key up
}
if(!strcmp(msg, "KD))
{
    // Key down
}

't is een beetje Jan Boerenfluitjes, maar het geeft je wellcht een nieuw idee.

[pe1rdp]

Ondertussen is het ene probleem, waar ik deze post mee begon, onder controle. Maar nu blijkt dat ook AsyncUDP met een ESP32 nog steeds veel te onbetrouwbaar is. RemoteCW is via wifi nauwelijks nog herkenbaar aan de remote zijde. Helaas maar ik heb het geprobeerd en er veel van geleerd. Iedereen nogmaals bedankt voor het meedenken.
Wired werkt het wel perfect.

[PA3CQN]

Waarom doe je op regel 59 een cast naar een const char ?
Zowieso een constant initialiseren vanuit een (niet constante) functie is mij een beetje een vreemde gedachte.
Dit dan nog los van de vraag of gegeven de CPU architectuur een const feitelijk wel bestaat maar dat is natuurlijjk gezemel.

Ik ben niet al te bekend met de class String,
en ik zou het resultaat gewoon in een char array zetten en dan met strcmp vergelijken

Ach, arduino voorbeelden staan vol met 'const' en typecasten waar het eigenlijk niet nodig is.
En alles is int, ook als uint8_t eigenlijk meer dan genoeg is.

String zit bovenop de char class en maakt het mogelijk zonder na te denken met strings te werken.
Beetje op de basic manier. Waarbij de String class er voor zorgt dat er altijd een null terminator is.

Dit werkt dus ook gewoon:

Code: Selecteer alles

      String myString = "";
      for (int t=0;t<packet.length();t++){
        myString += (char)packet.data()[t];
      }

[Hans PE1KWH]

Dat je timing off is lijkt me niet onlogisch.
Berichten over ethernet en erger internet zijn nu eenmaal niet tijd vast. De latency zal varieren waardoor punten en strepen van lengte veranderen.

Waarom stuur je niet gewoon de character over die je dan remote omzet naar punten en strepen MET de juiste minimale tijd tussen 2 characters ?
Dan heb je de hele timing zelf in de hand.

[pe1rdp]

Ondertussen ben ik weer verder gegaan met al jullie tips waarvoor mijn dank!
De combinatie ESP8266, waar ik mee ben begonnen, en AsyncUDP werkt het beste. Niet geheel vlekkeloos maar dat kan ik van UDP met een cheapo WiFi board ook niet verwachten.

[coolepascal]

Ondertussen is het ene probleem, waar ik deze post mee begon, onder controle. Maar nu blijkt dat ook AsyncUDP met een ESP32 nog steeds veel te onbetrouwbaar is.

Absoluut niet waar ! Maar het zit ehm in de aanpak van je probleem (voor zover ik je code zie en de rest moet ik er dan bij fantaseren)
Je moet weten dat een ESP32 onder water nog een heel OS draait om de Draadloze stack te kunnen onderhouden.
Je moet dat OS wel af en toe rekentijd geven. Ik ga daar niet verder op in, want het eten staat zo op tafel
Arduino is leuk om een paar kerstlampjes te laten knipperen, maar ik schrijf vrijwel altijd mijn eigen libs, Dat is wat meer werk maar dan heb je ook minder gezeik.

[pe1br]

Ik zie dat je best veel serial gebruikt.
probeer eens te spelen met de timeout van de serial lib:

Code: Selecteer alles

void setup() {
Serial.begin(9600);
Serial.setTimeout(10);
}