- Welcome to LowPowerLab Forum.
Recent posts
#81
General topics / Re: Dropped Packets with High ...
Last post by Aerokeith - July 10, 2025, 06:18:16 PMI think I'm getting closer to identifying the root cause of my "dropped packets" issue. The link is very reliable, with essentially no packet drops, if I continuously transmit packets by calling send() in a tight loop. But as soon as I add any delay between calls to send(), the packet loss rate jumps up. My guess is that during the delays the RFM module is switching to RX mode to listen for incoming packets. And then on the next call to send() maybe there's some kind of glitch when switching back to TX mode that corrupts the packet. Or maybe this is happening on the receiver side?
I've tested the difference between "continuous-transmit" and "periodic transmit" modes a couple of different ways, and get consistent results: continuous-good, periodic=bad. In periodic-transmit mode, the size of the delay between calls to send() doesn't seem to matter, although I haven't yet tried very small delays to see where the breakpoint is.
In my application i have dedicated transmit-only and receive-only nodes. Is there a way I can force the module to remain in either TX or RX mode?
Note that in my application, the delay between calls to send() are important. I use the elapsedMillis library to "pace" the calls to send(), allowing the CPU to perform other tasks during the delays.
Regarding the question I asked about center frequencies: I will have two transmitters in close proximity, and each transmitter will be sending data to two receivers located slightly further away. I plan to use different center frequencies for each transmitter [using setFrequency()] and I was asking about the necessary frequency separation.
I've tested the difference between "continuous-transmit" and "periodic transmit" modes a couple of different ways, and get consistent results: continuous-good, periodic=bad. In periodic-transmit mode, the size of the delay between calls to send() doesn't seem to matter, although I haven't yet tried very small delays to see where the breakpoint is.
In my application i have dedicated transmit-only and receive-only nodes. Is there a way I can force the module to remain in either TX or RX mode?
Note that in my application, the delay between calls to send() are important. I use the elapsedMillis library to "pace" the calls to send(), allowing the CPU to perform other tasks during the delays.
Regarding the question I asked about center frequencies: I will have two transmitters in close proximity, and each transmitter will be sending data to two receivers located slightly further away. I plan to use different center frequencies for each transmitter [using setFrequency()] and I was asking about the necessary frequency separation.
#82
General topics / Re: Dropped Packets with High ...
Last post by Felix - July 09, 2025, 08:17:50 PMThey should work just as well at 2m apart.
You want the center frequency to match as much as possible. In reality it will vary from module to module by some amount, which is OK.
You want the center frequency to match as much as possible. In reality it will vary from module to module by some amount, which is OK.
#83
General topics / Re: Dropped Packets with High ...
Last post by Aerokeith - July 09, 2025, 03:33:47 PMA quick initial test indicates that it works well enough. More testing to come.
Any thoughts on the second question?
Any thoughts on the second question?
#84
General topics / Re: Dropped Packets with High ...
Last post by Felix - July 09, 2025, 02:59:24 PMLooks like, try it!
#85
General topics / Re: Dropped Packets with High ...
Last post by Aerokeith - July 09, 2025, 11:41:10 AMCan you please confirm that these are the correct settings for BitRate=100 Kbps?
Also, if I want to use two transmitters operating in close proximity (~2m apart), do I need to offset the center frequencies by more than RxBw?
Thanks!
Code Select
void set100KBPS() {
writeReg(0x03, 0x01); //REG_BITRATEMSB: 100kbps (0x0140, see DS p20)
writeReg(0x04, 0x40); //REG_BITRATELSB: 100kbps (0x0140, see DS p20)
writeReg(0x19, 0x49); //REG_RXBW: 200kHz (DccFreq=010b, RxBwMant=01b/20, RxBwExp=001b)
writeReg(0x1A, 0x89); //REG_AFCBW: 200kHz (DccFreqAfc=100b, RxBwMantAfc=01b/20, RxBwExpAfc=001b)
writeReg(0x05, 0x06); //REG_FDEVMSB: 100khz (0x0668)
writeReg(0x06, 0x68); //REG_FDEVLSB: 100khz (0x0668)
writeReg(0x29, 240); //set REG_RSSITHRESH to -120dBm
writeReg(0x37, 0b10010000); //DC=WHITENING, CRCAUTOOFF=0
// ^^->DC: 00=none, 01=manchester, 10=whitening
}
Also, if I want to use two transmitters operating in close proximity (~2m apart), do I need to offset the center frequencies by more than RxBw?
Thanks!
#86
Low Power Techniques / Re: Current Ranger LED current...
Last post by Felix - July 07, 2025, 04:04:20 PMThe max output is 3300mV.
In fact the battery is up to 4.2V and USB power is up to 5V.
It takes a divine miracle to get 6.7V at the output.
That your scope reads exactly 10x what the OLED reads tells me there's something going on with the scope.
And hence, I asked, if you could check the output with a DMM instead of the scope.
In fact the battery is up to 4.2V and USB power is up to 5V.
It takes a divine miracle to get 6.7V at the output.
That your scope reads exactly 10x what the OLED reads tells me there's something going on with the scope.
And hence, I asked, if you could check the output with a DMM instead of the scope.
#87
Low Power Techniques / Re: Current Ranger LED current...
Last post by Sarfaraj - July 06, 2025, 09:40:44 AMHi Felix, Thanks for your reply. Could you explain what you mean by that? I didn't see an overload warning in the OLED display. It is showing me 674mA as mentioned. What value do you expect to see if an oscilloscope is connected at the analogue output?
Best Regards
Best Regards
#88
Low Power Techniques / Re: Current Ranger LED current...
Last post by Felix - July 05, 2025, 10:54:28 AMThere's no way to get more than 3.3V from the CR, ever, it would OVERLOAD.
Cross check with a DMM at the output.
Cross check with a DMM at the output.
#89
General topics / Re: Dropped Packets with High ...
Last post by Felix - July 05, 2025, 10:49:25 AMSee definition for RFM69::set300KBPS().
Adjust for 100 or the lowest you need to achieve your requirement:
Datasheet is here.
Adjust for 100 or the lowest you need to achieve your requirement:
Datasheet is here.
#90
Low Power Techniques / Current Ranger LED current out...
Last post by Sarfaraj - July 04, 2025, 02:29:38 PMHi,
I am new to this community. I bought myself a current ranger MK6 to measure power consumption for my projects. As I am reading the outputs from the OLED display, I read 674mA, and simultaneously, I have an oscilloscope connected, which reads 6.74 V (RMS). I was expecting 0.674V
From the guide in lowpowerlab, I didn't clearly understand the conversion. I haven't checked the code yet. Can someone help me understand it, and also point me in the right direction for my reference?
Regards,
Sarfaraj
I am new to this community. I bought myself a current ranger MK6 to measure power consumption for my projects. As I am reading the outputs from the OLED display, I read 674mA, and simultaneously, I have an oscilloscope connected, which reads 6.74 V (RMS). I was expecting 0.674V
From the guide in lowpowerlab, I didn't clearly understand the conversion. I haven't checked the code yet. Can someone help me understand it, and also point me in the right direction for my reference?
Regards,
Sarfaraj