• Print
• .

GPSbistatic

I'm writing a note to show that I can do this, -AK

1. Continuous data acquisition: CODAR can collect files continuously with no gap, which is nice for processing in ensembles
   • Using nc
     • not possible; they interact in unpredictable ways
   • Using acq400_stream.py
     • Yes BUT- the channels in each file do not necessarily line up because this is based on final file size, so it may do 10000 sets of all channels and then data from the first three channels in one file and start with the fourth channel for the next file
     • When combined with recording trigger signals (see below), it's possible to keep track of channels and reorder if needed
     • Probably also possible to slightly modify script to accept more precise file sizes to get correct amount of data in full channel sets
2. GPS restart: necessary to use restart or are other options faster and effective when format/language is not correct?
   • WARMBOOT is software reload and seems to fix what's necessary
   • COLDBOOT is like RESTART
3. GPS hangups: sometimes, the gps doesn't work correctly on reboot or it stops working for no apparent reason
   • Wrong baud rate - GPS does not answer when you ask it something (or comes up with very strange output that looks like a set of specifications in braces), but it also does not say that it cannot be contacted
     • A manual check can be done via: /bin/stty -F /dev/ttyPS1 speed
     • It should be 115200; note that if you check immediately after reboot, it may take a few seconds before it gives the correct rate without any intervention
     • To manually intervene, do: /bin/stty -F /dev/ttyPS1 115200 followed by /usr/bin/ubxtool -p WARMBOOT -P 29 -v1
   • Wrong data output - GPS sometimes spits out a whole lot of information for a simple request
     • A manual check can be done via: /usr/bin/ubxtool -p MON-VER -P 29 -v 1 | wc -l
     • It should be less than 20
     • To manually intervene, do another warmboot: /usr/bin/ubxtool -p WARMBOOT -P 29 -v1
   • These checks have now been automated into /mnt/local/dtacqcheck.sh that runs via crontab on the nuc; if problem is not resolved after a certain number of attempts (sometimes, baud rate that was okay before is not following warmboot to correct for wrong output, and vice versa), a dtacq reboot is triggered and the issue is logged in /mnt/local/dtacqerrors.log
4. Excessive time from dtacq reboot to ready: a single test showed 18:47 between reboot initiation and when dtacq was ready to output a real data file
   • Lots of sleeps; removing all cuts time down to 12:56
     • Which sleep commands are necessary and which are not?
   • Control loop tuning is inefficient when restarting; cutting out tuning leaves 2:57
     • The most gains can be made by improving the tuning initialization
     • Added capability to restart from last recorded tune value, assuming that only a short time has passed
5. Timing discipline: there are issues where timing (as indicated by location of Bragg scattering in relation to theoretical Bragg line frequencies) jumps drastically, especially after dtacq reboots
   • GPS timing wandering caused by not setting GPS location and switching to timing mode with fixed position
   • Errors in tuning script chain can create "fake" missed pps signals, where the pps is detected by GPS and is logged, but then lost by ppsmon script when making mean frequency calculations
     • Fixed with new version of ppsmon that also includes m300 and m1000 mean frequencies; contained in package 35-radcelf-2306021934.tgz
   • Real missed pps signals can happen and can send tuning into a spiral that it does not recover from
     • Modified radcelf-tune-pps.py to make a note of current tune value and ensure that new value does not deviate from old too much, assuming significant time has not passed since old value was noted
     • This needs further checking, perhaps to save a few old values instead of just one
6. Arming infinite wait: sometimes the dtacq does not properly detect that it is armed during radcelf-chirp-init.py and will hang forever
   • A manual check shows that the dtacq is armed, so I'm not sure why/how this happens
   • Fix: comment out the lines where it checks and waits in a loop
   • So far, no negative consequences discovered
7. Number of channels/recording trigger signals: some dtacqs started recording 20 channels instead of just the 16 data channels
   • A function of the scratchpad set up in /mnt/local/sysconfig/transient.init on dtacq: