SparkFun Forums 

Where electronics enthusiasts find answers.

All things pertaining to wireless and RF links
By carl888
#116521
Hi,

Is it possible to use the WiFly shield to receive UDP packets like with the Ethernet shield?

Using the Ethernet shield with a Duemilanove, I was able to send and receive UDP packets by using the standard ethernet libraries and a small amount of code like this:
Code: Select all
#include <ethernet.h>
#include <Udp.h>

void setup(){
Udp.begin(localPort);    // start UDP
}

void loop(){
int packetSize = Udp.available(); // note that this includes the UDP header
  
  if(packetSize)
  {
    packetSize = packetSize - 8;      // subtract the 8 byte header
    Udp.readPacket(echoStream,255, remoteIp, remotePort); //read the remaining packet
  }

Serial.println(echoStream); //This will print the contents of the packet received.
}
The UDP.c / UDP.h files were created for use with the Ethernet shield and not the WiFly shield, so they don't appear to work natively. I've tried googling this, and I get some results which state that UDP communication is supported, but I can't find any physical examples of it being used.

Any help would be appreciated, I'm fairly new to Arduino dev, and very new to the WiFly shield so I don't understand a great deal yet.

Thanks
By follower
#116555
Hi,
carl888 wrote:Is it possible to use the WiFly shield to receive UDP packets like with the Ethernet shield?
Short answer: sort of, but not really.
The UDP.c / UDP.h files were created for use with the Ethernet shield and not the WiFly shield, so they don't appear to work natively. I've tried googling this, and I get some results which state that UDP communication is supported, but I can't find any physical examples of it being used.
The WiFly module supports UDP in a limited form but the WiFly library does not support it at all.

You can read chapter 11 "Sending data using UDP " of the WiFly User Guide (e.g. http://www.sparkfun.com/datasheets/Wire ... SX-um2.pdf ) to get an idea of UDP support the WiFly module provides. AFAICT it's nothing like the support that is possible with the UDP library for the Arduino Ethernet shield.

There's been some comments on the forums here that suggest people have had some success with UDP on the WiFly but I've not seen any code.

I don't anticipate adding support for UDP to the library in the near future but will look at patches if someone provides them.

--Philip;
By carl888
#116577
Hi Philip, thanks for your response.

It's a bit disappointing. Is there another protocol that the WiFly supports that I can use to send small packets to the Arduino for processing (probably a max of 10-15 chars in one packet)? I'm trying to send data from an iPhone to the Arduino, which will then process and output the data as Infrared codes via an IR-LED. Speed is the key to it working well (if network delays occur, my TV won't turn over quickly enough) so I've been trying to stay away from the HTTP route.

Thanks again.
By follower
#116610
carl888 wrote:It's a bit disappointing. Is there another protocol that the WiFly supports that I can use to send small packets to the Arduino for processing (probably a max of 10-15 chars in one packet)?
If it suits your purposes well enough and you could write the additional code to support it, you could probably make the WiFly's limited UDP support work as it seems what you want isn't very demanding.
so I've been trying to stay away from the HTTP route.
The other approach would be to have the equivalent of a "telnet" connection (i.e. just a plain socket connection ) and remove the HTTP overhead. That would probably improve the latency issues and could use the existing library AFAIK.

--Philip;
By dillan
#121101
follower wrote:The other approach would be to have the equivalent of a "telnet" connection (i.e. just a plain socket connection ) and remove the HTTP overhead. That would probably improve the latency issues and could use the existing library AFAIK.

--Philip;
Thanks for bringing this up Philip. I am pretty new to network programming and was wondering if you might have a quick example of how to pull off a simple socket connection. I've searched around and haven't come across any clear examples.
By rabaukendisko
#124316
Hi there,

I just read you post and it seems like I'm having the same issue.
Was just wondering whether you have found out how to send / receive simple UDP messages from WiFly? There seems to be no documentation about this.
Quite frustrating...

Thanks,

Dine
By mckinnley.workman
#128462
Hi,

I am also trying to use UDP with WiFly and running into the same problems. Has anyone had any success with it?
By jam60
#128587
I'm in the same boat. I want the TouchOSC iOS app to communicate directly with the WiFly, eventually in adhoc mode but I'd settle for infrastructure mode first. But I have yet to see the WiFly communicate anything in either direction via UDP. The tx light flickers when i send data from the SpiUartTerminal, but I can't get Packet Peeper or a simple Python UDP server on my Mac to indicate that any packets were actually received. I know the TouchOSC app is configured and working because I can communicate with it between two iOS devices and I can also sniff the packets in Packet Peeper and decode them with my simple Python UDP server.

I don't have a choice of different protocol so long as I want to use TouchOSC. It transmits via UDP datagrams (not stream). I suspect the WiFly is in UDP stream mode given ambiguous statements in the WiFly user manual, but there is no indication of how to put it in datagram mode (if it even has one). The alternative to TouchOSC is to write a custom iOS app, which I can do but it's a lot more hassle.

Has anyone seen any UDP traffic either direction from the WiFly? If so, could you please describe how you saw it?
By jam60
#129114
I was able to get the WiFly to communicate via UDP. Part of the problem was that the packet sniffer I was using (Packet Peeper) was lying to me and not showing UDP traffic - I hate it when the analysis tool is the problem.

I can't really grok the "file" capability of the WiFly (the "save" and "load" commands). It's not at all clear exactly what information is stored/loaded. It certainly doesn't appear to be saving and loading the ssid and passphrase of the preferred network. If I set them and save a configuration, then reload it, the ssid and passphrase are back to factory defaults and obviously the WiFly can't join my network.

Anyway, I can get the WiFly to pretty reliably initialize and communicate both directions via UDP if I do the following:
Code: Select all
set comm time 2000
set ip proto 1
set ip host x.x.x.x   // IP of remote UDP machine, may not matter
set ip remote 9000
set ip local 8000
set wlan ssid <ssid>
set wlan pass <passphrase>
// delay here if called in a sketch
join
Then use a UDP source to send packets to the WiFly's IP address. I'm using the iPhone TouchOSC app or a simple python test client (below). TouchOSC uses datagrams. The WiFly can receive either datagrams or a UDP stream.

Here is the python UDP datagram test client:
Code: Select all
import socket
mySocket = socket.socket ( socket.AF_INET, socket.SOCK_DGRAM )
mySocket.sendto ( 'Wherefore art thou?', 0, ('192.168.1.107', 8000) )
Here is the python UDP stream test client:
Code: Select all
import socket
mySocket = socket.socket ( socket.AF_INET, socket.SOCK_STREAM )
mySocket.connect(('192.168.1.107', 8000) )
mySocket.send ( 'Wherefore art thou?' )
My next step is to figure out how to detect datagram boundaries at the Arduino. The data arrives over the serial port and one has no idea what the datagram boundaries are. The UDP headers have been consumed by the WiFly apparently. When the Arduino echoes data received via UDP streaming the data is enclosed in "*OPEN*" and "*CLOS*" but I haven't a clue where those delimiters are coming from. They do not appear at the Arduino when a datagram arrives.

I'm trying to modify the WiFly library to accomplish detection of datagram boundaries since TouchOSC sends datagrams and I need to decode them atomically. If anyone has suggestions I'm all ears.
By jam60
#129250
More progress using UDP.

Here is a sketch based on WiFly_WebServer.pde that accepts UDP traffic on port 8000:
Code: Select all
/*
 * UDP Server
 *
 * (Based on WiFly_WebServer Example)
 *
 * A simple web server that echoes data arring via UDP on server port.
 */

#include "WiFly.h"
#include "Credentials.h"


Server server(8000);

void setup() {
  WiFly.begin();

  if (!WiFly.join(ssid, passphrase)) {
    while (1) {
      // Hang on failure.
    }
  }

  Serial.begin(9600);
  Serial.print("IP: ");
  Serial.println(WiFly.ip());
  
  server.begin();
}

void loop() {
  Client client = server.available();
  if (client) {
    while (client.connected()) {
      if (client.available()) {
        char c = client.read();
        Serial.print(c);
      }
    }
    client.stop();
  }
}
And here is a python script that will send data via UDP datagrams:
Code: Select all
import socket
import time
mySocket = socket.socket ( socket.AF_INET, socket.SOCK_DGRAM )
for n in range(1, 10):
  print repr(n) + " ";
  mySocket.sendto ( '*OPEN* ' + repr(n) + ' Wherefore art thou?\n*CLOS*', 0, ('192.168.1.107', 8000) )
  time.sleep(1);
Note that it only works (the data is only echoed) if the payload is wrapped in *OPEN*/*CLOS*. That is required in Server.cpp although as I said before I have no clue why those delimiters are required. If you use UDP streaming in the python script (SOCK_STREAM instead of SOCK_DGRAM; see previous post in this thread) the delimiters apparently get added automatically.

Unfortunately I cannot make TouchOSC wrap it's datagrams in delimiters. So I'll have to figure out how to modify the WiFly library to not require them at least for datagrams.
By k_san88
#130674
Hi Jam60, I read of your UDP success with great interest. I too want to use it with TouchOSC and couple it with the Midi shield from SparkFun to drive some Midi gear from my iPad. Did you have further progress with TouchOSC? Thanks in advance for any sharing you might care for.
By jam60
#131109
avidan and k_san88: sorry, no progress since my last post, summer fun with kids and other projects keep getting in the way. Hopefully I'll get back to this soon. My plan is to look closely at recotana's OSC arduino library (http://recotana.com/recotanablog/closet) and perhaps other C++ OSC libraries to see if I can adapt something. If I can turn one of those into an OSC message parser including correct computation of message length then the packet boundary issue should be moot.
By avidan
#131138
thanks for the update. what happened when you used the python and the script you posted? did that function? perhaps we can modify the wifly library to not require those enclosing statements...
User avatar
By viskr
#131175
We've been using UDP on WiFly to gather data and send it to a PC from a remote sensor.

enter command mode with $$$
then enter "set ip proto 1" for UDP mode
to set the IP to send to enter "set ip host 192.168.1.2" or whatever
finally enter "save" and "exit"