The todolist for OpenGPS
------------------------

11 June 2003
------------

 - Later on, use semaphores for writeGP2021, thus RWTask will suspend until the
 channel is done changing. (OBSOLETE)

 - Use semaphores to suspend tracking tasks until a channel is ready for
 tracking. (DONE)

 - RTAI tasks have FPU flag, we should use this

 - Change RWTask, no more writes (DONE)

 - Change 1kHz to 2kHz (DONE)

 - Asynchronously write to ring buffer, keep chHead pointer
 for each channel. (DONE)

 - Make sure currentCorr and corr values make sense (DONE)

23 June 2003
------------

 - What a command task handles 3 channels? We can't wait for
 multiple semaphores. A solution to this is to group semaphores and
 have one semaphore represent all 3 channles. (DONE)

 - survey only handles slew correctly for 1ms integration times, but
 for > 1ms integration times we should discard the last IQ dump value
 that we got. I'm going to ingnore this for now, perhaps a good implementation
 of this will occur to me later on.
 

26 June 2003
------------

 - When rtError gets called, the message sometimes doesn't make
 it into /var/log/messages - I think this is because some higher
 priority task interferes.

27 June 2003
------------

 - Currently all input/data files are statically programmed,
 change so that it can read that from a parameter file (DONE)
 - Change Power prompt to 1/4

29 June 2003
------------

 - Sometimes CH12 takes up to 30 seconds to have its accum new
 bit set, I don't know what the problem is with this.
 - Currently readTask waits for all 12 channels and then
 wakes up tasks, but what if a channel is doing a slew? It might
 take up to 1ms longer for that channel's data to become available,
 we don't want all other tasks to wait on this channel. I should
 use the chanUsed bits and make readTask more intelligent (DONE)
 - producerAdd doesn't correctly check whether it is actually
 producing the data that the sending task is asking for (DONE)

1 July 2003
-----------

 - Make sure that new readyChan implementation works, currently
 all accum_new bits are set and I can't check whether it works
 correctly when the channel data required is split up over
 two dumps.

14 July 2003
------------

 - Make sure that *ALL* data is being read and written to buffers for later
 access during DUMP and TIC.
 - Merge param->chan with Task[] struct, doppler windows and such must be in
 task struct, not in param-> struct.
 - Clean up global memory structs, make more intuitive.
 - Input file must be able to change priority of task
 - Currently OpenGPS doesn't run when you don't first run the plessey codes.
 This is also true for openGPSRec. It appears that everything inits fine,
 but for some reason the accum_new bits are never set.

15 July 2003
------------

 - IQ samples over different channels for same PRN sometimes match exactly and
 other times not. (DCO phase always match until survey changes carrier/code)

16 July 2003
------------
 - Add a 'use FPU' token in input files. For now they all use FPU

17 July 2003
------------
 - When I call producerDeleteAll() in cleanup_module() I get an
 'invalid page fault at virtual...' error. This problem started
 when I added carrier tracking tasks. The weird thing is that
 the page fault occured when surveyTask's producers were removed
 in cleanup_module(). For some reason too, I don't have RT Memory manager leaks
 any more. 

6 August 2003
-------------

 - When MAX_TASKS = 64 the program crashes?!
 - When I have too many tasks, and RTAI needs to allocate some more space, it
 appears to fail. [HACKED: I modified rt_mem_mgr.c and allocated 1MB instead of
 200kB, this ensures that I can run 64 tasks @ 16kB stack size before it needs
 to allocate (and fail) more memory]
 - Must find standard for sharing data that each task generates, for instance,
 carrierTask has a freqErr output and codeTask has a phaseErr output. Currently
 I just stick that into the corr ring buffer, but this is no good.
 - Must also figure out how to dump data to file. Currently readTask writes all
 raw IQ and DCO values.
 - FLL sometimes track at false point (GPS: Theory and Applications, p.382 fig. 31)

8 August 2003
-------------

 - Zero doppler happens when dopplerFreq (DCO) is at -1.5kHz, *not* at 0kHz I don't
 understand why this is so. OpenGPSRec also has this problem.

13 August 2003
--------------

 - Sometimes for small code phase values ( < 0.1 ) the yplot doesn't scale
 correctly.

14 August 2003
--------------

 - There are many things I don't like.
 1) What if a command task needs to start two survey tasks? I have to add many
 lines of code in different files to support this
 2) The filtered code tracking loop *sometimes* works - with 4 duplicate
 channels it will work 2/4 times. This is rather concerning, because on average
 all 4 channels get the same data - thus the loops must respond in the same way.
 3) Carrier tracking sometimes acquires a false lock - it might track 25Hz
 above/below the actual tracking point - as a result my IQ phase changes like
 crazy. I must write some lock detectors.

 - Plessey, ogr, and my code reported missed accumulations. A power cycle (5
 seconds) didn't fix it! After leaving the computer off for 9 hours, it worked
 again.

29 September 2003
-----------------
 - Timestamp data
 - Instead of rt_printk, use some #DEFINE DPRINTK so
 that it can be turned off later in the code
 - Standarise output of debug print statements, perhaps
 all of them should say OpenGPS < function name > : info

5 October 2003
--------------

 - Write lock detectors!!
 - Add pseudo range measurements

15 January 2004
---------------

 - Use lock detectors to switch states (thus re-acquire or coast)

16 January 2004
---------------

 - Keywords identifier are not case sensitive and 'code' matches both 'decode'
   and 'code'!!!

11 February 2004
---------------

 - I should write a 'interpreter' task, so that it virtually allows the
   user-side to send messages to the rt-side.

19 February 2004
----------------

 - For low-traffic FIFO's, generate a message structure so that the first byte
 can be used to determine what type of message follows, ie:
 1 - PRN select
 2 - TOW data
 
 - Must use some type of locking mechanism for selectPRN linked list (since many
	tasks may access it

25 June 2004 - Code Walkthrough
-------------------------------

- Read back code phase after slew.
- Email beyerle about slew
- Check accum new and see whether they are in phase (should be with multi)
- Write up failure about slew + feedback (do feedback on low level slew)
- Have a look at watchdog
- Other correlator CHIP - many correlators per chip
- Check dither mode (why or) - fix
- Dither mode in ch_select to code select
- PRESET bits get cleared
- Start chInit after TIC
- rstb bit
- write up rules for tracking satellite
- change survey to scan
- updateProducers should perhaps be updateConsumers
- commandTask->cmdTrackTask
- PLL gain issue + accum_new bits (get accum on diff dump)

21 July 2004
------------

 - BUG: TOW anomaly found in

 campaigns/20040419_BAO/tmp/20040419-1347/channel0_TOW.dat

 Dallas searched all other TOW from campaigns and didn't see anything amiss.
