It should work at 1000 Hz (in all likelihood you'd need to replace '0' in the interrupt condition with a positive number, e.g. 10, and check durationSeconds to avoid division by zero), but you probably mean 1000 kHz - I am sorry, but I don't think this can be achieved in managed code.

Yes, sorry about that. I meant 1000kHz (1MHz).

Stefan W. is completely right; the actual limit is significantly lower than 500 kHz: at 100 kHz the interrupt occurs every 10 µs, which is too fast for managed code to keep up - I don't have exact numbers right now, but execution of managed code statements takes roughly tens of µs (it is not possible to measure code execution precise enough, due to the resolution of the system clock, but I could do that with my custom firmware that has improved clock resolution 2.7 µs).

I am building your custom firmware this morning, but will it work with Netduino Plus? And if I run your custom firmware with this project, do I have a chance of achieving 1000kHz?

I have actually tried it and it is able to measure 10 kHz - unfortunately, I don't have neither signal generator nor Netduino firmware with the newest PWM implementation, so I cannot try higher frequencies.

CW2, here are some of the numbers I am getting with your code:

F = 1802.8 Hz
F = 2467.3 Hz
F = 2930.0 Hz
F = 4076.6 Hz
F = 3125.0 Hz
F = 3232.6 Hz
F = 3125.0 Hz
F = 3348.4 Hz
F = 3349.0 Hz
F = 2467.3 Hz
F = 3347.8 Hz
F = 2930.0 Hz
F = 3125.0 Hz
F = 4688.2 Hz
F = 2467.3 Hz
F = 4075.8 Hz
F = 5208.3 Hz
F = 7401.9 Hz
F = 8635.6 Hz
F = 7812.5 Hz
F = 16581.6 Hz
F = 17081.8 Hz
F = 17347.7 Hz
F = 17987.1 Hz
F = 17790.1 Hz
F = 17701.4 Hz
F = 16971.8 Hz
F = 14610.1 Hz
F = 14322.9 Hz
F = 14802.9 Hz
F = 15828.6 Hz 

I shined a bright light near the sensor and that is how the frequency jumped over 10k. However, if I shine the light directly on the sensor, the whole thing locks up again.

I have added the Interlocked increment statement and that does not help:

// TODO: Probably needs lock here (or InterlockedIncrement)
            if (Interlocked.Increment(ref pulseCount) == 0)

The c

Chris, et. al, Here is the simple version of my code: [

No, the custom firmware just increases clock resolution, it does not make code run magically faster. Seriously, you are wasting your time.
I don't get why you think this is a reasonable goal ... you will not be able to count pulses coming in at 1mhz in managed code. Why are you so fixated on directly interfacing this sensor with the netduino?
As was already suggested in the beginning: Use another sensor, e.g. with a phototransistor or photoresistor (it does not get much cheaper or easier than this) or use another MCU to do the counting for you.

Adding more hardware to this project is a kludge since the chip on-board the Netduino can count these pulses, and I'm not going shopping for more components when I have what I need right here. I just need to know how to be able to count the pulses up to 1MHz. I want to get this sensor to work with an ARM7 48MHz chip, and Netduino has one. I do not care if this project cannot run in managed code.

Is it possible to get this sensor working with native code on Netduino, or not? Can I build my own custom Netduino firmware using the porting kit and make this sensor work?

I own a truck: it has 500HP. I wonder why it can't reach 300Km/h...But I'm sure: it's 500HP powered! Much more than a Ferrari!...
I definitively want it will able to reach 300Km/h, even it's a truck...
What can I do?

Hi Nickduino!...First off, I DO NOT want to start any other ambiguous discussion, or something like that!
I am sooooo happy that you have found satisfaction by realizing your goal.
I would only point that by using the Input Capture, you should able to reach a counting much faster. That's because it is NOT the program that counts, but the hardware itself: the program has only to read the counter value.
The Input Capture stage is also present (named as TC) in the Atmel's chips, such as the AVR and ARM (the Netduino's). By hacking the Netduino firmware you will also able to take advantage of the TC section.
However, what I wanted to say in the previous post is that the project is much faster to realize having an extra microcontroller, as your PIC.
Again, happy to read your success!
Cheers

Thank you Mario!

I've decided to dig in to PIC32 programming in order to get full 1Hz to 1MHz display resolution from my TSL235R light-to-frequency sensor.

The answer is yes, to both questions.

Thank you.

Hi NickDuino,

I'm just picking up on this thread now, but are you using InputPort to meeasure the time in managed code instead of using InterruptPort (which passes a fairly precise timestamp of the original event)?

Hi Chris,

I am using InterruptPort:

                // the pin is expected to interrupt on rising edges
                InterruptPort _dataOutInterruptPort = 
                    new InterruptPort(Pins.GPIO_PIN_D2, false,
                                       Port.ResistorMode.Disabled,
                                       Port.InterruptMode.InterruptEdgeHigh);

                // add an interrupt handler to the pin
                _dataOutInterruptPort.OnInterrupt += 
                    new NativeEventHandler(_dataOutInterruptPort_OnInterrupt);

And in the event handler _dataOutInterruptPort_OnInterrupt, I am simply counting the pulses with a long variable:

            private void _dataOutInterruptPort_OnInterrupt(uint port, uint state, DateTime time)
            {
                _pulseCount++;
            }

I'm then using the _pulsecount to determine the frequency and then using some additional math to get the irradiance. If I cover the TSL sensor with a black cloth, I do get a few readings from the Netduino, but after that, my Interrupt stops firing. If I shine a bright light on the TSL sensor, I never get any readings and the Netduino becomes "busy" and unresponsive to the IDE.

Perhaps there is too much code in my interrupt routine. I am going to write a real simple version that does not do any irradiance calculations and only prints a very limited amount to the Debug console. I will post the code to this thread later today.

P.S. A quick way to help determine if the Netduino's memory is getting filled with events is printing out the avaiable memory using Debug.Print(Debug.GC(true)); in your loop (not the event -- Debug.Print will slow down your event).

Here's the Debug.GC(true) output, and I ran this from the main loop, not the event:

27888
27000
27912
31056
32796
32796
32796
32796
32796
32796
32796
32796
32796
32796
32796
32796
32796
32796
32532
20472

After the 20472, I lose connection with the IDE. I am using a Netduino Plus by the way. If I turn off networking, would that help? I see that with networking turned off, I should have 60k of RAM. If so, how do I turn off networking? If that won't help, what else can I do?

No, the ADC was for an hypothetical analog sensor. If you're hooking your sensor to an arduino, you can directly count the pulses with it and then send that number to your netduino. However, using an arduino is overkill for that, you could just use a "naked" microcontroller (e.g. an atmega168 or similar - also overkill for this, but a lot cheaper than a "full" arduino - that is, if you already have a programmer/are planning to buy one anyway).

Can an Atmel AT91SAM7X512 microcontroller support the functions of the Taos TSL235R?

I am still not convinced that I need to throw more components at this problem. Netduino has an ARM7 48MHz processor- why should we deny that there is plenty of speed right on this development board? If I were to remove the processor from the Netduino and program it directly, or remove the .Net firmware and run C/C++ on it, I am sure that this sensor would run fine. I've read in these forums that version 4.1.2 of the Netduino firmware is supposed to offer run-time native code interop. I've also read about someone's project called "Fluent", which runs code something like 20 to 30 times faster than the managed code. I've also read that you can run FreeRTOS on the Netduino platform. Can't you run a quadrocopter with FreeRTOS? Isn't that real-time?

Does version Netduino 4.1.2 have runtime native code interop? If not, when will it have this functionality? Where can I get this "Fluent" project? Where can I find resources on how to run my own C/C++ on this board?

I understand the opinion that more tools will help me solve this problem, but I would rather use what I have instead of having to then deal with connecting, learning, and powering these other pieces.

Page 3 of this document indicates that the TSL235R can be used for photographic applications. Instead of the project I mentioned above, let's say I want to build an accurate light meter for a camera. How could I make the TSL235R work with the Netduino from 1Hz all the way to the full 1MHz output frequency so that I have full resolution? If I programmed this in native code, would that work? Or is there another component I could use to obtain the frequency from the TSL235R and then somehow send the results to the Netduino? If so, how can I do this?

I am still confused as to why I cannot directly interface it with a Netduino. Does it somehow make a difference if it is outputting a 50% duty cycle and not a pulse train? How are they doing this with a .Net Micro Framework board? Here is an example of directly interfacing a TSL230R with a .Net FEZ board, using .Net Micro Framework C# code. Am I missing something? Are they scaling the result or something?

The sensor looks great, but there is a problem that makes any conversion hard. You may notice that the sensor has a dynamic of 10E6, i.e. from 1 to 1MHz. In other words, if this sensor was a voltage generator and you were using an ADC, you should consider at least a 20-bit ADC.
So, I guess the Arduino would be the easiest way to monitor the frequency produced by the sensor, just because you may code the best algorithm without great efforts.
Hope it helps.
Cheers

Pardon my ignorance, but does this mean I could connect a 20-bit ADC to an Arduino and use it to measure the TSL235R output and then connect an Arduino to my Netduino via SPI? This way, the Arduino could report the measurements to the Netduino at a certain reasonable time interval. Is that correct?

I found this ADC chip that looks like it interfaces with an Arduino nicely. Although it is a 24-bit ADC, they were getting 18-to-19-bit precision in testing. Would this chip work for me?

Can someone please speed up my Netduino? Does anyone have a Netduino Ultra I could borrow?

I just set up that FEZ code to run with the Netduino and the TLS235R, and Netduino still chokes on it after three reads. I also had to cover up the sensor with black cloth or else the Netduino failed immediately. Here are the readings I'm getting with the sensor completely covered:

Using an Interrupt
Reading 0
20400 Hz
221739.13043478262 uW/cm2
2650.3369113867698 lux (single)
163.81671308080081 lux (gauss)

Reading 1
20500 Hz
222826.08695652176 uW/cm2
2663.3287589916072 lux (single)
164.61973618413808 lux (gauss)

Reading 2
20400 Hz
221739.13043478262 uW/cm2
2650.3369113867698 lux (single)
163.81671308080081 lux (gauss)

Reading 3
3500 Hz
38043.478260869568 uW/cm2
454.71466616929877 lux (single)
28.105808616804058 lux (gauss)

Invalid frequency 0
Invalid frequency 0
Invalid frequency 0

I guess I am going to have to learn how to program another bare MCU and use that for my readings. It is really cool to watch the frequency change on my oscilloscope as the light levels change. The readings look nice and stable. And yes, I shined a really bright light on the sensor and watched the scope and it did go to one pulse every 2µs.

.

The Gainspan GS1011MIP is $69.99, for the breakout board. I use this module with the Netduino.

If you're good at soldering and figuring out schematics, you can get the GS1011MIP module itself for $33.95.

Thanks Nick F. for the quick response. I will take a look at the breakout board version as soldering is not my specialty.

In general how was your experience working with this device? Are there any other components that you used for your implementation? thanks again.

mattnet,

I've had great success with it. My Gainspan post should help. There is example C# code which has helped others get up and running quickly and I also put up a video example of ad-hoc Wi-Fi communications between two Netduino's with Gainspan modules.

Just a word of caution: if you want to update the firmware to the current version, you will need to sign a non-disclosure agreement with Gainspan in order to get the current firmware files. However, the device works fine out of the box without a firmware update. I updated my firmware to take advantage of the ad-hoc DHCP server functionality.

Besides wires, there are no other components required, unless you want to update the firmware, which requires a USB-to-UART 3.3V adapter. Check out my post for all the details.

You'll still need to do some soldering to get wires connected to the breakout board holes, but it is not difficult.

Nick

Stefan, you are right about the current peak, but it is very very short in time.
Supposing the switch equivalent resistance around 1 Ohm (it is surely lower), the capacitor will be discharged in less than one microsecond.
Within this short time an overheat is not possible, so nor any switch damage.

It is also valuable your tip about the software debounce filter, but I think it should be already present. Either it has been implemented and it works, or it has *NOT* been implemented and we must create our own.
Anyway, post the code of your solution: it may be useful sometime.
Cheers

I wrote a simple software de-bouncer today and it works great. I am a little surprised that we would have to do this since the glitch filter should provide this capability. I will post my code here tonight.

I set up my software debounce like this:

	static long lastDebounceTime = DateTime.Now.Ticks;  
        static long debounceDelay = 100000;   //adjust as necessary

	public static void Main() {
		InterruptPort input = new InterruptPort(Pins.GPIO_PIN_D4, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeBoth);
        	input.OnInterrupt += new NativeEventHandler(input_OnInterrupt);
	}	 

	static void input_OnInterrupt(uint data1, uint data2, DateTime time)
        {
            if ((System.DateTime.Now.Ticks - lastDebounceTime) > debounceDelay)
            {           
                lastDebounceTime = DateTime.Now.Ticks;
		// do stuff
            }
        }

Thanks everyone for the help.

Hi, I have a wall switch connected to D4 and Ground on my Netduino Plus. I am using the internal pull-up resistor and I set the glitch filter to true. The input still bounces a lot. I also tried just using jumper wires as the switch and it is still very bouncy. My code is simple. I set an Interrupt to listen for EdgeDetectBoth and in the interrupt I am just printing the status to the debug window. Any thoughts as to why it would be so bouncy? I tried putting a .1uF capacitor across the connection and that helped, but is a cap connected across D4 to Ground an Ok method to use or will this cause problems with the Netduino? Is it better to set up a software debounce?

I am converting a project from Netduino to Netduino Mini, and I have a device that requires 3.3V power. Is there a 3.3V pin on Netduino Mini so I can power this device with the Mini? Thank you