OpenBee Telemetry Traffic Test

Hi everyone, 

Another blog post about OpenBee :)

Everyone asking about telemetry speed but i didnt answer this questions because of nature of RF telemetry.
RF telemetry speed depends more than one thing. I just take this video for showing unidirectional communication limits. 
The limit depends FSK modulation frequency and RF bandwidth. We can increase the limit but range reduces.

As you can see on the video, OpenBee handling %47.7 of 115200 baud without any problem. I guess 5500 bytes per seconds (55.000bps) is enough for most of telemetry project :)

I'm using firmware v1.01 on this video, we can add MAVLINK packers and other useful codes. 

Please feel free for any question and request. 



E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • Hehhehhehe :)
    maybe you must watch it :

    stay alive kill more :)

  • Regarding the audio in the background:

    I need to learn how to keep my tanks alive! I am always dying!!! I need the rest of the video! :-)

  • Hi Tridge,

    Current OpenBee code based on telemetry code of OpenLRS RC system.
    In OpenLRS we are hopping in 3 channels because of some security reasons. 3 Channels increasing the re-locking speed under hard conditions. And refresh rate too. It is opensource and you can change it easily. If you can find better way we are ready for your updates. Just inform me or share the code on internet.

    About OpenBee, hopping system disable in current code. FHSS is not a rule for radio transmission. There is two reason for using it:

    1. Military usage (also AHSS) hiding the transmission from hacks.
    2. Civilian usage, reducing band load and spreading it in whole spectrum

    The first reason is not important for us. Second one depends you and your telemetry requirements.
    Xbee making only 5 channels FHSS and their packages bigger than our one because of networking stacks. And if you read their documents you will find, they are under regulations when only you are using the telemetry for %10 of time (or something).  This mean you cant use 9600baud for full time. If you planning to using continuous telemetry, the limit is 960baud. or 100 byte per second.  

    In our case, my current code using the rf band when only serial data coming. Mean, you can control your RF load like all unidirectional telemetry systems. And also hopping code there, you can enable it with a little bit work.  But i'm not suggesting it, because if you want to use hopping system, you have to locked and need continuous connection between 2 module. Mean, your RF load will be higher than you expected because of "antenna resonation timing" and "package headers". You need 200-300 byte times for every pack(read Silab's RF IC documents for details) and you have to load rf band with empty packages for hopping. I thing your band load will be higher than current system.

    We can discuss about solutions. I'm open for any help. If you want to make it better, i can add you as OpenBee developer.




  • Developer

    Hi Melih,

    I just had a look at the source code for controlling the RFM22b for OpenBee, and I'm puzzled by a few things.

    It looks like frequency hopping is currently fixed to 3 channels in the Hopping() function. The frequency hopping also seems to have no synchronization between the radios - it just changes channel on each packet transmit. It also doesn't seem to change channel on receive, so you'll lose 2/3 of all packets if hopping is enabled unless I've misunderstood the code (quite possible!).

    So my guess is you are running it currently with no frequency hopping. Have you checked that you meet the local radio regulations? For example on 900MHz I believe you would have to hop over at least 50 channels in the US, and in Australia you have to hop over 20 channels to meet the LIPD rules. In the 433MHz band the rules are simpler and don't require as many channels, but the power limits are also much lower.

    There also seems to be no attempt at all to prevent the two radios transmitting at the same time, and thus talking over each other. So if you are receiving telemetry from the plane then I don't think sending commands to the plane will be at all reliable - it would only get through it you happen to transmit the command at a time when the plane isn't transmitting.

    Cheers, Tridge

  • Moderator

    I use 19200 and think is absolutely enought :)))

This reply was deleted.