Two Problems and a Reward

[Tom Droege <tdroege@veriomail.com>]

I have two problems that I would like to get solved.  Solving either 
problem will move you to the top of the list to get a Mark IV if you are on 
the list.  If you are already at the top of the list, solving either 
problem will maintain your position.  Solving both problems will get you on 
the list near the top if you are not presently on the list and have an 
interest in operating a Mark IV.  I reserve the right to negotiate with 
whoever wants to take on these problems.  Neither problem is more than a 
few evenings of work for the person with the right experience.

Problem 1  Speed Up Stamp Communication

Problem 2 Faster Memory to Disk Transfer

Discussion of Problem 1

At present communication with the stamp is quite slow.  The stamp will 
accept serial communication at speeds up to 38400 baud, possibly even 
faster.  QBasic supports COM speeds up to 9600 baud.  At present, the only 
way I could get communication to work was to run the Stamp - PC 
communication at 2400 baud and to put a .4 second delay in the stamp 
code.  This is a great pain to me.  During debugging, I have to turn of 
power to the Mark IV boards many times.  I can leave the PC on, since it 
connects only through the serial port, but I have to restart the program 
and load the DACs each time I turn back on.  There is also the mystery 10 
second delay that is probably a late DOS enhancement.  Note that I have 
already determined that there is a difference between running under real 
DOS and running in a DOS window under Windows.  One inserts an extra 
carriage return in the serial communication.  This is patched in the QBasic 
code to make it work depending on which system is being operated.

The goal is to get the .4 second delay out of the Stamp, and to run at at 
least 9600 baud.  This should get the complete DAC load and readout of the 
ADC channels down to a fraction of a second from the present near 
minute.  Note that this should be possible to do in a DOS window under 
WIndows.  For testing I need to run Windows and switch back and forth 
between the DOS window and the Windows program that I use to read an image 
to see if it is OK.

I will furnish a Stamp test kit and the necessary code to anyone who wants 
to work on this.

This task will be considered successful when I can run the stamp link at 
9600 baud or faster.

Discussion of Problem 2

I will probably want to run with my QBasic code indefinitely.  This is 
because I will be constantly designing improvements and will need to be 
able to write code to work on them.  Chris is debugging C code to run in 
real time for final operation.  It is unlikely that I will be able to take 
the time to learn to make patches in this code.  It would be a great help 
if the Memory to Disk transfer worked faster.  Andrew and Chris have 
demonstrated that this can be done quite fast, even with a slow PC.  There 
is an advantage to using an old slow machine for this work as soon new 
machines will not have ISA slots.  So we will have to run with old slow 
machines from the junk pile to get an ISA slot.  This is just fine as they 
are cheap.  So why not use an old slow cheap machine for the routine task 
of running a camera?

What is needed is a .exe program that does the following:

1) Gets parameters from two disk files.  One contains routine things like 
location, operators name, etc..  That is all the stuff that rarely changes.
The second file gets quickly changing things like shutter open and close 
times, time of exposure, current file name, etc..  That is the things that 
change.
2) Read out the Memory card and write a .fts file.  This requires some 
research on what exactly we want to put in the .fts header.  An ideal 
program would allow any possible .fts format by just reading stuff out of the
routine file.

Chris has demonstrated that this can be done in 20 seconds or so on a 
relatively slow machine.

Given such a program, I will patch the QBasic code to shell out to the 
program to make the transfer after writing the right things in the fast 
file.  Possibly this will need to be done in a file on a ram disk for speed.

I will work with whoever takes this on to create specifications and to 
debug the code.

This task will be considered successful when I can read out the Memory in 
under 25 seconds with my 500 MHz K6 and read the resulting image with Image 
Scientist or other .fts reader.  Another requirement is that most things 
are possible to be put in the .fts header through editing the parameter file.

Tom Droege