Hello Stefano,
Sampling rate is a function of the Sharp sensor itself and the rate at which you poll the Serializer for sensor updates. The GP2D120, for example, can generate distance measures at a rate of one every 38.3 +- 9.6 milliseconds (according to the datasheet). Depending on the serial datarate you have configured for the Serializer and the number of other commands being sent, you should be able to send the command to read the Sharp sensor (using the .NET library or C++ library, soon to be released) and parse the return value within this 38.3 millisecond sensor sample rate.
So in general, I would expect that the sample rate of the analog input will be governed by the location of the largest bottleneck for all processing required to produce the digital numeric value that you can begin to process. This processing path would include the sensor itself, the Serializer A/D, and the host processor running the .NET (or C++ in a future release) library to parse the value returned by the Serializer. In most cases, I suspect that the sensor will be the biggest bottleneck and will dictate the maximum sample rate. This will of course vary from sensor to sensor. The Serializer A/D will have its own maximum sample rate, but I suspect that this will always be significantly higher that the sensor it is connected to and will never represent the largest bottleneck.
James Y. Wilson http://www.learningce.com Fortudine Vincimus!
Stefano,
The maximum rate that you can query any sensor plugged into the serializer using the .NET library is every 1 msec, and that's based on the value of the UpdateFrequency for all objects derived from QueryableComponentBase. QueryableComponentBase uses a .NET Timer object, which has a timing resolution of 1msec.
Of course, the more sensors you have connected to the Serializer to query at a high polling rate, then the ability to realistically meet the 1msec deadline is reduced.
As Jim pointed out, the Sharp IR sensors have around a 38.3 +- 9.6 milliseconds response time, so it would be silly to query these sensors at a rate faster than around 30 msec.
Since you communicate w/ the Serializer at 19200 bits/sec (default baud rate), which is actually 2400 bytes/sec, it takes 0.4msec to transmit each character. The command to query a Sharp ir sensor, for instance, is 'sensor X' (where X is the analog pin), which takes 8 bytes, and thus 4msec (including start/stop bits). Then you have to wait a very short time for the Serializer to respond (which varies based on if you're performing PID looping, etc.). Then you have to interpret the results in the .NET lib, and set the property values. So, I'm guessing a realistic round trip time at this baud rate is about 9-10 msec per sensor.
You can communicate w/ the Serializer very reliably at 115200 bits/sec. At this speed, you should be able to reduce the round trip time to around 1-2msec, which might be useful if the sensor you are querying is fast enough, or if lets say you have 5 analog sensors you want to query every 2-3 msec.
Hope this helps!