By request of @bsancken and others on this fourm, I’ve created a UART Splitter for connecting multiple add-on devices to VESC based motor controllers.
TYPES:
There are two types currenlty in the works. The two way splitter allows 2 devices to share a single UART port of a VESC based ESC. LEDs on the back of the splitter indicate when communication is taking place on any of the 3 UART ports.
1:2 UART Splitter
.
The three way splitter allows 3 devices to share a single UART port of a VESC based ESC. LEDs on the top of the splitter indicate when communication is taking place on any of the 4 UART ports.
There is plenty more testing that needs to be performed before I start selling any but I wanted to start a thread now to share the project with you guys and get your input on a some key aspects of the final product.
The next device I will be testing with is a Firefly remote. That will exhaust all of the add-on that I own so any other devices will need to be tested by others when I begin beta testing.
Nice! I volunteer for beta testing. I recently found out that with my dual ESCapes, if I connect Metr to the master and DAVEga to the slave, it doesn’t work very well. They seem to somehow interfere with each other. I might very well make a good use of the splitter. I’m happy to pay for the tested sample and/or do the assembly if needed.
Are you properly buffering packets and responding in between devices or just split uart (same lines to two different ports) into two devices? Because if you split in two ways I am interested how everything works without collision detection
I have already worked on splitting vesc to be controlled by more than one device but I have done that on nodejs level so not much help for embedded but its doable in arduino level too you just need 3 uarts
So far I’ve only tested the most basic functionality of the Metro Pro module. The TCP/IP bridge is a great point to bring up and I will try my best to get it working as well. I don’t believe it should be too hard but we’ll see as I have no experience with it I dont have a setup to test the CAN forwarding but since that is one of the common commands in the VESC UART communication I believe it should work. That would be a good one to have a beta tester try out.
@janpom Consider your spot reserved maybe the interference issue your faced with is due to CAN forwarding. If you turn that off in the Metr app does it start working well?
@Kug3lis, I do buffer packets and act as a middle man
I am also considering making a 3 way splitter version since I would like to connect up a DAVEga, TTL system, and a Firefly remote in my board. Would enough people be interested in a three way splitter for me to make some up? The two way splitter could be stacked up to get three devices connected but then the propagation delay of messages from the furthest removed devices may cause issues.
My Ideal use case would be your proposed 3x setup with a Feather based remote instead of firefly! I’m willing to do assembly also if needed, working on another project for a car that has me doing smd level soldering. Count me in for beta testing!
Ok, I’ll make some 3 way splitters and test those out soon. What are your thoughts on the form factor of the 3 way splitter? There are a few options I can think of:
I can lay it out in a similar way to the 2 way splitter and just put 2 device connectors next to each other on one side of the board, but that would make it pretty wide and board space wouldnt be used efficiently.
I can put one connector on each end of each side. This would mean one of the devices would plug in on the same side as the ESC, possibly making it less ideal for positioning devices in a your enclosure. This option would be smaller than the first and would probably look the cleanest, but I dont think it would be the most efficient use of board space still.
I can put 3 connectors on one side of the board, but instead of placing the 2 device connectors next to each other, the connectors would be placed facing out 3 different edges of the board. This design would be pretty awkward to place inside a build since one device would plug in at 90deg for the others but it would probably be the most efficient in terms of board space.
One more thing I need people’s input on is what I should do about the fact that VESC 6 based ESCs have the TX and RX pins swapped relative to v4.12 HW based ESCs. I am going to try implementing automatic detection and configuration of these pins on the software, but in the case that I cannot, what should I do? Should I provide a dip switch that can be used to swap the TX and RX pins? Or is there another method you would like me to use that is better?
Why no just leave it as it is and then if someone has the pins reverse it just reverse them on the jst or whatever connector they use. For metr doesn’t Metter since it recognizes TX and RX automatically.
For the other question I think the solutions I see are like your 3rd one and maybe another idea is place one pin connection on the other side. So for instance the one from the vesc on one side, the flip the pcb and split it in 2 parralle UART ports.
That is definitely an option, I am just thinking of how to make it as user friendly as possible. THe dip switch option would be a little easier than swapping the pins in the JST connector, but implementing the auto detection like Metr is definitely ideal.
For the layout, I believe what you are describing is what I am doing with the 2 way splitter right now. I need to post a render of the board from fusion but, the tool has a bug and isn’t rendering the PCB correctly. I’m waiting on autodesk to fix the bug I’ll have to draw my ideas out to make them clearer.
Just out of curiosity do you think this will work with like metr and firefly remote on the same UART? I though they could not work together since both are sending and receiving info at the same time
I dont have a setup to test the CAN forwarding but since that is one of the common commands in the VESC UART communication I believe it should work. That would be a good one to have a beta tester try out.
I’ll have to draw my ideas out to make them clearer.