Joshk

I was successfully using this code in the 4.2 framework to get the MAC address.  

    Private Function getMacAddress(ByVal seperator As String) As String
        Dim netIF As NetworkInterface() = NetworkInterface.GetAllNetworkInterfaces()
        Dim macAddress As String = ""
        ' Create a character array for hexidecimal conversion.'
        Const hexChars As String = "0123456789ABCDEF"
        ' Loop through the bytes.'
        For b As Integer = 0 To 5
            ' Grab the top 4 bits and append the hex equivalent to the return string.'
            macAddress += hexChars(netIF(0).PhysicalAddress(b) >> 4)
            ' Mask off the upper 4 bits to get the rest of it.'
            macAddress += hexChars(netIF(0).PhysicalAddress(b) And &HF)
            ' Add the dash only if the MAC address is not finished.'
            If b < 5 Then macAddress += seperator
        Next
        Return macAddress
    End Function

But after having to upgrade to 4.3 when I setup my new computer, the code-check underlines the code

netIF(0).PhysicalAddress(b) >> 4

and gives this error if I try to deploy:

Please delete this duplicate.

I need to deploy a program I have deployed dozens of times on 4.2 framework...  

I have a new computer now so I was forced to 4.3 because I couldn't find all the 4.2 drivers and downloads for my new computer.

So when I try to deploy I get this error:

Public Class globalConfig
    Public Property version As Integer = 3
End Class

But it deploys if I write it like this:

Public Class globalConfig
    Public Property version As Integer
        Get
            Return _version
        End Get
        Set(value As Integer)
            _version = value
        End Set
    End Property
    Private _version As Integer = 3
End Class

This is a big deal because it now takes 9 lines of code to do what I used to use 1 for.  So my 50 lines of code will go to 450!  I don't know if the project will still fit on a Netduino Plus2 after all that work.

This appears to be a large bug in 4.3...  Am I missing something?

I have been away from the Netduinos a while, now I need to get a new computer setup.  The Netduino.com download for VS2013 takes me to VS2015.  That installs fine, but ".NET MF plug-in for VS2013" will not install.  I am unable to even open my project as things stand.

Please install in the following order:

  1 Microsoft Visual Studio Express 2013

  2 .NET Micro Framework SDK v4.3

  3 .NET MF plug-in for VS2013

  4 Netduino SDK v4.3.2.1

Your diagram is correct, and your resistor seems sized just fine.  This is what worries me:

 

 

and nobody pushed the button outside.

If you are connecting the same doorbell switch to the Netduino and an actual doorbell chime then you have circuits crossing between the two systems.  You need them separate, either with a fancy switch called a DPDT (double pole, double throw), or by some fancy relay wiring.

You need a pull-up or pull-down resistor to avoid this floating state that is delicate.  Assuming your button sends power to the digital pin to say it is pressed, that means you need a resistor pulling the digital pin to ground at all times.  The button will overpower the resistor anyway when it is pressed, but when it is not pressed this setup will prevent false readings.

Hello, it's been a while but I have found this community very educated and helpful so I am looking forward to these replies.

I am thinking the sensor and board are not sharing a common 3.3 top voltage, so regulation imperfections work against each other.  

Both my board and sensor are powered by a stable 5 volt source.  For the board it goes into the 5v pin.  To scale the signal from the 5v sensor I am using a voltage divider (51K-->100K) into the analog pins of the NP2.  The sensor is very high quality and my oscilloscope agrees it puts out an amazingly stable signal, however the Netduino debug readings are a bit wild.  Obviously the Ground is common between the two, so no issue there.

If only I had an Aref pin to feed with a voltage divider off of the 5v source they would have a common high end, instead of a relative one. (As I understand, my ioRef pin is an output.)

Shouldn't NP2 have a 3.29~3.31 volt Aref pins so sensors can share a common top end??