pyserial comports() outputting only /dev/cu.* , not /dev/tty.* on Mac

[simon3789]

I downloaded the application on my M1Pro MacBook Pro today, everything worked, except the NTRIP client. (it showed connected but my receiver got no rtcm-stream)

I had a look around and found, that the port selector only offered /dev/cu.* Ports, no tty.

It looks like the cu ports only work "one-way" so the Ntrip client simply wasn't able to push the correction stream to the receiver.

I then confirmed my supposition by running

python -m serial.tools.list_ports -v

in the Terminal and I only got back:

/dev/cu.Bluetooth-Incoming-Port desc: n/a hwid: n/a /dev/cu.usbmodem3301 desc: u-blox GNSS receiver hwid: USB VID:PID=1546:01A9 LOCATION=3-3 2 ports found

As a simple fix I just edited serialconfig_frame.py in lines 262, 265 and 270 to replace "cu" by "tty"

I simply replaced the port calls in these lines by port.replace("cu", "tty").

After that, the Ntrip Client is working.

I don't know how to fix this the proper way, but you should have a look at this.

Thanks for this awesome application anyway.

[semuadmin]

Hi @simon3789

As you've seen, PyGPSClient uses the standard serial library for its serial comms, and there's no hard coding or filtering for specific port designators (e.g. cu or tty). The use of cu or tty port designators is device and operating system dependent - as I understand it, tty is conventionally used for non-exclusive incoming textual comms while cu (calling unit) is for exclusive bidirectional binary comms. In the context of an application like PyGPSClient, which expects exclusive use of the GNSS device's serial port to send or receive binary data, cu would ordinarily be the one to use. There's a more detailed explanation here:
https://stackoverflow.com/questions/8632586/macos-whats-the-difference-between-dev-tty-and-dev-cu

If you think the serial.tools.list_ports.comports() method is missing certain valid port designators for your connected device, this issue really needs to be raised against the serial library (if it hasn't already been) rather than this one. PyGPSClient simply invokes the method and I have absolutely no control over its functionality. I will, however, have another look at the serial API documentation and existing Issues log to see if it's a known issue.

Out of interest, what specific device type and serial port type (i.e. USB, UART1, UART2) are you using? I've tested on various Macs (including M1 but admittedly not M1Pro) using many different u-blox GNSS devices and I've not come across this particular issue before. Are you able to test this on an Intel-based Mac to see if you get the same behaviour?

One last point - is it possible that other processes are running on your Mac that might be contesting the same serial port?

[simon3789]

Hi @semuadmin

Thanks for your quick reply!

You are right, I should definitely report this to the serial library.
Yes, I have access to an intel based Mac and I am going to test further with that machine.

I am using an Ardusimple SimpleRTK2B Pro (which is basically a u-blox F9P) connected via USB.
As I said, I can see the tty port with ls /dev or using the Arduino IDE, it's only missing using comports()

Even the tty-Port for the Bluetooth-Incoming-Port is missing, so I guess its not a blocked port.
Btw, I am able to connect to that port using other applications, so it can't be blocked, right?

[semuadmin]

Hi @simon3789

I don't have an M1 Mac to hand at the moment, but I just double checked on an Intel Mac using the same Ardusimple F9P board. The USB port is listed as /dev/cu.usbmodem142101 (i.e. not tty) but I can successfully connect to an NTRIP caster and receive RXM-RTCM messages from the F9P confirming that it is receiving and accepting the NTRIP messages (msgused=2), so it's not clear that this is specifically a cu vs tty issue necessarily. I suspect this may be a red herring, though I can't account for why your workaround appears to resolve the problem???

At the end of the day, I'm happy to consider adding a 'replace cu with tty' option on the drop-down serial configuration panel as an accessible workaround, but I'd ideally like to understand the cause of the issue first. I suspect this is an M1 thing.

[semuadmin]

Closing for now but happy to consider future functionality in this area if it proves to be a common problem.