On 5/10/2018 7:35 PM, Richard Cini wrote: > Herb -- > This is an interesting topic because I did some work on this for the Altair32 Emulator. I just dug the code out and it was just about 10 years ago. I was trying to add the ability to directly read WAV files (22050Hz, 8-bit) from within the emulator and Bob Grieb helped me with the Fast Fourier Transform code needed to make it work and tought me a bit about DSP and filter design. Bob’s expertise was DSP and filter design so we went with what he knew. The add-on basically became a WAV-to-digital converter based on the Altair ACR recording format. We used a configurable band pass filter and then FFT routines to extract the bit stream from the actual audio. I don't think it ever made it into the main code tree because of the inability to locate WAV images at the time. - Rich Cini ?On 5/10/18, 9:42 PM, "Herb Johnson" wrote: I'd be glad to add your information to my Web page, and point to your Altair32 emulator, especially if you describe the ACR recording format (so the link is useful_. If you can add some details to your Web page at some later time, that would be good. Otherwise, here's my reaction, and we can take the discuss back public if the response isn't embarrassing. FFT's are pretty fancy means. These tapes were designed for simple decoding, by decoders expecting fixed frequency/period waveforms. Plausible software can look at analog zero-crossings, count samples to get frequency/period, and go from there. Or, decoding hardware runs timers and creates sampling windows in time, same deal. On 5/11/2018 Richard Cini wrote: Herb: I looked at the code that I used and I think the below subroutine comment provides the creates detail. The rest of the code opens the WAV file and uses the Windows API to navigate the file format to extract the samples and process them. I can always send you the source code if you're interested, but here's the comment: /***************************************************************************\ * * FUNCTION: ProcessWavFile ( PSTR ) * * PURPOSE: Main loop for PCM sample processing * * PARAMS: Pointer to filename of WAV file * * RETURNS: Success, failure, or cancel. * * COMMENTS: * * Basically, what we have to do is mimic in software the electronic * circuitry required to process audio samples to extract the recorded * pulse stream. Thanks to Bob Grieb for outlining the steps required * so I could start coding the wrapper around the FIR algorhythms and * providing ongoing assistance with writing and testing the * efficiency of the code. * * In the first revision of the ACR, binary data is recorded with the * frequencies 1850Hz (0) and 2400Hz (1) at 300 baud. Later versions * of the ACR used the Bell 103 FSK frequencies of 2025Hz (0) and * 2225Hz (1). 300 baud yields a bit frame of 3.3mS (1/300). * 22050/300 is 73.5 WAV samples per 3.3mS bit frame. We selected an * averaging period of 1.67mS, so each frame we will examine contains * 36.75 samples (rounded to 37). At 300 baud, each data bit is * recorded * as 8 samples of 2400Hz (2400/300) or approximately 6 samples (6.17) * of 1850Hz (1850/300). This is a sliding frame, so for each pass * through the loop, one processed sample drops off the back and one * is added to the front and then averaged. The running averages are * compared to signal 1->0 or 0->1 transitions. If the 2400 average * is greater, it's a "1". If the 1850 average is greater, it's a "0". * * We selected an 81-node Hamming bandpass filter with 53dB of * rejection. We used the on-line filter design tool at this Web site: * http://www.dsptutor.freeuk.com/FIRFilterDesign/FIRFilterDesign.html * to create the bandpass filter coefficients. This tool assumes a * sampling rate of 8000Hz, so the frequency ranges input into the * tool had to be scaled down by the ratio of 8000/22050. The * bandpass range was widened by 8% on either end to allow for * variation in the signal. * * The filtering code converts the raw audio samples recorded by the * sound card into 0's and 1's based on the existence of the two * frequencies we're interested in. In the output file, a logic 1 * appears as 73 bytes of 1 and a logic 0 appears as 73 bytes of 0. * * This output file is processed by a soft-UAR/T to convert the 73-byte * groupings back into plain 0's and 1's. The hardware UAR/T in the ACR * transmits bytes in LSB order (i.e., LSB goes out first), so the bit * stream has to be shifted as its received. * * The serial data frame is recorded as 10-bit words consisting of: * * Start Bit Data (LSB->MSB) Stop Bit * ========= =============== ======== * 0 8 data bits 1 * * \***************************************************************************/ Rich -- Rich Cini http://www.classiccmp.org/cini http://www.classiccmp.org/altair32