Hi Nobby,


There appears to be a bugfix in lwIP to correct this type of issue. .NET MF 4.3 is getting an lwIP upgrade, so we're hoping to have a fix for this soon. [lwIP is a big complicated project and 10,000s of boards rely on it working properly...so introducing the update in beta firmware should help it get some good in-field testing.]

Chris

Thanks for the information Chris

I'm also having ethernet issues with the latest firmware. Although, I can't confirm if the issue exists with older versions. I discovered that the ethernet interface never works at all if a network connection doesn't exist on boot. I made a thread here: http://forums.netdui...h__1#entry32165 Nobody has shared any discussion on the matter. I'm using static IP in this case and absense of network connectivity is fine as long as it occurs after boot/powerup.

Well, I understand the concept and I dont have a problem writing the code for say a 2.4GHz processor x86 with a 4 GBs of ram sampling time of around 1e-6 second easily, the problem I had over here was using this high resolution encoder with a netduino thats all. Just to put things in perspective, if the shaft is rotating at 3 revs/second (180 rpm which is not much )thats 1200*3 = 3600 interrupts/second. I just need help on generating an efficient enough code for the netduino to be able to handle all that along side of some computation thats all. Like I said I am just not used to micro-framework.

There's a couple of ways you can deal with your scenario. If your PID controller is for speed only then the only problem you'll face is convergence speed and possible overshoot depending on your performance specification. Even if the interrupt frequency basically matches the transport delay of the netduino hardware/framework, you just design your PID outer control loop as fast as the device can.

Position control for 3600 interrupts/sec is going to be hard. Depending on how smooth the control needs to be, you would probably have to slow the motor down. If you have to maintain a particular speed range then you'll most likely have jerky position control from lack of controller bandwidth and transport delay.

Although the netduino is capable of 100ns precision timing, most timing functions have 1ms precision. Do you have an option of a lower resolution encoder or do you need to have ridiculously fine position control?

Just noticed that the Netduino Plus forum got renamed so I'm putting my money on a second generation Netduino Plus

TCP sockets consist of remote and local endpoints by design so naturally you'd assume the state of the connection is managed by TCP but it isn't. The only way to determine the current state of the socket is: -Enforce an activity timeout -Attempt to read from the socket -Attempt to write to the socket In the first case, simply enforce a timeout of a desired interval. If no communications occur within a certain time-frame, forcefully terminate the socket. In the second case, the operation will block indefinitely if no deterministic data stream exists(i.e. client isn't required to send data regularly). If you set a read timeout on the socket, it will throw an exception but this is a false-positive in terms of detecting a client disconnecting. The best method is to write to the socket. This is commonly refered to as Keep-Alive. If the client has closed their socket at the remote endpoint, a socket exception will be thrown at the local endpoint and you can remove the client. Send a single byte or an appropriate byte pattern to the client. They can either absorb the data or make an appropriate response if required. The problem with this approach is that the client is required at at least monitor for this incoming Keep-Alive data. End-to-End data transfer with TCP is fully-interlocked. Even if you perform a write operation on a socket asynchronously, the data backs up in the server's memory(in the netduino RAM in this case) until the client reads all pending data. This is dangerous to server stability. If you are creating an HTTP server, the HTTP specification covers the aspect of Keep-Alive and the client notifies the server through GET/POST methods whether or not they would like the connection to remain open. Even then, this is usually in the order of minutes. HTTP is typically not used for persistent connections though except in the case of data streaming. Good luck

Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks has 100ns precision(0.1us) but the accuracy is skewed by +- a few hundred microseconds due to the runtime overhead. If you need to measure an interval less than one millisecond, you end up with an error of about 20% but this error is negligable for slightly larger intervals. The 100ns precision is definitely usefull for cumulative timing functionality. Are you using the timer as a measurement interrupt?

Hello Alex,

Sound a typical field instrumentation problem.

Use a 250ohms in parallel to 4-20mA signal. Remember V=IR .... V=(4/1000)(250) = 1V...do similar
operation for 20mA and you get 5VDC...right in the acceptable voltage range of the Analog inputs...

Hope helps.

You can't measure the current of a circuit using a parallel impedence, that's only appropriate for voltage measurements(scale conversion). Parallel impedence splits the current through branched paths and it also alters the characteristics of the circuit in a large way(unless the impedence is essentially infinite, 250ohms is very low).

The current transducer circuit has to run in series and have a negligable impedence.

Hi Guys,

Separately, do you have any sample circuit to connect to N+ for measuring 4-20mA Analog input?
Together with sample code will be great. Currently I am using VB.net to handle the 12V pulse input through opto-coupler circuit.

Thanks in advance.

I don't think you can measure current with a microcontroller. You need to transduce the current to a voltage.

The most accurate method is getting a transducer which uses electromagnetic coupling. It's also the most expensive method.

The easiest method is to use a really small series resistance (1-5 ohms, whatever you can get your hands on) with the circuit you are measuring current. Measure the voltage across the resistance and divide that by the series resistance in your netduino code. The result has errors obviously. Adding resistance to the circuit changes the current. You might also get non-negligable current flow into the analog pin even if it has a high impedence characteristic during analog sampling.

The other consideration you need to be aware of is that 4-20mA is a rather small current to transduce. Mostly because ADC(Analog to Digital Conversion) usually has a precision relative to the operating voltage of the microcontroller(AVR/Netduino) and the value of AREF(usually set to zero volts or Vcc/2). A current that small will produce a voltage so small it will appear as zero after ADC. You'll need to amplify the transduced current signal significantly, especially if you are working in a narrow measurement range (4-20mA).

You can make a simple voltage amplifier with two resistors and an op-amp package.

I have version 4.1 since this is what is recommended in the Download section of this site.



I tried all your suggestions and my browser still doesn't want to connect to the Netduino. I am running the example code from Chapter 8.



I really appreciate the it! Here is a screenshot of my current network settings in MFDeploy:

I noticed in your MFDeploy screenshot that your default gateway isn't in the same IP pool as the DHCP assigned IP address(192.168.5.XXX vs 192.168.1.XXX). Since you're using 24-bit networking, a lot of things are going to go south here. It also suggests that you might have some sort of configuration issue in the netduino or your router.

--Edit my bad: I saw that was your old static IP address.

Was just about to go to bed and saw this thread. Downloaded the beta framework and installed. Two days ago I downloaded and installed the retail VS2012 Professional. Microframework applications in my solutions now load. I built a 4.2 netduino+ application, deployed and debugged, working fine so far. Will be putting this to a hard test over the next few days and hopefully will be able to do away with 2010.

Hey guys, Is there a method to check runtime memory usage and possibly get the total memory of the device through micro framework? With the regular .Net Framework you have to do it through a process object but this doesn't apply to .Net Microframework. I've had a skim through all the namespaces for 4.2 and can't find anything relevant.

Hi Nobby,

Try:
int freemem = Microsoft.SPOT.Debug.GC(...);

You can optionally pass in true, forcing a garbage collection, giving you the full amount of memory available.

Chris

That worked a treat, thanks Chris )

One method I use is to create a socket which is a listener using IPAddress.Any for the binding. The listener will be created if the network is up or down but you can call Socket.Poll(). It will throw a SocketException if the network is down with an error code 10050. The only time this approach fails is if you power the ND+ up and it initially isn't connected to the switch/router. There's some bug which is apparently being fixed in 4.3 where network connectivity to the ND+ is impossible under this start-up condition but the ND+ internally believes connectivity is fine after you plug the network cable in.

If I'm using a dual coil latching relay with voltage of 3V (with coil resistance 129 ohms), do I need to use the transistor ??

It's a bit touch & go with your situation. When they say 129 ohms, they mean total impedance. Part of it is reactive and the other is purely resistive. 129ohms at 3.3V from the CPU pin will draw up to 23mA which is borderline. If you intend on driving the relay in short bursts then it would possibly be acceptable but otherwise you wouldn't.

Once the transient behaviour dies away from switching the relay on, the effective impedance of the relay will be less and you'll exceed the maximum continuous current draw from the CPU pin and smoke the poor thing.

If it was me, I'd use a transistor.

Hey Patrick, this may or may not be of any use because it depends on the back-end code for sockets. With the regular .Net framework, socket objects can be disposed but underlying socket resources are maintained by the CLR in the event that in a short space of time, you decide to create a new socket to the same remote host on the same port. This is true even if you call dispose and try to trash the socket as hard as you can. When you use the 'using' clause, it just calls Dispose on the IDisposable object. Your network stream will dispose fine but your socket objects might be doing funny things if the implementation of System.Net.Socket is the same under MicroFramework as it is for regular framework. This is the only thing I can think of that hasn't been explored yet.

I recently moved to 4.2 RTM to take advantage of the reduced networking byte-code size which I read about in a forum post on here somewhere. Where does general information about new microframework footprint sizes come from?

Hey crawf, I'm about to head to bed so I'll read this thread tomorrow. Judging by your code, the methodology is fine. I use I2C comms with a GPS unit and i've tried various approaches to see how flexible the API is. The main points you need to know: -When you perform a write operation, .Net will ALWAYS provide the device address in the transaction, you don't have to add this to the byte[](not that you are but just so you know) -When you perform any transaction, if zero actions are returned from Execute(), this means that communication to the device failed completely. This has nothing to do with register addresses -.Net handles all ACK & NACK signalling(comms interlocking). The number of ACKS & NACKS returned by the slave device determines the return value of Execute(). -You can't simply read a single byte in a transaction. The data you read from a target register needs a destination array large enough to fit it. If you don't know the size required, give one sufficiently large enough. The remaining bytes in the array are set to zero(or a value defined in the device documentation).

Thank you Mario for your response.

I know that the framework slows things down..But most of teh time the developper is the problem!

But I know that on a PC, the differences is sometimes hard to see..
The conversion time of an ADC can be less than 5 Microseconds..
A simple loop with simple calculation run very fast.
It is the call to the ADC which goes wrong.
Usually, it is possible to start conversion, than to read the result later.
With NetDuino, it seems that we have to start and wait conversion..
Even though, response time is very long...

What I want to to is to store data from 1khz ->10khz signal into memory, and dump it from a PC.
It works fine for 100hz signal..


I will work on it...

If you configure the ADC to operate in free-running mode, the contents of the ADC register is constantly changing for you at the maximum rate the ADC will operate at. This kinda eliminates conversion times from a hardware interrupt. There are two probelms with a free-running ADC.

If you strobe multiple pins you run into parallel operation errors. I haven't checked the SAM7 architecture but most AVRs only have 1 ADC but have 5+ pins you can strobe off. When you change the ADC strobing register to select another pin, it might be impossible to determine which pin the ADC data register contents belongs to if you read it immediately or shortly after. Some AVRs don't allow free-running with strobing.

The other issue you have is when you read a sample from the ADC register in free-running mode, you don't know how "old" the data is. When you take two readings, there will always be a degree of skew in your measurement windows which increases with a slower ADC sampling rate.

Those two issues aside, it's also a tall-order to measure a time interval less than 1ms accurately.

You've got two goals to achieve here. Your circuit build/hook-up and software to control the H-Bridge. The good news is that regardless of how you end up controlling the H-Bridge, the connections are the same.


You haven't specified what your H-Bridge is and how it's been put together etc. They're simple systems to understand. You need to connect at least three different kinds of connections:

• DC Bus link voltage. This is the power supply you provide the H-Bridge. It can be bi-polar or uni-polar but it depends on if your H-bridge will allow you to connect a 'center-tap' for setting the ground as a mid-point.
• CMOS/IGBT gate inputs. You connect your PWM outputs to these. There are four of them but they are in pairs so you only need two PWMs to drive it. One switch is always off when the other is on for each pair(side note on this)
• H-Bridge output goes to the motor. You will be able to drive a DC or an AC motor with an H-bridge.

There may be some other component considerations depending on the gear you've bought.

Controlling the motor can be as easy or difficult as you want and it's a massive field for you to explore. To start with, you will most likely be able to get a library or use .Net classes which will operate the PWMs for you. Because you have an H-Bridge you have two options:

• Use one PWM on half of the H-Bridge as a starting point. It turns your H-Bridge into a single phase-leg modulator which means you can't drive an AC motor
• Use two PWMs on the full H-bridge which will allow you to drive an AC motor as well as DC

Above is your starting point but it has no feedback control loop. Without feedback from the motor, you won't be able to know how fast it is actually spinning for a given input signal. If it's important for you to have precise control of the motor speed, you need software in your project which will measure the motor speed and figure out the difference in desired speed and actual speed the adjust your modulation depth to drive the H-bridge harder or less. Some motors can tell you their position as well so you can precisely control the position of the motor as well as speed.

Having said all this, if you're just a hobbyist and want to see the motor spin, you don't need a feedback control system or understand much about modulation theory. If you told us more about your goals then we can be very specific about helping you to setup the right system.



--edit: oops forgot the side note. Depending on how your H-bridge has been designed, you have to build a "dead-zone" into the PWM signal. If there's free-wheeling diodes and/or your H-bridge uses IGBTs, there's a discharge transient when the device attempts to switch off. If you toggle the other switch on before its complimentry switch has fully turned off, you create a short on your power supply every time the PWM switches on/off. It will damage your supply and possibly much more.

Not sure if this is an issue or not but I'm looking at trying to get around a certain type of behaviour with the NIC. -If I boot/power up the device with the netduino connected to a switch/router everything is fine -If I boot/power up the device with the netduino initially unplugged, I run into issues. -Currently using static IP Plugging the device into a network after startup negotiates fine with the hardware. I cannot ping the netduino at its IP address though. I can ping it if I hit the reset button or re-power the netduino My software binds a listener which constantly throws socket exceptions when calling Socket.Accept() while it is disconnected(as expected). When the exception occurs, I close the listener, rebind the socket(using IPAddress.Any) and retry to called Socket.Accept(). When I plug the netdunio into a switch, the socket rebinds and stops throwing socket exceptions from calls to Accept(). I still can't ping the Netduino or make a TCP connection to the device unless I reboot/re-power the netduino with the network cable plugged into a switch. I've tried various things such as reseting the static IP settings once the netduino is plugged into a switch, before and after binding the listener to 0.0.0.0:portNum. Anyone else had similar behaviour?

I finally found some time to create analysis tools to investigate NIC behaviour. The initial results were fairly conclusive.

---Netduino Software---

A threaded socket listener accepting TCP connection requests. It's a non-blocking approach utilising Socket.Poll to check for pending connection requests before calling Socket.Accept. Detection of NIC being up or down is monitored using the WinSock socket exception code 10050. Once the network status is up, I tried two methods that involve either retaining the existing listening socket object or recreating the listening socket.

• Netduino is using static IP and gateway (192.168.1.95, 255.255.255.0, 192.168.1.1)
• Experiment involved starting a debugger on the netduino with the network cable plugged in or unplugged
• A separate thread does a Debug.Print of the current IP address and default gateway of the Netduino every three seconds

---PC Software---

A simple app which allows you to enter an ip address and port number. A "Connect" button which attempts to create a TCP connection to the remote host at the defined address and port. A "Ping" button which broadcasts an IMCP echo request to the defined address. All connection and ping results displayed in a listBox.

---Results---

Starting the debugger with the network cable initially plugged in produces positive results. The device is pingable and TCP connections can be made. Unplugging the device from the network results in WinSock 10050 exceptions on Socket.Poll as expected. Plugging the Netduino back into the network and recreating the listener socket resumes desirable behaviour. The device is pingable and TCP connections can be made.

Starting the debugger with the network cable initially unplugged is where it all goes wrong. The frequently displayed IP address of the Netduino is correct. After any length of time, the netduino is plugged in, all related link/activity etc lights come on. WinSock 10050 errors cease to occur when calling Socket.Poll as expected. However, the device is unpingable and TCP connections cannot be made to 192.168.1.95. No amount of time changes the conditions of connectivity without restarting the device.

Is anybody familiar with the inner workings of the .Net Microframework runtime startup in the Netduino and how NICs are affected by it? Fortunately, the only vulnerability of the product I'm developing is that it must be plugged in and active at both ends of the network cable before the product is powered up. I would like that to not be a requirement.

This thread http://forums.netdui...?showtopic=3420 alerted me that sometimes the Netduino needs to be rebooted. Is there any other functionality that isn't as brutal as a reboot?

I'm now using Socket.Poll to detect the initial NIC connection state and rebooting the device upon the NIC status changing to up, if it was originally down. I can't exactly do this if the product is in the middle of being used.

I saw this issue with an attached debugger in this thread http://forums.netdui...tartup-problem/ .

I've nailed the culprit on this one but no explaination as to the adverse result obtained. Take the code snipet below:

            long startTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks, endTicks=0, delta=0;                        
            int sleepTime = 50, choice=1;
            
            clock.start = startTicks;

            for(;;)
            {
                if (choice == 0)
                {
                    Thread.Sleep(sleepTime); //Sleep to regulate timing intervals. 50ms here.

                    endTicks = Utility.GetMachineTime().Ticks; //Get the current Netduino time
                    delta = endTicks - startTicks; //Calculate the time difference
                    startTicks = endTicks; //Assume significant overhead from the previous line of code

                    clock.time += delta; //Increment instance member time value
                }
                else if (choice == 1)
                {
                    Thread.Sleep(sleepTime);

                    endTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;
                    delta = endTicks - startTicks;
                    startTicks = Utility.GetMachineTime().Ticks; //Assume no overhead from the previous line of code and this line as well

                    clock.time += delta;
                }
                else if (choice == 2)
                {
                    //Choices 2 & 3 just involve a different order of operations but have the same logic as 1 & 2
                    endTicks = Utility.GetMachineTime().Ticks;
                    delta = endTicks - startTicks;                    
                    startTicks = endTicks; //Assume overhead from the previous line of code

                    clock.time += delta;

                    Thread.Sleep(sleepTime);
                }
                else if (choice == 3)
                {
                    endTicks = Utility.GetMachineTime().Ticks;
                    delta = endTicks - startTicks;
                    startTicks = Utility.GetMachineTime().Ticks; //Assume no overhead from last and this line of code

                    clock.time += delta;

                    Thread.Sleep(sleepTime);
                }
            }

I performed some optimisations on my original timing code which was not optimised at the time. There was still drift. The results were fairly conclussive though. Choices 0 & 2 provided identical and ideal results. There was no slip between clock.time, the Netduino time and the PC time.

Choices 1 & 3 resulted in the slip of 100ms every 30seconds. The only difference in code was using startTicks = Utility.GetMachineTime().Ticks vs startTicks = endTicks. The previous line of code, delta = endTick - startTicks and the alternative code in choices 1 & 3 were resulting in what appears to be significant overhead. Based on the results and a loop interval of roughly 50ms, it works out to be roughly 166us of slip per itteration.

Not being a huge fanatic of investigating the inner workings of the micro framework, I'm just going to accept that I can't be lazy in design with respect to these things. Failing longer duration tests for choices 0 & 2, There's no evidence of any chronic issue with timing accuracy.

I'm currently looking into factors affecting the accuracy of Netduino timing. Precision isn't a massive factor, tenths of a second is fine. I've tried two approaches for timing -Using a timer interrupt with constant frequency/Thread.Sleep and then making timing variable adjustments -Implementing Chris Walker's System::Diagnostics::StopWatch and using ElapsedMilliseconds The first approach is the easiest but overhead causes loss in accuracy. The second approach would have the higher accuracy but has a dependency on the framework runtime overhead. System::TimeSpan::TicksPerMillisecond is also fixed at 10,000 instead of being device specific. At the moment, I'm curious as to what factors cause the runtime DateTime clock to slip. I have an application with various medium performance threads running, one being a timing thread. Over a space of 15mins, the timer has fallen more than 10 seconds behind my sports watch and a synchronised timer on a PC application I have running. The Netduino is not being debugged, has release build code deployed to the target board and is broadcasting its time through UART to be observed. Considering the crystal freq of the Netduino Plus, I'm unsure as to the massive accuracy/overhead issues with timing here. I'm currently using the 4.2 framework and firmware associated with that framework.

The final observation I made with time slip came down to precision rather than accuracy. Initially my timing precision was in milliseconds. Naturally I elected to just utilise TimeSpan.Ticks/TicksPerMillisecond. The major issue with cumulative timing measurements here is a significant degree of time slip due to rounding-down. The slip increases as the sampling frequency increases. An example of slip due to measurement error was about 100ms every four mins for a interval measurement frequency of 20Hz. I still only require millisecond precision but now use 100 nanosecond precision for higher frequency timing intervals.