(in Sd Card) can i copy the entire file and rename it ?

Hi GoForSmoke. i made no claims to prowess, just relentlessness. Your note on 9600 is a bit cryptic, but it would suggest that my problem is in the receiver end, not the sender. I also suspect that you are recommending Nick's works to me.

I might add that the code above produces a lot of errors in the SD file running even at 19200 bps.

so it's very clear that this isn't the way to do it.



jferg: I might add that the code above produces a lot of errors in the SD file running even at 19200 bps.

so it's very clear that this isn't the way to do it.

Got any idea of why besides bad output?

What baud rate is the logger sending? How long is the data dump from the logger and can you change that serial dump to include software or hardware control, some sort of handshaking or protocol to let the MCU bite off 512B chunks to block-write to SD before the next transmits.

The logger and receiver both run at 9600 bps when transmission works ok. the files are very large up to 60 megs but will get much longer later in development. I have an intense interest in getting speed up but in addition to trying to absorb Nick's counsel you kindly referred me to, I'm going to do more googling to see if i can come up with a way to isolate the sd writing from the serial input. It could be that better buffer handling will allow increase in speed.

the nature of the data can tolerate random errors but I think error toleration can cascade into indifference and I may find that i need every byte for short period records - just don't know yet.

and i think the system does need a handshake.

But then, I'm not there yet.

thanks for your interest. all ideas welcomed.


Wow. it turns out there is xmodem for Arduino. suddenly I'm back to 1983 and CP/M days. if it works and at speed, problem solved.

You read the file at 9600 baud?

Reading from an SD file does not involve the serial port. So, any claims about baud rate being relevant are nonsense.

agreed, there is no transfer rate assigned to SD. bps does seem relevant but apparently only on the receiving end. Sending is fine to 115200 as seen and recorded on Linux terminal program. that i cannot record and save accurately to a nano resident SD at speeds above 9600 suggests I need to improve my code.

wouldn't you think?

I can only guess that your code is blocking/waiting somewhere that it should not. SD will sometimes hang up for short periods, the size and class of the card make a difference, that's why video devices use class 10.

Hey CP/M! I cut teeth on CP/M starting 1981. Even got to play some with MP/M. Remember when 4 MHz was fast and 64K was big RAM?

I haven't dug into the SD library but a buffer's in there, you should be able to fill it and it should write in burst mode. If you can buffer incoming data at the same time (should be able if your code does not block, 115200 baud takes 86.7 usecs, 1388 cpu cycles per char) you won't need handshaking but I'd use it.

Have a look at RS485 for your transfer, higher speed / longer cable possible. The length of your wires and if they are shielded can make or break your xfer speed especially with weak TTL signals. Even MAX232 chips could speed up a too-long serial connect.


We looked at MP/M for the office with a nice looking big machine which had S-100 cards. I think it ran on a Z-80. In the infinite wisdom of the boss, it was decided that we only needed one computer which turned out to be a Zenith Z-100 with two 8 inch floppy drives from Priority One. We ran it on CP/M, I had RCP/M set up on it so I could run it from home via the hayes, telco and my Osborne with its hayes (1200 bps - gasp). I was in Chicago at the time which was very active in hobbiest computing. I can can still remember being astonished at how may people could write assembler for USARTs off the top of their heads.

it’ll take me a couple of weeks to get on top of this, assuming, as I do, that it is possible.

thanks for your interest.


Perhaps try writing patterns to SD and time the writes, see what kind of bandwidth you can get.

file.write(buf, len)

Don't forget that until you close a DOSFAT file, the FAT does not get updated.

good idea GFS.

It just occurred to me that I should be using the single hardware serial port on the nano. I guess I was superstitious (wrongly) about not using the only port but I don';t really need it for anything else.

I'll also try your suggestion.