Hi Guys,
I have a short question about the transmission time of the RFM95 LoRa.
I read in the datasheet that a dutycycle of 1% should not be exeeded. I used some serial output to try to determine the time the RFM is sending a packet. I used this:
t0 = millis();
P = getPressure();
a = pressure.altitude(P,baseline);
t1 = millis();
char radiopacket[20] = "PAYLOAD";
rf95.send((uint8_t *)radiopacket, 20);
t2 = millis();
rf95.waitPacketSent();
t3 = millis();
Serial.print("BMP: ");Serial.print(t1 - t0);Serial.print(" Send: ");Serial.print(t2 - t1);Serial.print("Wait: ");Serial.println(t3 - t2); // time to get pressure in ms
delay(500);
The time between t0 en t1 appears to be about 30-35ms.
The time between t1 en t2 appears to be about 0-2ms.
The time between t2 en t3 appears to be about 60-65ms.
Question: Is the module actually taking 60ms to send a small packet? And if so, would that mean that I need a 6000ms delay inbetween transmissions to get a 1% dutycycle? I was planning on sending data (airspeed and altitude) about 5 times a second. I could live with twice a second (if reliable), but any slower would be unacceptable unfortunately.
Thanks in advance!
EDIT:
I have this so far, and it seems to work.
Tx:
void TxData()
{
t0 = millis();
// Set "active" value.
data.active = false;
// Get pressure from BMP180 and put in struct.
P = getPressure();
alt = pressure.altitude(P,baseline);
data.alt = alt;
//Get data and put in struct.
data.ias = random(85,140);
// Transmit Struct
Serial.print("Sending: ");Serial.print(sizeof(data));Serial.println(" bytes...");
t1 = millis();
rf95.send((const void*)(&data), sizeof(data));
rf95.waitPacketSent();
t2 = millis();
Serial.print("Pressure: ");Serial.print(t1 - t0);Serial.print("ms Tx: ");Serial.print(t2 - t1);Serial.println("ms");
}
Serial output:
Sending: 5 bytes...
Pressure: 35ms Tx: 41ms
Sending: 5 bytes...
Pressure: 35ms Tx: 41ms
Sending: 5 bytes...
Pressure: 35ms Tx: 41ms
Sending: 5 bytes...
Pressure: 35ms Tx: 41ms
Transmission time is (if i'm measuring it correctly???) 40ms for a package of 5 bytes. It's been transmitting overnight with a 2000ms interval at 10dB power. That would be a dutycycle of 2%.
Is there someone with knowlege that could confirm that this duty cycle calculation is correct? For the application I would need to bridge 1km reliably (100% free line of sight), so transmitting at the full 100mw (23dB) will be neccecery I think. It would really suck if I could only send a package (safely) every 4 sec. :(
I noticed something else. The RFM69HW datasheet also states a 1% dutycycle absolute max. However, I've been (not knowing this) running my 'old' Moteino's for quite some time now with a 25ms "TRANSMITPERIOD". Have had no problems so far. What is the limiting factor on the duty cycle? Heat? Can't feel any at all, or is it at a smaller scale?
QuoteIs the module actually taking 60ms to send a small packet?
The module is not, you have to factor in the time it takes for the Serial Library print/write, which is generally 5ms for a print and 11ms for a println off the top of my head. Someone may chime in who is more knowledgeable ::)
1% was for measurement of the resolution bandwidth
Ah, thanks for the reply.
I never knew Serial prints took so long!
But in this case, there are timing variables (t1 and t2) being set right before (t1) and right after (t2) transmitting. Later on the difference is being printed, but the time it takes to print should have no effect on the output value, right?
Or do you mean the time it takes for the arduino to talk to the RFM95 module and instruct it to transmit?
Yes, i'm wrong the calculations will still be the same :o
Err, umm...
Quote// Transmit Struct
Serial.print("Sending: ");Serial.print(sizeof(data));Serial.println(" bytes...");
t1 = millis();
should be
// Transmit Struct
t1 = millis();
Serial.print("Sending: ");Serial.print(sizeof(data));Serial.println(" bytes...");
t1= millis(now) & not millis +5 +5 "I can not say what the actually time it takes for print or printn"
It is late my brain is malfunctioning oops
Put all the Serial statements at the end to be safe :-X
I think the prints are interrupt driven (at least I hope they're not blocking, that would be silly as it would affect timing). So little impact on time.
Mark.
Hi,
I don't quite understand why the t1 and Serial printing should be switched around. If the t1 = millis() is placed before the Serial printing, then the printing time will be included in the time measurement. This is exactly what we don't want. Am I missing something, or is it just late? ;D
About the minimum interval, I just said the hell with it and coded it to transmit 5 times per second. Will let it run overnight again to see if it still works. If it can't handle that transmission interval the whole thing can go into the garbage bin anyway...
You got it right the first time. Anyway I think the prints are interrupt driven so wouldn't effect the timing much anyway.
Mark.
Hmm, what exactly do you mean with "timing" and "interrupt-driven"?
What I understand about it is that de RFM95 is connected to a hardware interrupt in on the arduino, so it can basically take over de arduino at any point.
Nevermind, got it.
Any suggestions about the duty-cycle limitation in the datasheet of 1%? It all seems to work fine at 23dB with 50ms transmission time and 150ms delay, so 25% duty cycle. But until I understand it, I'm worried it could fry any second.
Quote from: Istria on October 23, 2016, 08:52:35 PM
Hmm, what exactly do you mean with "timing" and "interrupt-driven"?
What I understand about it is that de RFM95 is connected to a hardware interrupt in on the arduino, so it can basically take over de arduino at any point.
Nevermind, got it.
Any suggestions about the duty-cycle limitation in the datasheet of 1%? It all seems to work fine at 23dB with 50ms transmission time and 150ms delay, so 25% duty cycle. But until I understand it, I'm worried it could fry any second.
If you're running this module at its maximum Tx power at a high duty cycle, it does get surprisingly hot to touch. So, I think heat is the issue (or, at least one of them). Perhaps 1% covers the worst case, which would be maximum power at the lowest bitrate and at a high coding rate with a maximum byte length transmission at the highest end of the ambient operating temperature range. Who knows? One could wish for better, more detailed guidance from the datasheet, but, since we lack that, anything else is just speculation.
Yes, it's unclear as to why this spec is as it is. The IC itself has a thermal resistance of 23.8deg/W, but that assumes a certain size thermal mounting as per JEDEC standards and the module isn't specified. However the chip too has this 1% criteria so I'm not convinced it's all down to heat. It could also be reflected power under mismatch conditions causes problems. Anyway, the spec is the spec, violate it and there's no guarantee it'll be OK.
There is a thermometer built into the chip, just as there is with the sx1231h. One could perhaps monitor the heat situation that way. Presumably they put it there for a reason.
Hmm,
I guess it's not just an easy function in the library to get that temp sensor value?
I think I'm just going to keep trying to run it at 25% dutycycle (assuming the measured 40ms is actually all transmitting) and max tx power.
Quick questions:
1) WhiteHare, you mentioned that at 20dB and high duty cycle the module is getting hot to touch. I get no heat whatsoever. Same as powered off. Powered directly from 3.3V 5A power supply, so no current limitation.
2) What is the highest Tx power I can set it? 20dB of 23dB?
3) A range test yesterday with the standard 1/4 wave wire antenna got me ca. 600m reliably, and 850m getting a packet every so often (missing 90%+ or so). At 1000m no link. This was with the transmitter placed at the window at about 2m above ground at 20dB. Then I decided to walk te other way. So the "LOS" was though at least 3 walls in my building, then 20m down the road another 4-5 walls of the flat across the street after which just an road with a tree here and there.
Could I expect, using the same setup and antenna, a reliable link of 1500m with almost completely free LOS and (1/4 wire) transmitter antenna at 20m altitude and receiver (wire) antenna at ca. 3m altitude?
If not, would I gain range by soldering on an sma connector and using an ebay external antenna (the wifi router kind)?
Quote//Standby
Write(0x01, 0x81);
//FS mode RX
Write(0x01, 0x04);
//TempMonitorOn
Write(0x3B, 0x00);
//wait 200ms
//TempMonitorOff
Write(0x3B, 0x01);
//Standby
Write(0x01, 0x81);
//GetTemp
Temp = Read(0x3C);
@Istria
I've asked similar questions in the past, but never really got any answers. For example: https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/maximum-rfm9x-lora-tx-power-(is-23dbm-actually-feasible)/msg11374/#msg11374
So far the LoRa user population appears to be small and/or doesn't talk much. Most likely you will simply have to read the datasheet and/or run some experiments to get your answers. For that and other reasons I'm primarily using the RFM69HW. I purchased the Moteino LoRa's as fallback insurance, which so far I haven't needed to use. Like you I got a feel for how well they work by doing a similar walk around the neighborhood experiment and testing for reception. As you've discovered, the signal range is fantastic, but the trade-off is that on-the-air transmission time can be comparatively long for the same size data payload. Depending on the particulars, that may or may not matter to you.
Good luck.
23db @ 240ma = very hot :-\
//Pa maximum power
RADIO_Write(RegPaConfig, 0xFF);
//150% LNA current & maximum gain
RADIO_Write(RegLna, 0x23);
//PaDac 20dBm on PA_BOOST
RADIO_Write(RegPaDac, 0x87);
//Set RegOcp 240ma
RADIO_Write(RegOcp, 0x3B);
//Bandwith 7.8kHz, Coding rate 4/8, Implicit header
RADIO_Write(RegModemConfig1, 0x09);
//Spreading factor 12, PayloadCRC on
RADIO_Write(RegModemConfig2, 0x62);
//Setting additional register for SF12 optimization
RADIO_Write(RegDetectOptimize, 0xC3);
//LoRa detection threshold SF12
RADIO_Write(RegDetectionThreshold, 0x0A);