GNSS Drivers

[AndronikosKostas]

Files

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

Most Recent Branch

comms-eqm-software repo at the branch gnss_eqm

Reports

PeakSat/comms-eqm-software#10
PeakSat/comms-eqm-software#11
PeakSat/comms-eqm-software#13

Chore Tasks

• Integrate the GNSS drivers on the new repo
• Make a backup file with all the functions of GNSS and keep in the current file only the functions that are needed (just mark the tested functions)

Data Handling

• 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.
• Implement a data size filter to distinguish the nominal message containing satellite data from the GNSS command response.
• See how many bytes are coming from the GNSS
  Answer: 460 bytes
• 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);
• 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
• 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

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 powerSave mode (or we can even close it with the mosfet)

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

• 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.

• 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.

• Read ACK which will indicate that the change has been successfully applied to the module. Not getting ACK but the message is correct

• 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.

Feature Tasks

• Write a function that controls the GNSS in a more sophisticated way...waits for ACK.
• 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)

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 (this is not an issue...vectors have a maximum size at compile time)
• A parser for translating NMEA messages to float variables https://github.com/kosma/minmea
• 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 : e3896a8

[AndronikosKostas]

Successfully changed the system position rate to 2Hz

[AndronikosKostas]

Function that control GNSS and waits for ACK