(Apologies for what may be a lengthy port, but in the interest of detail…)
Started a thread in the uBlox forums about an issue encountered after updating the firmware from the original version (originally installed firmware) to HPS 1.30. After upgrading to HPS 1.30, any configuration information “sent” via uBlox’s configuration software does not remain after a reboot (even if what’s being set via “Send config changes” includes both RAM, Flash, BBR). eg: using the config v9 in the GUI, and ensuring that BBR/Flash is also selected for send, those parameters have to be re-sent after any reboot/power cycling of the RPI. Suspecting it may be a “bug” in the 1.30 firmware, reverted to the 1.21 firmware and the same issue is present. Hoping that someone may have some information or thoughts, otherwise will need to RMA the unit for replacement.
And before it’s asked “Why did you update the firmware if it was ‘working’?” - generally there are some “post initial version” updates to address bugs, etc. and doing at least an initial update seems pragmatic after a unit has had some field time. Thus, updating from initial firmware is generally pragmatic and good.
Some notes (not sure if germane):
Solely used the uBlox uCenter software for all config/update
Update and config only performed via USB-C connection
Use case is centered on NTP (this HAT met the need for a more stable clock source)
Used the Gen 9 Config view. When setting, selecting RAM, Flash and BBR which seems to be the ‘norm’ with uCenter. Under the original firmware, was still having to use the non-Gen 9 Config view under “CFG” to do a final “write” in order to get the unit to “save” the settings across reboots. Which appears to be “incorrect” from what I’ve read on the forums? From what was read, it infers that selecting RAM, Flash should be sufficient to get the configuration to be saved across reboots/power cycling.
A side note is that settings under “GNSS Configuration” under the Gen 9 Config view have always worked and always persisted across reboots/power cycling.
Side note: a little frustrated that uCenter doesn’t expose the “config” file so that it could be attached to this posting for additional reference.
What is present after a reboot via View → Text Console (this is what the serial port SHOULD show):
22:37:22 $GNRMC
22:37:22 $GNVTG
22:37:22 $GNGGA
22:37:22 $GNGSA
22:37:22 $GNGSA
22:37:22 $GNGSA
22:37:22 $GNGSA
22:37:22 $GNGSA
22:37:22 $GPGSV
22:37:22 $GPGSV
22:37:22 $GPGSV
22:37:22 $GPGSV
22:37:22 $GPGSV
22:37:22 $GPGSV
22:37:22 $GLGSV
22:37:22 $GLGSV
22:37:22 $GLGSV
22:37:22 $GLGSV
22:37:22 $GLGSV
22:37:22 $GAGSV
22:37:22 $GAGSV
22:37:22 $GAGSV
22:37:22 $GAGSV
22:37:22 $GAGSV
22:37:22 $GBGSV
22:37:22 $GBGSV
22:37:22 $GBGSV
22:37:22 $GBGSV
22:37:22 $GQGSV
22:37:22 $GNGLL
After reboot, here is what’s actually appearing via the serial port:
(100) b562
(78) $GNGNS
(67) $GNGRS
(48) $GNGRS
(61) $GNGRS
(53) $GNGRS
(56) $GNGRS
(65) $GNGRS
(64) $GNGRS
(52) $GNGRS
(52) $GNGRS
(39) $GNGRS
(33) $GNVLW
(448) b562
(26) b562
(24) b562
(12) b562
Shouldn’t “Text Console” show what’s actually appearing on the serial port? What’s particularly odd is that the Text Console does show the correct output, but it doesn’t mirror what the serial port is actually outputting.
Hoping that perhaps someone here may have some thoughts on either A) a means to resolve or B) if perhaps its simply a defective unit. Would be curious to know if anyone else has upgraded their unit to the HPS 1.30 version of the firmware? Or if anyone has updated to at least the HPS 1.21 version of the firmware without issue in terms of configuration persistence across reboots.
The U-blox forum will probably be better source…but I have seen an issue where u-blox u-center v1 worked but v2 did not; perhaps a software change also happened sometime in the year? If using the newer try doing it using the older version
Side note: Eh, perhaps I’ve just been burned too many times but I disagree with the theory that unprompted firmware updates are ‘generally pragmatic’…the golden rule is to not try fixing things that work/suit the project’s purpose (if the bug fixes were relevant, you’d likely already know). Here are the release notes https://content.u-blox.com/sites/defaul … 035201.pdf
Unfortunately, did post in the uBlox forums and while some suggestions were made - a solution did not come about. Afterwards, opened a support case with uBlox and it was closed within hours of it being opened - without any response/reply.
The version of uCenter that is being used is the one for “legacy” products as the “F9” series is directly listed. Hadn’t tried the newer uCenter v2 with the unit. Perhaps v2 should have been tried?
In retrospect, would agree with your statement in terms of this unit. Which is notionally different from a broad swath of IT where to obtain any measure of support the firmware/software must be recent (eg: one of the available versions for download from the vendor’s website). Perhaps lessen learned in terms of GPS devices.
Once the RP is booted and then open uCenter, load file for settings and “send config changes” is performed - it does work. Although its offset accuracy is rather high, its running around 3-5 microseconds of offset while some existing RPs using a more common/generic HAT are running 800-2500 nanoseconds of offset. Which is somewhat surprising after a couple weeks of continuous GPS signal using the associated uBlox antenna (purchased with the unit).
On a side note, would happily share the config file being used (no specific location data being coded into the config), if that had any merit but evidently the file(s) aren’t “available” and have not found a way to get to those. Seems highly limiting (dubious at best) to not allow the config files to be extracted - even for the purpose of backup. Are you aware of any means to extract the config file(s) for the purpose of backup?
To use the v2 version of uCenter would require validation as an account is required along with Internet access. As another group would need to establish if/what data is being exfiltrated before approval can be obtained to install/use within the environment. As the original uCenter didn’t require an account or Internet access, it was much simpler.
I’m not even sure of the mechanism of failure here.
In SAFEBOOT / ROM mode it’s not going to save things.
If the firmware is corrupt it won’t be run, as the signing will fail, and it will revert into SAFEBOOT. UBX-MON-VER will be indicative of it running from ROM 1.02
If you update with “Erase Chip” it should discard any hold-over configuration data hiding in FLASH.
The “Save Configuration” methods do kitchen sink an entire list of keys, many that are not documented, and not relevant. If you change the baud rate mid flow everything else sent is going to be ignored.
My preference is to make simple delta Generation 9 configuration files which just change the settings I want that differ from default.
If you’re not a direct customer most tickets will be closed as you don’t have a support engineer assigned to your account. You could perhaps have SparkFun walk it in as they do a reasonably large amount of business.
Attached is a capture of the UBX- MON - VER information. Would be interested to know if it’s “what is expected” or not. As nothing appears as “1.02” in the information, would believe that it is not running in SAFEBOOT/ROM mode - correct?
For good measure, did run the firmware update [again] and used the chip erase function [again]. However that had no impact on settings being saved across reboots. Even tried reverting to the 1.21 version with chip erase and re-upgrading to 1.30 with chip erase and still no change in the behavior. It’s simply bizarre.
The settings being changed are limited to only those that must differ from “default”. Basically, setting BAUD, adding NMEA messages to UART1, removing UBX messages on UART1 and setting a couple time related items to UTC.
For the purpose of completeness, each ‘changed’ parameter is selected for RAM/BBR/FLASH. Thus resulting in 3 lines for each altered parameter. Should all three be set? Should only “RAM & Flash” be set or “RAM & BBR”? Does that make a difference? (Notion was that the send config function in the gen 9 config view would (on the back end) simply do the “right” thing in terms of saving. Will happily create a new load file if you think removal of BBR or FLASH would make a difference. (seem to think I read somewhere that the unit uses “flash” not BBR for persistent storage of settings, Yes?). This is one of the reasons that being able to “share” the actual load file would make “diagnostic sense”. eg: the ability for someone else to be able to “load” the file to review settings (without writing to their own unit). Only time it would make sense to -not- share is if/when the configuration had hard-coded location information, otherwise its fairly generic, IMHO.
