Forum Replies Created
I mentioned the cause of the problem a few posts back, but I realize now that it may not have been clear enough. The problem is that the micro minimOSD is simply not compatible with the F3FC board. This is because the UART on the minimOSD runs at 5V, while the UART on the F3FC runs at 3.3V. While David did mention that the STM32F chip on the F3FC board are 5V tolerant, this is not true when the internal pull-up or pull-down resistors are enabled. For UART operation, internal pull-up/down resistors are enabled, and so the STM32F chip cannot handle the 5V from the UART on the minimOSD.
I don’t know exactly what is happening, but my guess is that the 5V from the minimOSD TX signal is running through the internal pullup on the STM32F, and pulling the chip’s internal supply rails to a higher voltage than they should be at. If the on-chip ADC is used, the this is probably messing with the ADC’s supply and reference voltages, causing it to read incorrect current values.
To correctly interface the minimOSD with the F3FC, you will need some electrical know-how, but one of the following approaches may work. If you don’t have much electronics experience, I would recommend buying a 3.3V OSD instead.
1.) Disable the internal pull-up or pull-down resistors on the UART port on the F3FC by modifying the firmware (and add an external pull-up resistor to 5V, if necessary).
2.) OR: Connect the TX signal on the minimOSD through a voltage level translator to step the 5V signal down to 3.3V, before connecting to RX pin on the F3FC. You can buy dedicated chips to do this, or build your own circuit with a transistor or two.
3.) OR: As a hack, you might be able to get something working using a resistor voltage divider. Connect the TX signal from the minimOSD through two resistors to ground. Connect the center of the two resistors to the RX pin on the F3FC. You will need to be careful, as you need to take into account the internal pull-up resistor on the STM32F, and make sure you don’t draw too much current from the minimOSD.
EDIT: DISCLAIMER: I don’t actually have a minimOSD with which to test out any of these fixes, but all evidence seems to point to this being the cause.
You should be more concerned about the peak current than the average current. You want to ensure that the peak current is below 10C, not the average current. And since battery manufacturers like to inflate their maximum current handling, I would personally make sure that peak current is below 7.5C for a 10C battery.
For what its worth, I also experienced the huge resonance vibrations that you described. In my case, the resonance was at exactly 1573us throttle, but in the Y axis. I eventually solved this by painstakingly balancing the motors themselves (without the props). I described the issue here:
I also considered adding vibration dampening between the frame/arms and arms/motors, but never quite got there. Perhaps I should revisit this.
Thanks for sharing!
@david Ok great, I wasn’t certain if the F3FC board was using the 5V-tolerant I/O pins or not.
I did however notice a footnote at the bottom of page 59 of the datasheet which says: “To sustain a voltage higher than VDD+0.3 V, the internal pull-up/pull-down resistors must be disabled”.
This is just wild postulating, as I haven’t looked into the source code much (so ignore me if you wish), but maybe someone more familiar with the firmware will want to look into whether the internal pull-ups (or downs) are accidentally being enabled on UART2.
Are both TX and RX wires connected between the F3FC board and the minimOSD? If so, it might be a case that the UART on the OSD board operates at 0-5V, while the UART on the STM32F processor operates at 0-3.3V. In this case, the TX pin on the OSD will pull the RX pin on the STM32F up to 5V at times, which is outside the processor’s spec voltage range.
Does adding a voltage divider help?
I’d also be interested to hear if anyone has figured out the cause of this issue yet.
@swissfreek: it’s only required if you power the satellite receiver from the UART. If you can power the satellite receiver from another 3.3V source, then no need to change the UART voltage.
I’m not certain how the 3.3V pin on the board is currently powered, so I would make sure that it provides enough current to power the satellite receiver before using it.
I am currently actually using a tiny inline 3.3V BEC to power my satellite receiver from the 5V BEC on the board, as I didn’t want to hack my satellite cable, and the only cable that I could find had an inline BEC already installed (from Hobbyking).
If your Spektrum receiver comes with a separate satellite receiver, you can connect the satellite receiver directly to a UART port on the F3FC (just make sure to set the UART to 3.3V).
You will need to use the main Spektrum receiver to bind the satellite, but after that you can dump the main receiver and just use the satellite receiver. I do it, and it works well for me.
Does your servo bind (i.e. get stuck) when give it full right? Because it sounds to me like the servo is hitting some mechanical stop in the tail mechanism, causing high current draw, causing the voltage to drop, and your receiver is shutting down.
I don’t think you need to be too concerned. When armed, the servo should move to the right compensate the motor torque. On my mini tri, it leans over to the right by 5-10 degrees when armed.
I’ve also discovered that it is hard to debug slow drifts in the servo when the tricopter is on the bench. This is because the accelerometers are not getting any real feedback, and so things tend to drift around. Once you take off, it should sort itself out.
To check if the servo is working correctly, leave the yaw stick centered and spin the tricopter around while armed (and props off). The servo should turn in the opposite direction to compensate the unwanted yaw.
Perhaps the UART2 pins are being used as a voltage reference for the ADC? Therefore, when you connect the minimOSD to UART2, it messes with the voltage reference, causing the ADC to read the incorrect current value. I don’t know, just thinking out aloud here…
Since David hasn’t published the schematics, this might be an issue that only him and Lauka can fix.
It works for me on Triflight 0.5 beta 3. As I raise the Tri off the desk, I can see the barometer altitude meter increasing in Triflight (can’t remember exactly which panel it was on).
I think you may need to upgrade your version of Triflight, as I’m not certain that the F3FC board was fully supported in 0.4.
Ok yes, you are correct. The tail servo centers at 1567, not 1500.
If I remember correctly, with the servo set to 1500, it was impossible to get the tail motor exactly centered, due to the size of the steps in the spline. So with the servo centered, the tail motor was a few degrees (I guess 8 degrees, in this case) from vertical.
Is there any downside to the servo center being 8 degrees from vertical? I can’t imagine how this would affect the flight performance. As long as the firmware knows where motor vertical is, and it can move at least 45 degrees in either direction, it shouldn’t matter, should it?
Stock mini tricopter with F3FC frame and the electronics kit (the one with the EMAX motors)
No FPV gear
Servo uses feedback wire.
Setup servo using David’s servo adjustment tool.
Tailtune was run on a day with only a very slight wind (only had to move the sticks twice). Tailtune took about 60 seconds. Tailtune was performed in angle mode.
TriFlight 0.5 Beta 3/RCE 1.12.0 May 17 2016 / 18:19:11 (e463d95)
tri_servo_angle_at_max = 400
tri_tail_motor_thrustfactor = 68
tri_tail_servo_speed = 290
Does the low value of 68 seem ok for the tri_tail_motor_thrustfactor? Everyone earlier in this thread was getting much higher values.