This is really interesting.
One of the problem that you have, if you want to deploy IoT solution in the field, is connectivity. WIFI is OK only for Home.
Imagine if you want to monitor condition of your fields in Agricolture, or things like that.
SigFox, a French company, has launched and is developing a global Net for IoT, based on Ultra Narrow Band technology. And today, SigFox network covers more than 22 countries, including Italy.
Arduino has developed and started selling a new board, member of MKR family, that allows connectivity to SigFox network, including a two years' subscription.
Here you find the announcement:
The board is called MKRFox1200 and costs only 35 euro.
And here, in Arduino blog:
IoT is progressing really fast: a world of new opportunities.
Showing posts with label Arduino. Show all posts
Showing posts with label Arduino. Show all posts
Friday, April 28, 2017
Saturday, November 5, 2016
Intricacies and fallacies of Embedded Development
I have spent some hours yesterday evening evolving my Home Automation Solution.
Porting some code developed for the Arduino MKR1000 on an Arduino One (a clone) board, I hit a strange problem: the sprintf function was not working as expected.
Strange, at the beginning I thought. Unbelievable.
I made resort to the skills in C development built 25 years ago. A step-by-step debugging of few lines of code.
Then, after some googling, I discovered what the problem is:
MKR1000 is a board with a chip from ATMEL that is 32bit. Arduino Uno is NOT.
On many "so-constrained boards" the C standard library has limitations introduced to reduce the memory footprint. Especially regarding floating point numbers.
sprintf has one of these limitations.
Resorting to another function provided by ATMEL I resolved.
But the important point is: if it is embedded it has constraints. Limitation.
It is not a smaller version of an Intel chip (the one that you have on your MacBook).
And we must be aware of this.
Porting some code developed for the Arduino MKR1000 on an Arduino One (a clone) board, I hit a strange problem: the sprintf function was not working as expected.
Strange, at the beginning I thought. Unbelievable.
I made resort to the skills in C development built 25 years ago. A step-by-step debugging of few lines of code.
Then, after some googling, I discovered what the problem is:
MKR1000 is a board with a chip from ATMEL that is 32bit. Arduino Uno is NOT.
On many "so-constrained boards" the C standard library has limitations introduced to reduce the memory footprint. Especially regarding floating point numbers.
sprintf has one of these limitations.
Resorting to another function provided by ATMEL I resolved.
But the important point is: if it is embedded it has constraints. Limitation.
It is not a smaller version of an Intel chip (the one that you have on your MacBook).
And we must be aware of this.
Friday, November 4, 2016
Constrained devices, MQTT, TLS
Yesterday evening I was doing some tests with an Arduino MKR1000 board.
It is a new board released some months ago. It is part of the Arduino family, but has some features specifically targeted to the IoT world.
It has WIFI on-board, has an encryption chip, and you can use MQTT.
Arduino has made available a Cloud Service (cloud.arduino.cc) where you can freely register your devices and test communication.
For example you can register several properties for each device (temperature, ...) and with an-easy-to-use API send updates.
The communication is based on MQTT over TLS.
Just a minute, I thought: but with TLS you need to encrypt the channel.
The usual handshake will happen: the broker has to send its certificate to the device and the certificate must be verified.
How is the board doing this?
The documentation is not complete, but walking around Internet and forums you find the answer
(thanks Google !).
The board contains a set of CA certificates, and for sure it is set up to recognize the site
The problem arises when you try to use MQTT + TLS to connect to your gateway (RPI 3, in my case).
Here you not only need to set-up keys and certificates on the gateway, but also you need to upload the root CA on the MKR1000 board.
How can you do that?
Well, not easy. MKR1000 doesn't have a traditional file system and you cannot FTP files.
There is an utility. But it take some time to understand how to use it.
I'll try (probably) in the week-end.
Conclusion: a constrained device is less simple to set-up than a Linux based device.
Basically, this is one reason why they use Gateways. Your "things" communicate with a gateway locally and the gateway, on behalf, send messages to the IoT Cloud Service.
Stay tuned.
It is a new board released some months ago. It is part of the Arduino family, but has some features specifically targeted to the IoT world.
It has WIFI on-board, has an encryption chip, and you can use MQTT.
Arduino has made available a Cloud Service (cloud.arduino.cc) where you can freely register your devices and test communication.
For example you can register several properties for each device (temperature, ...) and with an-easy-to-use API send updates.
The communication is based on MQTT over TLS.
Just a minute, I thought: but with TLS you need to encrypt the channel.
The usual handshake will happen: the broker has to send its certificate to the device and the certificate must be verified.
How is the board doing this?
The documentation is not complete, but walking around Internet and forums you find the answer
(thanks Google !).
The board contains a set of CA certificates, and for sure it is set up to recognize the site
mqtt.arduino.cc
The problem arises when you try to use MQTT + TLS to connect to your gateway (RPI 3, in my case).
Here you not only need to set-up keys and certificates on the gateway, but also you need to upload the root CA on the MKR1000 board.
How can you do that?
Well, not easy. MKR1000 doesn't have a traditional file system and you cannot FTP files.
There is an utility. But it take some time to understand how to use it.
I'll try (probably) in the week-end.
Conclusion: a constrained device is less simple to set-up than a Linux based device.
Basically, this is one reason why they use Gateways. Your "things" communicate with a gateway locally and the gateway, on behalf, send messages to the IoT Cloud Service.
Stay tuned.
Saturday, October 15, 2016
Arduino MKR1000 and IoT
Arduino is the most used prototyping board (well, actually it is a family of boards) in the world, and I have to tell you that I’m proud that it has been designed in Italy.
Recently, Arduino has entered at great speed in the IoT world. One board that is really interesting is Arduino MKR1000 (MKR stands for Makers!). A very small board, with built-in WIFI, enough cheap.
I have bought one at Maker Faire 2016 (in Rome, obviously) and this evening, after some soldering, I have decided to give it a quick try.
Obviously, my first choice was to test if it is easy to send an MQTT message from MKR1000.
Well, I have to tell you that it has been really easy.
1. Use WIFI101 library
2. Use PubSubClient Library (by Knolleary) for Arduino (C/C++)
3. Use one example sketch from PubSubClient Library, slightly adapted
4. To make it simple, the MQTT broker used is Mosquitto, running on my MacBook.
Et Voila, it has worked.
I can go to eat something. I’m happy.
See you soon.
Recently, Arduino has entered at great speed in the IoT world. One board that is really interesting is Arduino MKR1000 (MKR stands for Makers!). A very small board, with built-in WIFI, enough cheap.
I have bought one at Maker Faire 2016 (in Rome, obviously) and this evening, after some soldering, I have decided to give it a quick try.
Obviously, my first choice was to test if it is easy to send an MQTT message from MKR1000.
Well, I have to tell you that it has been really easy.
1. Use WIFI101 library
2. Use PubSubClient Library (by Knolleary) for Arduino (C/C++)
3. Use one example sketch from PubSubClient Library, slightly adapted
4. To make it simple, the MQTT broker used is Mosquitto, running on my MacBook.
Et Voila, it has worked.
I can go to eat something. I’m happy.
See you soon.
Subscribe to:
Posts (Atom)