Alan B. Pearce <A.B.Pearce <at> rl.ac.uk> writes:
> program for hams. I seem to remember periods of 50% to 150% being used for 
> timing received streams.

I'd rather measure timing for a while and sort marks into two bins, 'long' and 
'short', *then* I'd compute some discrimination limits based on that, and then, 
I'd try to start decoding based on that, and while updating it (and maybe 
median filtering to cast out 'aliens'). There would also be two averages for 
spaces (short and long(er)). But for a PIC, this gets a little long in the 
tooth, so I'll try something simple, like:

// pseudocode, untested and almost certainly wrong and lacking in more than one
// way
Hunt=0; // 0...HUNTED, RECEIVING 
Ditcount=0; Dittime=0;
Dahcount=0; Dahtime=0;
Ditspcount=0;    Ditsptime=0;
LLspcount=0;     LLsptime=0;
Acc = 1;
Flags &= ~(IDLE | RECEIVED_CHAR);
// try to decode characters. Output in Buffer marked by Flag
while((what,time)=measure_period()) {
  // detect no signal
  if(what == TIMEOUT) { 
    Flags |= IDLE; 
    if(Hunt == RECEIVING) {
      Buffer = Acc; Flags |= RECEIVED_CHAR; Acc = 1;
    }
    continue;
  } else { Flags &= ~IDLE; }
  // detect enough training 
  if(Hunt < HUNTED) {
    if((Ditcount >= DITS) && (Dahcount >= DAHS) 
      && (Ditspcount >= DITSPCS) && (LLspcount >= LLSPCS)) 
        Hunt = HUNTED; // now wait for a long space which will start recv.
  }
  // key down
  if(what == MARK) {
    // first assume dits
    if(!Ditcount++) { Dittime = time; continue; }
    else {
      if(time > 2 * Dittime) {
        if(!Dahcount++) {Dahtime = time;}
        else {Dahtime += time; Dahtime /= 2;}
      } else {
        if(time < 0.5 * Dittime) {
          if((Hunt < HUNTED) && (time > GLITCH)) {
            // got it wrong, swap dit and dah accumulators
            t = Dittime;  Dittime  = Dahtime;  Dahtime  = t;
            t = Ditcount; Ditcount = Dahcount; Dahcount = t;
          } else {
            // toss current char on glitch
            if(Hunt >= HUNT) {
              Acc = 1; Hunt = HUNT;
              Buffer = GLITCH_CHARACTER; Flags |= RECEIVED_CHAR;
            }
            continue;
          }
        }
        if(!Ditcount++) Dittime = time; 
        else {Dittime += time; Dittime /= 2;}
      }
    }
  }
  // key up
  if(what == SPACE) {
    // ... similar to above to fill initial bins

  }
  // start/stop condition iff ready (HUNTED or RECEIVING)
  if((Hunt >= HUNTED) && (time > 5 * Ditsp)) { 
      // end of previous character
      if(Hunt == RECEIVING) {
        Buffer = Acc; Flags |= RECEIVED_CHAR; Acc = 1; Acl = 0; continue;
      }
      // expecting first symbol of next (or first) char
      if(Hunt == HUNTED) Hunt = RECEIVING;
    } 
  }
  // if everything works, receive symbols
  if(Hunt == RECEIVING) {
    Acc <<= 1; if((what == MARK) && (time > 2 * Dittime)) ++Acc;
    if(Acc == 0x100) { 
      // 8 dits, drop it (max receivable is 7 symbols/char due to byte enc.
      Buffer = ERROR_CHARACTER; Acc = 1; Hunt = HUNTED; Flags |= RECEIVED_CHAR;
    }
  }
}

Note1: the symbol TRAINED can be used instead of HUNTED.

Note2: the bins need not start empty. But during receiving, if the speed changes
abruptly, the system should be reset or forced into training mode. Some 
heuristics may have to be used for this.

Note3: There may be a more elegant way to do this, but likely involving a single
'action' function and a lot of variables stored as a structure. Then the code 
could be shared for MARK and SPACES sections.

> >> The code is somewhere in the historical records department
> >> at Byte Craft then all I need is to find a paper reader that
> >> has been run in the last 20 years.
> >
> >I think that that could be helped. There is a way to transfer paper tapes
> >into computers using a scanner and a black sheet of paper as backing.
> 
> Oh, I hadn't heard of that scheme. Sounds like it could be a do-er though, 
> but would require a fair amount of operator time. I have some old tapes of 
> bits I wouldn't mind getting at, and have been considering building a little 
> reader with some surface mount leads on some strip board as receivers, and a 
> second set as emitters, with a small stepper or DC motor to pull the tape 
> through. A suitable small PIC with UART to send it out as serial stream and 
> control the motor would complete the scheme. 

The hint about the camera and (which is also a) scanner is the winner. Just run 
the camera in capture mode and pull the tape slowly in front of it. The computer
 can make sense of the resulting movie. Note that I haven't seen this part 
working but it should. There is no difference between individual consecutive 
frames split from a movie and a set of consecutive scans. If the camera manages
10fps and its fov spans 10 x 10 cm you can pull the tape with at least 50 cm/sec
without losing data. That is not so slow.

Peter P.



-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist