By adding some rules to the /etc/udev/rules.d directory, you can force Linux to always use the same
USB serial device which you can refer to by a more meaningful name.
e.g. You have 2 USB-to-RS485 adapters. One is FTDI based, the other CH340 based.
You want to use them both on the same Raspberry Pi to read two modbus instruments.
The problem is sometimes the OS enumerates the adapters in opposite order. i.e. what was /dev/ttyUSB0 at last boot time is now /dev/ttyUSB1 and vice-versa.
Adding a udev rule for each device, enables referring to the device by a name like /dev/FTDI or /dev/CH340 as well as ensuring each name refers to the same USB device every time.
If you have FTDI based adapters you can often edit the device id’s and utilize that in the udev rules too, so for example if you have multiple devices the same (FTDI based) they are given both a recognizable prefix and a unique ref that doesn’t change regardless of connection order etc.
pi@emonBase24(ro):~$ ls -la /dev/emonTX*
lrwxrwxrwx 1 root root 7 Dec 5 2017 /dev/emonTX-N1110RBF -> ttyUSB2
lrwxrwxrwx 1 root root 7 Dec 5 2017 /dev/emonTX-N212X7O2 -> ttyUSB1
lrwxrwxrwx 1 root root 7 Dec 5 2017 /dev/emonTX-N3Z3VPD -> ttyUSB0
there is a free windows “FT_PROG” utility available from FTDI to edit the ID (and other stuff) (Utilities - FTDI)
[EDIT]
Interesting choice to name your FTDI device “CH340” and the other one “FTDI”, that might prove confusing at some point down the line.
Here’s the vendor:product id’s of the above mentioned 3 FTDI emonTx’s
pi@emonBase24(ro):~$ lsusb
Bus 001 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
notice the vendor:product id’s are the same for the your FTDI usb~rs485 and my FTDI usb~serial programmer.
and here’s one of those cheap rs485 usb adapters on a local Pi (top of the list)
pi@raspberrypi:~ $ lsusb
Bus 001 Device 004: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 005: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
the second one down is an old style (full USBA) OEM shop bought programmer.
I know I’m dragging up an old post here, but… I’m looking to connect 3 emonTx’s to an emonPi over a more reliable method.
Currently they are posting using the Rfm2Pi which has issues with conflicting radio transmissions over time, despite the various attempts to stagger the transmissions. It’s just not bullet proof enough.
I’ve also got 1 emonTx elsewhere on an ESP8266 which is not reliable in maintaining it’s connection to the Wifi despite there being plenty of coverage.
Anyway, I’m not looking to discuss the above, but move to something reliable. I beleive I was pointed towards direct serial connection previously, so here I am.
Reading through a few threads that are discussed on here, with regards to adding the nodeid to the interfacer output and changes to emonhub as well as the longer discussions about the wider issues of keeping compatibility with the different output formats for ESP8266 etc.
So I’m looking for the simplest way forward and from what Im reading here, these programmable vendor id FTDI USB to Serial devices would still be the best option here? Or is there something more current in terms of sketch’s / emonhub updates etc that I’m missing?
I’ve had a quick look on Amazon and identified the following possible candidate USB > Serial cables, would these be ideal?
What measures have you tried to get them more stable? What’s the symptom of your RF problem.
Is there anything unusual about your RF setup - big distances? Thick walls? Metal walls? Insulated walls with alumuniun foil bnded to the insulation to reduce radiant heat?..
As he hasn’t come back, I expect he’s happy - or given up.
The latest rfmTxLib can ‘sniff’ the band before transmitting. It’s not completely foolproof, because if the competing transmitters don’t do the same, or dive in between the first one deciding the band is free and turning around to transmit, there’s still a collision. But I did find an improvement, with fewer missing values.
(emonTHs don’t check first - it costs in battery life and they only transmit once a minute anyway.)
Indeed, and I think that’s mentioned in the documentation.
[Edit]
And it is: “…a signal above the threshold is detected at the transmitter, it does not necessarily indicate conditions at the receiver.”
The documentation also points out “Refer to JeeLib documentation for more information about the usage of the network group. Specifically, all groups use the same radio band, therefore although receivers ignore traffic in a different group, mutual interference might still occur.”
Nothing to make them more stable per se (over rFM). I have 3 emonTX’s in close proximity to each other, one per phase next to where the power comes into the property in a workshop attached to the side of the garage. The other side of the single skin brick wall of the garage, maybe 10 feet away is where the pi is located.
On my data collection I would see random periods where one of the emonTX unit’s data feeds are all dropped collectively, suggesting that this particular unit cannot communicate. This was also verified in the emonCMS tool looking at the inputs screen and seeing the delays on the input updates in many minutes rather than within 10 seconds as they are usually.
Resolution was to move them all to USB serial and put the Pi in the workshop with them once I’d run an ethernet cable to that location.
and also on the guide somewhere, but search function on the guide pages is as much use as a chocolate fireguard!