@jinchengde that GPIO_ISR internal error is triggered when we see more than 10k pulses in 100ms, so a rate of 100k pulses per second, which would be 360000 RPM. The reason we check for this is that interrupts take priority over all threads, so if we get too many interrupts per second then we get starved of CPU for flying the heli. I chose 10k per 100ms as at that level we are using just one or two percent of the CPU for interrupt handling, and it is a level beyond any reasonable RPM value. If we didn’t have this check and the number of pulses per second went over about 700k/second then you would fall out of the sky as there would be no CPU left to fly with.
There are a few possible reasons this is happening:
it could be a short lived transient from this sensor
it could be that the sensor is missing a pullup or pulldown to prevent the pin from “floating”. A floating pin can generate a lot of interrupts from electrical noise
it could be that we were getting this issue in 3.6 and the errors were being suppressed using the simple filter we have in the RPM code (which rejects pulses that are too fast).
maybe our software pullup/pulldown settings are different in 4.0 than 3.6? If you tell me what flight controller this is and what pin you are connected to then I can check
Ideally we’d get a trace (eg. oscilloscope trace) of this pin when the problem happens.
I finally managed to get the align sensor working for the rpm… now the rpm is being displayed in the gcs… next is to switch on the Governor mode.
Thanks guys… will keep you posted… but ya the futaba sensor is def a no no till it’s rectified…
Sorry for the late reply.
I think I had a faulty sensor which I removed from my old helicopter. I ordered a new one and it’s working.
I installed a aerospire gov sensor on another Heli, and that’s working too…
@ChrisOlson see post 28 in this thread from @tridge. He had thrown out some ideas on what could be causing the problem but needed some one with an oscilloscope that could help troubleshoot. If you could support this trouble shooting, I’d really appreciate it. I don’t have an oscilloscope and I am not seeing this issue on my controllers.
@tridge what exactly do you need to see on the oscilloscope. What would be the setup in order to do this test? Here is the post on what Chris found.
@tridge this is serious bug that will impact tradheli users that want to use the existing governor in 4.0 and the improved governor that Chris Olson has been work on for 4.1.
RPM sensor is working (led changes status upon each magnet passage) but reading on the flight control is not.
If rpm sensor is powered instead by external 5V power supply with ground and signal connected to flight control, rpm reading in the flight control works.
Sensor itself outputs 3.3V level signal.
Additionally, we noticed on this flight control that the servo rail voltage is not logged:
Since all modern digital tach’s are pulse train, what is the thoughts on implementing a pulse train frequency counter in the Heli RSC specifically for the governor and rpm functions in heli, and not use the RPM library with an interrupt? The RPM library was originally written only for logging and was called from the main code at 10Hz. I increased that to 40Hz for the governor, but it is still not ideal and really needs to run at 400Hz (or main loop rate) with the rest of the governor code.
no Chris, it’s connected to pin 63, I followed this:
Also, we have a fuel flow sensor connected to pin 62. They both work fine if powered by a 5V source, otherwise if powered by the servo rail (HV) straight the autopilot doesn’t read anything.
Both sensors are rated for HV power supply, as side note.
That did not work to reduce the drive voltage to 5V on the sensor. Further, I do not get an rpm signal from the RPM library with the Pixhawk 3 Pro on ChibiOS with Copter 3.6 either. It only works with NuttX.
Chris, sorry to hear that. On our Drotek Pix3Pro it works fine with 4.0.5 (using the same sensor as above linked). Furthermore, on the pix3pro it is powered directly by servo rail which runs on HV.
In our scenario, only the CUAV Nora shows no readings if sensors are powered directly from servo rail (but sensors are working, we checked with a logic level analyzer).
Yeah, I don’t know. The new governor I wrote needs a reliable speed signal or it’s going to be considerably more unpleasant than the old code with a flaky sensor. Hall effect sensors are pretty simple and reliable devices, without them your car engine won’t even run. The fact that it works on NuttX tells me the hardware is fine. The fact that it seems to be problematic otherwise tells me it’s probably not going to be a good idea to put the new governor in 4.1 without a different and more reliable method of speed measurement.
I’m using the Drotek Pixhawk 3 Pro as well with Aliexpress Hall effect sensor with 10K resistor between 7V to signal (Pull up) and I’m getting the RPM1 reading.
I still having problems to make the governor to engage.
I followed Chris instructions from the thread bellow, but I’m probably missing something.
Hi ., all
My case is CUAV V5 Nano with hall effect sensor like a 3144 which need +5V to drive , Can I get +5V from AUX3 (+ - S) and sent output to “S” pin of A3 , or I need to link another +5V from another or external or RC pin please.
Measuring A3, I can’t found any volt from A3 (+ -) but found 3.3v between “-” and “S” please.
Thanks you
Zicroff
@bnsgeyer Yes , at servo rail I have put 8.4volt from buck convertor for hv servo , but for hall sensor need 5v , just confuse about 5v source from AUX or not please
About 2 years back I set up a big gasser and I used GY701 sensor and the governor and it worked great. I see that you are trying to use the autopilot as as governor so this might not be relevant to you. But for me, it worked great, and I can see the governor was able to quickly recover the blade speed after a sudden control of the helicopter.
