I admit I know little about pulse width modulation, and have limited experience with robotics or servos. I’ve had a futaba s3003 servo in my toolbox for some time, and done nothing with it. On a lazy day when I had some down time, I decided to get it out and do some experimentation.
I’ve been doing some labor intensive projects at work lately, and while hard work is very rewarding, it takes a lot of physical and mental energy and crowds out innovation. Just out of boredom, I burned the most basic servo script example provided by the arduino IDE into a nano clone I recently bought, and analyzed it with pulseview to better understand pwm.
Above is a trace of the output of the default arduino ide servo script with me tuning a 10K pot. In this example script, the position of the servo corresponds to the position of the potentiometer. Just at a glance, you can see pulses bunched up at different intervals. What I empirically observed is that when the servo was at position 1, the pulse width was about 0.55ms in duration at the standard 50Hz required by the servo. This pulse was constant, and the servo was stationary. If the pulse width changes at all, it changes position proportionally.
The futaba s3003 has 180 degrees of rotation. At position 3 (180 degrees) the constant pulse width is about 2.4msec. as you can see in the graphic below:
This simple analysis has demystified pwm somewhat for me. Next, I hope to experiment with some pwm on the raspberry pi using perl.
Most everyone knows that unlike an arduino, the pi lacks an analog to digital converter. I normally use an MCP3004. These work ok for me most of the time, but I get a lot of readings that are outliers, and obviously not correct. I haven’t noticed this as much on the analog inputs on an arduino.
In this experiment (for an upcoming project) I essentially let an arduino nano clone read the voltage of a 6V lead acid battery that I was discharging with some low-value, high wattage resistors. The arduino read the voltage and printed it on it’s serial line at 9600 baud. The serial lines on the arduino were connected to the pi’s serial lines, and the pi recorded the readings by logging a screen session. First, you have to disable getty on the serial line, and then set up screen to log the session. sudo systemctl stop serial-getty@ttyAMA0.service sudo screen -L /dev/ttyAMA0 9600
I forgot to mention, that I used a 10K potentiometer as a voltage divider to step down the 6V so the arduino could read it.
I got a pretty good dataset with very little jitter and hardly any outliers. I think a pi and an ardino make a powerful combination. You can effectively extend all the arduino’s gpio’s, i2c, spi, etc. to the pi. You also have all the muscle and storage of the pi at your disposal for your projects.
I finally got around to deploying my rssi / temperature / relative humidity data logger and recorded nearly 6,000 samples of each metric over a five day period. This radio system operates in the ISM band, and is susceptible to propagation issues due to atmospheric conditions, especially humidity. The logic board provides a terminal that outputs a DC voltage that represents the rssi in dBm. My data logger uses a raspberry pi zero w, and reads the rssi voltage with an MCP3004 analog to digital converter using a bit-banged driver I wrote in perl. Each reading is timestamped using time derived from a DS3231 i2c real-time clock chip.
I use a HTU21 temperature / relative humidity sensor break out board from adafruit. This chip is MUCH MORE STABLE & RELIABLE than the DHT22 I was originally using.
For starters, here is the temperature in fahrenheit (red) vs. the relative humidity (green). Predictably, when the temperature rises, the relative humidity goes down and vice versa.
Now here is the relative humidity vs. the rssi. This radio is about 20 miles away from the transmitter over flat terrain with an output of 37dBm (5 watts), and has an average rssi of about -90dBm. You can see from the above graph that at about sample 4,000 when the relative humidity takes a noticeable dip that the rssi has a corresponding, albeit small, increase: precisely what we would expect to see.
Nothing surprising here. It just proves the effectiveness of my data logger device. It would be useful in situations where an RF path is going up and down due to atmospheric conditions or other obstructions, and real-time data would be useful in diagnosing problems and coming up with solutions like a higher gain antenna or increasing height.