New project code named: teensquitto

Status
Not open for further replies.
not sure, never used ground control or extended UDP tests, perhaps it could be an issue with mavlink as it does dynamic allocation?
 
Don't know for sure but I have used UDP before and never had an issue but it was always directly on a ESP8266 or ESP32. Mavlink been used on a lot of different platforms and including Teensies with out issue - seen a few projects. The only difference is that no one is really doing it the way we are implementing it with a T3.x to EPS device.

I will give it a try directly on the ESP and see what happens.

PS. Ever thought about porting teensquitto over to a ESP32 :)
 
wouldnt be surprised if it “just worked”
the core methods should be the same on all ESP models, have to compile and see what errors if any they throw or not
 
Just finished the conversion and pretty simple. The only error it threw was because I forgot to include elaspsedMillis for the ESP.

Only thing I deleted was the onDetect method otherwise its the same sketch.

EDIT: of course had to get rid of teensythreads :)
 
:)

“transparency” working on esp32? :) like i said, the core functions are pointed to by the library, so long as they exist, itll compile, no function files have been harmed in the creation of this library :D
 
Well to a point. When I did just a compile no issues. When I went to load it another story - a bunch of errors associated with the ublox library, .o files. So I am compiling without the GPS. Still have the IMU though unless something happens.

I deal with the Ublox issue later, want to get this test done. Anyway, how may serial ports are there on the feather, looking at the pinout looks like there should be 2, Serial1 and Serial2. When I try to use Serial2 no luck.
 
In ublox library I bet you got issues with this:
Code:
#if defined(__MK20DX128__) || defined(__MK20DX256__) ||  defined(__MKL26Z64__) // Teensy 3.0 || Teensy 3.1/3.2 || Teensy LC

  if (_bus == 3) {
    _port = &Serial3;
  }
  else if (_bus == 2) {
    _port = &Serial2;
  }
  else {
    _port = &Serial1;
  }

#endif

#if defined(__MK64FX512__) || defined(__MK66FX1M0__) // Teensy 3.5 || Teensy 3.6

  if (_bus == 6) {
    _port = &Serial6;
  }
  else if (_bus == 5) {
    _port = &Serial5;
  }
  else if (_bus == 4) {
    _port = &Serial4;
  }
  else if (_bus == 3) {
    _port = &Serial3;
  }
  else if (_bus == 2) {
    _port = &Serial2;
  }
  else {
    _port = &Serial1;
  }

#endif
:eek:
 
Your probably right Chris. Didn't really look at the issue yet - wanted to get the UDP communication working first. :) will have to fix that one to work on non-teensy boards. :)
 
Ok. Been working this all day. Besides some annoying problems with the loading the feather board. I did manage to test two versions for UDP directly on the ESP. One with Async and the other with just two instances of WifiUDP. Both failed in the same way. They both lost signal after a few minutes.

I also downloaded new versions of APM Planner and qGroundControl and still had the problem. I did manage to get APM Planner to work at least one way. And as long as I don't open the serial monitor it seems to be maintaining its lock on UDP, but I am not receiving any messages from the APMPLanner.

One thing that I did notice is it looks like the both ground stations can use different ip addresses as well as ports. tomorrow I am going to try this approach and see if I can get them working. :)

Right now I am back to running teensquitto on a t3.5 and it seems to be working - not loosing the transfer from the T3.5 to the ESP to the Ground station.
 
The good news is, for sanity checks, if it won’t work off an ESP, most likely it wont run in teensquitto as it uses the ESP functions transparently, but yeah, like when ESP upgraded its core, it broke marvins asyncmqtt as well which is why we updated. Perhaps, on the old core, your UDP app might still work, it means the library author has to update their library for new core :)
 
When I was using it I was just streaming UDP packets to a processing sketch and periodically sending a command to the ESP and had no problems. This is probably a lot different that what mavlink and the ground stations are doing.

I spent a lot of time doing some googling on what the issue could be and found a whole lot of people were running into some problems. Not the same as mine. One of the things that I think could be the cause, in this instance, the fact that I am using the same IP address for sending and receiving while the GCS's are using two different IP addresses.

I did come across something called mavesp8266 (https://github.com/dogmaphobic/mavesp8266) which acts as a bridge, and uses a ESP8266 Multicast DNS (https://github.com/esp8266/Arduino/tree/master/libraries/ESP8266mDNS) that allows you do what is needed. So this is always a possibility for this application.

In the mean time I am going to try to implement the whole thing as a TCP server/client. I think you have that implemented in teensquitto. I really want to try a do a nifty example for this. :)
 
yup, WiFiClient is supported but your limited to the function calls, don’t try to make local WiFiClient objects or pointers to them, that kind of stuff wont work obviously

You are limited to one WiFiClient object, I never played much with ESP code or WiFi stuff, to me its a project that kept me busy on the side :)
 
Did just notice that ESP8266 Multicast DNS is actually a library within the ESP8266 core. Interesting.

don’t try to make local WiFiClient objects or pointers to them, that kind of stuff wont work obviously
Going to try and follow your example and a couple other I have but I thing the examples all use pointers - should be interesting. Probably just ignore that piece and just use the functions.

to me its a project that kept me busy on the side
You've got a lot of projects that keep you busy on the side :) Anyway you created another monster with this one so you are stuck now :)
 
I remember when SPI_MST started off with STL container and vectors that used dynamic allocations (same as Teensquitto), not soon after, Circular_Buffer was made to prevent dynamic allocations to be used in SPI_MST, but it has matured alot since... Many libraries working with it now, including uart display i use and now teensquitto. Even your IMU threads :)

SPI_MST was only midway through development before we switched out the queue system
back then, once the CB was ready, MST was still put on priority, but I’ve been doing CB and MST upgrades at same time :)
 
Ah I remember it well :) It has both matured and improved dramatically since it began. And tested the heck out of... My poor little t3.5's got over worked - kudo's should go to Paul on its design - it took a beating and keeps going strong :)

EDIT> I am even using threads with Teensquitto so still pretty compatible with every thing. Haven't really figured out how it SPI_MST works with it yet though - that's another project.
 
Indeed - good effort and end results Tony.

"Genius: one percent inspiration and 99 percent perspiration."

Don't forget the 1% credit … as the first to chime in on teensquitto so you didn't have to chat to yourself - and then suggesting SPI_MST and also said there are better ways than STL for micro data storage … of course you over engineered and over achieved all 3 by at least 200% on both counts … i.e. 400% … so that puts any contribution of mine well under 0.25% - but still part Genius :)

And yes the PJRC T_3.5 and T_3.6 are (bigger) better versions of the solid T_3.2 - I thought I broke one the other day ... the one I had breadboarded to test T_LC SPI early on … then I saw the mark on the USB connector to remind me I cut the VUSB trace ( Hint: Pearl white nail polish is not as good reminder as a RED hue! - though I did see it before I worried too much and have updated the color. )

** This threads has views by 152 members … 'only' 110 on SPI_MSTransfer … and 83 on CircularBuffer > that probably has the most general utility
 
Yup!, although my documentation skillz are lacking, i’ve included you guys as well as linearism in the source :)

Next project will be a challenge and may take awhile to get the basics up, but if things do work out, teensy will have something very unique :)
 
I wasn't going to mention the horrendous lack of usable documentation to allow it to be used to full effect :) More lack of desire than skillz I'd suppose - bringing something to life is way more cool than changing diapers.

What's the next thing CAN?
 
Yup!, although my documentation skillz are lacking, i’ve included you guys as well as linearism in the source
And more examples are being added......
Hint: Pearl white nail polish is not as good reminder as a RED hue!
Got to remember that one since I have some with the traces cut and some without :)

BTW. Since I am stubborn I managed to get UDP to transmit to APM Planner 2.0 for just about an hour before I had to turn disconnect to go do some errands. Finally figured out that APM planner would disconnect if it received a packet that wasn't the proper length so this is what I ended up with:
Code:
    UdpS.beginPacket(UdpS.remoteIP(), UdpS.remotePort());
    int nbytes = UdpS.write(buf, len);
    if (nbytes < len) {
        Serial.println("Got Stop Indicator!!");
        once = true;
        UdpS.begin(localUdpPortS);  //for sending messages
        Serial.printf("Send port at IP %s, UDP port %d\n", WiFi.localIP().toString().c_str(), localUdpPortS);
    }    
    UdpS.endPacket();

Now to go resolve a couple of other issues and clean up some of the debugging code I added:
 
next question is on setting up a Wifi server and client. In looking at the .h and .cpp files it does not look like there is an option for setting up a wifi server currently. Also, in looking at the WiFi client code WiFiClient serverClients doesn't look like it has been implemented probably because server has not yet been implemented.

Now, the reason I am asking is that I want to set up a wifi server for a couple of projects. Wanted to start off with converting the following, but doesn't look like it can be done right now. Are you planning on updating teensquitto to implement wifi server?

Code:
/*
  WiFiTelnetToSerial - Example Transparent UART to Telnet Server for esp8266

  Copyright (c) 2015 Hristo Gochkov. All rights reserved.
  This file is part of the ESP8266WiFi library for Arduino environment.

  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 2.1 of the License, or (at your option) any later version.

  This library is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  Lesser General Public License for more details.

  You should have received a copy of the GNU Lesser General Public
  License along with this library; if not, write to the Free Software
  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*/
#include <ESP8266WiFi.h>

//how many clients should be able to telnet to this ESP8266
#define MAX_SRV_CLIENTS 1
const char* ssid = "**********";
const char* password = "**********";

WiFiServer server(23);
WiFiClient serverClients[MAX_SRV_CLIENTS];

void setup() {
  Serial1.begin(115200);
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  Serial1.print("\nConnecting to "); Serial1.println(ssid);
  uint8_t i = 0;
  while (WiFi.status() != WL_CONNECTED && i++ < 20) {
    delay(500);
  }
  if (i == 21) {
    Serial1.print("Could not connect to"); Serial1.println(ssid);
    while (1) {
      delay(500);
    }
  }
  //start UART and the server
  Serial.begin(115200);
  server.begin();
  server.setNoDelay(true);

  Serial1.print("Ready! Use 'telnet ");
  Serial1.print(WiFi.localIP());
  Serial1.println(" 23' to connect");
}

void loop() {
  uint8_t i;
  //check if there are any new clients
  if (server.hasClient()) {
    for (i = 0; i < MAX_SRV_CLIENTS; i++) {
      //find free/disconnected spot
      if (!serverClients[i] || !serverClients[i].connected()) {
        if (serverClients[i]) {
          serverClients[i].stop();
        }
        serverClients[i] = server.available();
        Serial1.print("New client: "); Serial1.print(i);
        break;
      }
    }
    //no free/disconnected spot so reject
    if (i == MAX_SRV_CLIENTS) {
      WiFiClient serverClient = server.available();
      serverClient.stop();
      Serial1.println("Connection rejected ");
    }
  }
  //check clients for data
  for (i = 0; i < MAX_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()) {
          Serial.write(serverClients[i].read());
        }
      }
    }
  }
  //check UART for data
  if (Serial.available()) {
    size_t len = Serial.available();
    uint8_t sbuf[len];
    Serial.readBytes(sbuf, len);
    //push UART data to all connected telnet clients
    for (i = 0; i < MAX_SRV_CLIENTS; i++) {
      if (serverClients[i] && serverClients[i].connected()) {
        serverClients[i].write(sbuf, len);
        delay(1);
      }
    }
  }
}
 
So if I understand correctly in the teensquitto.ino file I can create the web server/client code and then just send the output to? Wouldn't that conflict with udp or mqtt connections? Not trying to be difficult but just confused on exactly how to do it in this situation. :(
 
Hi tonton,

not much action on the teensyquitto thread, so thought I would revive it. I am not sure if right place to ask, but I am in early stages of a project where I am saving data to the SD card on a teensy 3.6. What I am looking to do is add an esp8266 that will allow the data saved to the SD card to be then sent to a network server. So there will be multiple devices saving data, and when a unit is not being used, I would then some how send a command to pull all the data off the SD card. I guess I am asking if you think this is possible. I assume I would have to open the file on the teensy, stream the data over serial to the ESP, which would then send it out via wifi.
Reason for all of this is that it will greatly reduce the headaches of having to pull the SD cards out of the devices, download to a computer and keep it all organized. So being able to stream the data off the device would be ideal and just trying to get a sense of what is possible.
Thanks again for all the work you put into your coding, your circular buffer library has come in very handy.
 
you could send the data over mqtt, dont know what type of server you have planned? the teensquitto protocol can be manipulated at the ESP end if needed, where the entire payload you send from teensy appears as one big single array block on the ESP end. You could always add custom code there to make it do what you want :)
 
Status
Not open for further replies.
Back
Top