Getting up to speed with this Moeino boards. Have several with RFM69HW radios. Testing them in promiscuous mode in one direction. I have some test code that goes
payload[VAL_MODE]++;
radio.send(0, payload, sizeof(payload), false);
delay(30);
And the output on the other end
New RX
2:0:0:0
New RX
4:0:0:0
New RX
6:0:0:0
New RX
12:0:0:0
New RX
14:0:0:0
New RX
17:0:0:0
New RX
22:0:0:0
New RX
25:0:0:0
New RX
28:0:0:0
New RX
29:0:0:0
New RX
31:0:0:0
New RX
33:0:0:0
New RX
38:0:0:0
New RX
40:0:0:0
New RX
45:0:0:0
New RX
52:0:0:0
New RX
55:0:0:0
New RX
58:0:0:0
New RX
62:0:0:0
New RX
67:0:0:0
New RX
69:0:0:0
New RX
78:0:0:0
New RX
80:0:0:0
New RX
82:0:0:0
New RX
84:0:0:0
New RX
89:0:0:0
So as you can see I'm missing a bunch of packets. Radios are both being powered by FTDI boards. They are 6" away from each other on my lab bench. I slow it down to 1 second waits and i still miss packets.
IS this normal for these radios? Is this why the majority of the examples all use ACK mode for transmission?
look like situation improves when I reduce the size of the payload. Was using 41 bytes @ 33ms delay, dropping down to 10 bytes looks almost perfect.
Is there a speed limit I am hitting somewhere? Should I fiddle with bitrate?
*looks at library code*
So by default the bitrate is 4800, so I'm hitting that limit. I've tried un-commenting #define BR_300KBPS but the radios don't work when I do. What is the upper limit for bitrate in these radios?
The upper limit is 300kbps and a bunch of us run at this speed to maximize battery life. I tend to get around 1% packet loss when I do my testing but then I live in a neighborhood <2 miles from downtown. Not sure if this would fall significantly if I was out in the country but others should be able to speak to that.
There are other threads in the RFM69 section of the forums that discuss running at 300kbps but here are the settings which work for me:
https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/changing-the-rmf69hcw-configuration-and-back/msg17071/#msg17071
I got both radios working at 300kbps, seems like I just had to turn off encryption. But I'm still getting high packet loss sending 41 bytes every 33ms. Is there some limit I'm hitting elsewhere?
From a recent thread, JoeLucid's experience suggested that at 300kbps you're better off with at least 4 preamble bytes and and at least three sync bytes. Those are greater than the defaults, so you may want to try increasing yours.
Data whitening might help. It's not defaulted either.
Beyond that, what RSSI levels are you getting? Higher speeds need a higher signal-to-noise ratio, so you may want to measure both.
My first guess though: 6" apart sounds too close. You're probably saturating your radios. Try moving them apart to a more reasonable distance, like, say, 10 or 15 feet apart, line-of-sight. That's still close, but not overly so.
My second guess: your FTDI adapters don't supply enough juice. So, when you send packets at a faster pace, that becomes more noticeable, because any caps are draining and not given enough time to refill before the next packet. As a workaround, try powering your moteino's with batteries instead.
Thanks, moved radios to 8' with similar results.
So my application I'm looking at a need for 41 bytes bytes every 33ms. I'm actually trying to stream 40 DMX channels to several receivers in a broadcast type setup. So by my math I really only need about 20kbps.
I'm trying it now at 115k just because it's any even modem rate.
radio.writeReg(0x03, RF_BITRATEMSB_115200 );
radio.writeReg(0x04, RF_BITRATELSB_115200 );
radio.writeReg(0x19, 0x40); //REG_RXBW: 500kHz
radio.writeReg(0x1A, 0x80); //REG_AFCBW: 500kHz
radio.writeReg(0x05, 0x13); //REG_FDEVMSB: 300khz (0x1333)
radio.writeReg(0x06, 0x33); //REG_FDEVLSB: 300khz (0x1333)
radio.writeReg(0x29, 240); //set REG_RSSITHRESH to -120dBm
But I'm having a hard time finding the guidance on how to adjust the other radio attributes to mesh with the change in bitrate.
I'm also seeing a lot of references to 'continuous mode' TX, which may be what I want in my application but haven't found any instructions or examples of how to use that mode.
I'll dig into the library code to look for preamble sync and whitening to make those changes.
Arg.
My settings:
/* 0x2D */ { REG_PREAMBLELSB, 0x4 },
/* 0x2E */ { REG_SYNCCONFIG, RF_SYNC_ON | RF_SYNC_FIFOFILL_AUTO | RF_SYNC_SIZE_3 | RF_SYNC_TOL_0 },
radio.writeReg(0x03, RF_BITRATEMSB_115200 ); //REG_BITRATEMSB: 300kbps (0x006B, see DS p20)
radio.writeReg(0x04, RF_BITRATELSB_115200 ); //REG_BITRATELSB: 300kbps (0x006B, see DS p20)
radio.writeReg(0x19, 0x40); //REG_RXBW: 500kHz
radio.writeReg(0x1A, 0x80); //REG_AFCBW: 500kHz
radio.writeReg(0x05, 0x13); //REG_FDEVMSB: 300khz (0x1333)
radio.writeReg(0x06, 0x33); //REG_FDEVLSB: 300khz (0x1333)
radio.writeReg(0x29, 240); //set REG_RSSITHRESH to -120dBm
TX code:
void loop() {
payload[VAL_MODE]++;
radio.send(255, payload, sizeof(payload), false);
delay(33);
RX
if (radio.receiveDone())
{
//new packet received.
//Serial.println("New RX");
/*
Serial.print("Got [");
Serial.print(radio.SENDERID);
Serial.print(':');
Serial.print(radio.DATALEN);
Serial.print("] > ");
for (byte i = 0; i < radio.DATALEN; i++)
Serial.print(radio.DATA[i], HEX);
Serial.println();
*/
//if it's 4 bytes, it's probably OTA Update request
if(radio.DATALEN == 4)
{
Serial.println("OTA?");
CheckForWirelessHEX(radio, flash, false);
}
else
{
uint16_t base_address = (SUITADDRESS - 1) * 4;
strip.setBrightness(radio.DATA[base_address + VAL_BRIGHTNESS]);
Serial.print(radio.DATA[base_address + VAL_MODE]);
Serial.print(':');
Serial.print(radio.DATA[base_address + VAL_BRIGHTNESS]);
Serial.print(':');
Serial.print(radio.DATA[base_address + VAL_COLOR]);
Serial.print(':');
Serial.print(radio.DATA[base_address + VAL_SPEED]);
Serial.print(':');
Serial.println(radio.readRSSI(false));
Result:
28:0:0:0:-21
30:0:0:0:-21
34:0:0:0:-21
38:0:0:0:-21
45:0:0:0:-21
48:0:0:0:-21
51:0:0:0:-21
54:0:0:0:-21
55:0:0:0:-27
58:0:0:0:-21
60:0:0:0:-21
62:0:0:0:-21
73:0:0:0:-22
78:0:0:0:-21
81:0:0:0:-21
83:0:0:0:-22
87:0:0:0:-21
91:0:0:0:-22
96:0:0:0:-21
107:0:0:0:-22
All sorts of packet loss @ 41 byte payload.
A lot of radio problems turn out to be power supply related. I'd check that next.
Quote from: ChemE on April 01, 2017, 03:53:35 AM
The upper limit is 300kbps and a bunch of us run at this speed to maximize battery life. I tend to get around 1% packet loss when I do my testing but then I live in a neighborhood <2 miles from downtown. Not sure if this would fall significantly if I was out in the country but others should be able to speak to that.
There are other threads in the RFM69 section of the forums that discuss running at 300kbps but here are the settings which work for me:
https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/changing-the-rmf69hcw-configuration-and-back/msg17071/#msg17071
Woah, his settings are an improvement.
79:0:0:0:-103
80:0:0:0:-96
81:0:0:0:-98
82:0:0:0:-88
83:0:0:0:-103
84:0:0:0:-103
85:0:0:0:-100
86:0:0:0:-102
87:0:0:0:-104
88:0:0:0:-104
89:0:0:0:-104
90:0:0:0:-98
91:0:0:0:-108
92:0:0:0:-91
93:0:0:0:-102
94:0:0:0:-98
95:0:0:0:-100
96:0:0:0:-101
97:0:0:0:-102
98:0:0:0:-104
99:0:0:0:-98
100:0:0:0:-104
101:0:0:0:-98
102:0:0:0:-104
103:0:0:0:-103
104:0:0:0:-106
105:0:0:0:-107
106:0:0:0:-103
107:0:0:0:-102
108:0:0:0:-97
109:0:0:0:-98
110:0:0:0:-102
111:0:0:0:-98
112:0:0:0:-99
113:0:0:0:-103
114:0:0:0:-100
115:0:0:0:-102
116:0:0:0:-107
117:0:0:0:-102
118:0:0:0:-104
119:0:0:0:-108
120:0:0:0:-97
121:0:0:0:-103
122:0:0:0:-92
123:0:0:0:-101
124:0:0:0:-100
125:0:0:0:-104But RSSI is bottomed out. Should that be expected?
Sorry for question overload. Appreciate any who help me understand these radios.
Quote from: WhiteHare on April 01, 2017, 01:50:53 PM
A lot of radio problems turn out to be power supply related. I'd check that next.
Definitely agree I used ESP8266's often, I'm using sparkfun FTDI boards here straight off a 7 port powered hub, so I hope it's not related to power.
Your RX code it waiting until the last possible microsecond to read the radio's RSSI and after a bunch of slow serial.prints. You really should be reading it as soon as you detect that a packet has been received and cache it for later output. Reason being is RSSI is most accurate as the packet comes in and starts becoming less accurate as time passes. Probably wont push those -108s up to -27 but it will increase them some. I don't get anywhere near those low signals when I test at power level 0 with my settings btw. I get -50s at power level 0 and -25ish at power level 31.
I moved it to
if (radio.receiveDone())
{
int pwr = radio.readRSSI(false);
//new packet received.
And still get
206:0:0:0:-103
207:0:0:0:-104
208:0:0:0:-99
209:0:0:0:-104
210:0:0:0:-102
211:0:0:0:-110
212:0:0:0:-93
213:0:0:0:-103
214:0:0:0:-103
And just to be sure my TX is now
void setup() {
Serial.begin(SERIAL_BAUD);
radio.initialize(FREQUENCY,NODEID,NETWORKID);
radio.setPowerLevel(31);
radio.setHighPower(); //uncomment only for RFM69HW!
I'm actually using your settings ChemE, not sure why just changing from stock to yours is showing a 80 difference in power.
Just to be sure, without changing the user sketchs; just the config structure in the RF69 library, stock I get
49:0:0:0:-18
54:0:0:0:-18
56:0:0:0:-18
62:0:0:0:-18
71:0:0:0:-18
73:0:0:0:-18
74:0:0:0:-26
80:0:0:0:-18
82:0:0:0:-18
89:0:0:0:-20
92:0:0:0:-17
96:0:0:0:-19
97:0:0:0:-27
103:0:0:0:-18
104:0:0:0:-28
105:0:0:0:-28
107:0:0:0:-17
109:0:0:0:-18
And using your posted config:
225:0:0:0:-104
226:0:0:0:-104
227:0:0:0:-105
228:0:0:0:-103
229:0:0:0:-99
230:0:0:0:-100
231:0:0:0:-102
232:0:0:0:-103
233:0:0:0:-103
234:0:0:0:-93
235:0:0:0:-99
236:0:0:0:-92
237:0:0:0:-92
238:0:0:0:-102
239:0:0:0:-102
240:0:0:0:-99
241:0:0:0:-103
242:0:0:0:-106
243:0:0:0:-85
244:0:0:0:-103
245:0:0:0:-101
246:0:0:0:-107
247:0:0:0:-103
Definite difference is packet loss, by alarming jump in RSSI.
Well in trying to find the setting that affects RSSI, (I would change one thing about the config and test to see if it changes result) I found by leaving the bitrate 'stock' to the library
/* 0x03 */ { REG_BITRATEMSB, RF_BITRATEMSB_55555}, // default: 4.8 KBPS
/* 0x04 */ { REG_BITRATELSB, RF_BITRATELSB_55555},
/* 0x05 */ { REG_FDEVMSB, RF_FDEVMSB_50000}, // default: 5KHz, (FDEV + BitRate / 2 <= 500KHz)
/* 0x06 */ { REG_FDEVLSB, RF_FDEVLSB_50000},
I suddenly get good reception with high RSSI.
24:0:0:0:-27
25:0:0:0:-27
26:0:0:0:-27
27:0:0:0:-27
28:0:0:0:-27
29:0:0:0:-27
30:0:0:0:-27
31:0:0:0:-27
32:0:0:0:-27
33:0:0:0:-28
34:0:0:0:-26
35:0:0:0:-27
36:0:0:0:-28
37:0:0:0:-27
38:0:0:0:-27
39:0:0:0:-27
40:0:0:0:-26
41:0:0:0:-27
42:0:0:0:-27
43:0:0:0:-28
44:0:0:0:-28
Which doesn't make sense. How am I getting reception of 41 bytes every 33ms @ 4800 baud? And why does just turning off CRC make that happen?
RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON
to
RF_PACKET1_CRC_OFF | RF_PACKET1_CRCAUTOCLEAR_OFF
What happens if you use my 300kbps settings but dial down your broadcast frequency to just a few times a second? I'm wondering if like WhiteHare said you have power supply issues.
Quote from: madsci1016 on April 01, 2017, 02:45:31 PM
And why does just turning off CRC make that happen?
RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON
to
RF_PACKET1_CRC_OFF | RF_PACKET1_CRCAUTOCLEAR_OFF
Could be that you are getting one or more bit errors in a large fraction of your packets. I turn off CRC which would let bit error packets come through. So you might be getting a high fraction through but they are malformed. Also regarding high packet loss originally at 55kbps but at a very tight spacing, it takes 40ish ms to get a packet across at slower speeds with ACKs and retries. It could be that you were just sending packets too fast and the transmits were not done before the next tried to start. Maybe try dialing down your packet TX frequency to see if that helps you.
I think it might be due to timing, and specifically when RSSI register is read.
It seems ChemE's settings gave a low packet error rate, but was reading a very low RSSI. With your settings you were getting a high packet error rate but with much more sensible RSSI. There could be differences in timing.
Since the RSSI threshold is set to very low, as soon as the packet is read from the FIFO and the radio put back into RX mode (which is done in the ISR triggered by PayloadReady), the radio will re-trigger again on noise setting the RSSI register to the noise value it read. You're getting values that are close to that noise value. So if there is any delay in your main loop (like for example lots of prints) before you call radio.receiveDone() but after a packet had been received then the original RSSI value will have been overwritten.
So I think the RSSI register should be read in the ISR, not in the main loop, just prior to reading the FIFO. Strangely enough such an RSSI read is actually done in the ISR! I think you should be using that value not re-reading the RSSI register in your main loop.
You also might want to check that the speed of the SPI is as fast as it can be and not set to a few hundred kHz.
Mark.
Quote from: ChemE on April 01, 2017, 02:48:48 PM
What happens if you use my 300kbps settings but dial down your broadcast frequency to just a few times a second? I'm wondering if like WhiteHare said you have power supply issues.
Same reported RSSIs, with a bunch of noise receptions too since I guess CRC is turned off and the TX is sitting idle for a while.
35:0:0:0:-102
167:68:133:247:-97
141:200:200:238:-98
246:185:221:180:-100
36:0:0:0:-97
37:0:0:0:-104
64:91:118:4:-93
186:23:77:33:-95
38:0:0:0:-99
39:0:0:0:-103
189:183:129:177:-101
65:128:107:6:-96
50:60:197:225:-100
35:161:120:157:-93
227:56:156:135:-99
Try using ChemE's settings and changing
if (radio.receiveDone())
{
int pwr = radio.readRSSI(false);
//new packet received.
to
if (radio.receiveDone())
{
int pwr = radio.RSSI;
//new packet received.
Mark.
Quote from: perky on April 01, 2017, 03:44:49 PM
I think it might be due to timing, and specifically when RSSI register is read.
It seems ChemE's settings gave a low packet error rate, but was reading a very low RSSI. With your settings you were getting a high packet error rate but with much more sensible RSSI. There could be differences in timing.
Since the RSSI threshold is set to very low, as soon as the packet is read from the FIFO and the radio put back into RX mode (which is done in the ISR triggered by PayloadReady), the radio will re-trigger again on noise setting the RSSI register to the noise value it read. You're getting values that are close to that noise value. So if there is any delay in your main loop (like for example lots of prints) before you call radio.receiveDone() but after a packet had been received then the original RSSI value will have been overwritten.
So I think the RSSI register should be read in the ISR, not in the main loop, just prior to reading the FIFO. Strangely enough such an RSSI read is actually done in the ISR! I think you should be using that value not re-reading the RSSI register in your main loop.
You also might want to check that the speed of the SPI is as fast as it can be and not set to a few hundred kHz.
Mark.
I'm too beginner with understanding these registers but this seems to make sense, if someone with the same radios can confirm the same behavior.
The RFM69 library looks to be using SPI clockDIV4 which would be around 2Mhz on a 16Mhz crystal, so that seems fast enough.
As for the RSSI, there's something funky in this library. It's not commented out in the ISR, it's just after the if statment at the bottom of the ISR. But when I call readRSSI from userspace, that value will get overwritten. Why do that? Why not just read back the RSSI saved from the ISR?
That did it perky, I see what's going on now. I missed RSSI as a public variable and only saw readRSSI as a public function.
Now output at 300kbps
64:0:0:0:-27
65:0:0:0:-26
66:0:0:0:-26
67:0:0:0:-26
68:0:0:0:-27
69:0:0:0:-27
57:221:130:68:-96
70:0:0:0:-28
71:0:0:0:-28
72:0:0:0:-27
73:0:0:0:-27
74:0:0:0:-27
75:0:0:0:-27
76:0:0:0:-26
77:0:0:0:-27
It's obviously getting some noise packets without CRC enabled. Wonder if it's better to bring up the minimum RSSI or just implement my own checksum in userspace.
CRC should now work ;)
Mark.
Worth noting that I had CRC off because I wanted to send very tiny packets and with CRC on the radio pads out your payload to be a multiple of 16 bytes. So your 41 bytes is actually 48, probably not a biggie to you. It was causing my 3-byte payload to become 16 which I railed against.
Quote from: perky on April 01, 2017, 04:04:37 PM
CRC should now work ;)
Mark.
Not quite.
Simply changing to
RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ONyields
60:0:0:0:-24
96:0:0:0:-25
124:0:0:0:-26
224:0:0:0:-25
248:0:0:0:-28
3:0:0:0:-25
7:0:0:0:-25
55:0:0:0:-28
67:0:0:0:-25
96:0:0:0:-25
159:0:0:0:-25
192:0:0:0:-25
204:0:0:0:-27
epic packet loss.
You need to set CRC enabled for both transmission and reception, have you done that on both ends?
Mark.
Try turning up your RSSI threshold to something above the noise floor but well below your RSSI. Something like -80dbm or -90dbm.
Quote from: perky on April 01, 2017, 04:16:07 PM
You need to set CRC enabled for both transmission and reception, have you done that on both ends?
Mark.
If you mean do I make that change in the RFM69 library and then recompile and flash both the TX and RX, than yes I did it on both ends. Otherwise not sure what you mean.
Testing also shows it's related to packet size. If I reduce to a 15 byte packet:
200:0:0:0:-25
203:0:0:0:-24
204:0:0:0:-27
206:0:0:0:-27
207:0:0:0:-27
208:0:0:0:-26
209:0:0:0:-28
212:0:0:0:-24
215:0:0:0:-24
216:0:0:0:-27
219:0:0:0:-27
222:0:0:0:-24Still some loss but not as epic.
That's still a very bad packet loss. ChemE's settings produce next to no packet loss. You shouldn't be getting more than 1% really, especially with such a strong signal. Are you using ChemE's settings but just with CRC enabled (both ends)?
Here's the settings:
const uint8_t CONFIG[][2] =
{
{ REG_OPMODE, RF_OPMODE_SEQUENCER_ON | RF_OPMODE_LISTEN_OFF | RF_OPMODE_STANDBY }, // 0x01
{ REG_DATAMODUL, RF_DATAMODUL_DATAMODE_PACKET | RF_DATAMODUL_MODULATIONTYPE_FSK | RF_DATAMODUL_MODULATIONSHAPING_00 }, // 0x02
{ REG_BITRATEMSB, RF_BITRATEMSB_300000 }, // 0x03
{ REG_BITRATELSB, RF_BITRATELSB_300000 }, // 0x04
{ REG_FDEVMSB, RF_FDEVMSB_300000 }, // 0x05
{ REG_FDEVLSB, RF_FDEVLSB_300000 }, // 0x06
{ REG_FRFMSB, RF_FRFMSB_915 }, // 0x07
{ REG_FRFMID, RF_FRFMID_915 }, // 0x08
{ REG_FRFLSB, RF_FRFLSB_915 }, // 0x09
{ REG_RXBW, RF_RXBW_DCCFREQ_111 | RF_RXBW_MANT_16 | RF_RXBW_EXP_0 }, // 0x19
{ REG_DIOMAPPING1, RF_DIOMAPPING1_DIO0_01 }, // 0x25
{ REG_DIOMAPPING2, RF_DIOMAPPING2_CLKOUT_OFF }, //0x26
{ REG_IRQFLAGS2, RF_IRQFLAGS2_FIFOOVERRUN }, // 0x28
{ REG_RSSITHRESH, 220 }, // 0x29
{ REG_PREAMBLELSB, RF_PREAMBLESIZE_LSB_VALUE }, // 0x2D
{ REG_SYNCCONFIG, RF_SYNC_ON | RF_SYNC_FIFOFILL_AUTO | RF_SYNC_SIZE_2 | RF_SYNC_TOL_0 }, // 0x2E
{ REG_SYNCVALUE1, 0x2D }, // 0x2F
{ REG_SYNCVALUE2, networkID }, // 0x30
{ REG_PACKETCONFIG1, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_OFF | RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON | RF_PACKET1_ADRSFILTERING_OFF }, // 0x37
{ REG_PAYLOADLENGTH, 66 }, // 0x38
{ REG_FIFOTHRESH, RF_FIFOTHRESH_TXSTART_FIFONOTEMPTY | RF_FIFOTHRESH_VALUE }, // 0x3C
{ REG_PACKETCONFIG2, RF_PACKET2_RXRESTARTDELAY_2BITS | RF_PACKET2_AUTORXRESTART_ON | RF_PACKET2_AES_OFF }, // 0x3D
{ REG_TESTDAGC, RF_DAGC_IMPROVED_LOWBETA0 }, // 0x6F
{ 255, 0 }
};
And yes just Chem's settings with the change on CRC.
And before someone thinks power again I have tried powering the TX with a fully charged li-po battery at 3.9V into Vin and same result. Can't get more hearty than that.
Also with two other Moteino sets to make sure it wasn't a hardware issue.
I'm not sure if it's related to Chem's settings. If I go back to stock library settings, and reduce update interval to 330 ms, I still have packet loss in promiscuous mode :
213:0:0:0:-16
217:0:0:0:-15
221:0:0:0:-15
223:0:0:0:-16
226:0:0:0:-16
228:0:0:0:-16
230:0:0:0:-15
233:0:0:0:-16
236:0:0:0:-16
240:0:0:0:-16
244:0:0:0:-16
245:0:0:0:-27
253:0:0:0:-16
254:0:0:0:-26
0:0:0:0:-15
4:0:0:0:-16
5:0:0:0:-26
6:0:0:0:-27
14:0:0:0:-27
15:0:0:0:-27
17:0:0:0:-15
SO do many people run these radios with no ACK in promiscuous mode? Maybe it's just nature of them?
Then it might be that there are lots of 0x00 or 0xFFs in the datastream. There has to be a transition every 16 bits or so to keep the bit synchronizer happy, this would explain why it appears to be packet length related.
Try turning on data whitening on both ends, change:
{ REG_PACKETCONFIG1, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_OFF | RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON | RF_PACKET1_ADRSFILTERING_OFF }, // 0x37
to
{ REG_PACKETCONFIG1, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_WHITENING | RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON | RF_PACKET1_ADRSFILTERING_OFF }, // 0x37
Mark.
That was exactly it. All looks awesome now. Is there a drawback to whitening not to enable it by default in the library? Would have saved me 2 days of debugging.
Even the stock library settings, at 4800 bps seems happy to send 41 bytes every 33 ms (14432 bps).
* thinks about it *
Wait a minute. Me thinks the comments are outdated or I misunderstood them
/* 0x03 */ { REG_BITRATEMSB, RF_BITRATEMSB_55555}, // default: 4.8 KBPS
Library is using 55,555 bps isn't it?
Nice!
This has caught out others before, I'm not sure why whitening is not default. It makes sense to do that IMO. Also the default comment of 4.8k is for power up default of the radio, not the library. The library does indeed default to 55555.
Mark.
BTW you should now turn on CRC on both ends, you'll need that protection against getting bit errors with such large packets. Your packet error rate should be somewhat less than 1% as you've got quite strong signals I think.
Mark.
Quote from: perky on April 01, 2017, 05:16:38 PM
BTW you should now turn on CRC on both ends, you'll need that protection against getting bit errors with such large packets. Your packet error rate should be somewhat less than 1% as you've got quite strong signals I think.
Mark.
It is, I went back to full stock with the whitening mod. I don't need more than the 20-30 Kps so I won't push the bitrate higher than the stock 55k.
Now if I could get back my two lost days...
I'm not bitter or anything.... May have opened an issue on the RFM69 github though....
But otherwise, THANK YOU for putting up with my ramblings and multiple posts and helping me. If I did want to try something higher, say 100kbps just to improve latency, is there a good guide you could point me too for setting the other attributes like FDEV?
You're welcome, glad it's working ;)
If you need to fiddle there's a sticky thread that I started that gives the rules for FDEV, BR and RXBW and how they are related:
https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/definition-of-rxbw-with-rfm69/
Mark.
Exactly what I needed, thanks again.
I thought data whitening instantly doubled the size of the payload by turning 0s into 01s and 1s into 10 so the stream stays DC-free regardless of composition. This is why I've always avoided data whitening. Is that not the case?
You're thinking of Manchester encoding which does double the number of bits. Data whitening is basically a scrambler that converts a stream of bytes into another stream of the same number of bytes but scrambled. A descrambler the other end recovers the original byte stream. So exactly the same number of bytes are sent.
Mark.