Well, in both cases you want to keep the PWM wires / traces away from the other wires / traces.  In a fancy multi-layer PCB you would put those signals on a separate plane and put a ground or DC power plane on each side.  In the proto case just use wires that are long enough to keep them away from everything else.  When you do a PCB you could try to put the PWM traces on the back side of the board and keep most of the rest on the top side of the board (or the other way around).

Good luck.  Sounds like a fun project.

Gismo,

We have this sort of problem all the time at work, but we work at much higher speeds.

I don't think that I've ever read about this on a Netduino.  Sounds like you're just going

to need to isolate those two circuits .  Great work tracking that down.

XML is easy to generate ... I'd probably just create the XML string in the same way I

would generate an output string.  You could create a method for each XML tag to clean

it up a bit.  Of course, XML is so verbose it will reduce your performance quite a bit.

Are you sure you don't want to use JSON?   I don't know of any libraries to do that

either.

Note that if you try to connect to the server and it doesn't respond, your thread will hang,

and if its the main thread, you're done ...

If you look at the spec sheet http://www.netduino....plus2/specs.htm you'll see

that there are 4 serial ports.  "COM1" ... "COM4".  Since each pin has multiple functions but

can only do one at a time, it all depends on what functions you're using.  I suggest you start

with "COM1" and hook:

    NP2 Pin D0 (RX)  --->  RFID  J2  Pin3 (TX)

    NP2 Pin D1 (TX)  --->  RFID  J2  Pin2 (RX)

    Hook up Gnd and +5 on J1

And you should be ready to go.  You will have to translate the Arduino example to C#.  Here

are couple hints, more information is at http://arduino.cc/en...erence/HomePage :

     Arduino uses the Serial object to talk to the host computer.  Since they only have a single

     serial port (in hardware) they use the SoftwareSerial  class (mySerial) to talk to the device.

     So convert:

         Serial.println  --> Debug.Print

         mySerial.print  -->  m_SerialPort.Write

Of, course they're not one-for-one but we have to leave a little fun for you  .

Enjoy,

-- John

I'm working on a similar issue right now.  If you're using Socket.Connect and the host does not respond that can also hang up the Netduino.  Check out http://forums.netdui...socket-connect/ if that sounds like a possibility in your situation.  The Netduino should not hang  .

--John

The link you supplied doesn't seem to work.  If your device is: http://www.seeedstud...KHz_RFID_Reader then it looks pretty simple, ground, +5, transmit, and receive.  You would use some code like:

       using System.IO.Ports;

    m_SerialPort = new SerialPort(port, 9600, Parity.None, 8, StopBits.One);

You can find information on SerialPort here: http://netmf.codeplex.com/ or just search on the web.

Have fun.

--John

If you are going to talk to the web, it seems like a WiFi card would make more sense than a XBee card.  I'd start with wired Ethernet and once that was working I'd work on the WiFi.  Sounds like a cool application, keep us posted.

-- John

I've seen this before (just this morning in fact) and I usually just pull down the build menu and stop the "build", unplug the USB cable, plug it back in, and try again.  If that doesn't work then I bring up the project properties and reset the .NET Micro Framework Device, that usually solves the problem.

This turns out to be harder than I expected, due to the fact that the .Net Micro Framework does not include everything from the full framework.

If you try to connect to a host on the network that doesn't exist, or just isn't responding, your thread will lock up until the host responses (which may be never).  Although the .Net Framework theoretically handles all of this with no problem, the 4.2 version of the .Net Micro Framework is missing a number of important properties and methods.

According to the documentation the normal way to handle this situation is to set the Blocking socket option to false, then the Connect() method will throw an exception because it can't connect immediately (the TCP connect protocol takes some time). You catch the expection and wait for the connection to be be completed, and if it doesn't complete quick enough then you return an error. No hang.

Unfortunately, the 4.2 .Net Micro Framework is missing the Blocking and Connected properties, and the Send() method does not work as documented. The following code shows how to get around this ... but it's a kludge. 

using System.Net.Sockets;
using System.Reflection;

int TIME_PORT = 37;
IPEndPoint iep = new IPEndPoint(
    IPAddress.Parse("192.168.3.3"), TIME_PORT);
Socket socket = new Socket(AddressFamily.InterNetwork,
    SocketType.Stream, ProtocolType.Tcp);

Type sType = Type.GetType("System.Net.Sockets.Socket");
FieldInfo blockingInfo = sType.GetField("m_fBlocking",
    BindingFlags.NonPublic | BindingFlags.Instance);
blockingInfo.SetValue(socket, false);

try {
    socket.Connect(iep);
} catch (SocketException se) {
    // Ignore this exception, it takes time to complete the connection.
}

This code uses reflection to access the blocking property which is not publicly available to us.  It catches the exception during Connect() and ignores it.

The problem is how to we know if the connect completes.?The documentation says that you should get an exception if  you call Send() with a zero length and  the socket hasn't finished connecting, but it doesn't.  If you call Send() with a non-zero length then it hangs whether blocking is true or false.  And if you call Receive() it just returns 0 bytes.

The good news is that the SendTimeout property does work.  If you set it to 300 the send will wait for 300 milliseconds and then throw an exception (might as well set the ReceiveTimeout value to 300 too).

So add the following code and you should be good to go.  There is a slight chance that you'll need to wait a little bit for the connection to complete, or maybe retry the first send a few times before giving up.

socket.SendTimeout = 300;
socket.ReceiveTimeout = 300;

byte[] cmd = new byte[1];
try {
    int xx = socket.Send(cmd, 1, SocketFlags.None);
} catch (SocketException se) {
    // Unable to send data - probably no connection.
}

I'm guessing that your NP2 server code is closing the socket after it sends the HTTP reponse.

And if you did have Netduino Plus 1/2 ... the MAC address is printed on a label stuck to the back of the board.

After you create the socket you need to set the Blocking property to false.  Now when you connect you get an exception (you'll need to put it into a try/catch block) which just says the connection couldn't be completed immediately.  You can then call Socket.Poll to wait for the connect to finish, and then check if the socket is connected.  I know this is probably not enough, I haven't found a good example, I'll try to come up with a simple example ...

OK, so here's the problem.  You load the data into XBuffer, then you store a pointer to that bffer into InBuff, you load the next set of data into XBuffer and store the same pointer into the next element of inBuff, and so on.  One way to fix it would be to move the new of XBuffer into the loop.  As in:

    for (Y = 0; Y < Ymax; Y++)
    {
        Xbuffer = new byte[Xmax];  
        for (X = 0; X < Xmax; X++)
        {
          XBuffer[X] = buffer[X + Y * 4];
        }
        InBuff[Y] = XBuffer;
    }

The down side of this is that this will use up twice the amount of memory.  If you use the data from the initial buffer it would save the memory.

I copied the example code and ran it (you obviously didn't since it has compile errors  ) and it works fine.  I ran it both on the PC and the Netduino.  Here's the code I ran ... you must be doing something else.  Note that if you reuse the numbers1..3 arrays that will also change the values in the numbersArr.

        int[] numbers1 = { 101, 102, 103, 104, 105 };
        int[] numbers2 = { 201, 202, 203, 204, 205 };
        int[] numbers3 = { 301, 302, 303, 304, 305 };
        int[] temporary = { 401, 402, 403, 404, 405 };
        int [][] numbersArr = new int[3][];

        temporary = numbers1;
        numbersArr[0] = temporary;
        temporary = numbers2;
        numbersArr[1] = temporary;
        temporary = numbers3;
        numbersArr[2] = temporary;

        for (int i=0; i < 3; i++) {
            for (int j=0; j < 5; j++) {
                Debug.Print(numbersArr[i][j] + " ");
            }
            Debug.Print("\n");
        }

Bernie,

The Netduino is not really fast enough to do this sort of thing in managed (C#) code.  And it's difficult to add unmanaged libraries and solve the problem that way.  In my opinion you have two choices:

1. The following fourm talks about a library for interfacing to the DHT-11 device which uses pulse width encoding of its digital data.  http://forums.netdui...managed-driver/ it uses interrupts to detect the edge of each pulse and compute the pulse width from the timestamp that comes with each interrupt.
2. Use an Arduino (there is probably code already out there) and interface it to the Netduino with rs-232, I2C, or SPI.

I'm working on the Arduino solution for interfacing some hardware to the Netduino right now.

John

I've got the EMIC2 (http://www.hobbytron...-text-to-speech) on my list, but I haven't got to it yet.  They have some amazing demo wave files.  And there is an Arduino demo program.  Let us know how it goes.

Hard to say without a logic analyzer ... but, it sounds like the I2C lines are in a bad state when the board initializes and after the first operation the I2C lines are left in the correct state so that the subsequent operations all work.  It seems to me there is another topic where this is discussed, I think that they set the pins to "1" before using them as I2C ...

Glad that that you found a work around.

I thought that the address was printed on the device, but I looked at a DS1820 and the numbers on the device do not have any correlation with the address (so I guess not).  The way I got the address was to add the new device to the 1-wire network and use the FindAllDevices() function to get all the addresses.  The one I didn't know is the new device's address.  You could also choose to make it the only device on the net.

I'm curious to see how you did that ... I'm always looking for a better way to do things ... could you post the code?

There are a number of useful string functions that are missing ... not to mention the StringBuilder class ... I would use some code like:

        String smsData = "31584C1E8bC160";
        String data = "";
        int bytePos;
        int charPos;
        int nibble0, nibble1, byteVal;
        int carryBits = 0;

        smsData = smsData.ToUpper();   // Not needed if digits will always be uppercase.

        for (bytePos = 0; bytePos < 7; bytePos++) {
            charPos = bytePos * 2;
            nibble0 = smsData[charPos] - '0' - ((smsData[charPos] >> 6) * 7);
            nibble1 = smsData[charPos + 1] - '0' - ((smsData[charPos + 1] >> 6) * 7);
            byteVal = (((nibble0 << 4) + nibble1) << bytePos) | carryBits;
            carryBits = (byteVal & 0x7F80) >> 7;
            data += ((char)(byteVal & 0x7F));
        }
        data += ((char)carryBits);
        Debug.Print("SMS Data = " + data + "\n");

--John

Wow, this does look pretty cool.  I'm a lot like you and I'm tempted to drop what I'm doing and get one of these eval kits ... but I'm trying really hard not to start any more projects until I get some finished and written up ... I guess I'll just save this link and hope to have time later this year  .

Kenny,

You should consider upgrading to the 4.2 (or 4.3) framework on your Netduino. It will be harder to upgrade later as they seem to like changing stuff in the interfaces.  Like for example in 4.1 analog ports return an integer with a range that you specify, in 4.2 you get a float between 0.0 and 1.0 which indicates the percentage of the reference voltage ... I like 4.2 but I should upgrade to 4.3.

BTW, be careful about the versions in use when you read posts in the forum .

John

Yes, TCP sockets are different, they work the way we would expect.

Except that I've found that they don't always return the number of bytes that I request ... even if I sent more than that.  I always do the reads in a loop to verify that I get all of the data I need for each read ...

That's what makes programming fun (and frustrating) - John

It seems like this should be easier ...

In C# I would set Socket.Blocking = false (which causes the Connect to throw an exception that I ignore), then call Socket.Poll to wait for the connect to finish, and then check if the socket is connected.

The following link shows a VB example that's not quite what you're looking for, but might get you headed in the right direction .

  http://msdn.microsof...#code-snippet-2

Hope that this helps - John

Hey, Paul,

Thanks for taking the time to report this.  I would have expected the second read to get the remaining 3 bytes of the first packet.

It's nice to learn something the easy way for a change .