The choice of a communication protocol to communicate with a data generating application is sometimes very simple. The application often determines the protocol with which to communicate internally. A good example is a car. The communication system in cars is called CAN. If data has to be read out to be sent to a back office, you will have to connect to the CAN protocol. There are still several internal protocols such as LIN or UART.
If the data has to be sent from the application to a back office (External communication), there are also many possibilities. In many cases, the choice of a communication protocol depends on the interests of the different users. If you, as a supplier, are highly dependent on the data because your business case is structured accordingly, you should not adopt a protocol that makes you dependent on your customer. In such cases, it is better to opt for 4G, 5G, LTE-CatM, but LoRa or NBIoT is also possible, so that the data transport does not go through your customer.
If your customer also has an interest in the data, you can also opt for a Bluetooth Low Energy (BLE) or WiFi solution. There are also no monthly subscription costs associated with this. With WiFi you can then use the customer’s router and with BLE a mobile phone of the customer.
Betronic’s engineers work on a wide range of products and therefore have extensive knowledge of all communication protocols.
We already use this knowledge in the quotation process to choose the most suitable protocol for your solution.
But which factors are important for choosing the right protocol? Which party has an interest in the data and its results? If a local readout is required for a service technician, this can be realized by a USB connection but also by a wireless WiFi Direct or Bluetooth Low Energy connection. The right choice depends on wishes regarding the cost price and what equipment the service engineer has at his disposal.
In the case of an IoT product, there are completely different considerations that come into play. Here topics come up about how often and which data should be sent, whether or not software updates and the business case of your product is built up with a subscription to cover any costs for communication.
Our experience is that different considerations are made for each product. If you would like to discuss the possibilities for your product without obligation, please contact us.
Practical example
This time we would like to show you an example from the medical sector. This is a product that ensures that the patient takes his / her medicines on time. If this does not happen, an auxiliary body will be called in.
Operation
The users receive a roll of bags containing medicines from the pharmacy (baxter roll). The bags are placed one after the other in order of intake.
The baxter roll is placed in a scanning device which is connected to a back office. The barcode on the next bag is scanned so that the device knows when the patient needs to remove the next bag from the device.
Signaling
To ensure that the user takes his medication on time, the display shows the time for the next intake. If the user does not take his medication, a local notification is sent by means of an audible signal. If there is no response, the patient will automatically be contacted by telephone. If this does not lead to contact, the general practitioner or district nurse will be called automatically. He will then visit the patient to determine what is wrong.
Protocol choice
The main requirement of the product is that it works immediately after the plug has been plugged into the socket. Reading out by means of a mobile application with Bluetooth or linking to a WiFi network is no longer necessary because the product must work independently of the patient’s environment. After weighing up all the requirements and possibilities, in consultation with the customer, NB-IoT with a fall-back to GPRS was chosen.