Parallax-ESP Module and UDP

iseries

First off lets talk about UDP.

UDP allows me to open a connection on the network to a remote device but I don't care if the remote device is ready or listening for my connection. I can just go ahead and send a packet of information to that remote device and if it's not listening it just goes into the bit bucket never to be heard from again.

So if you have critical data that needs to get to the remote device and you can't afford to lose the data then this is not what you want to use. You would want to use a TCP connection so that if you open the connection and the remote is not listening then the connection would fail telling you to try again later.

Now once the port is open you can freely send packets to that remote host and move on to the next task with no guarantee that it was received. In addition you can also send a packet to a broadcast address so that every device on the network can received the same packet of data. So if there are 10 devices listening they will all receive that packet of information. The broadcast address is set by changing the last octet to 255. So the address 192.168.1.255 is the broadcast address that will allow all devices on that network to receive that packet.

This could come in handy if you have some information that you want publish every so often and you may want it once in a while. All you need to do is open a port and wait for the information to come.

So if I have 5 Parallax-ESP units each taking temperature reading at different location throughout the building and I want to collect this information at a central hub I would just build a central server listening to that port and collect those readings. Like wise each of the ESP units would also see those reading as well. The central server could also send out a packet that lets them know they should send in there temperatures. Now some care should be taken such that they all don't send them at the same time causing some of the packets to be lost because you were not able to receive them fast enough.

The latest firmware for the Parallax-ESP unit has UDP in it. It uses the same Send and Receive commands for processing the data so the only change is the UDP start command.

b=UDP:address,port E
Open a UDP connection to address on port.
Address
The destination address of the target to connect to.
Port
The port number to attempt communications on.
Returns b = S,handle E on success, or b = E,code E on error; see Error Codes. Use the
returned connection handle with CLOSE, SEND, or RECV commands.

The TKN_UDP code is 0xDE and the current C library function do not contain a function for doing UDP so you will have to roll your own code.


Here is a sample C program that sends out a packet and then polls for an incoming packet. This program uses a special print program so that the returned data which could contain command codes is encoded. This is because I used the console port for both sending data over the WiFi and as my debug console. This could be simplified if you used different pins for the Parallax-ESP module.

#include "simpletools.h"
#include "fdserial.h"

void test_print(char *, int);


#define UDP 0xDE
#define CMD 0xFE
#define SEND 0xEA
#define RECV 0xE9
#define CLOSE 0xE8


char Buffer[256];
int Handle;
fdserial *fd;


int main()
{
  simpleterm_close();
  // Put ESP unit in command mode
  pause(10);
  low(30);
  pause(1);
  input(30);
  pause(1);
  fd = fdserial_open(31, 30, FDSERIAL_MODE_NONE, 115200); //Buffered input
  
  dprint(fd, "%c%c101.1.1.255,9710\r", CMD, UDP); // open UDP broadcast ip with port
  readStr(fd, Buffer, 256);
  
  test_print(Buffer, 256);
  Handle = Buffer[4] - '0'; // get handle and make number
  dprint(fd, "%c%c%d,4\r", CMD, SEND, Handle); // send test data
  dprint(fd, "TEST"); // Test data
  readStr(fd, Buffer, 256);
  
  test_print(Buffer, 256);
  
  
  while(1)
  {
    pause(1000);
    dprint(fd, "%c%c%d,256\r", CMD, RECV, Handle); // send receive command
    readStr(fd, Buffer, 256);  // read the results
    test_print(Buffer, 256);
    if (Buffer[4] > '0')  // we got something
    {
      readStr(fd, Buffer, 256); // get received data
      test_print(Buffer, 256);
      dprint(fd, "\r");
    }
  }  
}

void test_print(char *data, int size)
{
  for(int n = 0; n < size; n++)
  {
    if(data[n] <= 128 && data[n] >= ' ')
    {
      dprint(fd, "%c", data[n]);
    }      
    else if(data[n] == 0)
    {
      dprint(fd, "[%x]", data[n]);
      break;
    }      
    else if(data[n] == '\n')
    {
      dprint(fd, "%c", '\n');
    }
    else
    {
      dprint(fd, "[%x]", data[n]);
    }      
  }  
}

In my case my internal network IP address range is 101.1.1.X so the broadcast IP is 101.1.1.255. You will have to change this as your internal network will be different then mine.

Mike

Clock Loop

I will give your example a try and see if I can produce a spin version!

With my railroad engine controller project, I think UDP is exactly what I need for communications with other railroad cars and other railroad crossings, and switches.
Since my engine will be the master of them all.
The current way to do it is slow(as you have already discussed with me) and with a model railroad, its not critical for verification of data.
I will simply send the data many times over, so if one doesn't get through, another will.

Clock Loop

What do you see in your terminal window with this code?

I am getting odd results.

E,1 errors sometimes as a reply to the recv command and sometimes S,0

Also, you mention your program 'polls' but I cannot find that, I can only find recv command, but I am not great with c.
Is the poll command needed ?

iseries

What I mean by poll is it does a receive every so often to see if data is available. If there is no data it just returns S,0 and if it received a packet of data it will return S, and the number of bytes in the packed followed by a return and then the packet of data.

Example: [FE]S,4[0d]TEST[0d]

In the case of the C code it eats the [0d] or return so it does not show up in the debug terminal.

Mike

Clock Loop

iseries wrote: »

What I mean by poll is it does a receive every so often to see if data is available. If there is no data it just returns S,0 and if it received a packet of data it will return S, and the number of bytes in the packed followed by a return and then the packet of data.

Example: [FE]S,4[0d]TEST[0d]

In the case of the C code it eats the [0d] or return so it does not show up in the debug terminal.

Mike

Ok, I thought that was the case since you mention there is no warning that data arrived.

So then I will try to recomplile the parallaxesp firmware because I am not sure my latest compile is working properly.

I tried to split up the udp transmission code and the receive code into two seperate programs to upload to two different props, but that didn't work either.\
I will try to re-git the esp firmware and re-flash it.. perhaps I don't actually have the latest code.?

I tried just removing all the debug feedback and monitor the tx and rx lines to see if it ever receives data but does not.

I also get messages saying something is unhandled or something, I will post the exact response.
Have you changed your local copy of the esp code at all? Or are you working with the latest copy on github?

Clock Loop

I re-downloaded and recompiled the esp firmware just now, and I am getting the same results.

I keep getting these 'no handler for' messages...
And it says it for the REPLIES?
I have no idea what is going on here.

Even the debug output for the connect to udp address replies with
30310> [30310] Reply: '=S,5'

But then it says this??? I have never had this happen before, so I don't know what this means.
31310> No handler for '=S,5'

Here is the debug output from the module.

 29805> UART break detected. Switching on SSCP command parsing.
 30310> [30310] Calling 'UDP' handler
 30310> [30310] Reply: '=S,5'
 31310> No handler for '=S,5'
 31311> [31311] Reply: '=E,1'
 31312> [31312] Calling 'SEND' handler
 31313> [31313] SEND 5 4
 31313> [31313] Reply: '=S,0'
 31316> No handler for '=E,1'
 31318> [31318] Reply: '=E,1'
 32314> [32314] Calling 'RECV' handler
 32315> [32315] RECV 5 256
 32315> [32315] Reply: '=S,0'
 32315> No handler for '=S,0'
 32317> [32317] Reply: '=E,1'
 33317> [33317] Calling 'RECV' handler
 33317> [33317] RECV 5 256
 33317> [33317] Reply: '=S,0'
 33318> No handler for '=E,1'
 33320> [33320] Reply: '=E,1'
 33322> No handler for '=S,0'
 33325> [33325] Reply: '=E,1'
 34320> [34320] Calling 'RECV' handler
 34320> [34320] RECV 5 256
 34320> [34320] Reply: '=S,0'
 34320> No handler for '=E,1'
 34322> [34322] Reply: '=E,1'
 34325> No handler for '=S,0'
 34328> [34328] Reply: '=E,1'

Clock Loop

For some reason the code

readStr(fd, Buffer, 256);

Is sending data to the wx device, which is why i am getting no handler messages.
The prop code is sending the WX devices replies back to its-self with the readStr function?

iseries

Right, Since the return code starts with a CMD code sending it "=S,5" will generate that message. The the problem with using the ESP unit as a console and a device.

You need to build the print code I have on the bottom of the C program so that code that is received and then sent back to the console does not get interpreted as a command. Should be simple enough to write a spin version of that function.

Mike

Clock Loop

My problem is that i cannot get any data to flow either way in your C example.
Even if I run your code untouched, and input the proper ip broadcast address, i can't get data to flow.
I wonder if i could find a udp packet sniffing program or something..

I wouldn't think my router is filtering the packets.
I am running ddwrt on the router with most default settings.

I haven't even attempted to write anything in spin.
I am just trying to get the c example to work.

iseries

Ok, what hardware are you using. My setup is a propeller mini connected to the programming pins.

I highly doubt your router is filter those packets out. Also the code you need is not in master yet so I may have to give you my firmware until it gets updated.

Mike

Clock Loop

iseries wrote: »

Also the code you need is not in master yet...

ROFL




...
Well at least I now have a packet sniffing and udp packet generation programs installed.

iseries

Wireshark seems to do the trick for that.

Mike