ofxNetwork communication with other apps

Hey all,
I’m trying to trouble shoot issues I’m having with with getting OF to receive messages from the arduino’s WiFIUDP class. I added a note to this topic that explains the initial problem better.

I’m now wondering if I can get ofxNetwork and the processing net library to talk and i’m failing there as well. I got an OF Client and OF Server to communicate as well as P5 Client and a P5 Server but OF > P5 isn’t really happening and I’m wondering if I’m doing something wrong or if this problem has something to do with why I’m not receiving anything from the Arduino WiFiUDP connection.

OF code (.cpp)

void testApp::setup(){
    ofSetWindowShape(200, 200);
    ofSetVerticalSync(true);
    ofBackground(ofColor::red);
    udpClient.Create();
    udpClient.Connect("192.168.122.35", 9000);
    udpClient.SetNonBlocking(true);
    cout << "setup server" << endl;
}

//--------------------------------------------------------------
void testApp::update(){
    if(ofGetFrameNum() % 60 == 0){
        sendData();
    }
}

void testApp::sendData(){
    string mess = "hello world";
    int sent = udpClient.Send(mess.c_str(), mess.length());
    printf("=========\n%s\n", ofToString(sent).c_str());
}

P5 code

import processing.net.*;

Server s;
Client c;
String input;
void setup(){
  s = new Server(this, 9000);
}

void draw(){
  c = s.available();
  if(c != null){
    input = c.readString();
    println(input);
  }
  
}

on the of side i get
“=========
11”
printed every second, as it should but I get nothing form the Processing end. Any Ideas?

Not for nothing, but you might also consider using the OSC protocol instead of raw UDP. The library support is in pretty good shape via ofxOSC and on the Arduino side, OSC from CNMAT:

As for your actual question, I haven’t a real clue but would Processing be listening on 192.168.122.35 or would it be something more generic like 127.0.0.1 or hostname.local.?

@pizthewiz I am thinking of going the OSC route at this point. I just want to make sure i’m not missing anything, call me stubborn. and for the processing route I’ve tried this ip 192.168.122.35(ethernet ip), 172.16.123.122(wifi ip) and 127.0.0.1 with the same results. and all these IPs also work when its P5 > P5 or OF> OF

I guess if i don’t figure this out by eod today I’ll just install osc on the arduino and go that route.

Sorry I had just assumed that this was all running on a single machine; a crappy assumption. The machines must be connected by a common network, what ever interfaces connect them to said network, what ever IP address is on said interfaces, that is what you’d want to use.

I haven’t done much with p5 but when you create a new Server can you have it spit out what address it is bound to?

Ah ha, from the Libraries > Net > Server > ip() doc:

println(Server.ip());

That should give you the ip that the oF side should be sending to.

@pizthewiz well this specific prototype IS on the same machine at work which happens to have wifi on and the ethernet also connected, hence the wifi and ethernet ip addresses. but yea just as I thought the print out from the ip() returns the ethernet ip 192.168.122.35

I feel like this shouldn’t be this complicated haha. especially since its so easy to get them to communicate within the same app.

it’s possible that processing is expecting a null terminator try:

void testApp::sendData(){
    string mess = "hello world";
    int sent = udpClient.Send(mess.c_str(), mess.length()+1);
    printf("=========\n%s\n", ofToString(sent).c_str());
}

strings are terminated by a 0 character that is not accounted in the length but if you read 1 more position instead of sending the characters only you’ll send the 0 at the end which delimits the string

@arturo I added an extra character and I’m still not getting any love in P5 from OF though the app in OF is still printing just fine.

haha OSCuino is looking better by the second. But I am really curious though as to why this is being so difficult. @bakercp i feel like we did a demo like this with P5 and Max/MSP in class at the CAD? unless that was with OSC as well? I don’t remember…

i think the problem is that the processing Server and Client classes are tcp not udp:

1 Like

@arturo well that makes sense. I just did a quick OSC implementation in Processing and it sends messages to OF just fine on my computer as well as between 2 computers, one with P5 sending and one with OF recieving. I’m still confused as to why I was having the issues with the arduino in the first place… dang I wish I had my the board here with me at work. Well I’ll keep poking at it. This essentially proves that the network functionality of OF and p5 have no issues talking to each other and the problem is more with ofxNetwork UDP getting messages from arduino wifi udp.

Thanks guys! I’m making progress with this!

1 Like

I doubt the problem is on the OF side, Wifi shields are notoriously difficult to get working with UDP and OSC due to all the Arduino libraries (ardosc,zosc,etc) dependencies on the internal Ethernet library. @pizthewiz have you tested oscuino via wifi- i think it only works on an ethernet or serial transport layer?

WifiUDP is a fairly new Arduino library though, you might just need to upgrade the firmware on your WiFi shield? If that works, you might get UDP but probably not OSC.

Alternatively if you have an ethernet shield, you could buy a $20 tp-link pocket router (http://www.tp-link.com.au/products/details/?model=TL-WR702N) and have that connected to your wifi and have a direct ethernet connection to your arduino. Then you can use any of the tcp/udp/osc examples with no headaches.

@trentbrooks you were right. I ended up having to do a Firmware update on my shield. I picked up the shield over the weekend and so it didnt initially cross my mind to think it may need an upgrade cuz it was totally new! :stuck_out_tongue:

Anyway looks like all cylinders are firing here finally. Thanks!

1 Like

I haven’t used an Arduino Wi-Fi shield, so I will totally buy the ethernet library dependency on most of the OSC libraries. The Wi-Fi shields always seemed disproportionately expensive compared to ethernet and when I did need wireless, I usually went Bluetooth or XBee. Maybe the Yún will start to turn this around, though it is still 2x the price of a Raspberry Pi Model B…
Arduino Yún

1 Like

@pizthewiz I should really have probably just gone with the Yun instead of the Uno with the shield. I’ve not used XBee or Raspberry pi before I’ll probably get around to that sometime soon. Bluetooth would probably not have worked because of a distance thing here. But totally awesome points though.

I moved 4 posts to a new topic: openFrameworks on the UDOO

(@arturo can you move the UDOO discussion to a new topic? I only have a basic user trust level.)

just made you a moderator but i think you can’t move part of a thread to another topic

(the little wrench in the upper left hand corner of a topic allows you to select new posts to move to a new topic, which I just did).

@pizthewiz @KobbyAppiah I was hoping the Arduino Yun would solve these problems as well, but it has no support for UDP yet. I’m sure it’s just a matter of time before better libraries start coming out.