UnTraDe commented 4 years ago

Is there a plan to add support for the long range systems (TBS CrossFire/FrSky R9)? By taking apart the R9M and the R9 I own, I found they are based on the SX1276 LoRa chip from Semtech (https://www.semtech.com/products/wireless-rf/lora-transceivers/sx1276).

Some pictures I took from the R9 receiver with a microscope:

2015_0606_000453_002

And the front-end ~looks like it has an amplifier~ has a switch (probably for antenna diversity):

2015_0606_000509_003

Googling around about TBS Crossfire, it looks like they use an RFM95-something chip, which appears to be the same silicon as the SX1276 chip just with different markings. Is there any work currently being done on reverse-engineering those protocols?

As far as hardware goes, I think this module could be used easily along side the current 4-in-1 2.4GHz module, with a different antenna of course. This module is available from a lot of places really cheap (3~8$). I've ordered a few and I'm currently designing a simple PCB that connects them to an STM32F103 and expose the antenna pad to an SMA connector. I will try to write some initial code to try to talk to a receiver.

I can capture some SPI communications with a logic analyzer between the stm32f103 and the SX1276 chip on the R9M and R9 I have. Which procedures are usually the most useful to start with? (binding/regular use/telemtry?) I can also try to capture on-air data with SDR, but that would probably take longer to decode.

IllusionFpv commented 4 years ago

@AlessandroAU I have the datasheet

UnTraDe commented 4 years ago

@AlessandroAU Look at https://www.skyworksinc.com/. Most amplifiers that I saw in the R9 systems are from Skyworks and have similar markings. What module is that?

@IllusionFpv Do you know which specific chip that is?

IllusionFpv commented 4 years ago

@UnTraDe https://www.mouser.com/datasheet/2/472/200428E-1501384.pdf

AlessandroAU commented 4 years ago

@UnTraDe This is a 2018 R9M TX Module

smaller09 commented 4 years ago

Another thought, maybe we can use R9M for the base, adding a 4in1 RF module. This module is for DEVIATIONTX. TB2WJA7sFXXXXXXXFXXXXXXXXXX_!!918558631 As R9M has a stm32f103cpu inside, all we need to do is connecting the spi / 4 io pins / power supply, and then port the software to it. As for T16 pro/TX16 which already has an internal 4in1 module, maybe we can trim a special firmware for R9M, just adding TBS CRSF

Dropsleutel commented 4 years ago

Possibly Allexandro's project might be one of the most interesting as it's open source, than it is just waiting for Jumper and or some manufacturars to make flashable small receivers cheaply, maybe jumper ? As they do produce hardware but not design there protocols/software ?

JyeSmith commented 4 years ago

@Dropsleutel that's a cool idea! Never thought of Jumper to manufacture some open source receivers.

Would be great to have an esp based nano Rx :heart:

pierrotm777 commented 4 years ago

For my test, i have build a DIY MPM module with a pro mini 5v board.

Do you think that was possible to adapt the RFM95W code to work with a pro mini board ?

rodrigosclosa commented 4 years ago

Hi guys, Sorry for the absence .. But my PCB's arrived from the 1W SX1276 adapter to the multiprotocol board ...

https://drive.google.com/file/d/17lkLhCMfKA6yBOe7DM0Bb2S5dezb_YNV/preview

How do I test the implemented code?

UnTraDe commented 4 years ago

@pierrotm777 I don't remember why right now, but the current code does not work with atmega based modules, but I think it can be adapter. You will probably need to disable other modules to free up space though.

@rodrigosclosa Cool! Try to connect the 4 SPI pins (MOSI, MISO, SCK, CS) and the 2 power pins (VCC, GND) to the multimodule. You can download the latest source code from the released page, and uncomment #define SX1276_INSTALLED and #define FRSKYR9_SX1276_INO in the _Config.h file. Then you should have FrSkyR9 option in the protocol menu at OpenTX. Just be careful of the power supply requirements, I don't know if the multimodule power supply can support that 1W module, you might want to test it with external power supply first. And don't forget to connect a compatible antenna!

rodrigosclosa commented 4 years ago

@UnTraDe right.. I did it! I have cloned this repository, made the changes you mention:

uncomment #define SX1276_INSTALLED and #define FRSKYR9_SX1276_INO in the _Config.h file.

Then, I read the Compilation and Build guide. I made my version, compiled with Arduino. Either , I sucessfully uploaded to my Multiprotocol board over USB, it flashed without errors.

So, I made all the internal connections and used an old Jumper 4-in-1 case to guard my breaking board. See pictures below:

https://www.icloud.com/sharedalbum/pt-br/#B0ZGY8gBYGaPcNc

Put everythning back togheter, It's turning on now. I can see the Led on my module lighted.

But in my model setup on OpenTX, dont have the option for R9M in Multiprotocol. I switched with every model available, and no one is for R9M. Is there any other thing to do?

I'm running OpenTX 2.3.5. I'll update now to 2.3.7...

berkerm4n commented 4 years ago

On 'FrSkyR9_sx1276.ino' file i see this line of code at line 142. SX1276_SetPaConfig(true, 7, 0); Why did you set output power to zero? I don't understant this line. Can we improve the code like original r9m to allow user to set output power?

pierrotm777 commented 4 years ago

@UnTraDe right.. I did it! I have cloned this repository, made the changes you mention:

uncomment #define SX1276_INSTALLED and #define FRSKYR9_SX1276_INO in the _Config.h file.

Then, I read the Compilation and Build guide. I made my version, compiled with Arduino. Either , I sucessfully uploaded to my Multiprotocol board over USB, it flashed without errors.

So, I made all the internal connections and used an old Jumper 4-in-1 case to guard my breaking board. See pictures below:

https://www.icloud.com/sharedalbum/pt-br/#B0ZGY8gBYGaPcNc

Put everythning back togheter, It's turning on now. I can see the Led on my module lighted.

But in my model setup on OpenTX, dont have the option for R9M in Multiprotocol. I switched with every model available, and no one is for R9M. Is there any other thing to do?

I'm running OpenTX 2.3.5. I'll update now to 2.3.7...

rodrigosclos, a thanks for your help. I can compile with success for a Pro Mini

Thanks

Pierre

pascallanger commented 4 years ago

I've just updated the code to hopefully add failsafe support along with quite some other changes. Since I don't have the hardware myself, can someone try it out and see if it still works and test failsafe? Remember the RX needs up to 40s to learn failsafe. New code: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/tree/FrSkyR9

@UnTraDe I'm puzzled by the protocol timing... From what I see in the specs, they run at 8ms for 8ch and 19ms for 16ch. Right now, we are at 19ms for 8ch and 40ms for 16ch... What I don't understand is that this should impact the hopping and therefore not work at all... So I'm wondering if their given specs are incorrect... On another note, I would like to add the power settings using the option field: 0=10mW, 1=25mW, 2=100mw, 3=200mW, 4=500mW, 5=1W and set range to 0.001mW. Do you have dumps on how the different power levels are set on the R9?

UnTraDe commented 4 years ago

@pascallanger I will probably be able to verify that the failsafe works in the next couple of days, I will update here when I do.

As for the protocol timing, that's the timing I got from the captures, you can see the parsed data here: (Look at the timestamp ts: XXXX in seconds of the SPI transfers writing to the FIFO register) output_8ch_no_telem.txt output_16ch_no_telem.txt

You can also see the raw capture with the DSView software (can be downloaded for free from here: https://www.dreamsourcelab.com/download/) 8ch_no_telem.zip

They have so many different firmware combinations and versions, so it might be different in different firmware configurations. Also, there might be an adaptive thing going on, when I tried to record some telemtry it switched between LoRa and FSK/OOK modes and sent/receive updates in irregular intervals.

As for the power, I can capture some stuff, but we will be limited to 200mW if I remember correctly, because above that you need a board with external amplifier. Maybe we could put a switch in the firmware for specifying if amplifier hardware exists or not.

pascallanger commented 4 years ago

@UnTraDe I've just looked at the txt files. The timing is even 20ms between the frames not 19.4ms. Which firmware combination and version are you working on? Is it ACCST Flex, FCC, EU? I'm also a bit lost in their stuff... For the power, we should even get an idea of what's the amplifier type is installed since it can boost to different levels isn't it? I've received one feedback that I've broken the R9 code in the branch linked above. I don't see what I've done wrong by a quick look at it but I'll give it another look.

UnTraDe commented 4 years ago

@pascallanger

I have the Flex firmware version 190117 on the R9M module (https://www.frsky-rc.com/r9m-2019/) And Flex firmware version 190201 installed on the R9 receiver (https://www.frsky-rc.com/r9/) Looking at the download page now I see that they renamed the tab "ACCST FIRMWARE", it used to be just "FLEX FIRMWARE", since the version number is the same I assume it is the same firmware.

If I remember correctly, the output power level can go up to 17dB or 20dB (around 100mW) without any external amplifier, anything above that needs an external amplifier. The module I ordered (RFM95) has no external amplifier, but there a lot of modules available. They also might require additional GPIO's from the STM32 side to operate.

I'll try to take a look at the new code soon, today I'm a bit swamped with work stuff :(

AlessandroAU commented 4 years ago

Sx1276 is limited to 50mw >1% duty cycle. On the r9 the power levels are controlled by a seperate i2c DAC and RF amplifier IC. I've experimented with those amplified Lora modules and found that they can't do much more than 250mw for continuous output. Also, for whatever reason they're easy to burn out. I've killed 3 by setting the sx1276 power output too high.

pierrotm777 commented 4 years ago

Hello all,

I try to completed the original schematic v2.3d with a rfm95w 100mW module. My schematic is that, but id don't know what pin use for cs on the atmega328 v2.3d&rfm95w.pdf

Thanks for your help.

Pierre

UnTraDe commented 4 years ago

@pierrotm777

Hi, I think we should connect the RFM module to the same SPI bus as the rest of chips, so we could free up the second SPI for more extensions. @pascallanger What do you think?

As for the CS pin, I'm not sure there is a free pin in the Atmega based multiprotocol modules.

pascallanger commented 4 years ago

For sure you must use the same SPI lines than all the other components being MOSI, MISO and SCK. The problem on the atmega is that there are no free pins to connect CS. So something has to give up... As an example, if you are not using one of the RF component (CC2500, NRF, CYRF, A7105) then disconnect the CS from that component (grounding it on the component) and assign it to the CS of the SX1276. From a code perspective it's then really easy to reaffect the pin. Pascal

pierrotm777 commented 4 years ago

Thanks Pascal. It's exactly that I shall do. I shall send my new schematic as soon as possible for check it with you. Pierre

pierrotm777 commented 4 years ago

Hello,

For use my Pro Mini with a RFM95W i use the CS pin used normally by the A7105 like that:

I have replaced in SX1276.ino file SPI_CSN_off by A7105_CSN_off and SPI_CSN_on by A7105_CSN_on. I use also now MISO,MOSI and SCK wires used by other modules. In the config.h, i comment the A7105 and uncomment SX1276.

Do i need to comment in Validate.h these lines? I suppose yes ?

if not defined(STM32_BOARD)

#undef SX1276_INSTALLED

endif

I am correct ?

Printing Impression Schématique.pdf

pascallanger commented 4 years ago

That should work for the A7105_CSN. You need to tell that the A7105 is not installed. And yes you need to comment the stuff in validate.h.

pierrotm777 commented 4 years ago

Thank :-) . Now i can cabling my module.

UnTraDe commented 4 years ago

@pascallanger I found out that the Jumper T18 is going to have a JP5IN1 multi module, which supports 915/868 MHz. Do you have an idea of what chip configuration they are gonna use? Maybe we should base the decision regarding power settings and amplifier support on that.

And do you know if they are intending to support FrSky R9, or some other custom protocol?

schwabe commented 4 years ago

The Bangood shop page say SX1276 and R9.

pascallanger commented 4 years ago

@UnTraDe I've received a preview module yesterday ;-) They are using a SX1276. The Amp is SKY65111-348LF: ISM 600–1100 MHz Band 2 Watt InGaP HBT Power Amplifier. There is a RF switch SKY13330 which is used for TX/RX. I agree let's try to set the power output using this setup. The R9 code runs on it. But the servo has some jitter time to time using a R9 Slim+ running Flex... I don't know if this is my latest change or not yet. But my modification to send the failsafe channels does not work. I've tried yesterday to dump the SPI on a R9M but my old Saleae 8ch running at 24MS/s is not enough to catch up with the speed of the SPI bus which is really annoying... Could you do a quick dump with failsafe enabled so I can see how it is implemented? Thanks, Pascal

pascallanger commented 4 years ago

@UnTraDe

As for the protocol timing, that's the timing I got from the captures, you can see the parsed data here: (Look at the timestamp ts: XXXX in seconds of the SPI transfers writing to the FIFO register)

That's not how the Multi timing works. It's using the callback time + the time you indicate to caluclate the next call back. In your screenshot the value that has to be used is the timing between each start of "packets" which looks to be 20ms from your dumps.

UnTraDe commented 4 years ago

@pascallanger

The R9 code runs on it. But the servo has some jitter time to time using a R9 Slim+ running Flex... I don't know if this is my latest change or not yet. But my modification to send the failsafe channels does not work.

I'll be able to test that later today.

I've tried yesterday to dump the SPI on a R9M but my old Saleae 8ch running at 24MS/s is not enough to catch up with the speed of the SPI bus which is really annoying... Which hw do you have to do the dumps?

That's the exact same problem I had when I started. I bought the DSLogic Plus from https://www.dreamsourcelab.com/product/dslogic-series/

I see now that they have even faster models.

Could you do a quick dump with failsafe enabled so I can see how it is implemented?

Sure, what setup do you want me to capture? (firmware versions, binding mode, etc)?

pascallanger commented 4 years ago

@UnTraDe

Sure, what setup do you want me to capture? (firmware versions, binding mode, etc)?

Latest Flex, 915 16CH no telem, failsafe set to custom and you could may be set the channels to different values (-100%,-50%,0%,+50%+100%) including hold and no pulse.

UnTraDe commented 4 years ago

@pascallanger

Latest Flex, 915 16CH no telem, failsafe set to custom and you could may be set the channels to different values (-100%,-50%,0%,+50%+100%) including hold and no pulse.

I've updated both the R9M and the R9 to the latest first from FrSky site. Mode: R9M Channels: 16 S.Port Link: Enabled (not sure what this means)? power: 10mW

Failsafe: custom 0: -100% 1: -50% 2: 0% 3: 50% 4: 100% all the rest are 0

Recorded from transmitter startup up to 1 minute. This is the text file from my parser: MOSI.zip Tell me if you need the raw capture file from DSView.

BTW, I've added an option to my parser to extract the channel data when there is a failsafe packet, this is what it printed for the above file:

[988, -1, -1, -1, -1, -1, -1, -1, -1, 1500, 1500, 1500, 1500, 1500, 1500, 1500]
[-1, 1244, 1500, 1500, 1500, 1500, 1500, 1500, 1500, -1, -1, -1, -1, -1, -1, -1]
[1658, -1, 1500, -1, -1, -1, -1, -1, -1, 1500, -1, 1500, 1500, 1500, 1500, 1500]
[-1, 1500, 1500, 1756, 1500, 1500, 1500, 1500, 1500, -1, -1, -1, -1, -1, -1, -1]
[1658, -1, -1, -1, 2012, -1, -1, -1, -1, 1500, 1500, 1500, -1, 1500, 1500, 1500]
[1660, 1500, 1500, 1500, 1500, 1500, 1500, 1500, -1, -1, -1, -1, -1, -1, -1, -1]
[1658, -1, -1, -1, -1, -1, 1500, -1, -1, 1500, 1500, 1500, 1500, 1500, -1, 1500]
[-1, 1500, 1500, 1500, 1500, 1500, 1500, 1500, 1500, -1, -1, -1, -1, -1, -1, -1]
[-1, -1, -1, -1, -1, -1, -1, -1, 1500, 1500, 1500, 1500, 1500, 1500, 1500, 1500]
[-1, -1, 1500, 1500, 1500, 1500, 1500, 1500, 1500, 1500, -1, -1, -1, -1, -1, -1]
[1658, -1, -1, -1, -1, -1, -1, -1, -1, 1500, 1500, 1500, 1500, 1500, 1500, 1500]
[1658, 1500, 1500, -1, 1500, 1500, 1500, 1500, -1, -1, -1, 1500, -1, -1, -1, -1]
[1660, -1, -1, -1, -1, -1, -1, -1, -1, 1500, 1500, 1500, 1500, 1500, 1500, 1500]
[-1, 1500, 1500, 1500, 1500, -1, 1500, 1500, 1500, -1, -1, -1, -1, 1500, -1, -1]
[1658, -1, -1, -1, -1, -1, -1, -1, -1, 1500, 1500, 1500, 1500, 1500, 1500, 1500]
[1658, 1500, 1500, 1500, 1500, 1500, 1500, -1, -1, -1, -1, -1, -1, -1, -1, 1500]
[988, -1, -1, -1, -1, -1, -1, -1, -1, 1500, 1500, 1500, 1500, 1500, 1500, 1500]
[1658, 1244, 1500, 1500, 1500, 1500, 1500, 1500, -1, -1, -1, -1, -1, -1, -1, -1]
[1660, -1, 1500, -1, -1, -1, -1, -1, -1, 1500, -1, 1500, 1500, 1500, 1500, 1500]
[1658, 1500, 1500, 1756, 1500, 1500, 1500, 1500, -1, -1, -1, -1, -1, -1, -1, -1]
[-1, -1, -1, -1, 2012, -1, -1, -1, 1500, 1500, 1500, 1500, -1, 1500, 1500, 1500]
[1660, 1500, 1500, 1500, 1500, 1500, 1500, 1500, -1, -1, -1, -1, -1, -1, -1, -1]
[1658, -1, -1, -1, -1, -1, 1500, -1, -1, 1500, 1500, 1500, 1500, 1500, -1, 1500]
[-1, 1500, 1500, 1500, 1500, 1500, 1500, 1500, 1500, -1, -1, -1, -1, -1, -1, -1]
[-1, -1, -1, -1, -1, -1, -1, -1, 1500, 1500, 1500, 1500, 1500, 1500, 1500, 1500]
[1658, -1, 1500, 1500, 1500, 1500, 1500, 1500, -1, 1500, -1, -1, -1, -1, -1, -1]
[-1, -1, -1, -1, -1, -1, -1, -1, 1500, 1500, 1500, 1500, 1500, 1500, 1500, 1500]
[1658, 1500, 1500, -1, 1500, 1500, 1500, 1500, -1, -1, -1, 1500, -1, -1, -1, -1]
[1658, -1, -1, -1, -1, -1, -1, -1, -1, 1500, 1500, 1500, 1500, 1500, 1500, 1500]
[-1, 1500, 1500, 1500, 1500, -1, 1500, 1500, 1500, -1, -1, -1, -1, 1500, -1, -1]
[1658, -1, -1, -1, -1, -1, -1, -1, -1, 1500, 1500, 1500, 1500, 1500, 1500, 1500]
[-1, 1500, 1500, 1500, 1500, 1500, 1500, -1, 1500, -1, -1, -1, -1, -1, -1, 1500]

Note the first 5 packets:

[ 988   -1   -1   -1   -1   -1   -1   -1   -1 1500 1500 1500 1500 1500  1500 1500]
[  -1 1244 1500 1500 1500 1500 1500 1500 1500   -1   -1   -1   -1   -1    -1   -1]
[1658   -1 1500   -1   -1   -1   -1   -1   -1 1500   -1 1500 1500 1500  1500 1500]
[  -1 1500 1500 1756 1500 1500 1500 1500 1500   -1   -1   -1   -1   -1    -1   -1]
[1658   -1   -1   -1 2012   -1   -1   -1   -1 1500 1500 1500   -1 1500  1500 1500]

Which looks like the correct values, (-100 -50 0 50 100)

P.S: The timestamp values are now in nanoseconds instead of seconds.

UnTraDe commented 4 years ago

@pascallanger

The R9 code runs on it. But the servo has some jitter time to time using a R9 Slim+ running Flex... I don't know if this is my latest change or not yet.

I've just compiled and uploaded the code from the FrSkyR9 branch, and rebinded the R9 receiver to it, and it seems to be working fine. I don't see any jitter: https://www.youtube.com/watch?v=Xf3HtkAU6Vo (Scope connected to the CH1/throttle of the R9) Maybe your TX has some jitter on the analog inputs? Or maybe it's the servo?

pascallanger commented 4 years ago

@pascallanger

Latest Flex, 915 16CH no telem, failsafe set to custom and you could may be set the channels to different values (-100%,-50%,0%,+50%+100%) including hold and no pulse.

I've updated both the R9M and the R9 to the latest first from FrSky site. Mode: R9M Channels: 16 S.Port Link: Enabled (not sure what this means)? power: 10mW

Failsafe: custom 0: -100% 1: -50% 2: 0% 3: 50% 4: 100% all the rest are 0

Recorded from transmitter startup up to 1 minute.

Ok I see the mistake. Failsafe should work now, I'll push an update.

pascallanger commented 4 years ago

@UnTraDe

I've just compiled and uploaded the code from the FrSkyR9 branch, and rebinded the R9 receiver to it, and it seems to be working fine. I don't see any jitter: https://www.youtube.com/watch?v=Xf3HtkAU6Vo (Scope connected to the CH1/throttle of the R9) Maybe your TX has some jitter on the analog inputs? Or maybe it's the servo?

No, this is more than just a small jitter. If I go to full deflection on aileron (where I have a servo connected), it goes there but time to time it just tries to go to the center and quickly come back. I'm thinking the center position is failsafe. Do you have failsafe enabled and set on your RX set from the R9M module? I'm guessing yes from the previous attempt...

UnTraDe commented 4 years ago

@pascallanger

Do you have failsafe enabled and set on your RX set from the R9M module? I'm guessing yes from the previous attempt...

Yeah it probably remembers the failsafe I set for the capture from the R9M module. But then shouldn't I see a jitter between the setpoint (1840 in the video) to 988 (0% which was what the CH1 failsafe was set to)?

pascallanger commented 4 years ago

I confirm failsafe is now working fine. But still bad jitter and not related to failsafe since I've change the failsafe value to full left and it still tries randomely to go to 0...

pascallanger commented 4 years ago

@UnTraDe Look at this video, I'm steady on the remote (I'm not shaking the stick in anyway): https://photos.app.goo.gl/tbW2UNvYfhjL6RQE6 As you can see there are some periods where it's all fine and suddenly it starts to shake. It's not failsafe as I thought because failsafe is set to full left as you can see at the end of the video but the servo tries to move to a center position. It's like the receiver does not get the right value somehow only time to time. It's cyclic: the servo is fine for a dozen of seconds, then shakes a few time, stops, shakes a few time, stops, shakes a lot, then the loop restarts fine for a dozen of seconds...

UnTraDe commented 4 years ago

@pascallanger

Look at this video, I'm steady on the remote (I'm not shaking the stick in anyway): https://photos.app.goo.gl/tbW2UNvYfhjL6RQE6 As you can see there are some periods where it's all fine and suddenly it starts to shake. It's not failsafe as I thought because failsafe is set to full left as you can see at the end of the video but the servo tries to move to a center position. It's like the receiver does not get the right value somehow only time to time.

Are you sure this is not an issue with the servo? I've tested it now with the multi-protocol, with failsafe set to "No set" (because you said the latest commit in the git had a problem with the failsafe) and it seems fine: https://www.dropbox.com/s/yfwduhn7dcdxgdf/VID_20200605_205553.mp4?dl=0 Code compiled from commit 83e1176296cdf90ed02859a414d8f3becba0656e

BTW this is the firmware I flashed on the receiver:

You have the same version?

pascallanger commented 4 years ago

@UnTraDe Can you try the latest code in the FrSkyR9 branch? This is what I'm testing. Failsafe works fine from my tests on this version. Same firmware version as you but for the R9 Slim+. It's not the servo or RX since with the R9M module that I have it works fine. I'm puzzled...

UnTraDe commented 4 years ago

@pascallanger Just tested with the latest commit, failsafe works fine (cool!), but there are still no jitters. What hardware are you testing it on? The one Jumper sent you? It might be a long shot, but maybe the RF switch and amplifier are interfering with the communication if they are not initialized properly (i.e if you their enable pins, etc are left floating). In my past experience with RF amplifiers, they need to be initialized to a known state. Anyway, it is more likely to have disabled the connection entirely if that were the case. BTW, you installed the FLEX version inside the zip right?

pascallanger commented 4 years ago

@UnTraDe True about the RF switch, I need to look on which pin it has been connected and configure it. I won't expect a loss of communication to do this kind of things but more that the servo will intermitently hold its position. The good news is that it works for you so at least we are on the right track! Yes I've flashed the Flex fw on the R9 Slim+ and R9M as well. I've been trying 915 so far. May be I should try 868.

UnTraDe commented 4 years ago

@pascallanger I'll try to see if I have some other R9 receiver model laying around. Do they have schematics available for the 5in1 module? BTW, if they have another spare prototype module to give out, I'd be happy to help with the amplifier code as well :)

pascallanger commented 4 years ago

@pascallanger I'll try to see if I have some other R9 receiver model laying around. Do they have schematics available for the 5in1 module? BTW, if they have another spare prototype module to give out, I'd be happy to help with the amplifier code as well :)

Contact me in PM. They gave me 2, I'm fine to send the other one to you. Could it be the TX ID? That's a difference between you and me for sure. What's your ID? Or better I can use the one from your dump. Pascal

UnTraDe commented 4 years ago

@pascallanger The TX ID from the dump is the R9M's ID: 0x04 0x3B How can I check the ID of the multiprotocol module? But I don't see why that should affect anything. Maybe it's not an ID after all? Although I have some capture from another R9M module and it seems that those 2 bytes ([1] and [2]) are the only difference.

pascallanger commented 4 years ago

@UnTraDe I confirm that the ID is not the issue. I've also set the extra pins (correctly?) that are in use in the 5-in-1 module but it doesn't work better. I'm wondering if it's because I'm on the bench with the TX and RX close together but once again I won't expect this kind of behavior from a loss of frame... I'm puzzled.

pascallanger commented 4 years ago

@UnTraDe You know what? You were right. I don't know how I've missed it... The problem is not the protocol where I've lost a day verifying everything dozen of times but the radio T18 which as soon as the module transmits all the analog inputs are getting crazy and move all around. I have the impression that the current required by the module (PA) is above what it can deliver or they have done a really bad job at filtering!

MicroMontis commented 4 years ago

Watch the similar issue with the Dragonlink and Jumper T16: https://youtu.be/71gSrZIOoJ4

Dragonlink adds jitter and even blocks the gimbals.

And the fix that helped - shielding with the copper tape: https://youtu.be/KdXZsqfb8rU

On Sat, Jun 6, 2020, 02:50 pascallanger notifications@github.com wrote:

@UnTraDe https://github.com/UnTraDe You know what you were right... I don't know how I've missed it... The problem is not the protocol where I've lost a day verifying everything but the radio T18 which as soon as the module transmits all the analog inputs are getting crazy and move all around. I have the impression that the current required by the module is above what it can deliver or they have done a really bad job at filtering!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/issues/303#issuecomment-639901851, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADZTJNKI72GIDDLRH7Z4JSDRVGADXANCNFSM4JVDW6MQ .

UnTraDe commented 4 years ago

Watch the similar issue with the Dragonlink and Jumper T16: https://youtu.be/71gSrZIOoJ4 Dragonlink adds jitter and even blocks the gimbals. And the fix that helped - shielding with the copper tape: https://youtu.be/KdXZsqfb8rU

Yeah those videos came to mind immediately after reading @pascallanger response, but I don't think the solution implemented there with the copper tape will help in this case, since the module is internal (unless the interference is from the antenna connected externally).

@pascallanger Did you enable the PA when it happened? Maybe it's a good idea to test it outside of the radio as well.

pascallanger commented 4 years ago

@UnTraDe and @MicroMontis Twisting all the cables within the T18 does help to reduce significantly the issue. But it's still there with a variation of some of the sticks of around 2-3% (it was 60% before). The module does not have a shield on the 900MHz part like it has on the 2.4GHz. Adding one could finish to solve the issue.

@UnTraDe Unless I'm wrong:

the code is set to minimum power output with 2dBm on the PA_BOOST pin: SX1276_SetPaConfig(true, 7, 0); -> the 0 sets it to 2dBm incrementing it up to 0xF would only increase the power output up to 20dBm. => the PA Absolute Maximum Rating input is 10dBm so the value must be limited to a max of 8
the PA can't be turned off/changed -> the gain is fixed Therefore I don't see a way to decrease the power of this module. You can increase the output but I'm not sure if the radio is designed to handle more current so I'm a little hesitant to try it out... I don't have a power meter to see how much it outputs currently but I've measured an input power of 1.55W. Usually there is a factor of 3-5 from input to output, so the output of the module is probably between 300mW and 500mW.

pascallanger / DIY-Multiprotocol-TX-Module

Add support for SX127X chips (TBS CrossFire, FrSky R9) #303

if not defined(STM32_BOARD)

endif