Hi IoT friends!

A frequently asked question is the possibility to provide location services for NB-IoT to avoid the necessity of GPS. (Since GPS is reducing the battery life).

There are several ways to provide NB-IoT location services. And there are also several use cases which require location services.

I’d like to learn more about how our users want to apply location services.

E.g.

• To track your devices
• To see if your device is moving
• To get a notification if your device has moves

Would you like to share here what you want to use location services for? Please also tell us more about the accuracy and if you need the information real time, a couple of times per day, every 5 minutes etc.

Thanks!

Hij wordt inderdaad ondersteund! Moet er wel bij zeggen dat deze modules nog niet zijn gecertificeerd voor ons netwerk, maar dat staat wel in de planning.

Leuk dat je 'm hebt besteld!

Spain confirmed!

@jmarcelino

That’s great news. Support for UDP passtrough is scheduled on our roadmap (apologies, only in Dutch). We aim to support UDP passtrough before the summer. However, if you are ready around the end of this month, we can test it on our PoC environment.

Please keep us posted!

Nadat het device een berichtje stuurt gaat hij een aantal milliseconden in connected mode an daarna een aantal seconden in idle mode.

Connected mode = voor het ontvangen van paging messages
Idle mode = voor het ontvangen van downlink messaged

Nu, in release 13, kun je idle mode op 0 seconden instellen. Straks, in release 14, ook de connected mode.

Not all cells are updated yet. Apologies.

Just talked to my colleagues from our radio network team. It will take 3 hours from now before all cells will be updated

@felixdonkers

Zo ver ik weet zijn er geen internationale afspraken over performance. Er zijn daarentegen wel theorieën over hoe de performance en prestaties van NB-IoT zouden kunnen zijn. Met nadruk op ‘kunnen’ en dus geen ‘moeten’.

Ik ben niet in de positie om te vertellen wat er voor andere providers of andere Deutsche Telekom landen geldt. Logisch zou zijn dat alle telecom operators NB-IoT aanbieden zoals het bedoeld is en waarvoor het concept ooit ontworpen is.

Er zijn volgens mij nog niet zoveel telecombedrijven die NB-IoT commercieel aanbieden. En van die paar telco’s die het al wel commercieel aanbieden, zien wij dat ze het als een ‘bit pipe’ aanbieden. Dat snappen wij niet zo goed. Dat was namelijk niet de bedoeling toen men aan de tekentafel stond voor NB-IoT.

Wij zien het in ieder geval als een dienst waarbij we de volgende zaken moeten aanbieden om van toegevoegde waarde te kunnen zijn:

• schaalbaarheid
• veiligheid
• duurzaamheid
• een lange houdbaarheid
• efficientie

Dit bieden we aan in combinatie met de mogelijkheid om 120 berichten per dag over en weer te kunnen versturen. Dit aantal is gebaseerd op de verschillende theorieën waar ik eerder in dit bericht over sprak en tevens bevestigd door de testen die we de afgelopen weken hebben gedaan. Deze vijf berichten per uur moeten ook altijd aankomen bij normale omstandigheden qua coverage.

Als ik iets nader moet toelichten hoor ik het graag!

Werkt weer na het herstarten van een proces op onze connection and device manager.

Root cause volgt!

@Philip-van-Gastel, heb je nog nieuws?

Hey @magnatron

We understand your worries. Really. And that is exactly why the team picked this timeslot for the maintenance.

We’ve been planning this since October 2020. The reason why we are already working on this upgrade and migration for more than 7 (!!) months, is because we want to mitigate all risks during and after this maintenance.

Hence, we are very optmistic about our statement that the interruption will not last longer than just a few minutes.

However, in case something goes wrong… we’d like to solve the problem as quickly as possible. And to solve it as quickly as possible, we need to involve people from different parts of the world.

If we move the maintenance to another timeslot and something goes wrong, there us a high possibility that solving the problem will take more time than we want.

For this reason, we see the announced time-slot as the time-slot with the least risk.

But I promise you that we are doing everything to avoid problems.

@MeneerJacco thanks for making us aware. This is because of the rollback. You probably registered the device on the new version of our service capability server.

Can you pls send me the IMEI numbers via PM or via hello@iotcreators.com?

We’ll fix it right away!

Hi @magnatron I am very sorry to disappoint you. But there is chance that, the next time, it will happen again during office hours.

For many of our customers there is no difference between daytime device data and nighttime device data. They’re both equally important.

The problems of today lasted for a little bit longer than 4 hours. The risk of doing this during the night could mean that it can take 8 or 10 hours.

I don’t like the idea of losing data at all. But if I have to choose, then 4 hours is better than 8 hours.

@Ronan-Lacroix @Kolja-Vornholt do you know this?

Good to hear @BrodVictor… but it looks like I missed your post from yesterday?

Hey @magnatron

We understand your worries. Really. And that is exactly why the team picked this timeslot for the maintenance.

We’ve been planning this since October 2020. The reason why we are already working on this upgrade and migration for more than 7 (!!) months, is because we want to mitigate all risks during and after this maintenance.

Hence, we are very optmistic about our statement that the interruption will not last longer than just a few minutes.

However, in case something goes wrong… we’d like to solve the problem as quickly as possible. And to solve it as quickly as possible, we need to involve people from different parts of the world.

If we move the maintenance to another timeslot and something goes wrong, there us a high possibility that solving the problem will take more time than we want.

For this reason, we see the announced time-slot as the time-slot with the least risk.

But I promise you that we are doing everything to avoid problems.

Hi @Claude-RICHARD

Welcome, happy to have you here :-).

Unfortunately you can only use our UDP server with simcards from Deutsche Telekom.

We can send you one, but there is another problem: we do not have NB-IoT roaming in France (yet)…

@JakubT , in addition to @Ronan-Lacroix last post, he also checked the simcard numbers that you sent to me by email and he did not see any attempts to attach to the network so far…

@magnatron yes it is correct

But it still possible that in some places there is no network available at all.
Some operators only activated part of their networks.

We can find this out by looking up the connection info in our network.
Can you please send me the ICCID (number on the sim-card) or IMSI via DM or support@iotcreators.com?

Thanks!

Looks like I overpromised here… I am very sorry.

Last year we’ve been discussing the upgrade of our Service Capability Server many times internally. And initially the installation of the generic CoAP adapter was part of the overall upgrade plan in each of these discussions.

However, for some reason it was deprioritized when we started the upgrade.

The upgrade will be finished in April and bring along new protocols as MQTT and LWM2M but unfortunately not generic CoAP.

Tagging my colleagues @Roalnd-Baldin and @Saher-Salem to see if we can come up with a new timeline.