# Capture stops in tunnel **URL:** \ **Category:** Android\ **Created:** [March 5, 2024, 8:56am UTC](https://forum.mapillary.com/t/capture-stops-in-tunnel/7861 "2024-03-05T08:56:14Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Eric\_S](https://avatars.discourse-cdn.com/v4/letter/e/aca169/32.png) [@Eric\_S](https://forum.mapillary.com/u/Eric_S)\ **Post date:** [March 5, 2024, 8:56am UTC](https://forum.mapillary.com/t/capture-stops-in-tunnel/7861/1 "2024-03-05T08:56:14Z")
Of course, capture stops in tunnel due to lack of GPS signal… but I’m using RTK GNSS + IMU (ublock F9R) and I still get a good estimated position in the tunnel: ![image](https://us1.discourse-cdn.com/flex015/uploads/mapillary/original/3X/0/0/0075142543b60ffbf58d13bd7292f6257d556a9f.jpeg) For one way, I got pictures all along the tunnel but it was interrupted in the backward way. You can check it there: > **[Mapillary](https://www.mapillary.com/app/?pKey=912332630356133)** > > Street-level imagery, powered by collaboration and computer vision. I imagine that the estimated accuracy was too high although one can see that the track is good. In earlier versions (android), it was possible to enable acquisition with poor accuracy. I would appreciate such an option or, may be, a more relaxed constraint when fix is “estimated” i.e. using IMU only. ---
**Author:** ![Yaro](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/yaro/32/71532_2.png) [@Yaro](https://forum.mapillary.com/u/Yaro)\ **Post date:** [March 5, 2024, 5:23pm UTC](https://forum.mapillary.com/t/capture-stops-in-tunnel/7861/2 "2024-03-05T17:23:13Z")
Yeah, this one is a stick with two ends, and hard to find a right balance of quality/freedom. @boris what do you think? BR, Yaro ---
**Author:** ![boris](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/boris/32/71767_2.png) [@boris](https://forum.mapillary.com/u/boris)\ **Post date:** [March 6, 2024, 9:16am UTC](https://forum.mapillary.com/t/capture-stops-in-tunnel/7861/3 "2024-03-06T09:16:56Z")
Interesting - does the RTK GNSS + IMU you’re using have an option to be paired with your Android phone? Then the accuracy could be high and everything would just work? ---
**Author:** ![Eric\_S](https://avatars.discourse-cdn.com/v4/letter/e/aca169/32.png) [@Eric\_S](https://forum.mapillary.com/u/Eric_S)\ **Post date:** [March 6, 2024, 11:24am UTC](https://forum.mapillary.com/t/capture-stops-in-tunnel/7861/4 "2024-03-06T11:24:08Z")
It is already paired with my Android Phone. I’m using Lefebure RTK software that is getting corrections from a RTK caster and send them with BT to the GNSS receiver. The receiver send back position through NMEA sentences. Then, Lefebure send it to other applications with Virtual Location (developper option). Indeed, accuracy is not very good along the track. There should be something wrong with synchronization. ---
**Author:** ![Yaro](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/yaro/32/71532_2.png) [@Yaro](https://forum.mapillary.com/u/Yaro)\ **Post date:** [March 6, 2024, 11:28am UTC](https://forum.mapillary.com/t/capture-stops-in-tunnel/7861/5 "2024-03-06T11:28:51Z")
So, you mean that because this device produces a better GPS the tunnel was captured successfully one way but failed to capture on the way back (same tunnel I assume). And by lifting GPS quality requirements a bit will help to get images with ok-ish GPS to mapillary. Am I correct here, @Eric_S? BR, Yaro ---
**Author:** ![Eric\_S](https://avatars.discourse-cdn.com/v4/letter/e/aca169/32.png) [@Eric\_S](https://forum.mapillary.com/u/Eric_S)\ **Post date:** [March 6, 2024, 6:02pm UTC](https://forum.mapillary.com/t/capture-stops-in-tunnel/7861/6 "2024-03-06T18:02:27Z")
In fact, while driving in the tunnel, I can see in Lefebure that the estimated uncertainty is increasing to meters (but I didn’t watched carefully values). Indeed, while checking NMEA logs, I don’t know where it get accuracy. Sample at tunnel exit (GSV sentences removed for clarity): ```auto $GNGLL,4412.0837477,N,00556.7948333,E,134507.00,A,E*7B $GNGST,134507.00,0.0000,20,7.9,154,7.5,4.6,3.2*40 $GNTHS,328.02,E*16 $GNRMC,134508.00,A,4412.0974116,N,00556.7827365,E,58.187,326.75,020324,2.31,E,E,V*6C $GNVTG,326.75,T,324.44,M,58.187,N,107.763,K,E*0E $GNGGA,134508.00,4412.0974116,N,00556.7827365,E,6,00,99.99,472.411,M,47.505,M,,*7B $GNGSA,A,2,,,,,,,,,,,,,99.99,99.99,99.99,1*30 $GNGSA,A,2,,,,,,,,,,,,,99.99,99.99,99.99,2*33 $GNGSA,A,2,,,,,,,,,,,,,99.99,99.99,99.99,3*32 $GNGSA,A,2,,,,,,,,,,,,,99.99,99.99,99.99,4*35 $GNGSA,A,2,,,,,,,,,,,,,99.99,99.99,99.99,5*34 ... $GNGLL,4412.0974116,N,00556.7827365,E,134508.00,A,E*7B $GNGST,134508.00,0.0000,23,8.5,153,8.3,5.1,3.4*41 $GNTHS,326.75,E*18 $GNRMC,134509.00,A,4412.1123090,N,00556.7698725,E,58.700,324.84,020324,2.31,E,D,V*67 $GNVTG,324.84,T,322.53,M,58.700,N,108.712,K,D*03 $GNGGA,134509.00,4412.1123090,N,00556.7698725,E,2,12,0.75,472.204,M,47.505,M,1.0,0000*6C $GNGSA,A,3,28,18,16,29,26,31,,,,,,,1.55,0.75,1.35,1*0C $GNGSA,A,3,78,77,88,87,,,,,,,,,1.55,0.75,1.35,2*06 $GNGSA,A,3,34,36,02,27,30,,,,,,,,1.55,0.75,1.35,3*01 $GNGSA,A,3,13,24,08,26,25,,,,,,,,1.55,0.75,1.35,4*0F $GNGSA,A,3,,,,,,,,,,,,,1.55,0.75,1.35,5*01 ... $GNGLL,4412.1123090,N,00556.7698725,E,134509.00,A,D*75 $GNGST,134509.00,89,8.1,5.6,162,3.2,2.4,2.1*79 $GNTHS,324.84,A*10 $GNRMC,134510.00,A,4412.1255542,N,00556.7565310,E,58.653,322.32,020324,2.31,E,F,V*6A $GNVTG,322.32,T,320.01,M,58.653,N,108.626,K,D*0C $GNGGA,134510.00,4412.1255542,N,00556.7565310,E,5,12,0.67,472.365,M,47.505,M,1.0,0000*6D ``` ---
**Author:** ![Yaro](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/yaro/32/71532_2.png) [@Yaro](https://forum.mapillary.com/u/Yaro)\ **Post date:** [March 7, 2024, 9:33am UTC](https://forum.mapillary.com/t/capture-stops-in-tunnel/7861/7 "2024-03-07T09:33:22Z")
@Eric_S I’m not sure how to read all the values in here, but I think that’s not needed. Based on your answers you are using [this approach](https://community.gpswebshop.com/2021/10/18/how-to-use-a-rtk-gnss-receiver-for-android-a-step-by-step-guide/) to share the location with the phone (i.e. mock provider Lefebure). I didn’t use this application itself, but used mock providers in general and they work correctly with the app. So, I am pretty sure the root cause of the missing images is the accuracy. To give more details, Mapillary app considers GPS good when [the accuracy](https://developer.android.com/reference/android/location/Location#getAccuracy()) is less than 30 meters (see the accuracy definition above). The perfect solution here is to use structure from motion (or similar) to detect the position from the last successful GPS, but that’s not the part of the app. I don’t see any half solution except lifting the lower bound, but that will cause more problem when app starts to capture with yet too bad GPS. cc @boris BR, Yaro ---
**Author:** ![Eric\_S](https://avatars.discourse-cdn.com/v4/letter/e/aca169/32.png) [@Eric\_S](https://forum.mapillary.com/u/Eric_S)\ **Post date:** [March 7, 2024, 9:38pm UTC](https://forum.mapillary.com/t/capture-stops-in-tunnel/7861/8 "2024-03-07T21:38:31Z")
Yes, I use the approach mentioned. I will check next time that I cross a long tunnel what is going one with accuracy and if it reaches 30 m. ---
**Author:** ![Yaro](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/yaro/32/71532_2.png) [@Yaro](https://forum.mapillary.com/u/Yaro)\ **Post date:** [March 8, 2024, 2:37pm UTC](https://forum.mapillary.com/t/capture-stops-in-tunnel/7861/9 "2024-03-08T14:37:04Z")
Thanks @Eric_S. There is even a chance that these 2 are connected. PS the [second](https://forum.mapillary.com/t/new-smart-spacing/7318/23). BR, Yaro