keithI’ve been working on the Java software the last couple days.
Trying to read from RXTX is producing only 3968 bytes per read. It looks like my USB -> serial converter uses a “transfer size” of 4096 bytes. It might be related. I’m going to lower the transfer size and see if that changes things.
If I read one byte at a time, I do get my 15238 magic number of bytes, but then the data is semi-corrupted. I’m getting a value of 0x2030 instead of a 0x89. It’s odd that I’m getting a multi-byte value for a function that is supposed to return only 0-255.
This semi-corruption that I was talking about was actually the Windows CP1252 -> unicode conversion that InputStreamReader() performs. Really ugly if you ask me. It maps characters in the range of 127 -> 160 over to some multibyte characters. I stumbled on it, and then a Bob from the RXTX maillist sort of confirmed it.
Someone else suggested DataInputStream and DataOutputStream, so I’ll check those out. I’m not sure I even need the functionality.
Right now, I’m able to transfer the whole track. I added the checksum and I’m able to receive data from the SX -> java client perfectly.
I can’t find any way to simply receive all 15238 bytes in one swoop. It seems that neither Java, RXTX, nor any other layer buffers up the data. The USB to serial device sends one “packet” of data, which happens to be 3968 bytes. And that needs to be read in before another 3968 byte packet is made available. I can’t just tell the read routine to “not return until you’ve read 15,238 bytes” There are various timeouts and threshold settings, but these have no effect on how read() performs, so they are useless.
So I just read multiple packets of 3968 bytes until I get to 15238. No big deal.
I’m measuring the performance of the transfer at 156ms including overhead, and I don’t think this is horrible. I never measured it in C++, so it could potentially be as much(if you recall, I had a decent portion of time unaccounted for.) This is double the theoretical transfer rate, but I don’t have any idea of how fast Java, rxtx, etc SHOULD be.
[…] still having the read-length problem mentioned in this post, or actually the comment on that […]