That would explain it 
Telemetry works when connected to Telem2.
I might be able to use the debug port
There are several solutions I can think of:
- we can change in the hwdef.dat to add the UART7 debug port to UART_ORDER list, and add a hal.uartG and SERIAL6, so we allow for 6 configurable ports on pixracer.
- we can make the FrSky_INV control pin be user configurable. I’ve opened a PR for that just now (see HAL_ChibiOS: allow FrSky_INV to be controlled as GPIO by tridge · Pull Request #8700 · ArduPilot/ardupilot · GitHub). That will allow RELAY_* settings to control if FrSky port is inverted or not
- we could add a BRD_* parameter for controlling FrSky invert
I’ve read the documentation for the RELAY* parameters here http://ardupilot.org/plane/docs/parameters.html#relay-parameters and looking at the schematic here: https://pixhawk.org/_media/modules/pixracer-r14.pdf it is not clear to me how those parameters would need to be set for this use case.
The RELAY parameters can be used to set any GPIO. For example, if you apply my PR and then set this:
RELAY_PIN=78
then from MAVProxy you could do:
relay set 0 0
that will bring the relay pin low. If you do:
relay set 0 1
then it will bring the relay pin high.
You can also set RELAY_DEFAULT to the value at boot.
The relay system isn’t really meant for controlling things like inverting a uart, it’s meant for things like bottle drop releases, but it can be used for arbitrary GPIO control.
Then we can implement a better method, perhaps with a BRD_* parameter if this works for you.
So should the relay be on or off? Looking at the schematic, the pin connects to pins 1 and 5 on the inverter chip. However i don’t know if setting RELAY_DEFAULT to 0 pulls pin 69low or high.
Setting REPLAY_DEFAULT to 0 works 
thanks for the advice.
1 Like
The GPIO pin defaults HIGH, so LOW is the value you want.
When a GPIO line in hwdef.dat doesn’t specify LOW or HIGH then HIGH is the default
Anybody know how exactly the reported RPM is calculated?
Is it the rpm of the magnetic field and needs to be divided by half amount of motor poles?
Is is rotations per minute or per second?
It seams to be way off, mine showing about 500 where it should be about 6500 on a 14 pole motor.
Does BlHeli_32 require pole count to be manually configured via the configurator application? I know Flyduino KISS reports RPM based on onboard -configured pole count.
(I had tried using KISS ESCs - as telemetry format looked identical - before realizing that they explicitly weren’t supported just yet)
How should the ESC know the real rpm from the field rotation when he does not know the pole count…? There is no param for that yet in AP AFAIK.
My bad, BLHeli_32 configurator (the desktop application) doesn’t seem to have an internal setting for pole count (just motor timing). KISS ESC telemetry has a pole count value you can program onto the ESC to report the real RPM. My apologies.
So I got around to testing a Wraith32 Metal v2 on a PixRacer, and after some struggling I managed to get telemetry working.
@palm369 Regarding value fields, it seems that the reported values are multiples of their actual values - likely to represent floats more efficiently as integer fields over telemetry. That said, I seemed to be getting reasonable RPM values . . .
I did run across an issue, however. Once I got the Wraith32 running my low- KV motor (it didn’t want to startup a 475kv KDE motor) by turning off low-RPM protection, I stopped getting BLHeli Telemetry. I tried swapping out PixRacers, to no avail.
Are instances of sudden telemetry failure on the ESC common? It seems odd that only that part of the ESC functionality would fail.
I wrote the original code that reports BLHeli_32 RPM on the OSD. It’s currently hard-wired for a 14 pole motor, which is obviously a crude hack. Tridge and I acknowledged at the time that a # of motor poles parameter was needed to accurately report RPMs. Yes, you should multiple the BLHeli-reported RPM number by the number of poles on your motor.
I hope our v1.0 hack doesn’t cause any smokin’ holes. 
Kelly
What OSD? You mean the values in Mission Planner?
Thats weird.
I also noticed that I only get telem data once a second in the log even I set the rate to 10 hz. I also set up every possible protection setting because my motors do desync otherwise :S
The OSD that is integrated with the Next Generation flight controllers based on STM F4 and F7 embedded processors. Search for Matek F405-Wing as one example. The OSD code displays ESC temperature, current draw, RPMs, Etc. Great to have detailed drivetrain stats in real-time in the goggles.
Kelly
I just played a bit with BLHeli passthrough and latest Copter 3.6-rc11. The Pass-through mode works perfectly with a PH2.1, and an Aikon BLHeli_32 4in1 ESC.
However, is there anybody who got BLH pass through working with BLHeli_S? If I try that, there is no successful communication to the ESCs (random beeping of ESCs, random error messages of BLH suite).
1 Like
Hi all,
I have got this working nicely, both pass through and telemetry. However I am getting a odd limit in RPM. It like I only have 10% throttle. I’m not sure if its a Arducopter setup issue or a BLHeli issue. I am using the same multistar 51A as in the demo.
At full throttle I should be at 8000 rpm or so not 500. It is not throttling up enough to take off. Have tried Dshot150 and PWM both with the same results.
Any ideas?
Hey!
Had same issue. Disable low rpm power protect on blheli32 suite. 
1 Like
The original issue was due to some odd thing that went away when I flashed master, the rpm limit was with no props on. Once I was on master I could then throttle up to full with no props but not with then I discovered the low rpm power thing so I could get full with props. Flys nicely know.
I’m still not sure what was going on originally but what ever it was has now been fixed.
1 Like