I believe there is a bug in the processing of GPZDA Messsage if the time is not present.
I am communicating with a UBLOX NEO-M8 module and asking for GPZDA messages from it. At a certain point the first "time fix" message changes from something like
$GPZDA,,,,,00,00*48
to
$GPZDA,124243.19,,,,00,00*6C
before finally, something like a full message;
$GPZDA,142504.00,28,03,2020,00,00*68
In both of the part completed messages, the m_fix.valid_date flag is set to true, but only in the case of the last two messages does the m_fix.valid.time flag get set to true.
Going by the logic of the m_fix.valid_time flag I would therefore have expected the m_fix.valid_date flag to be set to false if any or all of the date fields are invalid or missing. i.e. in the case where there is a time present, but the date is just empty fields.
I believe there is a bug in the processing of GPZDA Messsage if the time is not present.
I am communicating with a UBLOX NEO-M8 module and asking for GPZDA messages from it. At a certain point the first "time fix" message changes from something like
to
before finally, something like a full message;
In both of the part completed messages, the m_fix.valid_date flag is set to true, but only in the case of the last two messages does the m_fix.valid.time flag get set to true.
Going by the logic of the m_fix.valid_time flag I would therefore have expected the m_fix.valid_date flag to be set to false if any or all of the date fields are invalid or missing. i.e. in the case where there is a time present, but the date is just empty fields.