RoadTest: Arduino MKR WAN 1300 + ENV Sensor Shield
Author: daemoninformatica
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: TTN LoRaDuino
What were the biggest problems encountered?: The hardware was OK, so was most of the libraries and support modules. The Documentation on the MKRWAN1300 left Much to be desired.
Detailed Review:
April 22nd 2020, mister Randall Scasny created a roadtest to invite enthousiasts to review the MKR WAN 1300. This is a LoRa-WAN development board containing a LoRa WAN modem, a powerful processor and some peripherals to be able to run autonomously for an extended period of time. I'd like to take this moment to point out that this is my first roadtest review. I had quite a bit of fun doing it and hope the review is useful for others. While It's quite a bit of text, I think it's pretty well structured and readable. English may not be my first language, but I'm well versed in it.
In this roadtest, I will review the parts, some background I could find on the MKR line and my personal experiences with the hardware and software (and support) as I try to develop a series of experiments. (More on this in the chapter ‘Roadtest outline’.) Each step / experiment in the roadtest will be described in a defined structure with the following elements (if applicable):
This may come across as rather formal, but in my field of development and testing of components, I learned that it pays to keep structure. This allows for comparing data and notes and will make tests transparant and reproducible.
Finally, I will summarize my experiences with the roadtest and recommendation.
For the tests I will use Arduino IDE version 1.8.13.
Whereas the standard Arduino boards are usually GPIO platforms without any builtin (wireless) communication (safe for a few exceptions) the MKR family are an Arduino compatible platform with a seperate formfactor (67.64mm x 25mm) (1) and a host of shields specifically designed for the MKR platform. (2) The platform appears to be intended for developers and engineers aiming to develop new IoT products. It appears that all MKR boards, beside a specific type of wireless communication, use an ARM Cortex-M0 as controller. The only exception in this case is the MKR Vidor 1400, which is an FPGA.
Its stronger, more complex controller and specific type of communication for each type of MKR board, would make it a somewhat more professional / advanced development board, relative to the basic Arduino such as the Uno, which is an entry-level platform, often regarded for education.
As mentioned, the roadtest is about a combination of 2 components:
1) The MKR WAN 1300 LoRa board.
2) The MKR ENV shield, a sensorboard with an array of sensors. (3) (More on this in the next section ‘Form-factor of the components’)
MKR1300:
Illustration 1: Captured from MKRWANV1.0_sch.pdf (4) and annotated
The pinouts, overal size and the mounting points are standardized throughout the MKR board and shield lineup. This means that with any combination of boards and shields the size of the platform will remain more or less the same. (Provisions for peripherals like antenna’s and other parts taken into account.)
Vin is a set of 2 1.5 Volt batteries, type AA or AAA.
Many of the other pins will be familiar from the typical Arduino spec:
- 14 digital in / out pins, of which 2 (D13 and D14) are serial output. There are also pins dedicated for I2C and SPI.
- 7 Analog inputs, of which one is potentially a DAC output.
- Power in / output: 3.3V, 5V, GND
- A reset pin.
Similar to most Arduino’s, the 1300 also has a built-in led.
MKR ENV shield
Illustration 2: Layout of the MKR ENV shield (3) - Annotated
The MKR ENV board is slightly shorter but as wide as the 1300. It holds 4 sensors (one of which measures temperature as well as humidity), an SD card slot and a reset button. All sensors, except for the light sensor are I2C sensors. The light sensor is wired to A2. The SD card is wired to the SPI interface. The entire board is powered with the 3.3V output from the 1300.
Both the Barometric and the temperature sensor also have a ‘data-ready’ pin wired to I/O 7 and 6 resp. These can apparently be used for interrupts to read measurement results as soon as they’re ready. This will be explored during experiments in the road-test.
In this chapter I will expand on planned experiments and observations which will be expanded on during the experiments themselves. For the roadtest, each tester receives 2 sets of MKR WAN modules and MKR ENV modules. For the sake of test environment documentation, I will number all parts and for each experiment will specify which parts are used, in which combination.
Unboxing: What is received. State of the packages. Contents.
Hello world of the MKR WAN modules: Prove that the board responds to power and data and is indeed programmable. Prove that a program as such actually runs. This is the quintessential blink program which is proven in and on itself and will in turn show that the builtin_led works.
Systematic test of all sensors on ENV: A simple test to read and evaluate the MKR ENV board and its sensors. Access and read all sensors and write the result to SD. The result will be a pre-defined structure of values which can be converted and viewed as a graph.
Peer to peer network between units: A simple connection between both units where one receives a short series of messages from the other device. A practical test might be to install one of the units outside (garden) and use the other as a receiver for metrics unit 1 generates and sends.
Both units to TTN WAN: Configuring both units to connect to the WAN and produce metrics.
I have a relatively bold plan for this setup to place sensors both at different edges of my town and measure metric differences. Hopefully I can camouflage the devices, power them autonomously and still generate both metrics and network output. (Given the relative danger to the devices, I will try this last…)
Details of test: Receiving the hardware, lets see what’s in the boxes. Step by step we evaluate what’s in them. The box contains the first set of the modules. Unless the second delivery deviates strongly from this one, this step will only be documented for the first delivery.
Setup:
hardware: The received cardboard box.
Expected result: While originally the setup of the roadtest was 2 sets of both the MKR1300 and the MKR ENV module, we received word that due to a misunderstanding the package received / on the way would only contain 1 set. The second one would be en-route shortly. The first box will contain the first set of modules.
Result: The delivered box is a solid unassuming flat cardboard box. Shipping address (covered in photo) is plastic-wrapped against the box. It’s closed with a reasonable amount of packing tape.
Illustration 3: Received box
Using a Leatherman I’ve opened the box and it contains cardboard filling and 2 simple Arduino boxes. Those who have experience with typical Arduino packaging are familiar with the method Arduino uses: Small box of thin cardboard with a picture and the name of the product. On the back some specifications and sometimes a link with more information.
Opening the Arduino containers: Simple stickers provide a seal to prove the units are new. These are easily broken with my leatherman and inside I find both units in good condition. The MKR 1300 box also contains a folded leaflet containing information about the unit, some references to other information and a list of other MKR boards. This I file aside. Some of them look interesting.
The units are placed on antistatic black mats, mostly to protect the (relatively long) pins on the bottom.
On both units, the headers are annotated with pin features and functions. These annotations are also on the bottoms of both units. The ENV shield, besides the annotations, also shows which pins are actually used for the features of this board. This is very interesting and will allow for easier planning for further expansion, parallel to the ENV board.
The connectors on both units line up perfectly and snap together effortlessly. Doing so, shows that the ENV board’s slightly shorter formfactor allows for easy access to the antenna connector of the 1300. However, I notice that the Vin connector is a screw terminal and the screws are blocked from access with the ENV board placed.
Personal observations
I’m not a fan of the black pin protection mats. I understand the need to protect / stabilize the pins during transport and storage, but ironically I’ve lost several IC’s stored in these mats because the mats would coat / oxidize the pins.
What strikes me as interesting, is that not only the ENV shield, but also the 1300 board has long pins on the bottom. This makes sense for the shield, to place it on the board. But the board, if anything, might be placed on a breadboard, or at most as a daughterboard in a bigger project. Either way, I would have chosen for shorter pins on the 1300, and / or delivery with the pins unsoldered, to be placed if / as required.
The resulting stack makes me wonder how to approach secure packaging for the environmental tests. Whether to remain stacked, or place them side by side and wire them up on a parent-PCB.
Summary:
I enjoy working with Arduinos. Both from an educational perspective and prototyping projects and ideas. Exposing useful I/O from powerful controllers and packed with features they’ve been pivotal in rocketing innovation into the 21st century.
Their packaging is cheap and simple, but honestly doesn’t need to be more expensive. I’m actually glad the package doesn’t contain an extra USB cable for connecting the board to a computer. The micro USB port is universal and many of my chargers (yes, I hoard chargers and other cables. All engineers do.) have removable USB cables with this port on one end. No paper is wasted on manuals, sheets or much information. In preparation of the test, I’ve been gathering data-sheets, schematics, notes, libraries and other information on both modules, which appeared readily available and easy to find. (See also appendix A: Sources)
One thing of note, is that there is no LoRa antenna supplied. I might imagine that this is because LoRa frequencies differ by regions (5) and antenna’s might well be designed differently for each frequency. (Wavelength differences) It’s not a problem though, I’ll borrow some antenna’s from work.
This set of devices arrived on time and in good condition. A second set that was promised but failed to pack in the first delivery, showed up a week later.
Details of test: The blinkenlight is considered the hello-world in embedded development. It’s pretty much the most basic implementation one can do on a controller, toggling a single pin on and off at a specified timing.
Setup:
hardware: The MKR 1300 board. It has an onboard led which is often used for this (as we’ll see).
Software: For this test we’ll stick to the basic ‘Blink’ tutorial as available in Examples > 01. Basics > Blink. This is because for the most part, we already know we can write a blink from scratch, but need a proven script to exclude it as a reason for failure when something doesn’t work (as intended). This code and a detailed explanation about it can also be found here: http://www.arduino.cc/en/Tutorial/Blink
For the purpose of the test, the code in and on itself is fine, but I've played around with the timing a bit to validate I was not running the original code. The code can also be found here: https://gitlab.com/element14-roadtests/mkr-wan1300-steps/-/tree/master/step-2
Execution: Because before I received the units I already prepared the IDE, I was able to select the MKR 1300 board without a problem. Blink loaded on selection and building went without errors or warnings. After a short misunderstanding about which port to use (one of these days I’ll select a port after connecting an Arduino, before uploading. But not today.) the code uploaded.
Expected result: Upon connection the device will be recogniced as a MKR1300 and given a port. The code is compiled and uploaded with Arduino IDE. The builtin led will blink.
Result: After the code uploaded, the Arduino reset and the led blinks.
Observations: As pretty much customary, any Arduino (compatible) device with a builtin led is shipped with a blink script loaded. As such, it started blinking upon supplying power. Uploading the blink project again the behaviour remained unchanged. To exclude the possibility that it was a false upload, I’ve changed the timing in the delays and uploaded again. This gave a noticeable change in pace on the led.
Summary: While the blink program is trivial, I often find myself writing these little tests even at work to put a new toolchain or installation through its paces. The simple action of blinking a led at a specific pace proves not only that the hardware is supported, but also the compiler and linker is working, there is communication with the device and if anything fails, there is nothing overly complex to debug.
Both boards behave as expected.
Details of test: The MKR ENV shield is an expansion for the MKR line. As described in chapter ‘Devices’ above it hosts an array of sensors that are accessible through several protocols. (Notably the I2C and analog input) There is also the ability to host an SD card for storage.
This test, I will go deeper into each sensor, access it and read data. I will store this data on the SD card and to make things interesting, I’ll power the boards over the Vin connector using 2 AA batteries.
Setup:
hardware:
- MKR WAN 1300 board.
- MKR ENV shield.
- Battery holder.
- SD card.
Software: A script that will periodically read the sensors and store this on an SD card. While no measuring or storing is done, the device will remain in sleep mode. Once every 30 seconds the builtin led will light for a moment. This indicates the program runs.
A seperate application will open the file from the SD card, read the content and parse it into a series of graphs.
Execution: After compilation and installation of the software, the device is removed from USB and connected to battery. The device is put in place (probably the dining room, next to the window, or a place behind the curtain, as long as it won’t be disturbed. After 2 days, the device is switched off again and the SD card removed.
In Observations and Summary we’ll see if we can deduce anything interesting from them. Perhaps also taking into account the local weather reports. The code I used for both operating the MKR's and parsing the resulting dataset is found: https://gitlab.com/element14-roadtests/mkr-wan1300-steps/-/tree/master/step-3
Expected result: With a given interval, it’s possible to figure out how many data-points will be stored. A simple 2 GB MicroSD card should be able to do the trick. The package will be left in front of the window for 2 days to record the rise and fall of parameters over time.
Result: It was in this step that I learned that to say the least: The MKR ENV shield is not compatible with the builtin-led of the MKR WAN. I’ve had a couple of false starts where I was wondering if / why not the device was working because the led (that I programmed to show a heart-beat) didn’t do anything. All to soon I deduced from the schematics of both the board and the shield, that the pin to which the builtin led is connected, is re-appropriated by the shield as an input. Since I first configured the GPIO as output and then intialized the shield support, the pin got reconfigured and the led was never going to blink. I ended up figuring out another pin, and add a new led there.
Observations: The board’s library produces a set of 7 values: Humidity, illuminance, pressure, temperature, UV-A, UV-B and UV Index (Apparently calculated from measured UV values).
I’ve stored the data and wrote a short python script to plot the values with mathplotlib. (both can be found on gitlab).
The graphs I’ll plot here:
Illustration 4: Humidity
Illustration 5: Illuminance
Illustration 6: Pressure
Illustration 7: Temperature
Illustration 8: UV-A
Illustration 9: UV-B
Illustration 10: UV-Index
The test has run for little over 2 days. I think it’s interesting to see how day and night-cycle are clearly visible from the data-points. Relative humidity makes kind of sense if you consider that an indoor location (behind the kitchen window) has the same actual humidity, but varying temperatures. (Something obviously visible in the next graph).
I was slightly taken aback by the maximum temperature measured at that point, but considering the fact it’s inside, just behind the window, in full sunlight, this is plausible.
The pressure sensor puzzles me. For the first measurement, it reports ‘76.13’. I imagine this is a ‘floor-value’ that indicates that the sensor isn’t returning a valid measurement value just after switching it on. For reference: The values were taken once a minute and I don’t buy the fact that the pressure would have jumped a 40 kPa in 60 seconds. (Although this would explain my headaches during weather changes..)
Summary: The library for reading the ENV shield is quite simple enough to work with. Part of me was actually slightly disappointed not having to write the drivers for the sensors, but the given library (6) makes things trivially easy to install and build. The fact the builtin led is effectively disabled threw me for a loop for a moment, but I imagine the decision was made that the shield more or less blocks view of the led at any rate. The full complement of board I/O is exposed through the shield, and the information about the shield easily allowed me to select IO for an alternative led indicator. There’s not much I can say at this point about sensor precision, but the values (save for the pressure one) appear sensible if nothing else. While I’m wondering about the fact that optimal sensor positioning for each type of sensor on this board might be different (and therefor the board itself not optimal) I must not forget the fact this is a sensor evaluation and experimentation board. Not an end-product.
Details of test: Before trying anything like connecting to a gateway, I’d like to try and connect the two units together. Nothing too insane, lets place one downstairs and run the receiver in my workshop. (1st floor.)
Setup:
hardware:
- 2x MKR WAN 1300.
- 2x LoRa antenna’s
software:
DumbModemLoraSender: This is the example script from the MKRWAN library. It starts the modem and every given interval sends a message over the air. This is unauthenticated and not over a gateway. It’s received by anything that might listen.
LoraReceiver: This is one of the example scripts from Sandeep Mistry’s LoRa module. It starts the modem and starts parsing received packets.
The code used: https://gitlab.com/element14-roadtests/mkr-wan1300-steps/-/tree/master/step-4
To use Either code, one has to install the library from Sandeep Mistry. (7)
Execution: An antenna is installed on both devices. According to research, a certain modem firmware update is needed. This is packaged in the examples of the MKRWAN library, and appears to install an array of hex values to the modem’s NVM. Both modems should receive this update.
One modem is then setup as a receiver with the LoraReceiver code.
The second modem is setup as a sender with the DumbModemLoraSender.
Expected result: Plugging in and starting the receiver first, it’ll monitor the configured frequency. The sender is then setup on another location and start sending as soon as the modem is configured. The receiver’s terminal will display the messages sent by the sender.
Result: The firmware update installed without a problem. Although I made sure that, after completion, I replaced the installer with a harmless blinky.
Having had a lot of headaches in the past where I observed others trying to connect LoRaWAN modules to a gateway, I expected failure. However, it worked on the first try.
Observations: With the receiver running and the sender then plugged in, I started observing transmissions immediately. A simple ‘hello [index]’, but still, the result is there. It feels like I should try more in this phase…
During the test, I noticed something, this is the output of the receiver:
Received packet 'hello 316' with RSSI -75
Received packet 'hello 317' with RSSI -74
Received packet 'hello 317' with RSSI -74
Received packet 'hello 318' with RSSI -74
Apparently, ‘hello 317’ was received twice… The receiver script reads only what’s in the buffer. The sender sends one line every 10 seconds. Diving deeper in the LoRa library, the write function writes the set of characters to some register one by one. Only one time.
I can only imagine that the receiver received the message twice, or for some reason the receiver’s buffer isn’t cleared or something.
Summary: The ease of which I did this step with, was refreshing. I hit a slight roadbump with the fact that ‘DumbModemLoraSender’ is packed as an example of MKR WAN, but needs an extra library to compile. The comment in the sender’s script mentions the library, but not the fact one should install it. Only that it’s based on it. Since the sender and receiver basically initialize the same way, I assume the roles can trivially be reversed. While in principle I’ve completed this planned step in the roadtest, I can’t help thinking I should expand this somehow.
Details of test: While step 4 was completed successfully, it left me wanting. Sure, I could establish a simple connection between the two units and send a hello, but that proved very little. I took most of the code from somebody else and added virtually nothing of my own.
I decided to expand on step 4 and use the ENV shield to send information to a receiver.
Setup:
hardware:
Illustration 11: Sender
Illustration 12: Receiver
For this test, I've connected both units to computers, over USB (Too much debugging going on, and by the time I had it working, I saw no reason to rebuild the hardware and software to work independent from Serial.)
Software:
The developed software for sender and receiver are added to the gitlab repository:
https://gitlab.com/element14-roadtests/mkr-wan1300-steps/-/tree/master/step-4.2
Expected result: Starting first the receiver and then the sender, the receiver will continuously scan the frequency for packets to parse. The sender will execute a measurement and send a packet containing values of the sensors and the switch.
The receiver will show this content. The first packet, it will always respond with the current state of its own switch. Every next packet it will receive, it will check if its own switch has changed in the meantime and if so, will send the state to the sender, which in turn will (hopefully still) listen for updates before going to idle.
The receiver's updates are numbered with an unique id (incremental int). The sender will track this value and if it happens to think it received a packet twice, it will discard it.
Execution: Both units were connected to a computer (Sender to a laptop, Receiver to the desktop).
Starting the sender and the receiver, once all issues were solved the packets from the server were clearly visible on the receiver's terminal. Switching the switch on the receiver, the receievr would send an update to the server. The server would then update its led-state to on or off.
Result: It took me a moment to get this working (contrary to Step 4) such that the receiver would
Once I got that working. The entire setup was pretty stable. While still pretty simple, this setup gave me a more complete overview of what a (peer to peer) setup of LoRa devices could do.
Observations: Both the sensor values, the switch and the led behaved mostly as expected. In the beginning I made the mistake of assuming that the Receiver would pick up and receive the Sender's packets even if you're not calling 'parsePacket()' continuously. Looking back and into the library this is of course nonsense. The dance of sending and listening to data on both sides is completely up to both programs. And ultimately not very complicated. Once, I noticed that the receiver somehow stopped receiving packets altogether. At the time of writing I'm still not sure what happened, but the only way to restore this was to reset the receiver. (The sender was unaffected) I was unable to reproduce the issue. I suppose I somehow lost synchronicity between the devices to a point where the receiver wasn't listening the moment the sender was sending.
Summary: I could appreciate how the LoRa libraries written by Sandeep abstract much of the work away from the main application. Listening to packets, as well as sending them can be done over and back by both sender and receiver, as long as each is acting its role in tandem.
However, this was the first step where I saw the need to actually document the hardware as a set of schematics. (i.e. I added more than a led.) The store page actually gives a Fritzing file to import to Fritzing editor, but importing it gave a (non-fatal) error about some svg and trying to use the model in the schematics editor was impossible: The variations simply did not contain the pins to use. I was not impressed.
Details of test: TTN stands for 'The Things Network'. It's a provider of sorts that sells hardware and provides infrastructure to install gateways and nodes throughout the civilised world. They're not the only ones doing so. Here in the Netherlands there is another provider (KPN) that aims to provide national cover for LoRa. The MKR WAN 1300 is built to connect with providers like these. I'm aiming for the TTN network because it's free. The only (rather painfully obvious) downside of this, is that their crowdsourced gateway coverage leaves something to be desired.
Setup:
hardware:
1x MKR WAN 1300
1x LoRa antenna.
1x tumble-switch
Laptop.
software:
Arduino code: https://gitlab.com/element14-roadtests/mkr-wan1300-steps/-/tree/master/step-5/LoraSendAndReceive
Expected result:
Once I connect to the LoRa WAN network provided by TTN, I should be able to send payloads that will show up on the TTN dashboard I've setup for my device. After that, I'll try to extract the information from the TTN network into a local program.
Execution:
Here's where I ran into some headaches concerning connecting to the network. The city I live in happens to have several gateways. 2 of them are clustered around the center of the city, virtually on top of eachother. Another one is on the outskirts, apparently radiating further out the city. A fourth one reports as 'likely a single channel gateway' on the map and shows no range area on that map.
Connecting from the northern part of the town (my home) turned out to be impossible.
My second try was much closer to the single-channel gateway. It still wouldn't connect. Reading up on these single-channel gateways (8), I learn that they're not LoRa-WAN compliant. Not being able to connect to them shouldn't surprise me.
My last try (third try is a charm) was from a small cafe near the center where I knew there would be devices in range. I opened the dashboard and powered up the module. Finally I was able to read message payloads from the device! At first, these puzzled me though. As one can see from the code, I basically send a string and then a seconds counter over the air. The received payloads were all the same. (The first message, after powering on the device.) What was more: While I received the messages on the gateway, the device reported on the terminal a 'Failed' execution.
Turns out that because I ended the packet with a 'modem.endPacket(true);', the modem expected the gateway to respond with an acknowledgement. It received the message, but didn't send this ack. The modem in turn didn't mark the payload as sent.
This caused the modem to hang on to the message in some internal buffer, and tries sending it again on endPacket. The gateway would receive the packet again and send no acknowledgement.
Setting the endPacket parameter to 'false', the modem would never stop to wait for an acknowledgement and simply go on its merry way. The next payload it would send is a new message with a new timestamp.
Result:
Once I had my code working, was in range(-ish) of a gateway and ironed out the final few kinks, I managed to send a series of messages to the gateway and in turn the LoRa WAN network.
Observations:
I was not impressed by how hard it was to connect to the network. In the end, I nearly sat on top of a gateway (about 400 metres away) to have some sort of connection. Once connected though, the way to send a message was in the end pretty transparent.
One other thing of note: The SDK documentation on the arduino.cc site is not complete. Functions available in the SDK are missing and information about several functions is either incorrect or incomplete.
This made the development / understanding of the (sample)code somewhat tedious, having to trawl through the libraries themselves to figure out what functions do / are available.
Summary:
I'm pretty sure the modem itself wasn't the reason it was so hard for me to connect to the network. Like I said: TTN is an interesting, crowd-sourced initiative, that lowers the threshold to get infrastructure up and running, but does not control or moderate where that infrastructure is placed. That's why there's two gateways nearly on top of each other and most of the city has no reach.
I'd much like to find a way to access the KPN network. In theory the coverage should be much better. But I don't have the keys for it.
The MKRWAN 1300 is a nice developer board to get aquainted to the LoRa WAN modem and network. Its design is pretty elegant and versatile. The onboard Cortex-M0 is more than powerful enough to run it.
Over the course of the steps in the Roadtest, I’ve had a couple of observations about parts of both boards (MKR WAN 1300 and the MKR ENV).
MKR WAN 1300:
hardware:
- Formfactor of the board: It’s nice, robust and works well on a breadboard. Its long pins make for a stable connection on such a board, as well as mounting as a daughterboard, using mounts similar to the ones on the board’s PCB itself. It does however stress the fact that it’s really not very much intended for more practical use in the field. It has a high physical profile and I had a bit of a hassle figuring out a compact setup on fieldtrips.
Software:
- Bootloader: The bootloader option to double-press reset to stay in the bootload really saved my bacon here. (I still feel like such a noob)
- Library: The support for most of the MKR WAN 1300 module is in one convenient header. But pretty much the entirety of the support is for the modem. And the WAN mode at that. For the peer-to-peer configuration I needed a different library.
- Examples: The examples in the library download were pretty useful actually. Took some fiddling but it helped me a lot to figure out the SDK. More than the documentation anyway.
Documentation:
I am not sure what exactly happened, but the documentation is far from complete.
- There’s schematics, but no PCB layout. I’m pretty much still assuming the two-pin screw-terminal Is the 2 pen-lite / 3V input. (And not / also the 4 pads on the bottom? I imagine one can solder a CR-battery holder to it?)
- The SDK documentation on the MKRWAN module is missing several functions and parameter descriptions for functions. In one or two cases the given examples aren't even relevant to the function, or add no insight in how to use it.
- There is virtually no mention of the ECC508 on the datasheets of the MKR 1300. Or anywhere else for that matter. There is no documentation about it at all, other than the re-iterations of the Examples in the MKRWAN library. I’ve found a library that should help talking to the chip using an Arduino, and it appears pretty straightforward. But the library has zero documentation, or comments in its code. There are some example projects for it, but between it and several posts about ‘locking / bricking the chip with wrong configuration’, I’m torn between using it and breaking my boards. (Even if the chip isn’t technically required for using the modem.)
- The Fritzing file on the website is unusable. I don’t have a mighty lot of experience with it, but trying to select options in the module, shouldn’t cause MKR 1000 or Arduino Nano layouts to pop up.
MKR ENV:
hardware:
Like most (but not all) shields, the ENV has a reset button on the shield. I like that.
The sensors though can't be 'switched off'. They don't draw much power, but still: In ultra-low power applications like a LoRa WAN setup, it's good practice.
Using the ENV shield disables the builtin led. This threw me off for a moment, thinking that I messed up somehow. Fair enough, the led is technically covered by the shield. So I suppose it's ok to assume one wouldn't use it. But in practice the led is perfectly well visible during debugging. I resolved to add a 'builton-led' (instead of a builtin-led) to take over the function of blink output.
Software:
Special Kudo’s to the library for the ENV board: The board has a lot of different sensors, not all of them easily usable. (I2C controls and some conversion factors to take into account.) The library makes this all go away completely. Essentially you receive the values for politely asking. I could scarcely have done a better job myself.
Documentation:
The schematics in this case helped me understand why the builtin led didn’t work if you tried using the ENV board. Still: Again no PCB layout, even if in this case I didn’t specifically need it.
Over the course of years, I've attended several TTN workshops where they'd try and demo the platform and gather interest in the technology. Those afternoons often kind of devolved into failed attempts to actually connect to the network.
I was pleasantly surprised when I finally succeeded. But not impressed by the actual range in the end. This might well be the location of the available gateways, but that's not the point.
Purely from a platform and educational perspective, I'd recommend the platform. Hobbyists can get aquainted with the tech and in classrooms students can get an introduction without too much of a hassle. (The MKRWAN library abstracts out a lot of the low-level control). If a school invests in a gateway, as well as sets of MKR’s, they shouldn’t have much trouble making connections.
As a hobbyist though, apply due dilligence to figure out what coverage your area has for LoRa-WAN.
Of the two boards though, the ENV board might well be my favorite.
1) https://maker.pro/arduino/tutorial/an-introduction-to-arduinos-mkr-family-and-iot-development-boards
2) https://www.arduino.cc/pro/hardware/product-family/mkr-family?id=1996559
3) https://store.arduino.cc/arduino-mkr-env-shield
4) MKRWANV1.0_sch.pdf
5) https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html
6) https://www.arduino.cc/en/Reference/ArduinoMKRENV
7) https://github.com/sandeepmistry/arduino-LoRa
8) https://www.thethingsnetwork.org/docs/gateways/start/single-channel.html
Top Comments
Very nice Road Test write-up! LoRa as a technology and TTN as a service are both something I have been meaning to look into.
I didn't know about the ENV shield. I have been working on something similar…
I agree, very good road test report.
DAB
Hello Jan,
First of all: 'Eeek! Somebody is responding to my review again. And asking for my advice! ^_^'.
Sorry.
To answer my question: I've spent weeks on and off in attempts to connect to that…