Main Site Documentation

Analog Input Improvement


#1

Hi all,

I recently dicover Fez and I must say I love them. I bougth one Panda to test it and its really amazing. I’m familiar with a lot of uC, avr32, coldfire, hcs12, hcs08, even hc11 !!!, done a lot of projects in C, C++ and asm… but having an IDE like visual Studio its priceless.

I wanted to use the Panda in a course (I’m a Teacher at an University in Argentina) to collect data at a not too higher sample rate and send the data througth USB.

Soon I discover that I cannot get a reliable latency of less than a millisecond because .NET is not real time (I’m still dont know why I get 3 to 4ms of latency when nothing else is ejecuted and there is no need to run GC I’ll post a sample later).

What I want to suggest is the following:

Make analog samples work on an interrupt as a regular basics (Not too dificult in C) and put data in a round queue and let the user take data from there using a flag to indicate overflow.

Doing that could be posible to get real time samples and transmit then through USB when there is time to do so.

Could it be posible ?

I could do that myself but I dont want to erase GHI using the open version of .NET because I want to use the USB functions not present in the open source version.

By the way, as far as I know RLP its not present in USBizi, i think this is due to prevent some user to do a program to read entire flash and get USBizi firmware. I am correct ?

Thank,
Pablo


#2

Thank you for the suggestion. This is something we thought of already. As a general idea, NETMF device is a high level device that does perfect job for non-realtime things, like SD cards, USB and networking. When a developer needs very specific timing (realtime) then they usually add a little 8-bit micro that does very simple task, like counting pulses or reading analog values. Now, what you have asked for is something that can be done and I will forward this to the GHI development team. No promises on implementing it though.

RLP is not on USBizi for multiple reasons, starting with protecting our IP, but there are other internal design reasons as well.

Please take a look at the FAQ page if you haven’t do so already :slight_smile:


#3

What a fast response !!! Never got a support quicker than that. Great Job.

I think this would be a great addition to accomplish a lot of things. In my particular case I want to sample an ECG signal at 1 Khz and transmit it via USB in an isolated way (I already did some USB isolators).

Thanks Gus.


#4

I was also thinking in these lines.

I would like to sample the analog output of an ultra sonic sensor, thus I need fast samples ,20kHz would do, 100kHz would be better… :smiley:

It would be nice to have an addon to the ADC where you can give it a buffer and tell the ADC to fill it at X sample frequency. With an event when it is done.

Maybe also a double buffered setup where you give it two buffers to fill. It starts with buffer A, raises an event when buffer A is full while continuing to fill buffer B.

Too much? :slight_smile:

Thanks,
Errol


#5

Using a buffer like this for analog sampling, especially the double buffering, opens up a lot of new projects. For example a sound recorder and a digital oscilliscope are two that come to mind right now. Im adding a +1 to this feature request too.


#6

+1 for this feature request as well. -Eric


#7

This would be great. +1 from me too.


#8

and me


#9

Hi Gus,

Did anything come of the internal discussions on adding a feature like this? I have been looking into using RLP on my FEZ Cobra to try and implement something along these lines. My needs are more in the 3 to 5 kHz range but I don’t see any reason why a low-level buffered IO reading feature could not deliver samples to a high level app, especially on the FEZ Cobra.

Thank you very much,
Rhynier


#10

We did some testing and got 8K samples/sec easily. We were doing audio recording. So the answer is, we will not add anything internally as this is user specific and using RLP a user can make any functionality they need.

This will be detailed on the wiki, there is a draft for now but it will be cleaned up in few days http://wiki.tinyclr.com/index.php?title=RLP_Realtime_Audio_Recording