openrcforums

I have no idea of what it would require to DIY a speed sensor and I do see one for $65. Being that a open source altimeter/vario, electric RPM sensor, and S-Port voltage sensor were designed by forum members, I wonder if a speed sensor could be next?
Hopefully the price would be lower to build.
Thank you
SM


Sent from my iPod touch using Tapatalk, small keys and a big finger.

A link on this speed sensor ?

There are a few threads about adding that capability to OpenXsensor already, but I don't think anything went very far yet.

Speed sensor at Aloft Hobbies: http://www.alofthobbies.com/n2-airspeed.html

Paul

Thanks Paul. The sensor Aloft has is a little high if I want more than one. I just wanted to ask the DIYers before buying one.


Sent from my iPod touch using Tapatalk, small keys and a big finger.

It's too high for me as well, but I would like a reasonably priced sensor.

Paul

Who wouldn't??

With most Frsky sensors priced below the GPS $40-45 price, the speed sensor price is out of my comfort zone for now being a sport flyer. That may change if the reviews are really good.
Not excessive for a turbine or highend speed plane however.

The one we use with Arduplane is a bit cheaper and readily available. I'm not sure about it's relative acuracy compared to the others mentioned but it seems to do the job.

https://store.3drobotics.com/products/a ... mpxv7002dp

If it works with opentx I'm ready to try one. The D series receivers have the analog inputs do maybe the code could be patched.
Any coders reading this thread?

Depending on the actual response, er9x/ersky9x may be able to handle this already, just use a Scaler.

Mike.

Mike, I think we will need some good tutorial on the scalers. I think they are a bit too mathematical for people to understand. At least for me, but maybe I am Just dumb

João

Sent from my GT-I9195 using Tapatalk

The problem is they ARE mathematical, they apply a formula to a value to get a different value!

I'll see what I can do.

Mike.

Thanks Mike.. when it is only dividing or multiplying I think I get there.. But when involves multiplying, dividing and offset among others, I think my brain cells short circuit

João

MikeB wrote:Depending on the actual response, er9x/ersky9x may be able to handle this already, just use a Scaler.

Mike.

Apparently the sensor outputs a value 0.5 to 4.5v proportional to the pressure differential between the two pipe inputs.

I don't believe the accuracy of an 8-bit conversion is enough to be even remotely useful.

Not being my area of knowledge, any idea what the $65 Aloft sensor accuracy is?
Is it supported well enough to be useful? It's an interesting gadget to own if it works well. I've always wondered how fast some of my planes go.


Sent from my iPod touch using Tapatalk, small keys and a big finger.

I would have thought that a speed sensor based around the openXvario would do the job. In fact if you put the vario sensor (or the whole lot) into a small box that is airtight apart from a tube leading into it that is pointing out of the front of the aircraft would be all you need for the vario to become a speed sensor.

The vario has the Kalman filter that helps remove instant variations (or not depending how you set the filter) and the speed readout will appear as negative feet on the transmitter. To roughly calibrate the sensor, you can use your car speedometer for that purpose. Just hang out the sensor whilst driving along taking note of the speed and the altitude over a range of speeds. That will give you a set of conversion figures. So let's say the transmitter shows minus 20 feet (or whatever Metres) which indicated say 20MPH then you know that one foot is equal to one mile per hour... Yes you could convert the altitude to Knots if you so wish. Knots makes a lot more sense while flying.

The above takes no account of the air density, so perhaps another bit of software in the openXvario could be written to compensate for that, as from what I recall the MS5611 does give you an absolute air pressure density along with local variations. But that IMO is getting picky unless you are considering going above 10,000 feet or more. You could also say that there is no compensation for side slips or skids.. I will leave that one to others to ponder from their armchairs.

Almost forgot.. A positive altitude figure means you are going backwards.

Would this sensor be acceptable then?

mpjf01 wrote:Would this sensor be acceptable then?

Meas Spec MS4525DO Series.pdf

Yes,
I think this is a good sensor for airspeed measurement.
It exists with several ranges.
Best would probably be 4525DO-DS5AI001DP.

It would normally be possible to let it be supported openXsensor if some code is added to openXsensor.

Best would probably be 4525DO-DS5AI001DP.

FWIW the price for the sensor is about $25 USD. But it has both digital and analog interfaces, so a bit of something for everyone.

Another way to skin this cat:
The $42 USD retail ($33 at HobbyKing) EagleTree Airspeed sensor is ready to use and includes the pitot tube. It is self contained -- the internal MCU does all the dirty work and it spits out formatted speed values (no difficult math). Data is available via the EagleTree Third Party Mode's digital i2c interface. So the host connection (arduino or any other decent MCU) can use its i2c port for communication.

Product Details:
http://www.eagletreesystems.com/index.p ... duct_id=63

Host Details:
http://www.eagletreesystems.com/Manuals ... or-i2c.pdf

- Thomas

thomas9x wrote: Another way to skin this cat:
The $42 USD retail ($33 at HobbyKing) EagleTree Airspeed sensor is ready to use and includes the pitot tube. It is self contained -- the internal MCU does all the dirty work and it spits out formatted speed values (no difficult math). Data is available via the EagleTree Third Party Mode's digital i2c interface. So the host connection (arduino or any other decent MCU) can use its i2c port for communication.

Product Details:
http://www.eagletreesystems.com/index.p ... duct_id=63

Host Details:
http://www.eagletreesystems.com/Manuals ... or-i2c.pdf

- Thomas

Anyone interested in making this part of openXvario code?
For $33 with pitot tube included, and just a 'plug in' on openXvario sounds like a good idea to me.

If someone does add this to Openxvario (and it would be great if so) and if the Eagletree sensor is the chosen one, is there a way to use the data from the Eagletree sensor without it having to be in third party mode please? Getting the sensor into 3rd party mode seems to require the purchase of an additional eLogger from Eagletree for around $50.

I would suggest using a 4525DO-DS5AI001DP sensor.
I think that this sensor can provide a higher precision for small speeds. This would be useful when airspeed is used too to calculate dTE (for a vario with total energy).
If someone requires very high speed measurements, it would be possible to use another sensor from the same serie with the same software.

If someone provide me a 4525DO-DS5AI001DP sensor, I can try to write the code in order to let OXS measure airspeed and dTE (when associated to a MS5611 vario sensor).

mpjf01 wrote:If someone does add this to Openxvario (and it would be great if so) and if the Eagletree sensor is the chosen one, is there a way to use the data from the Eagletree sensor without it having to be in third party mode please? Getting the sensor into 3rd party mode seems to require the purchase of an additional eLogger from Eagletree for around $50.

yep, I missed that part.
or someone knows a seller would configure the senor with 3rd party mode for their customer prior shipping out.

mstrens wrote:I would suggest using a 4525DO-DS5AI001DP sensor.
I think that this sensor can provide a higher precision for small speeds. This would be useful when airspeed is used too to calculate dTE (for a vario with total energy).
If someone requires very high speed measurements, it would be possible to use another sensor from the same serie with the same software.
If someone provide me a 4525DO-DS5AI001DP sensor, I can try to write the code in order to let OXS measure airspeed and dTE (when associated to a MS5611 vario sensor).

I just checked Digikey sells that sensor for 25.00 and shipping in US is usually 6-7.00 in US. that adds to 32.00 (without pitot tube and the labor to make one )
How much precision we are talking about here compared to the Eagle tree?

PS:
mstrens: My head just partially returned from a major family event , but I do have all the parts for OpenXvario now. Will ask for your code once I got everything ready to go.

The easiest and cheapest solution from a hardware viewpoint is Eagletree provided that it is possible to get around the need to put it in 3rd party mode. The following was posted in the sensor comments on the Hobby King site, and gives hope of that

"The paparazzi autopilot has code to use this sensor in native mode. It can be attached to an Arduino nano, and connected to the Taranis S.port. You just need to interface with the S.port code available on the OpenXVario forum. I already created an S.port interface for the Eagletree GPS. Adding this using the paparazzi code should be easy."

There is also discussion of the matter on RCG here

http://www.rcgroups.com/forums/showthread.php?t=1118096

The provision of an I2C interface option to support Eagletree may also allow the use of the 3DR digital sensor, also comes with pitot etc. But that's more expensive.

One benefit of Eagletree may be the digital readout of highest speed attained. This could be checked with the reading obtained by the openxsensor for calibration purposes. I'm not sure though whether this works in 3rd party mode. I have a sensor but no way to get it into 3rd party mode to check.

I don't know which kind of sensor is used by Eagletree in their airspeed sensor.
I expect they use an analog sensor being read by the ADC of a microprocessor.
I have no idea of the precision they can reach but it should not be optimum for a dTE vario because it is able to measure a very high airspeed (so precision for low speed should be limited).
I presume that they use a quite old type of sensor.

A similar solution could be used by OXS using a sensor like this
https://store.3drobotics.com/products/a ... mpxv7002dp.
In this case, there is no need for a I2C interface.
Still the precision will not be optimal because:
- the ADC performed by Arduino OXS will be only a 10 bits conversion
- it can be impacted by noise on Vcc

3DRobotics has also a digital sensor which use the 4525DO-DS5AI001DP sensor that I proposed.
I think that this sensor is much more accurate because
- it uses internally a ADC on 14 bits
- it has normally a better temperature compensation.
The kit provided by 3DRobotics is more expensive (55) than the EagleTree sensor but it is also possible to buy just the 4525DO-DS5AI001DP sensor for about 25$ and to build his own pitot tube.
Here the link to the digital 3DR sensor:
https://store.3drobotics.com/products/p ... sensor-kit

Here another link that seems to confirm what I expected : the digital sensor works better than the analog one
http://diydrones.com/profiles/blogs/adv ... 657&page=5

The specifications for the Eagletree sensor supplied with the unit state that it is capable of measuring airspeeds of between 9mph to 350 mph (15kph to 563kph)with 1mph (1kph) resolution. Precalibrated with advanced temperature compensation. This is a wider speed range than the 3DR digital sensor (up to 360kph) although the extra is probably irrelevant for modelling purposes.

mpjf01 wrote:This is a wider speed range than the 3DR digital sensor (up to 360kph) although the extra is probably irrelevant for modelling purposes.

You want to tell that to these guys

https://www.youtube.com/watch?v=Oix6sHKzOLU

I have no experience with dTE vario but I expect that it is important to measure accurately small airspeed variations in order to get a significant dTE vario . Normal use of a dTE vario would probably be with airspeed between 30 and 100 km/h. For this purpose, it is then a drawback having an airspeed sensor able to measure high speeds because the sensor is then less sensitive for low speeds.

Anyway, there are different versions of 4525DO sensor. Some are able to measure higher pressure and so higher speed.
If someone would like to measure high speed, he just would have to buy the right version. This would have no impact on OXS software (except setting up a parameter in a config file).