After having built a number of Wi-Fi IoT gadgets for the home, Brian became curious to see how LoRaWAN-based IoT devices would work. He decided to investigate the Notecard LoRa IoT modules made by Blues Wireless.
For a few years now I have been experimenting with various IoT devices that I either designed myself, using wireless-SOCs like the ESP32, or using Particle IoT modules that were specifically designed to interact with the Particle cloud server. Therefore, I wasn’t familiar with the IoT products made by Blues Wireless over the last 4 years, until I saw a recent press release describing a Blues Wireless IoT module using the LoRaWAN RF protocol for communication between an IoT device and a local gateway. LoRa is a much longer-range RF communication method than either the Bluetooth, BLE or WiFi methods that I had tried so far. I found LoRa communication interesting and while looking at the Blues Wireless Notecard LoRa module, I found that it was only one of a line of Notecards which can be used to make IoT devices- using RF communication methods such as WiFi, Cellular, WiFi+Cellular, and LoRa. Figure 1 is a photo of the Notecard LoRa
This is a photo of the Blues Wireless Notecard LoRa module. It’s small: 30mm x 35 mm and has a common M.2 edge connector.
Blues Wireless were kind enough to send me a sample of the Notecard LoRa module along with everything else needed to test it out. In this column, I’ll describe my findings, after having tested this module and the cloud server that Blues Wireless operates to support it and other IoT modules that they sell. Interestingly, while I was reviewing the Notecard LoRa, Blues introduced a new Notecard that is designed to communicate with a satellite constellation, administered by Skylo.
“Data Pumps”
Having consideration of the reader’s time, there is one important distinction that all the Blues Notecards share, which I’ll mention right off the top. All Notecards are described as “data pumps”. What exactly does this mean?
The RF-enabled MCUs and SOCs that I have used in the past, for custom IoT devices in my home, were all complete units. That is, the same MCU that handled the RF communication protocol stack also executed the program that:
- Read any sensors used and optionally processed that data, to some extent.
- Manipulated GPIO lines to handle any actuators connected to the IoT device, such as lights, pumps, etc.
- Possibly handled some scheduling of the above two tasks.
The ESP32 is an RF-enabled MCU and the Particle modules contain a WiFi or Cellular modem device onboard. The ESP32 has a dual MCU core: one core is dedicated to the WiFi and/or Bluetooth stack, leaving the second core free to perform any user-defined tasks such as reading sensors without fear of disrupting any necessary RF communication tasks. The Particle modules, by and large, have used an intelligent RF modem chip to handle the RF protocol stack, or they ran an RTOS on an RF-enabled MCU, to ensure that all tasks were performed in a timely fashion.
In contrast, all the Blues Wireless IoT modules are, in Blues Wireless’ words, strictly “data pumps”. That is, they handle one or more of the RF protocols needed to establish wireless communication with a central controller/gateway. They don’t execute a user program that would handle the three categories of tasks listed in the bullet points above. Those tasks must be handled by an external, user-supplied MCU, which communicates this information, bidirectionally, to the Notecard via UART, I2C or USB. The designer is free to choose whatever MCU he is most comfortable with, assuming it can do the low-level tasks such as interfacing sensors, actuators, etc., and has a UART or I2C port.
The other distinction is that the Blues Wireless Notecards are designed to seamlessly connect to the Blues Wireless cloud server. You might be thinking “Wait- that is too limiting for my purposes”. You may be right, but the Blues Wireless cloud server is structured to act only as a temporary “middle-man” for the data to/from your IoT device(s). Their cloud server is set up to allow “routings” to various other commercial cloud providers which offer a full suite of services. I’ll go into more detail on the Blues Wireless cloud service in a later section of this column. Note that this method of implementing a cloud service is similar to what Particle provides for their IoT modules. However, the Blues cloud does store and display IoT “events” for a modest amount of time, which is helpful in troubleshooting. The Particle cloud service will only display such events if you are monitoring your IoT device, using their web-based “dashboard”, at the time that these events actually take place.
The advantages to the Blues IoT board/Blues cloud integration are simple. First, they shield the end-user from having to determine how to get their IoT devices authenticated by the various cloud servers. With security becoming a very important part of IoT installations, this authentication can be quite complex and involve encryption algorithms that may be hard to implement on the MCU that you are planning to use for your IoT device.
To a large IoT developer, setting up an AWS or other similar cloud service account may not be a major undertaking. Cloud services like those provided by Adafruit or Arduino, have free plans for small developers with small data traffic requirements and will likely remain in operation for the foreseeable future. However, some free services tend to disappear over time, rendering any IoT device that connects to them useless. Using Blues Wireless IoT modules will minimize this possibility.
Notecard LoRa and Notehub Integration
Figure 2 is a block diagram showing how data flows when using the Notecard LoRa modules. The Notecard LoRa communicates with a local gateway using the LoRaWan RF protocol. This local gateway is a Wisgate RAK7268V2 Gateway device that has been pre-configured by Blues to connect to their cloud server called Notehub. Figure 3 is a photo of this gateway along with its power adapter. While you could buy a different LoRa gateway device and configure it yourself, this is somewhat complicated, so it makes sense to purchase this gateway from Blues Wireless directly. Once you’ve done a simple configuration process, your gateway will connect to the Blues Wireless cloud. This consists of the Blues Network Server and the Blues App Server, both of which are based upon the cloud service “The Things Stack.” This cloud service can be accessed by the end user using the Blues Notehub dashboard, which is a web-based application. Note that nothing will show up here until you actually power up a Notecard-LoRa module and configure it for your own IoT Project. As far as I can tell, the Blues Notehub dashboard, doesn’t show any information regarding the connection status of your gateway device, nor any of the gateway’s identification information.
Data flow between the Notecard LoRa and the Blues Notehub is shown. Note that it is intended that the Notehub not directly act upon that dataflow, but merely pass it on to another cloud service.
This is the Wisgate RAK7268V2 gateway that is supplied by Blues. It has been pre-configured to connect to their Notehub cloud service.
Once your IoT data is in the Blues cloud, it can be monitored in the Notehub dashboard, using the Device and Events tabs. The Device tab will show you when any specific Notecard was last “seen” by the Notehub cloud server, and possibly where it is located, if you have a notecard containing a GPS receiver. The Notecard LoRa does not offer this option. In the Events tab, you will see a list of events that have occurred lately. I’ve seen 700+ events stored and displayed such as a demo program I left running for a while, unintentionally. I don’t have a higher tier paid account, and am not sure how long the display of these will persist, but it’s been a few weeks since I started and they’re still there. These events can be individually deleted manually, but I don’t see where you can choose “Delete All”, so I guess I’ll leave these 700+ events intact. Maybe they’ll disappear automatically, in due time.
Selecting an event and clicking View will supply you with all the details about that event, including the data itself, Product UID number of your assigned project, as well as the DeviceUID of the Notecard itself. If the Notecard has knowledge of its location from GPS or cell tower information, this will be displayed here as well.
When events arrive on the Notehub from remote IoT devices, apart from the above monitoring capability, they can also be routed to another cloud service of your choice. I believe that these linked cloud services can also send messages to Notehub, where they would be forwarded to the appropriate Notecard. This could activate some external device, under the control of the Notecard’s host MCU’s GPIO lines. More on this “Route” integration in a later section of the column.
Notecard-LoRa Starter Kit
For those who have not used Blues Wireless Notecards before and wish to try out the Notecard-LoRa modules, I would suggest purchasing the Blues Starter Kit for LoRaWAN, shown in Figure 4. Unlike some development boards, which are high-priced because they aren’t sold in large quantities, Blues Wireless offers the Notecard-LoRa Starter Kit for $199 USD. This kit includes a Wisgate RAK7268V2 Gateway unit, and 3 Notecard Lora modules, 3 Notecarrier B carrier boards, 3 Molex antennas and 3 LiPo batteries. This is good value, since Wisgate sells their RAK7268V2 gateway alone for $139 USD. Therefore, each set of parts for the three IoT devices is being sold for only $20 USD. If you’ve bought LiPo cells, you’ll find them to be more expensive than you’d expect, probably because they are not easy to ship, for safety reasons.
This is the Starter Kit for LoRaWAN that Blues Wireless sells. Besides the gateway, it includes 3 complete sets of parts needed to interface Notecard LoRa modules to your host MCU.
For the purposes of my review, it didn’t make much sense for me to get a complete set of parts for three IoT devices. Instead, I requested that only a Gateway and one complete set of parts for the Notecard-LoRa be supplied. In place of the Notecarrier B carrier board, I asked for a Notecarrier F board. The Notecarrier B boards are basic carrier boards containing circuitry to provide the Notecard with power, a USB port (power and serial), level shifters for the logic signals, a Qwiic socket for I2C devices, and a LiPo charger chip.
The Notecarrier F board contains all the above as well as a socket for an external MCU, using the popular Feather footprint developed by Adafruit. This was a particularly good choice as Adafruit sells many different MCU cards based upon the Feather footprint. To support these boards, Adafruit has written and provided a lot of library routines, examples and tutorials. In terms of language support, they provide equally comprehensive content for both the Arduino IDE and Circuit Python which they developed as a fork of MicroPython.
From Figure 4, it appears that the Starter Kit comes with 500mAh LiPo batteries. I didn’t get a Starter Kit and received a 4000mAh LiPo battery, instead of the smaller ones normally supplied in the kit.
While it’s nice that the Starter Kit for Notecard LoRaWAN comes with a LiPo battery augmented by the Notecarrier F board’s LiPo charger chip, you can do a lot of testing without it by plugging the carrier board into a PC, using the USB cable. From my tests, the maximum current draw of the Notecard LoRa and Notecarrier F combination, is about 115mA during transmission peaks. However, some other Notecards contain a cellular modem. These boards will require much more than the 500mA available from a standard USB port, during the current peaks that occur during cellular transmissions. When testing those notecards, you would need to have a charged LiPo battery plugged into the carrier board.
The Starter Kit comes with 3 Molex 209142 stick-on antennas. These cover the frequency range of 696-to-960 MHz needed to handle the 868 MHz (EU) or 915 MHz (North America) LoRa bands. However, they also handle 1710-2590 Mhz and 3300-3800 MHz. I assume these same antennas may be used for the Notecard modules that contain cellular modems, which use these much higher frequencies. At LoRa frequencies, they have a gain of 1.2dBi with respect to an isotropic reference antenna.
Notecard Lora and Notecarrier F
Like other Notecards, the Notecard LoRa is a small (30mm x 35mm) module containing an M.2 Key E edge connector. This is the same type of connector used for SSDs and modems in laptop computers, for example. The module contains a U.FL socket for the antenna and a very tiny red LED indicating RF operations.
LoRa began as the brainchild of two French friends Nicholas Sornin and Olivier Sellar and later joined by Francois Sforza. Their company, Cycleo developed this long-range, low power modulation scheme using Chirp Spread Spectrum modulation technology. That company was acquired by Semtech. It, along with IBM and others, developed the LoraWAN protocol, that is commonly used today. Semtech developed the popular SX1172 and SX1176 chips used in Lora transceiver modules, and the SX1301 chip used in LoRa gateways, like the Wisgate RAK7268V2.
Other chip companies have licensed this technology, and the French-Italian company ST Microelectronics has developed an RF-enabled MCU, the STM32WLE5, that operates in the sub-GHz band and uses the LoRaWAN protocol. The Notecard LoRa uses this MCU, which is an Arm Cortex-M4 operating at a 48 MHz clock rate and containing 256 Kbytes of Flash and 64 Kbytes of SRAM.
Notably, the STM32WLE5 is an ultra-low power MCU drawing only about 360 nA in Standby+RTC mode. Once integrated into the Notecard, this idle mode current is still only ~9 uA.
When transmitting, the STM32WLE5 will draw only 15mA at a transmit power of 10 dBm or up to 87mA at a transmit power of 20dBm. While I am not sure what transmit power setting is used by default on the Notecard LoRa, these readings agree closely with the 62mA average transmit current that I measured with my Joulescope Power Analyser (see Figure 5) That 62mA value includes current drawn by all of the extra circuitry present on the Notecarrier F board, which is not insignificant.
This is a screen capture of the power consumption of a Notecard LoRa, mounted on a Notecarrier F board. The current peak at the right is a LoRa transmission, which lasts about 284 ms.
The STM32WLE5 is a very versatile RF-enabled MCU containing both a 12-bit ADC and a 12-bit DAC as well as the usual assortment of timers, an RTC and communications ports. Since the Notecard LoRa module is strictly a data pump, many features such as the ADC and DAC, are not accessible to the end user. However, the ADC is used to measure the battery voltage, which can be read using the Notecard’s API.
The STM32WLE5 MCU contains a built-in switching mode power supply operating in step-down mode. The Notecard LoRa module’s datasheet shows that it requires both of the following power supplies:
VMODEM_P pin requires between 2.5V and 5.5V.
VIO_P pin requires 3.3V @ 150mA
While Blues supplies a schematic for the Notecarrier F board, I couldn’t find the schematic for the Notecard Lora module on the GitHub site cited in the documents. I believe that the voltage supplied to the Notecard LoRa’s VMODEM_P pin is passed along to the STM32WLE5 MCU where it’s internal SMPS converts it to the power supply needed by the STM32WLE5 MCU itself. The Notecard LoRa datasheet indicates that one should also allow for up to 150mA current draw on the VIO_P power pin. When I checked with Blues Wireless, they confirmed that both power supplies are needed, and that the 150mA requirement on the VIO_P pin is a conservative value. It’s only a guess on my part, but I think this current value allows for the possibility that the end-user may choose to swap out a Notecard LoRa with a Notecard featuring Wi-Fi or cellular or both, which might draw this amount of current.
While other Notecards that utilize cellular data transmission include a GPS module, the Notecard LoRa does not include such a module.
The LoRa frequencies used in various regions of the world differ. The Blues Wireless Notecard Lora is available in either 915MHz for North America or 868 MHz EU models. Other regions of the world, like Asia, India and South America also use frequencies that are in the 868 MHz and 915 MHz bands, but with somewhat different upper and lower band limits. The STM32WLE5 MCU accommodates both bands, and the band selection is programmed in when the Notecard Lora is provisioned at the factory.
Like other Notecards, the LoRa must be controlled by an external MCU. Notecards contain three different serial interfaces over which this communication can take place:
UART interface at 3.3V logic levels (i.e. equal to VIO_P), at a fixed baud rate of 9600 baud.
I2C port at 3.3V logic levels.
USB Serial port full-speed CDC device. This is how the Notecard communicates with a PC when using the In-Browser Serial Terminal available on the Blues website, when viewing applicable webpages.
I chose to receive the Notecarrier F board in place of the Notecarrier B that normally comes with the Starter Kit for LoRaWAN, because it contains a socket for a Feather MCU module. While it wouldn’t have been a big effort to wire up an external MCU board to the Notecarrier B board, it was easier to just plug a Feather MCU module into the Notecarrier F. Figure 6 shows the top side of an unpopulated Notecarrier F board. Apart from the Notecard module, most of the active components are actually mounted on the bottom of the board.
This is a top view of the Notecarrier F board, less a Notecard module. Most of the active components on this board are located on the bottom side of the board. Note the Feather MCU socket at the bottom.
Initially, I assumed that the Notecarrier F board would connect the Feather MCU’s UART port to the Notecard LoRa’s UART port. While there is a dedicated connection between the Feather MCU and the Notecard LoRa’s AUX Tx and AUX Rx pins, the Notecarrier F document shows that as being used for Notecard Outboard Firmware Update purposes. Also, this second (AUX) UART port is normally switched off in the Notecard firmware to save power. If you wanted to use it to communicate with the Feather MCU, you would have to raise the AUX_EN_P pin high. This is all explained in the Auxiliary Port section of the Notecard’s datasheet.
To control the Notecard LoRa using the UART port on a Feather MCU, you would need to wire up the Feather’s Rx, Tx pins to the Notecard’s Rx_P (pin 62) and Tx_P (pin 64) (which is the Notecard’s primary UART port and is enabled at all times).
Please refer to Table 1 which shows all the interconnections between the Notecard and the Feather MCU socket on the Notecarrier F board. Notice that the Notecard’s I2C port is connected to Feather’s I2C port. I found that the Blues-supplied Arduino sketch examples use the I2C port to communicate with the Notecard LoRa. While it was not evident from the example sketches provided, the Notecard’s I2C port has a default address of 0x17. If this conflicts with other I2C devices that you may be using, it can be changed by issuing the following JSON command:
{
“req”:”card.io”,
“i2c”:24
}
Note that you must issue this command from either the UART or USB serial port and not the I2C port. I am guessing that this setting must be non-volatile, as you wouldn’t normally have the Notecard plugged into a PC under normal (i.e. non development) conditions.
— ADVERTISMENT—
—Advertise Here—
This is a list of interconnections between a notecard and the Feather MCU socket, on the Notecarrier F board. Their usage is described in the text.
From Table 1, you can also see that there is a dedicated connection between the Feather’s EN line (F_EN) and the Notecard’s ATTN line. The EN line on a Feather MCU board is always pulled up: pulling it low will disable the Feather’s onboard LDO regulator and power the whole board off. Therefore, the Notecard could reduce the system power consumption by dropping its ATTN line low. Note that on the Notecarrier F board, there is a switch that will disconnect the Feather’s EN line from ATTN and connect it instead to N_VIO. This powers the Feather up at all times. Here is what the Notecard LoRa’s datasheet says about the Notecard’s ATTN line:
Using software, you can optionally configure Notecard to use the ATTN output pin to:
Inform the host MCU of certain asynchronous events (such as incoming data availability) in an interrupt-driven manner rather than just polling.
Place the host MCU into a power-off sleep state and wake it back up again.
The first option is easy enough to understand. However, this would only work using a Notecarrier F board, if the switch mentioned earlier were configured properly.
The second option would work with a Notecarrier F board, again assuming the switch was set properly. However, since the Feather MCU is supposedly the master controlling the Notecard LoRa slave, it isn’t obvious to me how the Notecard would know when to re-activate the Feather MCU. I am assuming this would occur when the Notecard received some incoming data, but I have not investigated this.
The Notecarrier F board includes two Qwiic sockets both of which contain 3.3V power and a connection to the Feather MCU’s I2C port.
Blues LoRa Gateway
Figure 3 is a photo of the Blues LoRa gateway. This is a Wisgate RAK7268V2 Gateway that has been pre-configured by Blues to connect to their Notehub. This device uses the popular Semtech SX1302 for full LoRaWAN stack support. It contains a 100M Base-T ethernet port with PoE capability. It also contains a 2.4 GHz Wi-Fi port which can also act as an Access Point (AP mode). AP mode is used initially to configure the gateway with the SSID and password of your router. The Wisgate gateway can support a cellular connection if an optional LTE modem card is added. This cellular option is not present on the Blues Gateway shipped with the Starter Kit for LoRaWAN. The unit comes with a 12V 2A wall adapter and draws 1A in operation (12 Watts). It comes with a wall mount plate that can also be used as a DIN rail mount.
Although it is preconfigured by Blues to connect to their NoteHub cloud service, you must perform a bit of personal configuration on the gateway. This involves:
When using the WiFi connection method, your SSID and Password must be supplied.
Supply a username. Use the same one used when setting up a Blues Wireless account
Change the default password for the gateway’s web-based dashboard, for security purposes.
I have a 100/1000M ethernet switch in my office, so I just plugged the gateway into that. However, it’s easy to configure it for your Wi-Fi setup using the gateway’s built in Wi-Fi Access Point (AP). This is well-explained in the Notecard LoRa’s Quickstart Guide.
Once the Gateway is connected to your local LAN, you then do the latter 2 steps described by the bullet points above. At this point, the gateway provides a web-based configuration dashboard. However, this uses a different URL than the one provided by the gateway’s Access Point, used while configuring the gateway with your SSID and password.
This new URL is 169.254.xx.yy. The “xx” and “yy” are decimal numbers corresponding to the last four digits of the gateway’s MAC address (referred to as GWEUI and present on a label on the bottom of the unit). Each 2-digit pair is a hex number, so you’ll have to convert this to decimal format before inserting it into the 169.254.xx.yy URL mentioned above. Note that when you enter this number into the URL window of your browser, it should be entered as http://169.254.xx.yy (not https: which might get added automatically, as you type it in). This is a URL on your local network, and it’s not a secure connection.
When you access this URL, you’re logging in to the gateway’s webserver, which provides a configuration and information dashboard. At this point in the procedure, I got tangled up a bit. I’m a senior and have eyesight to match but I do have a huge wide screen monitor. Even so, when following the Quickstart Guide, what I “saw” for the default password was “BuildWithBlues!” which made a lot of sense. However, that didn’t work and upon closer examination, I saw the correct password is “Bu1ldW1thBlues”. The Guide recommends that you change this default password, and given the above confusion, I did that right away.
Once logged in you must do a small configuration procedure to associate this gateway with your Blues account. If this Starter Kit is your first exposure to Blues Wireless, you’ll have to first establish an account with them before proceeding with the Gateway configuration. For the purposes of my review, and for small developers, this can be the free tier account.
In operation, the status of the gateway can be determined by observing the various LEDs on the unit:
Slot on top of enclosure: This LED is dark for < a minute when the unit is first plugged in. It will then breathe red for a while and end up breathing blue when it has established a connection with the Notehub server.
The Power and Lora LEDs should be lit (green).
The Lora LED will flash when a LoRa packet is being received/sent
— ADVERTISMENT—
—Advertise Here—
WLAN will only be lit if you’ve configured the gateway for Wi-Fi.
The green LED on the Ethernet port should be flashing, showing traffic, if you are using an ethernet connection, as I was.
Note that the gateway’s LoRa transmitter puts out much more power than the Notecard LoRa modules do. Wisgate cautions you to always ensure that the LoRa antenna is plugged in before powering up the unit, or damage to the LoRa module inside may occur. The LoRa module, containing the Semtech SX1302, is contained on a mPCIe removeable module, so I guess you could fix this with a new module, if you didn’t heed this warning.
Connect to Blues Notehub
The complexities of the Lora transmission to the Wisgate Gateway and then on to the Blues Notehub cloud service, are generally transparent to the end user. However, the commands that the host MCU must send to the Notecard LoRa, to initiate such messages, are the user’s responsibility. The method that Blues has implemented is different from what I’m accustomed to but then I generally build custom IoT devices for personal use and implement my own “protocol.”
Since the Notecard LoRa communicates with a host MCU over one of three different serial data links, it’s helpful that the Notecard LoRa’s API commands are ASCII mnemonics. That is, you can enter them manually from your PC, using Blues’ In-Browser Terminal (an extension to your web browser). Furthermore, these commands all follow the JSON structure rules. While JSON is not a compact way to transfer information, this doesn’t matter much between the host MCU and the Notecard, as bandwidth there is not an issue. The advantage of JSON is that it’s well-understood and there are MCU library routines available that will pack and unpack JSON-structured data.
The first thing you would normally want to learn is how to send messages from your host MCU to the Notecard LoRa module (and then on to the Notehub cloud server). First, the Gateway must already be configured, as outlined in an earlier section. Then you must create a New Project and then Add Devices to it, using the Notehub dashboard.
While I could describe the process of setting things up and sending your first message to Notehub, this procedure is well-laid out in Blues’ Notecard LoRa Quickstart guide. This can be found on the “Dev Kits/Blues Starter Kit for LoRaWAN” webpage. Note that, while most HTML links on the Blues website are shown using the standard blue font or underline, in this case, to get to the LoRaWAN Quickstart you must navigate to “Additional Resources” and click on the bullet-point “Blues LoRaWAN Quickstart” which does not show up as a HTML link.
At this point, I’d like to say that Blues Wireless has provided a lot of very good documentation on their products, most of it readily available on their website. One innovation is that when navigating through these Quickstart guides, there are many points at which the right section of the screen will be occupied by a black dashboard prompting you to connect to your Notecard via a USB-Serial link (see Figure 7). Clicking on this button will open the Notecard’s In-Browser Terminal and will connect to any Notecard which is plugged in to your PC via a USB cable. This connection is a USB Com port connection, but you don’t have to figure out what Com port number it has been assigned. This is determined automatically by the In-Browser Terminal. However, if you do check Window’s Device Manager, the Notecard will show up in the Ports (COM & LPT) section as a Silicon Labs CP210x USB to UART bridge. Note that the In-Browser Terminal will only work on browsers that feature the web-serial API. MS Edge and Chrome work fine but my default Firefox browser doesn’t.
This is the black dashboard that appears to the right of your screen when viewing Quickstart documentation, on the Blues website. Once you click on the USB Notecard button, your Notecard will be connected to the In-Browser Terminal, via a USB-emulated serial port.
To further simplify the Quickstart process, at intermediate steps of a procedure, there will be two buttons “TRY IT” and “COPY”. “TRY IT” will paste the contents of the relevant Notecard JSON command(s) into the In-Browser Terminal, at the “>” prompt. You do have to move the cursor to the end of this command and then press “Enter”, in order for it to be sent to the Notecard.” COPY merely copies it to the Windows clipboard, from where you could then paste it into your own program code. There are a few concepts that I’d like to mention regarding the Quickstart procedure describing how to send your first message to Notehub.
For all Notecards (LoRa or the others), these messages are called “Notes.”They resemble the MQTT “publish” or “subscribe” format, in that each Note will include one or more user-defined descriptions of the variable plus a value for that variable. However, these Note definitions, in JSON format, are not something that you can spontaneously define and then send out to Notehub. First you must define a template for each Note, which describes the exact format of the JSON structure used for that Note. Here is a copy of a template definition taken from the Quickstart guide:
{“req”:”note.template”,”file”:”data.qo”,”port”:1,”format”:”compact”,”body”:
{“temp”:14.1,”humid”:14.1}}
Here, we are making a request to define a note template named “data.qo”. The “qo” indicates that the data is outgoing, and “data” can be whatever filename you wish to use. For now, ignore “port”:1, as I will describe it later. The format is defined as “compact”. LoraWAN transmissions are low-speed, so you want to make the Notes as small as possible. After “body”, you define the variables that you wish to send within that Note. Here again, you can name these according to whatever makes sense for your application. In this case the two variables are “temp” and “humid.” However, they are each followed by 14.1 and this bears explanation. Variables can be expressed by your choice of integers, floats, Strings or Boolean. The 14.1 that you see is made up of two parts. The integer part defines the byte size of the variable, as well as whether it’s signed or unsigned. If a “.1” is used, that indicates a floating-point number, the precision of which is encoded into the integer part of this format number. While this looks a bit like the way that the “printf” format specification works, it’s not. To see a table of this numeric format definition, see the Notecard documentation under the “Low Bandwidth Design” section.
The section of the template “port”:1 is not needed for some Notecards but is needed for the Note LoRa and the StarNote (satellite) modules. For both of those RF communication modes, it’s important to minimize the size of each Note: either because of the low bandwidth nature of LoRaWAN, or because of the cost of sending each packet, in the case of a satellite connection. Each Note template must have its own unique port number- in the range of 1-100. I don’t have experience with Notecards beyond what I learned/tried out for this review, but I suspect that both the Notecard(s) and Notehub will have a list of your project’s templates, by port number. When Notes are sent/received, only this port number would be sent- the template structure could be looked up at the other end, using this port number with a template list. Using that template, it’s then possible to interpret the data properly, parsing it into the correct numeric, or String format.
It’s not spelled out in the Quickstart documentation that these templates, once defined, are non-volatile. That is, they are stored in the STM32WLE5 MCU’s flash memory. In the case of templates for LoRa Notecards (and possibly Starnote cards), which use a port #, you can’t just re-define an existing template assigned to a specific port number. You must clear that template using a command like the following:
— ADVERTISMENT—
—Advertise Here—
{“req”: “note.template”,
“file”: “readings.qo”}
Basically, here you are defining the template “readings.qo” with no body arguments. I ran into this issue when I connected a Feather-based MCU to the Notecard LoRa and tried to send a note to Notehub. When I tried to define a different template, using port #1, the Notecard LoRa module refused to accept it, and threw an error. That happened because I had already used Port #1 when going through the Quickstart tutorial. Luckily, I was running a Blues example sketch at the time, which had enabled error logging to the serial terminal. Therefore, I was able to see this error message, which was descriptive enough for me to discover this limitation.
After successfully sending a Note from the Notecard LoRa to the Notehub, I next tried the same exercise but in the opposite direction. In the Notecard LoRa Quickstart guide there is a link to the documentation to accomplish this. Here too, each step is described, along with the code to accomplish it, plus the “Try it” and “Copy” buttons. This time, things did not work at all, no matter what I tried. After reporting this to Blues Wireless, they responded by telling me that one must also define a template for incoming Notes. While this template step was included in the Quickstart guide for outgoing notes, it was missing in the section describing how to receive incoming notes from Notehub. I reported this but it wasn’t corrected in the documentation, when I last checked.
Routes
As I mentioned earlier in the column, the Notehub doesn’t actively do anything with the Notes that it receives from a Notecard, nor does it initiate the transmission of Notes out to the remote Notecards on its own. It does, however, store them for a while.
To do something useful with the data, you must make use of the Routes feature of Notehub. Routes are the equivalent of Integrations in the Particle IoT framework (which I have used in past projects). Table 2 shows the available Routes which the Blues Notecard/Notehub currently support. Blues provides a tutorial for most of the routes shown in this table.
This is a list of the Cloud service providers that Blues directly supports. There are Tutorials supplied to show you how to implement most of these.
Routes are intimately connected with Blues’ monetization model. Notehub operates under a “pay-as-you-go” model with Consumption Credits. A Consumption Credit is only used upon event egress such as when events are routed out of Notehub. All Notehub accounts are automatically topped-up to 5,000 free Consumption Credits every month, but there are subscriptions available to scale this up.
Not being a commercial user, I don’t have accounts on any of the commercial cloud services listed in Table 2. I have, however, used Webhooks in the past, and they are supported by Routes. This method is described in the “Routing Data to the Cloud” section, in the “General HTTP/HTTPS Route Tutorial”. This tutorial makes use of the “webhook.site” cloud service, which is free to use for limited applications. That site assigns the user a unique URL and email address, as soon as you access their webpage. When you create a route, you just paste this URL into the URL window and add the name of the Note that you want routed (as described in the tutorial). Once you have your Notecard running and sending notes (the same notes that you defined in the Route), if you navigate to the “webhooks.site” webpage, you’ll see these notes arriving as Posts (with timestamps). If you click on one of these posts, you’ll see all of the information that Notehub has forwarded- including the newly arrived data in that Note, originating from your Notecard. Figure 8 shows a screen capture of the “webhooks.site” dashboard, showing the data that was received from Notehub. Note that it includes the transmitting device’s ID #, the time (epoch time), the Note name “sensors.qo” and the 4 variables, including temperature and voltage readings (as defined by the template). Also, if you go back to the Notehub dashboard, all the events that have been forwarded to this web-hook site will have a green diamond with a check mark attached to them, to show that they have been dispatched.
This is what you’ll see on the “webhook.site” website when webhook triggers are received from Notehub. Here, I have clicked on one of the Posts to the left, revealing all the data that Notehub sent for that one event.
The free “webhook.sites” service can be upgraded to perform other functions. But, for the purposes of this tutorial, this site is just acting as a “proof of concept”- to show that Notehub is actually triggering a webhook URL and sending out the requested Note information.
As part of my home automation setup, I have designed water leak detector modules which send alerts to my Amazon Echo smart speakers. The Amazon Alexa service can’t be accessed by just any random IoT device. Instead, the Alexa service will only accept notifications from known, accredited sources. Therefore, I use a webhook service to act as the “middle-man”. That webhook service is accredited with Amazon Alexa. When I trigger the webhook assigned to my account by that webhook service provider, it passes along a specific notification message to my Amazon account. That notification is then announced with a spoken message from my Echo smart speakers. A similar scheme could be implemented for the Notecard, by using the web-hook method and substituting the “webhook.site” URL mentioned above, with the URL provided by my web-hook service provider.
I don’t pretend to be knowledgeable on any of the cloud service providers that Notehub supports, shown in Table 2. However, Blues provides similar tutorials for most of those services, and I assume they are detailed enough to allow individuals with experience in those cloud services to integrate them with Notehub successfully.
Recovering a “Bricked” Notecard
To finish off my review, I thought I’d mention what might be considered “a bad note”. Hopefully, you’re not going to “brick” your Notecard, as there is no reason for you to try downloading code to it. However, the Notecard firmware can be updated over the air (OTA) and something could go wrong if a wrong version of the firmware were sent to the Notecard, by mistake. Given the low-speed nature of LoRaWAN, I doubt that the Notecard LoRa’s firmware can be updated in this manner, but I’m not certain about that.
In any case, the Notecard LoRa’s MCU is an STM32WLE5 Arm device, which contains a built-in USB bootloader in ROM (which can’t be erased or modified). To enter this boot mode, you plug the Notecard into a Notecarrier board and connect the N_BOOT pin to N_VIO. Then power up the Notecard LoRa/Notecarrier. Using the Blues In-Browser Terminal, you type in “firmware install latest”. Alternately, you can issue the command “firmware list” and check for the version you wish to load. Then, use the firmware install command, followed by the version name. After this process completes and the Notecard re-starts, issue the JSON command:
{“req”:”card.version”}
It will display the currently loaded firmware version. There are a few other ways of reloading the firmware, which can also be found at the URL[1].
Blues recommend that you don’t try to update the firmware using STMicroelectronic’s own STMCubeProgrammer (part of the STM32 SDK package). This risks erasing portions of the flash memory that Blues has programmed with important configuration data.
Conclusions
I was generally quite pleased with the operation of the Notecard LoRa module and the Wisgate RAK7268V2 gateway. It was certainly a time-saver having the gateway pre-authorized on the Blues cloud infrastructure. All Notecard modules use an M.2 edge connector, which is common in the industry, and are small and pin compatible. I requested the Notecarrier F carrier board, which is their most sophisticated carrier board. I would recommend it for early development purposes, if you are familiar with Feather MCUs. Using it, you don’t have to worry about which serial or I2C port to hook up, or whether your MCU uses the same logic levels as the Notecard.
I must admit that I didn’t take the time to drive around in my car with a Notecard LoRa, to check out what its range was. The range of RF communications in the 915 MHz band is dependent upon terrain, and line-of-sight distances are often quoted. Any results I might have gotten would have depended upon what floor in my house the Wisgate gateway (for in-door use only) was situated. My house is surrounded by large trees, so there was no way to measure under line-of-sight conditions. The Notecard LoRa’s STM32WLE5 MCU is capable of transmitting at 20 dBm (100 mW) and if the gateway’s RF sensitivity, plus any gain due to its antenna were known, one could derive a link budget and make distance estimates.
Overall, I found the documentation to be excellent. There are numerous tutorials and Quickstart guides. Integrated into the Quickstart guides is an In-Browser Terminal, which in conjunction with the “TRY IT” and “COPY” buttons, make it easy to do early-stage testing of the Notecard.
To be fair-minded, I must add that I did encounter some significant errors/omissions in the documentation. Because of the high overall quality and user-friendliness of this documentation, I usually accepted that information at face value, and therefore got led astray a few times. I have reported these issues to Blues support, and hopefully they will be corrected before any readers encounter these documents.
Thanks! We would like to express our appreciation for the assistance provided by Tre Clay in making this review possible.
REFERENCES
[1] https://dev.blues.io/notecard/notecard-firmware-updates/#dfu-with-in-browser-terminal
RESOURCES
Notecard Lora: Blues Wireless | blues.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • SEPTEMBER 2024 #410 – Get a PDF of the issue
Sponsor this Article
Brian Millier runs Computer Interface Consultants. He was an instrumentation engineer in the Department of Chemistry at Dalhousie University (Halifax, NS, Canada) for 29 years.
