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

Incorrect transmit frequency #40

Open
Suretronic opened this issue Oct 29, 2017 · 9 comments
Open

Incorrect transmit frequency #40

Suretronic opened this issue Oct 29, 2017 · 9 comments

Comments

@Suretronic
Copy link

Gateway receives uplink ok at 865062500 but then transmits an ack at 865620000 when it should be the same as the Uplink frequency.

Could be misinterpreting the ack request from the LoRaWAN server as the same end node communicates with an 8+1 channel gateway (mcard on RPi) using the same router, exact same configuration, with no problem, i.e. 86506250 up and down.

This router is Orne Brocaar's LoRaWAN server, latest version.

Here's some output from the ESP8266 gateway via telnet:
rxpk 0176c600a020a6f42f19ff48 message {"rxpk":[{"rssi":-91,"stat":1,"modu":"LORA","rfch":1,"tmst":1590172565,"datr":"SF12BW125","lsnr":7,"time":"2017-10-28T22:54:58.558062Z","codr":"4/5","data":"gAEBAQGACgAPSO+NYWcB0v7UWQ==","freq":865.062,"chan":0,"size":19}]} length 235
txpk {"txpk":{"imme":false,"tmst":1591172565,"freq":865.062,"rfch":0,"powe":27,"modu":"LORA","datr":"SF12BW125","codr":"4/5","ipol":true,"size":12,"data":"YAEBAQEgFgBuDfmj"}}
txpk_ack {"txpk_ack":{"error":"NONE"}}
transmitPkt 16598 12388 -1 865620000 192 112 2 64 27 12

If I'm reading this correctly the LoRaWAN server request is 865.062 but actual transmission is 865.620.

Spectrum analyser indicates these frequencies are indeed being transmitted.

Probably a while since you've looked a this! So any suggestions would be appreciated.
Cheers, Ron

@Suretronic
Copy link
Author

Further.
It works ok with frequency 866200000, which indicates either a calculation problem or problem parsing the server request.
Fix would appreciated if poss. Cheers Ron

@JaapBraam
Copy link
Owner

@Suretronic
Copy link
Author

Hi JaapBraam
Apologies, missed seeing your response until now. If it isn't fixed in that line yet (no chance to check yet), it shouldn't be too difficult to sort out. Much appreciated ... and the gateway is great work by the way, particularly with such an innovative approach to handling multiple spreading factors. Best wishes, Ron.

@jrw77
Copy link

jrw77 commented Nov 8, 2017

My solution for line 191 (split into lines and indented for better readability):

  local fix=data:sub(5):gsub('"freq":(%d+)[.](%d+)',
    function(d,f) 
        local h=f; 
        while h*10 < 1000000 do 
            h=h*10 
        end; 
        while #f > 0 and f:sub(1,1) == '0' do  
            h=h/10; 
            f = f.sub(2) 
        end; 
        return '"freq":'..(d*1000000+h) 
    end)

@JaapBraam
Copy link
Owner

Looks good!

If it works as expected, please create a pull request to fix the bug.

@jrw77
Copy link

jrw77 commented Nov 9, 2017

Actually, I´d love to, but first I have to get my gateway to receive its first package. I am struggling with creating a node that would send a package. My current approach is to use the same code base (second set of nodemcu/D1 + sx1276, Ra-01) and basically call

function send(mydata)
    padlen = (4 - (#mydata) % 4) % 4;
    
    pkt = { codr="4/5",
            data=mydata,
            freq=CONFIG["GW_FREQ"],
            ipol=true,
            modu="LORA",
            powe=27,
            rfch=0,
            size= #mydata + padlen,
            tmst=tmr.now()+8000,
            datr=CONFIG["GW_SF"]..CONFIG["GW_BW"]
         };
    radio.txpk(pkt)
end

This does send something, which I can perceive as a chirp in a receiver tuned to that frequency, but my gateway (configured to the same frequency and spreading factor) does not receive it. Anything obvious that I overlooked? Does radio.txpk(pkt) send a packet format that the gateway ignores, as it seems to come from another gateway (would make sense to reduce ping-pong interference)?

@Rubensen
Copy link

Rubensen commented Nov 9, 2017

DIO pins configured correctly ? I expend hours last week with exactly this issue with a Wemos board...

@jrw77
Copy link

jrw77 commented Nov 9, 2017

When I shorten the pins to 3V3, the correct interrupt handler gets called (rx timeout on DIO0, rxpk on DIO1, which does not find data available). I don´t think I damaged the sx1276 outputs by that, but it helped to check the wiring to the nodemcu.
I am using 433175 kHz, as my module is for that freq band, do you think that is an issue?

@Kingwulin
Copy link

When I shorten the pins to 3V3, the correct interrupt handler gets called (rx timeout on DIO0, rxpk on DIO1, which does not find data available). I don´t think I damaged the sx1276 outputs by that, but it helped to check the wiring to the nodemcu.
I am using 433175 kHz, as my module is for that freq band, do you think that is an issue?

I guess you are a Chinese, I meet some question on the function of detecting multiple SF,would I have a talk with you over QQ or wechat (:

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

No branches or pull requests

5 participants