This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL1871 support

Other Parts Discussed in Thread: AM3352

Hi,

I am not quite sure where to ask this question, so I'd appreciate if you could please redirect to the appropriate venue/personnel if this is not the right one.

We use a module that is based on TI WL1871 - this module doesn't seem to have any information from the TI website, but it seems it is manufactured and supplied under TI license by an OEM module vendor, Jorjin. We have been using it based on recommendations from TI sales personnel, but there is very limited technical information from the OEM.

Is there any TI contact we can reach out to obtain detailed technical information ? In particular, we need detailed technical info on the GPS receiver in this module. If NDA etc. are needed, we'd be happy to engage on that basis. Please let me know.

Thanks,

Best regards,

Anand.

  • Hello Anand,

    Can you please send the questions you have here
    and we will make sure to send you all needed information.

    BR,
    Chen Loewy
  • Hi Chen,

    Thanks, our questions are with regard to the GPS on the module:

    1. Regarding the PPS signal, we observe an offset in the generated PPS signal relative to reference receivers.  The offset appears to be on the order of several microseconds and appears to be always present from hour to hour, day to day; even as the PPS 'jitters' around the observed offset, the observed offset appears to remain fixed with regard to the PPS signal generated by reference receivers.  So, the questions in this regard are:

    - is there a reason the WiLink firmware might be introducing such a fixed offset?

    - is there a parameter that we need to understand and tune to correct for such an offset? 

    - what is the specification for PPS accuracy?  (For this testing we are in a static location)

    2. Regarding April 2019 GPS week number rollover:

    - what is the guidance for this module, will it be an issue? 

    - If so, what are the suggested mitigations in the host software?

    Thanks,

    Best regards,

    Anand.

  • Hello Anand,

    I have looped in our GPS expert KNS.
    He will help you with these issues.

    Chen Loewy
  • Hi Anand, 

    Thanks for reaching out for support!! WL1871 supports GPS, Glonass, SBAS (WASS, MSAS, EGNOS) and QZSS constellations. One of the key highlights of the device is that it can simultaneously decode the data from all the constellations listed above. This approach provides a very good Time To First Fix (TTFF) in autonomous and assisted mode of operation. 

    In order to help you better can  you please let us know the following details - 

    - What is the end equipment targeted with this device? 

    - Is there a specific host platform and OS that you have decided to use for development? 

    Please let me know these details and i will be glad to help you with the required information and support. 

    Best Regards, 

    Sudharshan K N

  • Hi Sudharshan,

    1. The end equipment is an industrial IoT gateway that we make in which the WL1871 is integrated along with various other communications functionalities such as cellular, ethernet etc. The applications are all industrial monitoring and control applications.

    2. The host processor is Sitara AM3352, running Linux  4.9.44. We use the kernel TI shared transport driver with gps driver in kernel plus UIM + devproxy + agnss_connect in userspace. For the module firmware, we are using firmware ti-connectivity/TIInit_12.8.32.bts.

    Just to confirm: the end-to-end driver and application functionality is fine, GPS fix is acquired etc. We just had the specific questions about the offset and week rollover that I had mentioned.

    Please let me know if you need any other information. Thanks for your help,

    Best regards,

    Anand.

  • Hi Anand, 

    1. PPS - we do not compensate for the offset learnt from the clock. i can check again and see if we can add a parameter to compensate for this. Also is this offset observed after the location fix? 

    2. Rollover - the current solution can support till 10/27/2019. We can modify this in the service pack to support for future rollovers. 

    Regards, 

    Sudharshan K N

  • Hi Sudharshan,

    1. Yes, the offset is observed even after the location fix has been achieved. I have attached two traces that show what we observe.

    In Fig. 1 the blue trace is the PPS signal from a reference timing receiver, and the orange trace is the PPS signal from the WL1871 module. As you can see, the WL1871 signal is shifted by about 5.5 us. We have captured the trace over many hours, and observed that the offset always remains and doesn't improve.

    Fig. 1

    Fig. 2 below is a close-up of the PPS signal edge - as expected, it jitters around, but the jitter itself is pretty small, of the order of +/-70 ns. So, it would seem that the module timing accuracy spec should be able to quoted as approx. +/-70 ns, but the systemic offset of 5.5 us makes it much worse. Since the offset is always there and is also pretty large, it almost seems like an artifact some software behavior in the module, rather than a function of the receiver capability. So that's why were wondering if there is any way to correct this.

    Please let me know your thoughts.

    Fig. 2

    2. With regard to the rollover, thank you for the information. Do you have a scheduled date when a service pack update might be available to handle the rollover?

    Thanks,

    Best regards,

    Anand.

  • HI Anand,

    Thanks for sending this data!! Does the offset vary based on the TCXO offset clock? Pl let us know if you have performed any such experiment. Also is the offset constant across different devices or vary from device to device.

    Regards,
    Sudharshan K N
  • Hi Sudharshan,

    1. We haven't changed the TCXO offset to check on the behavior - I am not quite sure how to do this. We do have the document titled "WL187x and WL187xQ GPS Interface Control Document Air Independent Interface (AI2), v0.9" from TI under NDA. Is this the interface to use for controlling/varying TCXO offset, and can you let me know what command packets to use with this interface?

    2. We have observed the same offset across multiple devices, although we haven't quantified the precise number across devices. So, it is definitely not a one-off observation that might be the result of one faulty device.

    Please let me know.

    Thanks,

    Best regards,

    Anand.

  • Hi Anand, 

    On #2 can you please provide us the numbers if it is handy with you. Also what is the FW version used for performing the tests?

    Regards, 

    Sudharshan K N

  • Hi Sudharshan,
    With regard to #2, we have now checked four more devices and all are showing the same ~5.5us offset.

    With regard to the the firmware version, as I mentioned before, we use the firmware ticonnectivity/TIInit_12.8.32.bts, so I guess the firmware version is 12.8.32 (?) If you are looking for some other version number, please let me know how to obtain.

    Best regards,
    Anand.
  • Hi Anand,

    Thanks for the information!! I will check if there is any SW latency that is not accounted for while programming the PPS.

    The FW version that you mentioned is for BT. There should be another one for GPS with the following name - dproxy.conf. Please send me this file. i will take a look at the version and check from my side.

    Regards,
    Sudharshan K N
  • Hi Sudharshan,

    Attached please find the dproxy.conf file we are using.

    We do see two patch files in the source tree for this file: 1) dproxy.patch_1_9_2_0 and 2) dproxy.patch_2_0_0_35. We haven't applied either of these patches so far, should we applying either of these, or both, one after the other? Do the patches have anything do with the issue we have been discussing? Please let me know.

    Thanks,

    Best regards,

    Anand.dproxy.conf.zip

  • Hi Anand, 

    Thanks for providing the patch!! The patch is basically a Service pack (SP) for the FW inside the device. Can you please provide both the patches? 

    The patches/SP in general has fixes to FW including parts of the PPS functionality that we are discussing. The patch/SP is downloaded based on the settings contained in dproxy.conf file. 

    in dproxy.conf file following settings will automatically download the SP to the device

    down_load_opt = 1

    patch_path = /etc/gnss/patch/dproxy.patch

    The two flavors of the patch are based on two different ROM versions. You can send both the versions to take a look at them. 

    Also we can have a call to discuss this further and let me know what is the best way to directly contact you. 

    Regards, 

    Sudharshan K N

  • Hi Sudharshan,

    Yes, I do think it is a good idea to have a call. Do you have a good time on Fri or early next week? Please let me know. You can certainly contact me direct at anand@machfu.com.

    Right now, we have 3 patches for dproxy.conf, named: 1) dproxy_rom.patch, 2) dproxy.patch_1_9_2_0, and 3) dproxy.patch_2_0_0_35. We are not  quite sure if any of them are used in our build, and we are working to verify now. We will try these and see if it has any effect on the PPS behavior.

    I have the patch files with me, but can you confirm if you want me to send you the actual patch files on this forum? I believe there is an NDA in place, so I was not sure if you wanted me to send this here, or direct? Please let me know.

    Thanks,

    Best regards,

    Anand.