CASDuino recording functionality

Page 3/5
1 | 2 | | 4 | 5

By RvS

Expert (72)

RvS's picture

23-10-2021, 21:50

I got around to running tests with both an Arduino Uno (original) and an Arduino nano clone with probably a fake ft232 chip. Most of the tests I did with the Uno board in this set-up:

Just the board, the SD-card interface (now moved to pin 10). The display is not used.
With both an old 2GB SD card and a class 10 32GB SDHC card (fat32), this works (the data is correctly written):

Ready
Signal detected, 1200bps, threshold [au]:1849
Filename:RECORD10.CAS
header
Writing time [µs]:247464
Error:18
Write time [µs]:2440
header
Writing time [µs]:5408
Write time [µs]:8320
Write time [µs]:8224
Write time [µs]:8280
Write time [µs]:7748
Error:18
Error:16
File closed

Here the initial write is also long (I formatted the card in Windows 10). I reformatted the cards wit the 'official' tool from the SD card association https://www.sdcard.org/downloads/formatter/
Now the initial write time is much lower.
The set-up with the nano is very similar, but the success rate at 2400bps is lower, probably due to noise. The 16k data file at 1200 bps was saved correctly though on a very old 128 MB SD card.

Signal detected, 1200bps, threshold [au]:1836
Open file time [µs]:16184
Filename:RECORD00.CAS
header
Writing time [µs]:23340
Error:18
Write time [µs]:2396
header
Writing time [µs]:5312
Write time [µs]:8276
Write time [µs]:8176
Write time [µs]:8260
...
Write time [µs]:8272
Write time [µs]:8320
Write time [µs]:8164
Write time [µs]:96932
Error:20
Error:16
Write time [µs]:772
File closed

I found out that the Uno has a nice 3.3V regulator, but the Nano borrows the 3.3V from the USB serial chip, this might need some filtering. Some Nano's also use the CH340 chip, I have ordered a few to test those as well.
Can you check if the formatting tool helps to lower the initial write time?

By CASDuino

Master (249)

CASDuino's picture

23-10-2021, 22:26

I had thought about it afterwards and realised it could be the USB power so I will try powering via DC instead.

I'll also try the formatting tool too.

This is my setup for now.

By RvS

Expert (72)

RvS's picture

24-10-2021, 08:32

Almost forgot:
I used Arduino version 1.8.15 and SD library version 1.2.4

By RvS

Expert (72)

RvS's picture

24-10-2021, 21:28

An update from my side:
I have added 'buffer overrun detection' and removed some unused code (see github link).
Also, instead of using the 3.3V line that differs per board and manufacturer, I tried using the internal 1.1V reference from the 328p chip itself:

I may need to tweak the resistance values a bit, but in my samples it worked very well. This should eliminate a lot of noise and differences between boards. Also, I moved the ground connection for the SD card to the other side of the board to lower noise near the ADC pins.

By NYYRIKKI

Enlighted (5889)

NYYRIKKI's picture

24-10-2021, 23:00

I only now took a look and saw these:

Quote:

Xm(n)=exp(i*2*pi*m/N)*[Xm(n-1)+x(n)-x(n-N)

... type of things... To me this sounds like you need to get over the ditch without wetting your feet, but you are not considering jumping or rubber boots but instead you try to build some sort of a helicopter. Smile

I just mean... The original MSX TAPIN-routine is small and straight forward. Why you don't just convert it to 328p? Ok, 328p is faster so you would need to compensate the increased speed, but there would not be need for any frequency bins, sin, cos, sampling frequency etc. stuff that you have now put in... Practically the routines are just waiting pin to go down and then calculating time it takes to come up again. What is wrong with this approach on 328p? To me it sounds like these frequency bins just make it less tolerant for errors like wrong tape playback speed. (Well, not a real problem unless you dump from real tape player)

By CASDuino

Master (249)

CASDuino's picture

24-10-2021, 23:25

Okay. Tried with a DC on the nano and that didn't help.
Using the same IDE and SD.h

Using the ref is interesting. I'll have to check that out.

Going to have a look at adapting to the Mega2560 as that's the next logical step with the 328p being so small.

Hopefully this time the image will show.
https://imgur.com/gallery/vqeZRPo

By Danjovic

Master (201)

Danjovic's picture

25-10-2021, 05:54

I believe the main issue here is that the SD card library needs to do a lot of stuff every time a new record is written, and that will cost you precious CPU cycles.
You may try to decode and record raw bytes to an I2c eeprom (or fram), then transfer the data from the eeprom/fram to the sdcard.

By RvS

Expert (72)

RvS's picture

25-10-2021, 22:53

Quote:

... type of things... To me this sounds like you need to get over the ditch without wetting your feet, but you are not considering jumping or rubber boots but instead you try to build some sort of a helicopter.

What is wrong with helicopters? Smile
I agree that using DFT for decoding MSX tape signals is a bit over the top, but it does work and requires only 8 multiplications and 4 additions per sample for 2 bins (sin/cos are constants and can be pre-computed for 1200/2400 bps).

To use the MSX bios routines, I would need the output of the signal comparator from a circuit like the one in a previous post or do some calculations on the ADC data stream to mimic a comparator. I will try both methods to see if they work. The biggest issues I have now are noise and the unpredictability of the SD card latency.

A separate amplifier and comparator will solve all noise issues at the cost of more components and a bigger data buffer should help with the latency. The internal comparator of the 328p might also be an option if I can trim the offset properly.

I still hope that using the internal reference voltage will solve the noise issue and enable a casduino with recording functionality with only 2 resistors and a capacitor.

By CASDuino

Master (249)

CASDuino's picture

25-10-2021, 23:43

Okay. Bit more testing but using the old code

Elite save using ref.

Ready
Signal detected, 1200bps, threshold [au]:1909
Filename:RECORD08.CAS
header
Writing time [µs]:6418512
Write time [µs]:8160
Error:18
Error:16
Write time [µs]:6960
File closed

Still the latency.

Elite Save using 5V

Ready
Signal detected, 1200bps, threshold [au]:1896
Filename:RECORD09.CAS
header
Writing time [µs]:6417472
Error:19
Error:16
File closed

Still the latency.

Interestingly the internal reference voltage almost saved the file properly.

Going to try the same but with the new code however I think looking at the new schematic I may have wired incorrectly. Okay. I'm still using the 22k and the 4.7k resistors. I'll have to find 2 10k and see if that makes a difference.

Elite Save using Ref

Signal detected, 1200bps, threshold [au]:1894
Open file time [µs]:30632
Filename:RECORD10.CAS
header
Writing time [µs]:6416284
Error:19
Error:16
File closed

Recorded less too.

I don't know if SDFat library will be better or not but it's worth a try, however it would be best to try 1.1.4 rather than the latest which is 2.1.0

By Danjovic

Master (201)

Danjovic's picture

25-10-2021, 23:39

RvS][quote wrote:

...
I still hope that using the internal reference voltage will solve the noise issue and enable a casduino with recording functionality with only 2 resistors and a capacitor.

Do not worry about adding extra components as long as they pay off their tickets to jump in the project Smile

Page 3/5
1 | 2 | | 4 | 5