I've scoured the internet for hours trying to figure this out, and I keep seem to find an answer. According the SCPI reference manual, you can specify a file name via MMEM:DOWN:FNAM, and then write to that file using the command MMEM:DOWN:DATA <binary_block>. The example given in the manual is #15Hello. My question is, how is the number 15 calculated? How about some other examples, such as the following:
Thanks, that clears up that particular question about the formatting.
Let's say that I have a text file with multiple lines. How do I indicate a carriage return to the instrument, and what are my limits to this transmission method? For instance, I've got an ARB file that looks like this:
Sample Rate:50000000.000000 High Level:0.300000 Low Level:-0.300000 Data Type:"short" Data: 32767 32330 31893 etc.
I can read this off of the USB drive and it does what I want it to. However, I need to be able to do this over the LAN from telnet.
--> However, I need to be able to do this over the LAN from telnet.
Are you trying to interactively do this with a telnet client, or are you writing an app to send the data? If you are writing an app, don't use the telnet port 5024, use the Raw SCPI Socket port of 5025 or use VXI-11. I'm not sure this approach would work correctly with an interactive telnet client (line endings might cause problems, and it seems like it would be really tedious to manually type in an arb file).
I'm not sure what the line ending are in this case, but they are usually \n (0x0a), \r (0x0d), or \r\n (0x0d0a). You could open one of the default arb files in a hex editor and see what the line endings are?
This will save the builtin waveform SINC.arb on my PC as purlpe.arb. Notice option -q on the netcat (nc) command. If you don't specify a timeout, netcat closes the connection immediately and you will never receive the file.
Since this isn't a proper .arb file (it has the binary block header prepended to it still, you can send it back to the instrument using something like:
Ok, I think the key point in all this that I was missing is what needs to be in the file that gets sent to the instrument. The binary block header needs to be in there, as I had ascertained, but the line endings are DOS-flavored (\r\n, in Unix parlance, ^M) and the line:
comes from the instrument as:
#Data Type:\"short\"\r\n (again, in Unix parlance, ~Tshort~T^M)
IOW, it's the ANSI ", not the ASCII ". I think that's what's been causing this errors. I'll go back and make sure that's the case.