Hi All,
Not sure if this is the best place to post this…
I’ve always thought it would be useful for a way to estimate or measure wind, at altitude.
Has anyone heard of Vaavud? I purchased their previous device that works with a smart phone. It’s great!
I was wondering if there would be a way to integrate this (or the sensors in this) into ardupilot?
Best,
Steve
Depends on the format the sensor spits the data out in and if it’s accessible. The technology itself is fairly old and commonly used in professional meteorological applications. See e.g. Vaisala’s sensor.
Besides, I wouldn’t really use a bluetooth device at least on anything flying as it might interfere with 2.4GHz remote control systems.
Hi @StefanG,
I agree that the bluetooth isn’t good. I’m not even sure if this particular device would be good to put on a drone.
I’m more interested with integrating this technology (or sensor) into the ardupilot code on a drone.
Would it be beneficial to the code in helping with autonomous missions? Especially to arduplane?
Best,
Steve
Bluetooth and WiFi do not interfere with 2.4Ghz controllers even though they are the same frequency.
Bear with me to post Oscope proof as we just covered this a few months back on the RCGroups forum…
UPDATE
https://www.rcgroups.com/forums/showpost.php?p=36678649&postcount=70344
Those spectrum analyses are very nice but I have some issues with them. First of all, the measuring device was a Turnigy radio, which is by no means a lab grade device. Second, we’re talking about a very specific case here in which the potential source of interference is on the unmanned system while the legitimate signal source is far away. This scenario hasn’t been tested at all by the posters and can open all kinds of worm cans. For instance, on close range you might have emissions from a radio which wouldn’t be an issue a few feet away because they are fairly weak. As you might know, the signal decreases in a way that is approximately inversely proportional to the square of the distance. So, it’s very possible that a weak transmitter like a bluetooth module doesn’t cause interference when just being half a meter away from the RX but does when it sits right on top of it.
@cczeets:
As those sensors are omnidirectional, I would potentially see more use in tradheli or copter but then I’m not a plane guy :D. I just happen to know that the majority of modern (full size) combat helicopters have some kind of omnidirectional wind sensor on board, so it must be of SOME use :D. As for integration, at least a Vaisala sensor should be very easy to integrate because it outputs a serial signal which is well documented. Probably just a few lines of code if a dev would get interested.
I understand what you are saying.
Isn’t it the characteristics of Bluetooth to avoid interfering with other frequencies?
Before I enabled radio failsafe, I would be knocked out of the sky several times by ha high power WiFi internet relay tower nearby. The ID Director for the hospital under the towers says by his equipment, the WiFi internet provider is way over the FCC limits. And I can tell with those lost link events.
But Bluetooth and WiFi cameras just do not interfere.
In my opinion, the transmission protocols of Bluetooth and WiFi cameras are different from the controller.
And it is not just my opinion.
I know a lot of RPICs that have not had a lick of trouble with on-board interference.
The thing is that BT and many RC systems are both spread spectrum. It might work but IMHO there’s also a chance that the BT interferes with the RC RX when mounted on the craft, so I’d at least be very careful and do lots of ground testing and lots of testing with activated failsafes before doing any serious flying.
I beg to differ here.
WiFi turned on in a GoPro will drop the range of a 2.4GHz RC system to less than 50m.
Have proved this in practise.
What is the Tx/Rx system?
On a previous CX-20, only dropped out of the sky when I got close to those towers I mentioned.
WiFi never affected range for myself or the rest of the group.
As practice though, they keep it off most of the time.
But there are tons of ready made FPV craft out there that are not 5.8ghz that fly very well.
@StefanG Yes, I agree that wind direction would be useful. Wonder if anyone is in the process of testing these sensors to see if there’s any value?
First, why would you want a sensor on the aircraft? The only useful information would be airspeed.
Second, Yes, multiple radios can share the spectrum. How else can a thousand people at a stadium use their cellphones at the same time.
But the problem with a 2.4 GHz transmitter on the A/C when the R/C is done with a 2.4 GHz link is desense, not interference. If you are in a room full of people, you can generally hear and understand many conversations within your hearing range. This is an example of everyone talking, the transmitters, sharing the frequency. However if the person standing next to you is talking loudly, then he is all that you can hear. This is an example of desense.
When you put a device using WiFi or Bluetooth (2.4 and 2.45 GHz respectively) next to the R/C receiver on your aircraft, you won’t get your A/C very far from the R/C transmitter before it can’t “hear” the controller. The WiFi or BT device is just “louder” because it is just inches away.
It’s not interference. The Spread-Spectrum techniques used in virtually all unlicensed 2.4 GHz devices is interference resistant- it just doesn’t happen.
Cellphone towers radiate on 850, 900, 1,800 and 1,900 MHz - none of which would effect a drone on 2.4 GHz.
First, why would you want a sensor on the aircraft? The only useful information would be airspeed.
That’s not true. Wind direction is also quite useful, especially for rotorcraft, as I wrote above.
I think you are mixing apples with oranges. this “desense” you are talking about is an effect observed in receivers with automatic gain control. Total different story. We’re primarily talking about nearfield interference here.
With ideal transmitters and receivers that wouldn’t happen at all because they would transmit exclusively on their frequency and not one hertz above or below. Unfortunately, they do not, so that is why we have nearfield interference. The “unwanted” transmissions are much stronger in the nearfield, again, as explained above.
Yes, it is 
- radio frequency interference or RFI caused by “unwanted” nearfield emissions. Interference resistant does not mean interference proof! First, you also have to take into account the layer 1 technologies, which are already different. Bluetooth uses Adaptive FHSS which has a much higher potential of causing nearfield interference to other 2.4GHz devices because of the channel hopping. Frsky RC systems also use FHSS which is fairly resistant to single channel interference (like Wifi) because it recognizes swamped channels and avoids them on the next cycle. The problem with Wifi is the comparably enormous bandwidth of a channel and the fact that nowadays Wifi products usually just barely pass the RFI tests, means, they cause considerably more nearfield interferences than would be “polite”
Anyways, the device in question is a bluetooth device and as written, bluetooth has a higher potential to interfere with other RF devices due to the channel hopping.
The last thing you have to consider is layer 2/3. Bluetooth and Wifi are data services and create a lot of their RFI-resistance through layer 2 and 3 protocol, means, they detect packet loss and request a resend. For data services that is fine but it’s not really good for real time critical stuff like RC. To my knowledge, no RC system to date includes any layer 2/3 transmission assurance protocols. They just send out the data and some receive back telemetry - even with RSSI information, but that RSSI is a more general information, not a transmission assurance protocol on packet level. So, RC systems are inherently less RFI-resistant.
I don’t believe, anybody talked about cell towers?
We’ve been working on using the IMU flight attitude data [multirotor] to estimate wind. We performed a series of calibration flights in a wind tunnel and produced this set of curves that relate tilt angle to air speed:
The bottom three lines are repeats of experiments with the copter pointing into the oncoming air stream The top [green] curve is with the right side of the copter into the air stream and reflects an asymmetry in our landing gear that complicates things. The ‘tilt’ angle is obtained from the pitch, yaw and roll angles by applying these as a rotation matrix operation to a unit vector normal to the plane of the copters arms. [i.e. a rod sticking out the top centre of the copter.]
This calibration curve can then be used to derive an airspeed vector that when combined with the ground speed vector from the GPS gives the wind speed.
The ultrasonic wind meters would also likely work - and are something we’ve considered - however would be subject to complications with regard to the rotor air flow. They would need to be mounted in such a way to minimise this and then may need the movement of the sensor relative to the copter body to be accounted for.
You get wind direction from the ground track and heading. Add ground
speed to the calculation and you get airspeed. This data is already
available to the controller, all that’s missing is the calculations and
the display.
Nearfield interference is just another term for desense. The result is
exactly the same. AGC just makes the effect more noticeable. Most drone
operators don’t want to know anything about bandwidth, selectivity,
frequency hopping and Part 15 specifications. They just want to know
why the WiFi on their camera reduces the controller range to a few meters.
Steve Mann