Signal-to-Noise of an A/D Converter

How do you know if the resolution of your signal is good enough if you have quantisation of your data? The quantisation could occur at an A/D converter or decreacing the resolution due to limeted bandwidth at a CAN bus. The performance parameter is called Signal-to-Noise-Ratio (SNR)

A system with analog-to-digital conversion consists of two steps; sampling and quantisation. Quantisation is the process of approximating each sample of the sequence with a digital truncated word. Often it is useful to know what the Signal-to-Noise Ratio of an A/D Converter.
The SNR is defined as





and the noise


The signal and the noise is assumed to be zero mean signals. If the noise is assumed to have a uniform distribution, then






SNR=20 \log \sigma_x +4.77+6.02 B

where B is the number of bits.

Two obvious conclusion could be drawn from the equation; the signal should be scaled properly and higher number of bit in the A/D-converter is better.



The inverted-pendulum motorcycle

The Tesla motors new car Tesla model 3 has an incredible low Cd-value according to Elon Musk, 0.21, see drag. For a Battery Electric Vehicle the product of drag coefficient and area (CdA -value) is a very important parameter.

Another possibility to make the CdA value small is to decrease the total front area as Lit Motors C-1 vehicle.

The motorcycle like car has two wheels as a motorcycle and is unstable at low speeds. The vehicle self-balances with two counter rotating gyros by moving the gyros. However, the idea is not new for cars, see this video.

The vehicle, which will be defined as a motor cycle, will cost about $24000 and is allowed to split lanes and use the ”car pool lane” in San Francisco…

It has 10 kWh in battery size and the gyros hold another 1 kWh in kinetic energy and will act as Kinetic Energy Recovery System. The gyros does not need to operate at high vehicle velocities, where it is stable.
There seems to be an application for the inverted pendulum….


When simulating controller designs, the plant model used is often developed using the K.I.S.S. approach – Keep It Simple Stupid. A model should capture relevant phenomenon with as low level of detail as possible. The general idea is to verify controller behaviour against the plant model and to do the final tuning against an actual prototype. One of the reasons for using this approach is of course that in many cases the development time and costs of a very detailed and complexed model is not motivated, when considering the effects of minor dynamics on the overall results. Another may be that the software used when creating the controller is not designed to handle certain complex modelling. Let’s have a look at how to handle this lack of complexity!

Take Simulink as an example. While excellent for controller design, it is not intended for multibody system simulations when including flex in components, for CFD analysis etc. On the other hand, MBS specific software is often not intended for controller design, providing only basic functionality. Wouldn’t it be nice to do all controller design in Simulink, do all MBS modelling in a designated software, and simulated the controller against the MBS plant model? Enter co-simulation.

Co-simulation is a widely used expression for combining different software in one simulation. For most of our cases, Simulink would be running the controller model, while the MBS software would be running the plant model. The co-simulation interface ascertains that each model is iterated in synchronization and that inputs/outputs to each model is updated correctly, thus allowing the models to communicate. The models need only a quick adaption to the interface, defining what signals to send/receive from the other software.


As an application example, let’s use a pilot project developed by Combine Lund in collaboration with Altair, who develops the HyperWorks suite (containing MotionSolve in particular) for MBS modelling. In this pilot, the model is that of a wind turbine in the event of a power failure causing a grid loss.

If grid loss occurs, the turbine will experience a sudden drop in generator torque. Left uncontrolled, this would cause an uncontrolled increase in rotor velocity, possibly resulting in a severe crash. As a countermeasure, a mechanical brake force is applied while also pitching the blades, in an effort to stop the turbine. This emergency stop behaviour can be seen in the figure below.

Figure 1. Emergency stop behaviour.

Now, considering the blades of the turbine as rigid, applying maximum brake force immediately may seem reasonable – the turbine stops as fast as possible. However, when defining the blades as flexible bodies, it can be seen that the blade deflections caused by rotor torque oscillations exert high stress and shear forces on the blades and may cause unnecessary wear and possible breakage.

Figure 2. Outputs from plant model, rigid vs. flexible blades.
Figure 3. Stress in blades increase in the case of emergency stop using full brake force.

A better control strategy would thus be to control the rotor speed to standstill while keeping the deflections of the blade to a minimum. Replacing the constant brake force with a proportional controller, using rotor speed as process variable, better performance can be obtained. In the picture below, 3 different gains for the P controller has been evaluated, resulting in very different brake characteristics. While the controller P3 has the longest brake time, oscillations have decrease significantly and this controller can thus be considered as the most appropriate control. Of course, a P controller is a very simple control strategy but the benefit with using Simulink for controller design is that the strategy could very easily be replaced with a more complex one, for example a state feedback controller.

Figure 4. Comparison of different gains when using a proportional controller.

Co-simulation is a powerful tool to simulate systems containing several modelling domains. In the case of the wind turbine, a better control strategy can significantly decrease stresses in the blades. This allows the mechanical engineer to optimize the design of the blades, which reduces material costs, energy consumption etc. At the same time, the control systems engineer can test the controller against a plant model that captures more dynamics than what is normally possible, a plant model that is often already developed by the mechanical engineer and needs only a quick adaption to the interface. Isn’t that a win-win situation?