Unable receive response from serial device

[sschimmel]

I have a SIM7000 NB-IoT modem attached to a Raspberry Pi. It's connected via serial and I'm trying to control it using node.js and node-serialport.

Using screen I am able to communicate with the modem. Sending AT commands works and the response is received back and printed to the terminal.

When I issue the same command using node-serialport I do not receive an error on the .write() command however the response is not received and shown on screen.

Using screen /dev/ttyS0:

AT+CSQ
+CSQ: 30,99

OK

AT+CSQ is the command send to the modem by typing it in the terminal.

The output of the script, source below, when running DEBUG=serialport/* node index.js:

  serialport/bindings loading LinuxBinding +0ms
  serialport/stream opening path: /dev/ttyS0 +0ms
  serialport/binding-abstract open +0ms
  serialport/stream _read queueing _read for after open +38ms
  serialport/bindings/poller Creating poller +0ms
  serialport/stream opened path: /dev/ttyS0 +25ms
Port is open
  serialport/stream _write 6 bytes of data +36ms
  serialport/binding-abstract write 6 bytes +97ms
  serialport/stream _read reading +13ms
  serialport/binding-abstract read +12ms
  serialport/bindings/unixWrite Starting write 6 bytes offset 0 bytesToWrite 6 +0ms
  serialport/bindings/unixRead Starting read +0ms
  serialport/bindings/unixWrite write returned null 6 +27ms
  serialport/bindings/unixWrite wrote 6 bytes +2ms
  serialport/bindings/unixWrite Finished writing 6 bytes +2ms
  serialport/stream binding.write write finished +49ms
Message send
  serialport/bindings/unixRead waiting for readable because of code: EAGAIN +35ms
  serialport/bindings/poller Polling for "readable" +119ms
  serialport/bindings/poller received "readable" +6ms
  serialport/binding-abstract read +71ms
  serialport/bindings/unixRead Starting read +19ms
  serialport/bindings/unixRead Finished read 6 bytes +4ms
  serialport/stream binding.read finished +38ms
Data:  AT+CSQ
  serialport/stream _read reading +21ms
  serialport/binding-abstract read +35ms
  serialport/bindings/unixRead Starting read +32ms
  serialport/bindings/unixRead waiting for readable because of code: EAGAIN +4ms
  serialport/bindings/poller Polling for "readable" +51ms

The source code of index.js:

const SerialPort = require('serialport');
const port = new SerialPort('/dev/ttyS0', {
  baudRate: 9600,
  dataBits: 8,
  stopBits: 1,
  parity: 'none',
  xon: true,
  xoff: true
});

port.on('open', function () {

  console.log('Port is open');

  port.write('AT+CSQ', function(error) {
    console.log('Message send');
    if(error) console.error('Error:', error);
  });

});

port.on('data', function (data) {
  console.log('Data: ', data.toString())
});

SerialPort@^7.1.4 Node: v10.15.1 Running on Raspbian (Linux) on a RaspberryPi.

The serial port is enabled and the ssh terminal on the serial port is disabled.

I've tried connecting the modem to my Windows laptop and using Putty and that also does work. Putty settings:

I've followed the examples from the documentation and tried several solutions from Github and StackOverflow. The command seems to be echo'ed back just fine it's just the response that should follow after it that's not received.

The device works as is shown using screen and putty so I clearly must be missing something in the JS code. I just can't figure out what I'm missing so any help on this is appreciated.

[ghost]

In my case, the problem was with ModemManager, which was probing the serial port during startup and block it. I create the udev rule to specify the ModemManger should skip modem's (GPS, etc) serial port. For example, my udev rule: SUBSYSTEM=="tty", KERNEL=="ttyUSB3", ACTION=="add", ATTRS{idVendor}=="1e0e", ATTRS{idProduct}=="9001", ENV{ID_MM_PORT_IGNORE}="1"

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week no further activity occurs. Feel free continue the discussion or ask for a never-stale label to keep it open. If this is a support issue, consider sharing it on stack overflow to get more eyes on your problem.