Hi All,

I received my 3DR radio kit last week and started to configure them for operation. My current configuration on both of them is:

S3: NETID=25
S5: ECC=1
S8: MIN_FREQ=433040
S9: MAX_FREQ=434790

Firmware SiK 1.6 on HM-TRP

Notice that S8-S11 should keep me in the legal range in Germany. I generally prefer to have the frequency hopping vs. single channel and reduced duty cycle since that way any small-banded RF problems will hopefully only be temporary. The only parameter I would consider playing with at this point is S10 (has to stay higher than 30, though).

For now I have turned off MAVLINK and OPPRESEND to have a better feeling of what is going on when looking at the serial output of the ground station. They will come back on before I go flying.

I did experience the same problems with sketchy links that have been mentioned here and noticed that sometimes I get a rock-solid link at 15 m across my house (plenty of steel in the walls) and sometimes it was just too lossy to have a mavlink connect with APM.

Upon closer inspection in that second state the green LEDs do something like 8 seconds on, 5/10s off. Looking at the serial output of the ground station, I can see the MAVLINK heartbeat come in at irregular intervals but most of the time not at all.

A third state I found is solid green LEDs but heartbeat coming in at 2-10s intervals or again not at all. When the heartbeat comes, it changes interval times in a seemingly sinusoidal manner.

In that scenario I use a serial terminal (screen under OSX, 3DR radio config under Win) to issue +++ and reset the radio via ATZ commands (you can also unplug/replug the radio in the FTDI cable), until I get a stable 1Hz heartbeat - once I have that, I can start APM and the connection seems to hold no matter what.

Another observation: When doing '+++', then just a single AT, then an ATZ, I occasionally get panics from the radio module.

To me the symptoms look like out of sync hopping patterns... According to the documentation the radios sync by hopping through the channels based on a pattern calculated from parameters S3 and S8-S10, but the unsynchronised hopping rate is different for the two radios. Here are a few questions:

  • How do the identical radios determine, which one is supposed to hop fast and which one is supposed to hop slow?
  • In the algorithm used to determine the hopping pattern, is there a possibility for ambiguous states that would seem synced but really is not?
  • Can the radios even separate 50 narrow channels within the min and max frequency given above or will channels partially overlap leading to wrong synchronisation? Within the given legal boundaries is it maybe necessary to modify the parameters to get a more stable link?

Hope this helps to spot the problem.


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

Join diydrones

Email me when people reply –


  • I have worked through the documentation of for the SI1000 and the firmware and I think from the tables that they hardcode to always run wideband FM modulation with H>2

    That doesn't work for ETSI/EN300 though - at least not if one wants to use the 100% dutycycle option

    If I interpret everything correctly, for the maximum width channels of 25kHz one could go to narrowband FM modulation. Reducing df to 10 kHz will reduce H below 1, but one could either take chances or follow the recommendations of SiLabs and stay >=0.5 by reducing the air data rate to 32kBps. Unfortunately I don't have Excel here and I don't know whether NeoOffice is running the sheet correctly.

    Using the other alternative - 10% duty cycle - would also require to carefully calculate the parameters in order to stay legal.

    I put together the build environment and I think I will start modifiying the firmware now and see what I can get. As I do not have the developer tools for the boards, I will have to work with debug code to spit out diagnostics on the serial port.

    If anyone with better HF knowledge and/or understanding of the firmware can help I would greatly appreciate that!


  • I did have some time to spend on the firmware sources and the radio documentation and I think my initial thoughts about erroneous syncs are true. Here is what I found:

    According to the ETSI rules (clause 7.2.3) there are three configurations in the 433 MHz range that we could use for the radio configuration. One of them limits the radio power to 1mW, so let's discard that for now. We are left with the two cases already referred to in the Wiki.

    Frequency Bands/frequencies



    radiated power, e.r.p. / power spectral density

    Channel spacing

    Spectrum access

    and mitigation requirement (e.g. Duty cycle or LBT + AFA)

    433,050 MHz to 434,790 MHz (see note 4)

    Non-specific use

    10 mW

    No requirement

    10 % (see note 3)

    434,040 MHz to 434,790 MHz (see note 5)

    Non-specific use

    10 mW

    ≤25 kHz

    100 %


    Since I first wanted 100% Duty Cycle, I took a closer look at that configuration. Other than noted in the Wiki I actually came out with 28 Channels to configure due to the code in the firmware, that leaves 2 channels "buffer" to the edges of the configured band of the radio. So S10=28 will result in 25kHz channels.

    However, there is one parameter in particular that I was looking at: Frequency deviation. If one defines a channel as a center carrier frequency, this is the amount of frequency shift that is applied up and down to the carrier in order to code 0 and 1.

    This parameter does NOT get caclulated according to configuration, but is hardcoded in register tables in radio.c, which are used to configure the radio depending on air data rate.

    The table looks like this (just the deviation)

    Air data rate [kbps] deviation [Hz]
    2 1875
    4 3750
    8 8125
    16 16250
    19 18750
    24 23750
    32 31875
    48 48125
    64 63750
    96 96250
    128 128125
    192 158750
    250 158750

    In order for the overall frequency to stay within the limits of the channel, we can deviate an absolute maximum of half the channel width from the center frequency. For practical applications we should do less as otherwise we have frequency overlap between channels. For the given case of channels which are 25kHz wide, the limit is an air data rate of 8 kBps (=8125 Hz deviation) in order to constrain the data modulation to the assigned channel. The next one up is roughly 16kHz which already takes us into the adjacent channel, if applied to modulate the payload signal.

    So the original configuration with an air data rate of 64 kBps doesn't modulate within the given channel but +- 2.5 channels up and down - which not only also leaves the assigned band in the outer channels, but screws up the TDM syncing. it CAN work, but there are many cases in which the radios only think they have synced their hopping pattern but in reality have mistaken a 0 for 1 during the preamble or vice versa and just talk gibberish.

    A practical test confirms that the radios start syncing reliably once configured with S2=8. This is not the rate I want, though... at that rate even the CLI produces FIFO overflows.

    I am by no means an HF guru, but it seems to me that the frequency deviation doesn't have to be spaced increasingly as it has been done in the lookup table. In fact the tools supplied by SiLabs let you chose the deviation and spit out the corresponding configuration values. I do not have Excel to run that tool at my hands, though - I will have to do that next week. Logically the SNR gets worse as the deviation gets smaller but with quality oscillators it should still work with 25kHz channels or even less.

    I do not have the complete toolchain for the compilation of the firmware installed yet and if someone from the devteam reads this, I would appreciate if they could consider including code that checks, whether the default deviation stays within the configured channels or whether a recalculation should be done to deviation = 1/4 of the configured channel width (that results in maximum modulation separation due to equal spacing of all possible carrier modulations). The code should logically go into main.c right after the radio_configure sequence. That way the changes are minimal and we stick with the existing firmware as much as possible.

    As we are using an FM scheme here, the overall bandwidth should still be governd by the carrier frequency, not by the individual signal modulation and it should work - but please correct me if there is a flaw in that logic. I have not checked yet, whether Mr. Doppler would be playing tricks on us, either.

    The other use case with 10% duty cycle allows for a max of 9 channels @ 64kBps BTW. So also for this we could use narrower deviation to allow more channels and/or higher air data rate.

    Hope this helps to drive some clarity. I will probably eventually get around to rolling my own firmware but maybe the devteam can help out here.

    Greetings from narrow bandwidth Germany,


  • Don't know how the S8=433040 slipped in there. Should be S8=434040

    Oh - and could someone explain what S13 and S14 do? S14 is fairly self-explanatory but S13:Manchester?


This reply was deleted.


DIY Robocars via Twitter
RT @chr1sa: Donkeycar 4.4 released with tons of new features, including path learning (useful with GPS outdoors), better Web and Lidar supp…
DIY Robocars via Twitter
RT @NXP: We are already biting our nails in anticipation of the #NXPCupEMEA challenge! 😉 Did you know there are great cash prizes to be won…
Nov 24
DIY Robocars via Twitter
RT @gclue_akira: レースまであと3日。今回のコースは激ムズかも。あと一歩 #jetracer https://t.co/GKcEjImQ3t
Nov 24
DIY Robocars via Twitter
UC Berkeley's DIY robocar program https://roar.berkeley.edu/
Nov 24
DIY Robocars via Twitter
RT @chr1sa: The next @DIYRobocars autonomous car race at @circuitlaunch will be on Sat, Dec 10. Thrills, spills and a Brazilian BBQ. Fun…
Nov 24
DIY Robocars via Twitter
RT @arthiak_tc: Donkey car platform ... Still training uses behavioral cloning #TCXpo #diyrobocar @OttawaAVGroup https://t.co/PHBYwlFlnE
Nov 20
DIY Robocars via Twitter
RT @emurmur77: Points for style. @donkeycar racing in @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video. https://t.co/Y2hMyj1…
Nov 20
DIY Robocars via Twitter
RT @SmallpixelCar: Going to @diyrobocars race at @UCSDJacobs https://t.co/Rrf9vDJ8TJ
Nov 8
DIY Robocars via Twitter
RT @SmallpixelCar: Race @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video. https://t.co/kK686Hb9Ej
Nov 8
DIY Robocars via Twitter
RT @PiWarsRobotics: Presenting: the Hacky Racers Robotic Racing Series in collaboration with #PiWars. Find out more and register your inter…
Oct 23
DIY Robocars via Twitter
RT @Hacky_Racers: There will be three classes at this event: A4, A2, and Hacky Racer! A4 and A2 are based around UK paper sizing and existi…
Oct 23
DIY Robocars via Twitter
Oct 23
DIY Robocars via Twitter
Oct 19
DIY Robocars via Twitter
Oct 18
DIY Robocars via Twitter
RT @NeaveEng: Calling all UK based folks interested in @diyrobocars, @f1tenth, @donkey_car, and similar robot racing competitions! @hacky_r…
Oct 13
DIY Robocars via Twitter
RT @araffin2: 🏎️ After hours of video editing, I'm happy to share a best of my Twitch videos on learning to race with RL. 🏎️ Each part is…
Oct 13