I can configure the module using u-center, but I’ve noticed that the configuration is not stored permanently. It only retains the settings for a short period after a power outage. Please help with this.
Hi @sayhello ,
If you are using the SparkFun ZOE-M8Q breakout, please ensure the small RAM back-up battery is fully charged. It can take several hours for the battery to fully charge.
The ZOE-M8Q program memory is ROM (Read Only Memory). The firmware cannot be upgraded.
I hope this helps,
Paul
I’m glad to receive your reply. Through your explanation, I hope to be able to use BBR for long-term configuration storage. I connected a SparkFun ZOE-M8Q breakout using a USB-to-TTL converter and tried to charge the battery in this way. I charged it overnight. However, after a power outage of about 12 hours, I powered it on again and found that the configuration had reverted to the default state. What could be the cause of this? Is it because my charging method is incorrect?
Hi,
Is your USB-to-TTL converter providing 3.3V power to the board? 3.3V needs to be present to recharge the battery.
The ML414H battery only has a small capacity: 1.0mAh. The ZOE will draw approximately 20 microamps in “back-up” mode. The battery should provide back-up for approximately 50 hours when fully charged. But there may be other small current leaks on the board which will reduce this.
You also need to make sure that the configuration is being saved correctly before shutdown. Are you using the SparkFun u-blox GNSS Arduino Library? Are you using the saveConfiguration function?
Best wishes,
Paul
12 is usually plenty, but I’ve seen cases where the battery took up to 24 hours to fully charge as well
If you are handy with soldering you can replace it with a larger mAh one if that helps
If you’re using it with an MCU you can also use a portable battery bank to power/extend the life of the whole setup for longer
Hi Paul，
I can confirm that the USB-to-TTL converter can provide a 3.3V power supply to the circuit board. I configure the SparkFun ZOE-M8Q using u-center, and before power off, I ticked “Save current configuration” and “0-BBR” through CFG-CFG. You asked if I am using the SparkFun u-blox GNSS Arduino library; are you suggesting that I should configure it through software programming? I’m sorry, but I didn’t quite understand your meaning there. As I mentioned earlier, the configuration is normal for a short time after shutdown, but it reverts to the default settings after a night. I think this also proves that I have correctly used the function to save the configuration. After it reverted to the default state, I measured the voltage across the battery terminals at 2.5V, and in my understanding, it should not revert to the default configuration.
Could you help me with this?
Hi @sayhello ,
I am not sure what is causing your issue, or what to recommend.
The ZOE Battery-Backed RAM should retain information so long as V_BCKP is higher than 1.8V. If the battery is at 2.5V, I do not know why the configuration is reverting to the defaults.
We have our own u-blox GNSS Arduino Library. The saveConfiguration function uses UBX-CFG-CFG to save the configuration. It sounds as if you are doing the same thing.
Are you sure the configuration is reverting to the defaults? Or is it just that the module performs a cold start?
I will try a test here, to see if I can replicate your issue.
Best wishes,
Paul
Using this image as an example, I set the reference time to GPS-time. However, after a period of power-off, when I check the configuration status using the POLL button, it reverts back to the default UTC time. I can attach my configuration file. I’m not quite sure what you meant by whether the module underwent a cold start. In theory, whether it’s a cold start or a hot start, the only effect should be on the satellite lock speed, and it should not affect the configuration settings. If the issue still cannot be resolved, I will purchase a new Zoe-M8Q module to verify whether the current module has a fault causing the problem. In any case, thank you for your reply and assistance.
GPS_CFG.txt (5.5 KB)
Once again, sorry to trouble you. I have another question regarding PPS signal stability. I captured consecutive rising edges of the PPS signal and obtained a total of 245 measurements of the time intervals between adjacent PPS signals, from which I calculated a standard deviation of 5.85 μs. However, this does not meet our device’s requirements—we would prefer this value to be as small as possible, at least in the sub-microsecond range, and ideally with nanosecond-level stability. I haven’t found any description about the stability of the PPS signal in the manual. Could you provide any relevant information on this? If this module does not meet the requirements, do you have any other modules you could recommend? I would be extremely grateful for your assistance.
Hi @sayhello ,
All we can do is refer you to the u-blox documentation.
For nanosecond stability, you need a very different solution. Please see our new GNSS Disciplined Oscillator.
Best wishes,
Paul
1 Like
Hello @sayhello ,
I had some spare time today, and I used the SparkFun GNSSDO to study the PPS signal of the ZOE-M8Q. The report is available here. The PPS timing appeared completely within specification. I was not able to observe the microsecond variations you observed.
If you would like more help with this, please tell us more about the equipment you are using to study the PPS timing. Is the equipment calibrated? What input trigger level was used? Did the ZOE-M8Q antenna have a clear view of the sky throughout the tests?
Best wishes,
Paul
Hello @sayhello ,
I have been able to replicate your original issue - the module reverting to the default configuration. The initial report is available here.
I will try more tests over the next few days.
Best wishes,
Paul
Architecturally it should be better than the 30ns RMS, but is going to have a Quantization Error in the order of +/- 11 ns based on the timing clock.
qErr is reported in UBX-TIM-TP (next pulse), local time performance is reported in UBX-NAV-CLOCK
I don’t recollect the ZOE-M8Q TCXO performance, but probably has a 0.5 ppm stability like it’s competitors. Clock performance is something that would be stored in BBR.
For the larger errors it would be helpful to understand the context/details the receiver thinks it’s working with at those instants.
Not sure the ZOE is in the same market space as a $2500 GNSSDO
The NEO-F10N might be a better choice, a NEO-F10T if you need and can use the qErr reporting.
OTP is the other alternative to frost settings into a ROM only receiver. There are other uBlox choices for parts with FLASH to retain settings
Thank you very much for your assistance. I have conducted experiments again on the 1PPS stability validation, and confirmed that its stability is at the nanosecond level, which meets our requirements. The previous errors were likely due to issues in my test code. Regarding the issue of reverting to default configuration after several hours of power outage, I have reviewed the tests you conducted. I will charge it for 18 hours in the follow-up, correctly write the configuration, and disconnect all cables. At the same time, I will attempt to use UBX-CFG-RST.I will also periodically POLL the configuration through u-center to check if the register status matches the previous configuration. I look forward to your further experimental results. Once again, I appreciate your help.
Could you please provide me with references to other modules? I’ve looked into the NEO-F10N, but the limitation of only offering UART communication is a drawback. Since we haven’t yet finalized which communication method to use with the MCU, I believe the long-term stability of FLASH functionality is what we need. I hope you can recommend such modules to us, as a $2500 GNSSDO is not suitable for our large-scale use and budget. I would be very grateful if you could offer your assistance.