xueliu / lora-feed

Semtech packages and ChirpStack Network Server stack for OpenWRT
GNU General Public License v2.0
77 stars 56 forks source link

picogw-packet-forwarder: gps_path_tty setting ineffective? #17

Closed s-2 closed 4 years ago

s-2 commented 4 years ago

Hi Xue, Thanks for your work!

I am using a picoGW card from n-fuse (LRWCC1-MPCIE-868) with an MT7620-based OpenWRT router (DWR-921 C3, basically just swapped the LTE card for LoRa).

It is working fine with picogw-packet-forwarder and The Things Network, now I have also added a GPS receiver based on u-blox 7 chipset. The raw NMEA data is accessible through the console UART port via screen /dev/ttyS0 9600 and I also soldered the PPS output to Pin 5 of the miniPCIE socket, so the SX1301 could synchronize.

Now I am wondering what is required to allow pico_pkt_fwd to use GPS, I tried adding

        "gps": true,
        "gps_tty_path": "/dev/ttyS0",
        "fake_gps": false

to global_conf.json, but it seems the path setting is not even parsed during startup; according to the code there should be at least an INFOoutput regarding the path (even if there were no GPS attached), but the only INFO I see is for the fake_gps disabled setting.

Is GPS functionality just not yet included in the latest picogw-packet-forwarder, or could you check whether the path setting is effective on OpenWRT? (should not require GPS for testing)

Any help is appreciated! Thank you,

Sebastian

By the way, what is fake_gps meant for in the first place? I don't want it to override the gateway location manually set for the TTN map since that is more precise (at least for indoor testing).

xueliu commented 4 years ago

Hello Sebastian,

Thanks for using this repository. Actually I have no picoGW card but only a IMST 880A without GPS module. Until now I did not jet test options for GPS. But I would like to help you to fix the problem. I will have do some study and come back later.

s-2 commented 4 years ago

Hello Xue,

Thanks for your reply.

My current build is still based on v19.07.2 since I'd prefer the option to install packages later via opkg, however I was only able to make the legacy packet forwarder work with the picoGW card.

But I see there have been several commits to basicstation since the v19 branch was forked, so I will try to compile basicstation and the LuCI plugin again using the latest master (without selecting any packet_fwd packages that might interfere), so I guess it should be working fine then.

In the long term, this is probably the better approach than using the legacy packet forwarder anyways, besides I saw in the screenshots that the LuCI app has a tab for GPS config already included.

I'm just not yet sure how this will work with TTN regarding their lack of support for class B devices at the moment. For testing, I would probably run my own chirpstack server to support class B, however at the same time the gateway should also be able to continue forwarding all class A packets to TTN, if this is possible with the current state of basicstation.

s-2 commented 4 years ago

Just a quick update, built a new image based on the latest master, but I'm still not quite sure whether picogw_hal is correctly installed, or how to make basicstation use it. According to station.conf the RADIODEV parameter is a path to an spi device, which I probably can't just set to /dev/ttyACM0?

Also I see the same error with luci-app-basicstation, which is probably normal as it is not running:

/usr/lib/lua/luci/dispatcher.lua:1341: module 'luci.cbi' not found:
    no field package.preload['luci.cbi']
    no file './luci/cbi.lua'
    no file '/usr/share/lua/luci/cbi.lua'
    no file '/usr/share/lua/luci/cbi/init.lua'
    no file '/usr/lib/lua/luci/cbi.lua'
    no file '/usr/lib/lua/luci/cbi/init.lua'
    no file './luci/cbi.so'
    no file '/usr/lib/lua/luci/cbi.so'
    no file '/usr/lib/lua/loadall.so'
    no file './luci.so'
    no file '/usr/lib/lua/luci.so'
    no file '/usr/lib/lua/loadall.so'
stack traceback:
    [C]: in function 'require'
    /usr/lib/lua/luci/dispatcher.lua:1341: in function '_cbi'
    /usr/lib/lua/luci/dispatcher.lua:1018: in function 'dispatch'
    /usr/lib/lua/luci/dispatcher.lua:478: in function </usr/lib/lua/luci/dispatcher.lua:477>
s-2 commented 4 years ago

I'll just close this one in favor of #19, we probably won't need the old packet forwarder after that anymore :)

xueliu commented 4 years ago

Hello,

I am very sorry that I did not response your request and problem for a long time.

I do not have a picogw and I guess that pico packet forwarder does not support or use PPS signal from GPS. Please have a look https://github.com/xueliu/picoGW_packet_forwarder/blob/master/lora_pkt_fwd/src/lora_pkt_fwd.c#L1163.

s-2 commented 4 years ago

It really does not seem to implement any GPS functionality, however I was only using picoGW_packet_forwarder in the first place since basicstation did not support the picoGW cards at all - but it seems that semtec have changed this now, so I'm quite happy about that :)

Looking forward to running basicstation on OpenWRT eventually, I'll be ready to test the picoGW and GPS stuff.

(Now I'm just wondering what software n-fuse would have used to actually test their cards during manufacture, if neither of the two solutions provided by semtec would support them... n-fuse also don't provide any code downloads themselves)