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:
S0: FORMAT=25
S1: SERIAL_SPEED=57
S2: AIR_SPEED=64
S3: NETID=25
S4: TXPOWER=8
S5: ECC=1
S6: MAVLINK=0
S7: OPPRESEND=0
S8: MIN_FREQ=433040
S9: MAX_FREQ=434790
S10: NUM_CHANNELS=50
S11: DUTY_CYCLE=100
S12: LBT_RSSI=0
S13: MANCHESTER=0
S14: RTSCTS=0
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.
Regards,Otto
Replies
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!
Otto
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.
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)
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,
Otto
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?
Otto