Directional Antenna Alignment Control System

The goal of the project is to create a control system that can be used to automatically align a directional antenna mounted on a barge to an on-shore omnidirectional antenna. This system will use GPS coordinates of the bow and stern of the barge to determine the directional antenna's position as well as the coordinate of the on-shore antenna to determine the angle of alignment that the system will need to output.

=Problem Definition=

Background
The U.S Navy Acoustic Research Detachment has been conducting research on a barge in North Idaho and have been transmitting their recorded data from the barge to an on-shore omnidirectional antenna.



Their transmitting antenna is not automatically aligned to the receiving antenna on the shore. Thus, those on the barge must go up to the antenna and manually redirect it every time the barge moves to a new location. This wastes time and energy of personnel as well as delays research. Utilizing a control system that automatically aligns the transmitting antenna to the onshore antenna could significantly reduce waiting time. We will be creating a control system that will align the antenna within 30 seconds the moment the system is powered. Additionally, the system will have an on/off switch so that those on the barge will not have to go up to the antenna to power the system, further increasing the convenience of aligning the antenna. The precision of the antenna will also improve as the antenna adjustment will be a mechanical output of a calculated digital input position, which is more precise than the human eye.

Deliverables
The objective of this project is to create a working finalized product that can be mounted and implemented atop the barge. The system will also be configured to be a "plug-n-play" device and made so that maintenance and upkeep is fairly easy to conduct.

5. Cost Requirements
=Design=

Functional Process
Once the device has been powered on, the first step of our system's process will be receiving a RS232 serial communication from a GPS receiver. This receiver will send the GGA, HDT, and RMC GPS messages which will contain the longitude/latitude coordinate of the bow of the barge as well as the barge's True North heading. Once the message is received, a microcontroller calculates the position of the directional antenna and then, using the fixed coordinate of the on-shore antenna, determines the angle that the directional antenna would need to rotate (relative to the bow of the barge) to properly align itself to the on-shore antenna. One thing to note is that the microcontroller will adjust the angle of rotation based on what angle the antenna is currently at (again, relative to the bow) and is also calculated counter-clockwise.

Next, the microcontroller interfaces with a stepper motor to move the motor to the calculated angle position. The mounting rod of the directional antenna will be connected to the shaft of the stepper motor, therefore rotating itself as the motor turns. To ensure the stepper motor moved to the correct position this system will need to be closed loop. An encoder reading the movement of the stepper motor would satisfy this requirement. If the encoder finds that the motor did not move the appropriate amount, then a process will run until the motor is deemed in the correct position. With this closed loop process finished, the system will save the new angle to be used for comparison of the new calculated angle on the next iteration of the system's process. This process will run continually until the system is shutdown.

Design
The design for our device can be split up into three different subsystems: Housing, Power, and Control.

Housing


There are three aspects of the housing that are important to the final design.

The first is water resistance. The antenna will be mounted to the top of a barge on a lake, so exposure to the elements will be a threat to the electronics of our design. The housing must be able to keep water out from waves, storms, and high humidity. The acrylic tube is removable and in between is an o-ring to ensure a water-tight seal. There was space left in between many of the 3D-printed parts to ensure enough space for the pieces to fit together. These spaces were later filled with silicone to create a waterproof part. Testing of the water-tightness of the enclosure is explained in verification/issues.

The second is thermal management of the electronic components. The stepper motor and power relay will be creating varying levels of Joule heat (heat shed from electronics) based on the level of control at a given point. In order to make sure the electronics don't overheat, analysis and measurements will be taken to ensure the heat can dissipate before damage occurs. There will also be an issue of influx thermal radiation from the sun. The fan on the top of the cover provided convective cooling by drawing air through holes in the baseplate. This fan is solar powered, therefore as the sunlight becomes more intense, the heat flux will increase in the housing but the solar-powered fan spins faster in turn. This is an example of a natural control system. Testing of this cooling method is explained in verification/issues.

The third is a firm mounting to the hand railing of the barge. This is vital due to the nature of our control system. Calibration of our rotary encoder will be made to know what position it has to move to in order to point to the onshore antenna. If the mount that the rotary encoder sits on were to move, then this calibration would be off and it would point in the wrong direction, even though our control system would be working perfectly fine. Snowboard buckles and straps are used to fasten the 80/20 profile to the hand railing. This can be seen in the picture to the right. Using buckles/straps allows the user to mount/unmount the housing freely.

The clear cylinder that the antenna is visible through and the baseplate are acrylics while the top circular cover is HDPE plastic. The lower cylinder is 3D-printed PLA plastic. The mounting below is an aluminum 80/20 profile.

Verification/Issues
We conducted to tests to ensure our housing could protect the electronics from the elements:

1. Hot car test - Cooling with the fan​: We placed a thermometer in our housing in a car with direct sunlight. This test was conducted to ensure that the fan was able to keep the inside of the housing cool. ​Our results showed that we were able to maintain a temperature below 37.78 C (100 F). ​

2. Water pour test - Water-tight seal of cover​: We poured water over our enclosure with paper towels lining the bottom of the housing. This test was conducted to ensure that none of the electronics would be damaged from water getting into the housing.​ Our results showed that the water was not able to get into the housing and the paper towels stayed dry​.

There were two potential issues with the final prototype shown at the top of the page: 1. Difficult fit between the housing and O-ring holder​: Very snug fit between cover and O-ring hold makes it difficult to remove and put on cover quickly​. One would need to update CAD models and reprint 4 parts and see how they fit​. A solution could be increasing the inner diameter of the cover to make accessing the electronics easier​.

2. 3D filament susceptible to UV damage: Our selected filament (PLA) tends to degrade in direct sunlight. We remedied this by applying a UV-resistant acrylic coating. Another solution would be re-printing the parts with a more UV resistant filament.

Parts
The power supply system is made up of four components: a 5V AC-DC Power Rectifier/Supply, an ATXRaspi Power relay, a momentary control switch, and an XL6009 boost converter. This subsystem is responsible for controlling and supplying power to the system components, including the RaspberryPi and the stepper motor.

For the power supply itself, I selected a universal KFD 5V power supply. Initially when we were planning to use an Arduino Uno as the microcontroller for the control system, I opted for an 18W 9V power supply from Meanwell as that reflected the Arduino's input voltage requirement. I chose the former model for it's wide variety of applications, including the Raspberry Pi specifically. It also is intended for outdoor use if desired, and has a stout current rating of 4A needed for our power demands. The system components combined in total could consume 20W of power at maximum output, which is the maximum output of this power supply. Luckily our system will not be running at maximum output, and this power supply should sufficiently provide the ATXRaspi with enough power to run the Raspberry Pi and the stepper motor.

Originally I had planned to use a simple 9V relay with momentary switch to control power, however when switching our microcontroller to the Raspberry Pi I found a wider variety of power switching options available. I also realized later that my original design would require a latching switch rather than a momentary one, but we never came to that point before switching microcontrollers. The ATXRaspi was an easy decision for this project, as it is designed specifically for Raspberry Pi applications using a momentary switch. This relay takes in a 5V DC input utilizing a 2.1mm DC jack, and allows the user to power on, off, reboot, and force a shutdown using the pushbutton switch. The relay initiates these functions based on the users button press, displays its status using the LED, and communicates/controls the Raspberry Pi through two input/output signals and a provided shutdown script. The model we are using also includes a USB A output port, which allows us to use the preferred method of powering our Raspberry Pi, via USB C connection. The ATXRaspi also features an additional 5V output, which is used to activate the secondary relay, responsible for switching power to the stepper motor driver.

I selected a reliable momentary actuation ON/OFF switch, with a clear blue LED indicator to show the system is powered on. This switch is rugged and waterproof, and the built in LED can connect directly to the ATXRaspi LED status pins to reflect what the system is doing.

The Raspberry Pi is the maximum load that the ATXRaspi is designed to handle, so I decided to wire it and the stepper motor driver in parallel. This however would cause the driver to be on whenever our device is plugged in, which is undesirable. Consequently I implemented a 5V relay to switch power to the stepper driver. As stated before, this relay is activated by the additional 5V output on the ATXRaspi, and only draws 5mA of current away from the Raspberry Pi. The driver is connected on the positive line directly to the power supply via a boost converter, but the connection is only grounded once this secondary relay is activated upon powerup of the ATXRaspi.

Lastly I had to implement a boost converter to compensate for the input voltage discrepancies between the stepper motor, and the new CL57T stepper motor driver. While the motor itself only operates on 5V, the driver requires 24-48VDC. Since we were using the same motor/encoder, I retained the use of a simple variable boost converter takes the 5V input from the ATXRaspi and steps up the voltage input for the stepper motor driver. I chose the XL6009E1 because it has a hefty output current rating of 4A, which should be more than sufficient if powering our stepper motor, which is rated for a maximum of 2.5A at 5VDC. Reusing one of the extra heat sinks provided with the drivers will also ensure the converter does not overheat.

Below you can see further specifications on each part:

Circuit


The circuit diagram above shows the wiring schematic of the power system design, including how the five components will be connected together, as well as to the rest of the system. The diagram also includes arrows indicating power flow when the system is switched on using the momentary button. When the momentary button is pressed, power is drawn through the ATXRaspi and supplied to the Raspberry Pi. The boost converter is directly connected to the 5V source, but it is only grounded when the secondary relay is activated by the ATXRaspi. The ATXRaspi relay is controlled through the momentary switch, and system status is reflected by the switches LED. The ATXRaspi activates the secondary relay, allowing power to flow to the control system from the 5V rectifier. Upon power off, the ATXRaspi also executes a shutdown sequence in the control system code, ensuring the Raspberry Pi shuts down properly. The boost converter raises the rectified 5VDC to meet the driver’s voltage requirements.

Verification/Issues
Earlier in the second semester, we were able to get the ATXRaspi to properly control power to solely the Raspberry Pi, executing ON/OFF/RESET/SHUTDOWN commands. It was not until later we were able to test the design with the Raspberry Pi and the final driver we selected.

At that point the power system was assembled, but upon interfacing we found that the driver would not respond to PWM signals from the Raspberry Pi. We contacted the manufacturer for insight on this issue, and found that the driver itself had much higher power requirements than anticipated which were not covered in the datasheet. The driver itself requires 24-48VDC as specified, but the manufacture told us additionally that it required a minimum of 6A current, equating to a 216W power supply at 36V. We made this discovery with too little time left in our semester to address it in our design, but we recommend to future teams to provided the stepper motor with its own power supply of minimum 216W. This would also require a separate housing for this secondary power supply, as a power supply of that size would not fit in the current housing. Ideally this secondary housing would be positioned directly beneath the existing one, mounting to the aluminum rail that fixes the main housing to the barge handrail. This secondary supply could be connected to the driver in the same way as our design reflects through the 5V relay, which is rated for a 300W maximum load.

Plug and Play
There are also a few more steps to be taken in order to make this system a plug and play installation for the navy. This will include extending the power supply cable to a suitable length, and integrating port connectors into the housing. AC extension cables are common, and will allow us to transmit DC power over a very short distance and therefor minimize voltage drop to control system components. Sample images of these connectors can be seen below:

Port in/out connections will need to be completely waterproof, as these will be four of the few orifices in our housing, and will make or break our unit's environmental performance. A company called CNLinko manufactures several different series of high-quality industrial waterproof connectors, all rated with at least IP65 waterproof protection level for our application. We needed four different ports between power and communications, all of which were addressed by this companies products. The connectors are ported through the bottom baseplate of our housing. The table and figure below reflects the four connectors we used as well as their pin designations, and destinations.



Hardware
For the stepper motor, we elected to use STEPPERONLINE's Closed Loop NEMA 17 Bipolar Stepper Motor. This device is a combination of a stepper motor and a rotary encoder. The motor has a default step angle of 1.8° with a holding torque of 59Ncm (84oz.in). The resolution of the encoder is 1000CPR, which correlates to approximately a resolution of 1.44°.

We needed a motor driver to interface between the stepper motor and the microcontroller so we first opted to use the HitLetgo A4988 driver. Using this driver enabled us to determine how many steps the motor should move and in what direction (CW or CCW). This driver also allows for microstepping down to a sixteenth of a step, allowing for 0.1125° per step. However, though the driver could move the motor appropriately, reading the encoder from the microcontroller turned out to be unreliable after multiple tests revealed the encoder readings were not consistent. Inconsistent readings would lead to the high probability of step error which would ruin the whole control system process. Thus, we eventually found that STEPPERONLINE supplied a series of closed-loop motor drivers, and so we changed our motor driver to be STEPPERONLNINE's CL57T Closed-Loop Motor Driver. This device would not only be able to handle the encoder readings well but would also run the whole closed-loop aspect of the design itself and could also allow the motor to be microstepped down to 1/280th of a step (0.00703°). So, for our final design, we chose the CL57T driver to be our motor's driver.

When choosing a microcontroller, we initially decided upon the Arduino Uno Rev 3. We chose this device since it had a serial port to communicate with the GPS receiver, a supply voltage of 9 volts (which turned out to be the same as the supply voltage of the motor driver), there were plenty of digital pins for connecting to the motor driver and encoder, and we were familiar with the Arduino coding interface. Unfortunately, when trying to run tests for our angle calculation algorithm, we learned that the Arduino does not use float data types and therefore is very restricted on how many significant figures would be allowed. Since we were dealing with GPS messages that would have data points where there would be 9+ significant digits after the decimal, we needed a microcontroller that would work with such numbers. Thus, we ended up using the Raspberry Pi 4 Model B. This device was able to use the float data type and also already had libraries that allowed for interfacing between a stepper motor, an encoder, and utilizing serial communication. In addition, Raspberries use the Python coding language, which we were even more familiar with. One thing we did have to account for with using a Raspberry though was that it outputs logic lines at 3.3V when the motor driver requires at least 5V for a logic input. Thus we included Adafruit's 74AHCT125 Quad Level-Shifter to boost the logic lines from the Raspberry to 5V before entering the motor driver. In order to do this, we did need to utilize one of the Raspberry's 5V output pins.

Code
The code is the core of the whole project. Here, the process for reading the GPS signals, calculating the directional antenna angle, and controlling the stepper motor takes place. Below describes the process of the code.

After initializing the system, the first part of the process is to read in the GPS message. Here, the Raspberry will use its serial ports to read in the data. A while loop will run continually until a GPS message has been read. This ensures that the system will wait until the GPS message is read. Once it has been read, the GPS message is then parsed and the bow's GPS coordinate and the barge's true North heading are extracted and returned to the main function.

For the next step, the extracted GPS data and the set data coordinate of the on-shore antenna are called and are ran through a trigonometry algorithm that determines the angle the directional antenna needs to rotate. The angle will always be calculated relative to the bow of the barge and in the CCW direction. With the newly calculated angle, another angle is calculated by subtracting this angle from the current angle position of the antenna. This "current angle" is the angle that the antenna resulted in at the end of the previous iteration of the control process.

After this, the resulting angle from the subtraction is used to move the stepper motor. Before sending signals to the motor driver, the result angle and the GPS-calculated angle are used to determine what direction and how many steps the motor should move. It should be noted that if the result angle is less than 1 step of the motor (0.00703°) then the motor will not be called to move and the next iteration of the control system code will run. With the step and direction determined, the Raspberry will use a PWM line and a GPIO line to output the steps and direction to the motor driver, respectively. The motor driver will then take those signals, properly move the motor, and then ensure the motor did not lose steps through running its built-in encoder process. those steps are then outputted to the A4988, and the motor turns accordingly. Once the motor stops moving, the encoder is then read to determine the motor's position. Once this is completed, the GPS-calculated angle will be saved as the new "current angle", the current iteration of the code ends, and the next iteration begins. The code will run continuously until the system is powered off.

In addition to the main code, there is a script that is implemented into the Raspberry thanks to the ATXRaspi Switch Relay. The ATXRaspi has a GitHub script (seen in the additional files section) that is supposed to be put into the Raspberry that allows for a shutdown or reboot sequence to occur when the user initiates a shutdown or reboot through the momentary switch (see power section). We added a couple of lines in this script that should call the main code discussed above when the shutdown or reboot sequence has been executed. This is supposed to call upon the main code to execute its "reset" function. This reset function takes the current angle position of the antenna and interfaces with the motor to move to where the antenna would face the bow of the barge (i.e. 0°). This allows the system to always have a reference point to start from upon boot up.

Trigonometry Algorithm
The algorithm to calculate the angle of movement for the directional antenna is based on a series of trigonometric equations and different cases of the barge's position. Using the coordinates of the bow and true North heading, a line can be created running through the barge, from the bow to the stern. Similarly, a line can be drawn from the on-shore antenna to the directional one. The bow's GPS receiver is very close to the directional antenna, so the bow's coordinate will be treated as the directional antenna's. The angle going from the bow side of the barge reference line to the antenna reference line is the angle we want to determine. This angle will be calculated CCW relative to the bow. Next, we find the angles of the two reference lines, relative to the positive latitude axis, using the slope of the lines and the True North heading reading. The angle for the directional antenna is then found using one of the 3 different cases. The different cases are listed below. It should be noted that HDT is the True North Heading angle and θA is the angle between the latitude axis and the antenna reference line.

Verification
For verifying the control system, the main this to test was the code itself. The major test to perform for this was what we called the "12-hour" test. Using a secondary Raspberry Pi to send set GPS messages to the main Raspberry, the whole code process would run for 12 hours straight and the movement of the motor would be observed and measured to determine if the motor is moving correctly (based on the hand calculated angles that the set GPS messages should result in). Unfortunately, due to the powering issue with the CL57T motor driver (see Power section), we were unable to use and verify the motor portion of the control system and so instead the test saved the calculated angles (adjusted with the previously calculated angle and without) were saved to a .csv file. From the .csv file, we would check to see if the resulting angles matched up with the hand calculated ones.

Running this test we found that all of the angles saved to the .csv file matched the hand calculated angles. This proved that the GPS parsing, trigonometry algorithm and angle saving processes worked. Again, unfortunately we were unable to verify the motor portion of the code as well as the reset function.

One issue with the test that we did find, however, was that a serial decoding error would sometimes arise signifying that a bit in the serial message stream was unable to be decoded. We found a workaround for the test so that we could still be able to receive the GPS messages when the error was not flagged, but this does mean that there may be an issue in the serial communication. This could mean an issue with sending GPS messages from the secondary Raspberry, noise coming from the serial cable, or an issue with receiving the messages from the primary Raspberry. The noise is the most likely possibility since the cable was cut up and re-soldered a few times over the course of our project, but we recommend that in order to verify that the issue is not in the main Raspberry is to rerun this "12-hour" test with the Raspberry receiving messages from the actual GPS transceiver on the barge.

=Recommendations= 1. Consider a different 3D printer filament for printed housing parts

2. Use a stronger fan to ensure proper ventilation inside the housing

3. Use two separate power supplies for the Raspberry and the motor driver

4. Run AC lines from the outlet to power supplies enclosed in housing rather than extended DC lines.

=Team Members=

=Additional Documentation=

Project Schedule https://vandalsuidaho-my.sharepoint.com/:x:/r/personal/haen3244_vandals_uidaho_edu/Documents/Sea%20Scanners/Team%20Documents/Project%20Management/ProjectSchedule1.xlsx?d=w952118ef20874842ba3bb40f16c0369c&csf=1&web=1&e=ckltoy

Meeting Minutes https://vandalsuidaho-my.sharepoint.com/:f:/r/personal/haen3244_vandals_uidaho_edu/Documents/Sea%20Scanners/Team%20Documents/Project%20Management/Instructor%20Meeting%20Documents?csf=1&web=1&e=3YySU6

Presentations https://vandalsuidaho-my.sharepoint.com/:f:/r/personal/haen3244_vandals_uidaho_edu/Documents/Sea%20Scanners/Team%20Documents/Project%20Learning?csf=1&web=1&e=trB1rK