Hello @Ricco ! Do you already have an idea of when we will have to pay for the first batch ? I filled the survey long time ago but never had any confirmation that it was taken into account
And Matt, can you, please, give us a list of the people and the quantities in the first batch so everyone can be sure all is ok for him/her/it and on a good way. Thank you !
Loving the minor changes shows how mitch thought has gone in to it. Did the 5v and 3.3v rails get protected? This might be a stupid question what would happen if a connection vibrates louse in use would it brick any thing?
Asking because just found out iv got my 2nd dead VESC due to 5v rail death.
If you filled out the survey, you were taken into account. The survey was closed at 49 requested units. I got tracking for the first batch of uSplits two days ago Estimated delivery says today, but it just left Hong Kong, so I doubt that lol Once I receive them, Iāll take a couple days to program, test, and package them. Then, I will talk to everyone who filled out the original survey to get payment and get them sent out
@Darkie02, Thanks for the support What type of protection would you like to see on the 5v and 3v3 rails? I do not believe there is any scenario where a connector vibrating loose would brick anything. The 3v3, GND, RX, and TX signals are the only signals used by the uSplit. The other signals are connected directly to the same pins of the other connectors, acting like a Y-splitter cable. What was the cause of the 5v rail deaths you experienced?
1st one was the ground of the metopro torching part of the Battry pack when I was testing a board so totally my fault.
2nd one unsure as it was a VESC 6+ Tampa told me today the 5v rail died as to why was only powering metro pro and a remote, my conser would be the fact it could be powering 3 other devises and a usplit could be overloaded unknowingly so some type of auto resetting overload protection
Donāt even know the kind of loads some of the UTAR devises pull
The vibrating lose can have VESC apply full brake on canbus and old foxboxes brick if can disconnected in use was unsure if this issue could happen on the UTAR in any way
The uSplit will come wrapped in heat shrink, so the connections will not be exposed. That takes care for the possibility of things touching it and shorting out.
To protect the 5v and 3v3 rails, I could add resetable fuses to them both. I looked yesterday for some options and a well suited fuse costs $0.88. So adding this protection to the uSplit would increase the cost by $1.75. That fuse would trip almost immediately when 1A is drawn, wont trip ever for a draw less than 500mA, and will trip increasingly faster between 500mA and 1A.
The only time the throttle would be affected by UART vibrating loose is if a remote is operating in UART only mode. I do not condone the use of UART only remotes with the uSplit. Even in that case, the ESC should timeout once the cable is disconnected and let the motor free-spin.
The first batch of assembled uSplits arrived today! Iāll be testing them, packaging them up, and contacting those who filled out the survey over the next few days
I have now reached out to everyone that filled out the first and second surveys and have shipped out most of the 50 units.
Right now I have 2 uSplits left to be sold. If you would like one, please DM me.
The price is $30 per uSplit + shipping, tax, and paypal fees
I just posted FW v0.7 to the uSplit downloads page of my site. This FW fixes a couple known bugs in the uSplit FW. Anyone that has recently purchased the uSplit should follow the instructions here to update your uSplit. If any other issues are found, PM me with details so I can start on those
is the MCU mulitplexing known vesc commands and responses between the uarts? or is it multiplexing or duplicating individual bytes. whatās the strategy to avoid mixing up incoming and outgoing messages?
I donāt want to give too much away as the FW is what makes the uSplit what it is but I will say that it handles the comms on a packet-by-packet basis, not byte-by-byte
Thanks. that answers the āWTFā¦ you canāt split UARTā question. still worried about how you keep response packets routed to the right uart idk maybe vesc packets have some kind of request response identifiers. anyhow I get if you donāt want to give too much away. was just trying to think how things might break. thanks for that info. it makes sense.
Hi @Ricco I no want I am ending up bumping a old thread for a stupid reason but was wondering if this could be used instead of adding 2 devices to 1 vesc rather 1 uart device to 2 vesc6 in order that I donāt have to use canbus
Thanks a lot
Ricco has said before remotes shouldnāt be connected to the USplit, as consistent performance canāt be guaranteed
Just make a splitter for the remote, like people do with PPM. Imo doesnāt make sense to put the same splitter you could have had beforeā¦ After additional electronics
In addition to what @Sn4Pz said, Depending on the device and the messages it is sending to the ESC, you may be able to connect the TX from the UART device to the RX of both ESCs. I have heard of this being done before.
So, one Firefly Nano UART based remote and a DAVEGA X is not recommended? Why exactly is that? My problem is that itās a single driveā¦
Because the Uart will have to juggle packets between the remote and the davega, meaning the reciever could miss an important shift in throttle position.
Alternatively, if the Uart were to choke and somehow malfunction, your remote reciever wonāt be able to communicate with the remote
Only remotes that are controlling the motor(s) over UART are not recommended with the uSplit. The Firefly Nano should provide the option between PPM+UART or UART only. In PPM+UART mode only the ESCās stats are communicated over UART which is perfectly fine to use with the uSplit. In UART only mode the throttle would be controlled through UART messages and because of the reasons @Sn4Pz stated, this should not be used with the uSplit.
Ah ok. Just out of curiosity, does the uSplit dump any packets or is it able to process everything with two uart devices (and a master) connected?
With the most recent FW update, I have been seeing the the only packets getting dropped now are either due to noise in the UART RX/TX or a device requiring priority (ex. writing motor settings through metr). This is with 3 devices (DAVEga X, Metr Pro, TTL) and the ESC connected, using a baud of 115200
That looks good! Can we also check this ourselves? I know itās not recommended but I really want to use the Firefly Nano remote with a Davega X. When so less packets are dropped (and I would be able to check it myself), Iād be pretty confident.