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

[UnTraDe]

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:

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

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.

[pascallanger]

This is totally possible. The DIY module PCB has been designed with this in mind providing a connector with a full SPI bus + power supply. I remember that the Banggood 4-in-1 and iRangeX IRX4 / IR4+ modules have the port as well. So it's basically just a matter of running a few wires to hook it up.

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'm usually looking at the regular use (ignoring telemetry). First looking at the packets content to locate the channels, presence of a CRC, counter... Then jumping quickly to the hopping RF channels to see what the cycle is and if there is any patterns. Next quick look on the bind sequence to see if it contains the channels, TX ID, negotiation between the TX and RX or only 1way... And move forward from there to implement something in Multi.

I can also try to capture on-air data with SDR, but that would probably take longer to decode.

That's usually unneeded when you have access to the SPI bus.

Pascal

[UnTraDe]

I found a good spot to tap into the SPI, there are 4 resistors close to the edge of the board beside the SX1276 chip:

I checked the SPI speed with an oscilloscope, it's 18 MHz. Unfortunately my old logic analyzer can only get a 20ms window at those speeds (it can't stream over USB without missing some packets). I've ordered a new one that should work, so it will probably take a bit of time before I can continue decoding. In the meanwhile I wrote a small python script to parse the logic analyzer output to a more friendly format, this is the result of the first 20ms of starting up my Taranis X9D+ with a bound model selected and the R9M in the module bay:

write (1 bytes) reg 0x01 (OpMode):
        0x80
write (1 bytes) reg 0x01 (OpMode):
        0x81
write (2 bytes) reg 0x40 (DioMapping1):
        0x00 0x00
read (111 bytes) reg 0x01 (OpMode):
        0x81 0x1a 0x0b 0x00 0x52 0x6c 0x80 0x00 0x4f 0x09 0x2b 0x20 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10 0x00 0x00 0x00 0x00 0x72 0x70 0x64 0x00 0x08 0x01 0xff 0x00 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x50 0x14 0x45 0x55 0xc3 0x05 0x27 0x1c 0x0a 0x03 0x0a 0x42 0x12 0x52 0x1d 0x00 0xaf 0x00 0x00 0x00 0x00 0x12 0x24 0x2d 
0x00 0x03 0x00 0x04 0x23 0x00 0x09 0x05 0x84 0x32 0x2b 0x14 0x00 0x00 0x11 0x00 0x00 0x00 0x0f 0xe0 0x00 0x0c 0xfb 0x08 0x00 0x5c 0x78 0x00 0x1c 0x0e 0x5b 0xcc 0x00 0x01 0x50 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0b
read (1 bytes) reg 0x42 (Version):
        0x12
read (111 bytes) reg 0x01 (OpMode):
        0x81 0x1a 0x0b 0x00 0x52 0x6c 0x80 0x00 0x4f 0x09 0x2b 0x20 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10 0x00 0x00 0x00 0x00 0x72 0x70 0x64 0x00 0x08 0x01 0xff 0x00 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x50 0x14 0x45 0x55 0xc3 0x05 0x27 0x1c 0x0a 0x03 0x0a 0x42 0x12 0x52 0x1d 0x00 0xaf 0x00 0x00 0x00 0x00 0x12 0x24 0x2d 
0x00 0x03 0x00 0x04 0x23 0x00 0x09 0x05 0x84 0x32 0x2b 0x14 0x00 0x00 0x11 0x00 0x00 0x00 0x0f 0xe0 0x00 0x0c 0xfb 0x08 0x00 0x5c 0x78 0x00 0x1c 0x0e 0x5b 0xcc 0x00 0x01 0x50 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0b
write (111 bytes) reg 0x01 (OpMode):
        0x81 0x1a 0x0b 0x00 0x52 0x6c 0x80 0x00 0x4f 0x09 0x2b 0x20 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10 0x00 0x00 0x00 0x00 0x72 0x70 0x64 0x00 0x08 0x01 0xff 0x00 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x50 0x14 0x45 0x55 0xc3 0x05 0x27 0x1c 0x0a 0x03 0x0a 0x42 0x12 0x52 0x1d 0x00 0xaf 0x00 0x00 0x00 0x00 0x12 0x24 0x2d 
0x00 0x03 0x00 0x04 0x23 0x00 0x09 0x05 0x84 0x32 0x2b 0x14 0x00 0x00 0x11 0x00 0x00 0x00 0x0f 0xe0 0x00 0x0c 0xfb 0x08 0x00 0x5c 0x78 0x00 0x1c 0x0e 0x5b 0xcc 0x00 0x01 0x50 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0b
read (1 bytes) reg 0x31 (DetectOptimize):
        0xc3
write (1 bytes) reg 0x31 (DetectOptimize):
        0xc5
read (1 bytes) reg 0x1e (ModemConfig2):
        0x70
write (1 bytes) reg 0x1e (ModemConfig2):
        0x60
read (159 bytes) reg 0x1d (ModemConfig1):
        0x72 0xe3 0x72 0xe3 0x60 0xe3 0x60 0xe3 0x04 0xe3 0x04 0xe3 0x08 0xe3 0xc5 0xe3 0x0a 0xe3 0x20 0xe3 0x00 0xe3 0x4f 0xe3 0x4f 0xe3 0x84 0xe3 0xcf 0xe3 0x84 0xe3 0xcf 0xe3 0x87 0xe3 0xcf 0xe3 0x81 0x1a 0x0b 0x00 0x52 0x6c 0x80 0x00 0xff 0x09 0x2b 0x23 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10 0x00 0x00 0x00 0x00 0x73 0x60 
0x64 0x00 0x08 0x01 0xff 0x00 0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x50 0x14 0x45 0x55 0xc5 0x05 0x27 0x1c 0x0a 0x03 0x0c 0x42 0x12 0x52 0x1d 0x00 0xa1 0x00 0x00 0x00 0x00 0x12 0x24 0x2d 0x00 0x03 0x00 0x04 0x23 0x00 0x09 0x05 0x87 0x32 0x2b 0x14 0x00 0x00 0x11 0x00 0x00 0x00 0x0f 0xe0 0x00 0x0c 0xfb 0x08 0x00 0x5c 0x78 0x00 0x1c 0x0e 0x5b 0xcc 0x00 0x01 0x50 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0b 0xe3 0xff 0xe3 0xff 0xe3 0x87 0xe3 0xff 0xe3 0x87

I'll also try to capture some data while it's communicating with the R9, I hope 20ms is enough to cover a full cycle.

[pascallanger]

Good job. I don't think 20ms is going to be enough to make tests. We need a couple of seconds at least so you have the time to move a stick for example but also see the freq hopping pattern repeating itself.

[UnTraDe]

A small update, I finally got the new logic analyzer so I'm able to continue working on this. If anyone's interested, I've uploaded the code for translating logic analyzer captured data to a more user friendly format (separate the SPI data into frames, add labels for register name and specify whether it is a read or write operation): https://github.com/UnTraDe/SX1276_capture_decoder Should work on CSV files generated from DSLogic's DSView (and possibly Sigrok, but I haven't tested it yet) Example of a capture: R9M running Flex firmware, bound to an R9 receiver with 8 channels and no telemetry, sampled @ 100MHz over 671.09ms (output of the translation code also included) caps.zip

In that capture, the following pattern is repeating itself:

write (1 bytes) reg 0x01 (OpMode):
    0x83 
write (1 bytes) reg 0x01 (OpMode):
    0x81 
write (1 bytes) reg 0x11 (IrqFlagsMask):
    0xbf 
write (2 bytes) reg 0x40 (DioMapping1):
    0x00 0x00 
write (1 bytes) reg 0x22 (PayloadLength):
    0x0d 
write (1 bytes) reg 0x0d (FifoAddrPtr):
    0x00 
write (1 bytes) reg 0x01 (OpMode):
    0x85 
write (1 bytes) reg 0x01 (OpMode):
    0x81 
write (1 bytes) reg 0x09 (PaConfig):
    0xf0 
write (3 bytes) reg 0x06 (FrfMsb):
    0xe6 0xc0 0x00 
write (1 bytes) reg 0x22 (PayloadLength):
    0x1a 
write (1 bytes) reg 0x0e (FifoTxBaseAddr):
    0x00 
write (1 bytes) reg 0x0d (FifoAddrPtr):
    0x00 
write (26 bytes) reg 0x00 (Fifo):
    0x3c 0x04 0x3b 0x10 0x08 0x10 0x00 0x00 0x00 0xd1 0x3f 0x06 0x04 0x40 0x00 0x04 0x40 0x00 0x04 0x40 0x08 0x00 0x00 0x00 0xab 0xad 

OpMode register is setting the radio mode (modulation type, sleep, low/high power) FrfMsb register is the MSB of the RF carrier frequency

And I guess the FIFO writing part contains the 8 channels data, I will soon make a capture while moving the sticks to confirm it

[UnTraDe]

I'm currently in the process of writing an initial code for the stm32 based multi-protocol module. I've set up and radio and everything, I just have a hard time to figure out the CRC algorithm they use. It looks like that last two bytes are CRC (I might be wrong though), I've tried multiple CRC16 variations with no luck. Is there any known CRC algorithm FrSky is using? Any help would be appreciated!

Here are some samples (including the suspected CRC in the last 2 bytes):

3C043B040B10000000A13F0604400004400004400800000002A0
3C043B0F0B10000000088000088000088000088008000000A7C6
3C043B1A0B10000000A13F0604400004400004400800000036CE
3C043B080B10000000088000088000088000088008000000F1AD
3C043B130B10000000A13F060440000440000440080000000EE1
3C043B010B10000000983F000880000880000880080000001894
3C043B0C0B10000000018006044000044000044008000000F193
3C043B170B10000000A83F000880000880000880080000000EDF
3C043B050B10000000913F050440000440000440080000005E68
3C043B100B10000000088006048000088000088008000000C9C6
3C043B1B0B10000000A13F000840000440000440080000006CA0
3C043B090B10000000088006048000088000088008000000ABC3
3C043B140B10000000A13F00084000044000044008000000124D
3C043B020B1000000008800604800008800008800800000091CD
3C043B0D0B10000000A13F000840000440000440080000007048
3C043B180B10000000088006048000088000088008000000E140
3C043B060B10000000913F080440000440000440080000000A2C
3C043B110B10000000783F06048000088000088008000000B9E4
3C043B1C0B10000000A13F000840000440000440080000003ACB
3C043B0A0B10000000088006048000088000088008000000B94B
3C043B150B10000000A13F0008400004400004400800000002E4
3C043B030B10000000088005048000088000088008000000C7A6
3C043B0E0B10000000A13F060440000440000440080000002807
3C043B190B10000000088000088000088000088008000000BB2E
3C043B070B10000000A13F060440000440000440080000001028
3C043B120B10000000983F000880000880000880080000005036
3C043B000B100000000180060440000440000440080000009DF6
3C043B0B0B10000000983F000880000880000880080000003233
3C043B160B10000000A13F060440000440000440080000005AAB
3C043B040B100000000880000880000880000880080000009DC8
3C043B0F0B10000000A13F06F43F00044000044008000000BB04

P.S What I managed to "decode" so far: 3 bytes[0:2] - seems to be a header of some sort (it is always the same even after rebinding) 1 byte[3] - the index to the next channel hope 4 byte[4:7] - not exactly sure

the following bytes (up to the last 2) seems to be the channels

EDIT

After a lot of trial & errors, reading about CRC, trying different methods for brute force and running samples through "CRC Reveng" (a program for reverse engineering CRC's...) I finally found it! It is actually the same algorithm used in FrSkyX, implemented here. It was one of the first that I tried, but apparently I had to swap the CRC's MSB/LSB.

Just out of curiosity, how did you find that CRC algorithm?

[UnTraDe]

Another update, I managed to get a initial working firmware that can bind and send channel data: https://youtu.be/HzVBL_GIwPI

The firmware is available here: https://github.com/UnTraDe/SX1276_capture_decoder

I think it's ready to start integrating into the Multi-protocol project. How should I go about connecting the RFM95 module to the Multi-protocol over SPI? And which module is the "official" one? I currently have the iRange IRX4.

[pascallanger]

The IRX4 is a good one since you have an extra SPI port with pinouts available on the PCB just for this exact purpose. So it should be quite easy to integrate right away in the current code.

[UnTraDe]

@pascallanger I started merging the code with the Multiprotocol firmware (checked out the latest master branch today), and I got a basic version working (only 8 channels and binding) : https://youtu.be/awcriis2tE8

Adding the new chip was pretty straight forward, just some definitions and a small SPI abstraction, but as you can see from the video I currently "borrowed" the protocol number 63 from XN297DUMP, since I couldn't go past 63 in the model setup menu in OpenTX.

PROTO_XN297DUMP = 64,   // =>NRF24L01
PROTO_FRSKY_R9  = 63    // =>SX1276

I also tried to add a new protocol option in Multi_Names.ino, but that didn't work either. My guess is that it needs to be added in the OpenTX side?

Also, I had some trouble understanding the units of time that remote_callback returns. I had to hack around a bit to get the timing good enough for the R9 recevier to not lose sync.

Is there any documentation about those kind of stuff? I couldn't find any in the docs folder.

[pascallanger]

You need OpenTX 2.3.5 or more to go past the protocol 63 and use multi names... Please use the entry 65, since I'm using 64 for the latest FrSky X v2 in the latest version. The unit of time in remote_callback are µs (microsec) so return 9000=call me back in 9ms Thanks, Pascal

[pascallanger]

I've modified your code, validation and updated the documentation in my last push. Can you verify that everything is still ok? I'm puzzled by the channels. This protocol looks to support 16 channels. The only thing that you need to do is to add a channel_offset of 0 (lower) or 8 (upper) with a xor on every packet (FrSkyX_scaleForPXX is already taking care of the upper flag). Like FrskyX this could be done using different subprotocols for 8 and 16 CH. Should I give it a go? Or I'm totally wrong? Pascal

[UnTraDe]

I've just tested the code from the master branch with your changes, and it works exactly the same as before. As for the upper 8 channels, I think it works exactly the same as FrskyX. But my current setup is just connecting the PWM channels of the R9 to an oscilloscope, and it only has 8 PWM channels. I need to setup a flight controller with SBUS and see the rest of the channels with Betaflight configurator or something. You're welcome to try, I'm pretty sure it would work.

[rodrigosclosa]

Great job! About the hardware design, anyone has making a new version to accomplish SX127x chips?

Em sex., 24 de jan. de 2020 às 08:35, Tomer Abramovich < notifications@github.com> escreveu:

I've just tested the code from the master branch with your changes, and it works exactly the same as before. As for the upper 8 channels, I think it works exactly the same as FrskyX. But my current setup is just connecting the PWM channels of the R9 to an oscilloscope, and it only has 8 PWM channels. I need to setup a flight controller with SBUS and see the rest of the channels with Betaflight configurator or something. You're welcome to try, I'm pretty sure it would work.

— 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?email_source=notifications&email_token=AABKLWOTKEYXTUA32MCTC4LQ7LHAJA5CNFSM4JVDW6M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ2QSNA#issuecomment-578095412, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABKLWPDZ2C7DG6QZPWQ3XDQ7LHAJANCNFSM4JVDW6MQ .

--

Rodrigo Sclosa • Arquiteto de Software

rodrigo.sclosa@gmail.com (19) 99292.6385

facebook.com/rodrigo.sclosa

[pascallanger]

I've modified the code. By default it's now sending 16 channels and using subprotocols you can switch to 8 channels. It shouldn't change anything on your 1-8 ch PWM outputs.

[pascallanger]

Great job! About the hardware design, anyone has making a new version to accomplish SX127x chips? All DIY and iRangeX modules and may be some others have been built with a future expansion port which is what we are using here to connect a daughter board for the SX1276.

[UnTraDe]

@rodrigosclosa I don't mind doing it myself. But it looks like there going to be a lot of shuffling required to fit an RFM95 module in the existing design, so maybe designing a new one would be the way to go? There's also the question of RF power, the SX1276 alone can do up to 20 dBm (100mW), but the R9M module can do up to 1W using an RF amplifier (which will require even more space). Not sure if it's needed though, 100mW @ 915-868MHz with LoRa modulation can get pretty far as is.

I've modified the code. By default it's now sending 16 channels and using subprotocols you can switch to 8 channels. It shouldn't change anything on your 1-8 ch PWM outputs.

@pascallanger I've connected the R9 module to an FC running iNav, and there's something weird going on with the channels. When "915MHz" mode is selected it seems to control channels 1-6 and 9-14, and when 915 8ch mode is selected, all the channels are not responding.

I've re-tested with the previous commit (before the 16CH mode) and it looks like only channels 1-6 are moving. I'm currently trying to figure out what's going on

[rodrigosclosa]

@UnTraDe cool .. excellent work on the R9M code ... I have knowledge in this area of ​​electronics and I studied the original project of the Multiprotocol. It is very simple, maybe I will create a new version of the hardware supporting the SX1276 .. The mini version is only 100mw, but there is the F30 version that has 500mw, which I believe is sufficient.. But there is also the 1W version: https://www.nicerf.com//product.aspx?cid=193&id=269

In terms of size, they are small .. It could be done as an expansion card as @pascallanger commented...

I ordered some 100mW and 500mW chips to do some tests and see if I can help you with that...

[UnTraDe]

@pascallanger I found the bug, the loop filling the channels stopped early and missed the last 3 bytes, that's why it was 1-6 and 9-14 (2 groups of 6 channels instead of 8). Channel 16 still doesn't seem to respond, I suspect that over SBUS it's used for RSSI. I've created a pull request with the fix (tested on both 915MHz and 8ch mode). As for the second part, the "915 8ch" probably did work before, I just didn't notice that when you change subprotocol it resets the Receiver No. Is that on purpose?

@rodrigosclosa Yeah I think a daughter board can be a good solution. Although the iRangeX module's case blocks the expansion port, and at least the ones I got didn't solder the pins to it. Also, note that the link that you sent is for the SX1278 module (which I think is air-compatible, but not sure) and that it's for 433/490 MHz. If there's a nice module with built in amplifier that would be perfect. Just need to make sure that if we go in the daughter-board direction, the existing power supply can handle it.

[rodrigosclosa]

@pascallanger nice! Ah yes, the link I sent was just to show that there is the option of 1W, but I only found 433 / 490mhz. What I think would be ideal: http://curtocircuito.com.br/datasheet/modulo/LoRa1276F30.pdf

This module, according to the datasheet consumes only 450mA at 500mW @ 868mHz .. I believe it will be above the maximum current of the AMS1117 ... Maybe putting a power regulator stage on the daughter board for the SX1278 would be the way ...

Taking advantage, can you shed some light on opening the original schematics and PCBs? I downloaded it to try to open it, but it gives KiCad an error that prevents it from opening .. I managed to import the SCH from STM32 in EasyEDA (I usually use it due to the ease of sharing the project and having the board made on JLCPCB.com), but the PCB cannot be opened. I need to study the scheme to see the best option to connect the SX1276 ...

[rodrigosclosa]

@UnTraDe I'm looking at the code to search where is the CS pins definitions and I think that is missing a CS pin definition for SX1276 here:

//CS pins

define CC25_CSN_pin PB6 //CC2500

#define NRF_CSN_pin     PB7                             //NRF24L01
#define CYRF_RST_pin    PB8                             //CYRF RESET
#define A7105_CSN_pin   PB9                             //A7105
#define CYRF_CSN_pin    PB12                            //CYRF CSN
#define SPI_CSN_pin     PA15

File: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Multiprotocol/Pins.h

[UnTraDe]

@rodrigosclosa I think that the STM32 project is made using Eagle. If I remember correctly KiCad added the option to import Eagle files in KiCad 5. I also use KiCad for PCB's but I haven't tried to open the Eagle files with it, for electrical connections I just looked at the JPG of the schematics in the folder.

Regarding the CS pin definition, currently the code is using SPI_CSN_pin:

This is my current setup:

[rodrigosclosa]

@UnTraDe Oh I understood... Looking at Pin.h calmly, I could understand ..

On your external connection, did you connect the DIO0 pin on the SX1276? I was reading in the manual and some examples, it seems to me that it is necessary ... Or were you able to function normally without it?

I have a Jumper 4-in-1 module here that came with my T16 .. I'll take a look at it, but I don't remember seeing an empty ICSP pad on the board ... But if you have, I thought about making the board with the SX1276 to fit it directly ...

[UnTraDe]

@rodrigosclosa According to the data I captured from the R9M module, it seems that the only interrupt they are using is RxDone on DIO0. So it is only relevant for reception (i.e telemetry). I'm currently working on adding telemetry support, and it seems that it could be "bypassed" by enabling RXCONT mode and waiting some time, then querying the IRQ register to see if RxDone was enabled (a.k.a polling). It will probably be less efficient than waiting for interrupt, but I think it will be reliable.

I'm not familiar with the module that the T16 ships with, the iRangeX 4-in-1 module has this group of 6 pins exposed:

Maybe @pascallanger knows more about the version that ships with the T16?

[rodrigosclosa]

@UnTraDe It looks like the Jumper module is another layout. See the pictures:

https://drive.google.com/file/d/0B0xypZ_5kK2WSVYweXBuaG9oeGhRTjczdXJkV2tUYVhNa3Q4/preview

https://drive.google.com/open?id=0B0xypZ_5kK2WMmJDa1QxTzlldnhUNVBtLUFQckprSE1paW5j

I think I will need to make two models of daughter board, one for the 2x3 connector and the other for this 1x5 connector of the Jumper multiprotocol.

Or, I was thinking of making only the daughter board, without any connector for the person to solder. What do you think @pascallanger?

[rodrigosclosa]

@UnTraDe @pascallanger take a look at the initial schematic and PCB i've made for a 100mW and 500mW Lora versions:

100mW Version: https://easyeda.com/rodrigo.sclosa/sx1278f30-board_copy

500mW Version: https://easyeda.com/rodrigo.sclosa/sx1278f30-board

Both has a 5V regulator exclusivelly for it and a filter section made by capacitors, to ensure a good quality power source... The 500mW version was made to fit into the Multiprotocol housing, on top of the module metal housing.. I think a 1mm ticker PCB is enought and a glue tape can hold it...

And they can also be ordered from JLCPCB.com and already practically assembled with the SMT Assembly service, lacking only the Lora1276 module and the UF.L connector of the antenna that they don't have ... And at a really very cheap price!

What do you think? Please give me any feedback...

[UnTraDe]

@rodrigosclosa Looks good!

• Where will the 5V regulator get it's power from? The 6-pin 2x3 connector that I have on my module exposes 3.3v, which is after the regulator.
• I think SMA connector might be better, unless you mean to use a UF.L to SMA extension cable like in the iRangeX modules?
• I think it would be better to have the modules connectable to the extension power without soldering, not everyone has a soldering iron :)

And another thing, there's this module: https://www.hoperf.com/modules/lora/RFM95P.html that can do 1W, did you see it?

[rodrigosclosa]

@UnTraDe Nice! Answering your questions:

• The Lora module needs 5v to work, a good source of energy. From the 2x3 connector it will not be possible to take the power. Then it will be necessary to connect the main input coming directly from the radio through the 1x5 connector. The Lora module board has its own regulator that supports up to 1A, with capacitors to stabilize and filter out energy noise. Even the 500mW Lora module consumes only 480mA, there is a safety current margin.

• Exactly, to reduce the size and fit inside the box of the 4 in 1 module, I designed to use a UF.L cable for SMA ... I think that a soldered SMA connector on the board would take up a lot of space and would not match the existing fittings .

• Initially I also thought it would be better to connect to the port directly. But the problem is that according to my measurements, it will not fit inside the box of the current module. The height of the 2x3 male and female connector will not let the housing cover close. It would be ideal, but then we also have the problem of the energy needing to come straight from the input through the 1x5 connector. I think this Mod to support the R9M line is a little more advanced for beginners, needing a more detailed documentation and tutorial on how to do it. But I don't think it's that difficult, it just takes a little more work.

I want to have some of these plates made at JLCPCB, but as they are in the Chinese New Year, only after the 1st of February. I will need to wait a while to be able to test them... I have already ordered some Lora1276F30 modules to test in the meantime...

I saw this module that you posted.. Interesting... The problem is the cost of it.. I was only able to find a store on Aliexpress at a cost of U $ 21.6 each (https://pt.aliexpress.com/item/32801975345.html?spm=a2g0o.productlist.0.0.364c39a0zwngUn&algo_pvid=0bce12b0-0c9a-4f61-98dd-6085f1443813&algo_expid=0bce12b0-0c9a-4f61-98dd-6085f1443813-19&btsid=a8a57056-e056-41b0-8bf4-0ee591ba755d&ws_ab_test=searchweb0_0,searchweb201602_6,searchweb201603_53) Very expensive i think...

The NiceRF module, 500mW Lora1276F30 costs U $ 24.60 a pair, (https://pt.aliexpress.com/item/32646645489.html?spm=a2g0o.productlist.0.0.267f6d4080E8PP&algo_pvid=6a386bec-590a-45e4-8b60-9d5218e38065&algo_expid=6a386bec-590a-45e4-8b60-9d5218e38065-1&btsid=d02a6750-a9a9-48f3-8333-0753e9340cbb&ws_ab_test=searchweb0_0,searchweb201602_6,searchweb201603_53) This module you sent is interesting for a 1W version, of course at a higher cost....

[tipouic]

Hello everyone, already good work. I prefer to have a daughter card because it will allow you to add another transmitter later.

@rodrigosclosa If you need a good power supply for the Lora module, in the iRangeX module, it is possible to solder a 2x4 connector on the free SPI port with 2 angled pins in order to add power to the battery. So we go back a bit to DIY. It will then be possible to create a new cover as well as a blocking system for future daughter cards. On the image, the location is for a 2x3 connector but I have enlarged to have a 2x4 connector (in red).

[linuxguy123]

Great work, guys.

You might be interested in this, which is UART based, FCC certified, but 433 MHz. https://www.aliexpress.com/item/32791508935.html?spm=a2g0o.store_home.productList_140007895.subject_1

Or this, which is FCC certified, UART based and 915MHz, but only 100ish mW https://www.aliexpress.com/item/32791688496.html?spm=a2g0o.store_home.productList_140007895.subject_3

Or this, which 915 MHz, 1 Watt, SPI based but might not be not FCC'd. https://www.aliexpress.com/item/32919771141.html?spm=a2g0o.store_home.productList_140007892.subject_1

What can I do to help this project ? Seems like you guys have it figured out.

Are "we" going to design an open receiver as well ?

[linuxguy123]

http://www.ebyte.com/en/product-view-news.aspx?id=453

It is FCC'd already.

Only does 10Mbps on SPI ?

[UnTraDe]

@linuxguy123 I suspect that the UART is acting like a bridge, so it will not be suitable. As for the rest of the modules, I just noticed they are based on the SX1262 chip, which we need to make sure it is air compatible with the SX1276 first. BTW I don't know if it matters whether it is FCC certified or not, because if we want to be FCC certified we'll have to certify the entire "product" as well.

10 MHz SPI is more than we need :)

[gretel]

btw - rumor has TBS' FreedomTX fork of OpenTX will be backported (early this year) containing "quite a bunch" of changes reducing latency of most protocols including csfr.

[AlessandroAU]

UART based modules are not applicable. They have their own MCU inside and implement some proprietary over the air RF protocol. They are only useful as transparent UART bridges.

DIO0 should absolutely be included in the wiring, it does a lot of useful things such as indicating when RSSI crosses a threshold or when a valid header/sync is received etc. This can be done 'blind' but excessive polling of the SPI bus reduces the sensitivity of the RF stage.

I have developed my own sx1276 based RF link, it currently runs at up to 200hz packet rate using lora modulation. I have developed a custom RX design based on ESP8266/8285 but my code can also be flashed onto a standard Frsky R9MM module which runs a stm32f103. Perhaps my experiences might be helpful, I am happy to join this and provide input.

My ultimate goal is to have a sx1276 baked into a whoop board like we have with the cc2500.

https://github.com/AlessandroAU/ExpressLRS/tree/ExLRSV1.1-EspRX-and-R9MM https://www.rcgroups.com/forums/showthread.php?3437865-ExpressLRS-DIY-LoRa-based-race-optimized-RC-link-system

[linuxguy123]

@UnTraDe I suspect that the UART is acting like a bridge, so it will not be suitable.

I concur.

As for the rest of the modules, I just noticed they are based on the SX1262 chip, which we need to make sure it is air compatible with the SX1276 first.

Should be, but never assume anything.

BTW I don't know if it matters whether it is FCC certified or not, because if we want to be FCC certified we'll have to certify the entire "product" as well.

I don't think you have to certify if you use these modules as is. I think the shielding and such is compliant if used as designed, ie with an appropriate antenna. That is the benefit of using a precertified module, versus a non certified component.

10 MHz SPI is more than we need :)

Agreed, but I thought I saw other components were communicating at a much higher data rate ?

[linuxguy123]

UART based modules are not applicable. They have their own MCU inside and implement some proprietary over the air RF protocol. They are only useful as transparent UART bridges.

I did not know this. I assumed they would just bridge UART <--> SPI port.

This can be done 'blind' but excessive polling of the SPI bus reduces the sensitivity of the RF stage.

Really ? RF Interference ?

I have developed my own sx1276 based RF link, it currently runs at up to 200hz packet rate using lora modulation. I have developed a custom RX design based on ESP8266/8285 but my code can also be flashed onto a standard Frsky R9MM module which runs a stm32f103.

Impressive !

[linuxguy123]

I am very distracted working on another project these days. I'll check back from time to time. Message me directly if I can be of help.

[pascallanger]

DIO0 should absolutely be included in the wiring, it does a lot of useful things such as indicating when RSSI crosses a threshold or when a valid header/sync is received etc. This can be done 'blind' but excessive polling of the SPI bus reduces the sensitivity of the RF stage.

We won't do excessive polling since like for all other rf components, we just look at the last minute if a packet has been received. So basically there is one pole and that's it. Anyway, there is no additional entry pin on an iRangeX or JP4in1 unless you start to remove some hardware. Pascal

[UnTraDe]

@AlessandroAU Your project looks awesome! Any experience you have with the SX1276 chips will help alot! Today I'll finally have some free time to continue working on adding telemetry support, hopefully I'll be able to verify that the solution without the DIO0 that @pascallanger suggested works fine. And what do you mean by degraded RF performance? Because of constant EMI from the SPI lines or keeping the SX1276 chip busy? Also, do you know if the R9M module uses DIO0 (or any other DIO)?

[AlessandroAU]

@UnTraDe I can confirm both the r9mm Rx and r9m tx use dio0

[rodrigosclosa]

@UnTraDe I've included DIO0 pin in my breaking board design for SX1276... The only thing is, where to wire it... Maybe to remap one output pin in code for this use with SX1276...

[UnTraDe]

Just a small update, I've found something interesting regarding the telemetry. Apparently when the transmitter detects that a receiver is active (send telemetry back) it switches to FSK/OOK mode instead of LoRa! Does that mean that with telemetry enabled in the R9 system you get less range? Has anybody else encountered that?

I caught the transition between the modes, here's the output of my parser: output.txt

@AlessandroAU Did you try using that mode before in your project? Does it affect range significantly?

@rodrigosclosa We need to check if in the existing schematics there is a free pin, but in either case connecting DIO0 might mean redesign of the PCB instead of extending it via the SPI port.

[pascallanger]

Do you have an International or EU firmware? I think there is a note on their web site stating that when telemetry is on you have reduced features with the EU version. Pascal

[UnTraDe]

I have the Flex firmware version 190117 installed on the R9M module, downloaded from this page: https://www.frsky-rc.com/r9m-2019/

And Flex firmware version 190201 installed on the R9 receiver: https://www.frsky-rc.com/r9/

This version allow you to choose mode in your radio (915MHz, 868MHz, FCC, EU), I'm running 915 MHz right now.

[pascallanger]

I don't own any of these products so I don't know but they are quite insisting on FCC/EU differences: Telemetry mode（25mW）/non-telemetry mode（200mW / 500mW） (LBT Version) Check the Features and Specifications tabs: https://www.frsky-rc.com/product/r9m-2019/ What you suggest looks like LBT siwtching between the 2 modes...

[UnTraDe]

Yeah they kinda made a mess with all the different firmwares and modes. But as far as I understood it, the "regular" firmware allows you to select between EU and FCC regions, and the Flex firmware adds additional 2 modes, 868MHz and 915MHz, which I assume do not have the limitations that the EU and FCC certifications impose. Also, I don't think it matters for LBT, because you can implement it in both modes, it's just different modulation techniques.

[MartinHugh]

Could the reason for no telemetry @500mW simply be that the legal 868Mhz 500mW band is very narrow compared with the 25mW band ?

[IllusionFpv]

@UnTraDe r9m start in FSK and after some distance switch to lora

[UnTraDe]

@MartinHugh I don't know what the laws regarding the power and 868MHz band in the EU are, but if what you say it's true it does sound logical that they would prefer to disable telemetry instead of sharing a narrow band with the uplink channel.

@IllusionFpv That's interesting, I wonder why they do that. Any idea what the threshold is? And there should probably be some kind of handshake before the switch no? I didn't see that behavior when telemetry is not enabled.

[JyeSmith]

@UnTraDe Nice work figuring this out!

If Ive read it correctly, this has a packet rate of 50Hz? Did you try any faster? From the LoRa calculator the on air time is <9ms.

I also imagine the r9 can dynamically changes LoRa paramaters (BW, SF, CR) to increase link budget. Have you been able to monitor any change when testing?

[UnTraDe]

@JyeSmith I don't think they change the parameters when the telemetry is off, because different settings are "orthogonal" to each other, which means that if the receiver and the transmitter don't have the same settings they won't be able to talk with each-other at all. But maybe it does happen when the telemetry is on, because then they can agree on settings and both change. So far though I've only seen them changing to FSK/OOK mode, but I've only tested it on the bench, so the behavior might be different when range is changing.

[AlessandroAU]

Any idea what the RF amplifier is? couldn't find a datasheet.