While testing Differential Positioning (following the User Getting Started Guide) the system worked fine for a few minutes. Once I started to slowly move one Piksi both consoles reported "Error: Stack Overflow". Afterwards no further position estimate could be obtained.

The simplest multipath mitigation technique is to narrow the early / late correlator spacing. This should be easy to implement. We probably need to start with wide correlators for greater pull-in range and then narrow them once we have achieved a good lock. Programmable spacing would be nice.

• Add variable correlator spacing to Peregrine
• Test tracking loops still work in Peregrine
• A/B test to compare multipath in Peregrine
• Add variable correlator spacing to NAP
• Enable narrow correlator spacing in piksi_firmware

Developer installation docs should show how to install traits, traitsui, chaco, etc.
Potentially mention install the Enthought Python distribution.

This is necessary for each platform.

PRN 30 (SVN 35) is on the fritz and is currently marked as unhealthy. Piksi correctly detects this, and doesn't use it in the navigation solution. But it keeps tracking the satellite, wasting a channel.

Maybe this could be a configurable option as some users might be interested in the tracking data for unhealthy sats.

Built NAP firmware with 1 tracking channel and STM thinks there are 9

Changing settings.c and recompiling isn't very user friendly.

@gsmcmullin has started porting minini which will provide a good solution but this needs to be integrated and a general system for reading and writing to the filesystem created.

I don't have the hardware, I was looking for an example and reading your code....

I thought I saw a "bug", but apparently you guys found that as well:

In src/peripherals/usart_tx.c

• Note that this function is not reentrant and does not guard against DMA IRQs
• running at the same time which will also cause spurious behaviours. Ensure
• that the calling function prevents this from happening.

This bug that has now been solved "ugly" by requiring the calling function to disable interrupts can be solved much more elegantly:

Instead of updating the "wr" pointer before the copy-into-the-buffer, do so only AFTER copying. Thus a potential DMA interrupt will not think there is new data if it happens before the memcpy is finished.

I've written a patch for you, but I'm not sure if I can attach it. I'll try. (uncompiled, untested!) (but I've done this construct countless times before).

Even when tracking satellites on all the other channels, no solution is calculated if channel 0 is disabled. If channel 0 is enabled, even if it isn't acquiring a satellite, a solution is successfully calculated.

Seems to be something to do with enabling DMA once the radio detection has completed.

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

This is long overdue...

Due to explicitly importing things from Qt

Currently we CPSID before writing but that doesn't help if we were in the process of reading and is quite heavy handed anyway.

Use a mutex to properly lock around reads and writes of the ephemeris struct.

If the radio link goes down, the base loses and regains a satellite and then the radio link comes back up then the ambiguity has changed but the rover currently has no way to know that.

It would be good to have these!

Can we add the capability to hot-start Piksi from the console app by sending it the current position by hand, along with the almanac and time, so its possible to hot-start it?

Explain to people how to connect this as a primary or secondary GPS for Pixhawk.

Mention the DF13 cable that ships with Piksi is NOT APPROPRIATE for going into Pixhawk - the TX/RX needs to be flipped!

Currently the almanac will be used from the Flash so long as the valid bit is set. We really should have the almanac (and any other important files) checksum'd to check for corruption.

Perhaps this could even be added at the Coffee FS layer to provide this protection to all files automatically. The checksum of each block could be written into its header.

If the bootloader script is still waiting to enter bootloader mode then the only way to kill it is to send it a kill signal.

Put up the blast shields!

Check for NaNs between filter iterations and reset if necessary.

While testing Piksi (following the User Getting Started Guide) the system changed modes by itself (no user input). Originally the mode was Fixed and the distance estimate was reasonable (~0.08m). Then for no apparent reason the devices switched mode to Float and the distance estimate was way off (~7.5m). During the entire test both receivers were not moved.

Users have been setting the USB USART into NMEA or RTCM mode without realizing the consequences of this. USB USART should either always start in SBP or there should be some really obvious way to set it back into SBP in the Console.

Log file attached that shows going from 7 to 8 sats causing it to drop out of RTK mode.

https://www.dropbox.com/s/unnpuyoesnoca60/baseline_log_20140729-175224.csv.zip

Have a way for people to buy cables that connects Piksi to Pixhawk. This is something we should potentially ask 3DR to have in their store.

Currently differential position solutions are calculated from time matched observations between the base station and rover.

In order to increase the solution rate beyond the limitations of observation throughput over the radio and to reduce the latency of the solutions we can "propagate" the low rate base station observations to match the high rate locally generated observations.

The solution code is already structured so the low latency filter can be hooked in:

https://github.com/swift-nav/piksi_firmware/blob/4a5f1bac07591af17b641c52c360b563429350f6/src/solution.c#L355-358

Sometimes even when not gaining a satellite.

These fields should be filled in with the position covariance. This is really important for integrating Piksi with other systems' filters.

Would require calculation of position covariance from properly transformed measurement and ambiguity covariances. The ambiguity covariances are estimated in the float filter but would need to be properly exposed to the baseline computation.

Very occasionally a tracking channel will 'flatline', show constant SNR and otherwise become unresponsive.

Also observed by Mark:
https://groups.google.com/forum/#!topic/swiftnav-discuss/7SEQot696QQ

Bootload.py attemps to write to addresses 0x10001000 and up, which is outside of the flash range.

The commit that intodocues this is f1843c0.
The lines that introduce this is ./src/STM32F405xG.ld:124-128

Recommend an appropriate external antenna to use with Piksi.

the Linx Technologies one is good: http://www.mouser.com/Search/ProductDetail.aspx?R=ANT-GPS-SH-SMAvirtualkey59000000virtualkey712-ANT-GPS-SH-SMA

For better multipath rejection in a base station setup, the Novatel Pinwheel works great: http://www.novatel.com/products/gnss-antennas/high-performance-gnss-antennas/gps-701-gg/

Once a PVT Altitude Too High message gets received, even after a reset, Piksi does not receive observations coming in from radio.

I confirmed that the radio is indeed putting UART data on the line using a logic analyzer running in-situ.

flash.py's Flash.read, Flash.write, Flash.erase_sector commands will hang if these are called and the return message from Piksi is incorrect.

In Python Console, the command:
self.link.send_message(sbp_piksi.SETTINGS, 'uart_ftdi\0baudrate\01000000\0')
Results in Piksi output:
Error in settings read message

Can be fixed by doing:
self.link.send_message(sbp_piksi.SETTINGS, 'uart_ftdi\0baudrate\0%s\0' % ('1000000'.encode('ascii')))

Do we want to change link.send_message to support the former?

I'd like to point out to you guys that Andrew Tridgell recently ( in the last year) wrote a functional DGPS system in python ( using two uBlox recievers). It's solution isn't a 100% RTK solution, but it does use the cycle-count of the carrier phase data, which is a long way toward what you are looking to implement, yes? He is doing this over RTCMv2 messages, and with a uBlox LEA-6T and LEA-6H. ( if I remember correctly ).
details:
https://canberrauav.readthedocs.org/en/latest/in-progres/DGPS.html
repository/code:
https://github.com/tridge/pyUblox

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

The position is currently just a hard coded constant...

This is at 115200 baud, 128kbps air data rate, ECC off:

AT&F,ATS1=115,ATS2=128,ATS5=0,AT&W,ATZ

To recreate:

• start with a clean Piksi
• go to Settings, change "soln freq" from 10 to 6
• Hit "enter" to confirm that it changes in the list on the left
• Click "save to flash"
• Close the console
• reset piksi. Wait for it to boot.
• Open the console
• Go to Settings, hit Reload
• Soln Freq is back to 10

Should be a function to check if the ephemeris is valid, healthy and not too old.

This function should be used consistently across the codebase.