Wed., Feb. 1st

• [ ] Ray wanted me to test the PADS license so he can do receiving on it, so that is probably my biggest priority for today.

Although we achieved our goal of streaming time-referenced pulse data to the server by the end of January, this doesn't yet represent a complete solution, because we can't yet match up the time-referenced pulse data to an accurate GPS time, for a couple of reasons:

1. Right now, the GPS module doesn't reliably acquire a time lock after initial power-up, without a lot of manual fiddling; need to try to fix this by letting server remotely try to massage the GPS into a happy state automatically.  Lots of new coding & testing work needed for this.
2. We need to program a reliable startup sequence for the whole system; most importantly, we need to ensure that the FEDM is up & ready to receive timing pulses before the very first timing-sync pulse is sent from the CTU, since otherwise (if the CTU starts first) there is no basis for matching up the sync pulses received with the OCXO clock cycles.  I described in detail a startup sequence that would achieve this in a recent blog post.

Therefore, my focus at the moment (over the next several days) is to do the above coding, since testing it (especially the GPS part) requires a lot of hands-on interaction with the hardware, and the development work is highly testing-dependent, since it's not obvious a priori what approach will work best with the GPS.  And of course, testing the startup sequence for the firmware also requires hands-on access to the hardware.  The students could conceivably help with the firmware & server-side code changes, but I'm not sure this will actually speed things up any, due to the synchronization overhead - the actual lines of code needed are fairly small, and it would probably take more of my time to get the students to understand what needs to be done, and to do it right, than it would take to just do it myself...  So for now, it probably makes more sense to have them work on a bigger job like the LogicLock coding.  Although that will require a lot of testing too.  Sigh... We have a real development bottleneck here, in that we only have a single instance of the hardware (and a single computer with the required software licenses) to test on, so my work station is a major bottleneck (and the students can't use it when I'm not here, since they can't get keys to the lab).  This severe resource constraint has always been a problem for this project.  Anyway...

A smaller, higher-priority task:  Yesterday, while working from home fiddling with the server code trying (so far unsuccessfully) to get it to work on MacOS, I broke something, and after that it wouldn't even work on my Windows Vista Home box under Python 3.1.4.  Need to get it running here at the lab again, at least.  Shouldn't take long. -- OK, that was easy; I just commented out the critical code changes in guiapp.py and COSMICi_server.py.  I'll return to the MacOS port some other time; it may be too much hassle for now.

The Senior Design students are having their team meeting here today at 3:00 pm, and I will talk with them before or after, except maybe Juan who is having car problems again.

Re: PADS:  Got the license file.  Now downloading the software.  Should take about an hour or so (>1GB file).

Ray suggested using the thermoelectric plate to test the condensation on the copper rod.  Set that up.  Plate and fan powered in parallel from 6V supply.  Drawing about 1.3A.

Next, let me go back to trying to set up an Eclipse-based build environment for the GPS app code, so that hopefully I can set the cpp options needed to use the ioctl() interface.

Here's ioctl documentation from the Nios II Software Developer's Handbook (p. 14-65):


ioctl()
Prototype: int ioctl (int fd, int req, void* arg)
Commonly called by: C/C++ programs
Thread-safe: See description.
Available from ISR: No.
Include: <sys/ioctl.h>
Description: The ioctl() function allows application code to manipulate the I/O capabilities of a device driver
in driver-specific ways. This function is equivalent to the standard UNIX ioctl() function. The
input argument fd is an open file descriptor for the device to manipulate, req is an enumeration
defining the operation request, and the interpretation of arg is request specific.
For file subsystems, ioctl() is wrapper function that passes control directly to the appropriate
device driver’s ioctl() function (as registered in the driver’s alt_dev structure).
For devices, ioctl() handles TIOCEXCL and TIOCNXCL requests internally, without calling the
device driver. These requests lock and release a device for exclusive access. For requests other
than TIOCEXCL and TIOCNXCL, ioctl() passes control to the device driver’s ioctl() function.
Calls to ioctl() are thread-safe only if the implementation of ioctl() provided by the driver
that is manipulated is thread-safe.
Valid values for the fd parameter are: stdout, stdin, and stderr, or any value returned from a
call to open().
Return: The interpretation of the return value is request specific. If the call fails, errno is set to indicate
the cause of the error.
See also: close()
fcntl()
fstat()
isatty()
lseek()
open()
read()
stat()
write()
newlib documentation

And, some relevant stuff from HAL/inc/sys/termios.h:


# define B0 0
# define B50  50
# define B75  75
# define B110 110
# define B134 134
# define B150 150
# define B200 200
# define B300 300
# define B600 600
# define B1200  1200
# define B1800  1800
# define B2400  2400
# define B4800  4800
# define B9600  9600
# define B19200 19200
# define B38400 38400
# define B57600 57600
# define B115200 115200


typedef unsigned char cc_t;
typedef unsigned short tcflag_t;
typedef unsigned long speed_t;


struct termios {
  tcflag_t  c_iflag;
  tcflag_t  c_oflag;
  tcflag_t  c_cflag;
  tcflag_t  c_lflag;
  char      c_line;
  cc_t      c_cc[NCCS];
  speed_t   c_ispeed;
  speed_t   c_ospeed;
};

Looks like PADS wants us to install a license server.  Great.  It's almost time to leave so I'll tackle that tomorrow.

In the meantime, in the GPS app (in my new Eclipse-based project at C:\f\DE3\S3\SB+SOPC\GPS_FPGA_app\Quartus_II_Project\DE3_GPSapp\software) at least I got a new function "set_gps_baud()" to compile, which should allow us to adjust the baud rate of the serial connection to the GPS module (may be helpful in case we need to revert to default configuration, which uses a different baud rate than we use in normal operation).  It starts with the FILE*'s for reading & writing, obtains the corresponding file descriptors using fileno(), and applies an appropriate sequence of calls to ioctl() to modify the speed fields in the termios structure.  It has not yet been tested, but I will get around to that after I write the new firmware code to allow the server to remotely massage the state of the GPS module.

This evening, I spent a while working on the server code from home.  After several hours of changes to model.py, as I continue migrating it towards the new, more sophisticated object model of the sensor nodes, it is getting pretty close to the point where I can start writing the code that actually interprets the data sent from the host, the first line of which is always (supposed to be) the HOST_TYPE message.  (Or did I call it NODE_TYPE?  Or SENSOR_TYPE?  Can't remember now...  Check the firmware.)  Anyway, continue working along this path later...  NOTE: The latest code changes still need to be exercised (regression tested) to make sure I didn't break anything.