DIY remote design inputs

That design looks great. Though I would place all switches/components on the pcb (like it is done in the boosted remote). I’ve been thinking what the easiest/best approach to move from your the case design to the pcb shape (with drill holes, and proper cutouts for certain mechanics (i.e. the thumbwheel)). Any suggestions? (the DXF only has a hole for the center of the thumbwheel, but I am not sure how much space is needed and if I could fully populate everything else :wink: )

I would not omit the antenna - especially considering that we don’t have a clear line of sight from the remote to the board receiver (i.e. board, human body etc. will dampen the signal). Also when testing some RF modules in the past, without antenna I had significant packet loss even if the modules where just couple of centimeters apart. :sweat:

I mostly looked at Open LRS for the protocol and the features - having a frequency spread spectrum (via channel hopping) is desirable for reliability. Almost all rm69 libraries I found, don’t have channel hopping included. Somehow it also seems that the rfm22/23 had this feature directly on the module. Will see if I can find more information.

For OpenLRS there are toosl (similar to the bldc tool) to configure the remote. So it shouldn’t be that hard - generally I see it the same as with the vesc - here people also need to adjust settings

In the end we can see if the open lrs firmware itself can be easily modified for our needs, or if it is feasible to port features over, or to write a custom solution. But I’d rather investigate already existing solutions (and learn the features/limitations) before starting from scratch

I’ve built several remotes using both 433mhz and Nrf2401. My experience with the nrf was good in terms of range and reliability but the biggest problem was that they interfaced the VESC via its ppm/pwm ‘app’ that lacks all of the nice throttle ramping controls, instant torque after coasting that the nunchuck ‘app’ has which makes the riding experience so much better

Does anyone know the protocol that the nunchuck uses to communicate with the vesc?

Please share a bit more about your experience and your design

There are different implementations - but for the one that is provided by benjamin vedder check his forums http://vedder.se/forums/index.php and the nunchuck app for the vesc

additionally check this github repository - it provides an uart → vesc interface for “nunchuck commands”

Great…I’ll start digging there.

I’ve been posting our whole project to hackaday…lots of stuff on both the board and remote hardware, electronics and software. Some stuff on how we handled NRF2401 challenges. Project log is here:

So sorry for the long away time… (A lot of shit hit the fan lately :-/ ) I will try to design a pcb for you, with the envelope you can design within. As to mounting screws I havnt really planned this out yet… But I will soon, else if yoo decide on some holes, I can also incorporate these into the design. For the case, would you mostly like screws or you glueing it together ?

It some time since I played with these modules, and ofc we should not remove the antenna, but I hope we will get good range still, but we just need to test it out, move stuff around in the case until there is a good signal :slight_smile:

Do the modules actually just do the channel hopping in hardware or maybe not at all ? Still it is a good thing that we are away from most noise sources not using 2.4Ghz

Its always a good idea to steal parts of code when needed, no reason to reinvent something simular

Looking at the VESC UART interface and other VESC GIt Hub references…these seem to be mainly concerned with how to communicate diagnostics or set/get values for things like the BLDC tool.

I found a good Wii-Nunchuck I2C protocol. It seems pretty easy to implement. It’s a simple I2C slave with 2 commands and a 6 byte payload and a bit of CRC.

Still I think the next thing to try is moving the receiver very far from the VESC, maybe supply an independent 3.3V to it. I’ll be outlining my attempts at doing this and some other things on my Hackaday log.

nice theory creation and testing! This sort of thing with the nunchuck receiver has been on my mind a lot lately because I want to implement a topside location for the receiver, This means the receiver will have to be given a longer wire. Obviously wondering of ways to shield from interference. But if its a 3.3 volt problem then theres an easy fix… Looking forward to option 3 test.

what do you guys think of the nRF24L01 compared to bluetooth in regards to handing interference? - had some issues with my early November Evolve Bamboo GT - just wondering if a different radio may work better. (its intermittent - some times ok - other times not - trying to determine if its a hw defect with my remote/board controller or if the nature of the beast with this radio) - I don’ think the nRF24L01 has frequency hopping or similar built in - whereas pretty sure all versions of bluetooth do (they are using similar frequencies) - thanks

@B4Me i would pay for a controller like yours with some buttons more:

  • speed acceleration (noob, pro)
  • cruise control
1 Like

Hi julian, its the same issue… you need to move away from 2.4Ghz if you want less interference… 2.4ghz is so populated with everything :-/

Hi! i`m new here im i just looking for some really good looking remote… so how is you Project going? if i can add somthing i think it need to be more “heavy” adding weight it would createe the “expensive remote” LOL and the ring wherer to put the finger would be great!

1 Like

lol at everybody arguing you need two receiver modules…its called a diversity receiver… diversity receivers are typically two transceivers that can both trans and receive, one is used for signal, one used for telemetry with packet health. both antennas can receive during packet degredation…

if your looking for multichannel capability, small receivers/transceivers. look into FrSky SBUS ie OpenTX. Its open source, supports upto 16 channels, and you can use SmartPort telemetry if you desire(ie send VESC data back for an OLED screen)

realizing now this was a dead bumped thread^ lol

dead, maybe, but the info is still valuable for me and the others following :slight_smile: My time is the issue, else this remote would long be in the marked