I know this. I’m telling you that assuming everyone wants all these CANBUS cross-connections and an entire networked system is a foolish assumption. Some folks are building for “reliable” (tools instead of toys) and want two completely separate drivetrains connected only by the power wires. You just keep ignoring me.
You wouldn’t need CAN if you use two receivers. One NRF remote can connect to two NRF modules, so you could build a setup with two totally independent NRF receivers. This way you can configure both VESCs via App, while keeping redundancy. Benjamin confirmed that.
7 Likes
After 9 months I’d kind of given up on my VESC Tool pull request. . . and then it got merged in. Official VESC Tool contributor 
. Vedder went through a few PRs yesterday, some got merged, others received constructive feedback. This is a good thing.
Other nice thing about the nrf51822 is that it packs enough power to do more than just handle BT data. It can also do stuff like drive a small OLED display itself. Should make for smaller, more power efficient remotes (as you no longer need an arduino).
12 Likes
adafruit do both a 32u4 and M0 version of the feather with the MDBT40 NRF51 on board so it may be an easy mod to update some remotes.
Additional this change might make new remotes super easy to make cause you basically just need a feather with the correct module on-board, the hall sensor and the oled. no more separate charging circuits or boost converters. and cause everything will run at 3v battery life might even be better.
1 Like
@Deodand what is the Bluetooth module used in the unity? is it able to bind directly with NRF remotes? i assume that is whats happening in the raptor.
Yeah, I noticed that he was merging requests and closing issues for the last 2 days or so. Congrats.
BTW, do you know if you can substitute nRF52 instead of nRF51? Is it a drop in replacement? That’s what is being used by metr pro, but their firmware is not OS, so no I don’t have any idea whether it’s based on vedder’s nrf_51 code or not.
1 Like
Benjamin was super busy with his PHD in the last year. Now that this thing is from the table, pull requests get attention and things move forward. The next update is not far away. NRF 51 does the trick and is very cost efficient. NRF 52 should also work. In the end you want one module to handle everything.
2 Likes
@trampa you are so boring!
Working yourself into the corner is not a bad thing! Sometimes you have to do it because what matters more is what people need and not how your code looks like. I do it all the time. My software engineer self-esteem takes a hit, but what I get back is happiness and this is so much more 
Take a classic example that happens here every now and then. She has a board, that rides perfectly. PERFECTLY! She doesn’t want to change a damn thing. But here it comes, a new version VESC APP says that she needs to upgrade firmware. Otherwise app doesn’t work. And after she updates it doesn’t feel the same anymore. The board is not perfect anymore 
This is the reason some people still have v2.18 firmware and we still have support for it in the Metr app. Alongside with every other version. I bite my teeth and force myself out of my comfort zone. It is very much worth it!
13 Likes
As long as all software engineers practice semantic versioning, you can have your cake and eat it too.
I think that’s actually the entire problem here. Benjamin and all 3rd party vendors all need to use sematic versioning and check for compatibility assuming everyone else uses it also.
2 Likes
I never experience that after an update my board setup is screwed. If anything it gets better. Also no one forces you to update and you can go back whenever you like and load your old XMLs back on. Any version of VESC-Tool can upload any FW.
There is no risk in updating if you save to XML what you have. You can keep a copy of your old VESC-Tool and use it whenever you like.
Found it 
4 Likes
nrf52 would be nice, from what I’ve read it’s quite the beast compared to the nrf51. That said the extra power may be overkill depending on what application you had in mind.
No, I don’t believe you could simply compile what’s in Vedder’s repo and upload to a nrf52. Vedder’s code doesn’t seem too platform specific, but there’s the config settings (sdk_config.h, etc) that certainly are. If I was going to attempt it I’d probably start with a working Nordic nrf52 based example, and then add Vedder’s code into it.
1 Like
I ran both verisions for projects at works, and I can confirm its not a drop in. Alot of extra work to get the 52 going with setup already done for the 51 (atleast it was for me, Im primarly focused on hardware not software.).
1 Like
The NRF52 is a bit overkill for what we do at this stage. Thh51 does the trick and is more affordable. In the end we want a stable wireless connection and a reliable remote and we want an affordable solution that does work for us. So we decided to implement the 51 first. At some stage the 52 might find more attention. If someone is happy to do the job, he is well welcome to bang on the 52 and send a pull request once it works. another thing to consider is also energy consumption. A remote should be designed to consume as little energy as humanly possible, so that we can use it for 40-60 hours without recharging the battery.
Pretty sure they’re close to identical when it comes to cunsumption, the nrf52 has more memory and better ADC features, but thats about it when it comes to the bottomline. Its the initial setup with config etc thats a hassle if you already did for the 51, as they’re different.
2 Likes
I have 2 vesc 6 and downkoaded the new tool. They are hooked up by canbus. It doesnt seem to recognize the slave. It only runs the master wheel when running wizard. Once motor and input are finished, both wheels run when using the remote, but it seems there is only settings showing for 1 motor. Canbus scan doesnt do anything? What am i doing wrong? @trampa
I guess FW update didn’t happen on both VESCs. Update the FW on both individually and try again.
That fixed it. A bit annoying to have to open it up though. Hopefully i am the only one that gets this issue. Thanks for the quick help.
The FW should update simultaneously. One way to avoid such issues is to connect to slave fist, update FW, then do the master. After that procedure any FW update can be done simultaneously in any future.
2 Likes