V26 Loosing log UBX after reboot M+ and M2

Hi @m.rocha,

Thanks for the detailed explanation!

Please share the Full System Reports from all the suffering units with me. As they contain sensitive information, it’s better to share them privately with me via PM or support@emlid.com. The info in them will help us to check the internal settings of the unit to identify the reason.

It’d be also useful to check the serial numbers of the devices. They can be found on the bottom sides of the devices under the bar code.

Hey,

Just wanted to say that I’ve received the data from the unit. Currently, we’re checking what can trigger this behavior. In case of any news, I’ll be in touch.

Hi @polina.buriak,

Today I performed a static point registration and calculating the ntrip. when accessing the log in the period in which it was in the float status, the ubx log failed, after fixing the stabilized log of ubx stabilized.

Hi @m.rocha,

I looked through all your data and tried to reproduce the issue on Reach M2 running the 26 firmware version but failed.

I tried to reload the unit by replugging the power several times, and the logs were recorded properly for each of them, though it took some time from Reach to compress all the UBX files.

I also noticed that you shared 2 Full System reports with us: one from the unit running the v2.24.2 firmware version and the other one from the device on the 26 version.

If I get everything right, it looks like the issue you experience occurs not exclusively on 26 firmware. Since we can’t reproduce the issue ourselves, I believe it may have a lot to with your specific setup and use case. Even it started happening after the update, it’s still possible that something could go wrong with the setup at the same moment.

Still, we are here to investigate it and find out the root of the issue, and it’s vital to do it the fastest way possible so that our devices work for you the way it’s expected. Let’s check several different things - just to exclude each of them as a potential suspect.

  • Try changing the way you reboot the unit: would it change anything if you do it by manual replugging?
  • Try connecting the unit to the power using another cable or power source
  • Share the setup photos with us over support@emlid.com: we will examine them together with our electronics engineers

Hi @tatiana.andreeva ,

Very strange, since all M + and M2 are in the latest FW26 version,

The M + and M2 units are disappearing all the files when looking at the logs with a longer boot time than the one connected to the unit, I took some screenshots for samples with 0.53mb and 4h of operation and after starting they were only 5 minutes away.

M+ Print Start Log
M+ Print End Log

These logs simply after being finalized, via SSH we can see and download them, but they are corrupted. To resolve this, we are collecting data with the Rinex 3.03 option enabled and downloading it in the field with the unit before shutting down via software, which is taking too long.

For NTRIP, we download the logs and disable the log, after we can use NTRIP without problems and without problems, if the Log is open, the repair time becomes extremely time-consuming and also generates failures in the UBX Log.

The operation is currently in 3 stages.

  1. M2 = Static Base (recording Logs UBX and Rinex 3.03 (Full Rate same RTK Settings 5Hz))

  2. M + = Rover Kinematics (Recording Logs UBX and Rinex 3.03 (Full Rate same RTK Setting 5Hz))

  3. M2 = Ntrip recording fix point standalone, no logs recording.

When the ntrip is active and the solution is in FLOAT, this information is generated by the log.

In the M + units, mainly, we noticed that some log names are missing, with a time offset of a few minutes in the name of the logs.

Before unzip

Plot of raw_202105181441.obs

Plot of raw_202105181442.obs

In other words, we are having to unzip and trying to find out who each one is through the head of the rinex or plot of the rtklib to later process with the M2 bases.

About setup energy, the 3 units M+ follow Teokit setup, since 2018 and 2019.


And 2 M2 Bases setup since Feb.2020 (one power bank, microusb cable).

The setup has been working perfectly for years and none has had a similar log fault disappear, name errors or holes in the logs in the firmware prior to firmware 26.

And we lost a m2 unit that failed test 1 (which says nothing about what it would be) and had to be retired compusively to everyone’s sadness, and it also makes us very concerned about future investments in new emlid hardware.

Hi @m.rocha,

Thanks for the detailed description! All of this looks rather strange. I’ll discuss this with the team and will get back.

Meanwhile, would it be possible for you to share all of the logs with us?

Hi,

Perfect, follow the link below

https://1drv.ms/u/s!An2p4XX_P07WoJFI1aryo-iZG6swjQ?e=tG6BQZ

Hi @polina.buriak,

Would you have any news?

Hi @m.rocha,

Sorry for keeping you waiting.

We’re checking the logs. As we can’t reproduce the issue, it’s hard for us to find the root of the issue quickly. That’s why troubleshooting takes time. Once we have some news, I’ll be in touch.

1 Like

A post was split to a new topic: Logging issue

Hi @polina.buriak,

Perfect! if you need more data I am available.

Hi @polina.buriak,

I updated the M+ units with FW26.1, and the time of logs stay that.

The logs filename are out of time of real log time.

See above, Yesterday, Today and again Yesterday.

@polina.buriak see the files of Fw26.1

https://1drv.ms/u/s!An2p4XX_P07WoKV8vVqMKrxYridNcA?e=yPUm0u

Hi @polina.buriak,

And here we go, missing another day of work!

image
Stressful.
Send good news please!

VALOES_BASE02_ReachM2_20210603_SystemReport.zip (2.2 MB)

Hi @polina.buriak,

We are not able to use any M+ and M 2 units safely, we don’t know what to do!

In time, we were able to see the files ZIP via SSH but they just don’t open after download!

There is how not to be done the compression of files, I believe that is the problem for the loss.

Hi @m.rocha,

Sorry it took us a long time to get back to you.

I believe we have found the root of the issue you’ve faced. We’ll fix it in the upcoming firmware update. I’ll reach out when it’s out.

@m.rocha,

Thank you for providing the extensive amount of data for the investigation! With your help, we were able to determine the cause of the issue now.

As promised, I’m coming back to you with the news of the update. We’ve just released the Reach Firmware 26.2. It should resolve the issue with the disappearance of the logs and their wrong time. The full list of fixes is here.

Please update your receivers to it and check if the issue is resolved for you. Please keep me informed of your results.

3 Likes

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.