Skip to content

sx127x 20dBm support 2 #153

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Aug 6, 2018
Merged

Conversation

dontsovcmc
Copy link
Contributor

@dontsovcmc dontsovcmc commented May 31, 2018

#79 (comment)

check current with BSFrance Lora 32u4 (HPD13) modules:
17 dBm - 59 mA
20 dBm - 80 mA

@Yury-MonZon
Copy link

This is working pretty good.

I've checked it with this power meter:

power setting 17 = 36mW (50mW)
power setting 20 = 64mW (100mW)

It is a bit lower than theory (in parentheses) because the tx pulse is so short.

When would this be merged to the master? @sandeepmistry

src/LoRa.h Outdated
@@ -54,6 +54,8 @@ class LoRaClass : public Stream {
void setSyncWord(int sw);
void enableCrc();
void disableCrc();
// Over Current Protection control (Semtech SX1276/77/78/79 5.4.4.)
void setOCP_sx127x(uint8_t mA);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this needs to be a public API anymore. Maybe the name can also be changed to setOCP as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem!
If your library doesn't support another chips it's not needed.
As I preferred commented code, I think to save comment is better.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only supports Semtech SX1276/77/78/79 as per the read me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uh.. i don't read read.me. wait a minute, I'll correct pull request.

@sandeepmistry
Copy link
Owner

API.md also needs to be updated accordingly for the new supported values.

@dontsovcmc
Copy link
Contributor Author

Check, please =)

@halukmy
Copy link

halukmy commented Jul 31, 2018

@dontsovcmc what is command for get the value?

@dontsovcmc
Copy link
Contributor Author

who needs to get over current protection value?! =)

minor code styling
properly map TX power levels 18 and 19
@sandeepmistry sandeepmistry merged commit 884769e into sandeepmistry:master Aug 6, 2018
@morganrallen morganrallen mentioned this pull request Feb 4, 2019
@danak6jq
Copy link

Note that Semtech specifies a maximum duty cycle of 1% at +20dBm.

@nevercast
Copy link

nevercast commented Jul 16, 2019

After speaking with Semtech they seem to think that as long as local regulations have no issue with your duty cycle, transmitting long duration payloads at +20dBm will be fine. This is obviously some mixed information. I asked if I can send 30 second long payloads at +20dBm and they said that will be fine.

Which leads to the question, duty cycle relative to what? 1% of the year? 1% of an hour?

@danak6jq
Copy link

I am a little surprised if regulatory limits made it into the physical limits part of the Semtech datasheet, but I can understand it happening. If 30 seconds transmit is OK at +20dBm, that's 1% of 5 minutes. I don't recall off the top of my head what the Part 15 conditions are for 1% but I believe this is well within the legal limits. Thank you for following-up with Semtech.

@nevercast
Copy link

Regulatory limits in a Datasheet is certainly odd to me, in my country, at 900MHz there is no Duty Cycle requirement provided that the signal is Digitally Modulated. So the note about 1% really does not apply to me; unless it is for power dissipation concerns, such as transmitting continuously in high ambient temperature?

I didn't get any more information from Semtech other than them saying that 30 second transmissions at +20dBm should not damage the device. So that's what I'll do :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants