Hi
We require to send a packet and it must be received straight away at the other end . I know a packet isn’t guaranteed to be sent straight away, so what I want to do is have my own 8 channel gateway that connects to my processor through SPI to read the packet. There will be a permanent connection to our server using a 4G modem. This way as soon as a packet arrives at the gateway our software can send data to the server.
Can anyone recommend a 8 channel gateway with an SPI interface, or uart ?
Effectively bypassing any TTN involvement therefore outside scope for this forum!
You do understand what a Gateway is and how it works, right? What you have described is … a Gateway! It is just a transparent ‘media-converter’. It ingests RF, demodulates, decodes, adds a bit of metadata wrt received packet, encapsulates in IP and forwards to back end server…job done! Obviously
is a subjective statement… will depend on where measured from/to… once message is assembled at the GW its down to backhaul latency/transit times, and speed of any load balancer.front end processing/LNS processes at the backend before passing on to your application server…
If what you want is the SPI interface this will be to the LoRaWAN Baseband processor on the concentrator (card) vs the final GW interface…
Question - if so critical that it must get there ‘as soon as’ - what breaks? There is no such thing as guaranteed 1st time delivery where radio is concerned! What if node transmits but isnt heard by a GW for it to even start the process of handling and then sending on ‘straight away’. Sounds like you need to review what LoRaWAN is about, what its limitations are, potential system, architecture and environmental constraints and how that might impact your use case - if even suited to the technology…
There are 8 channel Lora receiver cards with SPI interface. Not gateways. No gateways with uart interface to a gateway either. LoRaWAN gateways use IP connections, not SPI or uart.
Hi Jeff
Thanks for the reply. I think I will have to rethink this one and as your question, I dont think LoRaWan is probably the best way to go. As it has to be low power, I think I will look at NB-IoT , not so good as low power but still good
I have to re-look at this , and was thinking of NB-IoT , but maybe Lora is the best way with an 8 channel Lora receiver . There maybe up to 5000 units , but only transmit twice a day indicating all is well. If there is an issue then a packet will be sent straight away .
None of the gateways I know (including the MultiTech ones) interface with an external controller using SPI. the Lora concentrator cards do, but that isn’t a LoRaWAN gateway without something that runs a packet forwarder of some sort.
With LoRaWAN (and any other radio technology) you will not have a guarantee that the packet will be received correctly or at all. Interference of other devices may cause the transmission to be lost.
However if the transmission is received it will normally be processed and delivered to your application within a second.
If your application can not work with a one second delay or up to 15% lost packets you should not use LoRaWAN. You should not use LoRaWAN for critical services where lives depend on it in any case. However you will have a hard time finding any telco that accept that kind of use cases on their nb-iot or lte-m networks as well.
It may just be your wording, which is certainly tangling other forumites up as observed, the gateways connect on IP, the internal hardware connects the radio hardware to a controller via SPI and the programming of that interface is seriously non-trivial. And most likely already does what you need, you just need to ask the right questions and give it a try.
But saying ‘8 channel Lora receiver’ indicates some confusion - all LoRaWAN gateways are 8 channel minimum. You can make as many channels as you like out of LoRa modules, but that’s not LoRaWAN.
Sounds fine for LoRaWAN subject to you setting sensible parameters on “straight away” - I can usually get an alert from a device within about 5 seconds - it sends, the gateway passes the data on, out of the LoRaWAN servers to my backend and distributed via email, SMS, push and PurpleAlert™️ as appropriate. My backend, if the alarm is severe enough, sends back an acknowledgement so the device knows that people know. The device runs to a much shorter uplink interval so that trends can be observed. If it’s a ‘ummm’ notification, the device doesn’t need an ack. If it’s a ‘ouch’ notification then it keeps trying on a much shorter interval until it does get an ack or it runs out of battery or is hit with a hammer.
When testing devices on the desk, it is typical for me to trigger a send (pushbutton or trip a sensor) and have it appear on the web console before my ageing eyeballs have managed to adjust focus from close to looking up at the screen. Which frankly is just amazeballs.
Reality is that ~95% of the time, the alert uplink arrives and is ack’d on the very same tx/rx. But the ones that are attached to nuclear power stations occasionally go offline when there is an accident with the rods and they are heavily irradiated - so you have to perform an appropriate risk analysis on what to do under the various failure/glitch scenarios.
But as you are being coy about the details, I’m not sure how much more anyone will be able to advise you. Probably best to use the Learn link at the top of the page and buy some kit and try it out.