Reach M+ Triggering Camera via Hotshoe

[santiago]

Hi everyone. I’m very new to RTK GNSS and just bought a Reach M+ to use it with a Sony Alpha 7RII. I’m triggering the camera via the hotshoe of the sony alpha. I have it configured to trigger every 4 seconds, but when I go to check the data on RTKLIB software and convert the UBX data to rinex I get a lot more coordinates positions than images taken. Is there a way to get just one coordinate per image taken or is there a way to sync the images with the log even if there are more logs than images.

Best regards,

Santiago

[wizprod]

Can you post some pictures of your setup and wiring for the hotshoe adapter, along with the raw ubx file of m+ and the base?

[santiago]

Hi Christian, I’m just trying to work with the M+ for now so I don’t have raw data of the base for this test. If it’s necessary I’ll make another test. Thanks for any help you can give me I’m very new to this. RAW DATA M .zip (255.4 KB)

[dmitriy.ershov]

Hi Santiago,

In the log that you’ve shared there are 44 events. How many did you expect?

[santiago]

Hi Dimitriy,

Exactly 44 but how did you manage to see the events. I’m completely new at this and what I manage to extract from the ubx file was a txt file with much more than just 44 events. But cleraly I’m doing something wrong. If this is explained in a tutorial maybe you can point me to it since I haven’t found that part. Thanks a lot.

Best,

Santiago

[dmitriy.ershov]

Santiago,

Please use the guide in our docs tp post-process your logs:
https://docs.emlid.com/reachrs/common/tutorials/gps-post-processing/

After you have solution file, check *_event.pos file - it will contain your time marks.

I’d also recommend checking the following thread:

Query on Reach M+ Operation

Hi…I have the following questions regarding operation the of Emlid Reach M+. I have read the integration manual of Rededge+Reach M+ and looked at the Emlid Reach M+ manuals and still have the following query. Considering a ROVER Reach M+, Does the Reach M+ start collecting GPS data when its ‘Marker’ pin is driven by an external device (such as RedEdge Top of Form signal) or Do you have to enable the ‘raw UBX’ switch on the ‘logging’ menu of the Reach M+ and then activate the marker signal…

[santiago]

Hi Dimitriy,

Thanks I managed to generate the event.pos and open it in excel. I can see the 44 events and there are exactly 44 images so it’s working exactly how it should. I’ll make the next trial with a test flight and the base station and post process everything to see my results.

Best regards and thanks,

Santiago

[santiago]

Hi Dmitriy Ershov,

We did a test flight with the M+. It was in an area very far away and used it by itself just to gather some GPS data for each image without expecting a lot of accuracy just about 10 m or so would be ok. The deal is that the event.pos created 1 event less than the pictures, I found the picture that didn’t get recorded but the weird thing is that precisely for this picture the event.pos data gathered the same GPS info for the rest of the flight this happened at event 115. What could have happened to the data and to the M+? Attached find the ubx and the event.pos. Another curious thing is that the LLH data seems to be fine and the coordinates are different for every second they got recorded. solution_201901301806.zip (165.2 KB)

Best,

Santiagoraw_201901301806.zip (4.0 MB)
Final1.zip (22 Bytes)

[dmitriy.ershov]

Santiago,

What was the GNSS selection on Reach M+?

[santiago]

Dmitriy,

Attached find the images with how the settings are for base mode and RTK settings with just the M+ turned on. I haven’t moved anything since the day we had the flight. Please advice on what setting and workflow should be followed when using just the M+ and when using the Base and the M+ for a survey mission in PPK.

I’m very new to this so please forgive my ignorance in the subject.

We bought from you guys 2 Emlid Reach + (1 base and 1 rover) and the M+. Would it make a difference to use the 2 GNSS rather than just the base? Would be nice if I could skype with someone from support that could resolve all my doubts.

Thanks,

Santiagoattachments (2).zip (599.4 KB)

[santiago]

Hi Dmitriy,

Could you take a look to the files I sent you?

Best,

Santiago

[tatiana.andreeva]

Hi @santiago,

I’ve checked your logs and configurations.

The GNSS selection you use is correct. You can examine other recommended configurations for time mark logging by following this link.

Here’s the observation data you’ve shared:

There are a lot of cycle slips (red marks), and that’s not good. Each cycle slip points the moment when the signal is interrupted. Please refer to the article to learn more about signal quality.

Could you please share your hardware setup photos? It helps me to recommend you what you can do in order to improve the signal quality.

[santiago]

Hi Tatiana,

I have a few doubts. It says the M+ should be isolated in aluminum foil is this necessary to improve signal. We have a 11x11 cm aluminum metal plate under the GPS antenna, is it ok to use aluminum or better to use copper.

We’re using the M+ on a manned aircraft not a drone for now. One issue I see here is that the antenna cable is too short. Is there a way to extend this cable by using another antenna and welding the connector you have on your for the M+ or this not recommended. This is a huge issue because the antenna isn’t getting enough field of view without obstacles.

Attached find the images.

Thanks

[tatiana.andreeva]

Ho @santiago,

To resolve your issue with time marks you need to improve your log quality first.

One issue I see here is that the antenna cable is too short. Is there a way to extend this cable by using another antenna and welding the connector you have on your for the M+ or this not recommended. This is a huge issue because the antenna isn’t getting enough field of view without obstacles.

I’d recommend using Reach M+ antenna extension cable or something similar to it.

[santiago]

Hi Tatiana,

Ok I’ll work on correcting my log quality, but I have a question. Why does the LLH file show the coordinates in the correct position while the events registered in the UBX file fail to determinate the position and block on a single position, when the system seems to fail.

Thanks,

[tatiana.andreeva]

Hi @santiago,

Why does the LLH file show the coordinates in the correct position

How did you determine that LLH solution is in the correct position?

[santiago]

Hi @tatiana.andreeva

I found the LLH list of coordinates hadn’t been interrupted like the event.pos generated from the UBX file had been. What I did was relate in excel by the nearest time mark to the LLH file and that way linked the coordinates. I know the LLH file was in the correct position because I used the coordinates obtained from this file to finally process my images, not with very good precisión but at least it helped me in aligning the images correctly. You can check the raw files I’ve uploaded. We did another test yesterday, we managed to extend de cabled in order for the GPS antenna to be outside the plane without any obstacles, but still no luck the coordinates block at one random event and stay that way until the log is stopped. UBX and LLH.zip (5.6 MB)

It would be easier If I could skype with someone from Emlid to solve this issue cause this is taking forever through the forum.

Thanks,

[tobias-dahms]

Maybe the external camera power is a source of interferences?

[santiago]

Hard to tell. I’ll load photos of the whole way we have our setup and details on the electric part.

[tobias-dahms]

I think best best would be to test it by using the original battery of the camera and a usb power bank. I have noticed that it is possible that connected devices influence the receiver.