RPM resolution?

Development & General Chat for the superb openxvario project.

Moderator: rainer

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

Re: RPM resolution?

Post by mstrens » Sat Feb 22, 2020 10:51 am

Fine that it works.
Is the rpm value on the Tx a logical value?
In a previous post you said you got 6000 (when oXs sent 1000). Normally, it should be 60000 because TX converts the Hz to turn/min)

Normally oXs should not
- sent a dummy value to Tx for temperature
- generates messages for the serial monitor.

I added this for testing but it is not required for a final device (even if it does not bloc oXs).
If you want, I can make a version removing those 2 items.
In principe, I will just go back to the "official" version with the right config files.
Do you want it?


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

Re: RPM resolution?

Post by Endorphin » Sat Feb 22, 2020 11:04 am

mstrens wrote:
Thu Feb 20, 2020 7:56 am
......................................
If it is more than 5 V, it is safe to add a resistor and also 2 diodes (one conducting over voltage to 5V vcc and one negative voltage to ground).
How exactly are these diodes wired in?
"Over voltage"? Do you mean a zener diode?

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

Re: RPM resolution?

Post by Endorphin » Sat Feb 22, 2020 11:23 am

mstrens wrote:
Sat Feb 22, 2020 10:51 am
Fine that it works.
Is the rpm value on the Tx a logical value?........................
I am not sure what you mean by "a logical value", sorry.
...................
If you want, I can make a version removing those 2 items.
In principe, I will just go back to the "official" version with the right config files.
Do you want it?
Yes please.
If I should want a version of the code including vario (I have a BMP180 and a BMP280 baro pressure module), for another OpenXsensor for a sailplane, is it much more work for you to add it?
Or better still, is it a simple matter for you to show me, or to direct me to a tutorial to learn to do it myself?
Can it be added to this sensor without compromising the more valued RPM tacho?
If so, I could then use it for altitude.

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

Re: RPM resolution?

Post by mstrens » Sat Feb 22, 2020 11:25 am

--------------[diode --->----]------------[to 5V Vcc]
|
signal from motor----------[resistor about 10k]--------x--------------[Arduino D8]
|
|
Ground ----[ diode ------->-------]--------------------------------------[Arduino Ground]

I hope this is clear (display could depend of font size of your browser)
No need for zener.
Just use normal diode to clamp voltage.

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

Re: RPM resolution?

Post by Endorphin » Sat Feb 22, 2020 11:39 am

After studying your diagram for some minutes, I think I know how you have wired it up. But I am not at all sure, I must be honest.
I will do a small CAD sketch tomorrow (it is very late here).
Just to make sure I have it right.
I have a 6.6 volts LiFe powered CDI unit, so I will have to add a regulator in the + line anyway to reduce it to 5 volts. I have some 5 volt regulators in stock. No great problem.
More tomorrow.


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

Re: RPM resolution?

Post by mstrens » Sat Feb 22, 2020 11:46 am

Endorphin wrote:
Sat Feb 22, 2020 11:23 am
mstrens wrote:
Sat Feb 22, 2020 10:51 am
Fine that it works.
Is the rpm value on the Tx a logical value?........................
I am not sure what you mean by "a logical value", sorry.
...................
If you want, I can make a version removing those 2 items.
In principe, I will just go back to the "official" version with the right config files.
Do you want it?
Yes please.
If I should want a version of the code including vario (I have a BMP180 and a BMP280 baro pressure module), for another OpenXsensor for a sailplane, is it much more work for you to add it?
Or better still, is it a simple matter for you to show me, or to direct me to a tutorial to learn to do it myself?
Can it be added to this sensor without compromising the more valued RPM tacho?
If so, I could then use it for altitude.
By "logical", I mean the "expected" value. I had this question because you said you got 6000 on the TX instead of the expected 60000 (1000Hz converted in turn/min) with the version that sent fixed values.

You can use the same oXs device (arduino) to connect different sources of data (BMPxxx, RMP, measure voltages, current, ...)
The only thing to do is to edit 2 files (oXs_config_basic.h and oXs_config_advanced.h ) in function of the data you want to capture/transmit.

If you can't edit the files inside the arduino IDE (because you can't select them in the tabs), you can just edit the files with a very basic text editor (like notepad++). So do not use an advanced text editor (like Word) that could add extra control characters.
Avoid to declare in the config that you are using a BMPxxx sensor if it is not connected to the Arduino. It could block the arduino program because it would continuously try to communicate with the BMPxxx and it will wait for an answer from the BMP.

It can be a good exercise that you first try to edit the config files just in order to get the RPM now that you know it can works.
To do so, you have to:
- donwload the latest version of oXs available on github.
- unzip it somewhere
- replace just (only) the 2 config files in this unzip latest github version by the 2 files from my previous post (the version that works)
- select openXsensor.ino file in the folder having the unzip version from github.
- compile and flash and it should work.

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

Re: RPM resolution?

Post by mstrens » Sat Feb 22, 2020 11:48 am

Endorphin wrote:
Sat Feb 22, 2020 11:39 am
After studying your diagram for some minutes, I think I know how you have wired it up. But I am not at all sure, I must be honest.
I will do a small CAD sketch tomorrow (it is very late here).
Just to make sure I have it right.
I have a 6.6 volts LiFe powered CDI unit, so I will have to add a regulator in the + line anyway to reduce it to 5 volts. I have some 5 volt regulators in stock. No great problem.
More tomorrow.
No need to add a voltage regulator. There is normally a 5V pin on the arduino. It is the output of an internal 5V regulator (that already drop your 6.6V to 5V)

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

Re: RPM resolution?

Post by Endorphin » Sat Feb 22, 2020 12:00 pm

mstrens wrote:
Sat Feb 22, 2020 11:48 am
................................
No need to add a voltage regulator. There is normally a 5V pin on the arduino. It is the output of an internal 5V regulator (that already drop your 6.6V to 5V)
Ok, good.
I have also just read on the nano specifications sheet, that it can be powered by 7 to 12 volts. On the vin pin.

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

Re: RPM resolution?

Post by Endorphin » Sat Feb 22, 2020 8:33 pm

In my application of the tachometer version of the openXsensor will be connected to the tacho output of the CDI, not the hall sensor directly.
The hall sensor is already powered by the CDI battery and circuit.
Therefore, I will only have to connect the signal wire and the earth wire from the CDI to the arduino pin number D8.
No power positive connection required - both the board and the CDI are already independently powered.
The arduino nano from the receiver battery and the hall sensor from the CDI (separate) battery.
I don't want to risk crossing up the two power rails.

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

Re: RPM resolution?

Post by mstrens » Sat Feb 22, 2020 9:05 pm

There is no reason crossing up the power rails.
You just need a common ground.
In my schema, I do not use the power rail from the CDI.
When I say to connect a diode to Vcc it means Arduino Vcc which is generated from raw pin (with internal regulator) which is coming from you Rx power supply I presume.

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

Re: RPM resolution?

Post by Endorphin » Sat Feb 22, 2020 9:53 pm

mstrens wrote:
Sat Feb 22, 2020 9:05 pm
................................
When I say to connect a diode to Vcc it means Arduino Vcc which is generated from raw pin (with internal regulator) which is coming from you Rx power supply I presume.
I have no idea at all what you mean here Michael.
It would be risky to guess.

If I could view a simple circuit diagram, I would understand immediately.

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

First test on running engine.

Post by Endorphin » Sun Feb 23, 2020 1:09 am

I have installed the hardware module in my internal combustion two stroke powered tug plane.
When all powered up, the tx. found the sensor immediately.
All looking good..........so far.

Then when I started the engine, the tx. telemetry display did show RPM.
However, the figure indicated is completely erratic!
So much so, that it is of no use at all, except to indicated the engine is turning.

Given one guess, I would speculate that the arduino input @ pin number 8 requires a clean hall sensor feed. The arduino is becoming contaminated with hash from the CDI inverter.

Edit: I wonder if the addition of a small capacitor across the signal/earth of the CDI output would smooth this sufficiently to improved the stability?
I think it would, but do now know what size cap would be suitable. I know who to ask though.
Perhaps I will get around to fitting a second bracket to the propeller hub and mount a second hall sensor to drive pin 8.

To more or less confirm this speculation, I could mount a magnet on a disk to spin at engine RPM like Karl displayed at top of page 3.
My little magnetic stirrer shows only 13 to 17 RPM indicated, when powered by a 5 volt, then a 6 volt battery respectively.
(which should be proof enough I think?)

Comments?
Last edited by Endorphin on Sun Feb 23, 2020 1:19 am, edited 1 time in total.

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

Editing tutoring required.

Post by Endorphin » Sun Feb 23, 2020 1:16 am

mstrens wrote:
Sat Feb 22, 2020 11:46 am
..........................................
It can be a good exercise that you first try to edit the config files just in order to get the RPM now that you know it can works.
To do so, you have to:
- donwload the latest version of oXs available on github.
- unzip it somewhere
- replace just (only) the 2 config files in this unzip latest github version by the 2 files from my previous post (the version that works)
- select openXsensor.ino file in the folder having the unzip version from github.
- compile and flash and it should work.
That is what I have actually been doing. No problem there.

The problem that I have, and cannot find an answer by doing a google search, is how to actually do the edit to a sketch.
Much is said like" Just edit out............etc. etc."

But I cannot find the way this is properly done.
Please note, this is an exceedingly simple question, not one about writing code or any such advanced work etc.

Can you either explain, or direct me to a beginners tutorial where I might find such a basic explanation.

Thanks,

Jim.

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

Dedicated hall sensor solution.

Post by Endorphin » Sun Feb 23, 2020 4:04 am

Endorphin wrote:
Sun Feb 23, 2020 1:09 am
..........................................
However, the figure indicated is completely erratic!
..........................
I went ahead and made up a separate hall sensor mount on the opposite side of the engine to the CDI one.
This one is now connected directly to the arduino board, as in my bench set up testing unit. Power + from Vin, black to ground, and signal wire to D8.
When I run the engine, the RPM figure is now reasonably stable.
I had to change the settings in the Taranis X9D Plus telemetry from one blade to two. This fixed the problem of it reading around twice the actual readout.
I don't know why and how, but this fixed it.
This may not have been the most convenient solution to the erratic reading problem, but it has the advantage of maintaining separation of both electrical systems and batteries. The main receiver/servo power is from 2 x A123 cells, while the separate ignition battery is a 1700 ma/hr soft pack LiFe battery.

I went to check the RPM by comparing to my optical tacho. However, the batteries were flat.

In conclusion?
I now have a working openXsensor, telemetry linked tachometer.

Many thanks Michael, Karl and Joao.

It's been a long trip, but I have learned a lot and finally got this working.

Jim.

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

Re: RPM resolution?

Post by mstrens » Sun Feb 23, 2020 8:10 am

Fine that you continue the project and are finally happy.

If the values are erratic when using the CDI, it is probably due to some noise in the signal.
You could confirm this if you can look at the output signal from CDI with your scope. There are probably some high frequencies.
If so, I expect it would be possible to "clean" the signal using a RC filter (just add a capacitor between Grnd and D8 pin - so after the resistor coming from CDI signal.
You can test several cpacitors and look at the signal on D8 with you scope. This would allow you to find a right capacitor.
Note: the capacitor value depends also on the resitor. Filtering is defined by R multiplied by C.

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

Re: RPM resolution?

Post by Endorphin » Sun Feb 23, 2020 8:44 am

mstrens wrote:
Sun Feb 23, 2020 8:10 am
..........................
If the values are erratic when using the CDI, it is probably due to some noise in the signal.
You could confirm this if you can look at the output signal from CDI with your scope. There are probably some high frequencies.
If so, I expect it would be possible to "clean" the signal using a RC filter (just add a capacitor between Grnd and D8 pin - so after the resistor coming from CDI signal.
You can test several cpacitors and look at the signal on D8 with you scope. This would allow you to find a right capacitor.
Note: the capacitor value depends also on the resitor. Filtering is defined by R multiplied by C.
I have looked at the signal and it confirms what we both deduced about noise.
I could do the resistor and capacitor filter circuit. However, I now have it working nicely with a dedicated separate hall sensor. Better isolation between the CDI and the receiver power this way.

In due course when you have the final code ready for me, I will upload that sketch. However, there does not appear to be anything wrong with just using it as it is.
And I will not be flying this plane again until June.

Jim.

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

Inconsistent RPM values

Post by gastolectric » Wed Mar 04, 2020 3:08 am

Guys,

I'm wondering if anyone has experienced this phenomenon and has a solution.. (I posted this on RCGroups and Jim pointed me to this recent discussion thread)

I've wired up an Arduino nano with GPS and RPM sensors in my 30cc gasser.

The RPM pickup is via y-lead coming directly from the Hal pickup with GND and Signal wires connected on one leg, signal goes to D8 and GND goes to GND on the 'Digital' side of the Nano board which also provides GND to the GPS. (the other y-lead leg feeds through to the CDI input).

Admittedly the GND coming from the y-lead is on a separate battery to the Rx battery, so GND is being made common through the Nano ie. the Rx battery GND is connected on the 'Analog' side of the board.

In OpenXsensor RPM config I changed the number of magnets/pickups to 1 (default is 2), because there is only a single magnet on the flywheel.

When I fired up the engine and searched for new sensors on my Horus running OpenTx 2.3.4 it instantly found the RPM sensor (and GPS)

I then edited the RPM sensor in the telemetry page to adjust the 'ratio' value so that the sensor reading was matched with the optical handheld tacho. I had to set a value of 60 to exactly match and I was getting sensible RPM values in the range of around 1800rpm at idle and 7400 rpm and max throttle.

I had a switch set up to announce rpm values in flight and it was giving me max rpms around the 9500 mark (which is impossible) so I landed and re-checked with the opto tach and adjusted the ratio value on the radio down to 55.

It seemed perfect on the ground, but once in the air it started giving over-inflated values again.

Any ideas???

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

Re: RPM resolution?

Post by mstrens » Wed Mar 04, 2020 7:18 am

For RPM, oXs counts the number of pulses in an enlapsed time.
If the signal coming on pin D8 is noisy, the arduino can recognise some "noise" as a pulse and so report a to high RPM value.

In order to avoid (reduce) this, you can try adding a RC filter between the CDI and the pin D8.
Resistor is put between CDI and D8
Capacitor is put between D8 and GND.
R should be lower that 10k
C should be selected to get a cut off frequency of about 12000turn/min = 200hz.

You can also try to turn the wires on a ferrite core.

Put those component close to the arduino.
Hope it helps.

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

Re: RPM resolution?

Post by gastolectric » Wed Mar 04, 2020 7:47 am

mstrens wrote:
Wed Mar 04, 2020 7:18 am
For RPM, oXs counts the number of pulses in an enlapsed time.
If the signal coming on pin D8 is noisy, the arduino can recognise some "noise" as a pulse and so report a to high RPM value.

In order to avoid (reduce) this, you can try adding a RC filter between the CDI and the pin D8.
Resistor is put between CDI and D8
Capacitor is put between D8 and GND.
R should be lower that 10k
C should be selected to get a cut off frequency of about 12000turn/min = 200hz.

You can also try to turn the wires on a ferrite core.

Put those component close to the arduino.
Hope it helps.
I'll certainly give this a go but surprising that there is noise if I'm branching off the input from the Hal pickup to the CDI - this is an older CDI unit which doesn't have a tacho output lead??

Or am I missing some basic electronics understanding?

User avatar
jhsa
Posts: 19295
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: RPM resolution?

Post by jhsa » Wed Mar 04, 2020 10:55 am

In the air the airplane is moving, I believe it is normal for the RPM to increase.
Example. Try making a dive. The RPM will increase.

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

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

Re: RPM resolution?

Post by gastolectric » Wed Mar 04, 2020 8:38 pm

jhsa wrote:
Wed Mar 04, 2020 10:55 am
In the air the airplane is moving, I believe it is normal for the RPM to increase.
Example. Try making a dive. The RPM will increase.

João
Hi João,

Absolutely but when the telemetry is reporting 9500 rpm for a 30cc gas engine and you're in straight and level flight and not even at full throttle - something is amiss...

Yet on the ground pre-flight at full throttle it was reporting a reliable 7300-7400 rpm

User avatar
jhsa
Posts: 19295
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: RPM resolution?

Post by jhsa » Thu Mar 05, 2020 1:19 am

Oh, ok.. It wasn't at full throttle. I might have misunderstood that, sorry.. :)

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

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

Re: RPM resolution?

Post by gastolectric » Fri Mar 06, 2020 4:41 am

gastolectric wrote:
Wed Mar 04, 2020 7:47 am
mstrens wrote:
Wed Mar 04, 2020 7:18 am
For RPM, oXs counts the number of pulses in an enlapsed time.
If the signal coming on pin D8 is noisy, the arduino can recognise some "noise" as a pulse and so report a to high RPM value.

In order to avoid (reduce) this, you can try adding a RC filter between the CDI and the pin D8.
Resistor is put between CDI and D8
Capacitor is put between D8 and GND.
R should be lower that 10k
C should be selected to get a cut off frequency of about 12000turn/min = 200hz.

You can also try to turn the wires on a ferrite core.

Put those component close to the arduino.
Hope it helps.
I'll certainly give this a go but surprising that there is noise if I'm branching off the input from the Hal pickup to the CDI - this is an older CDI unit which doesn't have a tacho output lead??

Or am I missing some basic electronics understanding?
Hey Michael,

I've been doing my homework on simple low pass filters (https://www.electronics-tutorials.ws/fi ... ter_2.html) and deduced that my capacitor C value at fc=200Hz should be of the order of 100nF. Does it matter much the type of capacitor to be used eg. ceramic SMD type, or monolithic etc??

I should have read all the way down the article before spending inordinate amount of time re-arranging equations to solve for Xc so that I could then work out C - which I was assuming occurred for 5V input and only a drop to 4.9V out so was getting a C value of 22nF which means I've ordered the wrong parts :o

Anyways, hopefully get to put this to the test over the weekend and will report back on the outcome

Cheers
Greg

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

Re: RPM resolution?

Post by gastolectric » Sat Mar 07, 2020 8:38 am

Some feedback on the subject I raised:

I added a simple low pass filter to the signal line coming directly from the Hal pickup which splits via a y-lead before feeding the CDI. Without the filter the rpm values were erratic and over-reading in flight.

Knowing nothing about the subject I ended up with a formula fc=1/(2.pi.R.C) where R is the resistor value and C the capacitance value. Knowing that I needed an fc of around 200Hz (cut-off frequency) I re-arranged the formula to solve for C to determine the Capacitor to use with a 10K resistor. I ended up using a monolithic 100nF cap so actual fc value was closer to 160Hz x 60 equates to 9600rpm - or so I thought..

Wiring this up and taking it down to the field this morning I soon found that I was given a smooth reliable rpm reading till it reached 4200rpm and then the capacitor began dumping the signal and it would drop to zero rpm with increasing throttle.

Came home and replaced the 10K resistor with a 5K6 assuming that this should get me from 4200 to around 8000rpm before the capacitor begins dumping the signal to GND. Sure enough I now have a smooth reliable rpm signal all the way up to full rpm of around 7500rpm.

So my question is, why is the theoretical determination of the cut-off frequency out by a factor of 2??

Would appreciate your helping me understand this more...

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

Re: RPM resolution?

Post by mstrens » Sat Mar 07, 2020 8:57 am

First, a RC filter does not cut off 100% of the frequencies higher than a value. It is a progressive filter.


More important: the formula applies on a sinusoîdal signal but the signal coming from the Hall sensor is not sinusoïdal.
It is a digital signal and probably look more as a pluse. So it contains much higher frequencies.

That is the reason why it is a little a try and error process finding a good value for RC

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

Re: RPM resolution?

Post by gastolectric » Sat Mar 07, 2020 7:06 pm

mstrens wrote:
Sat Mar 07, 2020 8:57 am
First, a RC filter does not cut off 100% of the frequencies higher than a value. It is a progressive filter.


More important: the formula applies on a sinusoîdal signal but the signal coming from the Hall sensor is not sinusoïdal.
It is a digital signal and probably look more as a pluse. So it contains much higher frequencies.

That is the reason why it is a little a try and error process finding a good value for RC
That makes perfect sense, thanks.

So I guess for others with this sort of application a better starting point might be the formula fc=1/(4.pi.R.C). i.e doubling the cut-off frequency value compared with a sine wave equation. :mrgreen:

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

Re: RPM resolution?

Post by Endorphin » Sat Mar 07, 2020 11:50 pm

gastolectric wrote:
Sat Mar 07, 2020 8:38 am
........................... Sure enough I now have a smooth reliable rpm signal all the way up to full rpm of around 7500rpm............................
That's good Greg. Just to clarify; by how much does the reading increase when the aircraft is in the air after this mod? That is, when the engine is unloaded to some degree?
mstrens wrote:
Sat Mar 07, 2020 8:57 am
.....................................
More important: the formula applies on a sinusoîdal signal but the signal coming from the Hall sensor is not sinusoïdal.
It is a digital signal and probably look more as a pluse. So it contains much higher frequencies.
...........................
Yes.
That is why I chose to fit a second hall sensor dedicated to the openXsensor. This just happened to be convenient on my engine, but might not be so on others.
One of the advantages of this alternative is maintaining the total separation of receiver and ignition system power rails.
Attachments
OpenX hall sensor.JPG

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

Re: RPM resolution?

Post by gastolectric » Sun Mar 08, 2020 9:01 am

Endorphin wrote:
Sat Mar 07, 2020 11:50 pm

That's good Greg. Just to clarify; by how much does the reading increase when the aircraft is in the air after this mod? That is, when the engine is unloaded to some degree?
Hi Jim,
I haven't yet had the opportunity to test it in the air - just backyard trial to make sure the combo of resistor and capacitor was working to at least full rpm on the ground. though I would estimate by ear that the unloading would only add around 500rpm to the top end in flight. I'm away for a few weeks so will report back later in the month when I get back in the air

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

A vario now working!

Post by Endorphin » Mon Apr 06, 2020 9:02 pm

Greg,

I have managed to get a file compiled, uploaded and the openXsensor vario working!
Using BMP180 baro.

My only remaining dilemma is trying to figure out what I was doing wrong before!....................

Question:

How do I save this compiled file reliably for later use?
I might get a couple more arduino nano boards out and flash them while I have an functional file compiled. Label them and pack them away for later commissioning in a glider.
I seriously don't want to go through the hours, days, weeks to get another one working sometime in the future.

Jim.

Double post:
https://www.rcgroups.com/forums/showthr ... st44198053

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

Re: RPM resolution?

Post by kalle123 » Tue Apr 07, 2020 6:22 am

Hi Jim.

Good to see you back :D

About your question.

I keep it like that with all version of oXs over the years, I use it.

This is a pic of the folder oXs 8.2 with the main program openXsensor.ino and the additional files.
Bildschirmfoto_2020-04-07_07-29-58.png
I made an additional folder inside this oXs folder named BACKUP_config.h

And that is the FIRST thing I do when I unpack openXsensor-master.zip on my computer.

And then I copy oxs_config_basic.h and oxs_config_advanced.h into this folder and rename both 'clean' and untouched configuration files oxs_config_basic.h.default and oxs_config_advanced.h.default

That is a pic of what is inside this folder BACKUP_config.h here.
Bildschirmfoto_2020-04-07_07-27-38.png
You see the 'clean' and untouched configuration files, just in case, I made a mess with the configuration. I deleted the original config files and I have my backups :D Don't have to reinstall oXs to get a new start.

Then you see four pair of config files, where I added extensions to the names

This pair oXs_config_basic.h.MOUNTY.MS5611.ACS712_20.Frsky oXs_config_advanced.h.MOUNTY.MS5611.ACS712_20.Frsky

is for my model 'MOUNTY' with a MS5611 vario and an ACS712 20 A current sensor setup for Frsky.

If I need a configuration similar to that, I copy both files from folder BACKUP_config.h to the folder oXs 8.2, delete the 2 (messed up?) config files there (I have backups :mrgreen: ) and remove the additional information .MOUNTY.MS5611.ACS712_20.Frsky

Easy like that, Jim.

This is folder BACKUP_config.h in my an old version of oXs (ver.7). We only had one config file at that time.
Bildschirmfoto_2020-04-07_08-14-27.png
One 'default' and 13 'special' ...

Jim, that is my way to handle that. Works ok over the years for me. But you have to decide and find your way.

I have a X9D and a X9D+ here. One on 2.1.9 and one on 2.2.4. But DEBIAN Testing is not supporting companion 2.1.9 and I plan to change from DEBIAN Buster to Testing. One full day upgrading 2.1.9 to 2.2.4 and then getting both RX in one companion and keeping the models, settings and logs separate ....... :roll:

br KH


Post Reply

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