Blinking an LED based on UDP packet

Hi guys,

I'm very new here and to electronics in general. I was able to upload the UDPSendReceiveString sketch to my arduino. I then used netcat to send some text udp packets to it, and to my delight it works!

I put an if statement in the code to check if the first character of the packet is C. If so, I print a message to the serial console. That works fine and dandy. However, in the same if statement, I'm trying to just turn off the LED that I have plugged into pin 12 (I've also tried pin 13). It seems to simply ignore my request.

Here is my modified code...

#include <SPI.h>         // needed for Arduino versions later than 0018
#include <Ethernet.h>
#include <Udp.h>         // UDP library from: bjoern@cs.stanford.edu 12/30/2008


// Enter a MAC address and IP address for your controller below.
// The IP address will be dependent on your local network:
byte mac[] = { 0x90, 0xa2, 0xda, 0x00, 0x7f, 0xc5 };
byte ip[] = { 192,168,2,19 };

unsigned int localPort = 8888;      // local port to listen on

// the next two variables are set when a packet is received
byte remoteIp[4];        // holds received packet's originating IP
unsigned int remotePort; // holds received packet's originating port

// buffers for receiving and sending data
char packetBuffer[UDP_TX_PACKET_MAX_SIZE]; //buffer to hold incoming packet,
char  ReplyBuffer[] = "acknowledged\n";       // a string to send back

int LED = 12;

void setup() {
  // start the Ethernet and UDP:
  Ethernet.begin(mac,ip);
  Udp.begin(localPort);
  pinMode(LED, OUTPUT);
  Serial.begin(9600);
}

void loop() {
  // if there's data available, read a packet
  int packetSize = Udp.available(); // note that this includes the UDP header
  if(packetSize)
  {
    packetSize = packetSize - 8;      // subtract the 8 byte header
    Serial.print("Received packet of size ");
    Serial.println(packetSize);

    // read the packet into packetBufffer and get the senders IP addr and port number
    Udp.readPacket(packetBuffer,UDP_TX_PACKET_MAX_SIZE, remoteIp, remotePort);
    Serial.println("Contents:");
    Serial.println(packetBuffer);
    if(packetBuffer[0]=='C'){
      Serial.println("works!");
      digitalWrite(LED, LOW);
    }
    int y = atoi(packetBuffer);
    
    for(int ctr=0; ctr < y; ++ctr)
      Serial.println(ctr);

    Udp.sendPacket( ReplyBuffer, remoteIp, remotePort);
    
    // clear the buffer
    for(int x=0; x<UDP_TX_PACKET_MAX_SIZE;x++){
     packetBuffer[x]='\0'; 
    }
  }
  delay(10);
}

Any insight would be greatly appreciated!

Where do you ever turn the LED on?

And I trust you are using a resistor in series with the LED, eg. 220 ohm or so.

Thanks for the reply. The board automatically seems to turn the LED on. I had a slightly different version of the code that actually turned it on, then had a one second delay, then turned it off again - but that, too, did not work.

I'm not currently using a resistor as I haven't been leaving the LED plugged in for more than a couple seconds, but I suppose that is dumb on my part.

What board? What LED? I don't know of any board that has an LED on pin 12.

Also the reset behaviour turns all pins into inputs. I would be very surprised if you have some sort of default "turn pin 12 on" behaviour.

I would put the resistor in right now, if you don't want to risk burning out the output transistor on your processor for that pin. It is only designed to source 40 mA absolute maximum, and preferably 20 mA. The resistor I quoted would limit current to a more reasonable 15 mA.

It seems to simply ignore my request.

Do you mean the LED comes on, but never goes off?

Hmm, wait a moment. You are using the Ethernet shield, and that communicates via SPI, right?

Then pin 12 is the MISO line, and pin 13 is the SCK line. They are overridden by the SPI processing. And they are quite likely to be on a lot of the time. Choose another lower pin (lower than 10), like pin 3.

Sorry for the lack of detail. I'm just using a 2pin LED. And you are correct, I'm using the Ethernet shield and the SPI header. I just switched down to a lower pin like you suggested, and it's working beautifully!

Thanks much for your help! I'll have to read more on the headers that I'm using to make sure that I don't run into something like this again