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.

As CW2 mentioned, a short could be occuring. Do you have a series resistance on the transistor collector or emitter? Another cause could be your base resistance. 1kOhm is too small. Assuming you don't use an emitter-follower BJT configuration, the base current into your BJT is 3.3V/1kOhm = 3.3mA. This current might seem small but BJTs have a current gain of at least 50 for common BJTs. When your control pin goes high, the BJT will try to draw 165mA from the 5V regulator. When you try to pull too much current from a supply, the voltage of the supply will dip and cause a reset of the Netduino. You should find out what the gain of your transistors are and calculate the base resistance to work well with your relay. For example, you need about 60mA to operate the relay and your BJT has a gain of 100. The base resistance needs to be in the ball-park figure of 55kOhms. Actual(peferred) values you can buy close to that at 56k and 47k. 56k will give you less than 60mA so I'd choose 47k in this case. For saftey, you probably have or should have a series resistor connected to the BJT collector or the emitter. If you drive a BJT hard enough, it's collector-emitter voltage can go down to 0.3V. If you don't have the series resister in there, you can virtually short the 5V rail and cause the Netduino to reset and possibly damage the board. Since your relay runs on 5V, you have to have a small series resistance so that the drop across it when you draw 60mA is small. Secondly, you don't need the anti-parallel diode since it's only for dealing with protection against negative voltages.

Hi!

Thanks for help! Finally I found the problem with Nobby's tip. I changed the base resistance from 1k to 6k and it works now in every variations. However I don't understant totally because I think that the relay's inner resistance limits the current to 70mA. So I don't know why is it a problem if the transistor's gain is too high. By the way I use a BC327-40. As I checked the datasheets its gain is above 250.

Now it works, so thank you!

Awesome work!!


250 gain is pretty high for low power circuits and 6k would be a lot better than 47k in your case. When you design in the future, transistor parameters are important. High gain will usually mean a higher forward-bias base current and larger voltage drop from base to emitter which means you'll choose a smaller base resistance etc.


As for the relay, devices like that don't have the capability to regulate/limit current unless they switch off from over-current(built in protection) so it's important to do power calculations for your transistor circuits. The current in simple circuits like this are always determined by the voltage level of your power source (i.e. 5V) and the total resistance/impedance of the circuit path the current is travelling along. If you follow those fundamental rules in design then your systems will function predictably and safely.

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.

The most common options are UART(RS232 or RS485 from the PC to the netduino) or TCP/UDP network stream/packets. The second option requires either a Netduino Plus or a Netduino with an Ethernet Shield. You can also use I2C(TWI) and SPI but you need to build interfaces at both ends. I'm not even sure you can get something like USB->TWI or USB->SPI(apart from microcontroller programmers) that you can put at the PC to send data to the Netduino. As far as I know, you can't utilise the USB socket for runtime applications but I could be wrong about that. For the 7-Seg display side of things, the serial drivers are usually the best option. They require minimal GPIO pins from the netduino compared to other options. You need to make sure the current capacity of the drivers exceeds the rating of the 7-seg displays as well otherwise they'll heat up and die fairly quickly

I was about to start prototyping code in my existing product to use SSL for client authentication. Haven't written I line of code yet but I've read through the framework API for supported functionality. http://msdn.microsof...y/hh401316.aspx is where most of what you need can be read. I'm not sure if this component of the .Net Microframework is part of the build for Netduinos.

The basic run-down is that your device can be a client or a server as far as SSL is concerned so technically you can pull off HTTPs. If you're using basic HTTPS then you only need to store one or two certificates. One to certify your netduino as a secure server and possibly another certificate/cert chain that points to a publicly trusted certification authority(CA). If you don't care about the certificate being trusted and you just want secure communications it's pretty simple.

• Generate and store the SSL certificate for your netduino into RAM at run-time via the CertificateStore class. Put the cert on an SD card and read it off each time you boot up
• Use the SSLStream class for reading and writing data instead of a NetworkStream with the client socket.
• Server authentication via the netduino certificate is mandatory but client authentication with a separate certificate is optional. Use the SSLStream.AuthenticateAsClient and AuthenticateAsServer functions.
• Once authenticated, you use the streams like normal HTTP

I have used only Nwazet and Proto-advantage for all my stuff, both give you cheap delivery, and reasonable fast shipping.
I'm always taxed on those purchases though, since Norway have this stupid customlimit, if it cost above 200NOK (about $32) I have to pay 25% on everything including shipping.

When I bought an Arduino now, I tried to buy from the italy shop, kinda, to support buying from correct place, but they did not trust the postal system, so they required me to use an $77 UPS shipping. So, of course I bought it from Adafruit instead, which sold me the unit at proper price, and $9 in shipping
Most of my electronic stuff is coming from the two above, pluss ebay, and adafruit.

I feel your pain. My country has horrible software tariffs with the USA. Our currency is stronger than theirs but my MSDN subscription costs me nearly twice as much as a US subscriber. I don't even order DVDs, just download everything.

I understand this might be a difficult ask because of how taxes and tariffs work in various countries but I was looking at being able to purchase Netduinos from overseas. There's only one reseller in my region and they have recently been 'less than helpful' with the loss of and expensive package. I would prefer not to do business with them anymore if possible and I'm a month or two away from a green light to purchase a commercial quantity of Netduinos for a client's project. I've tried using Amazon and a few other resellers and they have international shipment policies in place to prevent purchases for whatever reasons/structures you have in place with your distribution network. This has probably been asked in a few threads but have Netduino Plus 2's been shipped to most international resellers? I would be looking at moving my product's hardware platform from Netduino Plus to Netduino Plus 2 and would like to do an evaluation before buying a bunch.

Hi Nobby,

Which region do you live in? Also, sorry to hear about your bad experience. Is it a Netduino-reseller? If so, it may be good to know for Secret Labs which reseller.

I'd prefer not to put the particulars of the issue on the forum. Is there an appropriate email contact at Secret Labs I could shoot my email off to?

another nice trick is the following

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

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?

I don't seem to be able to find the 30cm go!cable's for sale anywhere. Does anyone have a source? I need the length for the location of the touch screen in this project.

You can make these kinds of things really easily. They require no soldering and you only need tools to do it if you want to make it easy for yourself. The Netduino Go uses standard 10-way header sockets(5x2 pin array) that have locator notches. The items you need to make cables are:

• 10-way plugs (one per end if required)
• Ribbon cable (grey or multi coloured are fine)
• Clamping tool (less than $10 and reduces chance of mistakes)

You can get all of these from electronics hobby shops and electronics parts retailers/suppliers. The 10-way plugs usually come packaged individually with three parts to them. The larger part has sharp contacts that pierce the ribbon cable wires when you clamp it. The other two pieces clip into the main piece. One is smaller than the other. The smaller one is used to clamp the ribbon into the sharp contacts. Line the ribbon up with the contacts and push down hard with the second piece(using the clamping tool makes this really easy). Once clamped, fold the ribbon back over the plug and use the final piece to brace the ribbon. It prevents tugging from ripping the ribbon out of the plug.

The ribbon cable can be bought in lengths you require. If you can't get ribbon with 10 wires in it, just buy anything larger than that. I personally have a massive roll of 16-way that I use for everything and strip off what I don't need for a particular cable. Sometimes you can buy bundles from electronics hobby shops which have breadboard wires and ribbon cable in them with other junk if they don't sell ribbon cable.

Not sure what country you live in but I've never seen these cables pre-made purely because they're not used in consumer electronics for external purposes. I have read that packs of 10-way cables for the Netduino will be sold soon within the USA for people who aren't hardware savey. Not sure what the status on that is.

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.

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

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

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.

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.

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/ .

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.

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.

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).