20 replies to this topic

[ULight.Me]

After performing a search on this forum I didn't find any information on the topic of High Speed Photography. Question: Would it be possible to trip (close circuit) of a camera flash on (for example) water drop passing through a photo-gate, or bb gun firing or bursting balloon? I imagine it's possible with the netduino. What parts would I need to purchase to achieve this? I'm a noob at all this circuit stuff, I'm fairly comfortable with a soldering iron but I would prefer a solution that's simple to assemble and to operate. I'm very comfortable with scripting languages and development. Thank you in advance.

[Mario Vernari]

Hi there. It might be possible, but you should calculate in advance how big could be the maximum error (in time) that is allowed. Netduino uses managed code that is not real-time proof, so if your target is within 1-2 ms (even less) of delay error, that could be possible. Cheers PS: welcome in our forum!

[Michel Trahan]

30fps is about 33ms ... do you have access to the ccd through i2c or serial ? what is the throuhgput available from the netduino compatible camera ? links please

[Mario Vernari]

Michel, I guess he mean the camera flash, not the camera (ccd). I have understand that the goal is to trigger a flash (so then the camera shot), via some sensor (e.g. photo cell). Is that true?

[ULight.Me]

Ultimately what I need to do is described in this link. DIY High Speed Photography

I need a delayed trigger circuit that can 'short' the flash hot-shoe pins (to fire a strobe flash) after getting tripped by sound or something passing through a gate (like a water drop)

I'm sorry if I'm not being clear ... I will look for some more links to share on the subject.

[ULight.Me]

OK so I found this article.
It describes what I'm trying to achieve by using the ARDIUNO

LINK

[Mario Vernari]

The Arduino sample looks pretty good and really simple. However, I don't think it can be performed by using a Netduino: the delay between the ADC reading and the flash trigger could be too long. It seems to me that you need an less-than-one-millisecond response time: perhaps could be hacked in some way even with Netduino, but I guess is somewhat hard. Cheers

[ULight.Me]

The Arduino sample looks pretty good and really simple.
However, I don't think it can be performed by using a Netduino: the delay between the ADC reading and the flash trigger could be too long.
It seems to me that you need an less-than-one-millisecond response time: perhaps could be hacked in some way even with Netduino, but I guess is somewhat hard.
Cheers

Thank you for your response.

I'm not sure what ADC is there a delay between receiving a trigger from a sensor and performing a pin short? I was assuming that I'd be able to modify this delay programaticaly or through a web interface?

[Mario Vernari]

The meta-program you should write, could looks like this:

forever
{
  value = read myADC
  if (value > threshold)
  {
    activate myOUT
    wait a bunch of millisecs
    deactivate myOUT

    exit forever
  }
}

The program loops indefinitely within the "forever" clause, reading the ADC port until the value become grater than a threshold. That threshold is adjustable from you, of course.
As soon the threshold has reached, the output (flash) has to be activated. The successive delay is just to keep the flash activated enough (on the Arduino project is 100ms).
Finally shuts the flash off and the program ends.
This is *VERY* trivial!

Where is the problem?
The bang of a gun runs about 34cm/ms (1 foot/ms).

A board like Arduino can read the ADC, evaluate the condition and perform the output activation within a bunch of microseconds. The delay between the sensor detection (i.e. ADC read) and the flash is insignificant.

Netduino operates with managed code, much more powerful, but also much heavier. The same task can take some millisecond, but it is also uncertain and variable time by time.
One millisecond less or more is significant, because your bullet could be run over the balloon, while the flash will light with a substantial delay.

I'd choose an external circuitry or an Arduino board. That depends on your long-term goal.
Cheers

[ULight.Me]

This is a valuable response .. I appreciate it.

[ULight.Me]

Netduino operates with managed code, much more powerful, but also much heavier. The same task can take some millisecond, but it is also uncertain and variable time by time.

Is there a way to test this delay between tripping a trigger and performing a pin short?

Why would the delay be variable?

[Mario Vernari]

Is there a way to test this delay between tripping a trigger and performing a pin short?

The simplest way is using a scope.
Without any instrumentation it could be difficult. Another way to test the time could be using a kind of circuit measuring the time...I think it is not so easy for who has not practice with hardware, though.

Why would the delay be variable?

Basically there are two factors that could influence the delay:

• the garbage collector, that is a underlying task that flushes away the finalized objects and compact the memory also;
• the multi threading, that may break silently your function to serve some other pending.

The last could be controlled with some trick, but not at all. The first one is completely out of control...at least I have no idea how to do it.

Cheers

[Terry Massey]

Is there a way to test this delay between tripping a trigger and performing a pin short?

Why would the delay be variable?

Garbage Collection. If garbage collection occurs while your trying to fire it off your code would be put on hold so thus the variable. You don't know if garbage collection will occur.

[CW2]

Is there a way to test this delay between tripping a trigger and performing a pin short?
Why would the delay be variable?

In response to what Mario and Terry said, IMHO neither multithreading nor garbage collector is really the issue here, in this particular application both can be avoided: there is no need for multiple threads and garbage collector will not run until there are objects that go out of scope and need to be cleaned up to make room for newly allocated objects - this can be ensured with careful coding.

The real problem is the way how .NET Micro Framework handles interrupts: they are queued and events are checked for only in between scheduling threads, this happens on Netduino every ~21 µs (frequency is 46875 Hz). Another problem is that in the current implementation of .NET Micro Framework native method calls are blocking, which means the CLR execution engine has to wait until it finishes - but in this particular application we can avoid this, if no such function is called.

The trivial case is to connect a sensor directly to a pin configured as an interrupt source. The sensor can be for example a phototransistor, or anything that outputs voltage in logic level thresholds (a passive level shifter, voltage divider, pull-up/down resistor can be easily used if needed). The application can look like the following:

using System;
using System.Threading;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace NetduinoApplication1
{
  public class Program
  {
    private static InterruptPort sensor = new InterruptPort(Pins.GPIO_PIN_D0, false, ResistorModes.Disabled, InterruptModes.InterruptEdgeLow);
    private static OutputPort trigger = new OutputPort(Pins.GPIO_PIN_D1, true);

    public static void Main()
    {
      sensor.OnInterrupt += sensor_OnInterrupt;

      // Wait for the sensor interrupt
      Thread.Sleep(Timeout.Infinite);
    }

    static void sensor_OnInterrupt(uint pin, uint state, DateTime time)
    {
      // This is called at 'time', but a little bit later
      // than the interrupt really occured.
      trigger.Write(false); // Toggle trigger (falling edge)
      trigger.Write(true);
    }
  }
}

After the setup (the interrupt mode and trigger initial value were chosen to make measurement easier, they are not particularly important) the application waits for the sensor interrupt to occur. When it happens, sensor_OnInterrupt event handler is called and toggles trigger output pin. The handler is called 266 µs (min), resp. 278 µs (max) after the signal change occurs on the interrupt pin; see attached screenshots (measured with official firmware 4.1.1. beta 1, yellow channel 1 is sensor, cyan channel 2 is trigger pin).

So, now the question is, if such delay is acceptable in your desired scenario? And if you can compensate for it? A bullet will travel about 10 cm in ~0.3 ms.

Personal note: For this kind of application, Netduino is rather an overkill and it makes little sense to invest into overcoming one of .NET Micro Framework's weaknesses. I would go for Arduino (even though it is an overkill too, this can be done with only few components ;- )

Attached Files

•  InterruptDelay-266us.png   2.2KB   49 downloads
•  InterruptDelay-278us.png   2.23KB   42 downloads

[Mario Vernari]

CW2 has explained much better than me and Terry the problem. Over that, I have learned another little feature of the MF. He has posted a minimal example on how to trigger an output. I agree at all that a similar program makes Netduino an overkill, that causes only problems instead of solve them. I have two observations, though... Firstly, that program has not any object going off the scope, so the GC would never work. I'd say that it is hard (better:nonsense) to write a practical application, where we must pay attention to avoid any GC'ing. So, *that* example is correct, but as soon you begin adding some function, some object would be created and destroyed. Secondly, the same example is firing me a question. That is a single thread task, without any other service running, and it waits for a stupid interrupt. I am also assuming that the interrupt is natively fired (such as a MCU handler), and *not* simulated by polling some flag. So far so good. Now, why the delay is so large? Assuming a certain number of tests, I was expecting a jitter of 21us (that is the slow clock period) and not 12us. Maybe 'cos you've done a couple of test only? Over that, CW2, we are talking of a 48MHz CPU: what the hell it is doing between the interrupt and the output falling edge???... According to the sheet is over 10K instructions: what are these ops??? Cheers

[CW2]

Firstly, that program has not any object going off the scope, so the GC would never work. I'd say that it is hard (better:nonsense) to write a practical application, where we must pay attention to avoid any GC'ing. So, *that* example is correct, but as soon you begin adding some function, some object would be created and destroyed.

Yes, I agree with you - although it is possible to avoid garbage collecting, in practical use it makes little sense - because it is one of things to benefit the most from in a managed application.

Secondly, the same example is firing me a question. That is a single thread task, without any other service running, and it waits for a stupid interrupt. I am also assuming that the interrupt is natively fired (such as a MCU handler), and *not* simulated by polling some flag. So far so good. Now, why the delay is so large?

The interrupt is handled immediately in the ISR (Interrupt Service Routine), but it just adds a callback entry to the HAL queue.

Assuming a certain number of tests, I was expecting a jitter of 21us (that is the slow clock period) and not 12us. Maybe 'cos you've done a couple of test only?

To be honest, I was expecting 21 µs too, at this time I don't have an explanation for ~12 µs jitter. The results are from many test passes, I have used 1 kHz continuous square wave signal to simulate sensor output.

Over that, CW2, we are talking of a 48MHz CPU: what the hell it is doing between the interrupt and the output falling edge???...
According to the sheet is over 10K instructions: what are these ops???

There is one slight inaccuracy in the original post related to time measurement - the delay between edges includes OutputPort.Write() call, the interrupt event handler is executed a little bit earlier. It takes roughly 50 µs for the interpreter to execute the method call, native pin state change function takes about 4 µs (the port register is changed at about 2 µs from the native function start) - it would require change in firmware to make precise measurement, I have not done that.

I also agree that such performance seems to be low, considering a 48 MHz 32-bit microcontroller - on the other hand, there is quite a lot of things happening in .NET Micro Framework. Unfortunately, I cannot give you a definite answer, because my knowledge is still rather limited in this area (and you would probably not appreciate a list of source files or function names :- ) I strongly believe there is a room for various performance improvements in the current .NET Micro Framework implementation, or it can be extended to support some specialized application scenarios. However, one has to keep in mind that it is not designed to be real-time system, and sometimes there is a board that fits particular need better than the other (dare to say Netduino; but $35 48 MHz switch... ...I do understand most of the projects here are to learn electronics and embedded programming, which is great and .NET MF is very good for that).

[Mario Vernari]

although it is possible to avoid garbage collecting

It sounds to me easier to say than to do.
Just modify any string and the game is over.

It takes roughly 50 µs for the interpreter to execute the method call, native pin state change function takes about 4 µs (the port register is changed at about 2 µs from the native function start)

Some microsec is fully acceptable as "macro" for setting a port. I guess an asm port r/w could take 1-2 cycles.
Of sure it's me, but I really cannot believe that a "gosub surrogate" could take thousands of ops.
Is there any way to make it faster?

dare to say Netduino; but $35 48 MHz switch

I don't believe the problem is Netduino itself. Chris has put a powerful MCU on a board, then glued some peripheral around. All that for a bunch of Euros. Nothing wrong on that.
I think the problem is behind the MF...I may understand that the MF team is climbing the Space Needle with nails, but they must recognize that a realistic platform could not perform decently only using a 100+ MHz chip.
Did you remember the "ancient" PC-XT @ 4.77MHz, with 640K ram???
Please, let explain me why a several thousand lines Turbo Pascal application would compile in few secs on that PC, and the MF would take a dozen of mins on a 4Gig, 2.2GHz dual-cored CPU???
Let explain me why on that old PC you may run and use complete apps, even graphical, and here a single call takes 50us???

I repeat, it's surely me, but I feel there is something off our control.
Cheers

[Fred]

I have to ask why the Netudino (or any microcontroller) is being used in a circuit like this? It doesn't appear to be the right tool to use. Surely this is a job for something like the versatile NE555? Triggering when a value crosses a threshold? Check. Accurate timings? Check. Fair enough if you just want to see if it can be done.

[Mario Vernari]

I have to ask why the Netudino (or any microcontroller) is being used in a circuit like this? It doesn't appear to be the right tool to use. Surely this is a job for something like the versatile NE555?

There's no doubt that a one-Euro 555 would be the perfect solution for this kind of apps. The '70 were plenty of 555 circuits and we able to fly to the moon without Netduinos!
However, there are many friends that don't know how to build even a simple circuit with a 555.
Secondly, perhaps they are attracted by this board and would build a very simple application.
Thirdly, such a context is very useful because it shows clearly some lacks of a Netduino/MF board.
Cheers

[Michel Trahan]

Did you remember the "ancient" PC-XT @ 4.77MHz, with 640K ram???

Hey, I bought a co-processor for one of those to make my galaxy creation simulation work in a week instead of a month

However, there are many friends that don't know how to build even a simple circuit with a 555.

I'll have to learn about those

Secondly, perhaps they are attracted by this board and would build a very simple application.

Yeap, that is me, simply learning .net in an interesting way (.net in all forms, normal, phone and MF, cool and having fun)

Thirdly, such a context is very useful because it shows clearly some lacks of a Netduino/MF board.

This is the goal of this experiment. Find out what works and what is missing, all for the ease of programming whatever we get our hands on

I'm looking at a 3D Printer right now and it is because I played with a netduino that I might have on in a few months

It is not a problem of our lack of knowledge about what to use when ... it is a question of finding out how we can adapt our tools to help even more

I Love This Community (ILTC)