COMMS.Drivers.GNSS

[AndronikosKostas]

Files

GNSS.hpp, GNSS.cpp GNSSDefinitions.hpp GNSSMessage.hpp

Most Recent Branch

comms-eqm-software repo at the branch gnss_eqm

Reports

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

Chore Tasks

• [x] Integrate the GNSS drivers on the new repo

Data Handling

• [ ] Address the scenario where data processing takes longer than the incoming data rate from the GNSS (potential solutions : two buffers, semaphores
• [x] See how many bytes are coming from the GNSS Answer: 460 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 to run only if there are data to process Note: You could lose some packets if the processing is very slow
• [ ] measure the processing time to see if you are losing data (this must be done when the parser is ready) 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

  4. configureInterferenceDetection(InterferenceDetectControl control, Attributes attributes) along with queryInterferenceDetectionStatus(). This could be useful to assess the validity of the GNSS data.
  5. configureMessageType(ConfigurationType type, Attributes attributes). We want NMEA format (I think it is the default but we should double check it).
  6. configureGNSSNavigationMode(NavigationMode mode, Attributes attributes). Maybe we will need Airborne.
  7. configureSystemPositionRate(uint8_t rate, Attributes attributes). This could be useful for the velocity calculation issue.
  8. query1PPSTiming() Again may be useful for the validity of the GNSS data.

     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<uint8_t>(type));
payload.push_back(static_cast<uint8_t>(attributes));
return GNSSMessage{GNSSMessagesID::ConfigureNMEATalkerID, static_cast<uint16_t>(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

1. • [ ] Read ACK which will indicate that the change has been successfully applied to the module.
2. • [ ] Read ACK which will indicate that the change has been successfully applied to the module.
3. • [ ] Read ACK which will indicate that the change has been successfully applied to the module.
4. This is a message with Sub-ID so maybe the GNSSMessage constructors (file GNSSMessage.hpp) don't work with that.
   • [ ] Read ACK which will indicate that the change has been successfully applied to the module.
   • [ ] Find a way to work with this message
5. • [ ] Read ACK which will indicate that the change has been successfully applied to the module.
   • [ ] Read ACK which will indicate that the change has been successfully applied to the module.

Error Reporting and Error Handling

• What happens if you want to send a command to GNSS and it does not respond with ACK
• What happens when queryInterferenceDetectionStatus() returns true or something like that
• When you know that GNSS is not working as it should be, you should discard its data. Note: The parser could help with that...So by having the variables, you should have a check on them to decide if you can trust them or not. For example, if you get the year 1980 while we have 2024 and in orbit 2025 you know that is incorrect.

  Other

• [ ] See what to do with vectors
• [ ] Make a backup file with all the functions of GNSS and keep in the current file only the functions that are needed (the tested and the should test)
• [ ] A parser for translating NMEA messages to float variables https://github.com/kosma/minmea
• [ ] Latitude, longitude, altitude to cartesian coordinates
• [ ] Velocity algorithm
• [ ] Check which variables we will use eventually and then try to store them on eMMC.

[AndronikosKostas]

There is no need for UART5 global IT to be enabled

Tested on the old comms-eqm-software.

Findings regarding ITs set up on CubeMX

In the FreeRTOSConfig.h file we have the following defines #define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 15 #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5 So any interrupt service routine (ISR) that has a priority greater than 5 (like 0, 1, 2, 3, or 4) should avoid calling FreeRTOS functions directly. Doing so could lead to unpredictable behaviour, as higher-priority ISRs could disrupt the operation of the FreeRTOS kernel. For example if you set an interrupt in CubeMX having a value of 1 is wrong and could disrupt the operation of FreeRTOS kernel. Another observation was that in the old comms-eqm-software that was tested on CSF the PendSV IT was set to 15 which is the lowest priority and it is not recommended. Note: The Pendable Request for System Service (PendSV) is a crucial part of the ARM Cortex-M architecture that enables efficient context switching in real-time operating systems like FreeRTOS.

[AndronikosKostas]

Update: The issue was not the FreeRTOS but the CubeMX configuration (Enable TX and RX swapping)

[AndronikosKostas]

Size investigation

When I am using the following HAL_UARTEx_ReceiveToIdle_DMA(&huart5, gnssTask->incomingMessage, 5000); So the callback is called when the buffer is full and half-full...so the IDLE might not work properly

Also after each receive you have to run again the following __HAL_DMA_DISABLE_IT(&hdma_uart5_rx, DMA_IT_HT); This will cause the IT to be called each when the buffer is full

The IDLE only triggers when UART global interrupt is enabled... If you are using DMA on circular mode you are getting something like: while in normal mode: which seems constant at 460 bytes

CHECK this : e3896a813787f02cdf4b05b77fc9ce72c9dbf8f4