Hi,
I'm new to this forum and to wireless stuff in general. I'm want to start a project where I create a wireless data connection between a glider aircraft and the winch (400HP winch pulling the glider into the air) during takeoff. The maximum distance between the two will be at the beginning of the launch: 1.5km (little less than a mile). 100% free line of sight though. The shortest distance will be when the glider has reached the end of the winch launch, which will be 400-600m above the winch.
To clarify things, here's a picture of a typical winch launch:
(http://zweefvliegopleiding.nl/evo/toetsevo/2.11%20lierstart.jpg)
Typically the winch operator has a simple throttle lever and he estimates the glider's airspeed based on sight only, dosing the throttle appropriately. This often leads to too high or too low (too much or not enough winch power) takeoff velocities. FYI: The "sweetspot" is 110kph. Slower than 90kph becomes dangerous, faster than 130 sucks also. I would like to have a display in the winch cabin displaying the glider's airspeed in realtime.
Considering the results of John in a different topic, this should be doable with a RFM69HW and a good antenna. In the glider there would be a moteino with a RFM69HW and a baro sensor. The moteino measures the glider's pitot pressure and converts it into indicated airspeed (IAS) and then sends it to the RX unit on the winch.
The questions:
1. "The most important one" (without it I can't order the stuff to play around / test with =p): I can't figure out what frequency to use: 433mhz or 868mhz. I can't seem to find a lot of (reliable looking) information about the difference, other than a couple of claims on forums about 433mhz having better penetration properties through solid mediums.
2. I can't find anything on using the RFM69HW with a Raspberry Pi (without an arduino). I guess no one wrote a library yet? If I'm missing something please tell me, since that would save me an extra arduino. There is already a Pi where the receiver should come. Not that much for the cost, but the less "moving parts" it has, the less it can fail. =)
3. Does the fact that the TX is moving at 70mph have an impact on the range?
4. Can this range (1 mile while moving 60-85mph) be achieved using the RFM69HW? Or is there another module that is to be preferred?
5. The RX module will be placed on the winch, where a 7.2L V8 engine will be roaring during a launch. Will this cause interference? Too much?
Any other advice about the project would also be greatly appreciated.
Thanks in advance,
Marko
EDIT: Forgot to mention. The system will be operated on a glider airfield. The wireless devices within a 5km radius are a Raspberry Pi with a WiFi dongle (50m), 2 wireless 2.4ghz routers (closest one about 1km away), VHF radio's (somewhere in the lower end of 100-200mhz), transponders (1090mhz) and a cell tower (1km).
(https://dl.dropboxusercontent.com/u/63392345/Capture.png)
Legend:
- Red/White spots: WiFi routers 2.4G
- Blue: TX Moteino with RFM69HW in the glider
- Green: RX Moteino with RFM69HW in the winch
- Distance between blue and green is ca. 1 mile.
EDIT2: I almost forgot, but at the "takeoff area" (blue) there will also be another stationary RFM69HW TX/RX system. Being used to switch a light on and off using a remote. Would it be wise to choose different operating frequencies for the light system and the IAS system? I'm guess it wouldn't matter much for the light system whether I use 433mhz or 868mhz since the required range is only 20m max.
I hope none of this really affects safety, I wouldn't want to have my life or safety depend on one of these RFM radios! It is very low power RF after all!
I highly recommend you use two moteinos and a serial connection to the raspberry. That leaves you with quite reliable technologies. Hooking the RFM to Linux is just asking for difficulties IMHO.
Is your baro sensor to measure altitude or pitot pressure? If the latter, I'm experimenting with one of the honeywell pressure sensors that has a digital SPI interface. They're a tad more pricey than the analog ones, but hopefully easier to use and more reliable. I paid $38 for a SSCMANN060PG2A3 at Mouser.
Quote from: tve on November 03, 2014, 09:53:49 PM
I highly recommend you use two moteinos and a serial connection to the raspberry. That leaves you with quite reliable technologies. Hooking the RFM to Linux is just asking for difficulties IMHO.
Not only do I principally object to this, but the Pi runs Linux!
Off course safety is always a high priority when flying. This is (for now) more of a hobby project of mine. I'd like to build a cheap proof of concept, to see if the system actually helps the winch operator to provide a smoother (and therefore higher) launch. And even if everything would fail terribly and because of it a very bad launch would be given: It happens every week. It's a normal thing that once in a while the winch operator screws up the launch. Every glider pilot is trained to react to a bad launch of cable snap. It's often simulated by flight instructors by releasing the cable by surprise at 100m altitude and letting the student solve it. It's not really that critical to have a bad launch, so I don't think testing this system would decrease safety.
Having said that, thanks for the advice on the Pi. Guess I'll be ordering at least 2 moteinos. But what frequency...
For the airspeed, I'll need to measure the static pressure (basically altitude) and the pitot pressure. From those two values the airspeed can be calculated. The sensor from your link would be perfect for it because of the tube connector. But I'm trying to keep this low budget for now and unfortunately you lost me at "digital SPI interface". Still a beginner at programming. So I don't exactly know what the advantages would be. I was thinking of using the cheap 1,50usd sensors. They should be more than accurate enough for the proof of concept prototype.
Interesting, ok let me try to answer according to my limited knowledge:
1. "The most important one" (without it I can't order the stuff to play around / test with =p): I can't figure out what frequency to use: 433mhz or 868mhz. I can't seem to find a lot of (reliable looking) information about the difference, other than a couple of claims on forums about 433mhz having better penetration properties through solid mediums.
The physics of a lower frequency electromagnetic wave says that it penetrates better. I think that's why they use a low frequency for sonars and black boxes. If 433mhz is legal where you live and you don't need a radio operator license for it, then go for it. If not 868/915mhz will work just fine. You are transmitting from the air so before frequency I would be far more concerned with lowering the bitrate and bandwidth to achieve much higher sensitivity, which is what others did to get much much longer range.
2. I can't find anything on using the RFM69HW with a Raspberry Pi (without an arduino). I guess no one wrote a library yet? If I'm missing something please tell me, since that would save me an extra arduino. There is already a Pi where the receiver should come. Not that much for the cost, but the less "moving parts" it has, the less it can fail. =)
I would strongly recommend using an interface between the RFM and the Pi. You are saving a few bucks by not getting an arduino but you are bound to spend hours upon hours trying to make it run smoothly on the Pi. Save yourself the trouble. The extra Arduino/Moteino will not make me richer nor make you poorer, you have quite an experiment to run. I would probably even run 2 pairs of independent frequencies if I were you. I imagine you can't be back in the air as soon as you need to reprogram/try something else.
3. Does the fact that the TX is moving at 70mph have an impact on the range?
Of course. It's called doppler effect. I don't know the math of how much impact that will be off the top of my head but I imagine it is not dramatic and you should not try to "fix it if it ain't broke".
It would actually be very complicated to fix unless you are always flying towards or away from the receiver. Then perhaps you could do the math and transmit at a slightly different frequency to compensate the doppler compressed/stretched signal. If it's variable then you would need to use GPS or some other way to tell where you are... but it hurts my brain to think how much more complicated that is, espcially with "the budget".
4. Can this range (1 mile while moving 60-85mph) be achieved using the RFM69HW? Or is there another module that is to be preferred?
Hard to tell but I think it's doable with the right antenna and low bitrate settings, frequency is not as important. See other threads where people got 1.5miles or more. They certainly had improved antennas, custom settings and knew what they were doing. The radio module itself is perfectly performant, it's a quality RF chip. The HopeRF implementation of the SX1231H is where performance might suffer, not the best engineering I've ever seen. But I think without making your own, the RFM69HW is quite a good choice. It's 100mW output power, you could find modules that go above that but you are really creeping in the range of very high power modules that require a radio license. Also you are hurting the budget again.
5. The RX module will be placed on the winch, where a 7.2L V8 engine will be roaring during a launch. Will this cause interference? Too much?
I would not think so because I imagine the mechanical vibration from the engine is overall much much lower frequency than the mhz of the radio. And I'm assuming the electronics will not be disintegrating from that :)
I am definitely not the radio/RF expert to ask but I try :)
My guess is even if your experiment fails with the Moteino/RFM69 you still end up with a few modules that are great for other experiments (at lower range?).
Hi,
Thanks a lot for the answers. I've ordered 2 moteino 433 sets and now we wait. =)
Wanting to save an arduino was not for financial reasons, but I didn't want to have an extra component in the system if it wasn't needed. But I guess it's the lesser for both evils to have a moteino running next to the Pi.
About doppler, the aircraft will be climbing with about a 30 degree angle towards the winch. So if really needed, I could write some frequency correction code based on time and airspeed. Those should give me a good enough movement vector of the TX. But since the glider will not be flying directly towards the winch (only for the first 50m rolling over the ground before it starts to climb), but towards a point 500m above it, the doppler effect should be less as well. First I'll try it without any corrections.
QuoteI would probably even run 2 pairs of independent frequencies if I were you. I imagine you can't be back in the air as soon as you need to reprogram/try something else.
Not quite understanding this. What advantage would a second parallel system give me? Except for acting as backup if the first system fails. I usually go flying about 3 times a month and on a typical day I make multiple flights with enough time in between to change some code and try again.
About the winch engine interference, I was thinking more about the alternator which creates a magnetic field around it. I remember the DVB-T TV signal used to disappear at my friends house when a car drove by. Would this also effect the 433mhz band?
Although you might not be an expert, you and this forum have clarified a lot for me. Thanks a lot.
There is no doubt that even if the project fails, I'll find some other use for them. Awesome things. =)
I meant if it saves you time and you are limited to how many times (and how quickly) your turnaround is for getting up in the air to test this system, you might find it more economical to try both 433/868 frequencies at the same time and see which performs better.
As far as magnetics I'm not sure what to advise. I don't think that will affect the RF but I tend to believe not. Again, try it as is, maybe do some on the ground tests before the real thing, if possible.
Ah, now I get it. Testing amount and time is not limited, I have the whole spring and summer weekends where I can make 4-5 flights a day.
I guess all I have to do now is wait for the moteinos. Do you have any indication on shipping time to the Netherlands?
I'm still looking for a cheap useable baro sensor which is easly connected to a rubber 5mm instrument line. Like this (http://www.ebay.com/itm/221555630198), but with a usable range. It should be able to measure up to 4500 Pa (0.65 psi) of relative pressure (= 300kph = Vneverexeed = speedlimit). The one in the link unfortunately only has a 0.3 psi range.
Like this (http://www.digikey.com/product-detail/en/HSCDANN001PDAA3/HSCDANN001PDAA3-ND/3934668) but cheaper. xD
If someone knows something (<20usd a piece) please tell. =)
EDIT: Nevermind, I found a solution. I'll just use two of these (http://www.ebay.com/itm/BMP180-Replace-BMP085-Digital-Barometric-Pressure-Sensor-Board-Module-Arduino-/200915895472) and glue the static and pitot instrument lines airtightly on them, finalizing with some hotglue for reinforcement. For the proof of concept prototype that will suffice.
Even better: link (http://www.freescale.com/files/sensors/doc/data_sheet/MPX10.pdf?fpsp=1&WT_TYPE=Data%20Sheets&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation).
(http://uk.farnell.com/productimages/farnell/standard/GE4344C-40.jpg)
Combined with an amplifier it should be able to plug staight in to as well the moteino, as the pressure lines.
Netherlands I think is quite good with First Class, I would think about 7-10days but if that doesn't happen please bear in mind first class is a "best-effort" service and there are no guarantees. But I don't recall ever having issues with any orders to Netherlands getting lost or anything.
With respect to the pressure sensors, the SPI interface gives you a digital interface where you can read the calibrated and temperature-compensated pressure. See http://sensing.honeywell.com/index.php?ci_id=45843 This may be too much programming for you (however, I'll be happy to share my implementation once I finish it). If you go the cheap sensor route (like the MPX10) you end up with an amplifier and A/D conversion. I just implemented that for an under-water use-case where I couldn't get a digital sensor and it's easy, but you now get to calibrate the readings and, if you need the temperature compensation, you get to add a temperature sensor (which I believe should be outside the plane since it needs to sense the temp of the air hitting the pressure sensor) and then do the math. I have no idea whether you need the temp compensation or not... In the end, it's easy to erode the $20 difference between the cheap sensor and the good sensor... But in the end, this is about having fun :grin:
Hi,
Thanks for the clarification. It does seen that a digital unit would give more accurate data. I do not think however that the temperature would have much of an impact. The standard mechanical airspeed gauge is also just an box with a membrane, which is connected to the dial gauge. It just has to be calibrated every 5 years. Or do you mean that the cheap analog sensor will give different values with the same pressure depending on the ambient temperature?
About the shipping time. That's great. No problem if it arrives a little later. I'm used to waiting up to 5 weeks on stuff from ebay/China.
Hi Guys,
Today I've finally found some time to play around with the moteinos to get a little familiar with the arduino library. I'm got it working using the example gateway and node. Also with a self written (simple) version.
But I can't manage to do anything with the received data. What I'm trying to do is something like this:
void loop() {
if (radio.receiveDone()) String payload = radio.DATA; // read the received package into string "payload"
if (payload == "secret code") digitalWrite(3,HIGH) //Turn whatever is connected to pin 3 on if payload matches the 'secret code'.
}
Unfortunately, this gives an error compiling:
Gateway:138: error: invalid conversion from 'volatile byte*' to 'const char*'
Gateway:138: error: initializing argument 1 of 'String::String(const char*)'
I've tried some different ways, like loops. But the all have their own error... Could someone please tell me how this is done? Thanks!
EDIT: Of course 2 minutes after posting it on the forum I find something that works:
String payload = (char*)radio.DATA;
No idea what is happening though. What does the (char*) do?
Quote from: Istria on December 02, 2014, 05:31:19 PM
<...snip>
EDIT: Of course 2 minutes after posting it on the forum I find something that works:
String payload = (char*)radio.DATA;
No idea what is happening though. What does the (char*) do?
One of the good/bad features of C++ is that it is both flexible and persnickety about performing operations.
It's flexible in that operators like '=' (assignment) can be overloaded many different ways so that C++ will happily do what's needed to assign type A to type B, but only IFF there is a definition for this overloaded assignment. In this case, C++ didn't 'know' how to convert a pointer pointing to a volatile byte, hence the message. Since you KNOW that radio.DATA is, in fact, pointing to a 'char' that is sufficiently stable at the time of the assignment, the (char*) is safely casting the pointer into a type that C++ knows about...
I read your reply 5 times. It's still chinese to me. xD
Terminology like "overloaded", "pointer" and "volatile byte" unfortunately surpasses my knowledge.
Fortunately, it works! So the understanding of HOW is optional. for now. =)
Quote from: Istria on December 04, 2014, 03:27:19 PM
I read your reply 5 times. It's still chinese to me. xD
<...snip>
GOSH! I've been wanting to be able to write Chinese for years! Thanks!
;D
As for the why...
There are different types of data in most languages. For instance in your example there are "character" strings and "volatile byte" strings.
Radio data must be a volatile byte pointer and when you try to assign that to payload which is a character pointer the compiler chokes.
Of course, with C++ the compiler gives you enough rope to hang yourself with and it allows you to override the error by simply forcing the cast to the new type.
If you want to assign a volatile pointer to a char pointer well then fine, you can do that. Just force it!