Skip to content
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

Fixed wrong frequency (json) & upload for TTN V3 #72

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

itsygithub
Copy link

Workaround for wrong frequency in json file. Will also solve the problem with upload for TTN V3. Tested with 868 MHz.This is the first time ever I upload or commend in gitub. Hope I did it wright.

Workaround for wrong frequency in json file. Will also solve the problem with upload for TTN V3. Tested with 868 MHz.This is the first time ever I upload or commend in gitub. Hope I did it wright.
Workaround for wrong frequency in json file. Will also solve the problem with upload for TTN V3. Tested with 868 MHz.This is the first time ever I upload or commend in gitub. Hope I did it wright.
@d-a-v
Copy link

d-a-v commented Apr 5, 2021

Nice finding !

Did you try to simply change from int to float in divisions ?
like:

doc["freq"] = "" + (freqs[gwayConfig.ch].upFreq / 1000000);

to

doc["freq"] = "" + (freqs[gwayConfig.ch].upFreq / 1000000.0);

?

@itsygithub
Copy link
Author

itsygithub commented Apr 6, 2021

Thank you for your fast answer. I tried your fix for both lines:

doc["freq"] = "" + (freqs[gwayConfig.ch].upFreq / 1000000.0);
ftoa((double)freqs[gwayConfig.ch].upFreq / 1000000.0, cfreq, 6);

But as example the frequency for channel 0 was 868099975 so it did not fix the issue.
Tested with Hallad-Board.

@d-a-v
Copy link

d-a-v commented Apr 6, 2021

Thanks for trying !
I hope your fix will be merged and maybe the data structure improved by the author to avoid to repeat frequencies in both format.

@itsygithub
Copy link
Author

Thanks a lot :-) It is really a great project and it should also live with stack V3 :-)

@IoTThinks IoTThinks mentioned this pull request Apr 15, 2021
src/loraModem.h Outdated
// TTN defines an additional channel at 869.525 MHz using SF9 for class B. Not used
{ 868100000, 125, 7, 12, 868100000, 125, 7, 12, "868.100"}, // Channel 0, 868.1 MHz/125 primary
{ 868300000, 125, 7, 12, 868300000, 125, 7, 12, "868.300"}, // Channel 1, 868.3 MHz/125 mandatory and (SF7BW250)
{ 868500000, 125, 7, 12, 868500000, 125, 7, 12, "868.800"}, // Channel 2, 868.5 MHz/125 mandatory
Copy link

Choose a reason for hiding this comment

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

Should be here 868.500?

Copy link
Author

@itsygithub itsygithub Apr 26, 2021

Choose a reason for hiding this comment

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

What do you think has to be 868.500? Which value should be changed?

Copy link

Choose a reason for hiding this comment

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

"868.800"?

Copy link
Author

Choose a reason for hiding this comment

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

Ah, now I see - typing error! I will correct it - thanks!

@dinoi7
Copy link

dinoi7 commented May 26, 2021

Thanks for this great project and thanks for this fix.
Unfortunately I still have problems to make downlink and OTAA working.
Could you please check or provide me your TTN Settings for the Node and for the Gateway:

Node:

2021-05-26 22_49_42-General settings The Things Network

2021-05-26 22_50_49-General settings The Things Network 2

Gateway:

2021-05-26 22_52_13-General settings - Gateway The Things Network

In the OTAA case I try to trace it from TTN Cloud to 1ch Gateway to Node Serial Log.

In the TTN Cloud the Downlink is send to the gateway:

grafik

In the Gateway I can see the transfer:

grafik

But in the Node Serial log there is nothing arrived:

grafik

Any ideas?
Regards
Dinoi

@pimente
Copy link

pimente commented Jul 19, 2021

@itsygithub
Replacing ftoa by dtostrf worked for me:

// ftoa((double)freqs[gwayConfig.ch].upFreq / 1000000, cfreq, 6);
dtostrf((double)freqs[gwayConfig.ch].upFreq / 1000000, 6, 3, cfreq);

and does not require to change loraModem.h. Maybe this could make your PR lighter?

@IoTThinks
Copy link

IoTThinks commented Aug 14, 2022

// ftoa((double)freqs[gwayConfig.ch].upFreq / 1000000, cfreq, 6);
dtostrf((double)freqs[gwayConfig.ch].upFreq / 1000000, 6, 3, cfreq);

This is working for me.
FYI, the fix is in _txRx.ino

IoTThinks added a commit to IoTThinks/ESP-1ch-Gateway that referenced this pull request Aug 14, 2022
To fix precision for frequency
things4u#72
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