Originally Posted by cojjung

I have interference of the radio link and the telemetry/video link ( both 2.4 GHz).

This is simply not possible. That's why nobody has been using 2.4GHz video anymore since 10 years or so, and the few who do use UHF (433/868MHz) R/C.

I think i did not formulate my question clear enough since you answered what most of the people do since how many years. Actually this is very far from my questions. But thank you anyway.

My questions are:

1. Is there a way to limit the used bandwidth for the module ?
( For the Ti chip itself it is pretty straight forward but how does it work with the code on iRX4 side and the receiver side)

2. Did anyone try a similar thing already ?

The bandwidth is pretty much fixed, since you can't change the bandwidth at the transmitter and expect the receiver to still work properly. The amount of data being transferred at the given baud rate is always going to stay the same, unless you're going to write your own protocol from scratch.

However, the bandwidth is very small in comparison to the size of the 2.4GHz band so I would not look there to restrict the amount of spectrum used. The protocol skips around the entire band due to it relying on frequency hopping. In fact, the only reason it is legal to transmit is because it jumps around the entire band and doesn't cause interference at any one frequency for very long. You could theoretically change the hopping scheme to have it only hop around half the band. I know the AFHDS2A protocol actually selects the hopping pattern from like 135 channels (band / bandwidth = channels) and uploads it to the receiver at binding. If your protocol (I assume FrSky?) can do that then you might theoretically be able to limit it to using just half the spectrum. Whether this would be legal to do I do not know.

I don't think anyone has done this because you're theoretically losing some of the benefit of the frequency hopping concept and also nobody runs 2.4GHz VTXes with 2.4GHz RC links any more. So if you're looking for just a technical challenge for fun to try to experiment, I'd say see if you can adjust the hopping scheme on your protocol, but if you're looking for a practical real-world use then you'd save a lot of time and danger a bug of possibly causing loss of control to just switch your VTX or RX to a different band.

Hey CapnBry, thank you for the elaborate answer !

The reason why i want to solve the 2.4 GHz vs 2.4 GHz issue is very complex so let's try to skip this part.

However, the bandwidth is very small in comparison to the size of the 2.4GHz band

Are you talking about the bandwidth of each channel ? This is usually between 25 and 230 KHz for CE-conform protocols and would mean that there a lot of channels available for a hopping pattern even with a reduced band.

My plan is to decrease the used band(width) which is the equivalent of using less channels for hopping. Most of the protocols only need a minimum number of channels to make their hopping patterns work ( and the ETSI regulation states that as well), but with a default channel spacing the 2400-2440 range should still allow enough channels for the default hopping-patterns.

(band / bandwidth = channels)

I believe it is band/ channel spacing = No. of channels. The channels have a gap in between ( channel spacing > channel bandwidth )

I know the AFHDS2A protocol actually selects the hopping pattern from like 135 channels (band / bandwidth = channels) and uploads it to the receiver at binding. If your protocol (I assume FrSky?) can do that

I am trying this using FrSky XM+ receiver and the D16 protocol. I am not sure how it works for FrSky but i was assuming that it works like you described ( the receiver and the transmitter agree on a pattern after establishing connection ).

Finding two perpendicular hopping patterns would work as well, but the second link i am using is proprietary and i can't influence the hopping pattern. This is why i though adapting the band would be way easier.

Thank you for helping me

As said the D16 protocol works with given parameters, you can't change them on the TX and have the RX still work. It hops over the whole band, if you restricted the TX to only a portion you'd get link losses or reduced/unusable performance.

And it still wouldn't solve your problem, since if your VTX and receiver are anywhere close the TX is desensitizing the receiver in the entire band anyway. You may get rid of the interference on the video on the ground, but you'll still lose control at 200m.

Originally Posted by Kill Switch

I see the nightly is now up for 2.3.2, however there alternative is to install Mikes boot-loader for the Radio, instructions can be found here
https://openrcforums.com/forum/viewtopic.php?f=7&t=4676

For DannyR he will most likely have to install the boot-loader for the module first (thus could upload directly the latest version of multi) and wait for 2.3.2

I looked at OTX 2.3.2. There doesn't appear to be a version for the X9D/X9D+, just the X9. I opened my IRX4+ module and it doesn't have a 6 pin header where one would select the boot0 configuration. I am guessing the one I got was one of the earlier ones. At this point I may just purchase another one, if, I can confirm the new one has the bootloader installed already.

Danny

Originally Posted by cojjung

I believe it is band/ channel spacing = No. of channels. The channels have a gap in between ( channel spacing > channel bandwidth )

Yup, good point, it is band / spacing = channels. I was over-simplifying. The key takeaway though is you can't reduce the channel spacing, which is determined by channel bandwidth, which is going to be fixed.

If you look in the source code Multiprotocol/Common.ino - Frsky_init_hop(), you can see how it builds the hopping_frequency[] array. This is sent to the receiver during bind process too it seems, although I have never messed with any of this for FrSky so there may be some limit to how much you can modify the hop pattern. Note that there "channel spacing" is different than the channel spacing we're talking about. It is talking about spacing between hopping_frequency[1], hopping_frequency[2] etc, not the actual frequency deviation between adjacent channels (which could be as simple as our channel spacing * channel number). Your best bet would be to modify that function so it only uses channels that don't conflict with your VTX and rebind your receiver. You'll have to search around to figure out how to convert FrSky channel number to actual frequency though, but you could also just add exclusions and then look on a spectrum scan to do it by trial and error.

As Kilrah pointed out though, your VTX is shouting so loudly it is still going to bleed over into your RX to some degree though and reduce its sensitivity although it would be less than you're experiencing now when it hops through the VTX range.

Is anyone out there having any issues with the jumper internal module and Tactic SLT receivers? Received my first internal module from RC-Wing.com about 2 weeks ago and updated to v1.2.1.85. It will bind to an SLT receiver, but has about a 5 foot range. So, I figured the internal module is no good and order another internal module from heli-nation which i received yesterday, update to latest .85 firmware and has the same issue with my SLT receivers. The external jumper t16 multi module works fine. My jumper t16 is updated with the latest nightly opentx. Is there a known problem with the internal module and SLT receivers??

Gerry

Originally Posted by DannyR

I looked at OTX 2.3.2. There doesn't appear to be a version for the X9D/X9D+, just the X9. I opened my IRX4+ module and it doesn't have a 6 pin header where one would select the boot0 configuration. I am guessing the one I got was one of the earlier ones. At this point I may just purchase another one, if, I can confirm the new one has the bootloader installed already.

Danny

That would be really surprising that there is no Boot0 strap... Can you post a picture?
Pascal

Originally Posted by gman326

Is anyone out there having any issues with the jumper internal module and Tactic SLT receivers? Received my first internal module from RC-Wing.com about 2 weeks ago and updated to v1.2.1.85. It will bind to an SLT receiver, but has about a 5 foot range. So, I figured the internal module is no good and order another internal module from heli-nation which i received yesterday, update to latest .85 firmware and has the same issue with my SLT receivers. The external jumper t16 multi module works fine. My jumper t16 is updated with the latest nightly opentx. Is there a known problem with the internal module and SLT receivers??

Gerry

There should be no difference between internal and external modules as they are sharing the same RF board.
Verify that:
- the antenna is well connected (you can screw it completly) and the right kind (SMA/RP-SMA)
- the internal module antenna wire is well attached (may be try to swap the full antenna +wire with the external module)
- you haven't checked the low power box on OpenTX
Pascal

Originally Posted by hpnuts

There should be no difference between internal and external modules as they are sharing the same RF board.
Verify that:
- the antenna is well connected (you can screw it completly) and the right kind (SMA/RP-SMA)
- the internal module antenna wire is well attached (may be try to swap the full antenna +wire with the external module)
- you haven't checked the low power box on OpenTX
Pascal

Thanks for the quick reply Pascal,
The antenna and coax connector are secure, low power is Unchecked and swapped antennas with the external module. I did not know the RF section were not on the multi modules, is the RF section on the T16 motherboard?

Here is a quick video of the problem

Output (0 min 46 sec)

Gerry

Originally Posted by gman326

Thanks for the quick reply Pascal,
The antenna and coax connector are secure, low power is Unchecked and swapped antennas with the external module. I did not know the RF section were not on the multi modules, is the RF section on the T16 motherboard?

Here is a quick video of the problem

https://youtu.be/at7CnggY3z8

Gerry

I see when you are using the internal module you have the receiver number set at 30?
The only valid inputs on MPM version 1.2.1.85 are 0 through 15.
When you switch to the external module you are using receiver number 0.

Try resetting internal with a lower receiver number and retest.

What version of OpenTx or JumperTX firmware is on the Radio?
All the versions that I have tested stop at receiver number 15.
So I'm not sure how you have number 30 selected?

Rich

Originally Posted by mrcurtis2

I see when you are using the internal module you have the receiver number set at 30?
The only valid inputs on MPM version 1.2.1.85 are 0 through 15.
When you switch to the external module you are using receiver number 0.

Try resetting internal with a lower receiver number and retest.

What version of OpenTx or JumperTX firmware is on the Radio?

Rich

Reset receiver number to 00, same result.
Jumper T16 is using this nightly "opentx-t16-internalmulti-lua-en-2.3.2N25.bin"

Gerry

Originally Posted by gman326

Reset receiver number to 00, same result.
Jumper T16 is using this nightly "opentx-t16-internalmulti-lua-en-2.3.2N25.bin"

Gerry

Not sure what problem you have but I just updated my T16 to that exact firmware.
I can't exceed receiver number 15 on Internal MPM or External MPM?
Maybe redownload and rewrite firmware to your radio?

Rich

Originally Posted by hpnuts

That would be really surprising that there is no Boot0 strap... Can you post a picture?
Pascal

Will do this weekend. Not home till Friday.