GNSS tracking ability

[PTsen]

Hi,

I would like to know the maximum velocity that the TESEO LIV3F chip can still having a stable update rate. I'm currently doing localization using TESEO LIV3F, and it update the position very slow under 3m/s. Perhaps that's because there are some trees and buildings when I'm moving around , but even if I'm at open space (at least 20m away from the building), I am still not getting the position updated. Therefore, I would like to know the maximum velocity that can guarantee TESEO LIV3F to continuously update its position.

Thanks

[Francesco Virlinzi]

Ciao

> maximum velocity that the TESEO LIV3F chip

On the max Teseo-LIV3F has to be compliant with ITAR regulation which are:

• speed: 515 m/s
• altitude 18000 m

When both are true the Teseo-LIV3F will STOP providing the position.

In General Teseo-LIV3F has a global max limits which are:

• speed 600 m/s
• altitude 100000  m

> it update the position very slow under 3m/s

under a specific threshold Teseo-LIV3F decreases the Fix rate.

To avoid that you can enable the 'pedestrian mode':

De-assert bit-15 in CDB-ID-200

Hope this helps.

Regards

Francesco

[PTsen]

Hi, thanks for your reply, it turns out that there are some conflicts in pin usage with my own extension board and X-NUCLEO-GNSS1A1, so I think that is the reason why GNSS kept giving me invalid data ('V' in GPGLL) even in open space.

BTW, regarding the pedestrian mode, is this the correct syntax ?

$PSTMSETPAR,1200,32768,1*3d 

I'm not pretty sure about it, despite the response says set par ok, but I'm not sure if the syntax is correct, or I'm just ruin all the settings in CDB 200.

[Francesco Virlinzi · Accepted solution]

Ciao

> some conflicts in pin

Which conflict do you have?

X-Nucleo-GNSS1A1 has several jumper to route the signals on different pins.

>  so I think that is the reason why GNSS kept giving me invalid data ('V' in GPGLL) even in open space.

No. this should not happen.

Between "Antenna->RP_path->LIV3F" there is No pin dependency.

Do you see satellites?

> $PSTMSETPAR,1200,32768,1*3d 

It's almost correct but you should disable the stop-mode, the correct command is:

$PSTMSETPAR,1200,32768,2*3d 

take into account that the change will take effect after a reboot thefore you have to save on flash and reset.

The complete script is:

$PSTMSETPAR,1200,32768,2	change the CDB
$PSTMSAVEPAR                save on flash
$PSTMSRR                    reset

[PTsen]

Hi, the conflict pin problem is due to the jumper for I2C, the manual do say that if not used, it should be floating, however, since I'm using CAN bus with it, so it is not floating as long as the can bus us functioning properly. This bug takes me about three or four days to find it, cause the can bus actually will not function if it senses error happening on the other side, so it sometimes work, but sometimes doesn't. Anyway, the problem is resolved by taking away the two jumpers associated with I2C.

I do see satellite, for reference, I use two X-Nucleo-GNSS1A1, one on the vehicle (with CAN bus and all other stuff, as mentioned) and the other not, both of them have the antenna at the same place. The one that is not on the vehicle always give me valid data, whereas the one on the vehicle doesn't (as soon as the CAN bus is functioning).

Last but not least, I suddenly remember that config message list has similar syntax, both the commands need to write to 32 bit data. The problem is that, for config msg list, I use the following syntax.

$PSTMCFGMSGL,0, 1,100000,0*7D

And I'm sure that this worked, since only GPGLL is shown in msg list. So isn't the syntax of CDB 200 be like

$PSTMSETPAR,1200,100000000000000,2

or both will work?

Thankyou very much for your patience. :D

[Francesco Virlinzi]

Hi

On I2C vs CAN bus issue... I think the only solution possible is removing the jumper you already did.

On "$PSTMSETPAR" vs "$PSTMCFGMSGL" question.

The $STMSETPAR is a generic command which can be used an all CDB-ID.

The syntax is:

$PSTMSETPAR,<ConfigBlock><ID>,<param_value>[,<mode>]

mode can be:

0: CDB-ID = <param>
1:  CDB-ID = CDB-ID | <param>
2:  CDB-ID = CDB-ID & !<param>

said that to simplify common operation we introduced the "$PSTMCFG" commands which work on specific CDB.

The syntax of $PSTMCFG command is command dependent.. they are not generic like $PSTMSETVAR

Therefore to change the message list at the end you can use:

• $PSTMCFGMSGL
• $PSTMSETVAR

Hope this helps

Regards

Francesco