Test - Debug Github Action

### Reports
https://github.com/PeakSat/comms-eqm-software/issues/16
https://github.com/PeakSat/comms-eqm-software/issues/10
https://github.com/PeakSat/comms-eqm-software/issues/11
https://github.com/PeakSat/comms-eqm-software/issues/13

### Main Tasks
- [x] Integrate the GNSS drivers on the new repo
- [x] Make a backup file with all the functions of GNSS and keep in the current file only the functions that are needed (or just mark the tested functions)
- [x] Use double buffers to avoid race conditions between ISR and the task and also to ensure data integrity or use two different queues one for the satellite data and one for the command response.
**Update:** we are using a large buffer that captures the UART data coming from the GNSS. Then there are two separate FIFOS along with two different events (one for the actual data and one for the response of the GNSS (ACK/NACK)) that are used for synchronisation of the ISR and the task to process the data when there are data to be processed (we pass to them pointers not the actual data). This works well even with 5Hz update of the ISR. However, it might be more efficient to use multiple buffers, each capable of holding the maximum size of a GNSS incoming message. This approach ensures that no messages are lost and eliminates the risk of a buffer being overwritten by GNSS data while it is still being processed. By using separate buffers, incoming data can be safely stored without interfering with ongoing processing. For that phase, we will not do that but maybe it is needed in the future.

- [ ] Implement a data size filter to distinguish the nominal message containing satellite data from the GNSS command response.
**Update:** If the size of the data equals to 9 or 10 then it is a response from the GNSS that carries ACK or NACK.
- [ ] See what to do with vectors (this is not an issue...vectors have a maximum size at compile time)
- [ ] See how many bytes are coming from the GNSS
**Answer:** 460 bytes but we have configured it to send only the RMC NMEA message which is around 100 bytes
- [x] Correct IDLE event detection
Answer: Global UART interrupt ON and disable of HT, TC interrupts after each call of ` HAL_UARTEx_ReceiveToIdle_DMA(&huart5, this->incomingMessage, 512);`
- [x] add notification logic in the rxEventCallback to have the GNSS task run only if there are data to process
Note: You could lose some packets if the processing is very slow
- [x] Measure the processing time to see if you are losing data
The printing of 460 bytes takes around 50ms
### Functions that are tested and working
1. `configureNMEATalkerID(TalkerIDType type, Attributes attributes`
2. `querySoftwareVersion(GNSSDefinitions::SoftwareType::SystemCode)`
3. `gnssReceiver.setFactoryDefaults()`
### Functions that we should check at GNSS.cpp
1. `configureInterferenceDetection(InterferenceDetectControl control, Attributes attributes)` along with `queryInterferenceDetectionStatus()`. This could be useful to assess the validity of the GNSS data.
2. `configureMessageType(ConfigurationType type, Attributes attributes)`. We want NMEA format (I think it is the default but we should double-check it).
3. `configureGNSSNavigationMode(NavigationMode mode, Attributes attributes)`. Maybe we will need `Airborne`.
4. `configureSystemPositionRate(uint8_t rate, Attributes attributes)`. This could be useful for the velocity calculation issue.
5. `query1PPSTiming()` Again may be useful for the validity of the GNSS data.
6. `configureNMEAStringInterval` useful for the nominal case of 2 or 5 min GNSS
7. `configureSystemPowerMode` You can enable the power-save mode (or we can even close it with the MOSFET)
8. `configureExtendedNMEAMessageInterval`: where you can choose which NMEA strings will be generated and how often (0-255 seconds)
#### Notes
For all of the above functions that need to be checked, you can check this function as a reference
`GNSSMessage GNSSReceiver::configureNMEATalkerID(TalkerIDType type, Attributes attributes) {`
`Payload payload;`
`payload.push_back(GNSSDefinitions::GNSSMessagesID::ConfigureNMEATalkerID);`
`payload.push_back(static_cast(type));`
`payload.push_back(static_cast(attributes));`
`return GNSSMessage{GNSSMessagesID::ConfigureNMEATalkerID, static_cast(payload.size()), payload};`
`}`

A simple workaround to check if you read ACK or NACK is the following
`for(uint16_t i = 0 ; i < dmaRxSize; i++){`
`if(rxDmaBuffer[i] == 132)`
`LOG_DEBUG << "NACK";`
`if(rxDmaBuffer[i] == 131)`
`LOG_DEBUG << "ACK";`
`}`

### Tasks for the above functions
- [x] Read ACK which will indicate that the change has been successfully applied to the module.
### Feature Tasks
- [x] Write a function that controls the GNSS in a more sophisticated way...waits for ACK.
**Update:** the function works fine. We used a combination of notifications and queues that transfer pointers that point to data so that we do not copy them.
- [x] Write a function that uses `configureNMEAStringInterval` but for multiple strings (this is very useful when we want the GNSS to send us messages every 2 or 4 min for example)
**Update:** This function whilst it returns ACK does not actually works always. Solution: just use always the `configureExtendedNMEAMessageInterval` along with the `configureSystemPositionRate` and you can achieve whatever combination you want)