LoRa gateway CRC errors

[Mat Burnham]

I'm trying to code up a LoRa tracker. It's transmitting, audibly audible, having an effect on the RSSI reading, but I'm always getting CRC errors on my gateway:

Given I've got two channels on the gateway I figured I'd try an uplink from one to the other to isolate whether the problem was at the gateway or the tracker:

Same problem. Now I'm stumped as even communicating from effectively the same device with the same software and configuration is failing me. Any bright ideas to try before I can perhaps get a known-good tracker nearby come 29th March?

I assume this is the LoRA CRC that's failing, not anything to do with the UKHAS CRC16_CCITT?

gateway.txt configuration:

##### Config CE0 #####
frequency_0=434.720
mode_0=1
AFC_0=Y
DIO5_0=1
UplinkTime_0=2
UplinkCycle_0=60
UplinkFrequency_0=434.720
UplinkMode_0=1
SSDVUplink_0=Y

##### Config CE1 #####
frequency_1=434.720
mode_1=1
AFC_1=Y

Mat

[David Akerman]

Those rssi figures are much lower than you would get with a local transmitter at the set frequency, so check your tracker settings.

Also, you can't get the gateway to transmit simply by setting up the uplink settings.  It needs to know what to uplink, and that has to come from a separate program.  Please just reset those settings so it listens only.

--
You received this message because you are subscribed to the Google Groups "UKHAS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukhas+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/6b0b42e2-0a49-40e4-b19b-3d399e054ecen%40googlegroups.com.

[Mat Burnham]

After a bit of trial and error, building another breadboarded tracker to run some very simple test code, and finding mode 0 worked, mode 1 didn't, and mode 2 did, I figured it was probably something to do with the implicit header inherent in mode 1. After a bit more fiddling it turns out I'd not fully understood the fixed length packet. Now that I'm actually sending exactly 255 byte packets all is well and I can get back out of that rabbit hole.

Cheers,

Mat

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/CAN3_bBqPf5pKHTCjqjdJepE8KUA-upbfHqexAMT%3DeZTM3scg2A%40mail.gmail.com.

[David Akerman]

Mode 1 is intended for use with SSDV, to send data as quickly as possible within the confines of the IR2030 rules for 434MHz airborne operation.  As such it uses the largest available packet size which is 255 bytes and uses implicit headers which are shorter than explicit headers.  Implicit requires the transmitter and receiver to agree on the packet length and there's an assumption at both ends that the packets are 255 bytes.

Dave

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/CA%2BEW5Kpa8nBjoEjJxaKtQ0GVjpt_Xh25ZMzaq4RZ_E_4WPwpeQ%40mail.gmail.com.

[gw7...@gmail.com]

And for implicit packets you have to be sure to set CRC on\off and coding rate at both TX and RX ends.

For explicit mode you only need to set these on the TX since the RX will pick up the settings from the explicit header.