So the analogy is
Mini is much like the old car esc with a program card and the OSSR is like the vesc with its lovely interface and options and options.
So the analogy is
Mini is much like the old car esc with a program card and the OSSR is like the vesc with its lovely interface and options and options.
That’s actually a very apt analogy.
The OSRR 1.0 is programmed/configured very similarly to a VESC, with a number of configuration settings available.
Love it then. Expect some I want it now shit in the new year. Thanks for the splain.
By this definition, couldn’t it be argued that the Mini isn’t
actually intended for dual receivers? Just because it can be used incorrectly/alternatively doesn’t mean that was the design intent.
You must purchase a separate receiver and then pair the transmitter to both, which is outside of the intended operation of the device. The mini doesn’t come with 2 receivers and instructions to pair it with both, does it?
I’d consider that a ‘hack’, so by the definition you’re proposing perhaps the mini doesn’t properly support dual receivers either.
Thoughts?
Pointless argument.
What matters is that you’ve let people know that if they must have dual / multiple receivers, your OSSR remote can support that. You’ve defended your creation, now let the trolls be trolls, and don’t become one yourself
You’re 100% entitled to your opinion!
Thanks for chiming in.
Really, when a question is asked, answers are submitted, and then the goalposts are moved because the answers given aren’t preferred:
It’s fair to ask the question on previously submitted answers, as well as point out that goalpost moving is poor form in any debate.
Also I’m not sure if you picked this up, but I enjoy the debate, its a topic I’m perfectly comfortable discussing. Sorry you find it pointless.
Hey buddy, what is that you’ve got going on there?
Can you please do two Rx on one board, then turn off one Rx while applying throttle? That’s the use case I’m interested in, two Rx giving signal to both ESC at the same time, or with failover handling.
This coming Thursday is the only day I have free to check. But yes. I will for sure.
Thanks mate, if it can do that properly it’ll be awesome!
What is your expectation of what will happen?
(I’ve actually done exactly this in testing)
My guess would be the system remains unaffected due to actual receiver redundancy. What actually happened?
Once the time-out period elapses, the disconnected ESC spins down. This would have varying impact on a rider depending on environment, inertia, board setup.
PS: @Zach @BillGordon could we please have the title reverted back to the original? I was told removal of the serious tag + changing titles to obfuscate the discussion at hand was a big no-no. Would be nice if we all played by the same rules.
You said the Rx’s are networkable, so hot failover would be my expectation of the capability (and also my hope).
The limitation there isn’t in the radios. The VESC itself isn’t going to switch between direct UART master & canbus slave as a hot failover.
Does that make sense? I can expand if needed
I concur. Stop being fucking babies and put not only the original title back, but also the original post with @b264’s latest edits. FFS it’s an SRO topic.
I’m not familiar with CANBUS/UART, but does the VESC need to know?
Let me explain:
Setup 1:
Dual ESCs connected via canbus. The slave ESC has its ‘app’ (aka its control input) set to take throttle commands sent from the master over can. You can’t use two receivers in this setup, because the can-slave input would conflict with the uart throttle input on the slave. No failover can occur.
Setup 2:
Dual ESCs, no canbus. Each has an RX and is configured as a separate uart master. This is an isolated/islanded approach and not something I can recommend. This is the scenario I used above, where if one RX times out it will spin down. No failover here.
Let me know if that makes sense!
But…programming and some hardware sauce?