0
\$\begingroup\$

I am trying to connect to a Quectel GNSS device that creates a virtual COM port in windows. I have always assumed these virtual devices work like a standard RS232 port with a fixed baud, however I have observed that when I connect to this port using Hyperterminal, it does not matter what settings I have, the data still streams normally. The baud can be anything, the stop bit can be anything, nothing changes the data stream.

Maybe I have always misunderstood how Hyperterminal works, but how is this device and virtual COM port able to work, regardless of the settings.

I realize this may not be the most appropriate place for this question, however I am shooting in the dark since it could be a protocol question related to EE topics.

\$\endgroup\$

1 Answer 1

7
\$\begingroup\$

It's not about how Hyperterminal works. It's how the virtual COM ports work.

Hyperterm or any other program just opens COM port and sets the baud rate you select and does what you want with it.

But since the data does not really go through an UART but just over USB packets, there is no concept of baud rate or stop bits that applies when communicating with USB devices that look like COM ports.

So this does not relate in any way to TTL or RS-232 or even UARTs.

Virtual COM ports are virtual for this reason. They can be opened and data can be sent and received by programs that want to open COM ports. But in reality the driver that provides a non-physical COM port can do whatever it wants to send or receive data, such as send it over USB or Ethernet or patch it to another virtual COM port so you can have a virtual null modem between two Hyperterms running on same computer.

They just pass bytes, but not through via an actual UART that does have to work at some rate and use some parity and stop bit settings.

\$\endgroup\$
11
  • \$\begingroup\$ Virtual com ports can communicate with real com ports, so minimally, the tx needs to honor baud rate and data width setup. \$\endgroup\$ Commented Aug 22 at 19:08
  • 2
    \$\begingroup\$ @ScottSeidman The only case where that is true is an USB UART port. Of course the COM port driver needs to provide the methods to set the baud rate etc of the UART. But none of this is true when the other device is e.g. an USB MCU that just sends and receives data and there is no UART. And in the OPs case there is no UART. \$\endgroup\$
    – Justme
    Commented Aug 22 at 19:13
  • \$\begingroup\$ Thanks for the clarification. I suppose this leads to another question - how would one go about communicating with a device like this through programming libraries? It seems like a standard serial port library would no longer apply? Would it need to support USB? \$\endgroup\$
    – T James
    Commented Aug 22 at 19:20
  • 1
    \$\begingroup\$ @TJames if your USB device exposes itself as a virtual COM port, then in your software you treat it just like any other COM port - virtual or 'real'. Your software doesn't need to know that it's actually connected over USB. \$\endgroup\$
    – brhans
    Commented Aug 22 at 19:26
  • 1
    \$\begingroup\$ @TJames That's why it is a virtual COM port. It's a standard COM port for your programs but not really a COM port at all because it's just a more direct data pipe to your whatever device and it just skips the data being actually passing through a physical COM port. \$\endgroup\$
    – Justme
    Commented Aug 22 at 19:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.