none
Dragonboard 410c geolocation issue: only occasional data from GNSS RRS feed

  • Question

  • Hi,

    We're using the Dragonboard 410c as a base for our field gateway, but we're having problems gathering GNSS data from the devices.
    The board runs Windows 10 IoT Core v1809 (10.0.17763.253) and a UWP app using the Windows.Devices.Geolocation.Geolocator class to obtain satellite data. However, .GetGeopositionAsync() almost never returns a Satellite coordinate as the position source. The resulting coordinates are almost always based on WiFi or IPAddress, which is far too inaccurate.
    That's why we only keep the coordinates coming from a satellite source and skip the rest. Apart from the Geolocator, is there another way to get satellite data?

    I know the onboard antenna is weak, that's why we use high quality external antennas supporting GPS, Glonass and Galileo. The antennas are connected with a UFL connector. I have tested a lot of different (active) antenna types, but they all have the same poor result.

    We currently have over 150 devices in the field, but we can't find the reason why satellite reception is so poor. Also, the antennas are mounted so they have a clear view to the sky.
    The strange thing is that sometimes the satellite data does come through from the devices and when it does, the position is very accurate. So we can conclude that the setup works.

    Furthermore, I've tested the same setup (board, antenna, location, power supply,...) using a Linux image. Here, a correct satellite fix is obtained between 20 seconds and 2 minutes depending on the weather, while the UWP app can't get a satellite fix when running for a few hours...
    The tool I used on Linux shows a lot of information, including NMEA sentences. Even on a cloudy day, the device is able to have 16 satellites in view (of which 10 are being tracked). Is there a way to get access to this kind of information in Windows 10 IoT Core?

    Perhaps there is a bug in the Qualcomm GNSS driver, but I have no idea how to check this.

    It feels like the Geolocator is not waiting long enough for a satellite fix, then just aborts the operation after a minute and returns a coordinate based on Wi-Fi or IP address.
    Maybe the weather conditions - in combination with the theory of the Geolocator not waiting long enough - could explain the "random" results: on cloudy days the satellite fix takes longer than a minute, but the process is aborted; and on a clear sky day, the fix takes less than a minute, resulting in coordinates from a satellite source.
    Unfortunately, I have no idea how the Geolocator is implemented, so this is just a guess. Maybe someone here can shed a light on this?

    While investigating this theory, I've tried using the .GetGeopositionAsync(TimeSpan maximumAge, TimeSpan timeout) overload with a longer time-out (half an hour), but the method always returns after 2 minutes max without a satellite fix.
    It would really help if we could have some more information about how the Geolocator class works. Or even better: have another way to obtain the satellite data (including details, like for example the number of satellites in view).

    Another thing I've found on the internet is this article: https://support.microsoft.com/en-in/help/3155465/location-apps-can-t-retrieve-the-correct-gps-location-data-in-windows
    This describes a similar issue where "the GNSS location sensor takes longer to get a reading than the cellular or Wi-Fi sensor. The original API doesn't wait long enough for this GNSS-only scenario".
    This looked promising, even though Windows 10 IoT Core was not listed in the "applies to" section.
    Anyway, I tried setting the WaitLongerForGPS registry key, but it didn't change anything in the behaviour. Maybe the issue we're experiencing is related to this one?

    For now, I'm out of ideas, so any pointers as to why satellite performance is so poor on Windows 10 IoT Core or ways to improve this would be greatly appreciated!


    Regards.

    Wednesday, October 16, 2019 2:10 PM

All replies

  • Hello crates_barrels,

    May i know if you have tested with the sample here? Not sure you added the locationHistory capability in your UWP app. This capability is required to use APIs in the Windows.Devices.Geolocation namespace.

    As you mentioned, the antenna on-board is very weak, in many conditions you'll need to implement an external passive or active antenna in order to boost the signal. (https://developer.qualcomm.com/qfile/29467/lm80-p0436-42_add_ufl_ant_and_valid_gps_on_android_app_note.pdf). 

    Did you connect an active antenna to the board with own power circuit, feeding the antenna 5.0v and AC coupling with the U.Fl connector? In general, it takes less than a minute to fix indoor and next to a window.

    Best Regards,

    Michael


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, October 17, 2019 3:11 AM
    Moderator
  • Hello Michael,

    Thank you for your response!

    I did not test the sample you mentioned before, but gave it a try just now. Unfortunately this sample is also only returning coordinates based on Wi-Fi (or IP address), but no satellite data.
    Also, I did not try including the locationHistory device capability yet, only the location capability. I thought this was enough, since the satellite data occasionally does come through and the sample you mentioned also only includes the location capability). Anyway, I tried adding the locationHistory capability to the UWP app, but it didn't help.

    The active antenne is indeed connected to the board using a U.Fl connector. 1.8V is supplied to the antenna, and the antennas support this 1.8V. I'm also pretty convinced this setup works, because the GPS monitor on Linux is capable of getting a fix between 20 seconds and 2 minutes on exactly the same hardware and configuration.


    Thursday, October 17, 2019 9:01 AM
  • Hello crates_barrels,

    Not sure this issue is about the driver on Windows IoT Core on DragonBoard. A workaround is that, you may try to use a external GPS module with I2C or Serail Port interface, and then you can get the location information from the GPS module output.

    Best Regards,

    Michael


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, October 17, 2019 9:26 AM
    Moderator
  • Hi Michael,

    We already thought the same thing in terms of workarounds, but it would be best to have the issue fixed at the core. The devices have all the necessary (and working) components embedded, so we think it should definitely be possible to get these components to do their job in Window 10 IoT Core as well...

    If you're not sure if this is an issue about the driver in Windows 10 IoT Core, what could be other possibilities causing this?
    I am willing to test deeper and try to get "raw" values from the GNSS sensor, but I don't know where to start as the sensor driver does not expose a serial port (at least not in UWP). If you can help me how to get the raw sensor data, I can try to help pinpointing the root cause.

    Regards.

    Thursday, October 17, 2019 2:41 PM
  • Hello crates_barrels,

    It is hard to diagnose this issue when you don't have the driver code. You might try to contact the support of Qualcomm.

    Best Regards,

    Michael


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, October 18, 2019 1:59 AM
    Moderator