9 replies to this topic

[dot]

Hi, what is the power (mW e.r.p.) and duty cycle of those radios? I.e., is any of those usable in Europe too?

For 433 MHz (class 20, band 433,050-434,790 MHz), allowed power limit seems to be 10 mW e.r.p and 10% duty cycle is allowed.
For 868 MHz (class 28, band 868,000-868,600 MHz), allowed power limit is seems to be 25 mW e.r.p and 1% (one%) duty cycle is allowed.
And 915MHz seems to be reserved...

Probably not very useful in Europe?

Edited by dot, 28 March 2011 - 10:01 PM.

[peabody124]

you can configure the power limits through the GCS and indirectly set the duty cycle via the telemetry rate.  i'd have to get really into the code but i bet it's typically bellow 10% duty cycle anyway.  what time scale is that averaged over?  clearly not 10% of the day.

[florian]

It is averaged over one Hour...

[Gary Mortimer]

Yes the GCS really ought to be talking to the UAS occasionally its a flight monitoring sort of thing not a direct control application, or is my thinking incorrect??

Like any flying the time you spend flight planning before a flight is the time that often separates success from failure.

fail to plan plan to fail

If there are issues with duty cycle then at least we are in a position to change how things work. I think OP is the first autopilot platform to actually think about its own radio system and how best to run it.

[peabody124]

So take a fairly high telemetry rate: 4000 bytes per second.  The packet size is 256 bytes, but there's some overhead so let's say the average payload size is 200 bytes.  That means 20 packets per second.  

Now if you have the RF rate at 192000 bits per second, then the total number of packets that would fill the air is ~ 192000 / 8 / (256 + 14) ~ 89.  (I'm approximating that + 14 - I don't feel like looking through the data sheet for the preamble size and any headers the rf module adds).

So off the bat, you're around 22% at this (quite high compared to the base) telemetry rate.  Given you'll only fly for 30 minutes out of an hour, that will keep you below 10% per hour :-D.

A normal telemetry rate without increasing anything is 400/150 so that would be only ~1%.  However for lower rates it will send more half packets and that means more overhead.  If this were a concern for someone and they wanted to keep the telemetry efficient in this sense we should expose the packetization timeout and keep it fairly high so we only send full packets.

For more direct control you will want to push these rates, so I would suggest 5 minute flights per hour

[dankers]

We have covered this before about legal limits in Europe inside the project and it seems to be a case of the user checking their local regulations and ensuring they stay within the law or breaking it at their own risk.

We have so much to do in the project without trying to decode legal requirements from around the world which everyone has different views on as well, Europe is one of the worst as some countries enforce their rules and others seem to ignore them totally. The simple option for us it to ship the PipX with a boot loader only in Europe and let people research the laws / duty cycle and power output themselves and configure the device as they want. To do anything meaningful in Europe a basic level radio Ham license is really recommended, its easy to get and means you will have a lot more options.      

For sure we can limit the firmware for power output and for duty cycle, I think smart users will ignore this however, but we can easily have a region configuration option. Still being Open Source, its going to be trivial for people to work around any enforced limits, however enforced limits is not at all the spirit of OP anyway and not something we would do.  

From what you have posted, I guess the option for Europe without a license seems to be only 2.4Ghz and even then it is limited compared to the rest of the world. For 2.4Ghz users the Xbee Pro are already available so there is no point creating another 2.4Ghz device and even these might not be legal? The PipX was created to provide a better option to the Xbee modems and even from what you have posted, 434Mhz still seems to be the best option, just limit your usage to stay within the class license.  

If staying within the classes you posted and using a PipX at 434Mhz is interesting, work out the correct power and telemetry rate. Otherwise go get a Ham license, this opens up a lot more options as I am really curious if there is actually anything you can use in Europe for long range UAV flight without one.

[dot]

Btw, do I referred to right frequency ranges on original post?

Some information about unified frequencies in EU can be found at: http://www.ero.dk/rtte

5.8GHz (5725 – 5875 MHz), 25mW erp, 100% duty cycle is probably one way to go in Europe, if you dont plan to use video downlink at the same time. Or some datastream-into-video decoding, to allow both? Harmonised Standard EN 300 440 – 2.

2.4GHz seems not beeing real option, as modern RC equipment uses it for RC control - so you can not have 2.4GHz transmitter on board.

[dankers]

dot, on 30 March 2011 - 07:04 PM, said:

5.8GHz (5725 – 5875 MHz), 25mW erp, 100% duty cycle is probably one way to go in Europe.

No, not the way to go for serious use, the range will be awful, it won't be useful for anything and you will need antenna tracker mess etc. The way to go in Europe is to work to change the legislation to bring them in line with the rest of the world or better yet spend some effort getting a ham license and the problem is solved.  

The PipX will be a 434Mhz device when it is first released, this is finalized now and we are at the end of the testing cycle. Changing to another frequency and one that will not achieve what we need is not happening.

Europe has no frequency that is usable for good range telemetry, 2.4Ghz is the best but as you pointed out it is a poor choice if using 2.4GHz for RC, still there are Xbees that work at that frequency so no point in us covering that band anyway.  

Some work is going in to frequency allocation for professional UAV operators but even then to use these standardized frequencies you will need a license.

[Gary Mortimer]

I think the WRC work will apply to all UAS David, amateur or professional. Have I missed something though, why would the modem need to be talking to the UAS 100% of the time? Surely it should just be,

everything alright

yes thanks

sort of exchanges.

oh btw where are you

Oh I'm here

Ok cool thanks, laters.

laters


It would be pointless to clog up the system with unnecessary messages. If your changing whats happening on the fly with your UAS you have not planned your flight properly. Even then when you are re tasking it does not need to be in the loop, its not going to say don't go that way there is a shortcut round the back of the church, you never listen to me I don't know why I bother...

Think about the grown ups there is I think about a half second delay talking to a Predator.

Perhaps this brings up a more interesting subject, ie how do we plan to talk to the platform.

[peabody124]

Yeah Gary, it's completely up to the user to configure the telemetry rates.  It's on Ed' long list of gadgets to too to create a bandwidth monitor so you can choose the total amount of data you want and which things you want more frequently.  For example I often want a lot of of the lower level things really fast for debugging.  

But I agree base configuration should be largely system health, battery, location at ~1000 and other things even less frequently.  Currently most objects default to 1 second which results in ~400 bytes/sec which following my above calculations should be well within regs if you set the max RF power appropriately.