From c5d937b42fc253ac06986d15d65e39aec68513e7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lu=C3=ADs=20Jesus?= Date: Fri, 26 Aug 2022 01:43:00 +0200 Subject: [PATCH] Eliminar 'members/luis-jesus/reports/sitrep1.md' --- members/luis-jesus/reports/sitrep1.md | 179 -------------------------- 1 file changed, 179 deletions(-) delete mode 100644 members/luis-jesus/reports/sitrep1.md diff --git a/members/luis-jesus/reports/sitrep1.md b/members/luis-jesus/reports/sitrep1.md deleted file mode 100644 index 29110d5..0000000 --- a/members/luis-jesus/reports/sitrep1.md +++ /dev/null @@ -1,179 +0,0 @@ -SOFTWARE ENGINEERING DEPARTMENT - -SITUATION REPORT 1 - -Rocket Logging System Architecture - -Luís Jesus - -August, 2022 - -Summary -======= - -The main purpose of this report is to develop the first plan of our -rocket's logging system in order to get a more detailed plan of the next -tasks that will be done. In this document, we will be talking about our -overall electronic architecture and some of the possible approaches that -we may want to implement in order to get the data from the sensors -chosen by the Electrical Engineering Department. - -Data will be received in two different ways: it will be stored in -comma-separated values (CSV) format in a persistent storage device, such -as a microSD card, and we'll also need to implement a "real-time\" -transmission of the data using both radio connection (main real-time -system) and 4G/5G broadband network. The viability of this last one is -still under analysis of the Electrical Engineering Team. - -Velocity, GPS, altitude, accelerometer, gyroscope and magnetometer are -the parameters that we want to save and transmit. - -Introduction -============ - -The Electrical Engineering Department was responsible for selecting the -most suitable components. We will be working with an ESP32 main board. -This microcontroller is not very energy demanding and has a quite good -configuration for the purpose we want it to. - -Along with this board, we'll have five main modules/sensors that will be -responsible for retrieving information to the ESP32. We will be using a -BMP280 barometer that communicates either through SPI or I2C, a BNO055 -IMU module communicating through I2C that integrates an accelerometer, a -gyroscope and a magnetometer, the Ultimate GPS Breakout v3, that will -also be responsible for velocity tracking and connects via UART and a -LoRa or XBee antenna module (yet to be decided). - -Backup Logging System (microSD card) -==================================== - -As mentioned in the introduction, we are planning to implement a -real-time transmission of the data acquired from the sensors. However, -radio waves are very prone to be reflected by the soil, at the -beggining, and there may be some interference caused by other factors -that we may not be able to predict very accurately. - -Considering this, we firstly have to think about a more reliable Logging -System that is going to be able to save all the important information in -a persistent storage device, so we can recover the data that was lost as -soon as we have the rocket "in hands\" again. - -The most reasonable way to do this is by implementing a microSD Card -Module in the circuit; it usually communicates via SPI communication -protocol (the electronic implementation of this module was not -considered by the Electrical Engineering Team; they must confirm if it -can be made considering all the other modules that will be connected). - -ESP32 allows us to use Arduino IDE(C/C++ languages). After some quick -research, I noticed that we will have to use SD.h and SPI.h libraries in -order to write to the SD card. Beyond these, all the sensors/modules we -will be using have their own libraries: Adafruit\_BMP280.h, -Adafruit\_BNO055.h and Adafruit\_GPS.h. - -It's not very easy to start trying those implementations without having -the components. I think it is important to begin by a very simple -Arduino IDE code (without considering possible optimizations) to -analyse, for example, how much time it takes to get the data from all -the sensors and write the string in the .csv file. The first approach -must be a loop that reads sensors' values at a fixed rate, builds a -(C-)string and writes it on the file. The frequency of reporting is -actually quite variable in different projects and I couldn't find a -consensus, but it would be interesting if we started testing at a rate -of 10 logs per second (100ms). The most amount of data per second, the -better, however, we have to pay attention to some details: SD.h library -automatically writes and updates the file of the SD card in chunks of -512 bytes (it has its own buffer). The buffer is written to the card -whenever .flush() or .close() is performed or when it actually gets -full. Writing in chunks is generally better because we won't need to -open and close the file every time we want to write (and this consumes a -considerable amount of time). Considering this, if we rely on the -library and the card controller to manage the timing of the physical -storage, we'll have new data being saved every time the buffer gets -totally filled, so, if we get sensors' information every 100ms, and if -each line of the file is about 50 bytes, we will have 10 logs being -effectively appended to the file every one second. Is this enough? - -Another way of doing this would be opening and closing the file in each -iteration, which means that any placement of data into the buffer, in -each iteration, would be successfully written. However, this can lead to -a bad performance and we don't want a big delay between all those -operations. It's a matter of testing and seeing which option is the -best. - -Maybe the best solution is the buffer approach. We need to test if the -native SD.h library 512 bytes buffer is reliable enough, otherwise, we -may want to work on our own buffer with a custom size, until we find the -best balance between writing speed and data safety. - -Logging Using Telecommunications -================================ - -The team is supposed to use a LoRa or a XBee antenna to send the exact -same data to the ground station. In order to implement this, we will -need to configure both the transmitter, to send data, and the receiver, -that will be on the ground station. - -We want this transmission of data to be as quick as possible because we -want to have live updates of the values we will be tracking. It would -probably be enough/satisfying if we could send a new csv string to the -ground station every 100ms as well. However, the velocity of -transmission will depend on the distance between the receiver and the -transmitter, which means that at a certain altitude we may face a big -decrease on the transmission of data, which is not desirable, but I -actually didn't find clear information about this and the Electrical -Engineering Team is still deciding the best antennas to use. With more -information and knowing the boundaries that assure us a stable and -constant transmission, it will be possible to decide a suitable -configuration. - -Those articles show a C implementation of communication between two -Arduino or ESP32 using Lora and its own library; they can be a good -start point. [ESP32 with LoRa using Arduino IDE -- Getting -Started](https://randomnerdtutorials.com/esp32-lora-rfm95-transceiver-arduino-ide) -and [Introduction to Lora -- Send data between two Arduino using -Lora](https://www.electronics-lab.com/project/introduction-lora-send-data-two-arduino-using-lora/). - -Veredict -======== - -We need to test some basic implementations of Backup Logging System and -start benchmarking at different rates of data acquisition to check if -there's significant delay between reading from the sensors and writing -to the file, in order to have a stable logging system. This is very -important to make sure that the existing libraries satisfy our needs, -otherwise, we may need to compact libraries or improve an existing one -to get better results. - -When it comes to the telecommunications, it is still difficult to make a -deeper study of implementation. We can actually put two microcontrollers -communicating with each other but, apart from testing (which is very -important), there is still lack of information from other departments -such as the position of the antenna(s), if it is going to be a Lora or a -XBee, how strong the connection is gonna be and how it is going to vary, -etc. This is a crucial information as it simplifies our research on the -most suitable libraries and functionalities. - -Logging system will have to work flawlessly and coherently: we need to -make sure that the lag between the logs obtained by these two different -ways is minimal. This coherence and "parallelism\" between the Backup -Logging System and the Real-Time Logging System is a little bit hard to -predict without trying and testing. - -A research about 4G/5G broadband networking data transmission and its -implementation along with the other two would be interesting, but it's -still not decided if we're actually going to use this (it depends on the -decision of the Electrical Engineering Department). - -References -========== - -\[1\] Arduino Forum; - -\[2\] [Arduino Rocket Data -Logger](https://www.instructables.com/Arduino-Rocket-Data-Logger/). - -\[3\] [ESP32 with LoRa using Arduino IDE -- Getting -Started](https://randomnerdtutorials.com/esp32-lora-rfm95-transceiver-arduino-ide); - -\[4\] [Introduction to Lora -- Send data between two Arduino using -Lora](https://www.electronics-lab.com/project/introduction-lora-send-data-two-arduino-using-lora/);