Could you remind us what does IMU stand for ?
Just make take a look at the vesc-tool logging description. You just have to use the same format.
IMU stands for Inertial Measurement Unit. Which is basically accelerometer, barometer, gyroscope and sometimes compass too (6 or 9 axis) on a small chip.
The most common chip used I see on flight controllers is from invensense :
Edit : corrected chip instead of ship…
This is basically the idea, hence the question to Franck Trampa. If we could just format the data like the original VESC does and use the VESC tool to read them, it would spare us hours of development.
You can do that. The CSV structure just needs to match.
Wow, wasn’t expecting this. This is a great nieuws, thanks !
@samisin could you provide a sample of your code formatting the data ? we’ll check this to make sure it’s the same structure in csv format
That is probably how Foil_USA start their remote to Rx module pairing:
1- when a battery insertion is detected, a silent pairing session window is opened awaiting the trigger PWM signal of the previously paired remote or a remote tap pairing frame.
IF during the pairing time window, a remote is tapped (opposite wrist, board deck, whatever…), AND a chock is detected by the IMU and sends a pairing frame to the Rx AND Reception signal level > y mdB or milidecibel (ensuring a close tap ie within a 1foot or 30cm distance)
THEN
the pairing is done and the pairing window is closed
ELSE !tap detected outside pairing time window OR tap too far from Rx module OR …
the remote cannot send any pairing frame AND the Rx rejects any pairing frame
So the pairing time window is (would be) opened by a battery insertion and is closed
EITHER BY the PWM signal of the previously registered remote (#CURRENT_REMOTE_MAC)
OR the end of a successful pairing session initiated by a remote tap (IMU)
OR The pairing time window could elapse X sec (15, 20, 30s…) after battery insertion
IF pairing frame of new_remote_MAC is accepted, current_remote_MAC = new_remote_MAC)
This is indeed a possibility. By measuring the signal Tx strength and the gyroscope + accelerometer data (you just need to analyse the altitude tough), you know nearly exactly when you are close to the Rx module and you can pair it.
But, what would happen if, say 5 users of the same brand are close to each others when trying to pair the remote ? Sami is working on a safer (maybe not the easier) way to pair them, especially if you want a receiver to be used with multiple boards.
Fixed MAC ID is basically the way your headset is paired to your laptop for exemple.
What happens if you have two touching headset trying to pair with two neighbour laptops ?
It is something that you never meet at home, do you ? You take some precautions to avoid this situation.
In the eFoil world, if it is in the same rental, there should be only one guy inserting the battery and tapping the remote to close the pairing window as quickly as possible.
The signal strength is a foolproof filter. Five (even two) guys cannot pair their remote in the same foot square.
Unlikely but If you realize that your Rx is receiving orders from a wrongly associated Tx, a reset pairing button might be needed.
Logging in csv format is easy. I am logging in text file Reason is it is light and fast versus structuring xml or csv. Simple script or app can convert it to proper csv format for vesc tool.
About pairing it is not that complicated as long as you pair the remote to the right receiver once they will remember each other until user unpairs them
Pairing is no big issue. Untill we see tons of Hydrofoils on a single spot, we probably have batteries with three times the capacity and mind controlled boards. Our new VESC Wand remote has a 10second window and that is closed once the remote is paired. Usually 2seconds…
Dude next to you needs to do the same thing within the same two seconds. And doing a quick test, he would realize that his remote ain’t working.
Do you mean first time pairing? Remote and receiver need to pair once and then receiver will advertise with white lost which means that speciific receiver is only visible for that paired remote and no one else. Remote stores the mac address of the receiver and only initiate connection with one receiver that matches the mac address. Most of the people uses ble with randomly created mac address which changes when mcu starts from the reset point of the mcu. Each nrf chip comes with unique id which I use to create mac address and this way the mac is always same and after carefully pairing once by seeing the serial numbers in advertising package of receiver ( on the remote lcd) you initiate the pair. Even if dozen of them are in the field you pair to yours which you can rename it as Trampa’s receiver, f
Receiver is Almost Ready for the fab.
Again mcu is nrf52840 module MDBT50Q family. This module comes in 3 flavor, PCB antenna, uFL connector for external antenna and chip antenna, Based on their documentation best range can achieve with external antenna and the chip antenna is also good. Good news is all have the same footprints and interchangeable.
Current receiver design feature:
1-VESC controll provisions for UART and Voltage (voltage with external DAC)
2- IMU unit (not decided what to do with it yet)
3- Analog front end for 2 leak detection and two external temperature sensors, Analogfront end is very similar for both TS and leak just resistors values
4- 3 servo pwm output for potential future development
5- I2C input for external sensors for potential future development
6- Kill Switch foor immediate shutdown, It can be used for safety leash
7- Pairing button
8- USB port for fimrware update and debugging
9- RGB LED
10 buzzer
All inputs are protected against high voltage and ESD, plus you can power it up in 3 different ways even at the same time, Power break, from VESC 5v out, or just with usb.
What is missing is CAN which It would be good to have to use with chimerical motor drives or even VESC. For this I need to add another MCU that has CAN peripheral. This would add lot of complexity for firmware development. Lets see how this goes mabe next rev.
Total board size is 60 by 40mm.
Nice work Sami !
I’ll try to take care of it. Let me know when you have a log file to work on
I think we agree Your remote is really nice. Do you indend to release a waterproof version ?
http://www.trampaboards.com/wand-p-26992.html
Some good progress today on remote side.
Asembly is done and continuity test passed . Will plug the power this weekend and do the smoke test lol. I have a dev board to use as receiver until Receiver boards comes from the fab. Half way during the assembly I realized I forgot to order imu chip not sure if I can assemble imu on this unit later.
Looks so nice !
20 char
What a job…
Wow!
Looks great! Very good use of the limited space of the lid. I have had good experience using uv glue to bond a PC sheet to the lid for the screen.
Thanks to your initial design. I took it as reference but it is going to change drastically. Hall sensor will be inside the housing, trigger system will change to be very simple spring based, no nots but inserts and inserts on the lid so screws will not be visible on the top, little more angled top face for better visibility…