2026-03-12 3:31 PM - edited 2026-03-17 2:49 AM
We recently had a batch of equipment assembled with the Teseo-LIV4F instead of LIV3, and I'm running into some real strange behaviour.
Whenever I try to disable the GPGSV frame the whole NMEA output breaks. It is not a problem with the receiving host as I have verified with an oscilloscope that the broken NMEA is really outputted by the LIV4F.
Commands I send:
$PSTMSETPAR,1201,0x4,2*7B
$PSTMSAVEPAR*58
$PSTMSRR*49
And the output starts to be like: (See concatinated GBS and GSV, the checksum and new line on GBS is missing)
$GNGBS,,,,,,,,,,,,,,,$GNRMC,,V,,,,,,,,,,N,V*37
$GNGGA,,,,,,0,00,0.0,,M,,M,,*56
$GNVTG,,T,,M,,N,,K,N*32
$GNGST,,,,,,,,*49
$GNGBS,,,1,01,25,,,39$BDGSV,1,1,01,25,,,39,,,,,,,,,,,,,1*79
$GNRMC,,V,,,,,,,,,,N,V*37
$GNGGA,,,,,,0,00,0.0,,M,,M,,*56
$GNVTG,,T,,M,,N,,K,N*32
$GNGST,,,,,,,,*49
$GNGBS,,,1,01,25,,,37$BDGSV,1,1,01,25,,,37,,,,,,,,,,,,,1*77
$GNRMC,,V,,,,,,,,,,N,V*37
$GNGGA,,,,,,0,00,0.0,,M,,M,,*56
$GNVTG,,T,,M,,N,,K,N*32
$GNGST,,,,,,,,*49Enabling / Disabling different frames caused different types of broken output (missing identifiers or checksums). The frames seem to break in the same way for every output cycle.
In above example the output will work like normal again after re-enabling GPGSV:
$PSTMSETPAR,1201,0x4,1*78
$PSTMSAVEPAR*58
$PSTMSRR*49
Does anyone recognize this behaviour?
Reflashing firmware does not help (It makes the device work like expected again until I disable some frametypes)
I tested on 4.6.8.5.11 and 4.6.8.5.10:
$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,00000af005070a0a0e0d0c0b0a090608070203630e110404180c0155030000500fffff0f0714000affffffffffffffffffffffffffffffffffffffffffffffff*1D
$PSTMSWCONFIG,1,1,12,ffffffffffffffffffffffffffffffffffffffffffffffffffff010101000001094005ffffffffff449641095f53884000000000000000000000000000000000*4D
$PSTMSWCONFIG,1,2,12,ffffffff00000000ffffffff000000000000000000000000ffffffff000100000019000000000000ffffffffffffffffffffffffffffffff0000120005282000*13
$PSTMSWCONFIG,1,3,12,01323200050358020a0a0000fe03000010f08334d50300a42023c07e00000000000000005f5388402023c07e0000000000000000000000000000000012090000*1A
$PSTMSWCONFIG,1,4,12,120000009a106464ae618400000001000000000000000000000000000000000006000000ffffffff040000000100000000000080b004780503000000f0c3f7ff*45
$PSTMSWCONFIG,1,5,12,00000000ffffffff000000000c0a00020fb4a005f5310000010a1900330a0a1400510000810e000000001810000008000e01000000000000020f000000000000*13
$PSTMSWCONFIG,1,6,12,0000e803ffffffff0610000080ba8c014810c703ffffffff9abed2e6edf2fafb0000020205060101ff00ff00ff00ff00ff000000ff00ff000000000000000000*4D
$PSTMSWCONFIG,1,7,12,9a9999999999b93f000000000000e03f0000000000000000000000000000f03f4bc431896f754440f0f67e923d8d2c408c65456bb71b56404b0484b86d3da53e*1E
$PSTMSWCONFIG,1,8,12,0cb8df888b2f9c3e2b69a4292b1b503e0cb8df888b2f9c3e4b0484b86d3da53e000000000000000000000000000000005feffe78af8e44406c21c84109c32b40*4B
$PSTMSWCONFIG,1,9,12,00000000000024401d8f19a88c8f4440598b4f0130be2b4000000000000024407ac2120f289f44402315c616828c2b400000000000002440ace28dcc239f4440*11
$PSTMSWCONFIG,1,10,12,95826e2f698c2b4000000000000024400f0c0c120f0c0c120f0c0c120f0c0c1244454641554c542050565420434f4e46494755524154494f4e00000000000000*76
$PSTMSWCONFIG,1,11,12,00000000000000000000000000000000000000000000000000000000000000000000000000000000*26
$GNRMC,,V,,,,,,,,,,N,V*37
$GNGGA,,,,,,0,00,0.0,,M,,M,,*56
$GNVTG,,T,,M,,N,,K,N*32
$GNGST,,,,,,,,*49
$GNGBS,,,,,,,,,,*5F
$GNGSA,A,1,,,,,,,,,,,,,0.0,0.0,0.0,1*33
$GNGSA,A,1,,,,,,,,,,,,,0.0,0.0,0.0,3*31
$GNGSA,A,1,,,,,,,,,,,,,0.0,0.0,0.0,4*36
$GNGSA,A,1,,,,,,,,,,,,,0.0,0.0,0.0,1*33
$GNGSA,A,1,,,,,,,,,,,,,0.0,0.0,0.0,3*31
$GNGSA,A,1,,,,,,,,,,,,,0.0,0.0,0.0,4*36
$GNRMC,,V,,,,,,,,,,N,V*37
$GNGGA,,,,,,0,00,0.0,,M,,M,,*56
$GNVTG,,T,,M,,N,,K,N*32
$GNGST,,,,,,,,*49
$GNGBS,,,,,,,,,,*5F
$GNGSA,A,1,,,,,,,,,,,,,0.0,0.0,0.0,1*33
$GNGSA,A,1,,,,,,,,,,,,,0.0,0.0,0.0,3*31
$GNGSA,A,1,,,,,,,,,,,,,0.0,0.0,0.0,4*36
On the LIV3 devices all worked like expected.
Regards, help much apreciated.
Solved! Go to Solution.
2026-03-18 12:33 PM - edited 2026-03-18 12:40 PM
Summary for reference by others encountering this problem:
At least upto and including firmware 4.6.8.5.11 NMEA output breaks when you enable or disable specific frametrypes using the $PSTMSETPAR,1201 command. It seems to be related to I2C being enabled which is factory default. You can prevent the problem by disabling I2C using:
$PSTMSETPAR,1263,0x1,2
$PSTMSAVEPAR
$PSTMSRR
2026-03-13 1:47 AM - edited 2026-03-17 2:51 AM
I can't believe it, but we've just verified it is a LIV4F firmware issue. We had some older LIV4F modules laying around running 4.6.3.5.3, they work completely fine. We updated it to 4.6.8.5.11 and the NMEA breaks!
Edit: 4.6.3.5.3 also seems affected, please see follow up post below.
2026-03-16 7:54 AM
Another update.
I received the 4.6.3.5.3 firmware file, at first it seemed to work correctly with a custom config on the enabled frametypes. Unfortunately I've now also encountered the same problem, whether it breaks or not seems to depend on how much data is in the frames:
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,142826.176,V,,,,,,,070180,,,N,V*2C
BROKEN -> $GNGGA,142826.176,,,,,,,*5C
BROKEN -> 0,,M,,M,,*43
BROKEN -> $GNGBS,142826.176,,,,,,,,,,0.0,$GNRMC,142826.576,V,,,,,,,070180,,,N,V*28
BROKEN -> $GNGGA,142826.576,,,,,,,*58
BROKEN -> 0,,M,,M,,*47
BROKEN -> $GNGBS,142826.576,,,,,,,,,,0.0,$GNRMC,142827.056,V,,,,,,,070180,,,N,V*2E
BROKEN -> $GNGGA,142827.056,,,,,,,*5E
BROKEN -> 0,,M,,M,,*41
BROKEN -> $GNGBS,142827.056,,,,,,,,,,0.0,$GNRMC,142827.535,V,,,,,,,070180,,,N,V*2E
BROKEN -> $GNGGA,142827.535,,,,,,,*5E
BROKEN -> 0,,M,,M,,*41
BROKEN -> $GNGBS,142827.535,,,,,,,,,,0.0,$GNRMC,142828.016,V,,,,,,,070180,,,N,V*25
BROKEN -> $GNGGA,142828.016,,,,,,,*55
BROKEN -> 0,,M,,M,,*4A
BROKEN -> $GNGBS,142828.016,,,,,,,,,,0.0,$GNRMC,142828.516,V,,,,,,,070180,,,N,V*202026-03-16 1:19 PM
Hi,
I used Teseo Suite to disable $GPGSV and $GPGSA
$PSTMSETPAR,1201,0x4,2
$PSTMSETPAR,1201,0x80000,2
$PSTMSAVEPAR
$PSTMSRR
I am able to see NMEA sentences.
I tested the set up in Teseo Suite.
I am wondering if there is a another bit setting which is causing the behavior you are seeing. Can you please retry flashing the chip and start troubleshoot by first turning off just $GSV and SGA?
2026-03-17 2:02 AM
Thank you for testing,
I just tested this after flashing 4.6.8.5.11, and over here the output breaks. However, especially in Teseo-Suite it might look like all is working fine as Teseo-Suite seems to filter out any frame that does not have a valid checksum.
What I did:
1. Flash firmware 4.6.8.5.11 using Teseo-Suite Pro, with 'Erase NVM' and 'Restore Factory Settings' enabled.
2. Connect to the device using the 'Control' mode.
3. Send the following commands:
$PSTMSETPAR,1201,0x4,2 $PSTMSETPAR,1201,0x80000,2 $PSTMSAVEPAR $PSTMSRR
4. At that point the output shown in Teseo-Suite seems fine, however, it seems to be so only because it filters out broken NMEA.
5. I Disconnected and reconnected in Debug mode. In debug mode Teseo-Suite can show the raw UART output. In this view we can see a broken $GNGBS frame attached just before every $GNRMC frame, that does not show up in 'Control' mode.
6. I disconnected Teseo-Suite and opened my raw UART logger, it also shows the broken $GNGBS frame attached before each $GNRMC frame.
Regards,
Joost
2026-03-18 10:54 AM
Hi,
Thanks for catching this. It looks like the NMEA frame GNGBS is not calculating checksum data and adding termination.
Let me bring this up to our product team and provide you feedback.
I was thinking disabling GSA and GSV was causing other frames to not populate data.
While we wait to resolve this issue, for delimiting an NMEA frame, can you use "$" as a frame start identifier i.e., consider the end of the frame only when a next "$" is received?
2026-03-18 12:28 PM
Not really because my application needs different modes where different combinations of frames are enabled that cause different types of broken output. Just to have some fun with really broken output you can try:
$PSTMSETPAR,1130,0x00
$PSTMSETPAR,1303,0.5
$PSTMSETPAR,1201,0x00000042
$PSTMSETPAR,1228,0x00002000
$PSTMCFGCONST,2,0,2,0,2
$PSTMSETPAR,1200,0x8,1
$PSTMSETPAR,1200,0x8000,2
$PSTMSAVEPAR
$PSTMSRRIt gives me this (No single valid line of output)
BROKEN -> $GNGBV,1,1,01,19,,,12$GNRMC,,V,,,,,,,,,,N,V*37
BROKEN -> $GNGGA,,,,,,,,,,*5F
BROKEN -> ,M,,M,,*56
BROKEN -> $GNGBV,1,1,01,19,,,12$GNRMC,,V,,,,,,,,,,N,V*37
BROKEN -> $GNGGA,,,,,,,,,,*5F
BROKEN -> ,M,,M,,*56
BROKEN -> $GNGBV,1,1,01,19,,,12$GNRMC,,V,,,,,,,,,,N,V*37
BROKEN -> $GNGGA,,,,,,,,,,*5F
BROKEN -> ,M,,M,,*56
BROKEN -> $GNGBV,1,1,01,19,,,12$GNRMC,,V,,,,,,,,,,N,V*37
BROKEN -> $GNGGA,,,,,,,,,,*5F
BROKEN -> ,M,,M,,*56
BROKEN -> $GNGBV,1,1,01,19,,,12$GNRMC,,V,,,,,,,,,,N,V*37
BROKEN -> $GNGGA,,,,,,,,,,*5F
BROKEN -> ,M,,M,,*56
BROKEN -> $GNGBV,1,1,01,19,,,12$GNRMC,,V,,,,,,,,,,N,V*37
BROKEN -> $GNGGA,,,,,,,,,,*5F
BROKEN -> ,M,,M,,*56
BROKEN -> $GNGBV,1,1,01,19,,,12$GNRMC,,V,,,,,,,,,,N,V*37
BROKEN -> $GNGGA,,,,,,,,,,*5F
BROKEN -> ,M,,M,,*56
BROKEN -> $GNGBV,1,1,01,19,,,12$GNRMC,,V,,,,,,,,,,N,V*37
BROKEN -> $GNGGA,,,,,,,,,,*5F
BROKEN -> ,M,,M,,*56
BROKEN -> $GNGBV,1,1,01,19,,,11$GNRMC,,V,,,,,,,,,,N,V*37
BROKEN -> $GNGGA,,,,,,,,,,*5F
BROKEN -> ,M,,M,,*56
BROKEN -> $GNGBV,1,1,01,19,,,11$GNRMC,,V,,,,,,,,,,N,V*37
BROKEN -> $GNGGA,,,,,,,,,,*5F
BROKEN -> ,M,,M,,*56
But good and bad news. I just found out it is actually a known firmware bug that you encountered before and is aperantly not yet fixed:
https://community.st.com/t5/gnss-positioning/gnss-modules-commands-teseo-liv4f/td-p/812774
Like you point out yourself, the broken NMEA output is caused by I2C being enabled along UART (Which seems to be factory default).
When I throw the 'disable I2C' in the mix:
$PSTMSETPAR,1130,0x00
$PSTMSETPAR,1263,0x1,2
$PSTMSETPAR,1303,0.5
$PSTMSETPAR,1201,0x00000042
$PSTMSETPAR,1228,0x00002000
$PSTMSETPAR,1102,0x9
$PSTMCFGCONST,2,0,2,0,2
$PSTMSETPAR,1200,0x8,1
$PSTMSETPAR,1200,0x8000,2
$PSTMSAVEPAR
$PSTMSRREverything starts to work just fine:
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*56
OK -> $GNGBS,,,,,,,,,,*5F
OK -> $GNRMC,,V,,,,,,,,,,N,V*37
OK -> $GNGGA,,,,,,0,00,0.0,,M,,M,,*562026-03-18 12:33 PM - edited 2026-03-18 12:40 PM
Summary for reference by others encountering this problem:
At least upto and including firmware 4.6.8.5.11 NMEA output breaks when you enable or disable specific frametrypes using the $PSTMSETPAR,1201 command. It seems to be related to I2C being enabled which is factory default. You can prevent the problem by disabling I2C using:
$PSTMSETPAR,1263,0x1,2
$PSTMSAVEPAR
$PSTMSRR
2026-03-21 9:05 AM
It is good to have one more thing in mind when using this gps module:
Software Change List (4.6.8.5.11) Fix loss of FW config issue
this problem is not solved no matter what it says in the pdf file to the firmware, I have 16 devices with this gps module working from 11.2025 until now 2 gps modules returned to factory settings for no clear reason. For the moment I think I managed to solve this problem by changing the factory settings in the .bin firmware file with the ones I needed using Teseo-Suite and rewriting the firmware in the gps modules.
2026-03-21 9:48 AM
Thanks, I must say I'm completely struck by how broken the firmware seems to be, just really to a point where it is almost unusable beyond the default config, even when changing settings that are perfectly well documented in the software manual.
As far as I know there is not even an Errata sheet available with all the known problems / workarounds.