Okay so i hope that my batteries arrives soon and I can start to configure all that!
Interesting, is there a special forum for remote controls, where i can find more information about this?
1 Like
The failsafe on this remote / receiver is like this: when the remote is on and in the receivers distance the signal of the receiver will be somewhere between 1000 - 2000 ms depending on throttle position. If the receiver is out of range or the remote is off, the signal will go to around 900 ms. Now your esc failsafe can kick in.
ok, this is already described in the small manual, you can set the fail safe value in the binding procedure.
I just bind the elder receiver i have to the new unused transmitter and now look at this:
Cloud
The signal range where the error happens has shifted.
I think this proves, the problem is not inside the transmitter and the hall sensor, but there is a systematic error in both of my receivers. And this throttle range fits the throttle range where i had reproducable problems on river Main last summer. Update: (Maybe a bug in the decryption?)
Just found, that both receivers produce at both values the same behaviour. One in the lower range, one in the upper. Its hard to find, but can anyone reproduce this, maybe using the Vesc Tool, a servo or complete setup?
I will look into it as well. I have the same osciliscope 
. I remember when I was foiling last summer that I felt little bumps from the motor like you hit the throttle and than go back to same position. So I ques I have the same problem and than it would be in every remote / transmitter:neutral_face:
Mine does it to. I try to make video later
Very cool, any forthcomings?
So, from what I understand, the $ 30 USD is not an option anymoe since the failsafe is not safe at all ?
Maytech remote is way too expensive, especially the V2 version.
We could work on the Flipsky VX2 that uses a hall effect sensor and can be waterproofed. Only draw back is the charging port. But it can be replaced by a cheap QI coil I think. I’ll try this out soon and let you know (remote is 75USD online, with great quality)
1 Like
I’m using the cheap remote for about a year now. For that price it is still a nice option. But of course you need to waterproof it for your one.
Here a video of my remote and servo plus osciloscoop to see the problem: https://youtu.be/o-YSas33Kic
For me this is happening at 0% or near 0% throttle but I have also seen it at other throttle positions earlier. It does not always show up if you move the throttle fast enough over this point. I now suspect it to be a software problem and will test with other remotes and reveivers as well to confirm if it is on the remote or receiver side.
Update: I don’t know if it is in de transmitter or receiver, I tried different combinations but they all have this problem.
Now I am sure the problem is in the software. This is what I found:
At throttle value 1030us signal jumps to 1280us
At throttle value 1280us signal jumps to 1530us
At throttle value 1530us signal jumps to 1790us
At throttle value 1790us signal jumps to 2050us
This means there are 4 throttle positions where this happens. The values are exactly the same for all my remotes and receivers.
If you look closely to those values you see there is a difference from 250-260us between values. I think it will be exactly 256us or 1 byte. So what I think is that there is a 1 byte storage for the the throttle value and this is overflowing every 1/4 position of the throttle. I don’t know exactly how this is programmed and also don’t know how to fix this right now. Is there anyone with a sugestion and can someone else confirm my conclusion?
I still don’t know if the problem is in the receiver or transmitter or maybe both?
Edit: the value where the problem is starting 1030 (I guess 1024 exactly is also a multiple of 256)
3 Likes
Very good analysis! Thank you. I will check later if i also can get 4 points of malfunction. I can confirm 4 points exactly like you described.
1 Like
Yes microseconds it is, thank you. Would be nice to see if you find the same values.
I tried to contact the manufacturer through sellers at ebay and alibaba, so far there is no response. I am asking if the manufacturer could chime into this thread.
Everyone who wants to buy this remote, please ask the seller if he knows this thread and his opinion about it. And do not buy it. If you ever noticed it in practice it is more than annoying, and after understanding how big the problem is i do not want to use it any more.
This all is about winning remote control w4r v2.1
Today I made a dirty fix on the receiver side. I used an arduino pro mini to read the receiver signal and output the same signal only if it does not jump between 200 and 300us. If the jump happends the signal out will stay where it was. See video of the result: https://youtu.be/3qdIkTI1xU8
Yellow is signal in
Blue is signal out.
I already use an arduino to smooth my throttle curve so it is not realy a problem for me, but I don’t like that I have to do this to make it work.
2 Likes
I think i know the reason why this is happening.
There are at least 11 bits necessary to transmit the value in microseconds. If the transfer is possible with bytes only, two bytes are needed.
I used the VESC Tool to analyse, choose RT App, Mapping and you can see the minimum and maximum values. You can reset them. Choose a value of 1250, reset the minmax and slowly decrease. In the moment you see a jump increase again. Write down the values. Continue with 1300 and repeat, until you documented the 4 values.
Of course there is some tolerance in sampling these values by the vesc.
But you will find a pattern e.g. like this:
1025 -> 1279 100 0000 0001 -> 100 1111 1111
1280 -> 1534 101 0000 0000 -> 101 1111 1110
1535 -> 1789 101 1111 1111 -> 110 1111 1101
1789 -> 2044 110 1111 1101 -> 111 1111 1100
So the problem is, that the high and low byte do not belong to the same sample, they are not correctly interpreted by the receiver. The high and low byte belong to two different samples, the critical value is when the overflow of the low byte happens. The least significant bit (LSB) in the high byte is set while (almost) all bits in the low byte are also set resulting in a jump of 255 or slightly less.
I am not sure if I understand you correct but do you mean something like this:
Transmitter has to sent 2 bytes, when it is sending the first byte, the second byte changes by a little variance of throttle input, so the first and second byte do not belong to the same throttle value.
Yes, in theory it would be like this:
First value is 1024 100 0000 0000 than changes to 1023 011 1111 1111 and the high byte of first value is added to the low byte of second value, resulting in 100 1111 1111 1111 = 1279.
This remote could also be affected by the same bug. Did you test it like supposed? Finding permanent waterproofing solution for 30$ "waterproof" remote - #49 by Rienk - Electronics (ESC, remote, batteries) - FOIL.zone