We're a group of interns at Nordic currently starting with a new project to work with during this fall. The goal is to "extend" range and functionality of the UART over BLE service using the nRF9160 in combination with the nRF52840. As the service is frequently used in many BLE modules and wireless enabled devices (like LED light bulbs) it could make it more convenient to interact with these devices from anywhere. The plan is to use the Thingy:91 as development platform.
Before we start developing we wanted to reach out to the forum to see if there are any thoughts on how this could be done. To be clear: we’re not planning to implement a UART/serial standard for LTE/IP, but rather use the the 91s as gateways for data pass through. A crude illustration of our current idea is shown in the figure. It shows how for example a phone (using the nRF UART app) can communicate with one or more devices over BLE UART, but with an LTE bridge in between. In this case Raspberry Pis (they can for example be part of a home automation system).
Our initial thought is to pass the data via a database (over for example MQTT), where TX and RX data for each device involved will be stored and read by the opposing end of the communication. By storing the data in a database it will be accessible via a web interface as well, which can be ideal for potential web apps. Does this sound feasible or is it better to have a more direct link between the devices? (e.g no database)
As it’s possible for one central to have several Nordic UART Service(NUS) peripherals we need some way to address these peripherals as well. Here we plan to use the IP already assigned to the respective Thingy:91, with an ID appended for each peripheral device. All of this is of course open for discussion and we welcome you to critique and comment! Is this even something developers wish for? From my understanding the UART over BLE standard is used quite extensively.
All the best.
I think one of the biggest benefits of the UART-over-BLE concept (or UART-over-ANYTHING, really) is the simplicity of knowing it is a point-to-point connection with easy to understand behavior. Part of that behavior is the real-time nature of it, meaning no historical backlog.
It is possible that your database concept could still achieve this, but I'm nervous that you're opening yourself to unexpected complications if either end receives historical data multiple times by accident or data substantially delayed from when it was sent.
OTOH, if you're hoping to make use of features like EDRX on your nRF9160 bridge to allow longer battery operation, you have to have some amount of buffering in the cloud, in which case you need something like the database.
It's a tricky decision. If I were designing this for something that I knew would be externally powered, I would go for a direct connection between the LTE nodes, maybe just even using a separate TLS socket for each UART channel. But if I were trying to go for battery powered operation, I would setup some sort of cloud-based buffer server, and be sure to design-in solutions for the complications above.