In my previous article, I shared my first steps as a Mioty user. Today, I want to dive into the creation of devices using this technology. It took me some time to publish this follow-up, as I encountered a few challenges—primarily related to an ecosystem that, unfortunately, remains stubbornly inaccessible.

In this initial post, I’ll share my experience with a ready-to-use module from Radiocraft. Future articles will explore other solutions… depending on my available time, of course. As you can probably tell, I haven’t been posting much lately, as I’ve been busy with other projects. Stay tuned!

Radiocraft Module MIOTY1

The Radiocraft module is the simplest option to get started, even though its AT interface requires a bit more effort than usual. It costs between 16€ and 20€ and is available on Digikey. The documentation is a bit harder to obtain, but I will provide you with the main information needed to get started. This solution has the advantage of allowing uplinks and downlinks without worrying about the stack, which will generally allow you to take your first steps with the technology quickly.

That is why I will start with this one. Moreover, it is quite simple to make a breakout board to interface it with an FTDI or a serial port for an Arduino.

Now, the objective is to control the module with an Arduino, as this one will not support the default 115200 bps, I firstly need to use my FTDI cable and switch to 9600bps

AT+IPR=9600

Now, it’s possible to start transmitting messages. Before I share the code I used, you should know that I encountered issues with reception. At first, my messages were received but not decoded. This is a good opportunity to talk about the debug mode of the MiroMico concentrator. To enable it, you need to connect to the concentrator itself (not the gateway); see my article on the MiroMico gateway for more information on this. Then, go to the debug tab and enable trace level 5 for the RX section.

Once this is done, all that’s left is to check the main screen (Dashboard), and you will find much more information about the received frames. Here is a frame received without any issues.

As a result, I found something I still can’t explain: for a device to be transmitted to the Network Server, it basically has to be registered in the gateway. Honestly, I don’t really understand the logic behind this. So, in the Loriot interface, not only you need to register the device, but once that’s done, you have to go into the object (on Loriot), choose Attachment, select your gateway, and click on Propagate Attachment. That way the gateway knows your device and accepts it.

Now, I can share my stupid Arduino transmit code

#include <SoftwareSerial.h>
SoftwareSerial radiocraft(4, 3); // RX = D3, TX = D4
void setup() {

  Serial.begin(9600);
  while (!Serial);

  Serial.println("Go");
  radiocraft.begin(9600);

  delay(1000);

  // print the module information
  sendAndPrintRadiocraftCommand("ATI\r\n",1000);

  // print the IEEE64 addres
  sendAndPrintRadiocraftCommand("AT-MEUI?\r\n",1000);

  // print the short address curently setuped
  sendAndPrintRadiocraftCommand("AT-MSAD?\r\n",1000);

  // set mode 2x100Khz EU1
  sendAndPrintRadiocraftCommand("AT-UP=1\r\n",2000);

  // set Standard transmission mode
  sendAndPrintRadiocraftCommand("AT-UM=0\r\n",2000);

  // Detach from network, required for setting up MNWK
  sendAndPrintRadiocraftCommand("AT-MDLO\r\n",2000);
  
  // Setup a network key
  sendAndPrintRadiocraftCommand("AT-MNWK=16\t000102030405060708090A0B0C0D0E0F\x1a\r\n",1000);

  // Attach locally to network
  sendAndPrintRadiocraftCommand("AT-MALO\r\n",2000);
}

void sendAndPrintRadiocraftCommand(const char * cmd, long tmout) {
   Serial.print(cmd);
   radiocraft.print(cmd);
   readAndPrintRadiocraftOutput(tmout);
}

// read output with a minimal wait time
void readAndPrintRadiocraftOutput(long tmout) {
  long t = millis();
  while ( (millis() - t) < tmout) {
    long k = millis(); 
    while(!radiocraft.available() && (millis() - k) < 1000);
    while(radiocraft.available() && (millis() - k) < 3000 ) {
      int c = radiocraft.read();
      Serial.write(c);
      delay(10);
    }
  }
  Serial.flush();
}


void loop() {
  sendAndPrintRadiocraftCommand("AT-U=2\t9191\x1a\r\n",10000);
  delay(10000);
}

This gives good results:

We can also try downlink by simply replacing the command in the loop:

void loop() {
  sendAndPrintRadiocraftCommand("AT-B=2\t9191\x1a\r\n",10000);
  delay(10000);
}

Then you can enqueu a downlink value in the Loriot Network Server, it is latter received by the device.

Here you see the 9292 value coming from the network. It has been received following the transmisison 1 (MPCT). The timing shows a total latency about 20 seconds for the downlink recepetion from the uplink request. It makes sense as the transmission itself (uplink as downlink) is more than 8 seconds.

It’s also possible to try the low-latency mode by changing it in the setup, you can see how it make a big difference in term to communication time (to be precise, the Normal communication here comes from a different device with a logger payload but it’s not really significative)

Switch to Low Latency mode requires the following change:

  // set Low Latency transmission mode
  sendAndPrintRadiocraftCommand("AT-UM=2\r\n",2000);

We can also have a look at the Repeat mode, in this mode we see the split repeated a few ms after the initial one. The pattern is also selected in group 2 (group of patterns dedicated to repeats) instead of group 1 – this can be seen in the mioty gateway RX-PHY-Message trace.

Switch that mode the following way:

  // set Repeat transmission mode
  sendAndPrintRadiocraftCommand("AT-UM=1\r\n",2000);

Dynamic attachement

My next attempt was to implement dynamic attachment, somewhat akin to a join request in LoRaWAN. This would allow a device to switch between networks by assigning it a specific session address. Unfortunately, I couldn’t complete this test because dynamic attachment with a Loriot server causes the gateway to reboot, which disrupts the timing needed to send a proper response.

This was quite frustrating. Upon contacting support, I was informed that a patch might be available—but only if I signed an NDA. Essentially, this would prevent me from sharing these experiences with you. As a result, I can’t confirm whether a fix exists or if dynamic attachment works reliably with Mioty.

This situation highlights a recurring issue I find disappointing with this technology: its lack of openness and transparency. For a system that has so much potential, these limitations are a significant drawback.