rns.recipes

Just curious if anyone else has run into this error, or if it is already a known issue. Was setting reticulum for the first time and getting the following error on every setup a tried: Could not detect device for RNodeInterface[RNode] read failed: [Errno 9] Bad file descriptor. The issue appears to be in RNodeInterface.py. Adding self.serial.dtr = False self.serial.rts = False to the end of Serial() resolved it for me. But with the github inactive, I am not even sure where to report the issue.

It could be that the port is not the right device, but that's just a guess. Can you post the [[RNode]] part of the config file? You've reported it in the right place, it's most likely a help request, not a bug.

No idea how this will format here. "[[RNode]] type = RNodeInterface interface_enabled = True port = /dev/ttyUSB0 frequency = 914875000 bandwidth = 125000 txpower = 14 spreadingfactor = 7 codingrate = 5 name = RNode selected_interface_mode = 1"" The actual error: "Could not detect device for RNodeInterface[RNode]" "A serial port error occurred: read failed: [Errno 9] Bad file descriptor" Cause as far as I can tell: rnodeconf works fine, it simply errors when rnsd tries to open the serial connection. dsrdtr=False does not seem sufficient on this board. Is that the root cause? No idea. Resolution: Edit the RNodeInterface.py file, specifically the sel.serial stanza to force dtr and rts false again after initialization. self.serial = self.pyserial.Serial( port = self.port, baudrate = self.speed, bytesize = self.databits, parity = self.pyserial.PARITY_NONE, stopbits = self.stopbits, xonxoff = False, rtscts = False, timeout = 0, inter_byte_timeout = None, write_timeout = None, dsrdtr = False, ) self.serial.dtr = False self.serial.rts = False Note the last two lines. Adding those, and rnsd initializes the rnode running on heltec v2 without issue. Reproduced on multiple computers with multiple nodes. Tested on 1.20 and 1.21. Hopefully that at least helps someone else having the same issue.

Posting with cleaned up spacing.

[[RNode]] type = RNodeInterface interface_enabled = True port = /dev/ttyUSB0 frequency = 914875000 bandwidth = 125000 txpower = 14 spreadingfactor = 7 codingrate = 5 name = RNode selected_interface_mode = 1

The actual error: "Could not detect device for RNodeInterface[RNode]" "A serial port error occurred: read failed: [Errno 9] Bad file descriptor"

Cause as far as I can tell: rnodeconf works fine, it simply errors when rnsd tries to open the serial connection. dsrdtr=False does not seem sufficient on this board. Is that the root cause? No idea.

Resolution: Edit the RNodeInterface.py file, specifically the sel.serial stanza to force dtr and rts false again after initialization.

self.serial = self.pyserial.Serial( port = self.port, baudrate = self.speed, bytesize = self.databits, parity = self.pyserial.PARITY_NONE, stopbits = self.stopbits, xonxoff = False, rtscts = False, timeout = 0, inter_byte_timeout = None, write_timeout = None, dsrdtr = False, ) self.serial.dtr = False self.serial.rts = False

Note the last two lines. Adding those, and rnsd initializes the rnode running on heltec v2 without issue. Reproduced on multiple computers with multiple nodes. Tested on 1.20 and 1.21.

Hopefully that at least helps someone else having the same issue.

OK, I found this related discussion on the GitHub repo: https://github.com/markqvist/Reticulum/discussions/481

Can you try the different suggestions offered there? While your hotfix apparently makes it work, I'm thinking there should be a way to fix this without having to change any code.

Also, what do 1.20 and 1.21 refer to?

Firstly, I apologize. I got frustrated because it felt like I was being treated like I had some expectation for help with a technical issue. All I wanted was to figure out a place to log an issue and workaround to help someone else who might run into the same issue. Poor excuse, but that's what I have. Secondly, typo. Missed a period. RNS versions 1.2.0 and 1.2.1. I read over the bug report - definitely the same bug. The first potential fix involves an issue with the pin setting for rst. That doesn't appear relevant for two reasons - one, the issue continued to be reported afterward, and two, that fix appears to have been merged two years ago. I used the latest firmware (not the community one, since it was several versions older). The second, later fix added self.detected = True, which is causing the troublesome serial initialization to be skipped. My change was slightly different, and probably less elegant, but accomplishes basically the same thing - and looks like how the stackoverflow link resolved a similar issue. The issue is also unresolved, and doesn't seem to effect other heltec devices. I did check diffs on that file, but I didn't expect it to be a two year old issue, so I didn't go back that far. The only other troubleshooting step is the device, but this board definitely mounts at /dev/ttyUSB0. And I am aware of the device ownership and have the correct group set. If these were the issue the device wouldn't work after tweaking the python file. I have a heltec v3 laying around somewhere, so if it of any use, I can test that. But it sounds very much like this issue is specific to this v2 board. It seems to have a reputation. I just know it was popular online for a long time, so I figured someone else would be running it, hitting the same issue, and could use the information.

I appreciate the apology, we definitely got off on the wrong foot.

I use v2 Heltecs myself without any problems, as many people do. They do have a reputation, but this doesn't seem to be a common issue. I don't know enough about this to be able to draw any conclusions from the hotfix working. But if it does, that's great, and thanks for sharing it for others to find!

Hmm...I can definite reproduce across several kernels and multiple devices - however I purchased said devices around the same time. So, maybe it is related to specific variations of the v2. That combined with this is only an issue on Linux, may explain why it doesn't impact more people. You are right, probably not truly a bug, more like a hardware quirk. If anyone else runs into it and interested in a workaround, I created a custom docker build that patches the issue automatically when a new version of RNS is pulled.