Okay. Still having issues, even with the new code.
I have a new simple PCB to rule out my bad soldering.
I had some ideas on how to 'remote' debug the issue.
For now, I just assume it either my coding, interference from the sdcard, noise pick-up or msx machine variation.
To rule-out the sdcard, I have made a serial-only version (link) that just dumps the tape data to the serial port and it shows the number of bytes received and the crc32 value. If this works correct, it is the sdcard.
In order to check for decoding errors, I have made a small Arduino program that just sends raw adc values to the serial port (link). It acts as a sort of tape recorder that samples at 19.2 kHz. This Windows (console) program (link) can read the data and store all values in a file. You need to tell it what com port to listen to and how many seconds to record.
If you could record a data stream from a test file and share it with me, I can try to fix the decoding part.
If that does not work because of noise, I can send you this prototype as a best effort to reduce noise.
If that does not work, let's try the opamp circuit :)
That’s great! I have been working on something similar I guess Link
Please share your code.
Thanks!
Here you are, the link to the code (as it is today) and a basic explanation of how it works.
The front-end to the tape recorder that I am using is my FA-32 diy
Hi RvS,
I was amazed to see that both our engines are structurally very similar, without any of us having shared any info with each other 
I have faced some difficulty decoding the start bit when the signal was played with the phase inverted (the HB-2400 provides such functionality). At the end I found that I was comparing the size of a consecutive pair of pulses with 2/4 of a bit time instead of 3/4 of a bit time (like BIOS).
The time interval preceding the start bit is tricky because of a distortion that can happen on the signal at the moment of the start bit.
Hi RvS,
I was amazed to see that both our engines are structurally very similar, without any of us having shared any info with each other
Remarkable indeed! It is good to see someone else in 2021 still working on tape
I cheated a bit in my circuit to get the duty-cycle closer to 50% by modifying the reference voltage because the LM358 is not a rail-2-rail opamp. Also, I opted for the 'rising' (or 'falling') edge for the interrupt, this makes the '0' or '1' classification easy, regardless of the duty-cycle of the incoming waveform. This might help detection.
I am looking at your work for the Casio machines and the FA32 unit. Let's see if we can make a proper tape-input for arduino like tape replacements.
Hi,
Although the MSX is a standard, I have not been able to find the exact definitions for the tape signals.
What I have found in the MSX Technical Handbook is the following:
In order to digitize the signal, I used an amplifier and a comparator with a bit of hysteresis. (schematic and board available on github). To remain in '80s style, I used a LM358, powered by the 5V from the Arduino. This is not a rail-2-rail opamp, so I adjusted R5/R6 to get the duty cycle close to 50% (close enough) and omitted R7. If you want a closer approximation, you can change R6 to 10k and change the opamp to a TLC2272 (rail-2-rail cmos opamp).
With the LM358, the output signal was 'close enough' for me (yellow: tape signal from the MSX; blue:output from circuit). The tape signal looks noisy due to bad probing...
The duty-cycle is close to 50%:
So far, I have only been able to test this on my MSX (NMS8245). I am curious if you have more machines to check to tape signals.
Hi Rvs
Now that I noticed that you are using the MIC output of the msx as a source for the recording. I was using a tape recorder, which provides a signal with greater amplitude but with more distortion.
