I think one of his concerns was running 4wd with a mix of v4 & v6 hardware between front/back.
Any thoughts on that?
I think one of his concerns was running 4wd with a mix of v4 & v6 hardware between front/back.
Any thoughts on that?
Eggzakery!
wouldnât split ppm be a safer option?
Redundancy has been discussed before. It possible with UART RXâs and a uSplit.
Weâve talked about this before.
Yeah, and people on this forum have wildly different definitions of what redundancy is.
That is not quite the same thing as what youâre describing by adding a black-box into the mix and rx lines, all things which specifically remove redundancy from the system. To clarify, I meant spectrum offset RX/radio modules tied into a singular MCU, purpose built for it and physically placed in different locations. Think kinda how WIFI routers started beefing up throughput by running multiple simultaneous bands and now all routers look like spaceships.
Just make sure the v4 and v6 are running the same FW version and itâs 100% fine. The can protocol hasnât changed in some time though so typically even different FW is compatible.
yeah sorry mate, i kinda jump in by skipping 300+ reply.
Thanks Jeff and robot⌠forward for science!
Confusing because I used âRXâ pretty casually, my b~
So uSplit / UART RX redundancy is not a thing?
Not the way I would approach it. uSplit is also a blackbox to me and not really intended for such use. Youâd need to do custom firmware on all of the surrounding devices just to get it to work correctly.
pretty sure the usplit is not recommended for even a single receiver and anything else. itâs doing some tricky âpacketâ multiplexing to make two serial clients seem like one to the vesc.
what would be the âredundantâ layout idea? 2 recievers connected to usplit connected to 1 vesc.
in that case I think it would fail
a.). one receiver cutting out would still send different throttle levels from the other⌠they would get multiplexed together resulting in weirdness.
b.) the usplit could mess up the multiplexing or drop messages and the cost would be throttle wierdness. which is why I think he recommends not using it with remotes/receivers.
interested to know if Iâm wrong there though.
Didnât know. Oh well.
hey hey, guess what? I have an update for you all! Itâs screen recordings from an Android and Apple device showing some of the progress on the FreeSK8 Mobile application and itâs interactions with the FreeSK8 Robogotchi.
What Iâm trying to accomplish lately is making the sync process (from the board/receiver to the phone) easy to use. Working on mobile devices is challenging with limited screen space and attempting somewhat complex tasks. Have I mentioned I donât know what Iâm doing? No? Donât worry about that.
This is the current state of things but so much more is possible with time:
So this is showing how you can manage the log files on the phone, as well as the log files on the receiver? I didnt quite catch the distinction between the two, but im sure my confusion could be cleared up if I had it in hand (hint hint wink wink Andrew )
Either way, this is looking seriously good Renee!
The logfile manager function you see here is using an actual file system so it can see what is on the board flash vs what is already syncâd uploaded.
When you sync the logs are transferred from the board to your phone and cleared from the board.
The side by side is showing an Android + iPhone both working cross platform, probably easier to just watch one at a time.
Weâre finding right now the board has the ability to log far more than it needs. Hundreds of hours of ridetime.
The core concept at play though is that you simply donât need to worry about manually starting the logging process.
You turn your board on, go for a ride, turn it off, go for another ride, maybe next week you connect your app & it syncs all rides since last time you connected to it, becoming automatic/integrated instead of a manual process.