dzikuvx / quadmeup_crossbow Goto Github PK

Cheap DIY RC link based on LoRa 868MHz modules

License: Mozilla Public License 2.0

C 8.27% C++ 91.73%

lora arduino rc radio lora32u4 protocol quadmeup-crossbow diy

quadmeup_crossbow's Introduction

QuadMeUp Crossbow

QuadMeUp Crossbow is a DIY project that gives 5km (at least) of RC link for UAV (airplanes and drones) for a price below $40. I uses SX1278 (LoRa 868MHz/915MHz) compatible (like HopeRF RFM95W) radio modules connected to Arduino compatible boards. It can be regular Arduino connected via SPI to SX1278 or dedicated board like Adafruit Feather 32u4 RFM LoRa or LoRa32u4 II

Future versions might be ported to ESP32 LoRa32 modules.

Current state

Works:

Getting data from OpenTX radio using SBUS protocol
Transmitting 10 channels to RX modules
Frequency hopping
Getting basic telemetry from RX module
Sending 10 channels using SBUS to flight controller
Binding
Allowing to use OLED on TX to get basic data

Needs implementation:

TX module configuration
RX configuration from TX module
Sending telemetry from TX to OpenTX radio

Dependencies

To compile, following libraries have to be installed:

U8g2 for OLED support in TX module
FlashStorage for EEPROM-Emulation if using a SAMD-Board (M0 etc.)

Protocol

Byte	Description	Notes
1	Frame type & used radio channel	bits 7-5 defines frame, bits 4-0 current radio channel
2 - 33	Payload	lenghth defined by frame type
payload length + 2	CRC	using crc8_dvb_s2 method

CRC

CRC is computed using crc8_dvb_s2 method. Initial CRC value for each frame CRC is equal to CRC of 4 bind bytes (unique for transmitter module).

Frame types

Value	Value hex	Description	Direction	Payload length
0000	0x0	RC channels data `RC_DATA`	TX -> RX	9
0001	0x1	Receiver health and basic telemetry `RX_HEALTH`	RX -> TX	6
0010	0x2	Request receiver configuration	TX -> RX	no used
0011	0x3	Receiver configuration	RX -> TX	no used
0100	0x4	Set receiver configuration	TX -> RX	no used
0101	0x5	PING frame, uses 9 byte payload	TX -> RX	4
0110	0x6	PONG frame, the same payload as PING	RX -> TX	4
0111	0x7	`BIND` frame, transmitted by TX only during binding	TX -> RX	4

`RC_DATA` frame format

Protocol allows to send 10 RC channels in total encoded as following

channels 1 to 4 encoded using 10 bits each (5 bytes)
channels 5 to 6 encoded using 8 bits each (2 bytes)
channels 7 to 10 encoded using 4 bits per channel (2 bytes)

Total length of RC_DATA payload is 9 bytes

`RX_HEALTH` frame format

Byte	Description
1	RX RSSI
2	RX SNR
3	RX supply volatage, sent in 0,1V
4	RX analog input 1 sent in 0,1V
5	RX analog input 2 sent in 0,1V
6	Flags

Flags

Bit	Meaning
00000001	Device in Failsafe mode

`PING` and `PONG` frames

PING and PONG frames are to determine packet roundrip between TX and RX module. TX sends PING frame with curent micros. If RX receives PING frame, it respons its payload as PONG frame.

`BIND` frame format

Byte	Description
1	Bind key byte 0
2	Bind key byte 1
3	Bind key byte 2
4	Bind key byte 3

RSSI

Receiver RSSI for the last received packet is injected as channel 11
RSSI is scaled in dB, NOT percent
RSSI 0 in flight controller means 40dB RSSI in RF chip on last packet received
RSSI 100 in flight controller means 140dB RSSI in RF chip on last packet received
Rule of thumb: to increase distance twice you need 6dB assuming nothing else will interfere
If at 100m RSSI is 40, at 200m should be around 34
I had successful flight with RSSI below 15
With correct antennas, at 1km RSSI should be around 20

OpenTX setup

OpenTX 2.2.1 or newer is required with enabled External RF SBUS.

Mode: SBUS
Channel Range: 1-16
Refresh rate: 12.0ms or 14.0ms normal

Tested with:

FrSky X9D Plus

Flight controller setup

RX module outputs RC data using SBUS protocol. The trick is that DIY RX module does not have inverters, so SBUS signal is also not inverted (TTL standard), while standard SBUS protocol used inverted serial signal.

That mean the following:

RX module TX line can be connected to any free UART RX pin
On F3 or F7 boards flight controller has to be configured not to use inverted SBUS (refer to flight controller docs)
On F4 flight controllers inverios has to be configured only when using dedicated SBUS serial port

Manual

Binding

After flashing TX and RX, binding is required.

Power up TX module
Navigate using button #1 to "Bind" option
Long press button #2 to enter Bind Mode
Power up RX
RX LED flashes quickly when in bind mode
After RX receives bind packet, LED goes to constanly ON state
When RX LED is solid ON, leave bind mode by long pressing button #2

TX module connection diagram

RX module connection diagram

quadmeup_crossbow's People

Contributors

Stargazers

Watchers

quadmeup_crossbow's Issues

PCB

Can we work together to produce a set of hardware to sell?

Add CRSF support on the TX module

PPM is crappy. Use CRSF protocol to get data from Taranis

TX should be transmitting only when receiving input from radio

This is the only way to ensure failsafe can be triggered in RX when radio dies

Which libraries do you use?

I'm trying to locate correct sources and versions of all libraries but I'm not sure I got it correct. It would be great if you could help me out, maybe update the readme?

My PPMReader (https://github.com/Nikkilae/PPM-reader) does not match the function prototype
"
crossbow:38: error: no matching function for call to 'PPMReader::PPMReader(int, int, bool)'
PPMReader ppmReader(PPM_INPUT_PIN, PPM_INPUT_INTERRUPT, true);
"

Then I need to fix the InterruptHandler to support the M0 chip but thats another story :)

Remove PacketID from QSP frame

It has no sense to use it. It only takes one byte without giving anything valuable

Issues on M0

Hi there,

i tried your code on adafruit m0 and it needs adjustmends, because the M0 does not have an EEPROM.

In platform_node.h:

#ifdef ARDUINO_AVR_FEATHER32U4 #include <EEPROM.h> #endif

In platform_node.cpp:
`
void PlatformNode::seed(void) {
uint8_t val;
#ifdef ARDUINO_AVR_FEATHER32U4
val = EEPROM.read(EEPROM_ADDRESS_BIND_KEY_SEEDED);

if (val != 0xf1) {
    EEPROM.write(EEPROM_ADDRESS_BIND_0, random(1, 255)); //Yes, from 1 to 254
    EEPROM.write(EEPROM_ADDRESS_BIND_1, random(1, 255)); //Yes, from 1 to 254
    EEPROM.write(EEPROM_ADDRESS_BIND_2, random(1, 255)); //Yes, from 1 to 254
    EEPROM.write(EEPROM_ADDRESS_BIND_3, random(1, 255)); //Yes, from 1 to 254
    EEPROM.write(EEPROM_ADDRESS_BIND_KEY_SEEDED, 0xf1);
}

#endif
}

void PlatformNode::loadBindKey(uint8_t key[]) {
#ifdef ARDUINO_AVR_FEATHER32U4
key[0] = EEPROM.read(EEPROM_ADDRESS_BIND_0);
key[1] = EEPROM.read(EEPROM_ADDRESS_BIND_1);
key[2] = EEPROM.read(EEPROM_ADDRESS_BIND_2);
key[3] = EEPROM.read(EEPROM_ADDRESS_BIND_3);
#endif
}

void PlatformNode::saveBindKey(uint8_t key[]) {
#ifdef ARDUINO_AVR_FEATHER32U4
EEPROM.write(EEPROM_ADDRESS_BIND_0, key[0]);
EEPROM.write(EEPROM_ADDRESS_BIND_1, key[1]);
EEPROM.write(EEPROM_ADDRESS_BIND_2, key[2]);
EEPROM.write(EEPROM_ADDRESS_BIND_3, key[3]);
EEPROM.write(EEPROM_ADDRESS_BIND_KEY_SEEDED, 0xf1);
#endif
}
`

Best regards,
David

Implement SBUS on RX side and deprecate PPM output

No RSSI output on RX module

SBUS output from RX module

Send RX device state in RX_HEALTH frame to indicate RX in failsafe mode

Get rid of Serial mode, it does not makes sense

serial passtrough (?)

Latest master PPM reading not stable

Reading packet from radio takes too much time and interferes with PPM processing

Verify PPM input on TX module

Inject RSSI as one of output PPM channels

OLED display for TX module to display basic statistics

Detect Failsafe state on TX side

Telemetry feedback from RX to TX

RF settings description

Can you write something about RF settings? It's very important for reliable, delay and radius.. Thanks

uint32_t frequency = 867000000;
uint32_t loraBandwidth = 250000;
uint8_t loraSpreadingFactor = 7;
uint8_t loraCodingRate = 6;

Why you don't change TxPower?

LoRa.setTxPower(17); //2-17

Thanks!

LoRa transmitting should not be blocking

Do not block loop during LoRa transmitting.
Add a periodic check if radio is done with TX and then switch radio to receive

Enable OLED only on button

There is no need to enable OLED processing all the time

Some kind of alarm when RSSI goes LOW

Drop frame channelID field in favor of CRC with salt

ChannelID (1st byte) of QSP packet is not needed. Drop it and instead use 32bit salt key for authorization:

Instead of initializing CRC with 0 at the beginning of frame encoding and decoding, initialize it with 32 bit secret key used to bind both TX and RX. This way, 1 byte will be saved and packets will be protected by crc only

Improve RC_DATA frame performance

Improve scaling, get rid of map function and find out faster way to scale input into output

Improve TX module indication

onboard led should be blinking if radio is working normally

Change RSSI scaling

Change rssi scaling to correspond to dB scale. Since radio usually looses signal at 40dB, scale like so:

constrain reported RSSI to 40-140
substract 40
multiply by 10
add 1000

Can sx1278 433m works

I bought an sx1278 works on 433m, but I don't know whether it can be supported by software.

Some ideas? I hate to waste my money:-(

Watchdog to go back to IDLE if frame did not completed in reasonable time

ability for RX and TX to change frequency

Improve radio sleep/wake/receive/transmit cycle

QSP Success:
- sleep
- transmit
- receive after TX is done
on QSP failure
- sleep
- receive again

decoding is taking more than n ms. 5ms should be enough. Check just to be sure
we should ignore everything after successful frame since frames are send every 6-7ms

Use slots for transmitting and receiving

TX determines transmission slots and transmits with constant frequency. RX can answer only after TX originated frame was received