Monday, 12 May 2003    
In   :	08:30
Out  :	15:30
Hours:	7

Log  :	First day at work, I moved jasmine up to the new
	lab, ECNT 226. This space is rather nice I think,
	some music will help though.

	I had a meeting with Penny and Dallas at 10pm,
	we talked about the timeline for First RF.
	Apparently we would like some kind of graphical
	demonstration by 21st of June.

	Apart from that, I figured that the opengps software
	has some frequency offset, which allows us to
	easily pick up red-shifted signals, but no
	blue-shifted ones. This has to do with the baseband
	frequency that the plessey receiver is set at during
	init. I'll look into this tomorrow.

Tuesday, 13 May 2003
In   :	09:50
Out  :	16:30
In   :	23:00
Out  :	23:30
Hours:	8

Log  :	Another day. I plan to figure out the frequency offset today
	by comparing the two codes to each other. After this is done I'll
	try Dallas' experiment to see if the two different front-ends
	behave differently. Man... I really need music here.

	OK, I remember now that the other GPS code corrected for
	clock error (statically set for now). I set this clock
	error to zero. Let's see what she does. Hmm.. the clock
	error doesn't really have an effect on it.

	I have looked at the plessey codes and they appear to use
	the exact same carrier hex value. Thus the doppler 
	problem might be somewhere else. I'm going to run
	the plessey dos codes and see what the doppler is.

	Hmm... doppler seems normal with these codes. I don't
	understand.

Wednesday, 14 May 2003
In   :	08:40
Out  :	18:30
In   :	22:00
Out  :	23:00
Hours:	10

Log  :	An interesting test for the day: See if I pick up a sat
	at -5kHz, whether it still appears at -5kHz when the
	doppler window is extened to -10kHz

	Finally, I spent a big part of today setting up jasmine to mount
	/usr/local from ccar. This is setup now and matlab runs very well. I
	had some issues with permissions, but this is fixed now too.

	I corrected my code for the frequency flip that is introduced during
	the 4th stage of downconversion. (Section 4.3 in Technical Notes of
	plessey)

Thursday, 15 May 2003
In   :	09:00
Out  :	15:00
Hours:	6

Log  :	Today I modified the opengps source to support 'idle' channels. These
	channels will not be touched by the acquisition software - but their i
	and q values will be dumped. I then used these files to analyse RF1/RF0
	- it appears that there is always a 1.23 gain on RF1 wrt. RF0.

	The next step would be to change the code so that we average I/Q over
	one second and then just dump the second. This way a long duration test
	can be run.
	
Friday, 16 May 2003
In   :	10:15
Out  :	17:00
In   :	18:00
Out  :	20:20
Hours:	8

Log  :	Well, ccar went down last night and just came up, thus I couldn't run
	my long duration test. Let's get that running quickly before the 2pm
	meeting.

	Hmm... Couldn't get 'er running in time. I'm going back to old code.
	Currently this code is dumping I/Q every 1ms - then I just average the
	power over 1 second and plot that.

	I'm learning RCS for now, it is not as powerful as CVS, but it will have
	to do.

	Well, I modified matlab so that we can now read raw I/Q vaules.

	Hmm... This is a problem: Matlab's matrices need to be the same size, thus 
	if I have different channel IQ data of different lengths, it won't work.
	There are two ways around this:

	1) Always make sure that you record n samples for each channel -> but when
	if the channel is DONE and other channels are not... record noise?
	2) Figure out how to create variable matrix size - or perhaps store in
	separate variables.

	Well, time to go.

Saturday, 17 May 2003
In   :	18:45
Out  :	23:00
Hours:	4

Log  :	I'm going to fix up the goldbox so that we can get more data concerning
	the RF1 gain issue.

	Oops... No goldbox fixup today. I struggled with matlab to get my scripts
	to give valid data. I forgot that I changed the program to dump 6 words,
	and not 7. Apart from that, I'm trying to figure out how to average I and
	Q over a long time. Just adding 1000 and dividing the sum by 1000 will
	give a value close to zero because of gaussian noise. 

	A few questions:
	
	1) How to obtain I/Q over a long time
	2) How must I/Q data be available to user program? Perhaps just via shared
	memory? This way A user program can access raw I/Q as fast as it can. 
	3) Perhaps also an average power that is updated every 10ms in shared
	memory will do. This way A GUI can nicely display average power in
	real-time.
	
	Yes, I should add this to opengps:

	1) In channel.txt one can specify if this channel should dump
		- IQ (1ms dumps)
		- Power (variable ms average dumps)

	Perhaps this data should also be available in shared memory for 
	a GUI to access.

	For now, it is time to go.

Monday, 19 May 2003
In   :	09:45
Out  :	15:30
In   :	19:30
Out  :	21:30
Hours:	7

Log  :	Well, today I'm going to run some of Dallas' tests (vary input
	impedance on RF inputs) and see what happens. Also, I would like to get
	the carrier pull-in algorithm running today. The working of the
	algorithm can be confirmed with a polar(theta,A) plot.

	I'm busy seeing whether the 'confirm' code works. Currently
	it picked up all 7 satellites that the novatel picked up!
	This is good news. PRN16 (+3134 doppler) wasn't picked up
	for a while, I think that the code doesn't search up high
	enough.

Tuesday, 20 May 2003
In   :	12:30
Out  :	15:50
Hours:	3.5

Log  :	Well, I did some of those termination tests today, no new
	results really. I'm going to work on the tracking loops now, I
	have only about a week to get it running.

Wednesday, 21 May 2003
In   :	13:00
Out  :	16:30
Hours:	3.5

Log  : Tracking loop time. Well, I added the pull in algorithm,
	it works very well!


Thursday, 22 May 2003
In   :	13:00
Out  :	18:00
Hours:	5

Log  :	Now let's see if I can get the tracking algorithm to run.

Friday, 23 May 2003
In   :	10:00
Out  :	17:30
In   :	21:00
Out  :	22:00
Hours:	8.5

Log  :	Hmm... the tracking loop is not working well, it appears
	to just drift off the carrier at about 25Hz/second.

	This is very interesting. 

	After many hours of changing settings, I don't know
	what is going on. I might just go with the OpenGPSRec
	code and patch it until it works for our purposes.

	I find that approach repulsive.

Tuesday, 27 May 2003
In   :	09:15
Out  :	18:20
Hours:	11.5
In   :	20:30
Out  :	23:30

Log  :	Big decision day. I have to figure out which route we are going
	to take concerning the GPS codes. There are several
	possibilities:

	1) Use current OpenGPSRec code and modify so that we can easily
	plot certain data, set up channels to certain front ends.
	2) Use OpenGPS code and add plessey tracking code to it.
	3) Take plessey code and compile under linux.
	4) Start from scratch and use Plessey as a model.

	Either way, for all these options we need to decide exactly what
	we want to do so that we can keep the code generic and easy to
	modify for other tracking modes, etc. Approach #3 will not be
	open source.

	Personally I like approach 3 and 4. The Plessey code is very
	well documented and all tracking loops are mathematically backed
	up in their documentation and comments.
	
	Taking Plessey code and compiling under linux is the quickest
	option, but can the code be modified so that future additions
	can be done in a organised manner?

	Apart from thinking about how to approach the problem, I put the PC104
	daughterboard into the ISA slots and ran some test on it, it appears
	that we have that same offset problem.

Wednesday, 28 May 2003
In   :	10:00
Out  :	14:00
Hours:	4

Log  :	It took a lot of time to put the PC104 box together again. I dislike
	the PC104 mechanical design. Right now I'm brainstorming some ways to
	approach the OpenGPS design goals (and come up with goals).

Thursday, 29 May 2003
In   :	13:00
Out  :	17:00
In   :	20:00
Out  :	01:30
Hours:	8

Log  :	Dallas and I are discussing different modes that we want supported by
	the new GPS code. So far we came up with:

	1 - Survey Mode: Sweep through code and doppler, dump IQ and other
	data. Properties include
		+ Code phase to search for (can be static at one code)
		+ Doppler space to search for (can be static at one freq)
		+ Chip increment
			- ch_code_slew (gives 1/2 chip resolution) 1ms
			- ch_code (custom chip resolution) n-ms?
		+ PRN to search for
		+ How long? Repeat once done with sweep?
	
	Questions: 
		- What format do dump I/Q in?
		- Long data dumps, need GB of data, perhaps average power
		and dump that
		
	OK, I have spent some time on my whiteboard at home to figure out how to
	structure the OpenGPS program. This is starting to look good. I also did some
	math to illustrate that the code frequency can easily be changed for a short
	period of time to get less than 1/2 chip offsets. If f1 is the code generation
	frequency, then in order to offset the correlator by x-chips (can be a
	fraction), the formula is f2=f1(x+1), f2 will be the output frequency. The
	desired code-offset will be reached after 1ms, and must then be changed back to
	the original frequency.

Friday, 30 May 2003
In   :	09:45
Out  :	16:30	
Hours:	6.5

Log  :	Today I'm going to meet with dallas and discuss different modes of the
	receiver more thoroughly.

Monday, 2 June 2003
In   :	13:40
Out  :	17:50
In   :	19:20
Out  :	23:10	
Hours:	8

Log  :	Time to start implementing some of the ideas that Dallas and I talked
	about on Friday. Basically we come up with a way where you don't need
	many different modes, but can just specify the workings of the receiver
	with the input file.

Tuesday, 3 June 2003
In   :	09:00
Out  :	18:00
Hours:	11
In   :	19:00
Out  :	23:00

Log  :	I spent a big part of yesterday redoing the code. I ran into some RTAI
	problems, this is not solved yet - but the code looks much better so
	far. I'm going to try and get the initialisation stuff done today so
	that we can move on to tracking loops.

	Well, the init stuff is not done yet. I'm debugging RTAI currently.

	I also ran some tests with the PCI/ISA daughter boards today with
	the preamp hooked up. It didn't make any difference to the gains.

Wednesday, 4 June 2003
In   :	08:00
Out  :	17:00
Hours:	8

Log  :	Oh dear, I'm having some problems with my dumpIQ function,
	it appears that in 24,000ms I dump 30000 I/Q samples, which
	is not possible, since in 24kms I should dump 24k samples.

	Perhaps I am reading accum_status_a incorrectly?

	OK, I found the errors:

	1) I didn't shift CODE_REF by 4 (scaled by 16 for extra bits
		of software precision). This caused more than 1000 dumps
		in 1 ms.

	2) The 505us and 1ms task have special cases where the 1ms task
	might miss a update from the 505us task.

	3) When I stick all channel data into one FIFO (for loop), it
	SAYS that data was written correctly, but on the other side
	random blocks of IQ_DATA_USER contained wrong data. (not dropped,
	just wrong)

Thursday, 5 June 2003
In   :	08:20
Out  :	18:00
Hours:	12
In   :	19:00
Out  :	22:10

Log  :	Dallas and I talked about how to share this IQ data between the user
	and tracking/acquisition code. We came up with the idea of using a
	"shared memory shift register" approach, where Shared Memory (SM) will
	written to in an array format. This means that if a tracking loop needs
	the previous 10 I/Q samples, it will read element 1-10 of the SM array.

	I'm going to implement a 500us and 1ms task and see whether problem #2
	from above still occurs - it shouldn't.

	Ok - that fixed the problem.

	I implemented a nice shared memory ring buffer today. I'm still having 
	some issues with missing I/Q samples - I know how to solve this though.

Friday, 6 June 2003
In   :	08:30
Out  :
Hours: ~8

Log  :	Today will be spent coding. I have the ring buffer implemented
	well, but there are still a few things I need to check. I really
	want to implement some code that does acquisition today, that
	way I can prove that this new architecture works. 


Monday, 9 June 2003
In   :	13:00
Out  :	21:00
Hours:	8

Log  :	After thinking about the code all weekend, I made some
	changes to so that it supports 'multi-threading' better.
	Basically I made sure that if a long task gets interrupted,
	it will still return valid data.

	Now I'm writing my 500us Write task.

Tuesday, 10 June 2003
In   :	08:37
Out  :	17:27
Hours:	12
In   :	19:00
Out  :	23:00

Log  :	The 500us 'write' function is now done. I'm busy doing acquisition, but for some
	reason I get valid I/Q samples, but no correlation. I'm investigating.

	Ok, the correlation works now, I wrote incorrect data to the slew register.

	Currently I'm making sure that data is synchronized between RWTask and
	other tracking loops. It looks good so far, except for ch_code_slew(), which
	seems to be behaving in an odd fashion. Plessey doesn't even use slew, they
	just change the code DCO to slide relative to the incoming signal.

Wednesday, 11 June 2003
In   :	09:00
Out  :	19:00
Hours:	8.5

Log  :	Since acquisition appears to work well, I might move on to the next stage - pull
	in. But before we can do that, it will probably be best to get some input file
	going where these properties can be defined. Dallas and I are also going to look
	at timing issues.

	Dallas and I talked about timing issues, etc. I'm rewriting some of the code
	to incorporate these new ideas.

Thursday, 12 June 2003
In   :	10:00
Out  :	18:00
Hours:	7.5

Log  :	After finding some timing problems I rewrote part of the code. This
	timing model now closer resembles plessey's model.

	I looked at timing some more today and I'm sure now that once we modify
	carrier or code DCO's, the changes take effect immediately and the next
	dump will reflect that. Also slewing (for acquisition) actually doesn't
	take effect immediately, but waits until the next DUMP event - I
	tweaked my code to take this into account.

	The problem I'm running into now is that I'd like to start adding more
	pieces to the software, but there are so many different ways to do
	this. Dallas said he will toy around with some ideas tonight - I'll do
	the same.

Friday, 13 June 2003
In   :	09:30
Out  :	16:30
Hours:	6

Log  :	I'm busy trying to get the PCI card to work, but it appears that PCI is 
	a litte bit more complicated than ISA. I can't just write to the memory 
	location, but have to initialise some PCI structure first.

	OK, the PCI board doesn't support I/O memory, thus I can't just write
	to 0xE308 to access GP2021 registers. I'm going to call Aerospace
	Innovations on Monday and see exactly how I communicate with this
	board.

	Also, the PCI board came with test software for RTLinux. I got a
	version of RTLinux, but since this is a newer version than the one that
	the test software was compiled with, it didn't work, meaning that I
	must get the same version of RTLinux. The problem is that I can only
	find the newest version of RTLinux online, not any old versions.

	I'm taking off for the day.

Monday, 16 June 2003
In   :	12:20
Out  :	18:00
Hours:	5

Log  :	Well, another day. I came in late because UPS delivered at my apartment
	today. Anywho, Dallas isn't back from lunch yet - I presume that I'll
	get the phone number from him today and also see what he came up with
	for the next phase of the software design.

	For now, I'm going to read the RTAI documentation and see how to
	communicate between different tasks.

	Ah, I came up with a good way to implement this using semaphores.
	Semaphores allow for synchronous communication between tasks.

	Dallas and I just met, we are getting closer to a nice solution, but he
	wants to sit down and think about this semaphore implementation some
	more. I think this might work, tomorrow I'll code some sample code and
	see whether this is realizable.


Tuesday, 17 June 2003
In   :	12:50
Out  :	17:00
Hours:	4

Log  :	Today I'm going to try and finalize this problem of how different
	software parts should communicate with each other. It appears that
	using mailboxes won't work very well - mail doesn't stay in the mailbox
	if multiple receivers access it. I'm going to expand on my semaphore
	and shared memory idea.

	This semaphore idea will work well, but currently Dallas want me to code
	up an idea that might allow us to preset the code phase generator down 
	to 1/512th of a chip. Let's see if this works.

	Indeed, it does work. We can now easily set relative offsets in 1/512 chip
	increments.	

Wednesday, 18 June 2003
In   :	14:00
Out  :	16:30
Hours: 	2.5

Log  :	I did some more experiments to confirm that this offset method really
	works, it appears to work. Dallas also gave me an outline where he explains
	exactly what information he wants available to the coder. Basically it
	boils down to this: ALL information that the GP2021 provides must be saved
	in some type of buffer somewhere so that if we ever need it, it is
	accessible without reading the hardware.

Thursday, 19 June 2003
In   :	09:30
Out  :	17:00
Hours:	7

Log  :	Currently all I and Q samples are available in a ring buffer for later
	access, I'm going to expand that so measurement data is put in another ring
	buffer for later access. Once this is done, I can focus on the original
	task: to synchronise between incoming data and WHEN tasks should run. Once
	this is figured out, we can move on to implementing code/carrier tracking
	loops - finally. 

	Quick sidetrack: When IQ samples are taken for the same PRN on
	different channels, I and Q values better be the same if the channels
	are synchronised. I have found that idle channels are always
	synchronised, but when you do a SEPARATE channel slew, code, or carrier
	change, then those channel DCOs become asynchronous. Thus if you want
	synched channels, make sure to always use the MULTI commands.

Friday, 20 June 2003
In   :	09:20
Out  :	~5
Hours:	7

Log  :	Since it looks like synchronisation will work using semaphores, I'm going to implement
	a very generic 'survey' mode, where one can specify doppler window, code window, chip
	size, etc. to search for. Once this is done we can build some more complicated pieces.

Sunday, 22 June 2003
In   :	11:30
Out  :	21:00
Hours:	8

Log  :	I spent a long time trying to get the gold box (DMR) to work with RTAI
	linux, this finally works. Some tests show that openGPSReceiver uses
	about 12% of the 266MHz CPU to track 2 satellites.

Monday, 23 June 2003
In   :	12:30
Out  :	17:30
Hours:	5

Log  :	Now that a generic survey is almost complete, I can start focusing on
	implementin acquisition and other loops, this will be somewhat tricky,
	because we need to figure out how to synchronise between a task
	surveying, and a task acquiring on the data, and perhaps how the
	acquisition task hands over to the tracking task. Dallas and I are
	working on this. There are many elegant ways to solve this problem, but
	our gold box might not be fast enough to implement it in such a way.

Tuesday, 24 June 2003
In   :	10:30
Out  :	17:00
Hours:	6.5

Log  :	Hmm... This semaphore idea won't work very well. It is rather difficult
	to change the timing of a task from 1ms to 10ms. Thus we came up with
	another idea: Each task will register itself whatever task is producing
	its data. This way task will only run when they have to, they don't
	need to wake up every 1ms now. This will save a lot of CPU time.

Wednesday, 25 June 2003
In   :	15:20
Out  :	17:30
In   :	19:30
Out  :	02:20
Hours:	7

Log  :	I'm writing requirements and planning how this new messaging system
	should work. It appears that this new method of tasks communicating
	with each other might take a while to code. It is fairly complex, but
	once done, will offer a very flexible platform for moving data between
	tasks and letting tasks wake up only when needed.

	Wow, this is very complicated. I worked out an example of how the user
	would want to specify parameters for channels/thresholds, etc - then
	how the program will read this and initialise everything appropriately.
	I think that this design will work well, it will just take a while to
	implement. I'm looking forward to getting this done, because then I can
	finally move on to carrier and code tracking loops.

Thursday, 26 June 2003
In   :	09:10
Out  :	21:30
In   :	22:30
Out  :	01:00
Hours:	13.5


Log  :	I'm going to start coding the new software layout. I think the best
	approach is to write the code in user land and once it works take it 
	into kernel land.

	Excellent! This new code works well, any task can now 'register' itself
	with any other task, specifying what type of data it needs and after
	how many samples it should be woken up. After a bit more tweaking and
	making sure that it really works I can actually move on to tracking
	loops.

Friday, 27 June 2003
In   :	09:30
Out  :	18:00
Hours:	8

Log  :	I'm going to add some more functionality to the base code, currently
	you can only register with once task, but what if a task wants messages
	not only from the readTask (IQ messages), but also carrier messages? I
	need to add another linked list for this.

Sunday, 28 June 2003
In   :	21:30
Out  :	23:00
Hours:	1.5

Log  :	I'm writing input files now, once this is done I'll actually write the
	program to parse it and fill the the data structures.

Monday, 30 June 2003
In   :	09:30
Out  :	20:30
Hours:	11
In   :	22:00
Out  :	0:30
Hours:	2.5

Log  :	The input paramter parsing won't be that difficult. I have figured
	out a way that the user can specify which task to associate with
	what data - this way you can easily, for instance, tell different 
	carrier tracking loops to operate on different channels - without
	recompiling.

	This is turning out to be much more complicated than I anticipated,
	I'm currently struggling with making input parsing work for different
	cases. Anyways, I should probably have planned this out before coding,
	because right now it somewhat works, but it is a mess. Time for bed 
	though, I'll attempt more work Tuesday.

Tuesday, 1 July 2003
In   :	12:00
Out  :	17:00
Hours: 	5

Log  :	I decided that the current input file parsing is a mess, I started the
	project thinking that it will be very easy, and thus didn't plan. A few
	hours today was spent planning the input parsing program - it seems
	very doable now.

	I met with Dallas and updated him with the current architecture of the
	OpenGPS software.

Wednesday, 2 July 2003
In   :	19:30
Out  :	03:50
Hours:	6

Log  :	Slow day today. I'm going to fininish up the input file parsing program
	today. Hmm... Ok, the parsing is now done.

Thursday, 3 July 2003
In   :	10:00
Out  :	18:00
Hours:	7
In   :	19:00
Out  :	20:30
Hours:	1.5

Log  :	I'm writing the real-time side of things now. Instead of statically
	programming which tasks to start up, the RT-side will read a task
	list that is provided by *.txt input files, and then start the
	appropriate tasks.

	Baam! It is complete, the input file parsing program works very well,
	it is a disgusting ~1300 lines of code, but done in a robust manner and
	very efficiently.

Friday, 4 July 2003
In   :	12:20
Out  :	14:00
Hours:	2.5

Log  :	Now that the input file parsing is done, I'm going to work on making
	my survey code more generic.

	Note: DCO Phase will always stay phase-locked relative to each other
	unless ch_code differs between the two, or different slews are
	commanded. Currently With two channels tracking the same PRN, but
	different survey loops change carrier/slew I get the following results:

	- DCO phase is always the same
	- IQ samples exactly match, until survey task starts up and changes
	the carrier of the channels at different times.
	- had a multi_carrier been used, the IQ samples would have stayed 
	the same.
	- commanding slew at different times for different channels will
	give the same DCO phase and IQ samples (when PRN of chan mathces),
	this is because the actual slewing doesn't happen until the next
	dump.

Thursday, 10 July 2003
In   :	13:00
Out  :	15:00
Hours: 	2

Log  :	This has been a rather busy week with UCEC. I hope to get into GPS again
		in the next few days. Input parsing is now complete, and I am working on
		getting survey task to be more generic.

Friday, 11 July 2003
In   :	11:00
Out  :	15:00
Hours:	4

Log  :	Survey task is a bit more generic, but I talked to Dallas and he wants
		me to put all the pieces together - currently carrier and code tracking
		loops will just be dummy function calls, but this will demonstrate that
		everything can work/communicate with each other. I have command task
		written now that will acquire a satellite and then run the dummy carrier
		and code tracking tasks. The only problem now is that the code crashes
		for some reason. I haven't been able to track the bug down het.

Monday, 14 July 2003
In   :	10:30
Out  :	18:20
Hours:	7

In   :	20:20
Out  :	00:20
Hours:	4

Log  :	Back to debugging. The code still crashes. I believe that it is a very
		silly bug that I just haven't tracked down. It must have something to do
		with the new command task I added.
		
		Ah, excellent. I can now start up multiple instances of my command
		task, which run multiple instances of a generic survey loop. The bug
		just magically disappeared also, this isn't so good.

		Remember: Check why IQ samples are not the same for same PRN, diff.
		chan. This used to be the same.

Tuesday, 15 July 2003
In   :	08:05
Out  :	17:00
Hours:	6

In   :	20:00
Out  :	21:00
Hours:	1

Log  :	Well, now to fool around and make sure that this input parsing is
		rock-solid - and cmd task parsing works. I have to add a few input
		keywords also, like 'priority' of task.

		OK, IQ samples over different channels for the same PRN sometimes
		exactly match, and other times not. I'll have to look into this.
		
		I just talked to Cory Dixon, and he said that I should really look into
		writing POSIX-compatible code. This way we can recompile OpenGPS on
		other (not Linux) operating systems. I'll look into this.

		I tweaked the acquisition thresholds a bit, results are on the
		website - data section. Now it is time to implement code and carrier
		tracking loops - but this will have to wait, I'm rather tired.

Wednesday, 16 July 2003
In   :	10:30
Out  :	17:00
Hours:	3

Log  :	Let's attempt writing these tracking loops.

		Ok, I have a floating point atan2 function 
		implemented (power series expansion).

		Problem: it appears that survey task is 
		dropping some data. I'll have to see why.

Thursday, 17 July 2003
In   :	08:30
Out  :	17:15
Hours:	8.5

In   :	20:00
Out  :	02:30
Hours:	6.5

Log  :	Survey task wasn't dropping data: when I enter my acqusition code I just
		don't write IQ data to disk.

		Ok, the carrier task is now implemented. I slowly (200ms) drift off
		correlation. I'm pretty sure that the carrier code is screwing it up
		somewhere.

		Hmm... Perhaps I should think. It would really help if I add a filter
		after the discriminator algorithm.

		Well, no filter added, but after adding the code loop things work better
		now. I can track for about 30 seconds before the code loop becomes
		unstable.

Friday, 18 July 2003
Out  :	~20:00
Hours:	~9

In   :	10:50
Out  :	17:00
Hours:	6

In   :	19:00
Out  :	00:00
Hours:	5

Log  :	I'm going to try and figure out today why my tracking loops go unstable.
		Also, I'm going to clean up some of my code - it is getting a bit messy.	

		Well, I decided to fix the website first. The document section is now
		updated, I also tweaked some other features of the website.
		
		In addition to this, I updated some of the 'documentation'. I'm
		maintaining a bunch of text files describing how certain components of
		the code interacts with each other.

Saturday, 19 July 2003
In   :	09:00
Out  :	17:00
Hours:	8

Hours: ~10

Log  :	Implemented a PLL, this didn't work at all. I'll have to investigate. I
		then implemented a LP filter, this worked, but I forgot that I shouldn't
		filter the intial FLL frequency error output, since I might require
		abrubt changes in frequency - which the LPF will filter out.

Tuesday, 22 July 2003
In   :	11:00
Out  :	17:20
Hours:	6.5

Log  :	Today I looked at different GUIs, I have a huge choice of what to use,
		currently my requirements are:
			 - GUI library must be actively maintained
			 - GUI library must have adequate documentation
			 - GUI library must support OpenGL
			 - Must be somewhat easy to learn
	
		GTK (very popular) and FLTK(very small, fast) are currently the
		forerunners. I'll code in both for a bit and then decide which one is
		for me.

Wednesday, 23 July 2003
In   :	12:00
Out  :	18:30
Hours:	6.5

In   :	19:30
Out  :	23:00
Hours:	3.5

Log  :	Today I shall teach myself to program in GTK.

Thursday, 24 July 2003
In   :	13:00
Out  :	18:00
Hours:	5

In   :	18:30
Out  :	01:30
Hours:	5

In   :	03:20
Out  :	05:00
Hours:	1.5

Log  :	The GUI is coming along slowly, the programming style is very new to me
		and will take a while to learn.

		Well, I just looked at all the available plotting libraries out there -
		the problem with all of them is that they only support plotting of
		static data. Thus if you want a nice static plot then these libraries
		will be fine. None of the plotting libraries were designed to plot real
		time dynamic data. It appears that I will have to write these myself.

		AH! I have a polar plot and y-plot OpenGL library that works. Now I just
		have to add nice little labels and autoscaling, etc.

Friday, 25 July 2003
In   :	10:00
Out  :	16:00
Hours:	6

Log  :	Things are going well, I'm going to add some more functionality to the
		gpsplot program, maintly trying to get yplot to scale better.

		Hmm... I'm not going to scale, how about let's try to plot the
		correlation waveform.

		Ok, I just implemented a xy-scatter plot in OpenGL, now let's see what I
		can do about this corelation waveform.

		First I have to make sure that my all_carrier and all_code commands
		work, otherwise when I change carrier and code for different channels
		asynchronously, the IQ samples won't match up.

		I'm running into some trouble. It appears that IQ samples for different
		channels (same PRN + same coarse/fine offset) match up all the way (even
		for 1/2 chip slews), but as soon as the carrier changes, then they don't
		match up any more.

		Current setup:

		writeGP2021 calls all_carrier, all_code, and all_code_slew. Currently
		all_code_slew works great, but all_carrier changes IQ samples for the
		two different channels.

		some more info:

		when ch0, ch1 and ch6 are setup exactly the same, then during
		an all_carrier change (survey 0), ch1 and ch6 IQ stays the same, but 
		ch0 is different.

		Actually I found the problem, when survey task starts up, it discards
		the first slew (explained in source code), I forgot to use all_slew at
		that point. 


Thursday, 31 July 2003
In   :	09:00
Out  :	18:00
Hours:	8

Log  :	Another fine day. I'm going to tweak my carrier and code tracking loops.
		The 1/10 chip correlator waveform plot looks very noisy.

Monday, 4 August 2003
In   :	11:00
Out  :	17:00
Hours:	5

In   :	19:45
Out  :	23:00
Hours:	3

Log  :	I changed my FLL to use atan instead of atan2, this gives a better
		response to bit flips, but the problem is that it is now having a harder
		time to get frequency lock. I'm still not filtering, I definitely have
		to check that out.

		Filtering didn't do the trick, I tried a 30Hz and 200Hz LPF. I looked at
		the Plessey code - they didn't filter their carrier FLL error output.

Tuesday, 5 August 2003
In   :	08:30
Out  :	17:30
Hours:	9

In   :	18:30
Out  :	00:00
Hours :	5.5

Log  :	I tried to track on 12 channels, but ran into a problem: The RTAI memory
		manager allocates 4 * 64kB chunks of memory initially. Each task uses
		16kB of stack space, thus if I have more than 16 tasks, then more stack
		memory must be allocated. I can see that RTAI does this (rt_mem_mgr.c),
		and with ZDEBUG and DEBUG enabled I get the following output:

		---- allocate another block of 64kB ----
		Found at [0xe1brt_alloc_sysrq_handler - 
			New chunk, Address: d8ff0000, size: 65536
		rt_alloc_sysrq_handler - Extra chunk count: 1
		
		---- free it? why?  ----
		rt_free - Request to free block at 0xda2f0020 from chunk 0xda2f0000.
		rt_free - 1st free block in chunk is 0xda2ffa50
		rt_free - Exit from while loop - 
			cur_blk_ptr 0xda2ffa50 prev_blk_ptr 0x00000000
		rt_free - Released a memory chunk.
		---- now we have 0 extra chunks again and rtproc.o 'freezes'  ----
		rt_free_sysrq_handler - freed chunk, Address: d8ff0000
		rt_free_sysrq_handler - extra chunk count: 0
		rt_free_sysrq_handler()

		It thus appears that rtai doesn't allocate this memory correctly.

		I have modified /usr/src/rtai/upscheduler/rt_mem_mgr.c to the
		following :
		 
		unsigned int granularity    = 0x20000;
		int low_chk_ref 			= 8;

		This now allocates initially 1MB of stack size. I really hope that this
		will work on the goldbox. I'll have to check it out sometime.

		+++++

		AH! I got the bit flips to not affect my carrier tracking loop.
		In Global Positioning System: Theory and Applications Volume 1, page
		379, eq. 87 they suggest that you correct for the bit flips by
		sign(dot). This works very well.

		I have some other findings also:

		Carrier Tracking: Changing the FLL predetection bandwidth from 1kHz to
		250Hz greatly decreaces the noise on the FLL freq error output. It
		appears that changing this bandwidth doesn't affect anything else
		(power, code DCO, etc stays stable). The only problem I might run into
		later is that when we MOVE the receiver, then I'll have to dynamically
		change the bandwidth...

		Code Tracking: This seems decently stable. When tracking the same PRN on
		4 channels, with different 'integration times' (average) of 25, 15, 10,
		and 5ms, then it looks like the 5ms one keeps the Eearly and Late power
		signals very close to each other, and as this averaging time increases,
		the Early and Late power levels differ more. On average, the 5ms code
		loop has less power (E + L) and the 25ms loop has the most power.

		Also, changing the gain for phase error -> code DCO from 1 to 0.5 or
		0.25 appears to affect the SNR fluctuations.

Wednesday, 6 August 2003
In   :	07:30
Out  :	15:00
Hours:	7.5

Log  :	I see one problem with the carrier loop: With small bandwidths for the
		FLL, it is possible to track an incorrect point (GPS: Theory and
		Applications, p.382 fig. 31). I think that this is happening, because
		sometimes the power will oscilate between I and Q every 2 seconds.

Thursday, 7 August 2003
In   :	10:30
Out  :	17:00
Hours:	6.5

Log  :	Fooling around with the AGC.

Friday, 8 August 2003
In   :	09:40
Out  :	18:00
Hours:	8

In   :	19:00
Out  :	21:30
Hours:	2.5

Log  :	I'm getting interesting results with the AGC. A lot of data has been
		posted in the data section of the website. For now, however, I'm going
		to try and optimize carrier and code tracking.

		ARGH!! The carrier loop slips all the time. I'll have to do some more
		reading...

Saturday, 9 August 2003
In   :	11:00
Out  :	17:00
Hours:	5

Log  :	I put together some code that queries a linux orbital prediction program
		(predict) and computes accurate doppler estimates for faster OpenGPS
		signal acquisition. It is working very well.

Sunday, 10 August 2003
In   :	11:00
Out  :	17:00
Hours:	6

In   :	19:00
Out  :	21:00
Hours:	1.5

Log  :	I put together the FirstRF computer today, everything looks good - I
		still have to install DOS and Linux on the computer. I also tweaked the
		orbital prediction interface software to support two instances (for some
		reason predict can only predict 24 satellites max, thus I had to run two
		instances of predict, each with a different set of TLE files).					
		I plan to update documentation tonight and also start a HOWTO website.

		Ok, I outlined the new layout of the documentation and started updating
		them. The HOWTO's will have to wait until I talk to Penny.
		
Monday, 11 August 2003
In   :	09:00
Out  :	16:35
Hours:	5.5

Log  :	I did some more AGC measurements, this time with the new PCI
		daughterboard (plugged into the ISA board). I took samples a few hours
		apart and got different results, see the data section for more detail.

Tuesday, 12 August 2003
In   :	11:00
Out  :	18:10
Hours:	6

In   :	20:00
Out  :	22:00
Hours:	2

Log  :	I fooled around with the AGC some more and came to the startling
		conclusion that even another cable hanging close to the board can affect
		the AGC by ~12mV. Well, enough of that for now - time to move on to
		fixing the code tracking loop.

		Argh, I implemented two filter loops, but the outputs do not make sense
		to me. One was a 3rd order discrete filter (Understanding GPS, p.154),
		the other one was plessey's code tracking filter -> the problem with
		Plessey, however, is that I find it difficult following their code,
		especially with all the scaling going on.

Wednesday, 13 August 2003
In   :	12:10
Out  :	18:10
Hours:	6

In   :	19:00
Out  :	22:00
Hours:	3

Log  :	I have to get this filtering done soon, it can't be *that* tough.
		AH!! I implemented plessey's version of the code tracking loop - it
		works very well, much less noisy.

		I'm modifying the software to support 'multi*' commands, this way I can
		have other channels follow at some phase/frequency offset.

Thursday, 14 August 2003
In   :	05:50
Out  :	11:00
Hours:	5

In   :	20:00
Out  :	

Log  :	Couldn't sleep - time to get some more stuff done.

		The weirdest thing happened: ogr and OpenGPS reported missed
		accumulations (20/second/channel) - I rebooted, ran the plessey codes 
		- plessey reported missed accumulations (and measurements) also! I then
		disconnected the power to the PC for about 5 seconds, plugged her back
		in, and ran plessey - the codes still reporeted missed accumulations!

		I was then rather depressed, disconnected power, took a long break (9
		hours), plugged power back in - and now plessey (and my code) reports 0
		missed accumulations!

Friday, 15 August 2003
In   :	10:00
Out  :	15:00
Hours:	5

Log  :	Ah, I found the problem: Apparently the ISA board doesn't like to bend.
		Because of the length of the board, it would start bending (because of
		gravity). When I put some pen caps underneath the board it fixed the
		problem.

Sunday, 17 August 2003
In   :	20:00
Out  :	21:00
Hours:	1

Log  :	I tried getting the A/D converter running, but I couldn't get the serial
		port up on the STK300 development board.

Monday, 18 August 2003
In   :	13:00
Out  :	19:00
Hours:	5

Log  :	I'm just making some more measurements today of RF0 and RF1. I plan to
		write up a quick report tonight and tomorrow explaining my findings and
		conclusions.

Tuesday, 19 August 2003
In   :	08:00
Out  :	18:00
Hours:	9

Log  :	I assembled all my plots for RF1 and RF0 tests -> We concluded that the
		noise interference is probably not gausian. I have a number of small
		projects that I need to finish up (listed on the blog webpage).

Wednesday, 20 August 2003
In   :	13:00
Out  :	15:00
Hours:	2

Log  :	I surfed the web and found a nice National Instruments DAQ card that we
		can use. I'll run this by Dallas.


Monday,	25 August 2003
In   :	10:00
Out  :	10:50
Hours:	1

In   :	17:00
Out  :	17:30
Hours:	0.5

Log  :	Had a meeting today with some NOAA and FirstRF people.

Tuesday, 26 August 2003
In   :	10:00
Out  :	11:00
Hours:	1

Log  : 	Meeting. I also emailed Dallas about using a PC and PC104 for the tower
		test.

Wednesday, 27 August 2003
In   :	13:00
Out  :	15:00
Hours:	1.5

Log  :	I went to JB Saunders today and bought some connectors and cables to
		extend the GPS analog board. This allows us to run the GPS board outside of the
		computer case.

Thursday, 28 August 2003
In   :	13:00
Out  :	14:00
Hours:	1

Log  :	I made the cable, but unfortunately because of connector gender issues,
		the pins are an exact mirror-image of what it should be. I'll have to
		figure out a hack before I can run the board with the extention cable.

Tuesday, 2 September 2003
In   :	10:00
Out  :	12:00
Hours:  1.5

In   :	16:00
Out  :	19:00
Hours:	3

Log  :	I had a GPS meeting today, but couldn't report anything new. I still
		have the AGC/DAQ issue to solve, and also the cable issue to extend the
		GPS card outside of the PC case.

		I have acquired some connectors now and will attempt to make the 
		cable myself.

		Tada! The cable is complete. I'm going to triple check my work and then
		tomorrow hook her up.

Wednesday, 3 September 2003
In   :	16:00
Out  :	17:00
Hours:	1

Log  :	Some final check of the cable shall now happen. 
		Ah, the cable looks good.

Friday, 5 September 2003
In   :	16:00
Out  :	18:00
Hours:	2

Log  :	I tested the cable today, but it didn't work. The plessey codes said
		that there was a address/data bus error. I then further investigated,
		and realized that the 5V power is very unstable (4.8V with 300/400mV
		ripple!). This occurs even after power regulation and decoupling caps. I
		don't think this is fixable unless we get a better cable.


Saturday, 6 September 2003
In   :	13:30
Out  :	15:30
Hours:	2

Log  :	I started building the differential amp circuit, but in order for the
		input impedance to stay high (>1Mohm), and still get a gain of about 50,
		it means that I need a resistor much larger than 1Mohm - this is
		impractical, and I decided to add two unity gain circuits. This allows
		me to select more practical values for the differential opamp circuit.

		I also received the new motherboard from Jeff and started putting the
		second computer together - so far everything appears to work - I have to
		install DOS and Linux. This will have to wait until after ION.

		Also, I still haven't biased the signal yet, I'll have to get some
		speciality diodes for this.

Monday, 8 September 2003
In   :	20:00
Out  :	0:00
Hours:	3.5

Log  :	I put together a 4 page summary of the OpenGPS code and why it it better
		than other open source code out there. This will be given out at the ION
		GPS/GNSS conference this week.

Monday, 15 September 2003
In   :	16:00
Out  :	20:00
Hours:	3

Log  :	I finally ordered the NI PCI 6023E DAQ card, I also finished up the two
		amplifier circuits. The circuits seam to work well.

Tuesday, 16 September 2003
In   :	10:00
Out  :	11:00
Hours:	1

Log  :	Attended general GPS meeting.

Thursday, 18 September 2003
In   :	16:00
Out  :	18:00
Hours:	2

Log  :	I obtained two more sampling cards from people on campus. I can't get
		the linux driver to compile for the ISA one.

Friday, 19 September 2003
In   :	15:00
Out  :	17:00
Hours:	2

Log  :	I got the driver for the PCI DAQ card to compile. The problem is that
		there exists no sample code, nor documentation. Thus I'm going to read
		through the source code today and see if I can use this driver.

Saturday, 20 September 2003
In   :	19:00
Out  :	21:00
Hours:	2

Log  :	I started writing code for the DAQ card, but with no documentation and
		just guessing what I should do, the future looks bleak.

Tuesday, 23 September 2003
In   :	10:00
Out  :	11:00
Hours:	1

Log  :	I went to GPS meeting. We discussed trying an external power source to
		power the GPS board outside the box, and that I should have my code
		ready for a lab by Oct 18, 2003. I will need to take one wednesday off
		from around 11:00 - 15:00.

Thursday, 25 September 2003
In   :	19:50
Out  :	22:30
Hours:	2.5

Log  :	Let's wrap this GPS board in some metallic foil. Ah! This looks very
		promising, my tracking loops work again too. See website for more
		details.

------------
Total: 13.5
------------

Monday, 29 September 2003
In   :	08:30
Out  :	11:45
Hours:	2

In   :	19:30
Out  :	10:00
Hours:	2.5	

In   :	00:00
Out  :	03:00
Hours:	3

Log  :	I got the DAQ card from Patt today (since Jeff is in Iraq). The comdi
		sources compiled and the DAQ card works.

		I hooked up RF0 and RF1's AGC 100x gain signals to the NI DAQ block, the
		example code can correctly sample the signals! Great.

		I modified my user-side OpenGPS code to stamp every 100th IQ dump
		with the average of the last 100 AGC samples. 

Tuesday, 30 September 2003
In   :	09:30
Out  :	13:00
Hours:	3.5

Log  :	I printed some plots of the overnight AGC sampling I ran. I also
		attended the GPS meeting and just after that tested some nice
		directional antennas.

Wednesday, 1 October 2003
In   :	14:00
Out  :	15:00
Hours:	1

Log  :	I had a long discussion with Dallas about AGC's and what we should do
		for the tower experiment. I also got about 20 hours of agc data.

Thursday, 2 October 2003
In   :	18:30
Out  :	19:00
Hours:	0.5

In   :	20:40
Out  :	22:16
Hours:	1.5

Log  :	I'm changing my code so that I can dump average IQ values also.
		Argh!! I'm an idiot - dumping the average IQ value will hopefully
		give you zero. I must rather dump the average power value.

Friday, 3 October 2003
In   :	11:00
Out  :	19:00
Hours:	7

Log  :	I had a meeting with Penny - we talked about requirements for her class.
		Basically I have to provide the following:
		 - Easy way to change acquisition doppler window, doppler bin size, and
		 integration time
		 - For tracking I must dump performance (carrier dco, code dco, phase,
		fractional phase, discriminator output, etc).				 

		 Ok, I put the GPS reciever in Dallas' aluminum box. This appears to
		 shield pretty well too. I still get low (~70,000) numbers for
		 correlation power. Another glitch that I noticed: The carrier
		 loop sometimes lock onto false tracking points - lock is then lost
		 immediately.

Saturday, 4 October 2003
In   :	13:00
Out  :	17:00
Hours:	4

Log  :	I wrote code that we can use to sample the AGC at 1kHz. This code can
		now run independent of RTAI (my other AGC sampling code is tightly
		embedded in OpenGPS). I also added dumpIQ and powerSamples to the
		channels.txt input file.

In   :	18:30
Out  :	00:40
Hours:	5

Log  :	I'm installing Linux on the other machine. After this we will have
		3 replica computers.

		OK, I started documentation - this is going to take a bit longer than I
		expected.

Sunday, 5 October 2003
In   :	10:40
Out  :	16:00
Hours:	5

Log  :	I'm just hacking away at documentation today.

		I realised a few days ago that my code/carrier tracking will be greatly
		improved if I don't just try to track the first 'signal' I find, a lot
		of times the code will try to lock onto a false tracking point.

Monday, 6 October 2003
In   :	13:00
Out  :	15:00
Hours:	2

Log  :	Dallas and I discussed how we are going to test the 3 GPS receiver
		boards. We basically decided that we will do 3 sets of tests with each:
		1) 50Ohn termination splitted to go to both RF frontends (PRN33)
		2) Omni antenna splitted - looking as sky, correlate with PRN33
		3) Omni atenna splitted - tracking a satellite

In   :	20:00
Out  :	23:15
Hours:	3

Log  :	I'm going to run these tests now.

		ARGH!! After taking test results for two of the GPS receivers, I found
		out that the test results differ depending on how you hook up the DC
		Block, and whether you add another ground from the box to the PC.

Tuesday, 7 October 2003
In   :	10:00
Out  :	15:00
Hours:	5

Log  :	I had the general GPS meeting. Dallas and I met afterwards and ran some
		controlled tests. After these tests we concluded that the AGC and
		correlation 'noise floor' level is stable over short (~30 minutes) of
		time.

Thursday, 8 October 2003
In   :	10:00
Out  :	11:30
Hours:	1.5

Log  :	I had a meeting with Penny, for the lab we decided that we will run two
		receivers and she will run a 'demo' of the code a week from today.


Friday, 10 October 2003
In   :	13:00
Out  :	15:00
Hours:	2

Log  :	Dallas and I met to talk about the tower test, I need to make some
		modifications to my code to allow for his 1 second serial 'timestamp'.

In   :	16:00
Out  :	18:00
Hours:	2

Log  :	I worked some more on my tower code, it is looking good. For some
		reason, however, the code only runs on jasmine, and not any of the new
		computers.

Saturday, 11 October 2003
In   :	12:00
Out  :	15:00
Hours:	3

Log  :	I recompiled the kernel on one of the new computers and now the comedi
		code doesn't panic the kernel any more.

Sunday, 12 October 2003
In   :	14:00
Out  :	18:30
Hours:	4.5

Log  :	I installed a temperature sensor and wrapped things up for the tower
		test. Dallas and I did a final checkout of our code.

In   :	20:00
Out  :	21:30
Hours:	1.5

Log  :	I 'beautified' the new computer (bannana blugs for power) and tested my
		code more with Dallas' - it appears that Dallas' code crashes every now
		and then, hopefully we can get this fixed up.

------------
TOTAL: 59.5
REPORTED: 40
------------

Monday, 13 October 2003
In   :	08:00
Out  :	11:00
Hours:	3

Log  :	Dallas and I went to the tower to test our code, unfortunatley I had to
		run early to go to class. The antenna cables, etc. were not ready yet.
		Dallas' code appears to crash randomly also.

In   :	16:00
Out  :	17:00
Hours:	1

Log  :	I changed my code so that it can run overnight.

Tuesday, 14 October 2003
In   :	10:00
Out  :	11:30
Hours:	1.5

Log  :	GPS general meeting and then I worked a bit with Dallas on his code, it
		seems that his code still crashes even without serial.

In   :	20:00
Out  :	02:00
Hours:	4

Log  :	I'm going to modify the code a little bit (migrate some channel.txt
		features to survey.txt).

		OK, so I didn't get a chance to migrate channel.txt to survey.txt, but I
		did add a dump measurement data function and matlab processing script. I
		also started a tutorial for the gps documentation project.

Wednesday, 15 October 2003
In   :	09:00
Out  :	11:00
Hours:	2

Log  :	Dallas and I tweaked the TXCO on the ISA GPS receiver. We got the clock
		error down to 0.01 ppm (from about 1.5ppm). The codes track much better
		now and doesn't crash.

In   :	16:00
Out  :	01:00
Hours:	6

Log  :	I talked to Dallas for a while about future work we want to do on a
		custom receiver and the OpenGPS code. I'm currently writing
		documentation for the demo that will occur tomorrow.

		Wow! I have been struggling with a problem where matlab crashes when I
		try to run 3D-plots under the hardware accelerated frame, I went back to
		NVIDIA's oldest drivers and now it works! 
		(1.0-4349  Thu Mar 27 19:00:02 PST 2003)

		The documentation looks good, I ran through it myself and things appear
		intuitive. I also added some low-level functionality to the GPS codes,
		one can now specify exactly what data to dump to file.

Thursday, 16 October 2003
In   :	10:00
Out  :	17:00
Hours:	7

Log  :	Penny stepped through some parts of my 'sofware tour', and I realised
		that the instructions skip many (not-so-obvious) steps, I will
		incorporate these changes into my website soon. Additionally, we
		discovered that mesh plots appear to have two peaks in the doppler
		domain, and that the I and Q samples are very noisy. The latter can
		probably be solved by upgrading the carrier tracking loops from FLL to
		PLL (or filtered FLL). The former problem I have no idea what is going
		on, it will require more investigation.

Sunday, 19 October 2003
In   :	17:30
Out  :	21:00
Hours:	3

Log  :	I'm going to see whether I can 'spruce up' my carrier tracking loop.
		Well, after trying plessey and

Tuesday, 21 October 2003
In   :	10:00
Out  :	11:00
Hours:	1

Log  :	I attended the general GPS meeting.

Wednesday, 22 October 2003
In   :	14:00
Out  :	19:00
Hours:	3

Log  :	I'm trying to see the difference between the 25 September 2003 data and
		now, I don't understand why that tracked so well. Dallas has a...

In   :	20:30
Out  :	23:00
Hours:	3.5

Log  :	I modified the FLL. Firstly I tried to see whether changing predetection
		integration time has any effect on the polar plot noise - it didn't,
		even though the carrier DCO gets much less noisy. I then noted a few
		problems with my data types, QPn had unsigned long, insted on signed
		long - curiously enough, however, changing from unsigned to signed
		didn't have any effect on my code. I also tried to run Plessey's
		carrier tracking loop, but still had no luck.

Thursday, 23 October 2003
In   :	09:15
Out  :	17:00
Hours:	5

Log  :	I'm going to implement a sliding average window today, I think that
		might help my carrier tracking considerably. Ok, sliding average was
		implemented - it decreased carrier noise from ~10Hz to < 1Hz, but I
		still see that spreading on the polar plot. This doesn't make sense.

In   :	21:30
Out  :	04:00
Hours:	6

Log  :	I'm going to check all the low-level functions in my code, perhaps I am
		corrupting data somewhere.

		I have checked the following:

		1) ReadTask and SurveyTask both dump I and Q data. readTask dumps
		directly from the 'corr' structure, while SurveyTask reads from the ring
		buffer. If these two tasks' I and Q data don't match up, the ring buffer
		is probably not working correctly.

		RESULT: I and Q match perfectly.
		CONCLUSION: Ring buffer contains data that readTask reads. We can not
		rule out that readTask doesn't corrupt the data somehow!
		
		2) Well, this is all I checked.

		Interestingly enough, I found that the noise is caused by the GP2010
		chip warming up. When I apply cold air (-52 C) the noise in I and Q qoes
		down considerably.

		I also fixed the OpenGPS code to support the DB Engineering board

Friday, 24 October 2003
In   :	13:00	
Out  :	15:00
Hours:	2

Log  :	I toyed around with the 2010 chip, it appears that the CHIP temperature
		affects the IQ noise, not any of the nearby components. I will do a more
		detailed study later today or tomorrow.

-------------
TOTAL: 48
REPORTED: 40
-------------

Sunday, 26 October 2003
In   :	19:00
Out  :	23:00
Hours:	4

Log  :	I'm going to play around with the 3D mesh plot and see whether I can 
		get only one correlation spike (instead of two - as we have seen in the 
		frequency domain before). Well, nope - I still get multiple peaks when I
		do the mesh plot. It appears that these multiple spikes are NOT in the
		same code bin (about 2 code chips off) and always about 500Hz different 
		in doppler space.

		I ran into a problem of my code crashing, but after a while I realised
		it was because I swapped the initGPS() and allocateMemory() functions in
		rtproc.c, this problem is now resolved.

Monday, 27 October 2003
In   :	16:00
Out  :	20:00
Hours:	3

Log  :	Ok, I bought some more coolant (since I ran out) and got a bunch of 
		labels and scarpie markers. For now I designate the GPS receivers as follow:

		#1 - Original ISA Plessey receiver
		#2 - PCI Receiver
		#3 - Gold box receiver
		#4 - Katzberg's receiver (also original plessey)

		I'm testing the Katzberg receiver now (#4) - actually the I and Q samples 
		appear to be as quiet as the DB Engineering board. Perhaps we should let
		this one warm up for a bit. (according to plessey, we have an Oscillator 
		Error of about 1.2 = ~1900Hz)

Tuesday, 28 October 2003
In   :	09:00
Out  :	11:00
Hours:	2

Log  :	I started playing with the Measurement data - from the CODE_PHASE one
		can actually judge the satellite velocity by looking at the phase change
		over time. Pretty cool.

Wednesday, 29 October 2003
In   :	09:00
Out  :	11:00
Hours:	2

Log  :	I'm writing a 3D plotting tool so that I can visualise the mesh plot
		better.

In   :	13:00
Out  :	17:00
Hours:	2

Log  :	Just hacking away at the 3D mesh plot.

Thursday, 30 October 2003
In   :	09:30
Out  :	12:00
Hours:	2.5

Log  :	Penny and I stepped through the demo again - this time it went a bit
		more smoothly. I'm still obsessed with my 3D plot...

Saturday, 1 November 2003
In   :	10:00
Out  :	17:00
Hours:	5

Log  :	I worked on the 3D plot some more, it is getting there. I think that I
		am spending WAAAYYY to much time on this, I should really start
		preparing for the presentation I have on Monday. It is just... sometimes
		I can't stop.

Sunday, 2 November 2003
In   :	10:00
Out  :	12:00
Hours:	2

In   :	14:00
Out  :	17:00
Hours:	3

In   :	22:00
Out  :	03:00
Hours:	4

Log   :	Err... I'm doing some more 3D plot stuff. The presentation is coming on
		nicely, I'm doing it in LaTeX, using the 'beamer.sty' stylesheet.

Monday, 3 November 2003
In   :  12:00
Out  :	15:00
Hours:	3

Log  :	 I practised the presentation a bit today, and give it from 13:00-14:00
		- everything went well. Currently I am preparing up jasmine.opengps.net
		and chandra.opengps.net for general use on Wednesday.

Tuesday, 4 November 2003
In   :	10:00
Out  :	17:00
Hours:	5

Log  :	We had the general GPS meeting this morning, nothing new to report. I
		am busy setting up the two lab computers today.

		Wow, this took quite a while - both lab computers appear to work now. I
		had to go back to gcc v. 2.95.3 (instead of 3.2) since 3.2 didn't
		compile correctly (Well, it compiled, but it parsed the input files
		incorrectly). I'll have to look into this issue later.

Wednesday, 5 November 2003
In   :	09:30
Out  :	15:00
Hours:	5.5

Log  :	My first 'TA' experience was a lot of fun. The GPS lab didn't go very
		smoothly at first, but as time progressed it went better. We have a
		number of issues:
		
		1) chandra crashes very now and then (it appears that the Matlab GUI
			doesn't run well, but console is OK).
		2) SNR's looked a bit low on chandra
		3) We should change the order around of my HOWTO, since the students
		don't get a clear understanding of how warmstart really works and how
		you change PRN's, it is better if they manually type in which PRN's to
		look for (perhaps by using some other GPS receiver)
		4) Perhaps I should modify my code not to overwrite data, but rather
		save it in different directories
		5) The 3D plotting tool crashes (if used incorrectly) and it doesn't
		work correclty on chandra (it doesn't plot right with the initial angle,
		but if you rotate the plot then it looks OK)
		6) File permissions: sudo will save data files as root

-----------------
Total: 43
Reported 40 hrs
-----------------

Monday, 10 November 2003
In   :	13:00
Out  :	14:30
Hours:	1.5

Log  :	I modified the matlab process_meas script so that a new parameter
		'phase' will be the addition of the CODE_PHASE and CODE_DCO_PHASE.
		It appears that the code tracking loops have about 1/100 of a chip
		error.

Tuesday, 11 November 2003
In   :	10:00
Out  :	11:00
Hours:	1

Log  : 	I attended the general GPS meeting today.

Wednesday, 12 November 2003
In   : 	11:00
Out  :	17:00
Hours:	5

Log  :	I helped out with the GPS lab today. Some interesting issues came up:

	1) The DB Engineering receiver still worked, but couldn't acquire 
	any satellites. It turned out that the antenna cable was shorted and
	the DB Eng. board didn't supply 5V any more.

	2) When students left the lab they logged out without killing the code.
	For some reason the next group's gps.sh script still ran, but didn't
	dump all the data it should have. I think that the other code running 
	dumped some data in the background while this new group's code also ran.

Thursday, 13 November 2003
In   :	19:00
Out  :	19:30
Hours:	0.5

Log  :	I helped some students in the GPS lab with carrier.c and code.c

Tuesday, 18 November 2003
In   :	10:00
Out  :	11:00
Hours:	1

Log  :	Attended the general GPS meeting today

In   :	15:30
Out  :	17:30
Hours:	2

Log  :	I had my (somewhat extended) office hours today. Group 5 is doing 
	very well, they just got their simple filter running.

Wednesday, 19 November 2003
In   :	12:30
Out  :	14:50
Hours:	2.5
Log  :	I had my office hours, most teams appear to do well. 

Friday, 21 November 2003
In   :	14:00
Out  :	15:00
Hours:	1

Log  :	Some more office hours.

------------
HOURS: 14
Reported: 40
------------

Sunday 14 December 2003
In   :	20:00
Out  :	03:00
Hours:	6

Log  :	Well, I'm tired of studying thus I figured that I should get some GPS
		work done. I'm currently investigating the multiple correlation peaks.
		From what I can see, it appears that the other correlation peak is off
		by atleast 1 chip (and ~500Hz in doppler).

Monday, 15 December 2003
In   :	10:00
Out  :	11:00
Hours:	1

Log  :	I had a GPS receiver meeting with Penny and Dallas - we have decided
		that I should get some code done so that we can start using it for
		research. We decided on:

		1) Scan code phase while doppler is slaved to tracking channel
		2) Scan doppler space while code phase is slaved to tracking channel

Wednesday, 17 December 2003
In   :	11:00
Out  :	16:00
Hours:	5

Log  :	I started implementing SLAVED channels. Currently I can slave code phase
		to another channel and freely move doppler around. Check out the website
		for some results.

Thursday, 18 December 2003
In   :	11:30
Out  :	16:00
Hours:	4

Log  :	I'm working on the slaved channels currently.

In   :	21:45
Out  :	02:00
Hours:	4

Log  :	Slaved channels... Well, I'm trying to get my doppler window to move
		relative to some other channel's doppler (thus if I scan from -5khz to
		+5kHz, it should really be -5kHz+prim_channel to +5kHz+prim_channel)...
		This might appear easy to do, but an elegant solution has eluded me for
		the past few hours, I really just need to go to bed.

Friday, 19 December 2003
In   :	12:00
Out  :	20:00?
Hours:	6

Log  :	It is time to look at this problem with a fresh mind... Ah! I finally
		fixed the problem, one can now scan from -[x]kHz to +[x]kHz and the scan
		will always center around the doppler frequency of another tracking
		channel.

------------
HOURS: 26
------------

Wednesday, 7 January 2004
In   :	16:00
Out  :	17:30
Hours:	1.5

Log  :	Ahh... It's good to be back. I'm busy trying to get the fine-chip
		stepping to work. I'm looking at the code phase of a channel that is
		doing nothing (codeDopplerFreq=0Hz). Apparently the code phase is moving
		slowly, around -1 chip/second. I don't know why this is, perhaps the
		100ms TIC interrupt isn't exact? Or perhaps the code period isn't
		exactly 1ms when generated?

Thursday, 8 January 2004
In   :	15:30
Out  :	18:30
Hours:	3

Log  :	Well, my office door died yesterday (flat batteries) and I couldn't get
		into the office to get my keys and wallet. It appears that the door
		works okay now.

		Hmm... Before finishing up the fine stepping of code phase, I'm trying
		to resolve this code drifting issue. When I set my code generation rate
		to nominal (1.023MHz), I get a phase change of 1.0533/s (+/- 0.0005). I
		have confirmed this on two plessey receivers and the DB ENG receiver.

		When I increase the code generation frequency by 2.0436 Hz I get almost
		no drift, but still around 0.0333 chips/second. This is true for both
		the plessey and DB engineering board. This makes me think that the phase
		drift is NOT clock error (how can it be, since the TIC interrupt and the
		code generator are running off the same clock?), but probably some
		timing issue between the 100ms sampling time and the code generator.

		I don't know what to make of this, I'll probably discuss it with Dallas
		for a bit.

Saturday, 10 January 2004
In   :	12:30
Out  :	19:00
Hours:	6.5

Log  :	Over the weekend I figured out that a TIC is really 99.99990ms, thus we
		sample about 1/10 of a chip slower than 100ms, thus we drift at about
		1/10 of a chip/TIC or 1 chip/second.

		Now to see whether I can get the fine stepping to work.

		Wait, I got some more accurate calculations:

		(100-TIC/codePeriod)*1023 = 0.1054999967638111  chips/TIC (theory)

		I get a drift rate of about 0.1054860726164080 chips/TIC (practice)

		It appears that when changing frequency over TIC intervals (for
		testing), I can get as close as 3/1000 of a chip to the desired phase.

		I now changed the code to change phase over 1MS intervals, now I again
		get around 3.8/1000 of a chip resolution.

Monday, 12 January 2004
In   :	09:30
Out  :	11:00
Hours:	1.5

Log  :	On saturday I scanned correlation waveforms at 1/100 chip and 1ms dumps.
		This was done by increasin the code frequency ONCE, then scanning slowly
		through all 1023 code chips. This is a good and accurate way to do it if
		we need only 1ms dumps, but what if we want to dwell for 4ms? Then we
		need to STOP the DCO at a phase for 4ms, move on, etc. I'm trying to
		figure out a good way to do this.

		I just talked to Dallas for a bit, and we realized in order to do any
		good coherent integration on the correlation waveform we need to have a
		sliding window in which we sample, because if we coherently integrate at
		the SAME code phase for, say, 4ms, then the code phase would have moved
		over that time.

In   :	14:20
Out  :	15:30
Hours:	1

Log  :	I planned what to do next, I'm going to get the fine-stepping to slave
		to another channel. This should be fairly easy, since I just change the
		chanWrite parameter.

		In order to do relative movement, I need to change so that
		codePhaseWindowMin can be negative (not just UINT16 from 0-1023)

Tuesday, 13 January 2004
In   :	12:00
Out  :	14:30
Hours:	2.5

Log  :	I'm reading through Beyerle's code now, trying to figure out how he does
		the NAV message decode. 

Wednesday, 14 January 2004
In   :	14:00
Out  :	16:00
Hours:	2

Log  :	I downloaded the newest code from Beyerle, tried to run it, but it just
		seg-faults. He implemented some of my OpenGL gpsplot code, and I thought
		it would be nice to see the performance of their tracking loops in
		real-time. I'm still trying to figure out the best way to implement bit
		sync and frame decoding.

Thursday, 15 January 2004
In   :	10:15
Out  :	18:30
Hours:	7

Log  :	Reading about data bit demod, etc. Currently I'm trying to figure out
		whether I should create a new task (more overhead) or just use the
		current readTask to do my 1ms timing. 

		Ah! Everything makes more sense now, I know how to do this!

Friday, 16 January 2004
In   :	09:30
Out  :	17:00
Hours:	5

Log  :	I'm going to see whether I can get bitsync to work today.
		Ah! I found the bug. of I have two keywords
		code:
		decode:

		then 'code' will match both code and decode!! 

---------------------------------
Hours: 30
Reported: 40
Payed for: 10 extra
---------------------------------

Monday, 19 January 2004
In   :	17:00
Out  :	19:30
Hours:	2.5

Log  :	I'm busy implementing bitsync

In   :	22:30
Out  :	00:30
Hours:	2

Log  :	Bit sync is very close to working.

Tuesday, 20 January 2004
In   :	09:30
Out  :	10:00
Hours:	0.5

Log  :	GPS General Meeting

In   :	12:00
Out  :	14:30
Hours:	2.5

Log  :	I just got readTask() to align other tasks with ms_count when bitsync is
		obtained. Now the next task would be to try to find the preamble and
		obtain frame sync.

Wednesday, 21 January 2004
In   :	12:30
Out  :	14:00
Hours:	1.5

Log  :	I'm hacking away at my find_preamble task, things are looking good. Aha!
		I can decode the TOW now!

Thursday, 22 January 2004
In   :	10:00
Out  :	15:00
Hours:	5

Log  :	Now that TOW is decoded, I have to do the following:

		1) Figure out what data I need to dump and how to sync. them up between
		different files
		2) Set computer clock w.r.t TOW
		3) Make sure that I can setup other channels with different code phase
		4) Software must decide when to stop tracking one sat and switch to
		another or re-acquire
		5) Any data other than TOW we want?
		6) Can code run for multiple days?

		I did some testing with weak SNRs, and I'm not sure whether my vector
		rotation (FLL) works as planned, it takes quite a while to get the TOW
		extracted with 'weak' signals (12dB) - I can still clearly see the bits
		on my gpsplot window, so perhaps the vector rotation isn't working...

		I'm currently recording code phase on two PRN's - I'd like to compare
		them over a few hours and see if clock drift and noise is visible.

Friday, 23 Januarty 2004
In   :
Out  :
Hours:

Log  :

Monday, 26 January 2004
In   :	13:00
Out  :	16:00
Hours:	3

Log  :	I'm checking out my frameDecodeTask, it works 90% of the time, but
		sometimes it will get an even distribution of bitflips over all 20 bins,
		this doesn't make sense, since the SNR was nice and high... (I also
		started bitsync when the carrier and code loops stabilized.

		I ran into a peculiar error today: gcc didn't compile because there was
		garbage on line 120 in /usr/src/linux/include/asm/io.h.. after a reboot
		the garbage disappeared (I don't compile as root, so there is no way
		that gcc could have screwed it up).

		chan.tow is initialised at the start of every subframe, ms_count ranges
		from 0-5999 and is reset at the start of every subframe

		tow: 0 - 100,799 (2^15 = 100,799)
		ms_count: 0-5999 (2^13 = 8192)

		I'll dump each as 2 bytes into all my data files so that we can be
		sync'ed up between files.

		I'm making sure that my slaving of channels work ok. To do this, I will
		read back the code phase at every TIC and make sure that my channels
		are, in fact, 1/8 chips apart.

----------------------
Total: 17
Reported: 40
Payed for extra total : 10+23 = 33 extra
----------------------
		

Monday, 2 February 2004
In   :	17:20
Out  :	16:30
Hours:	1

Log  :	I tested the phase offset today, just made sure that I can set my phase
		reliably by 1/8th chip. The good news is that reading the measurment
		data shows code phase off EXACTLY by 1/8th chip.

Tuesday, 3 February 2004
In   :	09:30
Out  :	10:00
Hours:	0.5

Log  :	We had our general GPS meeting.

Thursday, 5 February 2004
In   :	09:30
Out  :	15:30
Hours:	6

Log  :	Ah! Ready to get some work done. I'm adding my dumpCount (1ms counter)
		to all data files.

		Added to:

		corr->chan
		meas
		codeErr
		carrErr
		powerAvg

		OK, all data files now has a 32bit number (dumpCount) which increments
		every time a dump comes in per channel. This way we can sync. between
		different files.

		Perhaps I should decode #of weeks also?
		
		Well, I'm busy working on implementing lock indicators and then 
		letting commandTask decide which PRN to select next

Monday, 9 February 2004
In   :	13:50
Out  :	16:00
Hours:	2

Log  :	I'm coding my lock indicators.

Tuesday, 10 February 2004
In   :	17:00
Out  :	18:30
Hours:	1

Log  :	The lock indicators work well, readTask keeps an average of 20ms, then
		the user-side determines CN0.

Wednesday, 11 February 2004
In   :	09:30
Out  :	11:00
Hours:	1.5

Log  :	I'm busy figuring out once lock is lost how to stop my tasks.

In   :	13:00
Out  :	17:00
Hours:	4

Log  :	Ah, my tasks now stop correctly. Now it is time to work on the
		select_prn() function.

---------------------------------
Total 16
Reported 40
Total payed extra for: 24+33 = 57
----------------------------------

Sunday, 15 February 2004
In   :	16:00
Out  :	23:35
Hours:	6

Log  :	I have my linked list working that can insert/remove nodes (PRNs) to be
		tracked. I'm currently working on the RT-side. I'm having some trouble
		with the FIRST prn to track, since the first one is not selected from
		the linked list. This is because the code doesn't know which channel is
		liked to which surveyTask.

Monday 16 February 2004
In   :	13:00
Out  :	16:00
Hours:	3

Log  :	Time to finish up the prn selection code. OK, I can select a PRN now
		when lock is lost. I really need to do some more work on it though.
		Current shortcomings include:
		1) First PRN tracked will always be one specified in channels.txt
		2) If Sat not acquired, then doesn't switch PRN
		3) Need to check whether code phase remains unaltered after PRN switch
		4) When PRN switched, dump that + counter to file + sourcesel
		5) Must check whether sourcesel works right
		6) Must make is so that can dump in different dirs for diff hours
		7) Comedi drivers need to be better + time sync
		8) Sync clock with TOW?

In   :	21:00
Out  :	23:00
Hours:	2

Log  :	My prnselect code works better, I checked to make sure that the phase
		remains unchanged. Between different channels when PRN is selected. The
		phase seems to be GOOD :)

Tuesday, 17 February 2004
In   :	09:30
Out  :	18:30
Hours:	7.5

Log  :	We had a general GPS meeting today. The FirstRF deadline is coming up
		soon. I decided to rewrite my prn selection code suchh that the linked
		list resides in the RT-side. This makes it much easier for RT sides to
		get a new PRN. User-land will now put data in a FIFO, this data will be
		read by a low-priority 1second task that adds data in this FIFO to the
		list.

		Ah, this works well. I checked my code phase, and it is still good after
		PRN switches.

Thursday, 19 February 2004
In   :	13:30
Out  :	18:00
Hours:	4.5

Log  :	I'm cleaning up code a bit and will add a 'PRN + counter' file soon.

		Oops! What was this!

		Feb 19 13:47:18 jasmine kernel: param->chan[0].tow_HOW = 70051
		Feb 19 13:47:21 jasmine kernel: Unable to handle kernel paging request
		at virtual address 6e6d6c8b
		Feb 19 13:47:21 jasmine kernel:  printing eip:
		Feb 19 13:47:21 jasmine kernel: c01457c6
		Feb 19 13:47:21 jasmine kernel: *pde = 00000000
		Feb 19 13:47:21 jasmine kernel: Oops: 0000
		Feb 19 13:47:21 jasmine kernel: CPU:    0
		Feb 19 13:47:21 jasmine kernel: EIP:    0010:[<c01457c6>]    Tainted: P 
		Feb 19 13:47:21 jasmine kernel: EFLAGS: 00010202
		Feb 19 13:47:21 jasmine kernel: eax: 00000000   ebx: d087fbb4   ecx:
		d087fbc4   edx: d087fbc4
		Feb 19 13:47:21 jasmine kernel: esi: 6e6d6c6b   edi: 00000000   ebp:
		00002f1e   esp: c183bf4c
		Feb 19 13:47:21 jasmine kernel: ds: 0018   es: 0018   ss: 0018
		Feb 19 13:47:21 jasmine kernel: Process kswapd (pid: 5,
				stackpage=c183b000)
		Feb 19 13:47:21 jasmine kernel: Stack: d03e1978 d03e1960 d087fbb4
		c014384d d087fbb4 00000017 000001d0 00000020 
		Feb 19 13:47:21 jasmine kernel:        00000006 c0143b1b 0000391a
		c012cac6 00000006 000001d0 00000006 000001d0 
		Feb 19 13:47:21 jasmine kernel:        c023fc68 00000000 c023fc68
		c012cb0d 00000020 c023fc68 00000001 c183a000 
		Feb 19 13:47:21 jasmine kernel: Call Trace: [<c014384d>] [<c0143b1b>]
		[<c012cac6>] [<c012cb0d>] [<c012cba3>] 
		Feb 19 13:47:21 jasmine kernel:    [<c012cc06>] [<c012cd1d>]
		[<c010573b>] [<c012cc80>] 
		Feb 19 13:47:21 jasmine kernel: 
		Feb 19 13:47:21 jasmine kernel: Code: 8b 7e 20 85 ff 74 0d 8b 47 10 85
		c0 74 06 53 ff d0 83 c4 04 
		Feb 19 13:47:24 jasmine kernel:   param->chan[0].tow_HOW = 70052
		Feb 19 13:47:30 jasmine kernel:  param->chan[0].tow_HOW = 70053

		This is the only time I have ever seen this, recent changes made:

		1) Added list_survey.c (RTAI linked list) to RT-side
		2) Changed chInit() to do minimum init, most init is now done
		in the surveySETUP function.

		I modified my readTask to dump TOW to a file only of I am in sync. I
		also just added code that will generate a file channeln_PRN.dat - this
		dumps the 1ms counter as well as which PRN was selected.

		Now it is time to add a low-priority 1s (or so) task that runs generic
		'house-keeping' stuff. This will include checking whether time is up,
		and if it is, then forcing commandTask to stop tracking of the current
		satellite.

Friday, 20 February 2004
In   :	15:00
Out  :	16:00
Hours:	1

Log  :	I tweaked my prnselect code a bit. Currently it won't work if no
		satellites are visible. What I still need to do for FirstRF:

		1) If no PRN's in list suitable, check periodically and notify
		command task that one is available.

		2) Files dumped in 1hr blocks with directory name containing
		time segement

		3) AGC circuit running + AGC dumps synchronised with incoming data

		4) Code phase of slaved channels should be easy to specify AND change

		5) Generate nice display showing data [agc dB, signal strength, etc]

Sunday, 22 February 2004
In   :	22:00
Out  :	10:00
Hours:	12

Log  :	I wrote a 'user-interface' program in ncurses that allows one to view
		what the GPS receiver is doing.

Monday, 23 February 2004
In   :	13:00
Out  :	15:00
Hours:	2

Log  :	I talked to Dallas about what we still have to do for the demo. Things
		are looking good

Tuesday, 24 February 2004
In   :	09:30
Out  :	15:00
Hours:	4
In   :	19:00
Out  :	22:00
Hours:	3

Log  :	I went to the GPS meeting this morning and debugged my AGC circuit.
		The problem with the code was that my sampling frequency wasn't fixed. I
		did a quick hack to this (sample rate not constant yet, but static over
		about 1 second...). I also emailed Dallas sample data + data format.

Wednesday, 25 February 2004
In   :	17:00
Out  :	19:00
Hours:	2

Log  :	I ran my code overnight, it tracked for 780 minutes, but gave the error
		(when switching directories):

		opengps:main(): Entering loop, press 'q' to quit
		Switching dirs...
		Making directory ../data/long/20040225-0041/
		Switching dirs...
		Making directory ../data/long/20040225-0141/
		Switching dirs...
		Making directory ../data/long/20040225-0242/
		Switching dirs...
		Making directory ../data/long/20040225-0342/
		Switching dirs...
		Making directory ../data/long/20040225-0442/
		Switching dirs...
		Making directory ../data/long/20040225-0542/
		Switching dirs...
		Making directory ../data/long/20040225-0642/
		Switching dirs...
		Making directory ../data/long/20040225-0742/
		Switching dirs...
		Making directory ../data/long/20040225-0842/
		Switching dirs...
		Making directory ../data/long/20040225-0942/
		Switching dirs...
		Making directory ../data/long/20040225-1042/
		Switching dirs...
		Making directory ../data/long/20040225-1142/
		Switching dirs...
		Making directory ../data/long/20040225-1242/
		opengps:main(): could not open output file make sure that directory data
			exists.
			The magic goes away...
			real    780m14.241s
			user    0m0.000s
			sys     12m34.240s
			unload 'opengps_rtproc.o' ...

		I rewrote part of the code to give a better error message, hopefully
		this happens again and I can debug.

Thursday, 26 February 2004
In   :	10:00
Out  :	12:00
Hours:	2

Log  : I realized that my code had a problem where it couldn't open more output
		files because there were too many fd's open. I fixed that by closing the
		file first...

		11:45pm - HD cable moved.

Friday, 27 February 2004
In   :	13:20
Out  :	19:30
Hours:	5

Log  :	I ran the code for 24 hours and everything seems well. Dallas reported a
		5 second periodic spike in the AGC and IQ data set. We investigated
		further and the spike to be caused by the fact that the HD dumps data
		every 5 seconds to disk. Cynthia also doesn't have any type of shielding
		on the IDE cable.

		I fixed my code so that it dumps everything in UTC, also if no
		satellites are avialable on current startup, survey regsters with
		houskeeping and waits until a satellite becomes available.

----------------------------------
Total 54
Reported 40
Total payed extra: 57-(54-40) = 43
----------------------------------

Saturday, 28 February 2004
In   :	14:00
Out  :	21:00
Hours:	5

Log  :	I fixed the code so that it registers with housekeeping when no
		satellites are avialable.

Sunday, 29 February 2004
In   :	13:00
Out  :	22:00
Hours:	7

Log  :	I modified the gpsplot software today to plot the waveform in real time.
		Also, I'm currently running into problems where I get missed
		accumulations! I have never seen this before, and I think it is related
		to my gpsplot software. I modified the sw to use measBufRead insted of
		meas->codePhase. I hope this fixes it! Also, I'm running into problems
		where the comedi drivers read NaN for all 3 channels! When I reset my
		gps code it gets fixed. This appears to only happen once.

		Hmm... OK, missed accum not fixed. I was just running my polar plot and
		it still happened. Hopefully I can trace this missed accum back to the
		gpsplot software. Damn.

Monday, 1 March 2004
In   :	12:45
Out  :	16:00
Hours:	3
In   :	17:15
Out  :	18:15
Hours:	1

Log  :	I ran the 23 Feb code overnight and it didn't miss an accumulation, now
		let's see how recent code I can run without getting missed
		accumulations. I'm running the Feb27 code now.

		What changes have I made since Feb 23?

		- Added housekeeping task
		- removed repeatCount from readFiles.c
		- Dump in GMT
		- Menu mod SNR for CN0
		- gpsplot read measBuf
		- Close output FID's before open new ones

		The Feb27 Code has run 41 minutes with no missed accum. 
		So: Things I have changed since Feb27:

		- Housekeeping task
		- Menu mod SNR for CN0

		It appears that the only RT difference is my housekeeping task. I think
		that made the code miss accumulations. Now, I did try to just not start
		housekeeping with the same results - which means that it must be
		something else I changed in order to get housekeeping running. Things
		that come to mind:

		I modified updateProducers so that it doesn't look at DATATYPE = NONE to
		identify readTask, but actually... hmm... read the string?

		I take that back, the Feb27 code missed an accumulation when I ran both
		polar and xyplot. (it took about 60 minutes). The Feb26 code just missed
		an accumulation also. I'm still a bit curious as to whether my openGL
		plots have anything to do with it. I don't think so since it died
		earlier when I didn't have anything running. Unfortunately it takes an
		hour (or more) for it to miss an accumulation.

		OK, the code crashes with the feb23 code also (when running openGL
		plots). Logically it apprears to be the opengl plots that screw up the
		code, but that is not possible. The opengl code run in user-side, and
		NOTHING, but NOTHING in the user-side  can interfere with the RT-side.
		The problem must be found somewhere else. Unless... perhaps OpenGL
		somehow modified memory (it SHOULD only read, but has write access
		also).

		I'm currently running OGR v0.1.6 - So far it has not missed an
		accumulation. (I though perhaps it is the board, but if other code don't
		miss accumulations then... well, it must be my code) OGR didn't miss an
		accumulation after more than 1.6 hours. I'm going to run my feb23 code
		again with the menu enabled... Nah, I decided to run my feb27 code with
		menu enabled (no opengl plot run during any time...)

		Ok, this is crappy, the feb27 code missed an accumulation with only the
		menu running. I'm rerunning it without the menu.

Tuesday, 2 March 2004
In   :	09:30
Out  :	22:00
Hours:	3

Log  :	We just had our general GPS meeting. Also, my feb27 code ran just fine
		overnight. I'm beginning to suspect that is is the menu.c file that is
		causing the missed accumulations. I just (10:40) started my gpsplot
		software, we'll see if we get a missed accumulation now.

		Well, good news is that the feb27 code is running well (with opengl
		plots going, but no menu). I did run the menu a little bit previous just
		to show Dallas what is going on though.

		Well, my code is still running (not tracking though, PRNs in list not
		visible). I just (16:38) started my menu program (modified so that corr
		and meas are not accessed directly, but through the buffer). Let's
		see if the code crashes then.

		I stopped the feb27 code at 18:22 - no crashed with modified menu code.
		I did notice, however, that the relative phase information takes many
		samples to refresh...

		Hmm... I got a FIFO RAW_IQ Full (after stopping and rerunning the code)

		Modifications I made to my code
		-------------------------------

		1) RT_BUF_SIZE to 32768*16
		2) param->measHead=measHead in measBufWrite

		I made the above mods to my feb29 code (and I am running it currently).
		Hopefully everything will go well and it won't crash. If it didn't crash
		(by crash I mean missed accumulations) by tomorrow morning, then I'll
		start my openGL code, give it a few more hours and then add the menu.

Wednesday, 3 March 2004
In   :	10:10
Out  :	16:00
Hours:	4

Log  :	Well, my feb29c code is still running, I just started the OpenGL plot,
		and I have 20 sampling points. With 11 channels, that should be 22, so
		it appears that I'm missing a channel?! It looks like it could be ch9 or
		ch10. Let's run the menu program and see what she says.

		Menu reports channel spacing of:
		-0.5,-0.25,+0.5,+0.75,1.0,1.25,2.0,2.25,3.0,3.25,4.5

		After restarting the code, the spacing is now
		-0.5 -0.25 0.5 0.75 1.5 1.75 2.5 2.75 3.5 3.75 4.5

		Feb29c ran for 807 minutes without missing an accumulation.

		I'm officially going with the feb29c code again. I found a bug where I
		didn't close my temperature FID, fixed that in closeFiles();

		I modified my code so that I can track WAAS satellites - unfortunately
		the satellite is pretty low and we have a building in the way...

		Look at data set data/long/20040304-0654 - the code phase is correct
		at the beginning, but then changes to
		0 -0.5 -0.25 0.5 0.75 1.5 1.75 2.5 2.75 4.0 4.25 5.0 this was
		even with no satellites tracking

Thursday, 4 March 2004
In   :	09:20
Out  :	17:00
Hours:	4

Log  :	I didn't fix my menu.c problem, the feb29c code missed an accumulation
		when running it. I did, however, run feb29c again overnight with polar
		and xy-plot going - and no problems occured. Well, actually, it appears
		that my carrierErr FIFO was full! I think this is because my gps program
		gets 'pushed around' by the opengl plot programs. I should look into it.

		I made a big change, instead of using kmalloc, I now use rt_malloc,
		apparently kmalloc could block. I started this code around 9:45am. Let's
		run it (with openGL plots) and see if it works OK.

Friday, 5 March 2004
In   :	14:00
Out  :  17:00
Hours:  3

Log  :	I showed my progress to FirstRF today, they were quite pleased.

Thursday, 10 March 2004
In   :	23:00
Out  :	08:00
Hours:	9

Log  :	Well, I fixed the code so that it will track a satellite given a certain
		time ONLY for that time, previously it would keep tracking the current
		sat if no others are available.

		I also made it so that data is only dumped when the signal is in lock,
		this took a while to make work because for some reason fwrite didn't
		write the whole data set, when I moved to just 'write', it worked. I got
		another missed accumulation (while running the menu program) - I thought
		I fixed this problem, but apparently not. I wrote some code that will
		spit out seconds since 1970 (or something) given UTC input.

		Problems at tower:

		- CodeFilterLoop (plessey) - didn't work well (code phase change
		  rapidly), I/Q power was around 7000 (very very strong). 
		- CodeTrackLoop (E-L/E+L) - worked well, but with E/L imbalance. I
		  decided to use this tracking loop on both channels.
		- For some reason I got CH0 RAW full a few times, I have no idea why
		  this happened.
		- SourceSel switched to 1, but then after prnSelect got called (I
		  think), they all got switched back to zero again, I had to comment
		code out in readTask.c (writeGP2021) to get this to work correctly. I
		need to make sure that it stays on RF1 even when switching satellites.
		- I got missed accumulations, but currently just report them and say
		  'lost signal lock' - the code seem to work OK when this happens.
		  Again, this only happened when menu was running.
		- For the test, I had it track satellites for 7 days... hopefully this
		  works. No menu or gpsplot program was running.
		- For future: Put 802.11b card in PC, this allows me remote access
		  and I can drive to the tower
	    - Yeah... that is it.
		- acqlist returns duplicate entries if there is a newline by itself
		  on a line
		- How do I set different thresholds for direct/reflected tracking?

----------------------------------
Total 42
Reported 0
Total payed extra: 43-41 = 1
----------------------------------

Monday, 15 March 2004
In   :  13:00
Out  :	14:30
Hours:	1.5

Log  :	I started jasmine up again (haven't run code on jasmine for a while, did
		all my tests on chandra). With my current code the mouse is very slow, I
		went all the way back to 2Mar2004 and then the mouse moves smoothly.
		Now to figure out why.

		Ah! The problem is with my gps.sh script, when I do nice 10 ./gps, then
		it slows down the rest of the computer. Let's see if I can run the mar15
		code for a long time.

Tuesday, 16 March 2004
In   :	09:30
Out  :	12:30
Hours:	3

Log  :	I ran the mar15 code overnight and it appears that it was in survey
		mode, looking for PRN 15 and PRN 9 (I think) - 1 hour later it was
		still at the same PRN - the doppler window was very very wrong (10
		thousands of hertz). I have no idea what could have caused this.

		Also, I fixed my sourceSel problem (sourceSel gets changed back after
		prnSelect is called). I'm busy modifying the code so that startDump()
		only starts dumping the channels we specified in channels.txt (instead
		of all of them). Hmm... after 15 minutes I got a 'cannot handle kernel
		NULL pointer at adr 0x12' - the gps binary file segfaulted soon after
		wards. I wonder whether this is me... This is bad news.

		I changed code.c such that codeFilter now uses float (instead of long)
		for EML. This should fix the overflow with strong signals.

		I'm running the mar15 code for a long time (menu.c running too). Let's
		see what happens.

		Restarted march15 code at 19:50pm (X crashed) (I also switched back
		to the float EML filter loop with menu.c running).

Wednesday, 17 march 2004
In   :	14:00
Out  :	16:00
Hours:	2

Log  :	After many hours of tracking, my code phase [ch1-10] 0 0.25 1.0 1.25
		2.0 1.75 2.5 2.25 2.5 2.75 - this isn't right. Also, I just tried
		stopping the code, but 'q' doesn't work. I have to look into this.
		I started the code up again with phase: -0.5 -0.25 0.5 0.75 1.5 1.75 2.5
		2.75 3.5 3.75 (didn't change input files). I looked at the data and the
		code phase changed from -0.5 diff (ch0 and ch1) to 0 diff. I didn't see
		any difference in code freq.

		Phase is (0:18) mar 18 -0.5 -0.25 0 0.25 1 1.25 2 2.25 3 3.25
		Let's leave it and see if it changes (20040318-0658).

		At 19 mar 0940 20040318-1558, my correlator spacing were:
		0 -0.25 0 -0.25 0.5 0.75 1 1.25 2 2.25

Thursday, 18 March 2004
In   :	13:00
Out  :	17:00
Hours:	4

Log  :	I started analysing some of the tower data, we are seeing interesting
		oscillations in the RF0 signal, and RF1 seems to be even more sensitive
		to temperature.

-------------------
Hours: 11
-------------------

Monday, 29 March 2004
In   :	13:00
Out  :	15:30
Hours:	2.5

Log  :	I replaced the power supply of cynthia (resoldered +-/12,gnd
		connections). I also started looking at the log file to try to figure
		why the code stopped dumping data during the tower test. I came up with
		the following:

		1) CH11 starting tracking on 09:08:41
		2) CH11 stopped tracking on  09:08:42
		3) CH11 starting tracking on 09:08:58
		4) CH11 stopped tracking on  09:09:02
		5) CH0 RAW IQ FIFO full on 09:09:10

		All of this happened while CH0 was tracking

In   :	21:00
Out  :	02:00
Hours:	5

Log  :	Busy seeing how I can revamp my user.c code so that things run more
		smoothly. I'm looking at timers and SIGNALS (for FIFO). I modified the
		AGC comedi FID to be non-blocking, let's see what this does.

		I changed the comedi driver to be non-blocking, I see much more
		improvement on my AGCCount (when I dump, I don't miss 20ms anymore, but
		more like 4ms)

Tuesday, 30 March 2004
In   :	09:30
Out  :	10:00
Hours:	0.5

Log  :	GPS General meeting

In   :	22:00
Out  :	1:30
Hours:	3.5

Log  :	I found another bug, sometimes comedi_get_range doesn't return the
		correct ranges (returns NaN for min and max). I just manually set these.
		I also modified the code to use a signal to determine when to stop.
		Started running code again.

Wednesday, 31 march 2004
In   :	12:50
Out  :	18:30
Hours:	5

Log  :	Well, the code ran successfully for PRN17 and PRN9, for both PRNs,
		however, did the code tracking find it difficult to lock on (about 30
		seconds). The phase spacing between channels also changed, it is now
		-0.5 -0.25 0.5 0.75 1.5 1.75 3 3.25 4 4.75. I'm going to leave the code
		as is (will not track sat until tomorrow), and see whether the code
		phase changes again.

		This I'd like to change before we go out to the tower:

		1) Invetigate missed accumulations
		2) Modify carrier and code tracking
		3) Investigate channel phase spacing changes.

		Ah! Dallas and I tracked the missed accumulations to down to heavy
		hardware usage, do a hdparm -d0 /dev/hda and for /dev/hdc (cdrom). This
		appears to have fixed the missed accumulation problems. I'm rerunning
		the code now. Channel spacing seems good.

In   :	23:00
Out  :	03:30
Hours:	4.5

Log  :	Code is still running well, I had a look at two data sets:
		20040331-1607 and 20040331-1707 - in 1607 code phase spacing
		is still correct, but in 1707 it is not. I didn't dump all data,
		when I wasn't tracking I didn't dump - it appears that the code
		phase shifts by half a chip at when selecting different satellites.

		OK, after some more debugging, this is where I stand:

		If I uncomment multi_slew in writeGP2021, then code phase doesn't screw
		up. Thus multi_slew must be causing it.

		After some more investigation, code phase gets messed up when

		1) PRN select occurs
		2) Code phase gets moved back from 0.5 to 0 for some reason.

		Ah! I increment codePhase by 0.5 and THEN check whether I'm done
		with this satellite. I fixed the error -> now the code phase is correct.

-------------------------
Total Hours: 21
-------------------------

Wednesday, 14 April 2004
In   :	14:00
Out  :	01:00
Hours:	8

Log  :	I bought a wireless card for chandra + directional antenna. I had to
		recompile the kernel and rtai (r3.0). The wireless card works well, we
		are going to do some range testing tomorrow. I'm running my code
		overnight to make sure that it works OK with the new mods.

Thursday, 15 April 2004
In   :	13:00
Out  :	17:00
Hours:	4

Log  :	The code ran well overnight, I made a few final tweaks to the input
		file.

Friday, 16 April 2004
In   :	07:00
Out  :	12:00
Hours:	5

Log  :	Went out to the tower today to set things up. We tested the 802.11b/g
		card with a 'b' laptop - we got about 300/400m out of the connection.
		The carriage didn't work, so we left the receiver running at the bottom.

Saturday, 17 April 2004
In   :	08:00
Out  :	10:00
Hours:	2

Log  :	I went to the tower today to check up on the receiver - everything is
		still running well.

----------------
Total Hours : 19
----------------

Sunday, 9 May 2004
In   :	13:00
Out  :	17:00
Hours:	4
In   :	20:00
Out  :	23:00
Hours:  3

Log  :	I'm cleaning up /projects/opengps and also updating the website.
		Things are cleaned up, I also started working on ogDataParser

Monday, 10 May 2004
In   :	08:50
Out  :	17:00
Hours:	7

Log  :	Ahh... First day of summer. Now to work on the ogDataParser sw.
		The GPS group had lunch today, I had a pretty good pizza. Anyways, my
		ogDataParser code is coming along well - I spent a while talking to
		Dallas and Penny about what to do this summer also. The conclusion was
		that for the next month (until Dennis Akos comes back), I will analyse
		data collected with my software at the tower and work on the OpenGPS
		code.	

Tuesday, 11 May 2004
In   :	10:00
Out  :	18:00
Hours:	8

Log  :	I'm working on the ogDataParser program. I installed the 250GB HD into
		chandra today and am busy copying all data files over.

Wednesday, 12 May 2004
In   :	12:00
Out  :	23:00
Hours:	9

Log  :	I spent most of today reorganizing my office and setting up jasmine
		with the other 250GB HD - for some reason, however, jasmine sees it as a
		136GB HD. I flashed the BIOS with no results. I'll look into this later
		- for now I'm going to work as it is.

Thursday, 13 May 2004
In   :	15:00
Out  :	19:00
Hours:	4

Log  :	Copying data to jasmine - for some reason I get 'corrupted MAC' after a
		few minutes - this resets the SCP connection.

Friday, 14 May 2004
In   :	15:30
Out  :	19:00
Hours:	3.5

In   :	20:20
Out  :	22:20
Hours:	2

Log  :	Well, my main computer is not working yet, but I really have to start
		doing some data analysis. I've run into a problem when looking
		at the measurment data. For some reason ms_counter for CH0 and CH11
		is off by 4ms?! This is not possible, since Meas data is always
		available at the same time. I had a look at CH0 and CH10 - these
		ms_counters match up (off by 1ms every time, but this is acceptable).
		The code phase diff is also 3.75 between them. So the fact that CH11 and
		CH0 are different must be because of either 'multi' commands... wait!

		Perhaps this is not a bug. If codefreq on average is faster for ch0 than
		ch11, then there will be a offset.

Monday, 17 May 2004
In   :	09:00
Out  :	17:00
Hours:	8

Log  :	I worked some more on the data analysis. For some reason it appears that
		my ms_counters do not match. I think this is because the code DCO value
		determines the ms_count value.

Tuesday, 18 May 2004
In   :	09:30
Out  :	17:00
Hours:	7.5

Log  :	We had the general GPS meeting. I talked to Dallas afterwards and we
		might have resolved the ms_count issue: When comparing the ms_count
		of SIMMILAR TOW values for CH0 and CH11, they are off by as much as 16
		seconds! I must look at the code and figure out a way to resolve this
		ambiguity.

		OK. We saw some odd codefreq behavious (+-40Hz steering of code DCO).
		This was because I used the plessey non-normalized code loops.

Wednesday, 19 May 2004
In   :	10:00
Out  :	17:00
Hours:	7

Log  :	I changed the timestap to be incremented only when readTask is entered.
		This allows all channels to be synched with the same stamp.

Thursday, 20 May 2004
In   :	10:30
Out  :	22:00
Hours:	9

Log  :	Well, I just got word that we are going out to the tower on Monday. I'm
		going to fix some of my bugs and hopefully get a good tracking loop
		going.

Friday, 21 May 2004
In   :	08:00
Out  :	17:00
Hours:	8

Log  :	Aha! Carrier is using a PLL now and code tracking a filtered DLL from
		Beyerle's OpenGPSRec.

---------------
Hours: 81
Reported: 80
--------------

Monday, 24 May 2004
In   :	07:30
Out  :	15:00
Hours:	6

Log  :	We went out to the tower today.

Tuesday, 25 May 2004
In   :	10:00
Out  :	15:00
Hours:	4

Log  :	I showed Dallas today how to use my OpenGPS code. I also made sure that
		jasmine can run the OpenGPS code.

Thursday, 3 June 2004
In   :	13:00
Out  :	18:00
Hours:	5

Log  :	Back from vacation today - I got the receiver back and it appears that
		we collected 39GB of good data. I'm having a look at it now.

Friday, 4 June 2004
In   :	12:00
Out  :	17:00
Hours:	4

Log  :	Dallas and I are checking the data from the tower and making sure
		everything is in place. It appears that FirstRF wants to go back out
		Tuesday. I'm look at the data now, things to note: (20040526-1401)

		Temperature
		-----------

		Temperature appears fine, most of the time there are 2000 and 2002
		counts between samples, this is fine since we are not in real-time. When
		plotting the temp diff over the 10 days, there is one point where more
		than 3 seconds went by before another temperature sample. This might be
		because the 10 day data set was averaged, but I don't think so.

		At points the temperature went up to 118F.

		AGC
		---

		Data looks good, except that the AGC values appear to be inverted. When
		the temperature is high, AGC should push down, but it doesn't. Another
		contradiction, however, comes in because the (noise) spikes go DOWN for
		the AGC data - this is correct, since it means that noise is attenuated.
		There are times when the AGC ms_counter skipped one or two seconds worth
		of data. Noise level is about 500mV - this is quite high.

		IQ
		--

		ms_count: 
		A diff on ch.IQ(:,1) shows 3.5e6 samples with diff=2, 5000 samples with
		diff=1, 100 samples with diff=3.

		Carrier:
		This is strange, the carrier dco appears to jump between two values 25Hz
		away from each other, this only happens when the PLL is running.

		Code:
		Looks fine. Very 'discrete' 0.085 Hz steps (or so) - this is the
		resolution of the DCO.

		IE,IL:
		Once the PLL kicks in, this channel is only noise, interestingly though,
		as soon as the SNR pics up, one can note an increase in noise on Early
		and Late.

		QE,QL:
		Beautiful - As SNR increases, this power increases, but perhaps the
		noise increases also. I'll have to do a statistical analysis to make
		sure though.

		Meas
		----

		Looks fine, ms_count always between 199 and 200.
		

		

------------
Total: 19
Reported: 20
------------

Monday, 7 June 2004
In   :	10:30
Out  :	17:00
Hours:	5

Log  :	I looked some more through the collected data. Things appear in place. I
		also performed a test on ADC noise: Conclusion - the 400mVpp noise we
		see on AGC data is most likely generated by the AGC (and not opamp)

Tuesday, 8 June 2004
In   :	12:30
Out  :	17:30
Hours:	5

Log  :	I don't recall what I did.

Thursday, 10 June 2004
In   :	10:40
Out  :	17:00
Hours:	5

Log  :	Talked to Dallas and Maria about the AGC circuit for over an hour today.
		We need to get our hands on a sampling o-scope so we can examine the raw
		adc samples.

		I'm currently breaking the code up into serparate object files. I also
		had a quick look at /var/log/messages that was dumped during the tower
		test and apparently we missed a lot of accumulations. This is bad, I'll
		have to look into this more.

Friday, 11 June 2004
In   :	10:30
Out  :	16:00
Hours:	5

Log  :	Got new HD (120GB) from Jeff. Busy breaking up code into modules.

Sunday, 13 June 2004
In   :	11:00
Out  :	12:30
In   :	14:00
Out  :	15:00
Hours:	2.5

Log  :	Transfering data from 250GB to verbal and then will swop out HD. I'm
		still breaking up code into modules.

Monday, 14 June 2004
In   :	10:00
Out  :	19:00
Hours:	8

Log  :	I installed the new 120GB Seagate HD's. Now I'm going to setup
		everything for tomorrow's tower test.

		Ah! I broke the code up to into modules - it runs again. I moved to
		fixed point math though, since one shouldn't use math.h in the kernel.

		I looked some more at the missed accumulations of the last tower test,
		they happened about 2 or 3 times per hour, sometimes when only one
		channel is tracking, sometimes when both channels were tracking for 30
		mins. I'm going to fix up carrier.c and code.c to use only fixed point
		math in the future.

		I just split the signal and tracked for an hour, I then suptracted CH11
		phase from CH0 phase and got noise of about +- 0.04. This is not very
		good. I should try to filter my code DLL more.

Tuesday, 15 June 2004
In   :	08:00
Out  :	19:00
Hours:	9

In   :	20:30
Out  :	23:00
Hours:	2.5

Log  :	Went out to the tower this morning, switched reflected to 7 element.
		Tower started going up 10:37:35 MDT and stopped 10:47:00 MDT.

		Mike Moreau is visiting from Langley, it is about time to see whether I
		can get the Pivot running.

		Yup, pivot (one corr) is up and running. I'm currently looking at making
		it multi-correlator.

Wednesday, 16 June 2004
In   :	09:40
Out  :	18:20
Hours:	7.5

In   :	19:00
Out  :	22:30
Hours:	3.5

Log  :	Modifying the OpenGPS code for two correlator chips.

Thursday, 17 June 2004
In   :	11:00
Out  :	15:30
Hours:	4.5
In   :	21:30
Out  :	04:30
Hours:	7

Log  :	Modified code for 2 correlators and fixed a few bugs. Things are working
		well.

Friday, 18 June 2004
In   :	09:00
Out  :	15:00
Hours:	8

Log  :	NASA presentation and other things.

-------------
71.5
------------

Monday, 21 June 2004
In   :	13:00
Out  :	19:30
Hours:	6

Log  :	I'm going to debug my code phase change error.
		I think I fixed the 'directory time minute' increment issue.
		I ran the Plessey #3 board and I think the clock is not working
		properly, I get really noisy plots in the polar domain. I recompiled the
		code for PIVOT and PIVOT seams fine (without rebooting, both cards were
		in computer). This is mighty strange, I'll check out the ORION and other
		plessey receivers tomorrow.

Tuesday, 22 June 2004
In   :	10:00
Out  :	17:10
Hours:	6.5

In   :	19:30
Out  :	20:30
Hours:	1

Log  :	I ran the code on pivot overnight and channels 4,9,10,11 moved by +0.5
		chips. Strangely enough, ch 12-16 didn't change, which is sitting on the
		other correlator (multi is thus done twice for 2 chips). I fortunately
		dumped all the data and can debug this some more.

		My investigations so far:

		The code phase did NOT wrap around zero during the time the errors
		occured. The Carrier DCO frequency did NOT change (ch_carrier not
		commanded) during phase change. A diff of ms_count for any channels only
		show '2' during time of anomaly, this is as it should be. Code frequency
		was at ZERO. ch(1) - ch(2) ms_count also shows a diff of 0 during
		anomaly.

Wednesday, 23 June 2004
In   :	13:00
Out  :	23:00
Hours:	8

Log  :	Implementing the new acquistion slewing.
		I have looked at phase differences between CH0 and CH12 (cor0 vs. cor1)
		and there appears to be a 1/2000 of a chip difference between the two
		whenever a new frequency is commanded. I suspect this is because a multi
		to cor0 takes effect immediately, then a few microseconds later the
		multi to cor1 takes effect. This way the code DCO doesn't change at
		exactly the same time and they get out of phase.

		OK, the new DCO slewing works and I think I fixed the missed accum - I
		forgot to disable DMA on the new HD.

Thursday, 24 June 2004
In   :	09:15
Out  :	17:20
Hours:	8

In   :	17:50
Out  :	19:50
Hours:	2

Log  :	I ran the code overnight and it crashed! (kernel oops). This is the
		first time I've run LTT in a long time, hopefully they are related.
		Below follows oops message and ksymoops analysis:

		Jun 24 05:43:40 jasmine kernel: Unable to handle kernel paging request
		at virtual address fee36428
		Jun 24 05:43:40 jasmine kernel:  printing eip:
		Jun 24 05:43:40 jasmine kernel: c01347d7
		Jun 24 05:43:40 jasmine kernel: *pde = 00000000
		Jun 24 05:43:40 jasmine kernel: Oops: 0002
		Jun 24 05:43:40 jasmine kernel: CPU:    0
		Jun 24 05:43:40 jasmine kernel: EIP:    0010:[<c01347d7>]    Tainted: P
		Jun 24 05:43:40 jasmine kernel: EFLAGS: 00010282
		Jun 24 05:43:40 jasmine kernel: eax: cf0dec24   ebx: da3e68e4   ecx:
		fee36404   edx: 00000000
		Jun 24 05:43:40 jasmine kernel: esi: da3e68e4   edi: da3e68e4   ebp:
		c17d8700   esp: ed573e3c
		Jun 24 05:43:40 jasmine kernel: ds: 0018   es: 0018   ss: 0018
		Jun 24 05:43:40 jasmine kernel: Process gps (pid: 7875,
				stackpage=ed573000)
		Jun 24 05:43:40 jasmine kernel: Stack: da3e68e4 da3e68e4 c0134843
		da3e68e4 c0136ce6 da3e68e4 c17d8700 000001d2
		Jun 24 05:43:40 jasmine kernel:        00000016 000078e3 c013549c
		c17d8700 000001d2 da3e68e4 c17d8700 c012c872
		Jun 24 05:43:40 jasmine kernel:        c17d8700 000001d2 00000020
		000001d2 00000020 00000006 00000020 ed572000
		Jun 24 05:43:40 jasmine kernel: Call Trace: [<c0134843>] [<c0136ce6>]
		[<c013549c>] [<c012c872>] [<c012cab6>]
		Jun 24 05:43:40 jasmine kernel:    [<c012cb0d>] [<c012d35e>]
		[<c012d58c>] [<c0128b21>] [<c012d306>] [<c0128b3d>]
		Jun 24 05:43:40 jasmine kernel:    [<f889b7e0>] [<f889b826>]
		[<c0133474>] [<c0106f00>] [<c0106f42>]
		Jun 24 05:43:40 jasmine kernel:
		Jun 24 05:43:40 jasmine kernel: Code: 89 41 24 c1 e2 02 be 44 62 2a c0
		39 1c 32 75 0a 31 c0 39 d9
		Jun 24 05:43:40 jasmine kernel: Unable to handle kernel paging request
		at virtual address fee36428
		Jun 24 05:43:40 jasmine kernel: c01347d7
		Jun 24 05:43:40 jasmine kernel: *pde = 00000000
		Jun 24 05:43:40 jasmine kernel: Oops: 0002
		Jun 24 05:43:40 jasmine kernel: CPU:    0
		Jun 24 05:43:40 jasmine kernel: EIP:    0010:[<c01347d7>]    Tainted: P
		Using defaults from ksymoops -t elf32-i386 -a i386
		Jun 24 05:43:40 jasmine kernel: EFLAGS: 00010282
		Jun 24 05:43:40 jasmine kernel: eax: cf0dec24   ebx: da3e68e4   ecx:
		fee36404   edx: 00000000
		Jun 24 05:43:40 jasmine kernel: esi: da3e68e4   edi: da3e68e4   ebp:
		c17d8700   esp: ed573e3c
		Jun 24 05:43:40 jasmine kernel: ds: 0018   es: 0018   ss: 0018
		Jun 24 05:43:40 jasmine kernel: Process gps (pid: 7875,
				stackpage=ed573000)
		Jun 24 05:43:40 jasmine kernel: Stack: da3e68e4 da3e68e4 c0134843
		da3e68e4 c0136ce6 da3e68e4 c17d8700 000001d2
		Jun 24 05:43:40 jasmine kernel:        00000016 000078e3 c013549c
		c17d8700 000001d2 da3e68e4 c17d8700 c012c872
		Jun 24 05:43:40 jasmine kernel:        c17d8700 000001d2 00000020
		000001d2 00000020 00000006 00000020 ed572000
		Jun 24 05:43:40 jasmine kernel: Call Trace: [<c0134843>] [<c0136ce6>]
		[<c013549c>] [<c012c872>] [<c012cab6>]
		Jun 24 05:43:40 jasmine kernel:    [<c012cb0d>] [<c012d35e>]
		[<c012d58c>] [<c0128b21>] [<c012d306>] [<c0128b3d>]
		Jun 24 05:43:40 jasmine kernel:    [<f889b7e0>] [<f889b826>]
		[<c0133474>] [<c0106f00>] [<c0106f42>]
		Jun 24 05:43:40 jasmine kernel: Code: 89 41 24 c1 e2 02 be 44 62 2a c0
		39 1c 32 75 0a 31 c0 39 d9

		============================

		>>EIP; c01347d7 <kmem_cache_reap+1d7/1e0>   <=====
		>>
		eax; cf0dec24 <_end+ed12ea4/384c22e0>
		ebx; da3e68e4 <_end+1a01ab64/384c22e0>
		ecx; fee36404 <END_OF_CODE+51886e5/????>
		esi; da3e68e4 <_end+1a01ab64/384c22e0>
		edi; da3e68e4 <_end+1a01ab64/384c22e0>
		ebp; c17d8700 <_end+140c980/384c22e0>
		esp; ed573e3c <_end+2d1a80bc/384c22e0>
		
		Trace; c0134843 <s_start+63/70>
		Trace; c0136ce6 <__free_pages_ok+1f6/320>
		Trace; c013549c <reclaim_page+15c/250>
		Trace; c012c872 <find_vma+22/60>
		Trace; c012cab6 <unmap_fixup+26/180>
		Trace; c012cb0d <unmap_fixup+7d/180>
		Trace; c012d35e <exit_mmap+9e/170>
		Trace; c012d58c <.text.lock.mmap+39/4d>
		Trace; c0128b21 <flush_scheduled_tasks+91/a0>
		Trace; c012d306 <exit_mmap+46/170>
		Trace; c0128b3d <start_context_thread+d/30>
		Trace; f889b7e0 <[ext3]ext3_file_write+0/50>
		Trace; f889b826 <[ext3]ext3_file_write+46/50>
		Trace; c0133474 <vmfree_area_pages+a4/d0>
		Trace; c0106f00 <gunzip+550/5d0>
		Trace; c0106f42 <gunzip+592/5d0>

		Code;  c01347d7 <kmem_cache_reap+1d7/1e0>
		00000000 <_EIP>:
		Code;  c01347d7 <kmem_cache_reap+1d7/1e0>   <=====
   		0:   89 41 24                  mov    %eax,0x24(%ecx)   <=====
		Code;  c01347da <kmem_cache_reap+1da/1e0>
   		3:   c1 e2 02                  shl    $0x2,%edx
		Code;  c01347dd <kmem_cache_reap+1dd/1e0>
   		6:   be 44 62 2a c0            mov    $0xc02a6244,%esi
		Code;  c01347e2 <s_start+2/70>
   		b:   39 1c 32                  cmp    %ebx,(%edx,%esi,1)
		Code;  c01347e5 <s_start+5/70>
   		e:   75 0a                     jne    1a <_EIP+0x1a>
		Code;  c01347e7 <s_start+7/70>
  		10:   31 c0                     xor    %eax,%eax
		Code;  c01347e9 <s_start+9/70>
  		12:   39 d9                     cmp    %ebx,%ecx

		I checked whether codeErr gets updated on bit-edges and it does, so does
		TOW. So things still appear in sync.

		OK, I just got some more FIFO full messages, but I think this is because
		I ran two openGL plots over the network (CPU power on jasmine + eth),
		this way I might have pushed ./gps out of the way, perhaps I should
		renice the thing.

Friday, 25 June 2004
In   :	08:40
Out  :	17:40
Hours:	8

Log  :	The code walkthrough will occur today.

Saturday, 26 June 2004
In   :	12:15
Out  :	18:00
Hours:	6

Log  :	I think I found the problem with the PLL - since it keep all the power
		in Q, this means that atan(Q/I). I see some periodic bumps in the
		commanded carrier DCO (when in PLL). I checked this on chandra and
		jasmine. On jasmine on both pivot and orion do I see this, and on
		chandra on an plessey I don't see it. Odd. Also, the plessey in
		jasmine's IQ plot looks very weird (4 clouds instead of two), but with
		the same code on chandra (and a different plessey board) it is OK.
		Things to investigate, yes?.

		AHA! I fixed the error, when I increment the carrierDCO by using +=, I
		used have used -= because my writeGP2021 already take into account the
		the 4th stage of the IF is at a negative frequency.

Sunday, 27 June 2004
In   :	14:00
Out  :	17:30
Hours:	2

Log  :	I ran the PLL on chandra and didn't see the strange dips every 5
		seconds. After some more investigation it appears the the PLL
		'screwes' up every 5 seconds (polar plot) on jasmine when the HDD light
		goes on. I wonder whether it is EM interference or some bus sharing
		problem.

Monday, 28 June 2004
In   :	10:15
Out  :	17:00
Hours:	5

In   :	22:20
Out  :	00:30
Hours:	2

Log  :	I turned DMA back on on /dev/hdb the result is that the PLL doesn't
		obviously lose phase lock, but when looking at the commanded DCO, it is
		still evident that it happens.

		I had a closer look today at the chandra DCO data and the PLL DCO drift
		is also there (after 100ms worth of smoothing).

		OK, I just  finished hacking the tower code a bit. Things I hacked (and
		should later gracefully implement):

		1) Slaved CH11 doppler to CH0 PLL (thus when in survey mode CH11
			shouldn't update doppler, but should change code dco)
		2) Channel-based acquisition thresholds (acqlist channel-based)

Tuesday, 29 June 2004
In   :	08:00
Out  :	18:00
Hours:	8

Log  :	We went out to the tower today. Issues:

		1) PS/2 keyboard pins were bent - after bending them back it worked.
		2) Tracked direct signal (PRN18), but had to higher thresholds... I
		really should write some time of pullin code.
		3) Didn't make sure whether the reflected channels were working - the
		AGC reading did look good though.
		4) Dumped PRN change every time

		I'm investigating the PLL error when HD writes (and reads) occur.
		Currently when I do a 'cp' of a big file, (with DMA off), ./gps gets
		pushed aside (even with nice -10) and the FIFO gets full. The odd thing
		is that a 'top' doesn't show CP using any resources... I think it is
		that my fwrite to disk takes a long time since it waits for 'cp' to
		finish with disk access. Now what does this have to do with my PLL not
		working well? I don't know.

Wednesday, 30 June 2004
In   :	11:00
Out  :	17:30
Hours:	6.5

Log  :	I'm going to clean up code a bit and put it on the website for Mike
		Moreau. I went out to the tower again today and changed two things:
		I reset dumpCount when readTask started up because during rtInit it
		doesn't get reset for some reason. I changed so that when a PRN is
		selected it is not printed out - with the modified code whenever CH11 is
		done scanning through the one doppler bin it would print it out.

Thursday, 1 July 2004
In   :	14:00
Out  :	00:00
Hours:	8

Log  :	I'm going to write up our PLL issues and other things.

-----------------------------
Total Hours: 77
Reported : 77
----------------------------

Tuesday, 6 July 2004
In   :	10:00
Out  :	17:00
Hours:	7

Log  :	I'm going to look a little bit more at data analysis, then fix up
		tracking loops so that I get a good pull-in mode. After this it is time
		to switch to the PPC again.

Wednesday, 7 July 2004
In   :	12:30
Out  :	17:30
Hours:	5

Log  :	Looked at the data a bit more (4.12 vs. 3.9) - I mostly helped
		Marcus with the FPGA and other things.

Thursday, 8 July 2004
In   :	09:30
Out  :	19:00
Hours:	8.5

Log  :	I got my paperwork ready for the GBT work, also Marcus and I installed
		XP on the new shuttle and multivac (rack mount computer). I had a closer
		look at the data - Satellites repeat the same SNR pattern:

		PRN30: 24 hrs - 4.139 minutes
		PRN18: 24 hrs - 4.098 minutes

Friday, 9 July 2004
In   :	08:30
Out  :	17:30
Hours:	8

Log  :	I moved the website around a bit today, also talked with Dennis, Randy,
	 	Damon and Marcus about the VirtexIIPro board.

Saturday, 10 July 2004
In   :	13:00
Out  :	18:00
Hours:	5

In   :	19:30
Out  :	22:00
Hours:	2.5

Log  :	Coming up with schedule for PRNs to track during GBT.

Sunday, 11 July 2004
In   :	13:30
Out  :	16:30
Hours:	3

In   :	17:30
Out  :	21:30
Hours:	4

Log  :	Writing SOAP parsing program
		Remember: qsort must operate on struct and sort that - currently
		my 'time' and 'azel' is not in a struct

Monday, 12 July 2004
In   :	08:00
Out  :	17:30
Hours:	8.5

In   :	11:15
Out  :	01:45
Hours:	2.5

Log  :	I plan to wrap up the SOAP parsing program and then figure out the GBT
		observation schedule.

Tuesday, 13 July 2004
In   :	11:30
Out  :	17:30
Hours:	5

Log  :	The observation schedule is complete and the code runs in windows. We
		got chandra back yesterday with 105GB of data on it, I copied it
		overnight to /projeces/opengps. I plotted refelcted tracking and it
		didn't look very good, the problem is that I don't dump any 'lock
		indicator' information - so how do we k now when it tracked? We should
		probably plot it with some SNR threshold.

Wednesday, 14 July 2004
In   :	
Out  :
Hours:

Log  :	Travel to GBT

Thursday, 15 July 2004
In   :	08:00
Out  :	17:00
Hours:	8

Friday, 16 July 2004
In   :	20:00
Out  :	08:00
Hours:	12

Log  :	Data collection at green bank.
		Notes:

		- Bring Pen + paper
		- Sticky notes
		- CHECK data files with other references
		- generate all PRNs visible for all time, we can
		later on cut and paste text files.
		- AZ/EL tracking doesn't work again.
		- If track files too big (4000 lines) then it dies.
		- Build error checking program for track files
		- Generate files in both AZEL and RA/DEC
		- Dynamically slew around tracking point WHILE tracking
		- write peak finding utility
		- Use spectrometer next time (and other goodies they have)
		- AZ/EL correct for refraction? Should not because GBT
		already corrects
		- For exotic objects, look at http://ssd.jpl.nasa.gov/cgi-bin/eph
		(horizons.jpl.nasa.gov)

-----------------------------
Total Hours: 79
Reported : 79
----------------------------
Monday, 19 July 2004
In   :	13:30
Out  :	16:00
Hours:	2.5

Log  :	Hmm... I don't recall what I did today.

Tuesday, 20 July 2004
In   :	09:30
Out  :	17:00
Hours:	7.5

Log  :	I talked to Dennis about writing a paper on the GBT work for ION.

Wednesday, 21 July 2004
In   :	09:30
Out  :	17:30
Hours:	7

Log  :	We had our general GPS meeting:

		- Talk to Nic about sysadmin work
		- Temperature sensor for LNA
		- Timestamp AGC for Arian

		I fixed my code today so that acqlist.txt has a channel specific
		input also.

		Dallas found an anomaly in the TOW stamp for data

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

		He searched all other directories but no other anomalies were found.

Thursday, 22 July 2004
In   :	13:30
Out  :	18:00
Hours:	4.5

Log  :	Slow day for me. I fixed up the Reflected-SNR paper to include newest
		orbit predictions and such. I'm also thinking about writing a GUI
		for changing tracking loop parameters dynamically. I talked to Penny
		about her class, basically the following is required:

		1) Carrier tracking GUI
			- Transfer function (2nd Order)
			- Switch PLL + FLL
			- Change BL,Zeta, gain, etc.
		2) Code tracking GUI
			- Transfer function (2nd Order)
			- DLL params?


Friday, 23 July 2004
In   :	09:30
Oout :	19:00
Hours:	9

Log  :	Here we are again. I don't really know what I'll be doing today.
		Well, I implemented a msglog() function to log all messages for OpenGPS
		to a file.

Monday, 26 July 2004
In   :	09:30
Out  :	18:00
Hours:	8
In   :	19:00
Out  :	00:00
Hours:	4

Log  :	I'm going to see how I can implement the GUI and also improve tracking
		loops. Look at wxPython - looks very good.

		Idea: Write C-based TCP/IP-RTAI interface program that one can use to
		remotely display IQ data and send commands. This way one can run 'menu'
		'gpsplot' and other tools remotely on windows/unix systems.

		I dropped wxPython becuase ogClient will be too big for python, need
		quick response.

Tuesday, 27 July 2004
In   :	09:10
Out  :	19:00
Hours:	9
In   :	20:00
Out  :	21:30
Hours:	1.5

Log  :	Well, I switched to wxPython again, it is absolutely impossible to
		program this GUI stuff in C++. I also implemented a 'forking' server
		that can handle multiple clients.

Wednesday, 28 July 2004
In   :	10:30
Out  :	19:00
Hours:	8.5

In   :	21:00
Out  :	01:30
Hours:	4.5

Log  :	Worked more on the python GUI program. I can now move the slider
		and let the server update values.

		BUG: logmsg() stopped dumping after about 9/10 minutes, debug.
		(this happened even though the code tracked fine for another 2 hours)

Thursday, 29 July 2004
In   :	11:00
Out  :	19:00
Hours:	8

Log  :	Well, I can now move sliders and update values. I'm but a few minutes
		away to controlling this thing in real time. We also discussed the NASA
		SMEX flight that will start around 16 August

Friday, 30 July 2004
In   :	08:40
Out  :	21:30
Hours:	11

In   :	22:00
Out  :	04:00
Hours:	4

Log  :	I plan to get a lot done on the tcpip client code. tcpip client working
		well. I just heard that we need to get the rackmount hw ready for a NASA
		flight by Monday/Tuesday. I'm busy installing gentoo linux on the
		rackmount computer. I couldn't install rh8 because it didn't see the
		CDROM.

---------------------------------
TOTAL HOURS: 89
REPORTED: 80
FREE HOURS: 9
---------------------------------

Sunday, 1 August 2004
In   :	11:00
Out  :	22:00
HOurs:	10

Log  :	Busy installing RTAI and patched kernel. Let's hope that things work
		with the new gcc 3.3.2 compiler

		OK, here is where we stand:

		RH8 booted from the CD but couldn't find the CDROM to install from. I
		thus decided to with gentoo linux. The default gentoo linux comes with
		gcc 3.3.2 (or so) installed, now RTAI USED to say that they recommend
		gcc 2.95.3 - I ignored this for now, compiled linux kernel 2.4.25 with
		RTAI patch (just like chandra), but for some reason shared memory
		doesn't work. I run a simple RTAI test program for shm and it doesn't
		get the right values from the kernel.

		I then compiled gcc 2.95.3 and recompiled the kernel and RTAI and
		OpenGPS with this compiler - same problem. The funny thing is that on
		chandra (replica system with AMD (not intel) CPU) it works fine. The
		fact that even the SIMPLEST shm example doesn't work. This means that my
		code is not at fault here but something with RTAI/kernel/CPU.

		I have... run out of ideas. Perhaps I can netboot redhat8...
		damn, but I don't think that will fix it, this is a KERNEL and RTAI
		issue, *NOT* distro.

		I tried rtai 3.1-test4 with kernel 2.4.25. This didn't work. I'm going
		with an older kernel now with old rtai.

		I'm now trying 2.4.20 and 24.1.12 for rtai... doesn't compile

Monday, 2 August 2004
In   :	09:00
Out  :	19:00
Hours:	9

Log  :	Well, I'm going to try a few more tricks I have up my sleeve and then
		perhaps just drop in another motherboard.

		OK. I got things to work (shmem example works at least). I had to modify
		the include file /usr/realtime/include/rtai_shm.h and change VMALLOC to
		USE_GFP_KERNEL for alloc/free function defines.

Tuesday, 3 August 2004
In   :	11:00
Out  :	16:00
Hours:	4

In   :	18:00
Out  :	01:00
Hours:	6

Log  :	I took the rack home and worked some more in it. Now I still use
		GFP_KERNEL for memory allocation, but the sw doesn't crash as often.

Wednesday, 4 August 2004
In   :	09:00
Out  :	20:00
Hours:	9

Log  :	Now my stuff works, but Dennis' samping receiver doesn't work. We
		installed XP on chandra with no luck.

Thursday, 5 August 2004
In   :	11:00
Out  :	20:00
Hours:	8

Log  :	We finally decided to put XP on the UCEC computer and go with that. Now
		I have to get the PCI plessey running within a week.

Monday, 9 August 2004
In   :	13:00
Out  :	18:30
Hours:	5.5

Log  :	Time to clean up the lab and get the UCEC computer together again. I
		put the SuperMicro mtb in the UCEC computer and things check out fine.
		

Tuesday, 10 August 2004
In   :	11:00
Out  :	20:30
Hours:	9.5

Log  :	Still hacking the PCI device.

Wednesday, 11 August 2004
In   :	09:30
Out  :	18:00
Hours:	8.5

In   :	19:00
Out  :	05:30
Hours:	10

Log  :	The PCI is not working yet... hold on for more info.

Thursday, 12 August 2004
In   :	10:00
Out  :	18:20
Hours:	7

Friday, 13 August 2004
In   :	08:30
Out  :	17:00
Hours:	8

Log  :	I'm debugging the PCI card some more, currently I have 31 logic analyzer
		lines hooked up to the thing and I'm comparing the RTL PCI module W/R to
		my code W/R - they appear exactly the same, except that mine doesn't
		work.


----------------------

Total: 94.5
Left from last pay: 9
Hours reported: 80

Free Hours: 23.5

----------------------

Friday, 12 November 2004
In   :	13:00
Out  :	16:00
Hours:	3

Log  :	Went to the tower to swap out the HD and extend the tracking file. I was
		a bit late for my office hours today. NOTE: check time on clock, it is
		drifting? Dallas pointed out that some TOW values are wrong for OpenGPS
		data. I did some more investigation and it appears that  the TOW gets
		decoded 3 seconds in the subframe (exactly halfway in). Usually two of
		these values would be off (6 seconds apart, but offset by 3 seconds into
		the true subframe). The 3rd TOW would then be delayed by 9 seconds and
		be correct (9 seconds places it on the correct subframe start/end).

Monday, 15 November 2004
In   :	11:20
Out  :	17:00
Hours:	4

Log  :	Dennis is going to test the rack mount today for a potential tower
		experiment.
