This is a similar thread to the one I posted earlier about free memory. This time I'm looking at writing thread-based diagnostics. Due to the Process class not being relevant for .Net MF, is there a way of getting a list or a count of threads that are in any possible state within the application domain or "process"? Secondly, if I have a stray, unreferenced thread floating around, does the GC gobble it up if it's in a non-idle state or when IsAlive is true?

There's no protocols(in the traditional sense) or encryption with devices like this. They're brutally simple. The three key bits of info there are carrier freq, freq tolerance and modulation type. The modulation type is ASK. Ideally you'd use an ASK demodulator with a center frequency of 319.5MHz(the carrier freq) which will give you the analog envelope as an output. You then process the signal here which could be nasty. The device obviously transmits a serial/unqiue ID number but the PDF indicates that you need to hook it up to an ITI security panel(whatever that is). You'd be hard-pressed getting the information to interpret the signals sent by the device but if you've got a good CRO/scope and a lot of time, you could figure it out.... or just find a generic product if they exist.

With the release of the .Net MF 4.3 Beta, we've all had the pleasure of Netduino development under VS2012. Since there isn't a Netduino SDK for 2012 yet, you can't make new Netduino, Netduino+ etc projects under VS2012. Are there registry hacks which are fairly painless to create Netduino project templates for VS2012?

Another observation I have made recently in the Netduino plus was similar to this issue. It was before I had upgraded the firmware so it was still running 2.1.xxxxx and .Net Framework 4.1. I had a TTL VGA board and I was displaying the value of DateTime.Now on a screen directly from the Netduino through COM1. On startup, the Netduino would perform a one-time synchronisation of Date & Time from my PC with the help of an application I had wrote to communicate with the Netduino. It had millisecond percision. After about 5 minutes or so, I noticed that DateTime.Now had lagged behind my PC by a few seconds. After leaving it there idle for nearly a day, it was a long way behind. Initially I beleived the discrepency to be with flucutations of time data when my PC was synchronising with my Domain Controller time server until I disabled time synchronisation on my PC and had the same result as well as using my stopwatch as a reference. I'm about to try this project on a standard Netduino running 2.1.xxxx

Hey Nobby,

Thank you for the additional information. Let's boil it down a bit more, to isolate any potential code or threading issues...

Can you please try creating an app which simply does the following:

• Create and open an instance of the SerialPort class
• In a loop: write the current time to the serial port and then sleep 500ms

And then share that code along with your results? If that basic case is losing 1+ seconds per minute...or if it's not...then we'll have a good basis for diagnostics.

Thank you, Nobby.

Chris

Getting onto that right now.

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 setup and experiment that follows the guidelines you provided. I created a simple PC app to track any time slip over an elapsed time. Each experiment itteration was roughly 4 mins long. Attached are images showing the differences between different timing strategies.

-mainThread.png shows your experiment rules. Over four mins, there is no clock drift between PC and Netduino DateTime.Now

-threadedMachineTime.png shows the same experiment except data transmission is done every 100ms on one thread and the current machine time is stored in clock.time on another thread every 50ms. There is no drift apart from 100ms synchronisation conflicts between threads every now and then which go back to zero anyway.

-stopwatch.png System.Diagnostics.StopWatch approach shows a drift of about 200ms every two minutes. Clock.time is incremented by stop_ticks - start_ticks after a thread.sleep(50). The itterative code is shown below. It should essentially always match the netduino machine time. There is only 1 line of code overhead separating

for(;;)
{                
                endTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;
                delta = endTicks - startTicks;
                startTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;

                clock.time += delta;  
                //clock.time = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks; //this was used in the second experiment
                Thread.Sleep(50);
}   

-internalDrift.png shows how clock.time drifts away from the Netduino system time. The netduino experiment code was modified to only transmit the drift between Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks and clock.time(shown in the Current Column for Netduino). The results show that the Netduino clock doesn't drift compared to the PC clock rather clock.time is drifting behind the Netduino clock. As you can see from the code above though, there's nothing to it. Certainly no reason for such a rediculous lack of accuracy. Even if I changed the code so that start_ticks = end_ticks after calculating delta, it doesn't make much of a difference. I did notice that if I reduce or increase the sleep time from 50 down to 25 or up to 100, the accuracy of timing was affected but minimally.

What can you tell me about operations and overhead with large datatypes such as System.Long? Could it be significant?

I will restructure this experiment to perform stopwatch-based approach in the main thread and see what results I get.

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.

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.

Hi Nobby,

Is the elapsed time from timers/Stopwatch not matching the increase in DateTime.Now?

Losing 10 seconds in 15 minutes is a lot (~1.1%).

Can you post a quick code snippet showing how you're calculating and writing out the time? We should be able to run it on our Netduinos to reproduce...

Finally...just curious: if you reflash the mainboard with Netduino firmware (instead of Netduino Plus) do you get the same results?

Chris

Hey Chris,

Due to the nature of my project, I can't share code but I have created a new project which is dedicated to the task of timing using Ticks.

The project has three threads. The main program thread, aka Main(), sits in a for(; loop with a Thread.Sleep(500) call. It does this after it initialises a class that manages the time measurements.

The second thread is fed a time object and reduces its time until it reaches zero or less. The thread is executed with default priority through a lambda expression.

 private static void timerFunc(Clock clock)
        {
            if (clock == null) return;

            long startTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;
            long endTicks, delta;
            while (clock.time > 0)
            {
                endTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;
                delta = (endTicks - startTicks) / m_tick; //where m_tick is System.TimeStamp.TicksPerMillisecond

                clock.time -= delta;

                startTicks = Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;
                Thread.Sleep(50);
            }            
        }

The third thread is one that runs in the clock class. It sleeps for 100ms and then uses COM1 to write, in ASCII text, the value of the time of the format "mm:ss.f".

I just started a 15min test against my sports wristwatch and PC application. 10mins into the test, clock.time is eight seconds higher than the timer on my watch.

I haven't tried flashing my Netduino Plus with the Netduino firmware. I have a regular Netduino to use and a handfull of Netduino Plus devices I can downgrade if necessary.

Currently, I'm stuck with the newest firmware for my commercial project. Purely because of the Socket runtime code footprint providing a much needed 10K.

Thanks for having a look at this

Does the call to s.Send() block indefinitely or does an exception get thrown? It's odd that the router permits the outbound socket connection but not the underlying data. I'm 50/50 about Tenda. I've bought quite a few different products of theirs. I use a 16 port gigabit switch at home but I've bought wireless gear as well in the past and thrown it in the bin out of frustration.

sorry, the topic is not going to be that interesting.

I've got my NP hooked up to a serial camera and i want to take a pic and then push it on a webserver.

By the looks of it im getting a outofmemory exception. Is there any efficient way of do this with out using lots of memory?

Is the camera data compressed into JPEG or is it full-frame RGB/YUV pixel data? Either way, image resolution of most cameras these days will exceed the runtime RAM of the Netduino. To test the full functionality of your project(i.e. take pic, get data from camera, post to webserver), try and set the camera to its lowest resolution if possible.

If you don't have those kind of configuration options for your camera, you'll have to go the whole-hog from the beggining. Adopt a block-data processing model. Take the picture and read small amounts of data from the camera at a time. You'll have to send or store(SD card) that data then leave it for the GC to pick up or force the GC to free the memory. Read the next block of data, rinse and repeat.

Are you using a POST method to a web URL? If so, you can define the Content-Length HTTP header property before you stream the data to the webserver(only if you know the datasize of the image before-hand). This will allow you to block process the data, as long as you don't exceed the webserver's timeout. If you can't determine the size of the pic data before you read it from the camera, stream it to a file on an SD card in the Netduino and then read the file-size.

Good luck

another nice trick is the following

string fileLine = "";
while((line=sr.ReadLine())!=null)
{
     Debug.Print(fileLine);
}
sr.Close();

If you mean you would like to create projects which are code libraries you would like to use in other projects, that's pretty easy.

• Add a new project to solution
• Choose "Class Library" instead of "Netduino Plus Application" under Visual C# -> Micro Framework. This what you mean by DLL?
• Write the code in your class library
• Go to your Netduino Plus application project, choose to add a reference
• In the projects tab, choose your new class library as the reference
• You can now use your class library in the Netduino Plus application!!

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

Your file creation and streamwriter code looks fine. The code will throw an exception though if

• The file test.txt already exists on the SD card
• The name of the root directory isn't \SD\

It may seem long-winded but I always query

VolumeInfo[] drives = VolumeInfo.GetVolumes();

It serves to ensure there is an SD card inserted(there are also other ways to check this). The objects also indicate the name of the root directory.

I haven't looked up the reference to Directory.GetCurrentDirectory for Micro Framework. It's standard usage is to return the current working directory which only applies to application domains running normal .Net Framework applications on a PC etc. Since the Netduino executes code from Flash rather than a virtualised application domain run from media, it doesn't use working directories.

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 )

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.

Hi,

Just wondering if anyone can recommend an RFID reader that is compatible with the Netduino. I need one that can read from at least 30cm.

Can anyone help?

Thanks

I've used the Texas Instruments RFID readers in the past with AVR based projects. Unfortunately, there's no way you're going to get 30cm read range out of most units. Purely because the most available and popular units are High Frequency RFIDs(used in keycard access etc).

All the long range options are the low frequency devices(cattle tags, anti-theft etc). I can't remember off-hand what those are but the high freq devices operate at 6MHz and the low frequency devices are in the hundreds of kHz.

Either way you go, all communications are TTL/RS232 with a possible USB option.

Hi Nobby,

wonderful... That clears my doubts.
Just for knowledge, how can I configure PIND7 as RTS, do you have the code for it?

Thanks in advance.

Sorry I've never needed CTS or RTS in any application. I'm fairly sure its only modern use is for UART communications which have multiple devices on the shared three-wire interface and have an address they respond to. There are still some ancient RS232 devices out there which require CTS & RTS for end-to-end comms.

From what I have seen with the .Net framework though, you need to specify hardware flow control on the SerialPort object. It supports XOn/XOff and RequestToSend or a hybrid. You do this through the SerialPort.Handshake property at runtime. I believe once you configure your serial port this way, it will configure the RTS and CTS pins to function with the serial port.

I have a project which utilises both UARTs and I also have RTS0 & CTS0 configured as either interupt ports or output ports with no issues. Can you please post your initialisation code for COM2?

Hi Nobby,

Below is my statement.
m_objCommMgr = New cCommManager("COM2", 9600, Ports.Parity.None, 8, Ports.StopBits.One)

so far, I have not connected RTS and CTS since i am only using 3 wire interface. Since on the board layout, for COM2 it comes with RTS and CTS (derived from GPIO pins), I just wonder if we can disable these RTS and CTS when using COM2. Thus giving my project the much needed GPIO to measure the pulse input.

Care to share how do you initialise your COM2 without RTS & CTS?

Thanks in advance.

The general rule-of-thumb with microcontrollers is that pin assignments aren't always restricted to their architectural labelling. For example, a pin maybe labelled as PWM(Pulse Width Modulator) which would normally tie-in with a hardware clock and hardware interrupts. By default, the pin doesn't function as a PWM unless you actually configure it to be.

Much the same with the CTS and RTS pins, you can configure them as OutputPorts or InterruptPorts. If you try to use them for two purposes, you'll get a runtime exception when trying to initialise the pin for a second use. Example of using the RTS pin as a GPIO pin

SerialPort comPort = (SerialPorts.COM2, 9600, Parity.None, 8, StopBits.One); //Initialise COM2
OutputPort oPort = new OutputPort(Pins.GPIO_PIN_D7, false); //initialise the RTS pin as an output port with logic low as initial value;

The first thing to change on the PC end is your calls to Socket.Recieve(). Since you aren't specifying how much data to read on each call, it will try to read enough data to fill the array and will block until it does unless

• You close the socket
• Have a ReadTimeout value set on the socket

Either way, an exception will be thrown on the PC application. Make the buffer smaller to match the length of the data or provide an amount to read. In your case, the PC application will try to read 1000 bytes all-up.

On the Netduino side of things, I never simply use Socket.Send(). I always tell it was data range to use from the array so that I know I have full control over safe execution. This doesn't mean that the Netduino exception is being caused by this.

Have you tried to power the Netduino with a DC power pack? Does the light turn off with a power pack plugged in and no USB?