TLW2-12B reporting "satellites":0,"valid":true

postnik0706

Hi, our TLW2-12B Topfly devices are reporting ,"satellites":0,"valid":true (full MQTT event can be found below). Could you please advise how (if) you are calculating that Valid attribute? Does Spec's Position message (0x250x250x13) byte 25 'Data and GNSS Status' have anything to do with the Valid attribute? We would want to distinguish real-time data with a fixed GPS reading from historical/last known position.
Would very much appreciate your response, this is a show stopper for us.

Here is an example of MQTT message we received during our testing:
flespi/state/gw/devices/XXXXXXX/telemetry/position {"altitude":0,"direction":0,"latitude":XX.XXXXX,"longitude":-XX.XXXXX,"satellites":0,"speed":0,"valid":true}

namo

Hello postnik0706 ,
I've added message.buffered.status parameter for Topfly devices, that comes from bit7 of 'Data and GNSS Status'.

As for the other bits of 'Data and GNSS Status': bit0-bit4 are registered into position.satellites parameter, and bit5 and bit6 are skipped at the moment.

And as for position.valid=true, you are right here, this parameter seems to be irrelevant, please rely on position.satellites value first. We will investigate and remove the invalid parameter.

Please, follow changelog of Topflytech protocol to be notified about the changes in protocol implementation.

postnik0706

Thanks!

postnik0706

Hello @namo, I do not see the 'message.buffered.status' coming with the position message (channels topic). Is it what you were referring to at changelog as 'For real-time messages parameter message.buffered.status is not registered.'?
How could I use that attribute if I rely on the channel message containing the position?

namo

postnik0706
Yes, message.buffered.status=true is registered only if bit7 of GNSS Status is 1, signifying that this is a black box message. The absence of message.buffered.status parameter means that this is a real time message.
This is applicable for Position Message (message types 0x02 and 0x13) and Alarm Message (message types 0x04 and 0x14) data packets, so yes, you may rely on this logic when analyzing channel messages with position in your code.

postnik0706

Thanks. One more question please - which parameter would you recommend to use for identifying an incoming message as being Position (0x02 and 0x13) or Alarm (0x04 and 0x14)?

namo

postnik0706
This is a good question.
To remove this ambiguity I've updated the protocol so that message.buffered.status parameter will be registered with either true or false value. In the other words, whenever raw packet contains Data and GNSS Status byte, the parsed message will contain message.buffered.status parameter showing whether this is a real time or black box message.
More details are here.