A bug in decode_ephemeris function

[yigiter]

The following lines are from decode_ephmeris in ephemeris.c (Link to Code)

805: / GPS week number (mod 1024): Word 3, bits 1-10 / 806: u16 wn_raw = frame_words[0][3-3] >> (30-10) & 0x3FF; 807: e->toe.wn = gps_adjust_week_cycle(wn_raw, GPS_WEEK_REFERENCE); 808: k->toc.wn = e->toe.wn;

As seen from this code, the week number in subframe 1 is used as the week number for toe and toc. However, the week number in subframe 1 actually represents the week number of time of transmission (in other words, tow-count in HOW). The original navigation words do not contain any week number information for neither toe nor toc.

In order to convert week number of time of transmission to week number of toe or toc, something similar to below has to be done:

weektoc=wn_raw; if (toc.tow<tof-302400.0) {weektoc++;} else if (toc.tow>tof+302400.0) {weektoc--;} toc.wn= gps_adjust_week_cycle(weektoc, GPS_WEEK_REFERENCE);

where tof is the time of transmission extracted from HOW (i.e. TOW_count*6.0). Unfortunately, in the current code, the first 2 words of subframe data in not passed to the decode_ephemeris. Hence we cannot extract TOW_count to perform the above transformation.

As long as the satNav data is updated every 2 hours, this does not create any issue during week transition. However, I believe, it would be better if this bug is corrected without relying on satNav upload intervals.

[ljbade]

This has been fixed in the Piksi Multi firmware. We are not planning to release an update to fix it on the older Piksi models at this stage.