Next Steps

Now that I have presented my research in rochester it is time to move on to the next few steps of the project. The current relay board is not properly functioning. Dr. Hassel has bought two new boards and I will need to replace them. We will also proceed to collect data and try to further develop an observation technique. Lastly, I will need to pass on the knowledge I have acquired and skills developed to either Dr. Hassel, another student, or both so that we can continue to use VIPER. This will involve operating the motor controls, understanding and troubleshooting the code, relays, etc, and taking measurements. I can do this personally or I can write an operations manual.

How To Test a Relay

In order to check if a relay is functioning properly all you need is a voltmeter and a way to activate the relay. Change the setting on the voltmeter to resistance. Check the resistance between the COM and NC pins as well as between the COM and NO pins. Do this when the relay is turned off and turned on. The relay is working properly if when it is off the resistance between COM and NC is very small and the resistance between COM and NO is very large (nearly infinite; the voltmeter should read 0L). Similarly, when it is activated, the resistance between COM and NO should be small and the resistance between COM and NC should be large. If this is not the case, then your relay is not working properly.

Fixed The Motors

I have identified that the problem with the motors originated from a bad relay. The V- relay was not working properly and so I had switched the wires to a functioning relay and adjusted the pins in the motor control code. Now the motors are working as intended again.

Troubleshooting The Motors

After removing the top motor from VIPER,I tried to troubleshoot why the motor no longer functioned. The problem does not appear to be with the motor itself. There was no water inside of it and all the wiring seems to be intact. The brakes are also operational because we can hear the click that signifies that they are disengaged and we are able to move the motor by hand.

The problem also does not appear to be with the power supply as we measured the output with a voltmeter and the measurement checked out.

The angle encoder appears to be fine as well. I had originally thought that there may have been something wrong with the wire that connects the angle encoder to the relays was malfunctioning because when you shook the wire while the angle encoder was not attached, the counts would increase. However, while the encoder was attached this problem did not persist.

To ensure that there were no problems with the code or that I accidentally changed some parameters, I redownloaded the original code that I had used when we successfully moved the motors the first time.

This leads me to believe that the problem lies with the relays because it is the only aspect left unchecked and I measured the voltage at the leads where the motors connect to the relays and there was no output.

Moving VIPER

Using the instructions included with Jon's simulink code, I was able to operate a small motor. The motor was unable to handle the power of the power supply used and it fried very quickly after using it.

Afterwards I used the same instructions on the VIPER motors with some mixed results. Overall the motors functioned but not to full expectations. The top motor often stopped moving partway through its intended distance. The motors also oscillated around the desired angle until fully coming to a stop. A few days later I tried to operate the motors again with no success. The motors failed to move at all.

Issues with Linux

This week I have been troubleshooting the simulink code. There were several errors regarding missing files that I was able to fix by creating my own with the proper text. After all of these issues were resolved I encountered another error that I was unable to resolve on my own. I had a conference call with Jonathan Farrell who was unable to recreate the error on his computer which ran Mac OS. I tested the simulink on a mac provided by Dr. McColgan and the program ran without any issues.
I have also contacted tech support from MathWorks and tried to troubleshoot the problem with them to no success. I am currently awaiting further feedback from them.

Currently the plan is to employ the simulink on a windows or mac and use the SRT software on the linux. I will test out the program on a smaller motor this week.

Familiarizing myself with the motor controls

I have been reviewing the code that Jonathon Farrell developed in the summer of 2016. Here is a picture of the simulink code from Jon's blog:



A basic understanding of angle encoders is necessary to understand this code. You can find this here: http://henrysbench.capnfatz.com/henrys-bench/arduino-sensors-and-input/keyes-ky-040-arduino-rotary-encoder-user-manual/

The basic idea is that there are two switches within the angle encoder each with different phases and the code identifies where the switches are and determines which direction the encoder is moving by the change in the two switches, Then, based on the desired input, the code determines the difference in the current angle and the desired angle and tells the motor to move in the correct direction and how far. The code has various outputs so you can observe in real time which direction and what angle the motor is at.

The MatLab code appears to only measure the angle encoder and does not control the motors as is the case with the simulink code. However, I have been unsuccessful thus far in connecting the arduino to simulink. I have been able to connect it to MatLab however and hopefully there are only minor discrepancies in the process.

Based on what Jon has left for me, it should be as simple as connecting the arduino to a laptop with the code, entering a desired angle, and running the program. I aim to test this with a small motor this week.

Once this is complete I can move onto the larger motors for VIPER. However, there have been changes to the control system that I had developed in the summer of 2015 and I will need to relearn how to use it. Once I can confidently power the motors I will attempt to use the motor controlling program with them.

New Clalibration Data

This week I performed the same calibration technique as the last time with a few precautions. I timed the measurements to make sure that there was a roughly equal number of data points in each. I also made sure that nothing else passed through the view of the receiver during measurements. This new data set is more consistent but has an outlier. The plots show that there is no correlation between signal strength and angular orientation of the calibrator. This set also indicates that the 100cm measurements had a stronger signal. This might be caused by interference with the receiver that occurs when the calibrator is placed too close. 

The outlier is the 180 degree, 100cm measurement. The other measurements have signals within the same range between 0 and 50Hz which is reasonably precise. Yet the 180 degree, 100cm measurement still follows the trend that the 100cm measurements have stronger signals. 

In the coming days I will meet up with Dr. Hassel to further interpret the plots. I will also begin to familiarize myself with the arduino that Jonathon Farrell had created during the summer of 2016. His blog, detailing the setup, can be found here: http://sienaviper2016.blogspot.com/

Once I am competent in implementing the motor controls on a smaller motor I will move on to the motors for VIPER.

Calibration Data

During the Fall semester of 2016, I began developing a calibration technique for the telescope's receiver. Using a calibrator that emits a radio signal, I took 12 measurements of varying angles and distances while toggling the power to the calibrator.

This week I took the data and plotted it. I compared the measurements of corresponding angles to see the relationship between signal strength and distance from the receiver. The following plots represent the difference in signal from when the calibrator is turned on and when it is turned off. The specific parameters of the measurements are indicated in the title.

                             

The data seems to be fairly inconsistent. When comparing the signal of similar angles but different distances, The 180 and 90 degree measurements indicate that the closer the calibrator is, the stronger the signal. This is intuitive and makes sense. However, the 45 degree measurement indicates the opposite and thus the data is inconsistent. This could be due to a small data set as well as not taking careful enough measurements. There were people coming in and out of the room who would walk in the view of the receiver and this could easily cause problems. In addition there does not seem to be any correlation with the signal strength and the angle. I plan to retake the measurements more carefully and try to find a pattern that will enable us to discover the best method for calibration.

Connecting the Arduino to MatLab

During the the Fall semester of 2016, I primarily focused on operating the arduino software to electronically control the motors of Viper. There were many challenges with getting MatLab to recognize the arduino. The primary problem was that Linux identifies ports differently than mac or pc and so I had to take a few extra steps to connect MatLab with an arduino. Following the instructions from the following websites successfully established a symbolic link that MatLab could recognize:
http://www.matlabarduino.org/serial-communication.html

http://www.howtogeek.com/199687/how-to-quickly-create-a-text-file-using-the-command-line-in-linux/

https://www.mathworks.com/help/supportpkg/arduinoio/ug/find-arduino-port-on-windows-mac-and-linux.html?requestedDomain=www.mathworks.com

Project Abstract

The VIPER telescope was donated to Siena College and has been a work in progress for a few years now. VIPER is a radio telescope with two focal points. The primary dish refocuses the incoming radio waves to a secondary mirror which focuses the light to a fixed point on the telescope. During the summer of 2015, I worked on VIPER and mounted a signal receiver to the secondary focal point. The primary goal of this project is to reverse engineer the software that came along with the receiver in order to allow further improvements and customization of VIPER. As of right now the receiver can detect radio waves that have a wavelength of 22 cm. If we can understand and change the code, we can then alter the receiver so that it can detect other wavelengths and conduct various observations without being limited to specific sources. The secondary goal is to actually obtain a measurement with the receiver. The plotting software produces three different plots. One is power vs time, one is instantaneous power vs frequency, and the last is average power vs frequency. The sun is a source of 22cm light, however it is a continuous source as opposed to a discrete source. This causes the plot of the spectrum to increase continuously and in turn skews the plot of the average power vs frequency. We would like to observe a discrete source because the plot will remain constant and enable us to properly calibrate the receiver. I built a calibrating device during the same summer and it will be crucial to develop and implement a calibration technique for the receiver to ensure accurate data. A team at Union College has also built the same type of receiver and cross analysis of data can help in confirming that the VIPER telescope is at optimal functionality.