I was planning a simple sensor node with temperature/humidity readings also using the ESP+RFM combo. I don’t see anything possibly wrong with this, please correct me if I’m wrong.
If all goes well, I wanted to build a proper outdoor gateway with a Raspberry Pi + RAK2287. Is that a good combo? I want to keep it reasonably priced but also want to have proper gateway with respect to specifications of LoRaWan and make it possible for people in my neighborhood to use the gateway easily.
A single channel gateway is not the best way to start your journey into the world of LoraWAN. This forum is about LoraWAN, not Lora, and single channel gateways became effectively obsolete last year when TTN switched from v2 to v3. Therefore, this is a dead end, at least in this forum…
My advice to you is to start slow to learn the principles of LoraWAN. Get the cheapest commercially available gateway, in my opinion The Things Indoor Gateway TTIG with the cheapest possible sensor (for example LGT-92 or LHT65) and learn the principles of the LoraWAN network protocol.
In the next stage, you can build Pi based nodes and gateways that will allow you to work around the limitations of the first devices.
What is the point of trying so hard to save money when you already have an idea that it’s not ‘a good thing’. And, by your own admission, no experience to inform why this shortcut would slow you down with hours of debugging that can’t be easily solved. Ironically, once you really do know LoRaWAN, you’d then know enough to get a SCPF working with your devices.
And, in all your reading, did you not see the comments on the forum regarding SCPF’s? And if you did, how did you think your gameplay was going to be received by the community?
But fundamentally, why come up with a gameplan when you haven’t done anything practical yet and post it here - why not do the most obvious thing and just ask for advice on the best gameplay? And what the best learning resources might be.
So moving on from reviewing your gameplan, this may help:
Well, I guess I could have just asked what would a good gameplan was but I was thinking that doing some research on my own before hand was a good idea. Why do I try so hard to save a dime, well this is a hobby for me and I have a family to feed so yeah, I try to confirm before spending.
Thanks for the tips and sorry if my post was shocking…
It is and is absolutely to be praised! We wish others would be so thoughtfull before pilling in. What gets the reaction is that IF you have done all this reasearch and IF you have understood what you have watched and read…why oh why totally ignore one of the key tennants of deployment that has been long councilled against - Do Not Use or connect a SCPF/DCPF to TTN - it is LoRa only not LoRaWAN (as you yourself pointed out), they are hard to work with - especially if not knowing precicely what you are doing and missing (the irony being as Nick calls out therefore not good for Newbies!)…and more important they are disruptive to other users as your research will have shown you and as would a simple read of the subject on the many threads on the forum dealing with this…
Contrary to
Not only does it not start the journey it doesnt get you to the starting blocks, and actually sets you off on a different running track…
and
No That V3 transition just made the impact worse…the fact is they have been deprecated and not supported since long before I even engaged with TTN many years ago…they were nailed once it was determined and better understood what their impact was to other users in the very early days - before me but likely during the V1/V2 transition period. The only excuse ever was it was seen as a then low cost route into exploring LoRa based IoT- at a time when LoRaWAN GW’s cost >>$1000, by then they were <<$200, and quickly we saw <$150 then <$100. Unfortunately, a lot of early SCPF deployments remained ‘on net’ disrupting for years after. Like you, many get into this on hobby basis, spend their hard earned pennies and cents on ‘correct’ kit but then find someone ignores what they have learnt (if bothering to check at all) and starts disrupting them, hence we can seem hard on this!
Use a community GW or get a low cost indoor GW (e.g. TTIG, LPS8. or …well do some some more research plentyas below $150 out there!) and enjoy your LoRaWAN journey - you will indeed be very welcome to the TTN community
This doesn’t make you unique - the vast majority of us on here family & as this is TTN, the community network, many are doing projects for their communities at some expense to themselves.
But mostly, consider this:
“It’s unwise to pay too much, but it’s worse to pay too little. When you pay too much, you lose a little money - that’s all. When you pay too little, you sometimes lose everything, because the thing you bought was incapable of doing the thing it was bought to do. The common law of business balance prohibits paying a little and getting a lot - it can’t be done. If you deal with the lowest bidder, it is well to add something for the risk you run, and if you do that you will have enough to pay for something better.” ― John Ruskin
There are some territories where LBT is mandated as part of local regs, hence facility on many units… check local requirements, otherwise both good choices…
Go SPI, don’t use USB as it does not scale and support for USB (full) gateways has been discontinued years ago. Only pico gateways support USB but those are not meant for ‘regular’ deployments.
I’d agree with the SPI recommendation, but not completely with the arguments made for it.
The RAK5146 appears to be in the modern “pico” gateway style (with an MCU not the problematic bridge chip), and I’d dispute that they aren’t meant for regular deployments.
However, with a host that can support it, SPI is strongly preferable at the moment if for no other reason that there’s a lot more software flexibility, since all the software is contained in one usermode program and the whole issue of USB enumeration and drivers is skipped. With a lot of cheap hardware manufacturers, the electronics are fine but their software can be a bit more questionable, so being able to use standard software versions does a lot to protect the ongoing value of the hardware investment. (The RAK2287 does require a small software patch to cover for its lack of a temperature compensation sensor)
The mPCIe form factor has no standard for SPI, so SPI devices in that form factor are going to require a purpose-built hosting board. Essentially no off-the-shelf embedded/router box with an mPCIe slot (beyond those designed as LoRaWAN gateways) will support an SPI LoRa card - however, it’s not a given that the USB version will work in those slots either.
At the first TTN conference Semtech told me the pico design is meant for small deployments as the USB interface does not scale for high loads. You are of course welcome to a different opinion…
I am a newbie(def noob) and is currently looking at using the Lora platform for part of my business. Is there someone that can help me with advice and development of such a product with a possible gui to track small items in an specific location of approx 1sqkm. Obviously ill pay them, but need good advice and guidance.
Mod edit: DeGoogled contact details - use Private Messages for initial contact
We wish others would be so thoughtfull before pilling in. What gets the reaction is that IF you have done all this reasearch and IF you have understood what you have watched and read…why oh why totally ignore one of the key tennants of deployment that has been long councilled against - Do Not Use or connect a SCPF/DCPF to TTN - it is LoRa only not LoRaWAN (as you yourself pointed out), they are hard to work with - especially if not knowing precicely what you are doing and missing (the irony being as Nick calls out therefore not good for Newbies!)…and more important they are disruptive to other users as your research will have shown you and as would a simple read of the subject on the many threads on the forum dealing with this…