Parallax-ESP Module Latest Hack

123457»

Comments

  • iseries wrote: »
    Looking at the code there seems to be three different codes sent.

    T - connect event
    X - disconnect event
    D - send data event

    Mike

    X and D are in the api pdf (32420-Parallax-Wi-Fi-Module-API-v1.0.pdf) but T is not.

    So thank you! I wonder what that is telling me. '=T,5,0' Connect event on handle 5... ?
  • Anyone know more about the data sent using WX command CONNECT? (and the subsequent SEND)

    What is this format, and what are its variable options?
    Are there options for "Connection: ?"
    Are there other data type formats specific like this one that can be also sent?
            ser.char(13)                '\r                   1
            ser.char(10)                '\n                   1
            ser.str(string("Host: caboose.networkA.local")) '28   Change host and domain here, change how many bytes it sends above, if your address is shorter/longer.
            'ser.str(string("Host: car1.networkA.local"))    '25                                                        
            ser.char(13)                '\r                   1
            ser.char(10)                '\n                   1
            ser.str(string("Connection: keep-alive"))       '22
            ser.char(13)                '\r                   1
            ser.char(10)                '\n                   1
            ser.str(string("Accept: */*"))                  '11           
            ser.char(13)                '\r                   1
            ser.char(10)                '\n                   1
            ser.char(13)                '\r                   1
            ser.char(10)                '\n                   1    92  or 89
    
    

  • Connect requires an IP address or Host name and a Port number to connect to. The send command needs to know how long the data is and then wait for you to send that amount of data.

    An example would be a weather services call that returns the local weather.

    Connect: api.openweathermap.org, 80
    Send: 62 "GET /data/2.5/weather?id=5274867&APPID=<YOURID>&units=imperial"

    Mike
  • Clock LoopClock Loop Posts: 1,940
    edited 2020-10-02 - 22:49:19
    Is there a faster way to connect to another prop and transfer data, but not have to disconnect every time you want to send more data?
    The connect and disconnect timing for me is many seconds.
    Can't the connection be used more than once?
  • That would be HTTP 1.1 - your "Connection: keep-alive" in the Spin Code. Not sure if the ESP supports it.

    Another thing you can do is to resolve the IP address once and use IP instead of DNS name - DNS resolving takes time.

    HTTP over TCP/IP is kind of a slow Protocol by design I think @localroger wrote something to just use UDP, there you can just send and receive data, but no build in error detection or correction, you need to do that by your own code.

    With 2 P1's on each end you do not really need HTTP and TCP/IP I think the ESP supports TELNET so you could build some simple 'serial' bridge and just send and receive bytes like with a normal serial connection.

    Mike
  • Another option would be to use UDP. This is a connectionless send where you listen on a port and then send a packet of data to that port. The problem with this method is there is no guarantee that the packet will received by the other unit.

    HTTP tends to wait a bit to make sure all the data has been received before moving on. Some packets can be fragmented and if you just except the first packet you maybe missing some follow on packets that should have been included.

    I notice when setting up a web page that by the time the propeller got around to responding to the request the other side had moved on and didn't receive the answer.

    Mike
  • iseries wrote: »
    Another option would be to use UDP. This is a connectionless send where you listen on a port and then send a packet of data to that port. The problem with this method is there is no guarantee that the packet will received by the other unit.

    HTTP tends to wait a bit to make sure all the data has been received before moving on. Some packets can be fragmented and if you just except the first packet you maybe missing some follow on packets that should have been included.

    I notice when setting up a web page that by the time the propeller got around to responding to the request the other side had moved on and didn't receive the answer.

    Mike

    I tried running your demo code on the first post. Does the WX module send anything to the debug port when using that code? I can't seem to get it to do anything.
    However I do not know how to make a host for the udp also I would probably need to see a working pair done in c?
    Most of what I am doing is looking at the c code in the learn/examples/network/wifi directory in simpleide and trying it out.

    Got any local udp Client/Host code i can try?
    I don't mind that the data is a catch or nothing deal. I don't really need to know if the data arrived, the catcher better be ready, and know the size, format,etc.
    I do the same with many of my other projects where I just send data to the other side, and if it gets there, good.
    If not, another send will be made right away again anyway.
    That is better than a connect: close: timing delay.
  • UDP is new to the WX and I only have examples going from the WX to a host or sending a packet and getting a response.

    One being getting the current time from a time server.

    Also the current libraries don't support UDP so I will have to see what I can put together.

    Mike
  • msrobots wrote: »
    HTTP over TCP/IP is kind of a slow Protocol by design I think @localroger wrote something to just use UDP, there you can just send and receive data, but no build in error detection or correction, you need to do that by your own code.

    Yes, TCP is bad for high-speed conversations because TCP will halt the whole exchange if a packet is lost in order to recover it, even if you don't care about that packet. All network games use UDP for this reason.

    There is another option if the libraries support it. The ESP8266 and ESP32 support a custom protocol called ESPnow which allows direct peer-to-peer comms between the ESP's without joining a network. The peers just know each other by MAC address. It's limited to 250 bytes per packet but exchange is quick, taking about 5 milliseconds with confirmation to the sender if everything goes right, and it's optimized for long range at the expense of bit rate. I did a 700 meter range test with 4-inch 3 db antennas. I've been using the Arduino IDE though, and it's a real mess if you're not used to wading through C++ code.
Sign In or Register to comment.