New project code named: teensquitto

Status
Not open for further replies.
You definitely have a sense of humor. ;) Anyway the issues I am having with UDP and now MQTT is with my computer. I tried running MQTT direcly (pub and sub) and keep getting socket error. Have to figure out what the heck is going on.....
 
Ok... all seems to be working now - stupid mistake that I would not have realized and did just a last test. I had both the teensy and esp connected to the PC through a usb cable and nothing worked. Once unplugged the esp an powered it off the 3.3v line of the T3.5 everything work...... I am dumb - in hindsight guess it makes sense.:confused:
 
the esp takes alot of power, its possible the usb hub/port isnt supplying enough ? I use the blue USB3 ports they support 1.5A current, even though they share common ground i still run a ground link between the MCUs
 
I was going back and forth between the two and as long as it was plugged in it didn't work. Once I made it stand alone and run off the Teensy 3.3v pin it worked fine. Think, RX0/TX0 is the same as usb serial so it may have been getting confused. Going to post a couple more examples for you to try out and then you can incorporate them into the main library if you want :) Still have to sort something out with MQTT first :)

Can't tell me how much this was bugging me :) pardon the pun.

By the way how do you turn off all the debugging - if I make debug = 0 still getting messages....

EDIT: yep = taken to always have a gnd to gnd wire attached between mcu's


EDIT2: Just pushed some examples for you ..... Cheers :)
 
Last edited:
debug where, teensy? i disabled it in the github copy, for the ESP it should be
comment out this on ESP side to disable ESP debugging
Code: 
void processing_data(uint8_t *data, uint16_t len) {
  if ( debugging && // IGNORE SPECIFIC PACKETS WHILE DEBUGGING, GOOD FOR PREVENTING FLOODING WHILE DEBUGGING
       (((uint16_t)(data[0] << 8) | data[1]) != 0x8783 ) &&
       (((uint16_t)(data[0] << 8) | data[1]) != 0x7E7E )
     ) {
[B][COLOR="#0000FF"]//  for ( uint16_t i = 0; i < len - 1; i++ ) {
//    Serial.print(data[i], HEX); Serial.print(" "); // DEBUGGING
//  } Serial.println();[/COLOR][/B]
  }

probably just commenting out 3 lines is enough
 
A couple things, all minor :)

For asyncUDP incoming data is grabbed with packetData(). But how do I get that into a char array for processing. If I try and use:
Code: 
        strncpy( incomingPacket, packet.data(), packet.length());
where incomingPacket is char[255] I get the following error:
error: invalid conversion from 'uint8_t* {aka unsigned char*}' to 'const char*' [-fpermissive]
strncpy( incomingPacket, packet.data(), packet.length());
Click to expand...

The second question I have is that we are using TX1 (ESP) connected to RX1 on the Teensy with and RX0 (ESP) if we connect to say TX2 (teensy) it still spews additional information (I am calling this debug messages for lack on my knowledge on what else to call it). How can we just use says serial1 on the teensy to rx0.tx0 on the ESP.
 
1) you need to cast it (const uint8_t*)incomingPacket, packet.data(),......

2) because debugging goes to console when you print as well, thats why i use TX1 (there is no RX1 on ESP8266) as a dedicated transmitter so we can still debug/write console, if we use TX0 we cant debug anymore unless you switch all the serial calls to TX1 and tell the core to enable debug on second port, this seemed easier? :)
 
Ok - I give up. I been at this one all day with no luck on solution which I am sure you know.

I am using AsyncUDP to listen for new packets and that seems to be working. But I need to send messages through the same localport that I am receiving messages on in packet format. I tried a few different approaches but no luck. Any suggestions.
 
Ok - new problem - can't get WiFiUdp working. I used the code from https://github.com/esp8266/Arduino/blob/master/doc/esp8266wifi/udp-examples.rst and loaded directly on the feather board and it worked no issues. So I converted it to use teensquitto hoping it would solve my other problem. No good nothing. Here is the code I generated:
Code: 
//#include <ESP8266WiFi.h>
//#include <WiFiUdp.h>
#include <teensquitto.h>
#include <IPAddress.h>

//Teensquitto setup for UDP send and receive
teensquitto Udp = teensquitto("WiFiUdp", &Serial1);
teensquitto wifi = teensquitto("WiFi", &Serial1);

    IPAddress ip(192, 168, 1, 162);
    IPAddress gate(192, 168, 1, 1);
    IPAddress sub(255, 255, 255, 0);


const char* ssid = ".....................";
const char* password = "....................";

//WiFiUDP Udp;

unsigned int localUdpPort = 4210;  // local port to listen on
char incomingPacket[255];  // buffer for incoming packets
char replyPacket[] = "Hi there! Got the message :-)";  // a reply string to send back


void setup()
{
  Serial.begin(115200);
  Serial1.begin(2000000);
  Serial.println();
  ESP.onDetect([]() {
    wifi.mode(WIFI_STA);
    wifi.begin(ssid, password);
    wifi.waitForConnectResult();
    wifi.config(ip, gate, sub);
    Serial.printf("Connecting to %s ", ssid);
    wifi.begin(ssid, password);
    while (wifi.status() != WL_CONNECTED)
    {
      delay(500);
      Serial.print(".");
    }
    Serial.println(" connected");
  }); // end of onDetect callback
  
  Udp.begin(localUdpPort);
  Serial.printf("Now listening at IP %s, UDP port %d\n", wifi.localIP().toString().c_str(), localUdpPort);
}


void loop()
{
  int packetSize = Udp.parsePacket();
  if (packetSize)
  {
    // receive incoming UDP packets
    Serial.printf("Received %d bytes from %s, port %d\n", packetSize, Udp.remoteIP().toString().c_str(), Udp.remotePort());
    int len = Udp.read((unsigned char *)incomingPacket, 255);  [COLOR="#FF0000"]//had to use this casting to get it to compile.......[/COLOR]
    if (len > 0)
    {
      incomingPacket[len] = 0;
    }
    Serial.printf("UDP packet contents: %s\n", incomingPacket);

    // send back a reply, to the IP address and port we got the packet from
    Udp.beginPacket(Udp.remoteIP(), Udp.remotePort());
    Udp.write(replyPacket,len);
    Udp.endPacket();
  }
  wifi.events();
}

void serialEvent1() {
  wifi.events();
}
Don't see why it wouldn't work but..... the version I posted to the library works fine.
 
loopback on the same ESP chip is not possible

just so i understand, asyncudp receives, core’s udp version doesnt?

if you change incommingPacket to uint8_t you wpnt need to cast it, dunno why the ESP core decided they should kill off overloads... hehe
 
Morning. Not really trying to do loop on the ESP. I will try to explain, may get long winded so forgive me. Oh by the way - don't think its a core problem on the overload:

In teensquitto.h you have for read:
Code: 
virtual size_t read(uint8_t* buf, size_t size)
while in the core it has:
Code: 
  // Read up to len bytes from the current packet and place them into buffer
  // Returns the number of bytes read, or 0 if none are available
  virtual int read(unsigned char* buffer, size_t len);
  // Read up to len characters from the current packet and place them into buffer
  // Returns the number of characters read, or 0 if none are available
  virtual int read(char* buffer, size_t len) { return read((unsigned char*)buffer, len); };


Let's talk about the ESP version of the WiFiUdp example that works if it is run on the ESP. It receives a packet on port 3333 from PacketSender and then, I have it currently set up to respond to the receipt of the packet back to port 3333. This works no problem. So basically it is sending and receiving on the same port.

For Teensquitto there are actually several cases that I tested:
1. Use AsynchUDPpacket to listen on port 3333 and send messages to port 4210 using WiFiUdp. This works and is the example sketch that I posted as an example for the library. See screenshot:
WifiUDPex.PNG

2. The second test using WiFiUDP using Teensquitto was just sending a message with and without the onDetect callback. Both cases work without a problem. Using packet sender I was able to send the message to the Teensy and it printed on the console.

3. OK Never mind the third case was adding to send a message back on the same port. Last night it wasn't working.... This morning its working. Must be another of those weird cache issues.

EDIT: Forgot a case.
The last case, which I couldn't figure out was how to do this with AsyncUDP only

EDIT2: Forgot a couple things the above test cases were all where the UDP.writes were acting as acknowledgement packets, i.e. pseudo code
Code: 
  if (packetSize)
  {
      read message
      send different message
   }

If I change it up to continually send a different message:
if (packetSize)
{
read message
} else {
send different message
}[/CODE]
it doesn't work, does identify that it received a message or but it doesn't send the second message.
 
Last edited:
Ok. Here is another interesting case.

If I create two Udp connections:
Code: 
//Teensquitto setup for UDP send and receive
teensquitto Udp = teensquitto("WiFiUdp", &Serial1);
teensquitto UdpS = teensquitto("WiFiUdp", &Serial1);
and define two different ports:
Code: 
unsigned int localUdpPort = 4210;  // local port to listen on
unsigned int localUdpPortS = 3333;  // local port to listen on
and the do a begin like so:
Code: 
  Udp.begin(localUdpPort);
  UdpS.begin(localUdpPortS);
and then in the loop:
Code: 
  int packetSize = Udp.parsePacket();
  if (packetSize)
  {
    // receive incoming UDP packets
    Serial.printf("Received %d bytes from %s, port %d\n", packetSize, Udp.remoteIP().toString().c_str(), Udp.remotePort());
    int len = Udp.read((unsigned char *)incomingPacket, 255);
    if (len > 0)
    {
      incomingPacket[len] = 0;
    }
    Serial.printf("UDP packet contents: %s\n", incomingPacket);
    packetSize = 0;
  }
    // send back a reply, to the IP address and port we got the packet from
    UdpS.beginPacket(UdpS.remoteIP(), UdpS.remotePort());
    UdpS.write(replyPacket,30);
    UdpS.endPacket();
it should listen on port 4210 and if it got a message print it to the console. At the same time it should be continuously streaming the reply packet to the second port 3333. I think that is the way it should work.

Anyway what happens is nothing is streaming to 3333. If I send a message on 4210 there is no response in the serial monitor that it got the message. However, if I switch ports to 3333 and send a message the sketch responds by printing a message too the monitor and I get a single response back to the server (packetSender).

Guess I really don't understand UDP....
 
you cant create more than one udp connection, its hard coded to one only, thats why whatever you do to one affects the other, they both technically link back to the same object at the source (ESP), due to the constrained connection limit on the ESP of maybe 4~5 i have omitted to add multi object support, but it can be added with a few edits to all funtions in teensy library and esp sketch...

so basically when you tell it to goto 4210 and tell the second object to goto 3333, you told the ESP object itself to switch 2 times, last one being 3333... thats why :)

Essentially, Udp and UdpS, 2 objects on teensy, to clarify, both link back to the single object Udp on the ESP. The functions have been designed to follow back to a specific object
Hope it clears that up, but I’m pretty sure I told you that when you played with WiFiClient last time
 
Hope it clears that up, but I’m pretty sure I told you that when you played with WiFiClient last time
Click to expand...
Yeah now that you mention it you did - sorry - I forgot.

Any got it kind of working by asyncUDP for one and wifiUDP for the other port. I got qgroundcontrol at least reading heartbeat messages (gps and basic mavlink messages). Now trying to figure out why qGCS is not sending the messages to or why the sketch is not reading them. I think its the former.

:)
 
Yeah - they have been around a long time but right now I am not using the libs.

BTW: Finally am able to send and receive mavlink messages from qGrounControl. Just have an issue with the incoming packet contents. Still working that piece. :)

EDIT: SUCCESS. Got two way heartbeat messages working as well as transferring gps data to qGroundControl. Now, for a break and I can figure out how qGCS works and expand the use of mavlink in the sketch :)
 
Last edited:
Ok. Added teensythreds to collect GPS/IMU data and then send Mavlink GPS/IMU messages to qGCS. Everything works.

Only issue is that after about 10 minutes communication is lost from the ground control station to ESP/T3.5. I verified this using wireshark - no data is being transfer to qGCS. Not sure what the problem could be.
 
Yeah it was happening without teensythreads as well and without the IMU data being sent either.

EDIT> the little blue lite on the ESP is still on and seems to be blinking very rapidly so it almost looks like its on constantly
 
the blue light is linked to pin #2 just like pin 13 is linked to led on teensy

that means the esp is sending data to teensy

what stops? groundcontrol or everything? did you increase serial1.c buffer like i mentioned earlier? 64 is too small
 
Send and receive. Sending data to port 14550 stops as well as receiving any data on port 14555.

EDIT. The only way to get it working again is to reset the Teesny which also resets the ESP.

did you increase serial1.c buffer like i mentioned earlier? 64 is too small
Click to expand...
I will double check... don't think I did that with the new version of the core.

EDIT2: nope. change it to 256
 
whats on that port? udp? did you test the code directly on esp to replicate?

also for the esp, some libraries might not work well with v2 low bandwidth mode in tools menu, choose the high bandwidth so it uses the full 1460 tcp buffer, else it uses half and might not work well if app isnt designed to work with
 
Ok. Finally got a chance to do some more testing. I changed the buffers on Serial1 to 512 and serial2 to 256. I also changed to v2highbandwidth. The same thing happened, after a couple of minutes I lost communication with the qGCS. No UDP traffic to or from the ESP. The only thing left to do is try the code directly on the ESP. The only thing would be I would have to modify it some - no onDetect and probably not use aysnchUDP and UDP for the two port set up or maybe will do as a better test. What do you think.
 
Status
Not open for further replies.
Back
Top