Author Topic: Long Range parameters for RFM69HW (868 / 915 MHz) (Read 18629 times)

fgomes · « **on:** July 18, 2016, 05:32:14 AM »

Hi,

I need to use the moteinos (868 or 915 MHz) in a long range configuration (longest link with about 1km, near line-of-site, in a rural area). I saw many posts with recommended settings, namely these from hdphilip (https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/rfm69hw-range-test!/15/):

radio.writeReg(0x03,0x68); //RegBitrateMsb 1200 bitrate
radio.writeReg(0x04,0x2b); //RegBitrateMsb
radio.writeReg(0x05,0x00); //RegFdevMsb 2000
radio.writeReg(0x06,0x21); //RegFdevLsb
radio.writeReg(0x19,0x56); //RegRxBw

radio.writeReg(0x18,0x88); //RegLna register

and these from Steinarrr (https://lowpowerlab.com/forum/moteino/multistorey-indoor-range-performance-1-75km-range-(solution)/msg3189/#msg3189):

radio.writeReg(0x03,0x68); //RegBitrateMsb 1200 bitrate
radio.writeReg(0x04,0x2B); //RegBitrateLsb 1200 bitrate
radio.writeReg(0x05,0x00); //RegFdevMsb 2000
radio.writeReg(0x06,0x52); //RegFdevLsb 2000
radio.writeReg(0x19,0x40|0x10|0x05); //RegRxBw DccFreq:010, RxBw_Mant:24, RxBw_Exp:5
radio.writeReg(0x18,0x00|0x00|0x01); //RegLna LnaZin:50ohm, LowPower:Off, CurrentGain:MAX

I've tried with the first values from hdphilip, but had stability problems, it worked in my house but when intalling the gateway at the final destination, even with the sensors around it (less than 1 meter), most of the messages failed.

Any recommended values for 868 or 915 Moteinos? Temperature compensation is necessary for these parameters?

Thanks!

Fernando

fgomes · « **Reply #1 on:** July 18, 2016, 07:14:21 PM »

Using the code from the first example (from hdphilip), running in 3 different nodes, using an RTL-SDR radio and SDR#, I observed activity in the following frequencies:

Node 1: 867,945 - 867,949
Node 2: 867,936 - 867,940
Node 3: 867,940 - 867,944

They are all at the same temperature (about 20ºC), side by side. This was the reason why they don't communicate between them (but they communicate using the RFM69 default parameters).

So what is the way to make them work together? it could be to activate the AFC in one of the nodes, use it as a receiver and get the frequency error (FEI Value) with each of the other transmitting, and then correct the frequency in the transmitter nodes based on the FEI calculated by the receiver nodes? And on top of this 'offset' calibration, is it still necessary to compensate the frequency based on the temperature?

Is there a reason for not having the AFC activated in the RFM69 library? Wouldn't it minimize this problem?

Thanks!

Fernando

fgomes · « **Reply #2 on:** July 19, 2016, 07:32:16 PM »

I made some additional tests. First I have used the procedure described here for measuring the frequency error for each node:

https://ukhas.net/wiki/ideas:rfm69_frequency_trimming

I have introduced an adjusted frequency in each node (using the radio.setFrequency method), and made some additional fine tunning observing the signal using sdr#. Using that approach I was able to have successful transmissions between nodes (but some of the messages only succeed on the first or second retry)

I then changed one of the nodes to the freezer, and then we can observe near 2.5kHz frequency drift in a few minutes (cold image)

So my main questions are:

Do you use temperature compensation when using low bit rate / bandwidth? Do you have a temperature compensation table or do i need to make my own, measuring the frequency drift with the temperature?

Are the non default parameters I have used ok? It seems strange that even making some fine adjustment to each node frequency and having confirmed that the frequencies are aligned, it still has some retries when the nodes are side by side. The parameters that i'm using are the following:

radio.writeReg(0x03,0x68); //RegBitrateMsb 1200 bitrate
radio.writeReg(0x04,0x2b); //RegBitrateMsb
radio.writeReg(0x05,0x00); //RegFdevMsb 2000 Hz deviation
radio.writeReg(0x06,0x21); //RegFdevLsb
radio.writeReg(0x19,0x56); //RegRxBw 5200 Hz RxBw

radio.writeReg(0x18,0x88); //RegLna register

Best regards

Fernando

emjay · « **Reply #3 on:** July 20, 2016, 08:54:20 AM »

@Fernando,

If you use the narrowest RxBw settings, then a static adjustment of the crystal error is not enough if you are expecting wide temperature changes. Some good material here https://lowpowerlab.com/forum/moteino/freq-vs-temperature-update/

When benchtesting, be aware that the over-strong signal can confuse the Rx section - curling up or removing the ANT wire can help. BTW, what does your payload format look like?

fgomes · « **Reply #4 on:** July 20, 2016, 10:26:43 AM »

@emjay

Thanks for your reply! Ok, I'll add temperature compensation, but even with the nodes all at the same temperature and with frequency adjusted as I described I have many messages that only succeed with retries. Without narrowing the band, using the default parameters of the LowPowerLab lib, it works without adjusting the frequency and without using retries. I was expecting that narrowing the band will have the impact of the need of frequency calibration (and eventual temperature calibration) but that will have the same communication reliability, this high retry number with nodes side by side worries me. I'll try to increase the distance between nodes to see if it could be a saturation problem, but this doesn't occur with the default configuration.

The payload is mainly the value of several sensors, a total of about 20 bytes.

Fernando

fgomes · « **Reply #5 on:** July 21, 2016, 03:05:00 AM »

I did some additional tests, always using the same nodes. I have removed the retries, and count all the failures. This is what I have observed :

Using the default settings, without frequency calibration, the failure rate is between 1% and 2%
Adding frequency adjustment / calibration the results were similar
With the default settings but changing the bitrate to 1200 and frequency calibration , the failure rate is 7%
Using a bitrate of 1200, rxbw of 10khz, 2kHz fdev and frequency calibration I got also about 7% failure rate.

So the failure rate seems to depend mainly of the bitrate ( only changing the bitrate to 1200 and even using frequency calibration the failure rate raises from 2% to 7%). Any idea why changing the bitrate from the standard 55555bps to 1200bps might increase the failure rate even using the default large rx bandwidth and fdev?

Fernando

emjay · « **Reply #6 on:** July 21, 2016, 06:44:49 AM »

@Fernando,

The payload is mainly the value of several sensors, a total of about 20 bytes.

You have some real data in there? Empty packets can be troublesome.

I suggest you estimate the noise floor at your testbench (the RSSI level of the occasional bad packet) then set the RegRssiThresh (0x29) value a few dB above this.

fgomes · « **Reply #7 on:** July 21, 2016, 10:23:40 AM »

@emjay

Thank you again! The packets are not empty, but didn't check exactly their content, the values are almost only floats, and are being used, so I think it would be an almost random sequence of bits.

About estimating the noise floor on my test bench, can you give me some additional clues about the process you are proposing? I am using the default lib RSSI threshold (220, corresponding to 110 dBm). All the packets that the receiver sees are at about -50dBm, and then there are some packets that the receiver don't see... Even if i put the nodes close together, the RSSI goes to about -22dBm, but it didn't receive some of the packets. When using the default parameters (BR=55555, Fdev=50000, RxBw=125kHz) I can receive correctly signals with RSSI lower than -90dBm.

So I'm not understanding the cause of the higher failure rate, unless the frequency didn't match (lower bandwidth will be much more sensitive to that, but I have tuned the nodes using RTL-SDR and SDR# otherwie they don't communicate) or disturbances in the same frequency (turning the nodes off I don't see any activity in the frequency I'm using, 868.000 MHz). Worse than that, even not reducing the bandwidth, but reducing only the bitrate, I get the same high failure rate!

BR=55555, Fdev=50000, RxBw=125kHz: Failure rate <2% (with frequency calibrated or uncalibrated)
BR=1200, Fdev=50000, RxBw=125kHz: Failure rate ~7% (with frequency calibrated)
BR=1200, Fdev=2000, RxBw=10kHz: Failure rate ~7%(with frequency calibrated)

Any ideas?

Best regards

Fernando

emjay · « **Reply #8 on:** July 21, 2016, 01:54:29 PM »

@Fernando,

Ok, we have some clues to the local noise floor level:

I can receive correctly signals with RSSI lower than -90dBm.

Try changing the default RegRssiThresh (0x29) to -95dBm - the weak packets will still get through.

fgomes · « **Reply #9 on:** July 21, 2016, 04:14:48 PM »

@emjay, thanks again for your support. I understand that the noise floor should be around that level (the weakest messages received) but since the threshold is now at -110dBm and I don't receive the messages that for sure have a much stronger signal, I don't understand what will be the benefit of raising the RSSI threshold, what is the impact of using an higher RSSI threshold, isn't it only used to automatically discard messages with signal below it?

Nevertheless I'll try it! :-)

Best regards

Fernando

fgomes · « **Reply #10 on:** July 21, 2016, 08:18:56 PM »

The problem of loosing acks seems to be related to the canSend() function continue to say that the RSSI is high for a long time after the RF signal has disappeared (it takes a second and exits by timeout - RF69_CSMA_LIMIT_MS, but during this second there is no RF activity, observed on SDR#). This only happens at 1200bps, not at 55555bps (lib default). In that situation, the gateway sends the acks to late. I've changed the sendWithRetry timeout processing in order to be able to have more than 1 second timeout, and it is working with 0 failures with the same setup, with BR=1200, RxBw=5000Hz, FDev=2000.

Why could the RSSI level get stucked when working at 1200bps with no RF activity present? Could this be an HW problem with some nodes? I've changed the gateway to other node and the results are similar, now more than 400 messages have been transmitted with this second setup without any failure, but always with the ack delayed a second (RF69_CSMA_LIMIT_MS timeout, RSSI during this second was constant and equal to the received message RSSI).

It seems that might be related to this post, but I don't want to remove the CSMA feature: https://lowpowerlab.com/forum/moteino/moteino-rfm69-ack-delay/msg10348/#msg10348

Best regards

Fernando

perky · « **Reply #11 on:** July 21, 2016, 09:08:54 PM »

I'm not convinced that the RSSI reading function works as intended, I had major problems with it. I also had problems receiving packets when transitioning from STANDBY to RX mode (which is supposed to reset the receiver), however transitioning from SLEEP to RX works. I think there is a bug in the silicon. Some more info here:
https://lowpowerlab.com/forum/moteino/communication-only-works-one-way-regardless-of-device/45/
Mark.

fgomes · « **Reply #12 on:** July 23, 2016, 07:58:43 AM »

Thanks for your reply. I just removed the readRSSI call from canSend, and the nodes have transmitted now more than 2000 messages without any lost message or acknowledge (code below).

Of course there are only two nodes, the CSMA is not a critical function and that is why this patch didn't have secondary effects, if it was a more complex network there could be collision problems.

As I posted before, I'm observing that without this patch the readRSSI reports always the RSSI of the received message and the ACK only goes out by timeout. This only occurs when I reduce the bitrate to 1200 (BR=1200, Fdev=2000, RxBw=5kHz). I've also noticed that with the standard configuration (BR=55555, Fdev=50000, RxBw=125kHz) I had a failure rate between 1 and 2%, now removing the RSSI reading from the canSend function the failure rate is also zero (no failed messages in thousands of transmitted messages).

My "conclusion" with these test results are that the readRSSI gets frequently stuck RSSI levels, that will cause the failing to transmit the ack on time because the node thinks the network is still busy, and that this problem is much worse with a low bit rate (1200bps) but still occurs sometimes with the default bitrate (55555bps).

About the use of sleep instead of standby patch in order to get a correct rssi reading, I've seen several references to it done in different ways, is there any recommendation for it for the stuck RSSI level before the ack transmission?

Thanks in advance!

Fernando

Code: [Select]

bool RFM69::canSend()
{
  if (_mode == RF69_MODE_RX && PAYLOADLEN == 0 /* && readRSSI() < CSMA_LIMIT */) // if signal stronger than -100dBm is detected assume channel activity
  {
    setMode(RF69_MODE_STANDBY);
    return true;
  }
  Serial.println(readRSSI());
  return false;
}

fgomes · « **Reply #13 on:** July 23, 2016, 09:24:05 AM »

In order to try the sleep vs standby patch I introduced the change in the beginning of the receiveBegin function, as @kolaf stated here:

https://lowpowerlab.com/forum/moteino/communication-only-works-one-way-regardless-of-device/msg13193/#msg13193

The receiveBegin code is the following:

Code: [Select]

void RFM69::receiveBegin() {

  // As sugested in https://lowpowerlab.com/forum/moteino/communication-only-works-one-way-regardless-of-device/msg13193/#msg13193
  setMode(RF69_MODE_SLEEP);
  setMode(RF69_MODE_STANDBY);
	
  DATALEN = 0;
  SENDERID = 0;
  TARGETID = 0;
  PAYLOADLEN = 0;
  ACK_REQUESTED = 0;
  ACK_RECEIVED = 0;
  RSSI = 0;
  if (readReg(REG_IRQFLAGS2) & RF_IRQFLAGS2_PAYLOADREADY)
    writeReg(REG_PACKETCONFIG2, (readReg(REG_PACKETCONFIG2) & 0xFB) | RF_PACKET2_RXRESTART); // avoid RX deadlocks
  writeReg(REG_DIOMAPPING1, RF_DIOMAPPING1_DIO0_01); // set DIO0 to "PAYLOADREADY" in receive mode
  setMode(RF69_MODE_RX);
}

With this change the RSSI stuck problem seems to disappear. Statistically it seems a bit worst than the dirty patch I made before (transmitting ignoring the RSSI level) but the failure rate is really low, so only with a long observation time it might have some meaning (I have now one failure in 400 messages, ignoring the RSSI I had 0 failures in more than 4000 messages, but of course there could be some radio interference or any other issue).

Then I have removed the setMode(RF69_MODE_STANDBY), as sugested by @perky to @kalaf, the test is running and it seems to give the same results (for now 0 failures with more than 400 messages transmitted)

So for now I'll keep this implementations and will keep an eye on the failures to see if there are no secondary effects or long term stability issues. This is the receiveBegin code I'm currently using:

Code: [Select]

void RFM69::receiveBegin() {

  // As sugested in https://lowpowerlab.com/forum/moteino/communication-only-works-one-way-regardless-of-device/msg13193/#msg13193
  setMode(RF69_MODE_SLEEP);
	
  DATALEN = 0;
  SENDERID = 0;
  TARGETID = 0;
  PAYLOADLEN = 0;
  ACK_REQUESTED = 0;
  ACK_RECEIVED = 0;
  RSSI = 0;
  if (readReg(REG_IRQFLAGS2) & RF_IRQFLAGS2_PAYLOADREADY)
    writeReg(REG_PACKETCONFIG2, (readReg(REG_PACKETCONFIG2) & 0xFB) | RF_PACKET2_RXRESTART); // avoid RX deadlocks
  writeReg(REG_DIOMAPPING1, RF_DIOMAPPING1_DIO0_01); // set DIO0 to "PAYLOADREADY" in receive mode
  setMode(RF69_MODE_RX);
}

If I noticed any issue I'll let you know. And if anyone wants that I make any specific test related with this issue please let me know :-)

Best regards

Fernando

perky · « **Reply #14 on:** July 23, 2016, 10:54:34 AM »

Well done. There definitely seems to be an issue with this STANDBY to RX not fully resetting the receiver. Glad you got it going.
Mark.

fgomes · « **Reply #15 on:** July 23, 2016, 01:24:12 PM »

It is still working well with the code from my previous post :-)

I was trying to introduce the AFC to compensate the crystal error and temperature frequency drift. Until now I was using the frequency calibrated manually (error observed on the SDR#).

The main comms parameters are BR=1200, Fdev=2000, RxBw=5kHz

If i introduce the AFC, it is not working, even if I introduce the adjusted frequency. The parameters I'm using are the following:

radio.writeReg(0x1a,0x4b); //RegAfcBw 50kHz Bw (also tested with 25kHz)
radio.writeReg(0x1e,0x0C); //AfcAutoClearOn, AfcAutoOn (also tested removing the AutoClearOn)
radio.writeReg(0x1e,0x04); //AfcAutoOn

I tried also to increase the preamble to 9 bytes since a big frequency error might need additional preamble bytes for synchronization:
radio.writeReg(0x2d,0x09); //Preamble 9 bytes

I made the tests starting with the corrected frequency, for example:

radio.setFrequency(868006500);

Also tested without setting the frequency, so starting at 868000000.

On the gateway node I only receive sporadic messages (one in each 100 messages or less). Is there any additional trick to use AFC? Does it work, or should I use a manual temperature compensation algorithm?

Best regards

Fernando

perky · « **Reply #16 on:** July 23, 2016, 07:19:54 PM »

What have you set the RSSI threshold to? Is it still at -110dB? The thing about AFC is it will trigger when the signal gets abouve the RSSI threshold, but it will latch on to those parameters forever until a payload ready is received or the software times out without an address match or payload ready and manually resets it. Since it can trigger with noise at low RSSI thresholds that can leave the receiver frequency offset from the desired one and incapable of receiving your real packets. Try setting the RSSI threshold higher to eliminate noise but still able to receive proper packets and see if that fixes it.
This document by Freescale MC12311 which uses the sx1231 silicon has a lot more information about AFC:
www.nxp.com/files/rf_if/doc/app_note/AN4983.pdf
Mark.

fgomes · « **Reply #17 on:** July 23, 2016, 07:51:31 PM »

@perky, once again thanks for your answer. Now it makes a bit more sense to me why the AFC might not be so useful to long range communications without manual frequency calibration... To be able to use the standard crystal we will have to use a large bandwidth for the AFC in order to 'capture' the other node frequency (I've tried 25kHz and 50kHz), and that way we will have much more noise due to the large bandwidth, so we will have to choose an higher RSSI threshold in order for AFC to work... But perhaps it might work with manual calibration only for temperature compensation, using also a low bandwidth for AFC. I'll try it with a BW more close tothe RxBw.

Best regards

Fernando

fgomes · « **Reply #18 on:** July 23, 2016, 09:45:07 PM »

With @perky tip of raising RSSI threshold I was able to communicate between two nodes with AFC and without frequency calibration and between -20ºC and 60ºC. All the non default parameters were the following:

radio.writeReg(0x03,0x68); //RegBitrateMsb 1200 bps
radio.writeReg(0x04,0x2b); //RegBitrateLsb
radio.writeReg(0x05,0x00); //RegFdevMsb 2000 Hz
radio.writeReg(0x06,0x21); //RegFdevLsb
radio.writeReg(0x19,0x56); //RegRxBw 5kHz Bw
radio.writeReg(0x18,0x08); //RegLna register
radio.writeReg(0x1a,0x4b); //RegAfcBw 50kHz Bw
radio.writeReg(0x1e,0x0C); //AfcAutoClearOn, AfcAutoOn
radio.writeReg(0x29,210); //RSSI Threshold = 105dBm

I'm a bit worried of two things:

I'm using a very large bandwidth for the AFC (50kHz), so lots of noise will be used for the AFC.I started by using a bandwidth of 25kHz but when I heated one of the nodes to 60ºC I had to raise the bandwidth otherwise there were no communication.
These two nodes have a frequency difference of about 4kHz but there are others with about 8kHz difference, I still don't know if it will work with frequencies so distant.

Best regards

Fernando

emjay · « **Reply #19 on:** July 24, 2016, 03:39:03 AM »

@Fernando,

If you look at the FEI for the received packets, you can estimate the offset of each transmitter. This could be the basis of a dynamic auto-calibrate mechanism by passing the offset back in the ACK to the transmitting node so that it can adjust the next packet.
Beware though, the FEI value is noisy, it needs some careful averaging/filtering....

fgomes · « **Reply #20 on:** July 24, 2016, 04:08:43 AM »

@emjjay, thanks! What is the best way to read Fei, read the Fei register immediately after receiving a valid message?

Best regards

Fernando

perky · « **Reply #21 on:** July 24, 2016, 06:30:40 AM »

Unfortunately Hoperf don't publish the specs of the crystals, but the empirical data out there appears to suggest the crystals used are +/10ppm (maybe even closer tolerance from the data), and since the standard for low cost close tolerance crystals is +/-10ppm nowadays this is a reasonable assumption. The actual full receiver bandwidth at 868MHz has to be increased to cope with the maximum difference between transmitter and receiver, which is 20ppm or 17.36kHz.

Looking at the other criteria, there's a thread I started to try to derive some basic rules:
https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/definition-of-rxbw-with-rfm69/

1) 0.5 <= 2 * Fdev/BR <= 10 (modulation index, MI)
2) BR < 2*RxBw (bit rate)
3) RxBw >= Fdev + BR/2 (receiver bandwidth)
4) RxBwAfc >= Fdev + BR/2 + LOoffset (receiver AFC bandwidth)
5) Fdev + BR/2 < 500kHz (maximum RxBw setting)

You have Fdev = 2000Hz, BR = 1200, RxBw = 5kHz, so RxBwAfc >= 2000 + 1200/2 + 17360,
i.e. RxBwAfc >= 20.6KHz.

So setting 25kHz for RxBwAfc should have been OK, even with a 17.36kHz difference in TX and RX frequencies. I suspect something else going on here if you needed to change to 50kHz. Have you enabled lowBetaOffset stuff?
Mark.

Edit: The reason I say this is that you don't have a very low beta (i.e. low modulation index < 1). Your MI is around 3.33, I'm wondering whether if lowBetaOffset is on this is messing things up. The other thing to look at is how sharp the roll-off is for the DC cutoff. Try putting 0x8C in RegRxBwAfc, that's for 25kHz with a DC cutoff frequency of 1% of RxBw rather than 4%.

fgomes · « **Reply #22 on:** July 25, 2016, 07:58:09 AM »

@perky, thanks for your feedback, I have changed the DC cutoff frequency to 1% and afc bw to 25KHz as you suggested and it worked even in the worst conditions, one node working at 50C, a total frequency deviation of about 6KHz. After some time testing it I decided to add the lna additional gain and after doing it the node freezes, even after removing the change, I don't know if it might have an hardware failure, I'll check later today.

Best regards

Fernando

perky · « **Reply #23 on:** July 25, 2016, 10:15:20 AM »

Turning on the LNA gain allows weaker signals to be received but I think has an unfortunate side effect of saturating the input when devices are close together. If this setup is on the bench I'd set the power limit on both radios to the minimum possible and curl up the antennae ino tight spirals.
Mark.

fgomes · « **Reply #24 on:** July 25, 2016, 11:47:54 AM »

@perky, I know about that saturation problem, but the nodes were far and one was in the metal 'climatic chamber' so I was seeing about -83dBm, and was trying to check the impact of the lna gain, but had no success. Seems the hardware is now broken.

Best regards

Fernando