RPM resolution?

Development & General Chat for the superb openxvario project.

Moderator: rainer

Endorphin
Posts: 154
Joined: Tue Jan 26, 2016 7:46 pm
Country: Australia

First submission. GPS only openXsensor

Post by Endorphin » Sun May 24, 2020 12:44 am

kalle123 wrote:
Fri May 22, 2020 8:53 am
....................................
working GPS oXs
.................................................
I am posting this one first. I will post all three separately, to reduce potential for confusion (on my part as well as for the reader).
You could also try the #define DEBUG thing with the NOT working baro + GPS oXs yourself.
.........................
I have no knowledge of how to start with that. I figure it will be better to wait for further information about that before (probably) compounding the problem and increasing resulting confusion/mis communication etc.

Supplementary information (may or may not be relevant):

Taranis X9D Plus on OpenTx version 2.2.3
Companion version: 2.2.3
Baro BN-180
Computer operating system: Linux Mint 19.3
Arduino IDE version: 1.8.12
Barometer reading at time of testing: 1009 kp.
Atmospheric temperature 18 deg. C
Google Earth coords for same location as test above: 30.24 S 152.56 E to the nearest minute.
Arduino nano clone board used. (ex Banggood).
Proper old fashioned lead solder used throught!

I sincerely hope I have provided sufficient information.
Please let me know if I have not.

I will do the BMP280 Vario only test tomorrow.

Jim.
Attachments
GPSdisplay.JPG
BMP280_GPS29042020.ini.tar.gz
(284.24 KiB) Downloaded 33 times
Last edited by Endorphin on Mon May 25, 2020 1:28 pm, edited 2 times in total.


User avatar
kalle123
Posts: 834
Joined: Sat Mar 29, 2014 10:59 am
Country: -
Location: Moenchengladbach

Re: RPM resolution?

Post by kalle123 » Sun May 24, 2020 6:23 am

BMP280_GPS29042020.ini.tar.gz
Jim, this is now your NOT WORKING BMP280 + GPS oXs ??

br KH

Endorphin
Posts: 154
Joined: Tue Jan 26, 2016 7:46 pm
Country: Australia

Working GPS only.

Post by Endorphin » Sun May 24, 2020 7:57 am

kalle123 wrote:
Sun May 24, 2020 6:23 am
BMP280_GPS29042020.ini.tar.gz
Jim, this is now your NOT WORKING BMP280 + GPS oXs ??

Karl,
Please read my post above.
I have quoted your words, exactly as you asked. The quote at the top of my post clearly indicated: "working GPS oXs".
Picture of the displayed coords attached.

Jim.
Last edited by Endorphin on Sun May 24, 2020 8:34 am, edited 1 time in total.

Endorphin
Posts: 154
Joined: Tue Jan 26, 2016 7:46 pm
Country: Australia

Picture of GPS display in my Taranis X9D Plus

Post by Endorphin » Sun May 24, 2020 8:24 am

Please find picture attached of my working GPS.
I forgot to attach it to the post above. I have edited the post to include it.
Attachments
GPSdisplay.JPG

User avatar
kalle123
Posts: 834
Joined: Sat Mar 29, 2014 10:59 am
Country: -
Location: Moenchengladbach

Re: RPM resolution?

Post by kalle123 » Sun May 24, 2020 9:06 am

So PROBLEM SOLVED, at least for me ;)

cu KH


Endorphin
Posts: 154
Joined: Tue Jan 26, 2016 7:46 pm
Country: Australia

Re: RPM resolution?

Post by Endorphin » Sun May 24, 2020 9:47 am

kalle123 wrote:
Sun May 24, 2020 9:06 am
So PROBLEM SOLVED, at least for me ;)
I will do the Vario / BMP280 openXsensor test tomorrow and take a video of it working.

Endorphin
Posts: 154
Joined: Tue Jan 26, 2016 7:46 pm
Country: Australia

Video of Working openXsensor BMP280 Vario.

Post by Endorphin » Mon May 25, 2020 12:57 am

Karl,
Please note: this is a Working Vario.
I am using the same board, same sketch as the previous working GPS test. It's working, but not very sensitive. I am ordering a MS5611 to use instead of this BMP280 baro.

https://vimeo.com/422278590

Supplementary information (may or may not be relevant):

Taranis X9D Plus on OpenTx version 2.2.3
Companion version: 2.2.3
Computer operating system: Linux Mint 19.3
Arduino IDE version: 1.8.12
Barometer reading at time of testing: 1009 kp.
Atmospheric temperature 18 deg. C
Google Earth coords for same location as test above: 30.24 S 152.56 E to the nearest minute.
Arduino nano clone board used. (ex Banggood).
Proper old fashioned lead solder used throught!

I sincerely hope I have provided sufficient information.
Please let me know if I have not.

Endorphin
Posts: 154
Joined: Tue Jan 26, 2016 7:46 pm
Country: Australia

Success!

Post by Endorphin » Mon May 25, 2020 1:48 am

I now have both functions working on the same arduino nano board.
BN180 GPS and BMP280 baro Variometer.
Same sketch as I have been trying for weeks now, before this, without success.
The only thing I have done differently is to power the GPS sensor off 3.3 volts and not 5 volts, as previously.

Wow!
This has been a long haul.
Thanks to all, especially Karl.

Jim.

Endorphin
Posts: 154
Joined: Tue Jan 26, 2016 7:46 pm
Country: Australia

Faulty FrSky D8R-11 Plus rx.

Post by Endorphin » Thu Jun 04, 2020 8:27 pm

A short explanation for at least some of my travails in getting an openXsensor working.
I discovered that the receiver I was using to test it was faulty.
Very poor range and intermittent RSSI.

My apologies for no picking this up earlier.

Jim.

User avatar
gastolectric
Posts: 46
Joined: Wed Jan 09, 2013 7:59 pm
Country: Australia

Re: RPM resolution?

Post by gastolectric » Mon Oct 12, 2020 9:06 pm

Hi guys,

I've been moving house, career change etc the past few months - dusted off my gasser this weekend to find that my RPM sensor isn't playing ball...

When I run the engine on the ground I get perfect, sensible read outs on my Horus all the way through the rpm range but the moment she is airborne the readings are all over the place - tried turning the filter function off in the Horus setup but this understandably only made it worse. With the filter on it seems to give sensible readings up to about 90% throttle but when I punch to full throttle I lose rpm values and telemetry reports zero rpm

Anyone experienced this in the past and/or any suggestions

I'm taking the pickup directly from the Hal sensor line to the Rcexl ignition unit via a y-lead that feeds into an Arduino nano that also has a gps unit connected to it (this is an old Rcexl that doesn't have a separate tacho line out)

Cheers
Greg

mstrens
Posts: 1411
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: RPM resolution?

Post by mstrens » Tue Oct 13, 2020 7:52 am

You can try to filter the value on oXS side.

In the .ino file you currently have
sport_rpm.value = RpmValue ;

Change it to
//sport_rpm.value = RpmValue ;
sport_rpm.value += 0.1 * ( RpmValue - sport_rpm.value ) ;

You can then adapt the "0.1" parameter.
With 0.1, it means that the new value is the previous one + 10% of the difference with the new value.
Decreasing the parameter increases filtering.
Parameter = 1 means no filtering at all.

User avatar
gastolectric
Posts: 46
Joined: Wed Jan 09, 2013 7:59 pm
Country: Australia

Re: RPM resolution?

Post by gastolectric » Tue Oct 13, 2020 9:46 am

mstrens wrote:
Tue Oct 13, 2020 7:52 am
You can try to filter the value on oXS side.
Thanks Michael,
I'll give this a go and let you know how I get on, though I'm also reminded wading back through this thread that because I'm only losing resolution above 90% throttle it may just be the rc filter that needs tweaking because I'm reaching the threshold where the filter loses efficiency and starts dumping noise...

User avatar
kalle123
Posts: 834
Joined: Sat Mar 29, 2014 10:59 am
Country: -
Location: Moenchengladbach

Re: RPM resolution?

Post by kalle123 » Tue Oct 13, 2020 10:32 am

gastolectric wrote:
Mon Oct 12, 2020 9:06 pm
When I run the engine on the ground I get perfect, sensible read outs on my Horus all the way through the rpm range but the moment she is airborne the readings are all over the place
That sounds strange. And when the plane is back on the ground, everything is fine again?

On the ground, did you move all servos?

br KH

User avatar
gastolectric
Posts: 46
Joined: Wed Jan 09, 2013 7:59 pm
Country: Australia

Re: RPM resolution?

Post by gastolectric » Tue Oct 13, 2020 6:59 pm

kalle123 wrote:
Tue Oct 13, 2020 10:32 am

That sounds strange. And when the plane is back on the ground, everything is fine again?

On the ground, did you move all servos?

br KH
Admittedly on the last flight I turned off the filter function on the rpm telemetry output on my Horus so that would explain it being jumbled throughout the rev range. With the filter on it offers sensible data until I go beyond 90% throttle so I suspect the rc filter at this stage but will play with servos while on the ground to rule that out too

And yes land and run it up on the ground and no issue, can only think that in flight the engine is reaching a higher Max rpm and therefore going beyond the rc filter threshold where on the ground these rpms aren't coming into play.

Carbo
Posts: 443
Joined: Fri Aug 02, 2013 6:55 pm
Country: Germany
Location: Freinsheim RP

Re: RPM resolution?

Post by Carbo » Wed Oct 14, 2020 8:10 am

A 100pF ceramic cap connected to (D)8 and GND solved a similar issue for me. Interference was presumably caused by RX telemetry. OpenTX filtering should not be neccessary imo.

User avatar
gastolectric
Posts: 46
Joined: Wed Jan 09, 2013 7:59 pm
Country: Australia

Re: RPM resolution?

Post by gastolectric » Wed Oct 14, 2020 8:32 am

Carbo wrote:
Wed Oct 14, 2020 8:10 am
A 100pF ceramic cap connected to (D)8 and GND solved a similar issue for me. Interference was presumably caused by RX telemetry. OpenTX filtering should not be neccessary imo.
Awesome thanks Carbo

User avatar
gastolectric
Posts: 46
Joined: Wed Jan 09, 2013 7:59 pm
Country: Australia

Re: RPM resolution?

Post by gastolectric » Sun Oct 18, 2020 8:30 am

Following a weekend of field testing I can report back that a combination of factors were involved:
  • I swapped out the 5K6 resistor in the rc filter for a 4K7 which extended the rev range (100nf cap)
  • I used mstens suggested formula adjustment above to curtail the data output starting with cutting back to a value of 0.1 (10%), but settled with 0.2 (20%) which offered slightly better resolution without having to use the filter feature on OpenTx - could possibly even have upped this further to 25-30%
**Change it to
//sport_rpm.value = RpmValue ;
sport_rpm.value += 0.1 * ( RpmValue - sport_rpm.value ) ;

Both these changes resulted in a stable readout throughout the rev range both on the ground and in the air - but the mystery remains - on the ground (and comparing with a tacho) the rev range readout was accurate from idle around 1800rpm to max throttle giving 7500rpm, but in the air the rev range shifted to around 2200 in a low throttle stall, to around 9500rpm gunning full throttle in a dive and a steady 9100 in straight and level flight.

So I swapped out the nano board for a FrSky rpm sensor from another plane and sent it back up for a few full throttle passes - low and behold it was also reporting 9000-9500rpm. So I've resolved to let it be, that this must be one sweeeeeetly tuned 30cc gasser

Though there was one comment from the pits worth considering : that the Hal sensor may be 'double sparking' in flight ie picking up a pulse as the magnet moves towards the sensor as well as when it moves past - though you'd expect this to double the read out - and given that we've chopped the data throughput to just 10% without any seeming change to max rpm in level flight - unless I really need to throttle it further to say 1% just to see if over an extended full throttle pass I'm still getting such high end rpms.

But having said all that, the FrSky sensor that was running in my 50cc bipe seemed to report a reliable max 7000rpm both on the ground and in the air, so back to thinking I'll just leave it be (both sensors behave alike on the ground and in the air in my Sbach) - and I really only need the sensor to report Zero rpm in the event of a dead stick with other planes in the air and not being able to hear it soon enough to head straight for the runway..

Thanks again for all the generous support on this forum.

Cheers
Greg

mstrens
Posts: 1411
Joined: Fri Dec 27, 2013 7:49 pm
Country: -

Re: RPM resolution?

Post by mstrens » Sun Oct 18, 2020 9:09 am

thanks for the feedback.


Post Reply

Return to “OpenXVario - an open source vario supported by the open source firmwares!!”