nomadnet - ttyUSB0 - Attempting to use a port that is not open

[TheTimC]

Hi folks, I'm hoping you, or Mark, can help me. I am a newbie to all this, but my intention is to build anumber of rnodes for the local area to allow country folks to keep in contact during emergency situations. Initially, I just want to get these working so I can communicate on a closed LoRaWAN network.
I currently have three heltec LoRa 32 v2 boards, and I have successfully installed the rnode firmware on them.
I am not a great Linux user, but I am persistent enough to get by.

The issue:
When launching nomadnet, it is not connecting to the ttyUSB0 interface. At first I had access denied erros in the logs, but I resolved that by creating a dialup group, adding my user and then restarting.
Now the issue is that I get a "Attempting to use a port that is not open" error. I'll paste the log below.
All help gratefully received.
Tim.

[2024-03-29 17:19:00] [Notice] Opening serial port /dev/ttyUSB0...
[2024-03-29 17:19:02] [Error] Could not detect device for RNodeInterface[RNode LoRa Interface]
[2024-03-29 17:19:02] [Error] A serial port error occurred, the contained exception was: [Errno 9] Bad file descriptor
[2024-03-29 17:19:02] [Error] The interface RNodeInterface[RNode LoRa Interface] experienced an unrecoverable error and is now offline.
[2024-03-29 17:19:02] [Error] Reticulum will attempt to reconnect the interface periodically.
[2024-03-29 17:19:02] [Notice] Serial port /dev/ttyUSB0 is now open
[2024-03-29 17:19:02] [Error] Could not open serial port for interface RNodeInterface[RNode LoRa Interface]
[2024-03-29 17:19:02] [Error] The contained exception was: Attempting to use a port that is not open
[2024-03-29 17:19:02] [Error] Reticulum will attempt to bring up this interface periodically

[faragher]

The dialout group is a big one. Good catch.

So, firmware is set up. Does it display the UI correctly? (I think Heltec boards have displays)

Have you set these up to use Bluetooth? If they're set to use Bluetooth they disable the USB serial connection.

The errors look like it's trying to open the port, not finding the device, and the error is really that it failed to initialize.

Is this the proper port? If it's /dev/ttyUSB0, then we need to keep digging, but if you're accidentally polling a mouse or the like and the RNode is actually on, say, /dev/ttyACM0, then it's an easy fix. I like easy fixes. :D

If you're not sure what it could be called, you can use ls /dev/tty* without the RNode connected, then with it connected. The difference is the device.

There are some other test we can do to make sure the RNode is functioning, but if you've taken care of dialout, then my next steps would be checking the port name and, it's happened to me too often, making sure you have a data cable for USB, not a charging cable.

[btalbot85]

So I am a beginner coder at best. But what I found is something to do with pyserial and flow control. Maybe these 2 links will shed light on it. I am only seeing the issue with the heltech v2 which stinks because I just bought a few of them. My ttgo works fine
pyserial/pyserial#59
https://stackoverflow.com/questions/37288278/python-serial-attempting-to-use-a-port-that-is-not-open

[btalbot85]

@markqvist @TheTimC I just did further testing and can confirm this is a linux only issue. Same heltec v2 works fine with rnsd in windows. Seems to be a linux only issue and not device/firmware related. The above link mentioned the same thing but its a bit beyond my skills to solve so far. Does appear Windows handles the control lines differently. Fingers crossed its a simple fix :) I really love my linux devices lol

[btalbot85]

Sorry for all the replies @TheTimC @markqvist after more testing I have found if you set your heltec v2 rnode to tnc and make sure it exactly matches your rnode config in reticulum then start rnsd where youll see the port that is not open error looping you can then run rnodeconf /dev/ttyUSB0 -T it will fail after a few seconds with some errors (sometimes i have to hit enter at the freq setting then run it the same command again but it does work lol. You will know it did when you see reconnected serial port.) Seems to be something with the mode switch and resetting the serial port to not open, not too sure. It does seem to be my timing when I run these and the port going back to available due to this. Not sure if its fixable. I also noticed if i time the reboot button just right before it says serial port opening it does the same thing

[TheTimC]

Oh, nice, thanks. Any chance you can share the commands to run to get it working?

[btalbot85]

So its a bit timing based on linux. If you setup in Windows it works out of the box.

First run rnodeconf /dev/ttyUSB0 -T
Set everything it asks to match your reticulum config options for rnode. Youll then see your rnode switch into tnc mode.
run rnsd wait till you see the error start, it will keep looping which is what we want. Do not close
In another terminal run rnodeconf /dev/ttyUSB0 -T again and wait a few seconds for an error. Do not enter any settings, If after a few seconds you dont see an error or rnsd window does not say reconnected to serial press enter it will then error out. I seem to have best luck running this command right before you see the connecting to serial output in the rnsd window
do the rnodeconf /dev/ttyUSB0 -T again and do just like the last step all while keeping the one terminal with rnsd open and looking for the reconnect, it will connect after a few attempts
open nomadnet in another terminal (make sure you keep rnsd open in the other terminal) and enjoy

Its not pretty but it works lol. Due to it being about timing their really isn't a good way to script this.

If you need to get your rnode back into the normal mode for bluetooth or whatever else just do rnodeconf /dev/ttyUSB0 -N

[btalbot85]

I think I solved this. I noticed some weird issues with the OLED and decided to peek at the boards.h code. It shows rst pin as 23, but I found the rst pin is actually 14 by looking through pin definitions for heltec lora32 v2 on their GitHub. Swapped it out and now everything works in Linux as well. Just to confirm I went back to the original FW via the configurator and the error behavior came back. Pull request submitted with proper pin and evidence.