We noticed that the topics of our latest posts were step by step getting more and more specialized. To avoid scaring new users away, we thought that it was time to go back to the basics and to gather in a few post the basic principles underlying the use of our modules. So, here is the first post of the series, which could have been namedYoctopuce for Dummies if it did not infringe on a well defended trademark.
This first post, rather theoretical, provides an overview of the concepts and choices behind Yoctopuce modules. Reading it will help you when you later use the modules.
Architecture
The common goal of all Yoctopuce modules is to provide a simple interface between machines and the real world. All of our modules share a very similar structure, directly resulting from this common goal:
- On one side, you find the electronics measuring or communicating with the outside
- On the other side, a small CPU which makes these measures readily available to a computer
The physical structure of Yoctopuce modules. Here, a temperature sensor
We made the deliberate choice to include in all of our modules, even the simplest ones, a tiny processor that provides a USB interface and publishes in a neat and explicit manner the functions available in the module. In the opposite to a basic breakout board which would contain only a sensor to be interfaced at the electrical level, the Yoctopuce module processor provides rather advanced predefined behaviors, such as data logging, and temporal automation.
The processor used in Yoctopuce modules is tiny: there is not room for an operating system such as Linux. The Yoctopuce module behavior is actually dictated by state machines, like an automaton. Thanks to this, its behavior doesn't change over time and it doesn't require any maintenance. But the price to pay, because there is always a price to pay, it that the user cannot modify the behavior of a Yoctopuce module: you can't install your own applications.
Modules types and interactions
You can sort basic Yoctopuce modules into three families:
- The sensors, which measure a physical quantity
- The actuators, which act on their environment
- Interface modules, which communicate with other electronic devices
A sensor, an actuator, and an interface module
Our modules are thus building blocks that each fills a well-defined function. They can be combined together and with a software to make a finished product. But in and out themselves, they are not complete products and even less turnkey solutions. For example, our temperature sensors don't have a screen because they are not meant to display the temperature, but to measure it. To display the temperature, you have to add a screen and write a program reading the value of the temperature sensor and displaying it on the screen using the Yoctopuce programming library.
When you embed our sensors in a project, the device is presented in several aspects. First, you can interact with the module itself, for example to detect its presence, read its power consumption, or assign it a name. Second, you can interact with each measuring function provided by the sensor. For example, a Yocto-Thermocouple provides two independent channels to measure temperature. The interface of each of these channels is by the way strictly identical to that used to measure temperature with a Yocto-PT100. It goes even farther: interfaces allowing your to manage the distinct modules all have a similar working mode. If you know how to use a particular Yoctopuce module, you most likely know how to use the others without even having to read the documentation :-)
Likewise, actuators provide one or more output channels, which you can use independently from one another. Each channel can receive a name allowing you to identify its role in the system. You can thus program an automation system requiring several modules based only on the logical role of each function, rather than to have to link each function to a particular physical module.
Yoctopuce interface modules, such as the Yocto-Serial, serve to facilitate the use of third-party products which are not designed on a model as practical as Yoctopuce modules. For example, there are sensors performing very good measures but which unfortunately only have a basic interface through the serial port. To avoid having to manage by software asynchronous communications and the sensor proprietary protocol, you can configure our interface modules so that they takes charge of it in an autonomous way. They can then provide the same features as the other Yoctopuce sensors: providing at any time the latest measured value, recording the measures, without the main program having to explicitly question the sensor.
Connections
A Yoctopuce module connected by USB
By USB
All of our modules use the same type of USB interface. It's our own protocol, reusing the USB HID layer present in all the operating systems. The main advantage of this solution is that you don't need to install a driver to communicate with a Yoctopuce module, as the HID layer is always present. You only need to add our library, that we provide in source form, to your driving software for it to be able to directly talk to Yoctopuce modules.
The fact that our modules work in USB 1.1 Full speed using an HID protocol reduces the maximal transfer speed with our modules. But this limitation is not usually very restrictive for the type of module that we manufacture: you really don't need to communicate at 1.25Go/s to switch a relay or to read a temperature. This solution has however a great advantage compared to the numerous products based on a virtual serial port emulated on USB: each module can be identified and inventoried uniquely by its serial number, can be disconnected and reconnected at will on any USB port of a single machine without any impact on its identification. In short: no proliferation of virtual COM ports :-)
By network
There is a fourth family of Yoctopuce modules: the YoctoHubs. They are used to expand the use of Yoctopuce modules to be able to contact them through a network rather than by a USB cable. You can connect one, or more, module to a YoctoHub and the YoctoHub connects itself to the local network by Ethernet, by Wifi, or by GSM cellular network.
The YoctoHubs were designed with the same philosophy as the other Yoctopuce modules: they aren't Linux mini-computers, but simple network interfaces with a few parameters easy to configure and an unchangeable behavior. At the level of the interaction with the modules from the driving software, there is almost no difference between using a module connected by USB or on the local network. Calls to the programming library remain identical, you only have to provide the IP address or the name of the YoctoHub during initialization.
A Yoctopuce module connected to the network through a YoctoHub.
YoctoHubs do more than simply provide a network interface for Yoctopuce modules: they also provide a basic web interface to interact with the modules. But above all, they are able to post on a Cloud service, or on your own network, the measures taken by the modules connected to them, and this fully autonomously. We'll talk about this in another post of this series.
Tools to access the modules
Let's repeat it: Yoctopuce modules are chiefly designed to be used from your own software. For this, we provide our programming library in a dozen of distinct programming languages. With a few exceptions, all the libraries are at the same level and provide as much as possible the same features. In each library, you can find an example to use each Yoctopuce module.
You can configure all the Yoctopuce modules through a web interface. If you use a module through the network, it's the YoctoHub which provides this web interface. If you connected your module directly by USB, we provide the VirtualHub software which is the software equivalent of a YoctoHub. The VirtualHub is available for Windows, Linux, and OS X. Not only can you obtain the same web interface as that provided by a YoctoHub, but it also provides the same network features. When the VirtualHub is running, you can access it at the http://127.0.0.1:4444 address and start configuring your connected modules.
The web interface to configure the Yoctopuce modules
For your tests and your first configurations, you can also use our command line library. Interactively or with scripts, you can use this command interface to question the sensors and to configure them. Have a look at the online documentation for more details.
To be continued...
We'll continue this series with different typical examples of the use of our modules: measures, alarms, and so on. Don't hesitate to add a comment to this post if you want us to go deeper into a particular topic!
