daveake / LoraHandheldAVR

10 stars 6 forks source link

CRC always wrong #1

Open cambazz opened 9 years ago

cambazz commented 9 years ago

Hello,

I managed to get FlexTrack and LoraHandHeldAVR on a pair of anarduino's with RFM98W. I had to change the dio0 and dio5 pins to 2 and 5, to get it working.

I also had to match the bandwidth, and spreading factor in both flextrack and lorahandheldavr to get it working.

Now, for some reason I am getting crc error all the time. In the part of the code:

if((x & 0x20) == 0x20) { // everytime receive packet, even if the packet length is correct, the crc is failing writeRegister(REG_IRQ_FLAGS, 0x20); }

I understand this crc we are checking at this point is calculated by the module itself and not by calculateCRC method in the code. (as it is not used)

I also noticed the PAYLOAD_LENGTH is 80 on LoraHandheldAVR and 55 on FlexTrack code.

Any ideas how to debug this problem?

Best Regards, C.B.

daveake commented 9 years ago

If you're using explicit mode then the receiver gets the packet length from the header, so the "payload_length" values don't have to match. If you're using implicit mode then they do.

If that's OK, then the problem is probably that the Tx and Rx aren't quite on the same frequency. Check the settings, then move one of them up/down in 2kHz steps till it works.

If you look at my gateway code, that shows how to read the frequency error.

Dave

On 24/03/2015 00:12, cambazz wrote:

Hello,

I managed to get FlexTrack and LoraHandHeldAVR on a pair of anarduino's with RFM98W. I had to change the dio0 and dio5 pins to 2 and 5, to get it working.

I also had to match the bandwidth, and spreading factor in both flextrack and lorahandheldavr to get it working.

Now, for some reason I am getting crc error all the time. In the part of the code:

if((x & 0x20) == 0x20) { // everytime receive packet, even if the packet length is correct, the crc is failing writeRegister(REG_IRQ_FLAGS, 0x20); }

I understand this crc we are checking at this point is calculated by the module itself and not by calculateCRC method in the code. (as it is not used)

I also noticed the PAYLOAD_LENGTH is 80 on LoraHandheldAVR and 55 on FlexTrack code.

Any ideas how to debug this problem?

Best Regards, C.B.

— Reply to this email directly or view it on GitHub https://github.com/daveake/LoraHandheldAVR/issues/1.

cambazz commented 9 years ago

On one side that transmits, I have the following frequency settings:

writeRegister(0x06, 0x6C); writeRegister(0x07, 0x9C); writeRegister(0x08, 0x88);

On the side that receives I have changed the 3rd statement, scanning from 0x00 to 0xFF but each time I got a packet with a bad crc. I was sending 15 bytes of 'u' character, and I received the following below:

u s y } g ( � �! � " �� � � u s y } g ! � � ! � " � � � u s y } g ( � �! � " �� ��
u s y } g ! � � ! � " � � � � u s y } g ( � � ! � " � � � u s y } g Q � �! � " �� ��
u s y } g ! � � ! � " l � � u s q } g � � � ! � " � � ��
u s y } g Q � � ! � " � � � � u s y } g ( � � ! � " � � �

And then I tried changing the second statement (the original was: 0x9C), so I scanned from 9B,80 to 9D,80 - and when I got out of this range, the module ceased to receive the packet.

So how can the tx and rx would not be on the same frequency if the frequency of the registers are set the same?

I also could not understand where is the gateway code - is it the FlexTrack on github/daveake ? or something else.

Best Regards, C.B.

daveake commented 9 years ago

Gateway code is in the pi-in-the-sky account on github. Tracker code is there too under the PITS repos (LoRa branch).

Modules vary in accuracy. I've seen some that are 5kHz out relative to others. When using 20.8kHz bandwidth they can only manage a 3kHz difference. My Pi tracker/gateway code calculates the frequency registers from the configured frequency, rather than hard-coding it. A change of 2kHz in one direction or the other should bring the modules close enough to work.

Dave

On 24 March 2015 at 19:52, cambazz notifications@github.com wrote:

On one side that transmits, I have the following frequency settings:

writeRegister(0x06, 0x6C); writeRegister(0x07, 0x9C); writeRegister(0x08, 0x88);

On the side that receives I have changed the 3rd statement, scanning from 0x00 to 0xFF but each time I got a packet with a bad crc. I was sending 15 bytes of 'u' character, and I received the following below:

u s y } g ( � �! � " �� � � u s y } g ! � � ! � " � � � u s y } g ( � �! � " �� ��

u s y } g ! � � ! � " � � � � u s y } g ( � � ! � " � � � u s y } g Q � �! � " �� ��

u s y } g ! � � ! � " l � � u s q } g � � � ! � " � � ��

u s y } g Q � � ! � " � � � � u s y } g ( � � ! � " � � �

And then I tried changing the second statement (the original was: 0x9C), so I scanned from 9B,80 to 9D,80 - and when I got out of this range, the module ceased to receive the packet.

So how can the tx and rx would not be on the same frequency if the frequency of the registers are set the same?

I also could not understand where is the gateway code - is it the FlexTrack on github/daveake ? or something else.

Best Regards, C.B.

— Reply to this email directly or view it on GitHub https://github.com/daveake/LoraHandheldAVR/issues/1#issuecomment-85666708 .

cambazz commented 9 years ago

I have managed to make the frequency error function work on arduino, and tuned the receiver part for minimal error. From the transmitting side (FlexTracker) I have modified the code that does memcpy to copy a string of "abcdeabcde..." for 80 characters. It appears the receiver is receiving the packet, but 'wrong' except the first few characters.

abc}pO��5�3������Wl�am"�����&�HXL<o�B���wA-�z��_Lf�c���J�����z frq_error:115.51 req_irq_flags:114 CRCfail abc}pO��5�3������Wl�am"��g�����HXL<o�DB����wA-��z��_Lf�c���J�����z frq_error:93.87 req_irq_flags:114 CRCfail

The above are two received packages, I also looked from the datasheet what the irq_flags 114 means:

RxDone, PayloadCrcError, ValidHeader, FhssChangeChannel bits are on, the rest are off.

So it does receive the packet, but because of some problem the data is corrupt? could it be a radio issue? What other things could I check to make it work?

Best Regards,

daveake commented 9 years ago

If the checksum is enabled and passes then it's a coding issue not the module.

On 24/03/2015 23:52, cambazz wrote:

I have managed to make the frequency error function work on arduino, and tuned the receiver part for minimal error. From the transmitting side (FlexTracker) I have modified the code that does memcpy to copy a string of "abcdeabcde..." for 80 characters. It appears the receiver is receiving the packet, but 'wrong' except the first few characters.

abc}pO��5�3������Wl�am"�����&�HXL<o�B���wA-�z��/Lf�c���J�����z frq_error:115.51 req_irq_flags:114 CRCfail abc}pO��5�3������Wl�am"��g�����HXL<o�DB����wA-��z��/Lf�c���J�����z frq_error:93.87 req_irq_flags:114 CRCfail

The above are two received packages, I also looked from the datasheet what the irq_flags 114 means:

RxDone, PayloadCrcError, ValidHeader, FhssChangeChannel bits are on, the rest are off.

So it does receive the packet, but because of some problem the data is corrupt? could it be a radio issue? What other things could I check to make it work?

Best Regards,

— Reply to this email directly or view it on GitHub https://github.com/daveake/LoraHandheldAVR/issues/1#issuecomment-85743349.

cambazz commented 9 years ago

well of course it is a coding issue. i just could not find where.

in LoraHandheldAVR, to start listening, register 0x26 is written with 0x0C

writeRegister(0x26, 0x0C); (1 1 00)

and in FlexTrack.ino we got:

writeRegister(REG_MODEM_CONFIG3, 0x04 | LowDataRateOptimize);

where reg_modem_config3 is 0x26 and 0x04 | 1 leads to a 5 (0101)

From the datasheet bit 2 is autoagc and bit 3 is mobile node on. Should not these two statements be reverse? the mobile node being the baloon, and the static node being the tracker?

Best Regards,

register 0x26 is written twice

hexameron commented 9 years ago

@cambazz LoRa gateway uses: LowDataRateOptimize = 0x08;

Flextrack never seems to set it, but you need to use 0x08, not 1.