Hi Bradygaster,

I had a similar type of issue (non responsive board) with a Netduino Plus 2. I used the latest application for updating the Netduino firmware (NetduinoUpdate.exe) to wipe my problematic application from the board.

Thanks,

Jason.

Hi,

I've noticed an interesting issue with the latest version of the firmware. I upgraded my Netduino Plus 2 to run 4.3.2.2 and the following fails on this version of the firmware.

public DateTime GetNetworkTime(string hostName = "time-a.nist.gov")

{

            var hostEntry = Dns.GetHostEntry(hostName);

.....

}

Rolling back to 4.3.2.1 of the firmware and the same code executes fine with no changes.

I'm pretty sure there is a firmware issue as I received my Netduino 3 (Ethernet) board today and deployed my application to the new board (it is running 4.3.2.2 out of the box). It fails on the same line of code.

An unhandled exception of type 'System.Exception' occurred in Netduino.IP.LinkLayers.AX88796C

Any suggestions?

Thanks.

Hi, 

I've also decided that I'm not going to continue with the Netduino platform primarily because of 2 factors: 

1) The inability of the Netduino team to deliver basic working infrastructure code on time (to their delivery schedule).

2) with the open sourcing of .NET (and specifically WCF) I see no need to constrain myself to the ancient Micro .NET platform and it's restrictions.

I've 25 years of commercial software engineering experience, most of it on server side and in multi-threaded development, and I find the basic networking issues on the platform inexcusable in this day and age.

I'm moving off the Netduino platform to more open and capable hardware that can accommodate the demands of the 21st century. I'm also removing myself from being dependent on the Netduino team, who seem unable to project manage themselves to deliver on time.

It might seem a little harsh but there is no excuse for the manner in which the community here have been treated by the Netduino team over this new build. I can't justify relying on a supplier who doesn't communicate what they are doing and also doesn't honour their communicated goals. 

I will be shortly releasing my Micro.NET libraries for general use on GitHub (under an open licence) as I move my focus back to the Core .NET framework for embedded development.

Regards,

Jason.

HI Chris,

Thanks for the update.

Based on your comment "the new feature requires some significant revisions to the stack structure" implies the core framework is what you've been working on for the last 12 weeks. Does this mean the original feature set hasn't yet been started and is therefore 12 weeks behind the planned scheduled delivery date?

Regards

Jason.

Can someone give a revised (and up-to-date) release schedule for the new IP stack? i.e. What feature set is being released and when? It seems as if the wheels have fallen of this project in terms of the communicated delivery schedule and what is actually being delivered. Its been nearly 3 months since the initial announcement and the communicated expectation was that in 3 months the entire stack would have been re-written and released (at least in a beta state).

Hi Chris,

Are you open to code reviews from the community? Or alternatively do you have a set of coding standards and principles that guides the actual development?

Thanks,

Jason.

Hi Chris,

My apologies for the lack of clarification -it is multicast that seems to be the problem. The nature of your reply seems to confirm that UDP multicast is not currently supported with the existing IP stack. Is that correct?

I'd like to help with testing on the new IP stack; however the existing issue does pose a challenge. If I read your new IP rollout correctly, 12 weeks from now we should have a new stack, feeding into a beta programme. I can't really afford to wait 12 weeks to resolve this existing issue, blocking development in the process. I've already lost a week trying to resolve issues around the existing IP stack (which thankfully your 4.3.1 firmware partially resolved).

I'm also concerned about the lack of clarity on what features in the MF are not supported by the firmware (or have issues). Do you have a defect list, by firmware version, that identifies issues, severity, status and timeframes to resolve?

I'm hoping to soon be in a state to release the framework I've built out for MF, which may be of use to others. Nothing fancy: multi-threaded services (not web services), logging support for AMQP and MQTT providers, basic assertions, and a standardised set of error classifications. The aim is to support integrating with a server side framework I've built up around WCF. 

Finally, thanks for the welcome!

Regards,

Jason.

Hi,

Has anyone had any luck with UDP on a Netduino Plus 2 with MF 4.3.1? I seem to get errors when using the SetSocketOption call. The exception returns an internal error id of 10042 (Bad protocol option).

I'm starting to wonder whether using the Netduino boards are worth it (given this sort of issue and other bugs - like the network stack not detecting ethernet plug disconnects). I've noticed that someone has tried this on another MF board and it worked fine. Any suggestions?

I'm trying to capture UDP messages broadcast by another device on the local network.

        /// <summary>

        /// Starts the client connection.

        /// </summary>

        public void Open()

        {

            m_IsOpen = false;

            lock (m_SyncLock)

            {

                var ipAddress = IPAddress.Parse("224.192.32.19");

                var ipBytes = ipAddress.GetAddressBytes();

                m_Client.SetSocketOption(SocketOptionLevel.IP, SocketOptionName.MulticastInterface, ipBytes);

                m_Client.Bind(m_Endpoint);

                m_IsOpen = true;

            }

        }