Made sure I changed to Remote.Feather. Saved and built then uploaded. Seems to be something going on with the upload process though, it’s been running for like 10 minutes…
In the meantime I tried to program the receiver and that worked ! , took like 20sec. Just need to figure out what’s going on with the transmitter
I have this issue from time to time, try pressing the reset button on Feather before upload starts.
Ok I’ll give that a go. Is it possible I screwed up the board on the previous attempts like does it need to be erased, or will it just overwrite. The reciever went easily !
I’ve tried this a dozen times now. The build is correct for the remote but I can’t get it to upload. Scratch that!!! It finally worked !!! Wooooo
1 Like
Does the direction of the magets matter for the thumbwheel ?
@PickSix24 their polarity should be opposite to each other. If you turn on remote only, you’ll see hal values on connecting screen.
@butt_stallion yes, both with original and @Ackmaniac’s firmware.
1 Like
Tested today BLE packet forwarding on TTGO board, essentially it works the same as HM-10 Bluetooth module. Got original VESC-Tool mobile to connect and show real-time data. Not quite sure that it will work good enough in parallel with the remote, but at least the ability to configure motor settings on mobile devices would be useful.
Hey @DroidSector, so i got finally my Feather M0’s and it looks like im finally able to compile & upload the code to them . They indeed are connecting and after soldering all the other components i was making some tests.
I saw that in the OLED screen if i press the power button i can then have further debug on checking the hall sensor values. It appears he goes from 127 to 20 from one way but if i move the thumbwheel on the oposite from neutrall the value goes reaallly small , from 127.500 to 127.800. is it intended? to have a completly different sensitivity on one of the ways ?
Also when i power on the transmitter and it is connected to the receiver, the LED of the power switch is constantly blinking. Is this normal ? And i have this issue when i turn the thumbwheel any of the directions , the connection gets lost for some miliseconds and back on. Looks like the magnets are affecting the communication? If so, is there something i can do to fix this?
And related to the receiver, i have it connected to my Maytech VESC based controller. I honestly don’t know what are the steps to correctly set it up. I just connected the pinouts to the UART port from the receiver but i am not getting any telemetry data. Do i need to update the firmware first of the VESC? If so, by using the vesc tool what do i need to configure there to properly get UART port work with the feather m0 receiver?
Hope someone can shed some light on this for me. Thanks.
Alright, i got an update on my issues.
Regarding the HALL sensors values. This was just a misjudgment from my side. It is indeed working as it should be and the values are relative if im pressing the deadman trigger or not. After also adjusting the min/max/center of hall the values appear to be alright.
Now after some more tries i realized that my vesc was not updated to the latest FW. After updating and changing baud rate to 9600 it looks like the receiver was collecting UART data.
Now i got ran into a weird problem… I see the transmitter connected with the receiver, however it looks like there is an issue with comunication. The OLED transmitter keeps blinking from 0% deck battery to 100% and speed from 0 to max, in 2 in 2 seconds. Sometimes if i write something on the config of the vesc , out of nowhere the transmitter and receiver are working perfectly. Then if i switch everything off and the on, the problem appears again. I can sometimes get the transm/receiver working by constantly changing baudrate of the vesc and for some unkown reason in one of the tries , it starts to work until i switch off…
Im lost now on where is the issue of this. i see on the log the UART data is being collected and transmitted, but the transmitter /receiver connection is really weird and only sometimes it work perfectly until i shut it off.
Are you testing it while your computer is connected to the vesc? Please try to disconnect all the cables.
You can also try to increase the baudrate both in vesc and in receiver.cpp:
59: Serial1.begin(9600);
Also comment out DEBUG directive and rebuild code for receiver and remote, it should also speed things up.
@DroidSector, i tried that but unfortunately no progress…
I tried something to make sure what is wrong and i went to the receiver code and uncommented the debug fields of UART message:
// telemetry.setVoltage(41.35); … // telemetryUpdated = true; // return;
After that the communication between the transmitter and receiver is working perfectly and it never went down , even if i shutdown any of them and put them back on.
So this indicates there is an issue on constantly fetching UART data from the VESC. I am having a strong gut feeling that this is related to the way my feather m0 is connected to the VESC.
Here is a small indication on how i have it currently connected:
Feather m0 VEsc UART 3v3 -------------------------3v3 GND------------------------GND TX---------------------------RX RX---------------------------TX
Now, i dont have any more connections because i saw the feather being powered up through the 3v3pinout…?! However it does not make sense because from the spec of the feather m0, that pinout actually provides power and not receiving it.
If had my feather connected though through usb to my PC for debugging purporses.
Do you think i have to use the 5V pinout from UART Vesc port to power as well the feather m0? could that be the issue? If that is it, which pinout connection should be ? USB/BAT to 5v UART ?
Try to set uartPullInterval = 1000; (1 sec) in receiver.h and maybe uncomment UART.setDebugPort(&Serial); in receiver.cpp.
You can connect UART 5v or 3.3v to BAT pin, it will use the regulator but I guess it won’t feed power into vesc from the USB cable.
So just to make sure, the connection pins your are saying is
Feather m0 Vesc UART BAT ----------------------3v3/5v GND ---------------------GND TX ----------------------RX RX -----------------------TX
Is just that on your diagram https://raw.githubusercontent.com/DroidSector/RF69-Esk8-Remote/development/images/electronics_schematic_receiver.png
I see the 3v3 connected from/to UART and feather m0. And then i see a power filter of 5v to GND, but which gnd and which 5v ? from feather ? i think its a power filter from the vesc to the feather, but then which pinouts should they be connected to ?
Thanks for the help , i will try though on doing the bat/3v3 and changing that code line.
Sorry, I was lazy and copy-pasted it, it should be 3.3v instead of 5v. Because the capacitors were rather big, I’ve placed this filter around the middle of power wires between Feather and UART.
Alright so after performing aditional trial and errors and following @DroidSector advice, here are the observations:
the wiring of the receiver it should be indeed
Feather M0 ---------- UART Vesc BAT --------- 3v
OR
USB ----------- 5v
All the others are the same as in the receiver image that Droid provided.
After this i got stable connection for throttling the engine and breaking… However, weirdly enough i am having issues with the telemetry information exchange.
With ddebug i did not find any weird error message or missing information when building the packet to send to the transmitter. But, on the transmitter i saw that i get sometimes, and for some periods i get only “No reply” debug message. This however does not interfere at all with the throttle/break command.
On the debug of the transmitter i see that before it gives “No reply” he actually receives a packet but with different information.
Response: 0 , chain: 23, CRC: 46
After these packets are shown on debug, then the “No reply” debug message shows after.
If i get a Response:1, chain:23, CRC: 77 It is then working fine.
I dont know where the response:0 messages are coming from but it is why my transmitter is giving incorrect telemetry on the OLED. Just to clarify, sometimes it does get proper info for some seconds and i see corrrect information, but most of the time is just giving default/different values than it should be.
Also on the receiver i am never getting UART data issues.
I changed the baudrate and the timeout to 1 sec of capturing UART data and it did not make a difference in this.
1 Like
Please try to increase the timeout to 100 in responseAvailable() function (remote.cpp):
if (millis() - ms > 10) return false;
I’ll connect Feather to vesc to test it more thoroughly today.
@DroidSector, it really worked! the refresh time of telemetry is not quick but honestly its more than fine for me. throttle/break response is quite good so its not conflicting with the driving.
Thanks a lot !!!
Just as an improvement for me, do you know where can i change the sensitivity of the acceleration? I feel that the moment i get close to the thumbwheel on a specific point it starts engaging almost full speed. Perhaps i could change the acceleration relative to the hall values? If you could help me checking which place it would be great!
Again, thanks a lot DroidSector, finally it is working ! and awesome transmitter btw 
Thanks! You can change _HALL values in globals.h. Move the throttle wheel to the full stop or a position convenient for you and note the hall value on the debug screen (should be around 600). Use it for MAX_HALL value. Repeat the same for brake and MIN_HALL. CENTER_HALL should match the idle hall value.
Another value to tweak is this one (in bold) on line 691:
position = constrain(map(hallValue, settings.centerHallValue + hallNoiseMargin, settings.maxHallValue, 127, 255), 127, 255);
Stand on the board and give a little throttle, just enough to start moving. Note the hall value and use it instead of 127. This will expand the useful range of the throttle wheel. I’m currently working on a calibration screen to automate this process.