Dude… 
2 Likes
Yes 
It’s too early for accurate feedback but the test welds are strong AF. The welding current is 1300A with nano-tech 3s 5Ah 65c-130C lipo. It’s well made and the tips are huge compared to some other welders. I’ll let you know how it performed after welding the first 12s6p. For now you can take a look at pics from test welding
3 Likes
https://www.electric-skateboard.builders/t/no-words-just-pictures-delete-words-2/88821/1118?u=janpom
That’s awesome! We need details. How does it work? How can we get one?
1 Like
@janpom, Thanks Basically, you just plug the splitter into the ESC, plug 2 other devices into the splitter, and voila, they can communicate without issue 
I’ll be making a post about it very soon. I’m going to make one more PCB rev, then get some beta testers to try it out, and after all bugs are fixed I’ll start selling them.
12 Likes
Great stuff. Looking forward to more developments.
I’m curious how the synchronization work. It seems non-trivial. Given the setup with DAVEga, Metr, and VESC, if DAVEga and Metr both send a request at the same time, will the splitter first relay one request and hold back the other one until it receives a response from the VESC, and only then it relays the other request? Or is it somehow more clever than that?
3 Likes
Im glad you’re so curious about how exactly it works, but atm I dont want to give away too much of the secret sauce 
It kills me not to explain how every part works since I put alot of time into getting it working perfectly, but for that reason too I’m going to keep the details of the firmware to myself. I will say though, that you are close in your guess but it is a little more clever 
3 Likes
I see no dildo on that helmet
4 Likes
That is pretty fucking cool
1 Like
Wouldn’t it work to make the DAVE read only by just connecting the RX and GND? So Metr works like it is the only device and sends the getValue request, DAVE reads (by UART interrupt) whenever the ESC answers?!
https://www.electric-skateboard.builders/t/no-words-just-pictures-delete-words-2/88821/1132?u=karamq
How fun was that, now all you have to do is attach a lawn chair to that thing just like @Boardnamics did
1 Like
@Grozniy I didn’t say I was riding fast on them, first ride down this track this year, still trying to find a line I don’t ground on lol
EDIT: I’m actually contemplating moving the battery up top and get myself load of clearance
7 Likes
Zie dat je niet in het water rijdt eh…
1 Like
Haha jot… En anders verkoop je m toch maar gewoon weer eh…
1 Like
until it also breaks like you evolve… & then you sell it on “Marktplaats” like a good board without any damage. Is your board already sold?
And why are you using a fake name? You are the guy that spam Facebook group with how awesome your DIY board is and how easy it is to build. But you can’t drill 4 holes in your deck.
5 Likes
Don’t forget about the scamming part 
3 Likes
If I were to guess, he is maintaining a mirror copy of all variables and paramters on the splitter by sending requests to VESC at regular interval. When either metr pro or DAVEga needs them, the splitter sends them that information.
When a device sends write command it forwards it to VESC, updates the splitter copy of parameters/variables and sends a suitable response back to the device.
2 Likes
Yeah, something like that would make sense. It’s obviously not possible to make a generic UART splitter that would work with any 3 devices so I guess it’s tailored to be used with the VESC.
I wonder how well it works with Metr’s TCP/IP bridging. That one allows some advanced stuff, including updating the VESC FW. I’m not sure how exactly that’s communicated to the VESC. I imagine that it could involve sending multiple messages. If the other device (DAVEga) jumps in while that’s in progress, that could very well brick the VESC.
@Ricco Is this something you have considered in the design? Will the splitter be safe to use for writing into the VESC?
1 Like
Perhaps there’s the implementation of priority read/write, where in the theoretical situation that you provided, the splitter would prioritise the signals from one of the UART device (the metr), and as such would prevent bricking?
1 Like
I’m just theorizing here. I don’t know the details of the VESC communication protocol. I only use a few of the read commands. I imagine a scenario like this can be problematic:
1
METR -> VESC: write X1
VESC -> METR: ack write X1
2
METR -> VESC: write X2
VESC -> METR: ack write X2
3
DAVEGA -> VESC: read Y
VESC -> DAVEGA: Y value
IMO, the splitter has no chance to do the synchronization such that the following cannot happen instead:
1
METR -> VESC: write X1
VESC -> METR: ack write X1
2
DAVEGA -> VESC: read Y
VESC -> DAVEGA: Y value
3
METR -> VESC: write X2
VESC -> METR: ack write X2
Unless the splitter understands all the details of the communication protocol, it wouldn’t know that after the write X1 the write X2 will follow, so it wouldn’t know that it should delay the interleaving DAVEGA read request.
2 Likes