Electronic – Convert MP3 recording of data casette to serial data

audiocommunicationdataserialsignal

I have a retro EMCO F1P CNC machine with a matching M1 controller that comes with mini data cassettes containing the "Machine State Data" which must be fed into registers of the controller before operation.

Unfortunately my cassette is missing, but I have managed to find this MP3 recording of it online.

The machine also supports RS232 input of this data. So my question is thus, is the format of the audio in the mp3 recognizable, and would it be possible to deduct simply by looking at the audio in the MP3 to determine how to format the equivalent RS232 data?

Some hints are to be found on page 9 in the service manual of the machine:

RS232c interface (V24 and 20mA), 150 – 2400 bd tape recorder (Phillips
MDCR) 600 signs/sec. (corresponds to 6 kbaud)

This way I would avoid having to find equipment to record the MP3 to a cassette, instead I could simply craft a binary file to send over TTY from my laptop, and even better, write a small software that would craft this file on the fly based on parameters selectable from an UI.

EDIT: Here is a picture of the cassette player:

enter image description here

Best Answer

Well, maybe. It might be helpful to look at the circuitry that processes the audio data to try to figure out what it's doing. You mentioned the spec is 600 signs per second, corresponding to 6 k baud. That seems to me like they are using some method of multiplexing 10 bits into each 'sign'. This is could well be some sort of multitone modulation where each bit is represented by a different frequency. The trick would be figuring out the specifics of how the symbols are constructed and then how to re-frame that data for transmission over the serial interface. tl;dr - it may be doable, but it will require some reverse-engineering.

Edit: after opening up the file in Audacity, it actually looks like it may be some sort of NRZ code. Looks like a 3 level format of some sort.

I'm not sure what the name is for the encoding, but it seems that it's a series of positive and negative going pulses with gaps inserted between the pulses that represent the data bits. I believe these gaps represent 1s as there are several long segments of pulses with no gaps, and it's far more likely for a binary file to have a long section of 0s than it is to have a long section of 1s. It would not be very difficult to write a script to extract the data. However, I am not sure if that data will be in the correct format to transmit via the serial port.

Success! This looks like a description of a very similar format: http://www.unige.ch/medecine/nouspikel/ti99/cassette.htm#Cassette%20tape%20format

encoding

The timings are a bit different and I think the bit levels might be inverted from what they are on your tape, but it seems like a very similar format.

Related Solutions

Electronic – How to produce clock signals with data on serial port

RS232 does not involve a transmitted clock; the reciever must synchonize to the transmission using the start bit, and the baud rate has to be agreed in advance (or inferred from a sequence of characters transmitted, sometimes called "auto-baud")

(If that PIC has a UART, you could use it to make this project easier)

Reading a serial data stream with Verilog

You have two requirements here:

You need to make sure you sample that data at the correct time according to the bus needs.
You need to synchronize this data into your system clock domain.

There are a couple of ways to meet these needs.

First, if the bus clock is slow enough below your system clock, then you can synchronize the bus clock to your clock domain with a double flop. Then use a simple edge detector to determine when the rising edge is. This is used to safely sample the data line of the bus. Note that this achieves #2 automatically. Also, as noted here, this is the preferred way to do this in an FPGA.

This method has a drawback in that the data is sampled somewhere between two and three system clocks later than the actual 'on the pin' bus clock edge. If this is too long (due to your system clock not being fast enough in comparison), you have to go an alternative way.

In this method, you sample before synchronizing to the system clock domain. The reason is to make sure you are sampling at the right time according to the bus.

always @(posedge bclk) begin  // positive edge of bus clock
    sampled_data <= data;
end

At this point, you have sampled_data which is a signal in the bclk domain. You need to synchronize it to your system clock domain. To do this, you have to use handshaking or a FIFO.

One way that works is to do the shift register in the bus clock domain to get to parallel data. Then pass it through a dual clock FIFO to the other domain. FPGAs have primitives just for this use.

// Latch the data in the bclk domain
always @(posedge bclk) begin
    fifo_d <= {fifo_d[30:0], data};

    data_count <= data_count + 1;
    if (data_count == 31)
        fifo_wr <= 1'b1;  // This will latch fifo_d to the dual clock fifo input
    else
        fifo_wr <= 1'b0;
end

// Read the data out of the FIFO in the system clock domain.
always @(posedge clk) begin
    if (fifo_ready)
        synchronized_data <= fifo_q;   // Now the data is in your domain.
end

Other notes:

As with any I/O at the edge of the FPGA as well as between clock domains, you will need to correctly define the timing constraints. Do describe the details is a bit too general for this forum, but as recommended in the comments by Greg, this paper is a good source for understanding the needs for the clock domain crossing. The FPGA vendors tend to have decent write ups for input delay and output delay definitions as well.

Best Answer

Related Solutions

Electronic – How to produce clock signals with data on serial port

Reading a serial data stream with Verilog

Related Topic