Sending this kind of data over Wi-Fi is not common (in my experience) but if you really want to do it over Wi-Fi you will require to do network socket programming or use a package such as Ncat. Also, maybe this could help you.
I would personally rather use Bluetooth to send this kind of data. I would use Bluetooth's SPP profile. In case you are interested I suggest you to read section 6.7 of the Edison's Bluetooth® User Guide and these documents that might also interest you:
1 of 1 people found this helpful
I am programming the arduino board with Eclipse so my answer might not apply fully if you use the Arduino IDE.
I have developed something very similar with a PC analyzing data coming from the Edison over wifi/ip and sending back instructions. I am using UDP, it is the simplest protocol to set up and the supposed lack of reliability is not an issue for my application (otherwise TCP would be a step up).
On the Edison side, I found the practical C++ socket library very easy to use
http://cs.ecs.baylor.edu/~donahoo/practical/CSockets/practical/ . However I ended switching to the standard C++ linux library <sys/socket.h>, it is a little more complicated but gives more control > (your implementation would probably also need utility functions from <netinet/in.h> and <arpa/inet.h> ).,
On the PC side, if you use visual studio, the UDPClient class is straightforward.
The only little complexity is the program flow since you want the calls to the socket read function to wait for complete data frames to arrive otherwise your messages will be mangled and you will need some markers to figure out where they begin and end. The practical solution is to create a listening thread, With regular C++, it very easy to implement multithreading on the Edison (esp with C++11) I don’t think the arduino framework includes multithreading though. If it is the case you will need to use non-blocking calls to the socket (I tried but never found how to do that) and message markers.
Finally, if you have a listening thread, it will need to queue the messages for the main program to consume while you make sure there is no risk of concurrent access, On the edison side, you can use the straighforward std:queue class to implement a LIFO queue, you prevent concurrent access to it with locks, which can be easily implemented with the <mutex> class. On the PC side the CurrentQueue class handles everything for you.
Hope this help and it is actually much simpler than it sounds !
Another thought, if you really want to stick to serial communication, you can use two Xbee circuits. You set them up once using your PC and then they act as the two ends of a serial cable. It is completely transparent for the Edison and the PC. The only caveat is that the technology is designed for reliability and low power consumption not throughput. 9600 is the highest effective throughput i have been able to achieve plus it defeats the purpose of an all in one circuit like the Edison, which offers two wireless technology, to add and external circuit wiht yet another wireless tech.
I started thinking about the XBee, yes.
looks like the most practical way to send data to actuators and receive data from sensors.
I thought about Bluetooth, too, but the range is quite limited.
My Wi-Fi field is rather large and the over would have some space to... uhm... Play.
BT range is too short, although still good for testing.
This is interesting, and would avoid the rather steep cost of a pair of XBee and the shields.
Do you, by any chance, have any examples?
After thinking about it for a while, looks like that XBee is the most practical way to go.
Now I have another question, but this is hardware related... Which XBee sheld should I get for the Edison-Arduino?
Looks like not all of them are compatible...
I don’t know about shields however I have been using the SparkFun XBee Explorer Regulated breakout board. It is a low cost and versatile circuit that can easily be recycled for other project. For your application, the Xbee chip will only require four connections that can be easily implemented with jump wires. : Power, Ground, Serial Transmit, Serial Receive. Any other breakout would do just as well, the only decision is whether you want to supply 5V from the board and have the board power regulate it to 3.3V or you will supply directly 3.3V. On the PC, you probably want to get a Xbee USB dongle, iis more convenient.
Also, I will try to post some code to help you with the UDP option, but not before the week end. Sorry, I have been travelling since you posted your request.
No shield? Even more interesting.
I think I'll go XBee, though UDP (Which, in 30 years of coding, I never used) is still interesting.
Difficult to teach a new trick to an old dog,... We'll see. :-)