EasySMU and Matlab

I'm having a lot of trouble getting the EasySMU to work with Matlab. I did some manual serial debugging and compared the serial commands on the TX and RX lines when sent from MatLab (which doesn't work), and from the Arduino serial monitor (which does work). The commands are bit for bit identical, and yet the Arduino works, but Matlab does not. I did make two observations:

  1. When the Arduino serial monitor sends a write command, the SMU sends a 5 byte command back. For example, if I sent the command CH0:VOL 1, the Arduino returns the string 1.000. With Matlab, the SMU only returns the last byte of that string.
  2. I also noticed that there is a 0.5 V drop on the TX line when Matlab sends a command, but not when Arduino sends one.

I've attached the Matlab script below. Does anyone have any idea what is going on?

dev = serialport('COM30',9600);
cmd = ['CH0:VOL 1' char(13) newline];
write(dev,cmd, 'STRING');

pause(3);
delete(dev);

Top Replies

Parents
  • 0
    •  Analog Employees 
    on Jul 10, 2021 1:50 PM

    Hi AR_MacDonald,

    That is indeed strange. What Arduino are you using? Is it a Linduino (Analog Devices / Linear Technology DC2026C), an actual UNO, or something else?

    One small discrepancy I see is that you're sending a newline only, while page 10 in the demo manual says to use newline and CR. But that wouldn't explain why you're only getting one character, you'd think it would be either all or nothing.

    Not sure how to explain the 0.5V drop - Do you know if MATLAB opens and closes the serial port with each transaction? TX and RX should both be driven either high or low all the time, either by the FT232 (data from FT232 to ATMEGA) and vice versa for the other signal.

    Can you post scopeshots of what you're seeing on the bus? Are you certain that only the last byte is being transmitted, or is that just what's showing up in the buffer in MATLAB?

    -Mark

  • Hi Mark,

    I'm using the Linduino as the controller, so the shield meshes with the EasySMU perfectly.

    I'm aware that the EasySMU requires a CR and NL as a terminator. For some reason, the configureTerminator function in MatLab wasn't working, so I just manually concatenated it. char(13) gives a CR and newline gives a NL. I probed the TX line and the command from MatLab and the Arduino serial monitor is bit for bit identical.

    I'm not an expert in MatLab, but Mathematica recently updated their serial functions. The command used to be something like this:

    s = serial('COM1');
    fopen(s);
    %do stuff
    fclose(s);

    But they've deprecated that so now you just create the serial object, write, read, and then delete it. So I don't know whether the bus is opened or closed in the interim.

    I just noticed one thing: when I open the Arduino serial monitor, I notice a brief 0.5 V drop on the TX line. This is before I transfer anything.

    Here are a whole bunch of screenshots from my oscilloscope:

    This first screenshot is me sending the command with the Arduino serial monitor. The blue trace is the RX line, the green trace is the TX line, and the yellow trace is Vout. As you can see, Vout went from 0 V to 1 V.

    This is a close up of the RX using the Arduino serial monitor.

    Here is a close up of the TX using the Arduino serial monitor. Note that the TX occurs after the voltage jump.

    This is when I sent the command with MatLab. Note that there is the voltage drop at -20 ms. This voltage drop is actually from the serialport('COM30', 9600) line of code. If I put a pause after this line, the drop moved before the data transmission, but this didn't actually change the outcome.

    This is zoomed in version of the TX. Note that it is identical to the one sent with the Arduino serial monitor.

    If I used an even larger time base (500 ms) with MatLab, this is what I saw.

    These are two screenshots zoomed in on the TX line. To answer your last question, I am sure that only one character is being transmitted. In fact, that one character is a NL

    I think something about how MatLab sends the serial command just doesn't agree with the Linduino, although I have no idea what it is.

    Thank you,

    -Alexander

  • 0
    •  Analog Employees 
    on Jul 10, 2021 6:00 PM in reply to AR_MacDonald

    Okay I think I may know what's going on - The act of opening the serial port will trigger a reset via the FTDI chip's DTR# line. This is needed for the Arduino bootloader / AVRdude to work. That would also explain the 0.5V drop - when the ATMEGA is in reset, that signal will go high-impedance.

    There's a trace marked on the reverse side of the board that can be cut to disconnect DTR#. Give this a shot and see if that changes the behavior.

    Alternatively, if you can convince MATLAB to open the port, wait 1 second (an overestimate) and keep it open for the duration of your test, that might work, too.

    -Mark

Reply
  • 0
    •  Analog Employees 
    on Jul 10, 2021 6:00 PM in reply to AR_MacDonald

    Okay I think I may know what's going on - The act of opening the serial port will trigger a reset via the FTDI chip's DTR# line. This is needed for the Arduino bootloader / AVRdude to work. That would also explain the 0.5V drop - when the ATMEGA is in reset, that signal will go high-impedance.

    There's a trace marked on the reverse side of the board that can be cut to disconnect DTR#. Give this a shot and see if that changes the behavior.

    Alternatively, if you can convince MATLAB to open the port, wait 1 second (an overestimate) and keep it open for the duration of your test, that might work, too.

    -Mark

Children
  • Hi Mark,

    I cut the trace, and now my computer doesn't even recognize the device. I'll solder some headers on and close that.

    I also tried using the deprecated functions, fopen() and fclose() and the behavior was no different.

    I'm not even sure at what point in the code MatLab opens and closes the port. I would've thought that serialport() opens the port and delete() closes the port. I'm far from an expert in MatLab, and I wasn't able to find any documentation to suggest of a way to manually keep the port open.

    If I put a pause() between the serialport() and write(), there is a period between the two when the voltage is 5 V, but as soon as the write() function executes, it seems as though the board is resetting, so there is nothing I can do about that.

    I know that MatLab used to work with these boards, I just have no idea what changed. If you have any other ideas, I'd love to hear them, otherwise, thank you for your help.

  • 0
    •  Analog Employees 
    on Jul 11, 2021 2:20 PM in reply to AR_MacDonald

    Hi Alexander,

    That's very strange that the board would not be recognized - I just cut the trace on a unit here and verified that it still responded to serial commands through a terminal after cutting the trace, but attempting to upload a sketch from the Arduino IDE (as expected.) Soldering in a wire to re-connect, then uploading worked fine.

    The only other thing I can think of at the moment would be to try out something other than MATLAB - like a little Python script using pyserial, just as a reality check.

    Also, there is an Excel spreadsheet posted on the documentation page that might be worth a shot. The original author is no longer with the company, so it's basically unsupported. I've never had great luck with VisualBasic, either on its own or embedded in Excel. But again, might make a nice reality check.

    -Mark

  • The device wasn't recognized because I unplugged my USB cable to plug in my microscope to cut the trace. Oops. Now that I've plugged my USB cable back in, it is working.

    I've got some headers that will be easy enough to solder on, and I'll pick up some shunts from digikey, so we'll be able to program it.

    Thank you for your help, and as always, you help has been greatly appreciated!

  • +1
    •  Analog Employees 
    on Jul 12, 2021 6:13 PM in reply to AR_MacDonald

    Awesome, glad you're up and running. Marking this as answered, let me know if you need anything else.

    -Mark