When Yoctopuce talks with customers, we realize that there are sometimes misunderstandings about the inner workings of Yoctopuce sensors. These misunderstandings may lead to suboptimal use of the said sensors. Therefore, this week we are going to clarify some points.
Yoctopuce sensors are not native sensors
Customers potentially interested by Yoctopuce sensors often wonder if these sensors are recognized as such by the operating system of their computer. Among typical questions, we have:
- If I connect a Yocto-Light-V3 to my computer, will the screen brightness start to adjust automatically?
- If I connect a Yocto-GPS-V2 on my phone, are the apps using geo-localization going to start working?
- If I connect a Yocto-3D-V2 on my Android car radio, is it going to be able to display how much my car leans?
In all of these cases, the answer is no because the operating system of the host machine doesn't recognize the Yoctopuce sensors as native sensors. In fact, all Yoctopuce modules use a protocol called "HID vendor specific" to communicate with their USB host, so that when you connect a Yoctopuce sensor to a computer, the latter doesn't realize that it is a sensor.
We chose this protocol because it enables us to spare the users the installation of a driver to use their Yoctopuce modules. In fact, all operating systems which can manage a keyboard and a USB mouse already have a HID driver available. This enables them to talk with "HID vendor specific" devices without additional driver.
Moreover, this way of doing things is flexible enough to allow us to freely implement all the features that we deem interesting, which would probably not have been the case for a standard driver of which the architecture is often imposed.
The other side of the coin is that Yoctopuce modules work only with applications which were specifically programmed to use them. Since Yoctopuce products are not intended for the general public but for customers who want to build their own solutions to specific problems, this has never seemed to us to be a big issue.
A few Yoctopuce sensors, understanding theirs inner-working is important.
get_currentValue() is not synchronous
The simplest and most intuitive way to obtain the value of a Yoctopuce sensor consists in calling the get_currentValue() method of its API. However, it is important to understand that the measures performed by the sensor and the calls to get_currentValue() are not synchronous. The sensor performs measures in a loop at its own pace and the call to get_currentValue() only returns the result of the latest measure.
Therefore, if you query a sensor by calling get_currentValue() in a loop, increasing the speed of your loop will not necessarily increase the frequency of your samples. Moreover, because of communication delays, querying a sensor by polling is far from efficient, you had better use a callback mechanism.
We chose this way of doing things for two reasons.
- Regardless of the sensor, physically performing the measure is not instantaneous. It can easily take a few milliseconds, or even a few tenths of second in the most extreme cases. If get_CurrentValue() actually triggered a measure, the call would take the time to perform the measure, with an additional 20-30ms to perform the round trip communication between the host and the module.
- All the Yoctopuce sensors have a data logger feature which enables them to automatically perform the measures and store the results in the module flash memory for later use. This means that when the data logger is enabled, the module has to take measures all the time anyway.
With a few exceptions, the internal sampling frequency of a Yoctopuce sensor is fixed and cannot be modified by the user. It was chosen as a compromise between acquisition speed, measurement noise, and the modest transfer capacity of USB 1.1.
It is therefore useful to understand that not only there is no point in trying to get data from a Yoctopuce sensor at a higher speed than its internal sampling rate, but it is also counterproductive. You can find this frequency in the specifications of each product. Even if you are not interested in a high frequency, the periodic callback technique can be interesting because below 1Hz, you will automatically get averaged values as well as the two extreme values for each period.
Maximum frequency
The maximum theoretical transfer rate available to Yoctopuce modules is of one 64-byte packet every millisecond. This means that callbacks at more than 1000Hz are physically impossible. In real life, there is no Yoctopuce sensor capable of offering a refresh rate higher than 100Hz.
Programming: classes
It may be useful to remember that the Yoctopuce API is not built on the "one module/one class" model, but rather on the "one feature/one class" model. For example, a module hosting one or several light sensors can be used with the YLightSensor class, a module containing relays must be used with the YRelay class, a module with a temperature sensor and a pressure sensor must be used with the YTemperature and YPressure classes, and so on. We wrote a a more exhaustive post on this topic a few years back.
The YSensor class
It is useful to know that, from a programming standpoint, all the classes of the Yoctopuce API which enable you to work with Yoctopuce sensors inherit from the same YSensor class. Thus, if your application uses different sensors and you need only to use the basic functions of your sensors, you could greatly simplify your code by basing it on this YSensor class rather than on the classes specific for each type of sensors. However, there is no equivalent for actuators.
By way of conclusion
We hope that these few points will help you make the most out of your Yoctopuce sensors. If you have other questions, don't hesitate to contact Yoctopuce support.