I'm building a gateway for an IoT project. I need to receive sensor data (from an end device) with LoRa (RFM95) and send it to a Cayenne server with GPRS (SIM800C).
The PCB is almost ready but I'm stuck at the coding part. How to configure it to work with two different protocols?
Related
I am doing my FYP and for this I need some information:
Is it possible to connect a mobile with a LoRa Network via cellular SIM?
Actually, I want to build a mobile software that will operate with a local LoRa network, and the user can connect to the network using this app via cellular network.
No, LTE/GSM/EDGE/Mobile network is a different transmission method than LoRa and thus can not connect to LoRaWAN networks.
No I don't think you can . But I think you need another module to include in your project to handle the SIM part and that way you can switch between the Lora and SIM
I was under the impression that in NB IoT world, if the client device enters PSM mode, it can actually retain both the IOT network registration and also the TCP IP connection session. so when it wake up from PSM, it can quickly send data and go back to sleep again. but in my case, it imitates disconnection of the PDP session before it enter PSM. Is this normal ??
Currently I am using a dev client system based on Qualcomm 9205 modem connect to LTE Cat-M1 network.
the client will wake up every 10min to send a small chunk of data (100byte) to the AWS IOT service, it uses MQTT as the messaging protocol .
ideally I prefer the device to initiate the MQTT connection with the server once, then after it goes to PSM sleep, the client side remembers the MQTT connection, so when it wake up, it can just send the data via MQTT without re-establish the MQTT connection again.
Unfortunately, I realise the real behaviour is: when I ask the modem to go to PSM sleep, it will drop the PDP connection (which means the TCP/IP session is lost, so does MQTT ), so when it wake up, it will take extra 5-10 seconds also to re-establish MQTT connection again before sending data. this is a waste of both time and additional data communication.
Any suggestions?
MQTT protocol works on pub-sub concept. Client can subscribe and publish topic to the Broker. Clients who are sensor kind of thing can publish respective topics (temperature, humidity, switch on/off request etc) to Broker. Broker will send the respective data to the subscribed clients (display device, any device which can on and off).
Broker usually hosted on open internet.
I'm not getting the point how Broker will send the information to client device as the wifi connected device usually couldn't be reachable from open Internet as there will be no public IP assigned to such IoT devices. (I mean to say IP communication from Open internet to IoT device should not be successful)
The connection to the broker is established from the client to the broker, as this is an outbound connection as far as any home router/NAT device is concerned it will work just fine (in the same way a web browser would open a connection to a HTTP server).
The connection is also persistent, meaning the client opens it and keeps it open for the lifetime of the client. This means that the broker always has an open connection to forward messages to the client.
At no point does the broker try to connect to the client.
I am using MQTT protocol in real time data communication application,therefore I need to retrieve the client device location data and pass it to MQTT broker. Is there any available API to track client device Geo location in MQTT environment
It really isnt' clear what you are asking in the question but I'll try to cover all the options.
The device knows it's own location and you want to publish this information on a topic. Assuming the device has a GPS receiver (or some other way to determine it's own location e.g. data from a cellular network) then it's simply a case of building a message with a payload including the location data in what ever format you want
You are trying to determine the location of the client purely from it's connection to the broker. The broker will know the client's IP address so in theory it could use a IP Geolocation API to give an estimate of the devices location. There are no standard brokers with this capability so you would have to build your own. Also in most cellular environments the devices sit behind NAT gateways so you would only be able to locate the gateway not the end device.
If I have an iOS client and an embedded device that I want to communicate between the two with a WiFi connection using UDP, do I need to write a server (python or something) to facilitate the connection? I am trying to look online but there are a lot of ambigious articles.
Thanks
You'll have to write a server application for the device (iOS or embedded) that will be listening for data.
However, for a simple, single-client UDP connection, your server is basically just a UDP socket, which you bind to the port you want to use - and then start listening for data on. You don't need any connection-handling as UDP is connectionless.
On your client, you just send data to the IP and port of your server, and that's it.
I've done this myself, connecting my iPod Touch to a small ITX computer (running WinXP), to control a small mobile robot over WiFi.