Just to confirm, did you guys both update your receivers with Galileo support?
After several tries, I canāt reproduce the issue. Please share some more details about your setups.
Yes, all my reach units were updated to 2.5 which included the update the the receivers. My setup I think is standard, pixhawk triggering the camera and the hotshoe connected to the reach. I have conducted 100ās of flights with this setup with no issues at all. Since the update it started to miss time stamps.
Yes, all my Reach units are up to date with the latest version. I have not carried out hundreds of flights with this machine, but certainly dozens. The only time the event marking did not work correctly prior to the current issues was traced to a loose connection. In that case, no event marks at all were returned.
I have however had issues with the GPS signal on this machine, which leads to dropouts in RTK coverage (solution drops to 0, sometimes for many seconds). I just use the single tags to cover the events which are missing with PPK, and until my last 2 flights this has given acceptable results. I donāt know if this issue and the event marker issue correlate at all in the logs?
In the case of the recent flight I have tried to match up the missing imags and event tags using the exif data from the camera, though have not yet managed to find a pattern perhaps you can? Image filename and timestamp from the exif data attachedflight2_exif.zip (2.3 KB)
Here is the setup, please excuse the mounting of the Reach, a temporary measure due to extending the mast to get better signal.
Cheers 
Well, that might be lead, for your case at least. If, for some reason, we donāt have at least a single solution, the events will be ignored. That might explain the missing time marks.
Losing your solution status is a whole other issue, that might be the drone interference or bad antenna connection. Try flying around with ReachView open and see if the SNR levels are ok.
Should there not be the time marks in the raw logs even if there is no single solution at the time of the event? On the recent flights they are missing in the raw log, previously there were a full set of time marks in the raw file, and only when processing the data are they lost.
In the case of the last 2 flights the events were missing from the raw .ubx logs.
I have tried several antennae, with the system powered up, flying, etc. It seems to just periodically lose lock on the satellites. When I watch the SNR in Reachview I see a lot of juming around - going from 8 or 9 good sats down to a few or none, then bouncing back up. I guess RF interference is the issue, but the antenna is mounted a good height above everything, certainly further away from emi sources than previous craft which have had good signal levels have been. I thought upgrading the antenna and extending the mast again would make a good difference, but performance is exactly the same. Anyway, it seems likely a separate issue from the eventsā¦
Well, there are two levels of the single status. Since we do all the processing separately, there is RTKLIBās single status, which you can see in ReachView. Also, there is receiverās internal single status, without which no time marks are produced, as they require accurate time info on the device.
@Charlie_Robinson I can also suggest to try to separate Reach module from the PDB, some recent reports suggest that high frequency power switching can cause cycle slips on u-blox.
I have the same issue.
Before GALILEO firmware update I donāt have any problem with missing events mark, but after update to 2.4 or 2.5 something about 10-20% of events are missing. Is it possible to back to eariler firmware?
Thanks for the reports. Could you guys try to perform a flight in GPS-only mode and see if that issue still persists?
Hi Egor, the flight I posted the raw log for above was carried out without Galileo enabled, though other possible constellations (GLONASS, SBAS, etc.) were all enabled iirc. I will try a GPS only flight this weekend, but for sure just disabling the Galileo sats did not fix the issue.
I can report similar issues 307 pictures taken 288 events captured, with Galileo enabled. The cabling and hotshoe connection has been recently re-soldered so that should not cause any issue.
Ok, I have now performed some tests with an actual camera connected. After a couple of hours of photographing my desk I can confirm, at least for now, that some of the events are missing, when and only when Galileo is enabled. At this point of my investigation, this might be either a receiverās firmware bug or some kind of misconfiguration, so I will continue.
It would help a lot if you guys could confirm this by making sure Galileo is disabled and performing a test flight.
1 Like
re my post above - I rechecked the settings. I had swapped the Reach module for my base module for the last flight, to eliminate the possibility of a problem with that specific unit. The one I swapped out had Galileo disabled, but I forgot to disable Galileo again following the switchover.
Will test with just GPS asapā¦
cheers!
1 Like
Did you a chance to test?
I just ran a flight, collected 74 images and have 52 events in the event.pos file. Anyone else seeing this?
AND GALILEO IS OFF, ONLY USING GPS AND GLONASS.
Cheers!
Hi all,
I had been meaning to start a new topic regarding this issue, and am glad it was brought to everyoneās attention.
A couple of weeks ago I was conducting aerial surveys of ice ridges in the Canadian Arctic with the Reach, and encountered this very same bug with missing time marks.
Initially, we ran the two Reach units in Single Mode, collecting RAW GPS data at 14 Hz, with the GALILEO, SBAS, and QZSS constellations enabled (since they can also be logged at 14 Hz). After our first day of fieldwork, we discovered that something was adversely impacting our ability to collect the correct number of timestamps. This behaviour was present during several flights, which produced the following results:
Flight 1
- Photos: 376
- Timestamps: 311
Flight 2
- Photos: 385
- Timestamps: 313
Flight 3
- Photos: 379
- Timestamps: 350
Flight 4
- Photos: 413
- Timestamps: 336
Eventually, through trial and error, we were able to determine that once the GALILEO, SBAS, and QZSS constellations were disabled and only GPS was selected, we were able to collect the correct number of time marks. This allowed us to conduct several additional days of flights with no issues.
@egor.fedorov I can confirm that in GPS-only mode I was able to capture approximately 2000 photos without a single missing time mark. The problem was only present when GALILEO, SBAS, and QZSS were enabled. Firmware 2.5
Hopefully this can be resolved!
Cheers,
Adam
1 Like
Did you use GLONASS and GPS? Just finished a collection with 74 and 52 time stamps.
Both GPS and GLONASS were enabled at 1Hz.
Have ground control placed as well and collected with Reach RS as backup.
@timvand I was only using GPS at 14 Hz, which I donāt believe GLONASS can record at. The 14 Hz was because we had a Topcon Hiper V receiver nearby that we were using as a local basestation, as well as a Canadian Active Control System (CACS) reference station ~13 km away.
Noted. Will refly again tomorrow and see what happens.
Are you using FW 2.5.3?
And your Reach, you are GPS only, 14Hz in Kinematic mode or Single?
Thanks!