edit: both top and bottom shell pieces are the same direction and impossible to close against each other, so you will have to mirror one of them, then flip, JFI
Also you may need to build the Mr Happy Face…I mean throttle with support.
It just occured to me and maybe this is a 3D newbie duh, any lefties out there can use that mirror-flip proceedure to make a left handed remote!
@banjaxxed What a mess, haha Second attempt looks good, did I forget to mirror the top? Thanks for notifying me - I will add it to my ever-growing to-do list :-)! If you mirror the remote to make a lefthanded version, the display will not be placed in the right way (the screen itself is not in the center on the board).
I twigged that I think I made a leftie, the screen is on my right hand palm side I should have mirrored and flipped the other case side instead!
I’ll notch it up to a learning curve also made a very nice active cooling addition to my dual extruder so expecting even better results but might use nylon instead of ABS
@solidgeek@Clonkex glad you like my idea. Just another suggestion, if you decide to store the pipe address on the eeprom. If by accident one receiver pairs with another remote during startup, and you store the pipes, then the two will be forever paired. Also if somebody loses their remote / changes the receiver, there will be no way to pair them.
However, if you still want to store the pipes, I would suggest another bit of code that monitors the pairing process in the setup. After a long timeout (for example 1 or 2 minutes), if it can’t pair, both the remote and receiver should erase the pipe address from the eeprom and reset it to the default one. This way if a cross pair happens or somebody replaces their remote/receiver, they can still pair the two. Just turn both on and leave them on for a while, then the timeout occurs and the default pipe is used again.
@solidgeek I’m interested in a beta unit as well, is there more room for one? (I’m in London, UK). I’m a software engineer and could help contributing to the codebase with a couple of PRs. I can source most of the electronics and put it together myself, getting a good 3D printed enclosure is the hardest part. If there is more room, I’d be interested in one beta remote to help with the coding and debugging/testing.
@Tathers I have been working on the newest version with pairing and unique nRF24 addresses. I got a few hours left of coding for sure, however, I think I will be ready to release this weekend
@egzplicit I like your ideas I have been thinking about the same problem for quite some time now. I am not sure that a timeout is the best solution. This is because you could easily forget to turn off your remote and having the remote using the default pipe next day without you knowing. Another option, I think would be better is to make a pairing procedure, and adding a little tactile button on the receiver to enable this. In this way, you can pair your remote and receiver, and save the pipe to both EEPROMs. In pairing mode, the receiver will listen on the default address, while waiting for a new pipe sent by the remote. This way you can always repair, and chances for pairing with a wrong remote is second to none. What do you think of this?
@egzplicit I am sorry I have already promised more than I am able to produce at the moment. I would love to get you one… I could surely use some fellow engineering support. If you want I can definitely print all parts for you, and maybe sell you some of the modules (I got some of them in spare).
@solidgeek thanks! For some reason i though the restriction is not having a button on the receiver. This is why I tried to come with a solution without any other physical components. The timeout would work without the switch but yes, if you decide to have one, your solution is much better.
A temporary switch will work nicely: press it them turn on the board and the setup() routine will see it being pressed and the receiver will enter pairing mode on the default pipe. Then put the remote into pairing mode as well (via the menu) and the process starts.
That’s ok about the betas, the 3d printed parts are the hardest for me so if you can help me with those it would be great. I can buy most of the components, however, if you have some extra parts, I don’t mind buying from you and save some time (shipping from china takes forever). I’ll PM you.
Awesome work with finding ways to deal with the pairing!
While I wait for the latest code, I wanted to start 3D printing the enclosure, however I noticed that there was a “newer version” with the knob on the thumbwheel, has that version been uploaded to thingyverse yet?
If that was the only change made then I can probably adjust the model myself but I wasn’t sure if there were other updates.
One other question I had was, if I am running dual VESCs, I assume I need to use the CAN bus between the two so that I will be able to read data from both simultaneously?
Hmmmm I just noticed.
The display takes up pretty much all of the looptime. so displaying more increases the looptime. (150ms in my case) Thats just too much for such a time critical application.
I was thinking about a second arduino in the remote just to drive the display? Either that or a 32bit micro controller like this one: ali link (which is way more expensive)