<\/p>\n
We have designed a computer network consisting of one Server (NanoESP S), two Arduino Clients (NanoESP C1 and C2) and a Laptop as third Client (running there either Packet Sender https:\/\/packetsender.com\/download<\/a> or TWedge of TEC-IT https:\/\/www.tec-it.com\/de\/download\/Default.aspx<\/a> ), to construct a small UDP WiFi network. We denote it as Y-configuration, which symbolizes the connections. The center is the Server S, at the ends of the inclined arms of the Y are the Arduino Clients C1 and C2 and the vertical line is the connection to the Laptop as third Client.<\/p>\n The Setup<\/p><\/div>\n The NanoESP or Pretzel Board is a combination of an Arduino Nano and the WiFi module ESP8266, which are connected via Softserial pin 11 (Arduinos RX) and pin 12 (Arduinos TX). A similar configuration can be realized also self-made. The Clients can principally not communicate with each other directly. This can only be done via the Server. A special message structure enables this. The following IP addresses are assigned:<\/p>\n Packet Sender is a program, which enables to send and to receive messsages. TWedge sends and receives messages as well, but enables to visualize the results in Microsoft Excel.<\/p>\n The following Ids are assigned:<\/p>\n The following ports are used:<\/p>\n The sketches have the following names: S<reverse date>_<designation> with the following designations:<\/p>\n <\/p>\n The use of library functions is omitted to have a clear idea, which AT commands are sent, to which one can refer by https:\/\/room-15.github.io\/blog\/2015\/03\/26\/esp8266-at-command-reference\/.<\/a>.A drawback of the ESP8266 is, that receivings from it can be either messages from outside or answers of the module itself (self generated answers). Sending messages via the ESP8266 is also realized with AT commands. There is no clear separation between an AT mode and working mode (sending and receiving).<\/p>\n All configuring AT commands are given in the Setup part of the sketch, although it would not be necessary to configure the ESP8266 after each restart. The AT commands are sent in the subroutine sendCom, which also analyzes the answers of the module on the command without fully printing out it.<\/p>\n Remark<\/strong>.: In the subroutine SendCom() the expression is used: esp8266.findUntil(“OK”, “ERROR”), which is true, when before “ERROR” “OK\u201c has been found, and false, when at first “ERROR” has been found or both strings have not been found..<\/em><\/p>\n <\/p>\n The Packet Sender menu looks like:<\/p>\n The Packet Sender Program<\/p><\/div>\n Under \u201eFile\u201c one finds \u201eSettings\u201c, where one has to configure the following:<\/p>\n Packet Sender Settings (1)<\/p><\/div>\n Packet Sender Settings (2)<\/p><\/div>\n In TWedge the following devices have to be configured:<\/p>\n Twedge Devices<\/p><\/div>\n Substantially TWedge is a single Client, but in the program sending and receiving is separated. The program receives as Ger\u00e4t\u00a02 (UDP Client) and sends as Ger\u00e4t\u00a03 (UDP Server). Received data can be transferred to an Excel sheet and cell contents from the Excel sheet can be sent by TWedge to another Client or the Server.<\/p>\n Sending and receiving are supposed to be realized via the Serial Monitor of the Arduino, which we choose to have a baudrate of 19200. All messages, sent and received are terminated by CR and NL, so that the length is messagelength + 2. To send a message is announced by the following AT command:<\/p>\n AT+CIPSEND=<Id>,<messagelength+2><\/p>\n where Id is the receivers Id as mentioned above. The ESP8266 answers with a prompt: \u201e>\u201c and one can input the message. On the receivers side appears the following:<\/p>\n +IPD, <Id>,<length>:<message><\/p>\n where Id is here the senders Id and length is the length of message.<\/p>\n The separation of At commands sending and receiving to\/from outside can be realized by the principle, that AT commands are sent solely by the Arduino sketch, and what appears on the Serial Monitor or is sent by it are pure messages. For the message a certain structure is chosen, to be aware about the final receivers Id (frId) or the original senders Id (osId), just what is of interest in the network. To this end the message consists of a net message Msg and a single Id. Both informations are separated by a colon (:).<\/p>\n message = <Msg> : <Id ><\/strong> When a Client sends, Id is the frId, and when it receives, it is the osId. For the Server holds the opposite. +IPD, <osId>,<length>:<Msg>:<frId><\/strong><\/p>\n If he is not the receiver by himself, he passes the message to the Client with the frId removed and replaced by the osId, in the form:<\/p>\n message = <Msg>:<osId><\/strong><\/p>\n since for the final receiver is solely the original senders identity (osId) of interest.<\/p>\n Message Structure<\/p><\/div>\n When via the respective Serial Monitor a message is entered without adding an Id, it is executed on place. Messages, which stem from other places of the network, have the form: \u00a0+IPD, <Id>,<length>:<message>, thats why the string \u201c+IPD,\u201c is used to distinguish messages from outside from answers of the ESP.<\/p>\n <\/p>\n It may seem complicated, this adding of the respective Id, either osId or frId, but enables to handle only one Id for each event. Each participant of the network can send to every other participant and even to himself. Receiving a message, the recipient is aware that it was his address, where the message had to be passed. The only question, from where it is, he can see from the osId. Only the Server needs both informations, and can get it from the receivings.<\/p>\n If for example Client 1 wants to send to Client 2 the net message Msg = 123pv, he sends to the Server:<\/p>\n <Msg>:<frId> = 123pv:2<\/strong><\/p>\n after handling by the Server at Client 2 arrives:<\/p>\n <Msg>:<osId> = 123pv:1.\u00a0<\/em><\/strong><\/p>\n The AT commands for configuring the ESP moduls are given in the Setup and are partially executed in subroutines (ConfigESP, ConfigWifi, StartCon and others), whereas the above mentioned IP addresses are defined and the participants of the network define themselfes as Server or Client (station).<\/p>\n In the Loop a hierarchy is defined with if else statements, priorizing receivings, that arrive via ESP, secondly it is looked after news from the Serial Monitor, and only in cases, where both are quiet, it deals with its own tasks.<\/p>\n A receiving from the ESP can be a self generated answer (ESPsga). This is supposed in the beginning of each receiving from the ESP (Flag: ESPsga = true). Only if the sequence \u201c+IPD,\u201d is found, the ESPsga is set false. Since it is an alternative, the receiving is a message from outside. Now follows the parsing of the receiving. In the case of the Server the message might be to send further to the final receiver, by sending it to him while replacing the final receivers Id (frId) by the original senders Id (osId).<\/p>\n To this end the subroutine WiFiSend is used.<\/p>\n Messages as well can be sent from each respective Serial Monitor and received messages are printed out there. The Baudrate is 19200 and CR and LF are to be set active.<\/p>\n The three NanoESP (Pretzelboards) have to be connected to three USB Ports and the Arduino IDE has to be started threefold. In \u201ctools\u201d select the \u201cArduino Nano\u201d and as processor \u201cATMega328P\u201d and select the respective COM Port. When the sketches for Server and Clients are uploaded, after some seconds at the Clients both blue LEDs should lid. Test sending and receiving data with the Serial Monitors.<\/p>\n On the Laptop the network NanoESP appears:<\/p>\n Das NanoESP Netzwerk<\/p><\/div>\n One should connect with this network, but note, that one has no Internet anymore, as long as one is connected with the Y network. The Firewall has to be deactivated:<\/p>\n Firewall deaktivieren<\/p><\/div>\n Afterwards one can send from each Serial Monitor to another network participant messages and receive from others messages. <message>:<frId><\/strong> as example: a letter from me:0<\/strong><\/p>\n (this message goes to the Laptop and either Packet Sender or TWedge).<\/p>\n We wish you fun with your WiFi UDP Y network and hope, that our work will help you further.<\/p>\n Dr. Christian Rempel & Laurin Kettner<\/strong><\/p>\n Zeuthen im August 2018<\/em><\/p>\n Refer to AT commands: https:\/\/room-15.github.io\/blog\/2015\/03\/26\/esp8266-at-command-reference\/<\/a><\/p>\n <\/p>","protected":false},"excerpt":{"rendered":"![\"Der](\"https:\/\/iot.fkainka.de\/wp-content\/uploads\/2018\/10\/001-scheme-e1538984723128-1024x530.jpg\")
<\/a>\n
\n
\n
\n
Download: Ernteroboter_Programme<\/a><\/h2>\n
![\"Das](\"https:\/\/iot.fkainka.de\/wp-content\/uploads\/2018\/10\/002-PS.png\")
<\/a>![\"Packet](\"https:\/\/iot.fkainka.de\/wp-content\/uploads\/2018\/10\/002-PS-s1.png\")
<\/a>![\"Packet](\"https:\/\/iot.fkainka.de\/wp-content\/uploads\/2018\/10\/002-PS-s2-1024x133.png\")
<\/a>![\"Twedge](\"https:\/\/iot.fkainka.de\/wp-content\/uploads\/2018\/10\/003-twedge-menue-1024x724.jpg\")
<\/a>Original sending and receiving:<\/em><\/h3>\n
Separation of At commands and sending and receiving<\/em><\/h3>\n
\nexample: 170pv:1<\/strong><\/p>\n
\nThe Server can get all information from the original receiving, which can only come from another Client:<\/p>\n\n\n
\n location<\/td>\n sending<\/td>\n receiving<\/td>\n<\/tr>\n \n Server<\/td>\n osId<\/td>\n frId<\/td>\n<\/tr>\n \n Client<\/td>\n frId<\/td>\n osId<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n ![\"Message](\"https:\/\/iot.fkainka.de\/wp-content\/uploads\/2018\/10\/004-message-structure-1024x424.jpg\")
The programs structure<\/em><\/h3>\n
Receivings via ESP<\/h4>\n
Sending via the Serial Monitor<\/h4>\n
Start using<\/em><\/h3>\n
![\"Das](\"https:\/\/iot.fkainka.de\/wp-content\/uploads\/2018\/10\/005-find-NanoESP-WiFi-1024x576.png\")
<\/a>![\"Firewall](\"https:\/\/iot.fkainka.de\/wp-content\/uploads\/2018\/10\/006-deactivate-firewall-1024x576.png\")
<\/a>
\nFor example:<\/p>\nDownload: Ernteroboter_Programme<\/a><\/h2>\n