This is not commercial project and there are no plans to do it commercial. I’m not selling any ready to use devices, and don’t get any money or other gratifications from guys selling DIY kits, ready products, etc (like q l r s . pl does).
Just to make sure that it’s clear


Hi,
Yesterday I tested my own LRS, and it works really great, so i thin that time to share it with community



So I made firmware for LORA SX1278 based modules available for $25 on eBay, making possible transmitting cppm signal, and receive mavlink (or raw) telemetry.
Mine features look like below:

• up to 16 CPPM or SBUS channels

• RF power selected btw 200(23dBm) – 1000(30dBm) mW

• telemetry

• -121 dBm receiving sensitivity, LORA modulation, frequency hopping

• RSSI and fail safe support

You can find detailed QCZEK LRS's specification on project site.

I also prepared building guide, you can find on my blog exactly there

And nice guide from Schalonsus
https://www.rcgroups.com/forums/show...&postcount=673

End RocketMouse FAQ
https://www.rcgroups.com/forums/show...o#post38777676

Enjoy

Support for ASR 6601 TCXO modules
https://qczek.beyondrc.com/qczek-lrs...-lrs-download/

3.10 for ASR now also supports master (TX) ...
https://qczek.beyondrc.com/qczek-lrs...-lrs-download/

3.00 for ASR Devices rleased
https://qczek.beyondrc.com/qczek-lrs...-6601-modules/

2.11 released
https://qczek.beyondrc.com/enjoy-new...today-morning/

2.10 released
http://qczek.beyondrc.com/qczek-lrs-...-lrs-download/

2.00 released
http://qczek.beyondrc.com/qczek-lrs-...-lrs-download/

If you want to use Taranis XLITE with PXX protocol enabled, you can use modified firmware enabling old PXX standard.
https://github.com/krzysztofkuczek/opentx

1.92 released
http://qczek.beyondrc.com/qczek-lrs-...-lrs-download/

1.91 released
Find out what is new except slave sport telemetry support
http://qczek.beyondrc.com/qlrs-new-release/

1.90 released !
What's new/fixed:

- support for FrSky smart port telemetry (see QCZEK LRS – SPORT TELEMETRY)
- fixed problem with frequency of receiving/sending telemetry frequency
- fixing possible problem with RX boot, after reset done by watchdog timer
- code size optimization
- support for mavlink HOME_POSITION (necessary both TX/RX serial port connection, to make possible reqesting home possition from FC)
- now beacon use lowest possible RF power

1.82 released !

1.81 is ready
- fixed problem with broken lBeep
- simply radio beacon for RX implmented
- small changes for switching PA and RX/TX switch

1.80 ready for download

- SBUS input protocol for TX part
- 1s delay before RF chip initialization during power up devices (to avoid not stable voltage)
- M0/M1 servo (software PWM) output for RX
- Silent RF mode for RX module (please note that it does not increase frame rate)
- mavlink hud altitude and HDOP transferred
- pushing RF chip to standby, every single frame, even when telemetry is not requested


Support for E32/E45 100mW modules is implemented !

1.70 version is available
- RSSI and air speed available in Tower app
- optimized TX side sync routine
- fix which, may (or not) prevent 868MHz modules to be burned during quick on/off cycle


1.6 us waiting for you

optimized resync routine

new packet lost based rssi calculation



Version 1.50 waiting for you

• RX/TX switching optimization
• Beta version of race mode - just to check how 500kHz band is working. Using race mode frames are send at 21Hz with full telemetry and up to 35Hz without telemetry.
• Hardware watchdog restart RX if no synchronization occurs, according to configuration parameter (default 30s)
• Additional parameter (bit mask) to prevent setting (by 10s button press) fail safe values for selected channels.

Find out more:
http://qczek.beyondrc.com/qczek-lrs-...-lrs-download/


New version 1.40 ready for download

• Hardware watch dog used to reset board when any of scheduled tasks takes more then 0.5s
• Hardware watch dog used to reset slave (RX) board if during fail safe state, no synchronization occurs for 30 seconds. Just in case if RF chip has some problems...
• SX1278 receiving optimization according to Semtech errata
• Correction to XJT(PXX) frame reading to avoid using fail safe settings frame as normal channels values
• Many changes in mavlink tunnelling protocol, to send as much as possible info to Droid Planner like applications. Unfortunately due to flash memory limitation, no way to pass RSSI and relative alt.

Find out more:
http://qczek.beyondrc.com/qczek-lrs-...-lrs-download/


New version 1.30 available
What's new:

• Code size optimization
• Changing sequence of PA and RX/TX switch switching
• Sending RSSI via telemetry, even without mavlink capable FC connected
• Experimental support for E44 modules (915MHz)

Find out more:
http://qczek.beyondrc.com/qczek-lrs-...-lrs-download/

Beta version of configuration tool is ready



http://qczek.beyondrc.com/qczek-lrs-...-lrs-download/

New version 1.20 available
What's new:

• First 8 channels send in every frame !
• RF channel number included in payload, for better synchronization, and possibility to use same freqencies for different rf channels
• 4 instead of 3 bytes of serial data send in every master->slave frame
• Minor master/slave synchronization bug fixed

E45-TTL-1W 868MHz modules are supported by beta version 1.10

Find out more:
http://qczek.beyondrc.com/qczek-lrs-...-lrs-download/
http://qczek.beyondrc.com/qczek-lrs-...configuration/

New version 1.10 available.

What’s new:
- support for SBUS protocol
- support for lbeep
- faster re sync after package dropping

Find out more:
http://qczek.beyondrc.com/qczek-lrs-...-lrs-download/
http://qczek.beyondrc.com/qczek-lrs-...configuration/


New version 1.0 available.

What’s new:

- support for PXX (also know as XJT D8 and D16) input protocol (without CRC calculation)
- adaptive telemetry rate
- more secure way to enter settings mode for slave module (RX module)
- RSSI based on SNR or signal strange

Find out more:
http://qczek.beyondrc.com/qczek-lrs-...-lrs-download/
http://qczek.beyondrc.com/qczek-lrs-...configuration/



Hi,
Currently there are two versions of module available. But only old one is now supported. I'm waiting for info from manufacture, what are the difference between both versions. You can see difference on project page http://qczek.beyondrc.com/qczek-lrs-...s-build-guide/

Update
New version 0.91 available (supporting new and old modules).

http://qczek.beyondrc.com/qczek-lrs-...-lrs-download/

and quick report from first testing http://qczek.beyondrc.com/qczek-lrs-...well/#more-254

Hi qczek,

Very cool
Great to see another good option for everyone wanting a LRS.

Do you plan to add SBUS support on the RX? Why SBUS, well latency with CPPM I always notice a lot of latency in control, not so bad on a plane but when you're quite far any ms counts.
I ask as I have a few LRS but none of them gives me a good match between range and downlink. EzUHF and DragonLink have great range but no telemetry support (telemetry from the FC). OpenLRS has downlink telemetry but crapy range.

Long time ago I made my own LRS to have this but I gave up as quality of the transceivers was crap! Same used in the OpenLRS and I just couldn't trust them.

Thanks!

Originally Posted by IceWind

Do you plan to add SBUS support on the RX?

I can try , but it has to be made using timers, because this little stm8L151 MCU has only single serial port. The other problem is limited (2kB) ram space, but i can think about it.

Hi qczek,

Interesting project. Is the source code for the project open?

Thanks,
George

Originally Posted by MGeo

Is the source code for the project open?

Hi George,
No, the source code is not available. If you have any specific question regarding implementation, please let me know.

Originally Posted by qczek

I can try , but it has to be made using timers, because this little stm8L151 MCU has only single serial port. The other problem is limited (2kB) ram space, but i can think about it.

Is not a show stopper just a nice to have, I'd consider making one to try.
I'm finishing a FPV wing and will definitely have a LRS system in it, for the moment will be EzUHF but I'd benefit from the option to have a downlink.

Does the telemetry part is bi-directional? I'd plug it to my iNAV controller in order to change settings and route planning remotely.

Originally Posted by IceWind

Does the telemetry part is bi-directional?

Yes and no
If you set serMode parameter to 0 – transparency mode, you will be able to send raw serial data from your ground station to UAV and back. But unfortunately, you can send only 3 bytes in every frame from ground station to UAV, and 10 bytes from UAV to ground station in every frame. It means that streams are limited to 45 bytes/s to UAV and 150 bytes/s from UAV to ground station. It's not enough to transport mavlink messages

But if serMode parameter is set 1 - mavlink, messages going from UAV, are "translated" to make it smaller, and transported to ground station. Ground station just regenerate messages back from received data. Currently only HEARTBEAT, ATTITUDE, POSITION_INT, SYS_STATUS, RC_CHANNELS_RAW are transfers, just to show global position and attitude of UAV. There are no any messages transported from ground station to UAV (for settings waypoints, etc.) but it could be implemented. Just need to know which one are really required

Hi,
This is raw RSSI value reported at 5km distance.
It means, that it could be possible to reach 40km at lowest RF power and even 80km at max 1W (30dBm) power.
You can find detailed calculation on my blog
http://qczek.beyondrc.com/rssi-checked-at-5km-distance/

The main governing factor for LoRa reception is its ability to operate at below noise levels.

RSSI and signal levels can be missleading, for instance the maximum quoted sensitivity is -149dBm. Now with the receiver typically seeing -100dB of noise, the quoted maximum sensitivity would suggest that signals can be received at 49dB below noise level !!!!. It migh be possible to demononstrate that in the lab, but not in the real noisy rf world outdoors.

So forgetting RSSI for a moment, if the LoRa mode allows for -10dB SNR and the noise level as seen by the receiver is -100dB then the failure point for signals will be at RSSI -110dB, i.e 10dB below noise level.

I once did a 40km hilltop to hilltop test and at the failure point the calculated received signal strength (based on distance, TX power and antennas used) was -114dBm. However the data sheet sensitivity for the LoRa mode used was -131dBm, so where had the missing 17dBm of sensitivity gone ?

Well the receiver was recording around -105dBm of noise and the LoRa mode was rated at -10dBm SNR, so the real failure point would be at RSSI -114dBm, and not -131dBm as the datasheet suggested.

Originally Posted by srnet

The main governing factor for LoRa reception is its ability to operate at below noise levels.

RSSI and signal levels can be missleading, for instance the maximum quoted sensitivity is -149dBm. Now with the receiver typically seeing -100dB of noise, the quoted maximum sensitivity would suggest that signals can be received at 49dB below noise level !!!!. It migh be possible to demononstrate that in the lab, but not in the real noisy rf world outdoors.

So forgetting RSSI for a moment, if the LoRa mode allows for -10dB SNR and the noise level as seen by the receiver is -100dB then the failure point for signals will be at RSSI -110dB, i.e 10dB below noise level.

I once did a 40km hilltop to hilltop test and at the failure point the calculated received signal strength (based on distance, TX power and antennas used) was -114dBm. However the data sheet sensitivity for the LoRa mode used was -131dBm, so where had the missing 17dBm of sensitivity gone ?

Well the receiver was recording around -105dBm of noise and the LoRa mode was rated at -10dBm SNR, so the real failure point would be at RSSI -114dBm, and not -131dBm as the datasheet suggested.

Hi,
Thanks for explanation. When you refer -10dBm SNR you think about spreading factor set to 8? Because SNR depends on spreading factor as far as i know. I'm not RF engineer, so sorry for stupid question, but if we do assumption that noise level is -111 dBm, can we achieve -121 dBm receiving sensitivity.?
And even if receiver sensitivity is depending on noise level, it's the same problem we will meet using different modulation like FSKK...
I'm going to use helium ballon to check what is real distance we can send/recive data...
Regards
Krzysiek


PS
Did you participate in building $50 satellite?

When you refer -10dBm SNR you think about spreading factor set to 8?

Yes.

I'm not RF engineer, so sorry for stupid question, but if we do assumption that noise level is -111 dBm, can we achieve -121 dBm receiving sensitivity.?

Dont worry about it, a lot of RF savy people seem to believe that you can get the datasheet quoted sensitivty and you just cannot, due the the impact of real world RF noise. As I mentioned the maximum quoted sensitivty is around -150dBm, mabye the RF environement out beyond Pluto is quiet enogh to receive signals at that level.

You can use the reported SNR directly to calculate achievable distance and it will take into account the noise factor. If a packet is coming in at 0dBm SNR, and the data sheet says the limit for that mode is -10dBm, then you can expect the reception limit to be 3 times further out (square root 10).

Did you participate in building $50 satellite?

I did, and helium party balloons are a great way to test this stuff;

http://www.southgatearc.org/news/201..._telemetry.htm

Originally Posted by srnet

You can use the reported SNR directly to calculate achievable distance and it will take into account the noise factor. If a packet is coming in at 0dBm SNR, and the data sheet says the limit for that mode is -10dBm, then you can expect the reception limit to be 3 times further out (square root 10).

Yes, but how can I predict RF noise? just by reading RSSI when I'm not sending any data?

Read the register that tells you the SNR for the last packet.

The RSSI will not tell you how close the link is to failure, the SNR will.