Teseo-LIV4F missing NMEA

[Joost123]

Unfortunately we experienced some serious issues with the Teseo-LIV4F regarding custom configurations on the CDB-ID 201 register.

While the issue with broken NMEA output seems resolved by disabling I2C (See other topic)

https://community.st.com/t5/gnss-positioning/teseo-liv4f-broken-nmea/m-p/886937#M1324

Another issue remains: Completely missing $GNGGA frame at 9600 baud, but only when the device has a fix.

Steps to reproduce:

1. Flash the latest firmware (4.6.8.5.11)
2. Disable I2C
3. Disable GSV, VTG, GST, GSA
4. Set Baudrate to 9600
5. Save settings and restart

Commands:

$PSTMSETPAR,1263,0x1,2
$PSTMSETPAR,1201,0x8001C,2
$PSTMSETPAR,1102,0x5
$PSTMSAVEPAR
$PSTMSRR

 
Connect to the device using 9600 baud, above should output RMC, GGA and GBS frames. At first this works, but as soon as a fix is reached the GGA frame is omitted: (Optionally send another $PSTMSRR to catch initial situation where GGA is still present)

$PSTMVER,FreeRTOS_V10.4.3_ARM*57
$PSTMVER,BINIMG_STA8041_4.6.8.5.11_ARM*34
$PSTMVER,SWCFG_86065331*62
$GPTXT,DEFAULT PVT CONFIGURATION*2A
$PSTMSWCONFIG,1,0,12,000005f005070a0a0e0d0c0b0a090608070203630e110404180c0155030000500fff000f0714000affffffffffffffffffffffffffffffffffffffffffffffff*49
$PSTMSWCONFIG,1,3,12,01323200050358020a0a0000fe03000010f08334d50300a42023c07e00000000000000005f5388402023c07e0000000000000000000000000000000012090000*1A
$PSTMSWCONFIG,1,6,12,0000e803ffffffff0610000080ba8c014810c703ffffffff9abed2e6edf2fafb0000020205060101ff00ff00ff00ff00ff000000ff00ff000000000000000000*4D
$PSTMSWCONFIG,1,9,12,00000000000024401d8f19a88c8f4440598b4f0130be2b4000000000000024407ac2120f289f44402315c616828c2b400000000000002440ace28dcc239f4440*11
$GNRMC,201639.338,V,,,,,,,190326,,,N,V*21
$GNGGA,201639.338,,,,,0,00,0.0,,M,,M,,*4F
$GNGBS,201639.338,,,,,,,,,*46
$GNRMC,201639.338,V,,,,,,,190326,,,N,V*21
$GNGGA,201639.338,,,,,0,00,0.0,,M,,M,,*4F
$GNGBS,201639.338,,,,,,,,,*46
$GNRMC,201640.038,V,,,,,,,190326,,,N,V*2C
$GNGGA,201640.038,,,,,0,00,0.0,,M,,M,,*42
$GNGBS,201640.038,,,,,,,,,*4B
$GNRMC,201641.018,V,,,,,,,190326,,,N,V*2F
$GNGGA,201641.018,,,,,0,00,0.0,,M,,M,,*41
$GNGBS,201641.018,,,,,,,,,*48
$GNRMC,201642.018,V,,,,,,,190326,,,N,V*2C
$GNGGA,201642.018,,,,,0,06,8.2,,M,,M,,*4E
$GNGBS,201642.018,,,,,,,,,*4B
$GNRMC,201643.018,A,****.*****,N,*****.*****,E,0.1,0.0,190326,,,A,C*10
$GNGBS,201643.018,7.4,5.1,7.1,,,,,,*65
$GNRMC,201644.020,A,****.*****,N,*****.*****,E,0.1,0.0,190326,,,A,C*19
$GNGBS,201644.020,7.9,5.8,7.7,,,,,,*6B
$GNRMC,201645.000,A,****.*****,N,*****.*****,E,0.0,0.0,190326,,,A,C*1F
$GNGBS,201645.000,7.7,5.8,7.7,,,,,,*66
$GNRMC,201645.979,A,****.*****,N,*****.*****,E,0.1,0.0,190326,,,A,C*16
$GNGBS,201645.979,11.6,7.1,15.5,,,,,,*6D
$GNRMC,201646.960,A,****.*****,N,*****.*****,E,0.1,0.0,190326,,,A,C*12
$GNGBS,201646.960,9.2,6.7,11.5,,,,,,*58
$GNRMC,201647.940,A,****.*****,N,*****.*****,E,0.0,0.0,190326,,,A,C*10
$GNGBS,201647.940,7.8,6.1,10.0,,,,,,*5D
$GNRMC,201648.919,A,****.*****,N,*****.*****,E,0.0,0.0,190326,,,A,C*1A
$GNGBS,201648.919,7.1,5.7,8.7,,,,,,*6C
$GNRMC,201649.900,A,****.*****,N,*****.*****,E,0.1,0.0,190326,,,A,C*1F
$GNGBS,201649.900,6.8,5.6,8.0,,,,,,*6B
$GNRMC,201650.099,A,****.*****,N,*****.*****,E,0.1,0.0,190326,,,A,C*1D

Higher baudrates (57600 and 115200) do not seem to experience the same problem. But it is definitely not caused by 'too much output' at 9600 baud as there is plenty of idle time between each output cycle.

@GalaxyQuest Do you maybe have an idea on how to work around this problem? Increasing baudrate or enabling unnecessary frames is not really an option due to limited resources on the host.