Project Evaluation

1. Assessment of the responsiveness of the application in the context of the task/environment.

The response of the application was smooth. Test the mouse event from the Main-GUI to the rotator-GUI via the sockets and to the stepper motor drivers with no noticable delay. This can be seen here Video to the test

2. Overall latency permitted between physical event and output (control output or display of data).

The latency was almost unrecognizable. it was approximately 10-25ms during the servo motor testing as it was measure using timers at the start of the code execution and the driving of the stepper motors. It is worth noting that the latency increases as the network connection, distance and network load increases in the system.

3. What deadlines need to be met?

we put 4 major deadlines:

• Preparation for the presentation.
• Check what we achieved.
• Finished the PCB design along with ordering the component.
• Review everything and test Qt. More details can be seen from here

4. What is the sampling rate?

The sampling rate comes from the polling rate of the mouse that the user uses to control the rotor. In this case, it has a polling rate of 500 Hz (2ms)

5. Buffering of data: how many samples?

We didn't need to do any buffer for the data since we do not perform extensive processing on the manual control data. However, on another note, the GNURadio code that performs the DSP on the received signal required buffering and this was done internally by the graphical program with dynamic ring buffer size.

6. How does the buffering impact on the realtime performance and how much latency is introduced?

Since there was no buffering used, therefore, the latency was hardly recognizable.

7. Postprocessing of data and how that introduces latencies/processor load?

There was no postprocessing of data for the control. The only processing done was for the conversion of the mouse positions in the x-axis and inverted y-axis into shifted polar coordinates for the angles using vectors and trigonometry. This produced very little to no latency.

8. How many channels?

We used ports for the socket connections for communicating between a main system and the raspberry pi rotator

9. What bus protocol should be used (I2C, SPI, ...) and why?

Used sockets for information exchange and plan to use I2C for an IMU in the future.

10. ** Low-level implementation: kernel or userspace and why?**

We used both Kernel and userspace. Most of the code and usage is in userspace and only some few threads are run in the kernal space. This is to avoid messing with the memory in the kernal space. Only time critical code was used in the kernal space.

11. Data flow from hardware to GUI to output with data formats, latencies, processing and conversions.

Unfortanlty due to the COVID-19 we couldn't finish the hardware and test it with GUI. The data format mostly used is QString and a little of int and float for calculations.

12. How many threads are needed and/or how can the load be distributed to allow a responsive application?

Used threads in the sockets and the automatic time keeping for when the rotor is supposed to track the scheduled satellite. This takes the load off the GUI and allows for slightly faster GUI refresh rate.

13. How to implement the GUI? Permitted refresh rate and latency resulted from it.

The application was completely built with GUI. The refresh rate was low but sufficient enough for the application and within tolerances of the rotor control itself.

14. Structure of the software in classes, associated unit tests to turn it into reliable software

The software was fully structured with classes and test. Although, the tests are not enough and cannot be certain that the software is fully reliable for long term. We will continue to work on it. More information can be seen here

15. Team structure: which roles in a team of 3 and how equal contributions are guaranteed?

• Ahmad Muhammad: Worked mostly on the software side and Telecom of the project

• Mohamed Salih: Worked mostly on the mechanical side of the project and social media management
• Mohamed Abdallah: Worked on the Electrical/Electronics side of the project and the component acquisition More can be found here 👉 Team

16. How much time is allocated to hard, software and debugging and how is this interleaved?

For the hardware we spent 3 weeks to finish it and resolving every problem with it. Software was a continues build process for all team members and the mechanical and telecom was given just a week. More info on that here

17. Which version control software is used? How are releases/milestones done and numbered?

Git version control was used and github used for remote collaboration between team members. Release and milestones were used in tandem with the kanban project management github provides and issue tracking. See here 👉 Project management, Github Projects, Release & Milestones and issues for more info

18. What is the release strategy/publication/publicity? How is that measured and deemed to be successful?

The release strategy was posting progress and teasing demos on Twitter and Facebook at the beginning and the plan was to make 2 posts per/day to get audience attention every day and that will make them have more interest on the project. Days to the final deadline is to announce a release announcement and finally release the product on the last day. More upgrades will come afterwards.

19. Would users of social media or general users would like it and share it?

yes, because its the human nature to like and share an interesting idea and everything that has a relation to space. This can be observed from the rapid growth in user following on our social media pages.

20. Measurement of success of the application in the context of the problem given and evaluation of it.

The task was to control or have a project that processes data in real time. This application was able to not only control rotator in realtime, but als smart enough for scheduling automatic tracking, receiving information from satellite performing DSP on the signal.

21. Originality of the project, impact, usefulness and able to demonstrate realtime performance.

The base idea is not 100% original but this flavour and features such as as the contol application, the incoperation of telecom system and making everything off grid portable was original (as far as we know). some of the usefullness are:

• Can be used to track fast moving satellites. Especially those in LEO with short fly by times.
• Solar panel can be mounted to track the sun and increase its efficiency
• Can be used as a teaching aid for young students about satellite technologies
• Telescope can be mounted on it and used to track a celestrial body in the sky
• Tracking the ISS and the activities on-board becomes possible
• When Starlink becomes fully operational, SatRot could be used to gain internet access anywhere in the world.

Demonstrations and other videos can be seen on our youtube page right here