Simple transfer like in the good old days

In the old days we were using a DECT system for the company (there was no VoIP at this time). I don’t recall ever putting a call on hold ever in my life before, but I do recall that I did a transfer. However not by using buttons on the handset, just physically: It was more a handover than a transfer. I just walked over to the person that should get the call and gave him my handset.

While that sounds antic, it was very productive (probably because this was a small office). While walking I could still talk, thanks to the cordless nature of DECT. Then before the transfer, I could visually verify that the transfer target was ready to take the call. Then the handover was also very simple, just physically pass the device into the hand of the target. The only problem was that after he finished the call, I wanted the handset back. This probably explains why DECT handsets get displaced to easily (the m9 has a function to locate all handsets to address this problem).

Key systems also used to be very productive. Unfortunately those systems were not in the favor of the IETF standardization committee and it is impossible to implement that with the existing standards. Seems like in the old days life was sometimes easier.

Anyway. Maybe nobody needs these features anymore because you cannot walk into the other person’s office any more if you are working from home. That’s something you could not do in the good old times!

Why software updates take forever

When you update the base station, it takes just a minute to download the software and install it. However, when it comes to the handset software update, it takes much longer. This is surprising at first glance, especially because the handset has just something like 768 KB Flash memory.

The reason for that lies in the DECT protocol. DECT has many advantages when it comes to the robustness of the voice transmission over the air and the lifetime for the battery. Voice is being transmitted at a rate of 32 kBit/s in the core DECT specification, which is enough for a good audio quality. However, when performing a software update, the constant bitrate of the voice channel becomes the problem: 768 KB times 8 bit divided by 32 kBit is 196 seconds, which is 3:17 minutes. Add the overhead for securing the channel with checksums, acknowledgements and so on and you get ten minutes for updating the firmware over the air.

We can actually be happy that the handset has just 768 KB memory. Imagine you wanted to update a 1 GB Flash over the air! It would take 4 days to update the software, if nothing goes wrong during that time. This also answers my question if it makes sense to have an Android based DECT handset: You need to have WiFi on the handset along with DECT. Wifi for the software updates and other miscellaneous data transfers and DECT for the voice calls.

Now it also becomes obvious why we included a USB connector in the handset. In the factory or even in the warehouse later, making a software update over the air for a large amount of handsets is not an option. Then it is much easier to connect the handset through USB and do the software update in a few seconds.

This also explains why you need to manually update the handset. If we would automatically update the handset after a base firmware update, users would face an unpredictable outage for up to nine times ten minutes (1:30h). And if the handset is low on battery, it could get stuck in limbo during the writing of the software. This could drive people mad, including our support department. Therefore, we thought it is better to leave the software update initiation to the user and he can make the decision it is to update the software on the handset.