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 @a1k0n: Did I get rid of hand-tuned parameters? Yes. Am I still hand-tuning more parameters? Also yes. I have a few knobs to address the…
DIY Robocars via Twitter
RT @a1k0n: I'm not going to spoil it, but (after charging the battery) this works way better than it has any right to. The car is now faste…
DIY Robocars via Twitter
RT @a1k0n: Decided to just see what happens if I run the sim-trained neural net on the car, with some safety rails around max throttle slew…
DIY Robocars via Twitter
DIY Robocars via Twitter
RT @SmallpixelCar: @a1k0n @diyrobocars I learned from this. This is my speed profile. Looks like I am too conservative on the right side of…
DIY Robocars via Twitter
RT @a1k0n: @SmallpixelCar @diyrobocars Dot color is speed; brighter is faster. Yeah, it has less room to explore in the tighter part, and t…
DIY Robocars via Twitter
RT @a1k0n: I'm gonna try to do proper offline reinforcement learning for @diyrobocars and throw away all my manual parameter tuning for the…
DIY Robocars via Twitter
RT @circuitlaunch: DIY Robocars & Brazilian BBQ - Sat 10/1. Our track combines hairpin curves with an intersection for max danger. Take tha…
Sep 22
DIY Robocars via Twitter
RT @SmallpixelCar: Had an great test today on @RAMS_RC_Club track. However the car starts to drift at 40mph. Some experts recommended to ch…
Sep 11
DIY Robocars via Twitter
RT @gclue_akira: 世界最速 チームtamiyaのaiカー https://t.co/1Qq2zOeftG
Sep 10
DIY Robocars via Twitter
RT @DanielChiaJH: Always a good time working on my @diyrobocars car at @circuitlaunch. Still got some work to do if I’m to beat @a1k0n howe…
Sep 10
DIY Robocars via Twitter
RT @SmallpixelCar: My new speed profile for @RAMS_RC_Club track https://t.co/RtLb7TcgIJ
Sep 10
DIY Robocars via Twitter
RT @SmallpixelCar: Practiced at @RAMS_RC_Club today with my new @ARRMARC car https://t.co/AEu2hCx89T
Aug 28
DIY Robocars via Twitter
Aug 24
DIY Robocars via Twitter
RT @gclue_akira: 柏の葉で走行させてるjetracerの中身 #instantNeRF #jetracer https://t.co/giVvuE4hP7
Jul 4
DIY Robocars via Twitter
Cool web-based self-driving simulator. Click save when the AI does the right thing https://github.com/pncsoares/self-driving-car
Jul 4