Some neophyte questions

Hi,

Though I’m very familiar with a few other Low Energy wireless sensor standards (BLE/ANT), I’m a definite LoRa neophyte. In short, I have an application that runs on Raspbian and I would like to add the ability to also receive data from multiple LoRa sensors. I would like to process the data locally on the Pi, so if I understand correctly (from other posts I’ve read) I’ll need to install the ChirpStack Gateway and Server software and then redirect the UDP output packets to my own local UDP receiver process. Then, get the packet format information from the sensor manufacturer to correctly parse the data. So given all that I have a few questions regarding feasibility and choosing appropriate hardware -

(1) Is my assumption correct regarding ChirpStack and getting the raw packets (i.e. direct the UDP packets to a localhost receiver app)? Any foreseeable issues?

(2) Using the technique above seems like a way to receive packets but what about sending packets to the sensors? I’m assuming like BLE sensors there will be times when you want to send data to the sensor (config/control/etc), how can that be done given the scenario above (or can it)?

(3) Are there any other considerations? Are most (or many) manufacturers willing to provide developers with their packet formats?

(4) Regarding hardware, since I’d like to have a Pi 4 while doing dev work, it looks like I should either go with the WisGate D4 or D4H. I’m not super clear on what the differences are though other than connection options? Would one be preferable to the other given what I’ve described (and also in light of my next question regarding GPIO access)?

(5) The WisGate enclosures don’t appear to provide any access to the Pi’s GPIOs. With either of the rak2245 or rak2287 the HATs attached, are the GPIOs accessible at all? I has because my main app generally gives the user the ability to select free GPIO’s to be used in their own applications.

(6) Anything else to be aware of, pitfalls, feasibility issues, etc.?

Thanks in advance for any feedback!

No. You’re over thinking the data flow. You have a gateway which also acts as a network & application server (Chirpstack) - in the application server settings you tell it how you want it to pass on the uplinks from the devices - you could send to a web server running on the Pi, or have the Pi run an MQTT client that connects to Chirpstack. UDP output from an application server isn’t common.

You tell the application server to send downlinks via the mechanism you use to get uplinks, but in reverse, it takes care of the rest.

Learn LoRaWAN 101 by trying stuff out. Be prepared to have your solution evolve.

They wouldn’t sell many devices if we couldn’t get the data the sensor sent. Look at the documentation.

If you don’t want to be allowed to mine for Helium tokens but have the hardware to do so, then the D4H would be appropriate. The enclosures are nice solid bits of metal and generally we leave our gateways to just be gateways, hence the solid metal.

You would be better off with a concentrator card and leave it all in the open:

Learn LoRaWAN 101 by setting up a couple of devices & a gateway to learn the basics. Then you’ll know what you don’t know and you’ll have a better idea to design a solution.

1 Like

Thanks for all the good info! I just ordered a D4H and a sensor to test with. It looks like the case is easily removable (or accessible at least) so hopefully I can test the basic GPIO functionality that way. It’s still not clear from the doc’s whether the “no connection” GPIOs are passed through but I’m assuming they are. I’ll find out eventually anyway. Again thanks for the reply. I just wanted to be sure I wasn’t missing anything obvious before I ordered all the hardware…

Like all HATS, they connect to all the pins. You can solder wires on to the bottom of the Pi or the top of the header card.

The D4 costs less, does the same thing …

That’s weird… maybe it’s only on the US website but the D4 actually costs a little more than the D4H for some reason (and uses the older Semtech chip?). Good to hear about the GPIOs. I’ve never used a HAT for anything (and hot a hardware guy) but at least from what I’d read some (particular older) HATs did pass through the pins and some didn’t. Or I could just be misunderstanding what I’m reading (entirely possible!).

Again though, thanks for the help… Looking forward to getting the devices and seeing if I can get them to do what I want.