If I have around 10 Arduinos which need a direct connection back to a computer and will be anywhere from 10' to 75' away, what are the pros and cons of using Serial communication over USB as opposed to using an Ethernet module and UDP/TCP? I purchased one of these USB over RJ45 extenders recently (Amazon.com) and was honestly amazed at how perfectly it worked over a ~75' length of cat5, both to upload code and handle Serial communications at 115200. I know so very little about the Ethernet/networking side of things, but I'm trying to determine if the added complexity and components would be worth it for that route.
The wider context behind this question is that I own an escape room business and am wanting to try something a little different for my next room. Typically, there is a dedicated Arduino for each prop/puzzle in the room which handles its own logic for that particular puzzle. When a puzzle is solved or an event needs to be triggered, I usually have a direct connection to a different Arduino which acts accordingly. It's very decentralized and hard to keep organized, so now I would like for each Arduino to only report its input states (ie., a player pushed a button, reed switch was closed, etc.), to a central hub, most likely a Unity program, which handles all of the game logic, progression, and audio/lighting effects.
Well, you're looking to reduce the footprint of each node, not increase it, right? An RS485 adapter and a Nano, or much smaller, is a whole heck of a lot simpler than an Ethernet shield on top of a Nano(I'm guessing here, you didn't tell us what your nodes are). The size is related to complexity, and power consumption as well. For example, a Nano and Max485 board will consume a whole heck of a lot less power. Convert that Nano to a teensy, and you're doing even better.
I see Ethernet as utterly pointless for your application; Frankly, even communication could be done away with, as a series chain of open/closed switches might suffice, but I get that a communication solution is more flexible for the future.
Okay. I was leaning in that direction. My only real reason for considering one of the Ethernet protocols was that they maybe had some sort of error checking or way to guarantee a message was sent. Though I'm probably just not trusting enough of Serial and could also implement my own error correction if need be.
Though I'm probably just not trusting enough of Serial and could also implement my own error correction if need be.
No, you're right to not trust Serial; adding a bit of error correction, or at least a checksum so you can re-request data when a cycle fails, would be wise.
Now that, my friend, would be a budget decision. And, doesn't matter RS485 or Ethernet, you still need a protocol.
Me, I'm cheap. Throwing 15 bucks at every node, putting in a bigger power supply, etc. etc. just smells... dumb to me; unless each location already has Ethernet, then it's a slam dunk. But the OP's opinion is what counts.
Yeah I've read that, and experientially that does seem to be true--I've rarely, if ever, noticed a dropped char from the serial monitor. But, what exactly is handling the error correction? The USB transceiver in the Arduino? The PC com port? All of the above? Could adding the repeater/extender that I linked above potentially muddy the waters with the USB protocol to make it less reliable?
Ethernet itself has only a CRC allowing packets with errors to be discarded. Any additional error correction (like retransmitting those discarded packets) requires additional protocols (eg TCP/IP) (which could also be run over Serial, if you wanted.)
I think that the ICs used in those extenders are "dumb" and just convert the USB differential signal to a different type of differential that can drive a longer cable. So basically the USB packet is matained from he PC all the way to the USB to TTL IC on the arduino board.
See attached UICH315h_0001.pdf (123.5 KB)
Okay, so any breakdown that could happen would have to be between the TTL component and whatever the processor is, within the main microcontroller IC . Outside of that, USB error correction has everything covered?
That is correct, for the USB-Ethernet option; it's unlikely to have enough noise onboard, as long as your power is robust.
I still say this is overkill, a string of tiny nodes on an RS485 link is much simpler, cheaper, and more robust. However, information is lacking on what exactly will be happening at each node, perhaps you're doing more than a Nano/Uno can do.
But as often happens in business, it's not about the dollars, it's about keeping the customers wide-eyed while their wallets are open... A few more suckers, and any cost of implementation is trivial.
Well, turns out I am both the customer and the one that needs to implement this. And believe me, I am a sucker.
Honestly, the nodes really won't doing anything complex. Primarily sensor reading and turning relays on and off, maybe moving a servo motor here and there. At most, controlling addressable LEDs, but if that complicates things by taking up too much time for data transfer to a given node, then I would be fine having a separate device off the rs485 link dedicated to updating the lights. I think maybe I'm attracted to having a USB connection per device because of how straight-forward it is, whereas the max485 setup requires me to be more thoughtful about avoiding collisions, polling devices regularly, etc. Any tips, libraries, or tutorials you have in mind that could make help implement such a setup? I actually attempted using Nick Gamon's rolling master setup in the past but had issues with certain libraries (RFID, in that instance) being too slow. But now, if all game logic is offloaded from the nodes and I take the time to really nail down my RFID problems, I guess it could conceivably return to that.
Oh, one other minor thing. I'm unclear on whether those cheap Max485 modules work well with 3.3V, which is the logic level for all my devices in my next room (leaning towards the Pi Pico).
Ahh, now we see the hardware selection in progress. The 485 is a 5V device, so there's that. But are you designing your own boards for each location, or cobbling things together using the hobby stuff available? If the latter, I think you're out of luck. If designing your own, perhaps there are 3V equivalents - I haven't looked.
Still, sounds like we sorta need to know more to avoid going down these rabbit holes.
I will be designing a couple boards to try and cover the majority of my use cases. Up to now, I have thrown together a boatload of nightmare protoboards that are obnoxious to make, much less reproduce. But ultimately I'm leaning towards just popping a Pico into these new custom boards, unless I can work up the courage to directly install an RP2040 or other microcontroller. However, given that a Pico is $4 compared to $1 for the RP2040, I don't think I'll be producing nearly enough of these for the prices difference to matter (though this does not consider the size of the final board). So, ultimately I'd put myself pretty firmly in the hobbyist category, with aspirations for better. I'm very new to and intimidated by the process of designing boards and having them manufactured, so as much as I can offload the more complex circuitry to existing designs (Pico, for instances, or a max485 module should one already exist for 3.3v), then I'd probably just opt to add headers to my breakout board for said modules.
An MQTT Broker running on a PC or an existing server could be used as a messaging scheme and Node-RED or a program could serve as the traffic handler.
I have 13 ESP32's and a BeagleBone Black all communicating to a MQTT Broker running on a RaspberryPi. On the Pi a Python program is used as a message traffic controller. Node-Red can be used instead or writing a program.
Man, I want to like MQTT, but it has been such a headache for me. In one room, I have 12 esp devices connected over WiFi to an MQTT broker, but there are constant connectivity issues (despite placing an access point right outside the room in question), and a couple months ago, some of them just decided to stop connecting altogether. I still haven't quite nailed it down.
To be fair, MQTT itself has been fine. It's the constant connectivity issues that have had me pulling my hair out. Since I'm basically abandoning wireless altogether, I'm not really sure there are many advantages to using MQTT over Serial/Ethernet. Potentially seems like a needless extra layer of complexity. But I will do some more reading to see if it might be a good option for my needs.