UDP problem's with simple program. Router side problem? [SOLVED]

So after I found that TCP was unrelaible I tried to implement UDP into my designs so I could at least get some data sending and recieving over the sparks. Please note that I'm on a unsecure satallite link wifi network (Just don't ask) and I have nothing to do with the system admin side of things. My core's (Uno and Duo) have been assigned two IP's. Here is my test data:

UDP IS WORKING Packet sender on Uno - Receiver on Duo
Added udp.stop(); to stop it breaking after a while of use. Didn’t work Note that I master reset both devices before the working one.
tested with udp.stop() after a master reset Didn’t work
tested after swapping the IP’s as cores Didn’t work
Swapped everything back and took udp.stop() out Didn’t work
Tried a factory reset. Didn’t work
Tried a factory reset with duo on reciever and uno on sender and DEFAULT SETTINGS on putty AND IT WORKED Stops working after a while. 
Test-Trying to add udp.stop again. Didn’t work
Trying back to last working settings Didn’t work
Master reset time Didn’t work

Bare in mind that it took alot of tinkering to get the first one to work. I don't understand why it's working so sporadically occasionally it just seems to work and the rest of the time I get no packets recieved on core UNO. The situation is the same with TCP and I'm beginning to think it's my side rather than the core's side. Has anyone else encountered a similar problem?

The code that's worked 2/6 times:
Reciever:

unsigned int localPort = 5000;

// An UDP instance to let us send and receive packets over UDP
UDP Udp;

void setup() {
    // Initialise UDP
    Udp.begin(5000);
    
    // Print your device IP Address via serial 
    Serial.begin(9600);

}

void loop() {
    // Check if data has been received
    Serial.println("At if loop");
    delay(2000);
    if (Udp.parsePacket() > 0) {
        Serial.println("Packet Recieved");
        delay(2000);
        // Read first char of data received
        char c = Udp.read();
        
        // Ignore other chars
        Udp.flush();
}

Sender:

UDP udp;

byte remoteIP[4] = { 172, 16, 0, 221};
int remotePort = 5000;

unsigned char TxMsg[5] = { 'H', 'E', 'L', 'L', 'O'};

void setup() {
    udp.begin(5000);
    Serial.begin(9600);
}

void loop() {

    Serial.println("Running");
    udp.beginPacket(IPAddress( 172, 16, 0, 221), 5000);
    udp.write(TxMsg, 5);
    udp.endPacket();
    delay(2000);

}

The post about similar problems with TCP:

Please get back to me, been fiddling for 3 days now and I've still got nothing concrete. Thanks.

Hi @OddieCAT

I don’t see anything wrong here–maybe I can try these out tonight but they look very similar to other programs using UDP that I know work.

You say you are on an unsecured WiFi network that is satellite based. That usually means long latency for things like Cloud operations. Can you run Tinker on this network and control your cores with that?

You might be better off with a different system mode like MANUAL or SEMI_AUTOMATIC to bypass the cloud latency if you don’t need it.

Thanks for the response @bko,
I ran the first tutorial on tinker and it worked fine but my phone’s in for maintenance. Could you direct me to some documentation on the different system modes? I’m relatively new to spark and haven’t tried them out yet.
Thanks alot for the help

The doc is here:

http://docs.spark.io/firmware/#advanced-system-modes

1 Like

Tried with both Semi-Auto and Manual but no change. I think I’m going to try them on my home wifi but the project eventually needs to work on the network I’m currently working on. Do you think it’s a network side problem? I think it is because if it was code surely it would either not work or work nto sporadically change between them. There’s always a chance it’s hardware side. I think I’m going to set up a UDP connection on my work PC and see if I can get them connecting to that. thanks for the help so far, any insight would be valueable.

I think trying them at home on a “regular” network will be a good test. I would think they will work fine but we will see.

Using netcat (nc) or tcpdump or wireshark to sniff for the packets from the core is also a great idea.

I hope they work on this network eventually. Was experimenting with low power radio for this project before I found sparks and I don’t want to go back there.

1 Like

@OddieCAT, although you are in the best hands with @bko for the UDP way, I'd like to pick up on your comment above

If you didn't experiance any or almost no problems with Tinker and could limit your messages to 63 bytes per transmission you could try it with Spark.publish() and Spark.subscribe().
This enables Cores to talk to eachother without any need for a phone :wink:

1 Like

Hi @ScruffR, I’m hoping to eventually release this as an open source project in which although it will be highly recommended you do use spark core’s, you don’t have too. That means that I’ll eventually be swapping out all the library code for straight wire and I think if I have UDP or TCP working it will be easier to do so. Also as this system will eventually not just monitor but be able to actively change the temperature my supervisor doesn’t want the sparks to communicate over the cloud, for security reasons.
Thanks alot for your suggestion though.

Right so tested using wireshark (Absolutely great bit of software by the way, very interesting on a guest network) and there’s no packets going out at all. I’m sure the code was properly flashed because the serial connection was printing what it should. Also tested the TCP code I linked above and I still wasn’t getting any packets through.

Hi @OddieCAT

When you say no packets came out, how did you configure wireshark? If you used the normal configuration like a host on the network, then you are only seeing packets from the Access Point (AP) to your host (or broadcast packets retransmitted by the AP).

You can also configure wireshark in monitor mode (MON) where it looks for packets in the air. Normally you have to have the host running wireshark be detached from the network for this to work. Then you might see the packet from the core to AP if the core is sending but the AP is not retransmitting. Worth a shot, just to be sure.

Where you able to test these cores on another network?

Thanks for the quick response again @bko,

I had it in normal configuration, I could try directing the cores to send the packets to my laptops IP, would that work as a test?

When you say detached from the network do you mean on a different network completely or just not directly connected to the cores (because if the later is the case that’s what I’ve done anyway)

I haven’t been able to yet, I’ll hopefully be able to try Saturday as I’m currently using most of my time trying to get the pi to work the server side correctly.

Thanks alot for your continued help.

Hi @OddieCAT

I think directing the packets to your laptops IP is a better test (but only tests the TX side of course). You are seeing “Running” over and over in the serial monitor for the sender, right?

Detached from the network as in your OS does not think you are on a WiFi network at all and wireshark completely takes over the WiFi interface. It can’t always do this, it depends on your WiFi chipset and OS. Windows PCs can be a problem–not sure what you have available.

Check the wireshark page here:

http://wiki.wireshark.org/CaptureSetup/WLAN

Yeah I am seeing running on the serial monitor, I will jump on trying to send the packets to my laptop.

I have a old linux laptop lying around that I could use, I’ll try that out.
Thanks again

1 Like

I modified the code slight and sent in intervals of 2seconds with much success to my laptop.

1 Like

Could you send the changes please? If it doesn’t work this proves it’s my end. and if it does… it’s finally working!

@OddieCAT, one variable i removed is using the core as the Server. I’m testing sending of UDP packets to my Mac and using a software to observe the reliability.

@OddieCAT how did you test the setup? I used my core to listen for UDP packets and sent some using a MAC software. Seems to be working fine as well :wink:

I would love to use one core as UDP server and another as UDP client later to see how it goes! :smiley:

2 Likes

I was orginally testing with one core sending packets and the other recieving and as I mentioned somewhere it did work occasionally with the code I posted but often I’d try again with the same cores etc and it wouldn’t! Very infuriating! Then yesterday I tried using wireshark to recieve the packets I was sending but that didn’t work.

Yeah It’d be great if I could get both TCP and UDP working Core to core!

Hi @OddieCAT

One more interesting thing to try would be to set up two laptops on this network and try to move data between them with UDP or TCP. You can do that with a program called “netcat” or “nc” fairly easily.

If that works, you can figure out what is different about that setup from the core setup.

If that does not work, it might be the easiest thing to debug and get working first.

1 Like

Right, Update.
Tested the cores on my home network (Not the satellite link) and they worked fine. I’m still going to test them another couple of times though because it could have been a lucky try. I’ve now only got access to one laptop at work so I can’t test the Udp via netcat. I’m buying in a new router which I’m going to dedicate to the spark’s to see if that makes a difference but I’m no expert on wireless networks especially not slow ones like I’m dealing with here. Anyone got any ideas to proceed? I can give more information on the project if needed.

2 Likes