Node-serialport: Example of using bindingOptions re: Power Limits

[vicatcu]

• __SerialPort Version__: 6.0.0
• __NodeJS Version__: 7.4.0

• __Operating System__ and __Hardware Platform__: Windows / PC

• Have you checked the right __version__ of the __api docs?__: Yes

• Are you having trouble installing and you checked the __Installation Special Cases__ docs? Yes
• Are you using __Electron__ and have you checked the _Electron Docs_?: Yes

Summary of Problem

When I connect my product to USB and open it with any serial program, e.g. Arduino Serial Monitor, it works as I would expect. When I open the port with node-serialport, I see signs that the product is not receiving enough power over USB (i.e. failure to properly initialize power-hungry subsystems is reported). I haven't confirmed this yet, but I think this is a Windows-only issue. Seems to me like I shouldn't see different behavior between a terminal program and node-serialport in this respect, though.

Steps and Code to Reproduce the Issue

I was perusing the docs and I saw there is a bindingOptions property you can pass through the options hash in the constructor, but I haven't found much (any) information on what / how you can use that. I have a sneaking suspicion, however, that perhaps something needs to tell Windows to provide the maximum power (500mA) explicitly, or else it will degrade the current limit to something less (e.g. 100mA). I would love to see an example of how to do that, if possible.

[reconbot]

I don't think that's a thing but here's a link to the windows function we
use to open the port. Happy to add any bindings options needed to make it
work.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx

---

Francis Gulotta
[email protected]

On Tue, Oct 10, 2017 at 1:06 PM, Victor Aprea [e-mail]
wrote:

>

-

SerialPort Version: 6.0.0
-

NodeJS Version: 7.4.0
-

Operating System and Hardware Platform: Windows / PC
-

Have you checked the right version of the api docs?: Yes
-

Are you having trouble installing and you checked the Installation
Special Cases docs? Yes
-

Are you using Electron and have you checked the Electron Docs?: Yes

Summary of Problem

When I connect my product to USB and open it with any serial program, e.g.
Arduino Serial Monitor, it works as I would expect. When I open the port
with node-serialport, I see signs that the product is not receiving enough
power over USB (i.e. failure to properly initialize power-hungry subsystems
is reported). I haven't confirmed this yet, but I think this is a
Windows-only issue. Seems to me like I shouldn't see different behavior
between a terminal program and node-serialport in this respect, though.
Steps and Code to Reproduce the Issue

I was perusing the docs and I saw there is a bindingOptions property you
can pass through the options hash in the constructor, but I haven't found
much (any) information on what / how you can use that. I have a sneaking
suspicion, however, that perhaps something needs to tell Windows to provide
the maximum power (500mA) explicitly, or else it will degrade the current
limit to something less (e.g. 100mA). I would love to see an example of how
to do that, if possible.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/EmergingTechnologyAdvisors/node-serialport/issues/1358,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABlbmsSiZZJHSazRJPNqmplVw3_la6cks5sq6QZgaJpZM4P0ROY
.

[reconbot]

I'm going to close this for now, but if you find a way please share and we'll make it happen.

[vicatcu]

@reconbot I think this should be re-opened, it's definitely a thing in 6.0.4 even.

The following minimal script exhibits the problem:

var SerialPort = require('serialport');
var port = new SerialPort('COM5', {
  baudRate: 115200
}, function (err) {
  if (err) {
    return console.log('Error: ', err.message);
  }

  const Regex = SerialPort.parsers.Regex;
  const parser = port.pipe(new Regex({ regex: /[\r\n]+/ }));
  let line = 1;
  parser.on('data', (data) => {
    console.log(`${line++}: ${data.toString()}`);
  });
});

In all that follows, the line to focus on as problematic is Info: ESP8266 Initialization...Failed. The only reason I can come up with for why node-serialport in Windows behaves differently with my hardware is that something is different about how the port is opened by node-serialport.

If I run the above script in Windows the script outputs the following:

1:  +------------------------------------+
2:  |   Welcome to Air Quality Egg 2.0   |
3:  |   CO2 / Particulate Sensor Suite   |
4:  |       Firmware Version 2.2.2       |
5:  +------------------------------------+
6:  Compiled on: Oct 25 2017 16:39:47
7:  Egg Serial Number: egg00802e6305980122
8: Info: Tiny Watchdog Initialization...OK.
9: Info: Slot Select Pins Initialization...OK.
10: Info: SPI Flash Initialization...OK.
11: Info: Current firmware signature: 310547 40166
12: Info: SHT25 Initialization...OK.
13: Info: BMP280 Initialization...OK.
14: Info: RTC Initialization...Fail.
15: Info: SD Card Initialization...Fail.
16: Info: ESP8266 Initialization...Failed.

If I run that same exact script (except point it at /dev/ttyUSB0) in Ubuntu I get the following output:

1:  +------------------------------------+
2:  |   Welcome to Air Quality Egg 2.0   |
3:  |   CO2 / Particulate Sensor Suite   |
4:  |       Firmware Version 2.2.2       |
5:  +------------------------------------+
6:  Compiled on: Oct 25 2017 16:39:47
7:  Egg Serial Number: egg00802e6305980122
8: Info: Tiny Watchdog Initialization...OK.
9: Info: Slot Select Pins Initialization...OK.
10: Info: SPI Flash Initialization...OK.
11: Info: Current firmware signature: 310547 40166
12: Info: SHT25 Initialization...OK.
13: Info: BMP280 Initialization...OK.
14: Info: RTC Initialization...Fail.
15: Info: SD Card Initialization...Fail.
16: Info: ESP8266 Initialization...OK.

It's also not a general issue with my hardware in Windows. if I use Arduino's Serial Monitor in Windows I get the following output:

1:  +------------------------------------+
2:  |   Welcome to Air Quality Egg 2.0   |
3:  |   CO2 / Particulate Sensor Suite   |
4:  |       Firmware Version 2.2.2       |
5:  +------------------------------------+
6:  Compiled on: Oct 25 2017 16:39:47
7:  Egg Serial Number: egg00802e6305980122
8: Info: Tiny Watchdog Initialization...OK.
9: Info: Slot Select Pins Initialization...OK.
10: Info: SPI Flash Initialization...OK.
11: Info: Current firmware signature: 310547 40166
12: Info: SHT25 Initialization...OK.
13: Info: BMP280 Initialization...OK.
14: Info: RTC Initialization...Fail.
15: Info: SD Card Initialization...Fail.
16: Info: ESP8266 Initialization...OK.

I can't think of a way to identify this as a problem outside the scope of node-serialport, so I would respectfully request that the issue be re-opened. This is using an FTDI FT231X USB-Serial chip, so maybe something about how node-serialport interacts with the FTDI driver?

[vicatcu]

For giggles, I just wrote an equivalent script in Python with PySerial:

import serial
import sys
ser = serial.Serial('COM5', 115200)  # open serial port
line = 1
while(1):
  serial_line = ser.readline().strip()
  print serial_line
  sys.stdout.flush()

ser.close()             # close port

... and sure enough no problems, here's the output:

|   Welcome to Air Quality Egg 2.0   |
|   CO2 / Particulate Sensor Suite   |
|       Firmware Version 2.2.2       |
+------------------------------------+
Compiled on: Oct 25 2017 16:39:47
Egg Serial Number: egg00802e6305980122

Info: Tiny Watchdog Initialization...OK.
Info: Slot Select Pins Initialization...OK.
Info: SPI Flash Initialization...OK.
Info: Current firmware signature: 310547 40166
Info: SHT25 Initialization...OK.
Info: BMP280 Initialization...OK.
Info: RTC Initialization...Fail.
Info: SD Card Initialization...Fail.
Info: ESP8266 Initialization...OK.

[vicatcu]

For even more lulz, I rewrote the node script for [email protected] and it doesn't exhibit the problem:

var SerialPort = require('serialport');
var port = new SerialPort('COM5', {
  baudRate: 115200,
  parser: SerialPort.parsers.readline('\r')
}, function (err) {
  if (err) {
    return console.log('Error: ', err.message);
  }

  let line = 1;
  port.on('data', (data) => {
    console.log(`${line++}: ${data.toString().trim()}`);
  });
});

... and the output is:

1: +------------------------------------+
2: |   Welcome to Air Quality Egg 2.0   |
3: |   CO2 / Particulate Sensor Suite   |
4: |       Firmware Version 2.2.2       |
5: +------------------------------------+
6: Compiled on: Oct 25 2017 16:39:47
7: Egg Serial Number: egg00802e6305980122
8:
9: Info: Tiny Watchdog Initialization...OK.
10: Info: Slot Select Pins Initialization...OK.
11: Info: SPI Flash Initialization...OK.
12: Info: Current firmware signature: 310547 40166
13: Info: SHT25 Initialization...OK.
14: Info: BMP280 Initialization...OK.
15: Info: RTC Initialization...Fail.
16: Info: SD Card Initialization...Fail.
17: Info: ESP8266 Initialization...OK.

[reconbot]

Keep digging I'm sure there's a real reason in there. I wonder if there's a program like strace for windows?

There is! https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

[vicatcu]

@reconbot OK, I used drstrace and captured traces of the above scripts running (pyserial, [email protected], and [email protected]). I have attached those trace logs to this comment.

drstrace.nodeserial4.0.7.log
drstrace.nodeserial6.0.4.log
drstrace.pyserial.log

I'm a bit out of my depth in understanding the contents of these traces. I surmise that one of the NtCreateFile calls is the thing to look for, but there are hundreds of occurrences of NtCreateFile in each of these. I don't know what I'm looking for :-/ ... any pointers? Hopefully someone with more experience in Windows driver development / debugging can jump in an help here?

[frank-dspeed]

@vicatcu i don't know whats wrong with your code but its not FTDI i am heavy FTDI device user and serialport don't uses the ftdi package from node

[reconbot]

On windows the serialport device is provided by the driver, can't even see it without having the driver loaded and it's the driver backed device that provides the communication to the chipset.

[vicatcu]

FYI I posted a question referencing this issue to StackOverflow. Upvotes are welcome. If I don't get any traction, I'll put it up for a bounty when it's eligible.

[vicatcu]

FYI, I have opened a 250 rep bounty on the Stack Overflow question.

[vicatcu]

@reconbot would it be useful to try every point release between 4.0.7 and 6.0.4 to find out exactly when this started happening? Where can I get a list of those point releases? Realizing I may have to tweak the minimal script slightly along the way... From the releases section of github, it looks like: v4.0.7, v5.0.0-beta3, v5.0.0-beta4, v5.0.0-beta5, v5.0.0-beta6, v5.0.0-beta7, v5.0.0-beta8, v5.0.0-beta9, v5.0.0, v5.1.0-beta5, v6.0.0-beta1, v6.0.0-beta2, v6.0.0-beta3, v6.0.0, v6.0.3, v6.0.4

[frank-dspeed]

@vicatcu you can see all the changes you should hire some one familar with git repos he can then show you the so called diff between the releases but there has nothing changed i checked that already

[reconbot]

@frank-dspeed your comment sounds a little rude. I don't think that was your intention but please be mindful of how you communicate.

@vicatcu that would be interesting. I'd compare the latest v4 vs v5 vs v6 first. As Frank mentioned there's nothing in the open code that has changed so identifying what did change might It would be helping to see if there is anything serialport can do.

[frank-dspeed]

@reconbot no i am not rude i think its clear communication it helps him most if he gets clear infos not make hope where is none i pointed in the stackoverflow question also to the Microsoft Information about that.

In it is pointed out that the windows driver controls its power by its flow so the change to the streaming api is probally causing this diffrent behavier.

he needs to contact the hardware vendor for the right behavier for his hardware.

[vicatcu]

@frank-dspeed no worries, I'm not offended... I am a more than capable and experienced developer, plenty of github experience too. I am happy to contact FTDI, but I need to know enough to clearly communicate with them technically. I'm dubious that the solution to this problem will come from them, but I'm open to the possibility. I'm just trying to be respectful of everyone's time and energy.

[frank-dspeed]

@vicatcu ask them about how the ftdi driver manages power then we can tell you how to do that with serialport

[vicatcu]

OK guys, what if I'm on the wrong track entirely in thinking this a power related issue. What if it is something to do with the flow control signals... does that ring any bells between v4.x and v6.x. I'm entertaining this possibility because if node-serialport v6.0.4, in Windows, is causing the FT231X to leave the DTR and RTS signals in opposing states (HIGH/LOW or LOW/HIGH), that would cause my hardware to either hold the ESP8266 in reset or put it into bootloader mode, neither of which are desirable states for my purposes. I'll have to get the scope / multimeter out to verify. Will report back, but wanted to see if this rang a bell for anyone.

[vicatcu]

@frank-dspeed @reconbot Eureka, that's it! In Windows, using node-serialport 6.0.4, the RTS signal is reading 3.3V and the DTR signal is reading 0V. No other operating system / programming language environment I've encountered has this resting condition for the flow control signals. So (1) I clearly need to change the title of this issue, and (2) what's the recommended way to get node-serialport 6.0.4 to set the flow control lines both low after opening the port?

The 6.0.4 docs for baseBinding.update([options]) ⇒ Promise seem to suggest that [options.dtr] = [options.rts] = true. I take that to mean, if I don't bother calling baseBinding.update, those are the settings, but this appears to not be coherent with my measured reality in Windows. Looks like maybe I need to do?:

serialPort.set({dtr: true, rts: true}, (err) => {
   if(err) console.error(err)
   else console.log('flow control signals asserted');
});

I can say with certainty that altering my test program for 6.0.4 as follows solves my problem:

var SerialPort = require('serialport');
var port = new SerialPort('COM5', {
  baudRate: 115200
}, function (err) {
  if (err) {
    return console.log('Error: ', err.message);
  }

  port.set({dtr: true, rts: true});  // this is the only line I added.

  const Regex = SerialPort.parsers.Regex;
  const parser = port.pipe(new Regex({ regex: /[\r\n]+/ }));
  let line = 1;
  parser.on('data', (data) => {
    console.log(`${line++}: ${data.toString()}`);
  });
});

I'll leave it to you guys to decide if this is a bug or not. It's a strong "maybe" from me :-)

[frank-dspeed]

@vicatcu simply if you got it running give us a example then we maybe also understand what you mean you need to understand we are only coding bindings :) we are only humans :) but sounds like the guy on stackoverflow got the right point and that it has something to do with flow is logical as i try to tell you thats all we changed now it is a stream :)

and you code example looks valid

[vicatcu]

@frank-dspeed not sure you saw my edit, but I posted the updated working example for node 6.0.4. Basically hardware flow control signal behavior differs between node-serialport 6.0.4 and 4.0.7. If I force the state of the DTR and RTS signals on open, my hardware is happy in 6.0.4.

[frank-dspeed]

@vicatcu then we can close this hurray :+1:

[vicatcu]

Closing this and opening https://github.com/node-serialport/node-serialport/issues/1399

[reconbot]

Glad you got this sorted!