Don’t know what i did! I think i was copying the output straight from the web page and the serial trrminal.
Probably just fat fingers, but i will report back if I keep seeing it.
Thank ypu for the support. Loving the bremote V2, just ordered a second receiver for the next project.
Hello Ludwig,
This morning I broke my steering lever (on the V2 Classic) and therefore lost the two magnets. Would you have a link or the part references for the magnets so I can order replacements and also have some spares? thanks
Bonus question: once I no longer had steering, I had the bright idea of switching off the remote. Obviously, I could no longer unlock it. Is there a trick if this happens again? ^^
It gave me a good swimming session.
Diameter 3mm, Length 6mm N52 magnets. Strength should be at least N52, lower will result in low steering resolution or failure to calibrate
Not really, except turning off locking all the time in the config.
Great thank you.
Sorry to bother you once again. I’ve just noticed that the magnet on my on/off button is starting to rust. Obviously, I can’t disassemble it to measure it. Would you have the specifications so I can get the whole assembly back in working order?
Toggle/Steering and Throttle: each 2 pieces 3dia x 6length (mm) N52
Power Switch: 1 piece 4dia x 4length (mm) N52
This is super interesting - especially for the soon to come nano RX. Does this also make it possible to bind, or send the bind and reboot over the air? I intend to fully pot ESC, receiver, etc. in a case but would need some way of binding afterwards.
A VX3 for example allows for this by just setting the TX to bind mode and it’ll pair to the first RX that powers up nearby. Something similar, or OTA force bind command would be perfect.
Yes, just set the paired variable to 2 and reboot, the Rx will go into forced pairing
I still do not recommend fully potting Rx, since bugs and other errors could always make a reupload of firmware for example necessary
If possible have the 4 USB wires accessible somewhere outside at least
Thanks for the quick response! Good to know, will try it later today with that firmware.
Noted on the usb to be pinned out - I’ll consider that.
Hi everyone,
I am building a second Bremote so that I have a spare and can also remember that one tow boogie could then be shared with two remotes on the water. Is that correct? If two remotes can be used, can you please let me know the steps to pair both so that nothing further needs to be done on the water?
Thanks,
James
You can bind 2 or more remotes to 1 receiver
However they can not be active (turned on) at the same time, so you would have to make sure to turn them on/off accordingly
To do that, set up both remotes by doing the calibration and all setup steps like usual
Bind remote 1 to the Rx
Then copy the paired, src-adress and dest-adress from the config of remote 1 to remote 2
Do not copy the whole config! Since that includes other values like the magnet calibration and so on.
Alternatively send me config strings of both remotes and I can do the merge
Perfect. Thanks. I’ll be back in touch if I struggle when I get to that stage.
I am pretty sure I used the full config string to setup my backup remote and just did a recal after.
I guess it is possible the values are so wrong you do not get into the calibration mode.
But aside from that, what is the downside?
You can do that as well
Copy the string, then immediately set cal_ok to 0 so it redoes the calibration. Otherwise it may lock you out from the startup key combination for recalibration.
Basically the same effort for both ways, the one I proposed is harder to mess up, so less support for me to give 
Had a few claims of “broken magnet sensors” just to find out exactly that was the problem, copied strings without recalibration…
Not trying to make your work harder 
But I was just using the string and turning the remote on in cal mode. No further config work needed. cal_ok=0 only needed if that fails.
Have you considered adding a full multiple remote feature? I think that should be pretty easy to do and would eliminate this fiddling around turning remotes on and off.
This works only 25% of the time, since you can glue both trigger and toggle magnet either direction, and both will invert the combination and make it do something else than calibration
V1 had this as an experimental feature, basically it just stopped sending data if the user did not input throttle, so only the remote that was sending throttle controlled the boogie. This would be rather easy to implement with a basic if-else. Any other “true” multi remote support would need some fundamental RF system change, which is not trivial due to timing restrictions in the current concept.
One could also use the locking feature to disable transmission in locked state, and only transmit in the unlocked state, this may be more comfortable than power on -and off
Guess I just got lucky with cal.
But is cal not only the toggle? And if its reversed, you just push it to the other side? Pretty sure I did this at least 5 times and never had to reset cal by config. But maybe I just got very lucky.
Regarding multiple remotes.
Maybe I’m missing something, but wouldn’t the simplest approach be to give all remotes the same existing pairing address and just add a small unique remote ID to each packet?
The receiver would only accept throttle commands from the active remote. If its throttle stays at zero for a defined timeout, another remote could take over.
I think this would be more robust than relying on inactive remotes not transmitting, since accidental throttle inputs would simply be ignored.
LoRa transmissions can already be received by multiple devices, and packet collisions are a potential issue even with unrelated eFoils nearby. Telemetry could also be shared between remotes.
I was thinking this might be possible with just some additional receiver logic, while keeping most of the existing RF communication unchanged.
Currently the Rx waits for a Tx packet, then responds with the telemetry.
For multiple Tx, each Tx would need to send at different times obviously, and the Rx would need to send telemetry at only one time. That’s what I mean by “not trivial” since all Tx will have to snycronize/que up when to send, and generally with each packet taking 15-20ms, the 100ms sending period will get full quickly
Anyways let’s shift this discussion to the dev thread, and keep this thread for currently implemented features and questions 
(post deleted by author)
Hi Etienne,
Since this is a question regarding V2.5 by monterman, please direct the question towards him in the Future_Dev topic