prn i is stored as (i-1) everywhere!

• Single-ended position
• IAR
• Float baseline
• Fixed baseline

Potentially via RANSAC or something simpler, or by looking at residuals from PVT.

Somehow it seems that a plover file gets deleted/removed during the make process. This then causes build problems that I don't really know how to solve. Can we have a default build option that doesn't rely on it to get built?

Found Haskell tools. Adding code generation step (to be run if Haskell subproject is modified).

-- Configuring done
CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   swiftnav

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /Users/mookerji/Dropbox/Documents/swift/libswiftnav/cmake
[  0%] Built target arithchk
[  0%] Generating arith.h
Scanning dependencies of target f2c
[  1%] Building C object clapack-3.2.1-CMAKE/F2CLIBS/libf2c/CMakeFiles/f2c.dir/uninit.c.o
Linking C static library libf2c.a
[ 13%] Built target f2c
[ 19%] Built target blas
[ 86%] Built target lapack
[ 92%] Built target cblas
Scanning dependencies of target generate
[ 93%] Generating ../../src/plover/ambiguity_test.c, ../../include/libswiftnav/plover/ambiguity_test.h
Package has never been configured. Configuring with default flags. If this
fails, please run configure manually.
Warning: The package list for 'hackage.haskell.org' is 126 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
Configuring libswiftnav-generate-0.1.0.0...
cabal: At least the following dependencies are missing:
plover -any
make[2]: *** [../src/plover/ambiguity_test.c] Error 1
make[1]: *** [plover/CMakeFiles/generate.dir/all] Error 2
make: *** [all] Error 2

@fnoble @kovach

I'm trying to use peregrine to analyze a fairly large file (~12 minutes of samples, 5.6GiB piksi format). Acquisition runs fine, but it segfaults systematically at 19% tracking (with or without re-using the acquisition data):

$ peregrine -a samples.piksi
 2014-06-27 08:23:45,959 [INFO] root: Skipping acquisition, loading saved acquisition results.
 2014-06-27 08:24:43,866 [INFO] peregrine.tracking: Tracking starting
 2014-06-27 08:24:43,871 [DEBUG] peregrine.tracking: Tracking 5 channels, PRNs [15, 12, 17, 24, 18]
  Tracking (CH: 1/5)  19% ETA:  0:03:00 |#########                                     |
Segmentation fault

From the backtrace however, it seems like the problem is inside libswiftnav, that's why I report it here:

#0  0x00007fae52fae893 in track_correlate (
    samples=0x7fac82990c28 ""..., 
    code=0xfabf20 ""..., init_code_phase=0x7fff277ea0b0, code_step=0.062499877161046859, init_carr_phase=0x7fff277ea0c0, carr_step=1.5700294860690449, 
    I_E=0x7fff277ea0d0, Q_E=0x7fff277ea0e0, I_P=I_P@entry=0x7fff277ea0f0, Q_P=Q_P@entry=0x7fff277ea100, I_L=I_L@entry=0x7fff277ea110, Q_L=Q_L@entry=0x7fff277ea130, 
    num_samples=num_samples@entry=0x7fff277ea0a0) at /usr/local/src/libswiftnav/src/correlate.c:57
#1  0x00007fae5297e81a in __pyx_pf_8swiftnav_9correlate_2track_correlate (__pyx_self=<optimized out>, __pyx_v_settings=0x7fae538668c0, __pyx_v_caCode=<optimized out>, 
    __pyx_v_remCarrPhase=<optimized out>, __pyx_v_carrFreq=<optimized out>, __pyx_v_remCodePhase=<optimized out>, __pyx_v_codeFreq=<optimized out>, __pyx_v_rawSignal=<optimized out>)
    at swiftnav/correlate.c:2314
#2  __pyx_pw_8swiftnav_9correlate_3track_correlate (__pyx_self=<optimized out>, __pyx_args=<optimized out>, __pyx_kwds=<optimized out>) at swiftnav/correlate.c:2153
#3  0x000000000052c6d5 in PyEval_EvalFrameEx ()
#4  0x000000000055c594 in PyEval_EvalCodeEx ()
#5  0x000000000052ca8d in PyEval_EvalFrameEx ()
#6  0x000000000052cf32 in PyEval_EvalFrameEx ()
#7  0x000000000055c594 in PyEval_EvalCodeEx ()
#8  0x00000000005b7392 in PyEval_EvalCode ()
#9  0x0000000000469663 in ?? ()
#10 0x00000000004699e3 in PyRun_FileExFlags ()
#11 0x0000000000469f1c in PyRun_SimpleFileExFlags ()
#12 0x000000000046ab81 in Py_Main ()
#13 0x00007fae58dedec5 in __libc_start_main (main=0x46ac3f <main>, argc=4, argv=0x7fff277eaab8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff277eaaa8)
    at libc-start.c:287
#14 0x000000000057497e in _start ()

The problem does not seem to be correlated with the length of the file (I reduced the file to one tenth of its length, and peregrine still segfaults at 19%), so I'm guessing it segfaults when trying to track the second satellite.

Some system information that may be relevant:

• swift-nav/libswiftnav@47f3827
• swift-nav/libswiftnav-python@8143b5c
• swift-nav/peregrine@e67d0c4
• gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
• libfftw3 3.3.3-7ubuntu3
• Python 2.7.6
• Ubuntu 14.04
• x86_64 / amd64

Need functions that will correctly unpack SBP messages for both little and big endian architectures.

Happens when one sat is dropped.

This is the underlying cause of swift-nav/piksi_firmware#159

Looks like it should just be a matter of transposing the M matrix. Would you want to move the populating of that matrix into a separate helper function, or just duplicate it in the new function?

Mainly printf formatting warnings.

running 'make docs' fails on my machine with:

---! Must increase the hyph_size
(Fatal format file error; I'm stymied)
make[3]: *** [docs/diagrams/costas_loop.png] Error 1
make[2]: *** [docs/diagrams/CMakeFiles/diagrams.dir/all] Error 2
make[1]: *** [docs/CMakeFiles/docs.dir/rule] Error 2

however, adding libswiftnav/src to the piksi_firmware Doxygen file can successfully generate the documentation.

The UDU factorization exists for symmetric indefinite matrices, but in our code, we want to maintain positive-semidefiniteness. Our Kalman filter's operations (performed on real numbers) would maintain positive-definiteness, so our actual numeric operations should maintain at least positive-semidefiniteness.

We recent changed the UDU decomposition algorithm from checking if the diagonal elements become non-positive to now checking if a diagonal element becomes non-zero.

We need to double check that this doesn't break the requirement of maintaining positive-semidefiniteness for the Kalman filter, and if it does, whether the correct fix is changing back to a non-positive check, of something else entirely.

(data flow from FW into filter)

Add assertions and sanity checks for common failure conditions such as number of satellite arguments being in a sensible range.

1342 u8 fits = inclusion_loop_body(
(gdb) p *N_cov_ordered@16
$35 = {1491378.3686824581, -93348.01535057585, 456224.42367533396,
-889490.15788424388, -93348.01535057585, 1852008.2489503184,
-45785.904954017227, -792817.34516954096, 456224.42367533396,
-45785.904954017227, 307401.52849414002, 42958.541583667742,
-889490.15788424388, -792817.34516954096, 42958.541583667742,
1483077.8191170169}
(gdb) p *N_mean_ordered@4
$36 = {-2561234.4842004091, 8788399.8654641248, 4066463.0112736765,
-12540846.750544041}
(gdb) p min_dds_to_add
$37 = 4 '\004'
(gdb) p state_dim
$38 = 4 '\004'
(gdb) p num_addible_dds
$39 = 4 '\004'
1187 memory_pool_fold(pool, (void *)x, &fold_intersection_count);
(gdb) p x->Z1
$40 = (z_t *) 0x2000ee10 <wa_time_matched_obs_thread+17848>
(gdb) p *x->Z1@16
$41 = {-134, -50, 207, -113, 225, 84, -348, 190, -51, -19, 79, -43, 289, 108,
-447, 244}
(gdb) p *x->Z1_inv@16
$42 = {-6, -1, 0, -2, 1, -9, 3, 8, -2, 1, 4, -1, 3, 7, 6, -3}
(gdb) p *x->box_lower_bounds@4
$43 = {2147483647, -2147483648, 824149833, -2147483648}
(gdb) p *x->box_upper_bounds@4
$44 = {2147483647, -2147483648, 824150866, -2147483648}
(gdb) p *x->itr_upper_bounds@4
$45 = {2147483647, -2147483648, 824150866, -2147483648}
(gdb) p *x->itr_lower_bounds@4
$46 = {2147483647, -2147483648, 824149833, -2147483648}
(gdb) p *x->Z2@16
$48 = {-134, -50, 207, -113, 225, 84, -348, 190, -51, -19, 79, -43, 289, 108,
-447, 244}
(gdb) p *x->Z2_inv@16
$49 = {-6, -1, 0, -2, 1, -9, 3, 8, -2, 1, 4, -1, 3, 7, 6, -3}
(gdb) p *x->Z@16
$50 = {1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1}
(gdb) p num_dds_to_add
$51 = 4 '\004'
(gdb) p num_current_dds
$52 = 0 '\000'
(gdb)
(gdb) p full_size
$53 = 1034
(gdb) p box size
No symbol "box" in current context.
(gdb) p box_size
$54 =
(gdb)
(gdb) p *x->intersection_size
$55 = -116391680
(gdb) p *x->counter@4
$58 = {-2078873256, -2147483648, 824149833, -2147483648}
(gdb) p *x->zimage@4
$60 = {-2078873256, -2147483648, 824149833, -2147483648}

e.g. mask and shift #defines to make it easier to read the flags.

calc_sat_pos should return an error if something is wrong (like too old an ephemeris) and should not just print an error message.

gives

error: duplicate 'const' declaration specifier

when we are doing const double const *.

Should be able to suppress by turning off the -Wduplicate-decl-specifier flag.

May need to include pyaml, jinja2, and some latex stuff for generate.py (among the other things)

Need to sanity check inputs.

If gps_time_t is not a packed struct, then calc_sat_pos+2496 issues a STRD to an unaligned address and segfaults.

If all structs are unpacked (aka there are no attribute((packed)) things), then Piksi never aquires.

All of this is with the v0.1pre1 NAP code, and a bootloader that scribbles 0xFE to the stack and 0xCD to the heap before jumping to the firmware.

Find functions that aren't used anywhere, and eliminate them.
e.g. almanacs_to_single_diffs()
/cc @fnoble

Support variable number of tracking loop updates per nav bit is rquired for swift-nav/piksi_firmware#65

We believe this is due to not having enough memory to add the full product of the new satellites and the existing hypotheses. We need to take advantage of the correlation between the new satellites and the old ones to reduce the new set size.

See #72

Some ideas:

• Better termination condition based on having a clear winner in the histogram
• Detect when the histogram doesn't show a clear winner
• Use a more sensitive technique such as integrating up the bit power for each of the bit phase hypotheses using 20 sliding integration windows of 20ms

Sometimes, it picks the wrong integers.

https://groups.google.com/forum/#!topic/swiftnav-discuss/NUet5ntbz9M

In gpstime.h

typedef struct attribute((packed)) {
double tow; /< Seconds since the GPS start of week. */
u16 wn; /< GPS week number. */
} gps_time_t;

ARMv6 and ARMv7 architectures support unaligned loads for everything everything except double-word structures.

This struct, since it is packed, can cause alignment crashes if an array of these are created and loaded, or if it is inserted into another packed struct.

Also move the console related issues over

Would you like to replace any double quotes by angle brackets around file names for include statements?

wgsned2ecef() current have the same first paragraph as wgsecef2ned(), which is wrong.

Some parameters (like "${PROJECT_SOURCE_DIR}" and "${DOXYGEN_EXECUTABLE}") are passed to CMake commands in your build scripts without enclosing them by quotation marks. I see that these places will result in build difficulties if the contents of the used variables will contain special characters like semicolons.

I would recommend to apply advices from a wiki article.

It turns out that with our current observation model, the KF update step is still a conjugate prior for the discrete amb_test, but it's even better since we don't have to restrict the set under consideration to any finite set. We can't get absolute probabilities (over the integers) easily, but it gets the relative probabilities exactly.

Using this for IAR with a simpler validation step may improve false lock rate and decrease resolution time. But it also precludes using fancier observation models, so that remains TBD and needs experimentation.

We anticipated this might happen here:

https://github.com/swift-nav/libswiftnav/blob/master/src/track.c#L613

@imh observed the issue in some HITL testing log files from Feb 15th.