I’ve been following Mioty for a long time now, but until recently, it was more of a vaporware in terms of testability than a deployable technology. I won’t go back over the nauseating marketing communication led by those promoting this technology, as I’ve already touched on that in several articles.

The good news is that for the past few months, it has been possible to deploy it thanks to the excellent Miromico solution, a Miro Edge gateway, which is essentially an indoor LoRaWAN gateway with an integrated Mioty receiver in place of the LoRa concentrator.

Before diving into the details of Mioty, to define it briefly: it is a radio solution very close to LR-FHSS, which breaks down a message into small packets that are widely transmitted across the spectrum with redundancy, creating both temporal and frequency spreading. This reduces the risk of collision, increases capacity, and improves performance at the edge of the coverage area (which makes sense, especially in satellite communication where LR-FHSS is used).

Mioty One O One

Mioty is a communication solution that uses a method called Telegram Splitting Multiple Access (TSMA). The principle involves splitting frames into small messages (telegram splitting), sending these small messages at slightly spaced intervals and using different frequencies while tripling the information. The goal is to minimize the impact of interference that can occur at any given moment on a specific frequency. By tripling the transmitted data at another time on another frequency, it can be reconstructed upon reception. Of course, this works as long as the duration and spread of interference across the spectrum don’t cause the loss of all copies. Each telegram split uses transmission on a very narrow frequency (Ultra Narrow Band) ; It’s names TS-UNB for Telegram Splitting Ultra Narrow Band). The TS-UNB technology is pattented as a consequence, unidirectional device pays 0.32 euro each, bidirectional 0.80 euro each and gateway 8 euro each ; this can be reduced by committed volumes above 200k.

One message transmission use 25 different carriers frequencies with a possible calculated offset from 3 to 11 channel spacing slots (based on clock precision) to increase the time-frequency diversity, expending to up to 35 different channels. The minimum size for a frame is 24 splits, corresponding to 186 bits of data, of which 160 bits are payload (20 bytes), with longer frames being possible. Since there are 25 (+11) different frequency slots, the minimum frame, called the core frame, will use different frequencies for each split. Larger frames will therefore reuse the frequencies. The order of frequency usage is defined in two groups, each consisting of 8 different frequency usage patterns. The second group is used for transmission including a repeat. A third group with a single pattern is used for lower latency transfers. There are two symbol transmission rates: 2380 and 396 symbols per second. Each of the splits are separated this a variable duration part of the transmission pattern in between 330ms to 595ms. The transmission time on air for the core frame can be 363ms at standard speed and 2.18s at low speed ; with the split intervals; the transmission total time is about 8.5s at standard speed and 22.2s at low speed. The special low latency pattern allows faster transmissions (800ms & 4.6s)

Since each split does not allow identification of which frame it belongs to, the reception of uplinks by the concentrator will require identifying patterns to reassociate the splits with one another. Thus, it is the frequency and time distance between two or more splits that will enable a unique identification of the pattern, allowing the identification of all splits from the same communication.

One channel bandwidth at 2,38K symbol /s requires 2.4KHz. The channel spreading is configurable between 400Hz in Narrow mode, 2.38KHz in Standard mode, and 28.5KHz in Wide mode; leading to a spectral occupancy of 12KHz, 60KHz, and 688KHz, respectively. With the frequency offset calculation, 23.8KHz of bandwidth is to consider. This requires a total bandwidth of 25KHz, 100KHz, and 725KHz, respectively. If you want to use Mioty for downlinks it is recommended to use twice of this. Also you can have a single or dual band mode. In dual band mode, two bandwidth like these one will be use alternatively.

In Wide mode, a frequency offset, random but constant for a given device (if I understand well, spec is fuzzy about this) is applied to use the whole spectrum.

The downlink frequency and sequence is directly derivative from the uplink frequency and header CRC bits, a single device does not need to listen for the whole spectrum but it can receive and decode the response following this predefined time & frequency sequence.

There are, in fact, regional parameters that define standard frequencies for network deployments. In Europe, there are three profiles:

• EU0 offers two 100KHz channels in Standard mode with communication at 2380.371 symbols/s, one for uplink centered on 868.18 MHz and the other for downlink centered on 869.575 MHz.
• EU1, with the same bandwidth and data rate characteristics, uses two uplink channels at 868.180 MHz and 868.080 MHz (both within the same band at 1% duty cycle) and two downlink channels at 869.575 MHz and 869.475 MHz.
• EU2 is a Wide band mode that occupies 1.5 MHz of bandwidth with two channels, 750 KHz each, around 867.625 MHz and 866.911 MHz.

In the USA, the Wide mode is the only profile used. The fact that the carriers are spaced 1.46 MHz apart and the long spacing between hops allows compliance with FCC regulations, which rely on channel hopping. Uplink and downlink use the same frequencies, with two channels centered on 916.357 MHz and 915.643 MHz.

Each of the split contains 2x12bits of data and 12 pilots bits with a predefined pattern used for sync / decoding.

However, when taking into account the pilot sequence of each small message and the information redundancy, it results in a raw communication rate of 529bps in standard mode (not including frame headers and CRC).

At the lowest level, the data is transmitted with an overhead of 26 bits (corresponding to the 186-160 bits mentioned earlier). At this stage, there is no addressing or signature, which are included at the MAC level within the payload. Like for LoRa, the bit stream is transformed before being transmitted, we have channel coding, Interleaving, whitening to maximize the ability to reconstruct message on collision.

The spits are transmitted with MSK or GMSK modulation (Gaussian) Minimum Shift Keying, basically, the frequency differ of a 0 vs a 1. This modulation is really efficient in term of spectral occupancy.

The coherent decoding of MSK signals at the device level is not straightforward, and not all transceivers support it. As a result, reception is a challenge, and not all hardware can handle it. Some may allow it but with a significant loss of sensitivity.

Mioty device uses IEEE standardized EUI64 address as unique identifier ; but like in LoRaWan, it can use a session address given by a network and reusable across devices with a 2 bytes size, without downlink you need to pre-register it and network migration can be a problem. But in reality, this concept of an address mainly serves to prevent confusion and slightly speed up the network server’s search, as the identification of a device is done by the frame’s signature and not by a unique or short address, which is shared and therefore not very identifying.

Payload encryption is based one AES-128-CTR (as LoRaWan or Sigfox when enable) and a pre-shared network key (static). The message Signature is also based on the same PSK and AES-128-CBC based algorithm

Due to the minimum core frame size, the user payload size is between 3 to10 Bytes. So the core frame can carry up to 10 Bytes of application data. Mac header defines the format of the frame, address size, MPF presence, ack …

MPDUCNT is the fCnt or SeqId field in other LPWAN, its is incremented on every transmission, here we have a 24 bits counter.

The protocol proposes some ADR like solution to optimize the transmission power in regard of the budget link.

There is one particularly surprising thing I discovered while implementing my first devices: Mioty gateways are not passthrough, unlike LoRaWan gateways or Sigfox basestations. For a reason I don’t yet fully understand, functionally, they must know the security information of the devices in order to relay them. This is done through a Join-type procedure, in which it seems that the Mioty Network Server transmits the signature/encryption key to the basestation. This implies that this secret, which should be protected above all, is stored in the basestations, spread across the field, and therefore, by definition, not secured in the long term. If my understanding is correct, this approach seems to me totally unacceptable in 2024, especially if the network is operated by a third party. In the case of devices without downlink (class Z), the commissioning is done manually from the MNS (Service Center) to the basestations.”

This also seems to have other consequences: how can a national network with millions of devices be deployed? Each device would need to be commissioned in all the gateways it might encounter during movement, which neither an operator nor a service provider can fully anticipate. Even at a local scale, replacing a gateway would require redeploying the information on the replacement equipment. Not to mention that during a dynamic deployment following a join procedure, it seems necessary to commission the information on a group of gateways; otherwise, the network would lack redundancy, which is a critical factor for the proper functioning of an LPWAN. Honestly, I don’t understand this part, nor how they arrived at this approach, and I really hope I have misunderstood this functionality.

Miromico Mioty Gateway

First of all, thank you to Miromico for allowing me to conduct these field tests on Mioty technology. I’m fortunate to be able to test their Miro EdgeCard Mioty, deployed in the MiroEdge Gateway, which is available in an indoor version (tested), as well as in an outdoor and dual-mode version (LoRaWAN/Mioty) with or without LTE. The kit came with an environmental sensor.

In terms of design, I find a lot of similarities between these gateways and the RAK Wireless range, which I really appreciate.

Hardware review

The design is classical for an indoor LPWan gateway, you see a Processor module running the protocols and external communications, ACSIP module here. It runs openwrt.

there are two PCIe slot to add communication board. The first one, empty is for LTE extension but we could imagine it could also support a LoRaWan concentrator for dual mode. The second one, populated, own the Mioty receiver. It’s a SDR solution to record a wide radio band and decode the telegrams. It’s also an emitter capable of +27dBm for the downlink communications. The receiver sensitivity is -136dBm (as a comparison, the LoRaWan concentrator have a -139..-142dBm sensitivity). It’s capable to decode about 40 telegram / second.

The gateway support EU0 and EU1 so it is able to receive 2x100kHz channels. It may be able to support the new regional settings for India (866MHz) and 433MHz in a new revision soon.

The PCIe board itself is interesting to detail:

The architecture is the following one: we have a strong system for telegram decoding from the radio flow. It’s capable to process 3.5M telegram a day (eq 40/s), the signal is captured by a CC1260 after LNA ; transmission is made by the same system. The solution is half duplex even when using 2 different channels for RX and TX. This is a classical situation in LPWAN, network coverage redundancy fix this.

CC1260 is a key component for the reception, it’s a sub GHz RF I/Q Front-End for SDR, meaning it transforms radio waves into I/Q a software solution can process to decode digital communication. It can be used from 10KHz bandwidth up to 2MHz bandwidth with lower sensitivity and have 30Hz frequency step.

GATeWAY INVESTIGATION

On the configuration side, there isn’t much to do on the gateway. The only parameter is the IP address of a network server (called BSSC) where the data will be sent. I don’t know of any open-source network server to deploy myself at the moment, so I will use the Loriot solution, which is configured by default. The Gateway have a configuration page where login is root and password miroxxxxxx where xxxxxx are les last 6 lower case digit of the mac address writen on the gateway sticker. SSH access use the same credentials.

It should be understood that Miromico’s PCIe concentrator is a fully autonomous system running its own operating system, independently forwarding the data received from the Mioty network to the Network Server. The host ultimately only serves to route this information and sees the PCIe card as an Ethernet card over USB, essentially as a host on a local network. This approach is quite clever, as it allows the concentrator to be installed on any system without requiring specific software deployment. It embeds all the intelligence needed for configuration and debugging. Moreover, it includes very advanced options, which are highly useful for developers of connected devices.

You can access the PCIe mioty board dashboard through ssh. In fact, the PCIe board is connected to the gateway with a network interface over usb and accessible on 172.30.1.2 from the gateway. By tunnelling this IP and port 8080 you can access the dashboard on your computer (ssh uses same password as ui):

$ ssh  -L 6080:172.30.1.2:8080 root@gateway_ip_address

Then you can access the (really cool) Mioty dashboard, with live freq analysis and waterfall… love it!

The started kit is fully preset, the gateway is registered on loriot network where the device has been pre-configured. You can access the Loriot platform with the precommissioned credentials. The platform does not provide much information yet regarding gateway management; the dashboard allows for viewing its status with some history, and that’s about it. Device management is standard for a network server, allowing data visualization and integration. In an upcoming article, we will explore this in more detail by adding a custom device.

The starter kit comes fully registered, so you can also login the micromico dashboard and watch the data. The login credential are derivated from the gateway mac. It basically prove that it’s working but nothing more exciting.

Now, if you want to really have fun with the devkit your need to register a owned device you can really use.

Creating a mioty device

I’ve started to investigate a way to make a device I have a full control on. But… what a surprise! Different solutions are available:

• RadioCraft module, ready to go, like a modem. I ordered some of them for having a test but module costs $20 on digikey. That’s an option I was expecting to integrate the license fee (see above), but apparently not !! Once reaceived, I’ve not been able to acces the User Manual to access the AT commands, supports helped me. It’s based on CC1312. The AT command is not easy to use due to some special, unusual, characters used in the serial communication. This solution is suporting uplink & downlink.
• STM32WL, this is the solution used in the device provided by miromico and even if the STM32WL is natively able to support (G)MSK, there is no open-source implementation, I just found the Stackforce implementation under license with just an usual and boring “get in touch” call to action. STL32WL seems to not support downlinks (to be confirmed).
• On Github, you can find an mioty arduino implementation with RFM69W as a transceiver with Atmega328p. This does not support downlinks.
• We also have the paul-adam STM32+RFM69W implementation. RFM69W is a radio transceiver not much usual, costing 12€ on rs-online or 2,5€ on aliexpress. This does not support downlinks
• Some other module exist, Weptech one is based on STM32L+S2LP ; swissphone based on unknown solution ; Waptech other one based on CC1310. You can’t really buy these one without deep sales contact.

As a result, I was not able to quickly develop a device due to the lack of appropriate equipment at hand. After one week, I now have what is needed to build a device, but this will be the subject of a future article.

To be continued

Alright, I would have liked to go a bit further, but there is no quick or short-term solution to really get hands-on and show you more about MIOTY. This article is already quite long for an introduction, so I’ll come back to it soon with a hands-on session once I’ve received some equipment. In the meantime, I hope you’ve learned a lot about MIOTY, and that for once, we’ve moved away from the usual painful marketing communication.

Personally, I find the technology valuable, and I especially see a lot of work around the alliance to organize a more open ecosystem, more accessible to makers and small design firms. Without that, adoption will be really difficult. We’re mainly talking about capacity, which isn’t always easy and real differentiator, in practice, especially with 2x100kHz, and they set the entry bar quite high with the licensing system and the difficult access to tech components. This seems to indicate a market target limited to large volumes, very vertical. Why not, but why? After all, those who can do more should be able to do less.

What I still haven’t been able to identify is the ‘sweet spot’ for Mioty. I’ve tested its capacity on a few models, and this is still ongoing and requires debugging, so I’ll discuss it later. For now, however, I find it much less scalable than Sigfox or LoRaWAN, at least for EU0 and EU1 modes. In EU2 mode, it would probably be different, but the equipment for deploying EU2 does not seem to be available yet. It is not cheaper, particularly given the complexity of the downlink and device licenses. This is the point I intend to explore further because it seems to me that each different technology must have a somewhat specific segment that allows it to find its market. To be continued.

You can also take a look at my Mioty video MooC on Youtube if you understand French.