Coming soon:
Professionally made and produced.
Br Felix
Can it work with vesc? Do you have pictures of the receiver? Is it waterproof or potted inside? What is runtime on a battery charge? How is it charged? Uff so many questions.
Come on Felix you can do better presentation.
When availibe and what price?
1 Like
Thanks for asking. I didn’t want to give out so many details yet, as there are many others who are currently under development. About Vesc compatibility:
Yes, my remote works with every system. It will get complete vesc support once the development of the standard version is complete. The receiver is only a pcb and I don’t want to give the design out yet!
Now the good parts. This remote is not potted. Why? Easy accessible electronics and parts can be switched out easily. The Remote is sla printed in high precision and strong resin. Sla printed parts are 100% waterproof.
Runtime is customisable, as you can set the display brightness to super high, or high. On super high, it is always readable, also in direct sunlight. Runtime is 8-10h. High brightness is still good to read but increases the battery runtime be nearly double.
Wireless charging: Remote is fully charged in 4h.
I think these are some good values.
Yes, this presentation was short, but for a good reason. I’m still under development, and I don’t want to give out many details right now. The remote will be consumer-ready in Mai-June. 5 Beta testers will be selected in March-April.
Thank you for these great questions!
Br
Felix
6 Likes
housing looks great!
2 Likes
Thank you! Stay tuned for the pcbs which will arrive next month.
2 Likes
Hi! The remote is looking great! You have really pushed on with the developement. Can you give an estimate on the price? And the size of the pcb?
Hi @Felixfoiler what is the penetration depth under water and what communication frequency is your set using?
1 Like
the receiver is under development. but my receiver is more than only a receiver. its also a logger. you will be able to log data to an sd card and view it on your phone. Also, GPS is available for addition. I need to calculate the price, but its defiantly not cheap. Quality never comes cheap!
Br
Felix
1 Like
Thank you for asking. I tested in a bucket (because the lake is frozen right now 
). It is based on a 433mhz signal which is perfect for water penetration. I can’t tell the penetration depth, but if you don’t go diving with your efoil, it won’t be a problem.
Thanks a lot!
Felix
Congrats ! What mechanism have you implemented for efoil meetings where several persons using 433Mhz could meet up on the same spot ?
1 Like
Perhaps a non-popular game of “control-a-friends foil”. Could be an interesting game to watch…
On a more serious note this is a very good point!
1 Like
sure i thought of that
i think i have 240 available channels or so. if I sell more then that it could happen that you are steering your friend
Good to know. Out of curiosity, how does it work ? A random token ? Let’s imagine 10 remotes realise they are all using the same channel…
won’t happen, as I configure them myself. you can set the channel on the remote and receiver, so if it would happen you would need to change that, if you dont want to steer your friend ;).
Estimated Price point?
please kindly wait till next week. I will release more info and a valuable presentation, where all these things are addressed.
Thanks a lot
Felix
1 Like
Nice looking remote!
I’ve implemented a quadcopter racing RC protocol, with an aim of the lowest latency and robustness. So if you want to bounce any ideas off me shoot me a message. I’ve done a fair bit of messing around with TI and semtech chips.
Thank you. Unfortunately the latency only comes from the 434mhz modules. But 20ms is already such a good latency, I don’t think I need to improve it anymore. You will never notice 20ms on an efoil 
Oh yeah, for sure you don’t that low of latency! But what I meant is I got a bunch of radio experience. Channel hopping, good error correction, etc. For example, even with 240 channels you can get a strong interfering 433 signal that blows away a set of channels when ever it transmits.
On my protocol, on binding you get a random (based on a microcontroller rom id) set of 50 channels (frequencies) it hops in sequence every packet that is transmitted. If you happen to get something blowing out a channel you just lose one packet.
Also good to have a CRC or error correction on there. As well as, some kind of transmitter id hashed with the mcuid, so when someone is using the same protocol on the same channel you know to reject that packet.
Getting the failsafe perfect as well, easiest just to stop sending anything to the esc in the case of missed packets.
Not too much effort to make something really rocksolid! Maybe your module takes care of some of that as well.
I had been thinking about the waydoo runaways, I could come up with a few ways bad RC implementations could cause that issue.
But again, awesome remote!! Look forward to seeing more about it.
I can see you know a lot there. My protocol is rocksolid, especially the turnoff when it looses connection. Yes I have a detection for corrupted data/incomplete packages. I think my communication protocol is good, but help is always appreciated. Thank you.