Evaluation Type: Evaluation Boards
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Lots of other angle sensors are available on the market.
What were the biggest problems encountered?: The Arduino library provided to interface the Arduino board with the motor was not working without a little change.
First contact with the product
The angle sensor and servomotor came in a nice and hard box. All the components were safely held in place in a foam mold. This packaging allowed everything to come without anything broken or damaged.
The first step was to set everything up by wiring together the Arduino, the RS-485 transceiver, the sensor communication board and the PC. A file was provided with all the instructions necessary. This made this first step pretty easy and doable by everyone, beginners included. As the sensor evaluation board comes with a software, a setup needed to be done on the PC. The Macom application is easy to find, quick to download and easy to setup. An automatic firmware checkup is done with the EVKT-MACOM board, the user has nothing to do.
For the servomotor, the software setup was not that easy. The Arduino library provided had compilations errors. Those errors were not hard to correct (if you are comfortable with C-language programming) but are a bit disappointing.
Understanding the test architecture
A diagram is given here to understand quickly the architecture used in this RoadTest. On the left side is the servomotor and the arduino that controls it. The purpose of those components is to provide an input to the angle sensor.
On the right, we can see the angle sensor. It is connected to the EVKT-MACOM board which samples the data from the sensor and sends it to the MACOM app on the PC.
With that in mind, we can now control the servomotor and analyze the data retrieved from the sensor.
Getting data from the sensor
With the Arduino code, I forced the servomotor to rotate at 1000 RPMs. On the MACOM app we can see a sawteeth-shaped signal corresponding to the angular position through time. This result was expected.
We can see on the picture bellow that the app shows three graphs, each one showing a variable through time : angular position, angle error and speed ripple. On the right of the window, some usefull variables are shown (the first one indicates the speed at 1000 RPMs which is correct).
The EVKT-MACOM board's sampling process can be configured through the app. The user can specify the sampling frequency and the amount of samples to be shown on the angular position graph. This functionnality allows the user to adjust the signal window to the rotation speed of the servomotor. For example, if your sampling frequency is too high, you will not be able to see a full period of your signal.
Through the MACOM app, it is also possible to read and write from and to the MA732 registers. This was super usefull to test the sensor's possibilities. However, it could be a great improvement to the MACOM app if this functionnality allowed the user to choose between a registers mode and a parameter mode. The latter allowing the user to read/write from/to a parameter. This could be easier to manipulate parameters that are split between two registers or parameters that do not occupy an entire register.
(There is an error concerning the registers in the MA732 datasheet. The table 9 lists the programming parameters and references other tables. Those references are not correct. For example, the FW parameter refers to table 17 but should refer table 18)
The two modes of the MACOM App
The MACOM application allows the user to choose between two operating modes : fast and slow.
The problem is that the angular position graph does not show the time units and the data plotted is not accurate at all. The figure on the right shows the result for a low speed (200 RPMs) and the data plotted is not a sawtooth signal at all. The fast mode provides the same graph (angle vs time) accurately. The slow mode is only good for knowing the angle when the input is steady (here, the servomotor). But the circular graph does this job, I do not think the angle vs time graph is relevant in this slow mode because as the name suggests, it is too slow to show reliable data. Either I did not understand something, or the only role of this graph is to confuse the user (feel free to let me know in the comments).
As we can see on the bottom of the MACOM GUI (for both modes), the user can at any moment change some of the sensor's parameters. This is a really great functionnality. The zero angle setting changes the angle reference but only on the MACOM app as I understood. I wonder why this setting does not change the angle reference inside the sensor's register directly, which would in my opinion be a better solution (this is still doable with the register read/write functionnality).
This sensor provides three different output modes : SPI, ABZ and PWM. The EVKT-MACOM board samples the data using the SPI output. I have tested the two other outputs using an oscilloscope.
The ABZ output provides incremental encoding. An entire revolution is divided in a configurable amount of sectors. A and B signals will output a pulse each time the sensor's input rotates from one sector. Every time the sensor's input makes an entire revolution, the Z signal outputs a pulse. A and B signals have a 90 degrees phase difference. By knowing which signal between the two outputed its pulse first, we can know if the rotation is clockwise or not.
The two figures above show the ABZ output for the same rotation speed but with 100 pulses per turn and 1000 pulses per turn. We can see that the frequencies are separated from a factor of 10. The period of the Z signal (Period 2) is 25ms in both cases, which shows that the RPMs are the same between the two.
In this configuration, the sensor outputs a square wave with a duty cycle proportionnal to the angle measured.
The first figure shows the PWM output with the servomotor steady at 61.7212 degrees (value on the MACOM app). The duty cycle measured is 17.27%. A formula given in the sensor's datasheet allows us to get the angle with the duty cycle, which gives 61.117 degrees.
The second figure shows in yellow the PWM output with the servomotor rotating. The purple signal is a low-passed version of the PWM output that shows the sawtooth signal produced by the rotation. The motor speed was 1000 RPMs. The signal's period should have been 60ms and we get here 59.6ms. This low-pass method is not accurate but was used as an illustration of the PWM output.
The sensor has a digital filter applied on its output. This is a low-pass filter and its purpose is to reduce the noise on the output. The two figures bellow show the MACOM application with the servomotor rotating at 1000 RPMs. On the first figure, the filter window is 51 long and on the other one, it is 187 long. As we can see, the resolution in bits (top right) is better when the window is longer and the the error graph shows less error when the window is long.
A second test has been made with the servomotor steady in order to see the noise on the measured angle. The results are showed on the figures bellow (top window length : 51, bottom window length : 187). We can clearly see that there is less noise with a larger window.
However, this comes with a little delay that can flatten quick transitions (not observable here). I wanted to measure some kind of impulse response to pinpoint the time spreading when the filter's window is long but I was not able to do it since the MACOM app does not provide a trigger capability (or I did not find it). I think this could be a great functionnality to add to the MACOM software : a user configurable trigger (maybe with speed or angle conditions).
When the sensor measures an angle of zero, it can happen that it reads alternatively 0.xx and 359.xx degrees because of the noise. If we look at the ABZ output in that case, we get what is showed in the next figure.
The A signal (yellow) does not indicate any pulse at all, which means the angle stays in the current sector (not moving much, depending on the pulse per turn parameter). But the Z signal (green) shows several random-spaced pulses that indicates the motor made a full revolution. This is normally impossible with a non-zero pulse per turn parameter (which is the case here). What is happening is that the noise causes alternative 0.xx and 359.xx degrees angle measures and the sensor indicates a full revolution when the angle goes from 359.xx to 0.xx degrees.
This is not properly a bug but it can be disturbing and could lead in issues in applications. I do not know exactly if other sensors have the same behaviour. It would be great to allow the user to choose if he wants this behaviour to be corrected through a register parameter or not (something like a Schmitt trigger on the Z signal).
Thanks to Monolithic Power Supply for this RoadTest. The kit was really fun to discover and the user's guide provided was clear. I hope this review was interesting to read. I will be happy to answer to you in private messages or in the comments (from MPS, someone that spotted a mistake in my review or someone that wants ask a question about what I did).
Interesting sensor. At what speed could you still get an accurate angle versus time plot in slow mode?
Hi, thank you.
For the slow mode, I understood its purpose was to observe the angle when the input is (nearly) steady. But in my opinion, the circular display does the job for steady input.
I agree with you for the fast mode since the time origin is always locked at a zero angle. It seems like there is a trigger but a hidden one. Letting the user configure it could be really cool.
Good review. Regarding your question about the slow mode, I think that mode has a similar view like the 'rolling mode' on an oscilloscope. 200 RPM is too fast for it, I reckon it is more for non-motor applications such as digital potentiometer, or for seeing shaft rotation limits or for zeroising for instance, merely for seeing activity, and that it is not frozen, so the time axis not having units against it becomes less important than just seeing a change (perhaps).
The fast mode has an almost triggered scope-like view, where it then performs calculations based on the triggered (i.e. sync'd) data/waveform.
That's how I see it anyway. The creators of the application may see it in a different way : )