The Kineis IoT solution is an IoT network based on satellite’s communications. Thank to it, a device can communicate from any point of Earth with a single technology. Kineis is using an existing fleet of Argos satellites launched during the last 40 years and is already commercially available. This fleet will grow fast in the next two years to offer a communication window up to 4 times per hour.

In this blog post, I’m going to detail my first experience with Kineis for sending frames through the satellites of the fleet. I’ve been using a KIM Arduino Devkit. The on-boarding is quite fast, let’s see this!

KIM1 Arduino Devkit presentation

The devkit is composed by a hat circuit for Arduino, you can use it with an Arduino UNO or a SMT32 board compatible with Arduino. You can also use it with a serial cable connected to a computer.

This board just have the KIM (KIneis Module) on it (plus extra chip but basically it is just that). To be honest, this board is a bit complex even if the number of components is really reduced, it is the side effect of a multi-purposed board. What I mean is you have many jumpers to be modified depending on the mode you choose for using it. As an example to use it with a serial cable connected to a computer, you also need to connect it over USB to get it powered. This makes sense, particularly when transmitting at 500mW to 1W but it is a bit more complex than usual IoT devkit. That’s the direct consequence of high power peaks related to power transmission and legacy USB limitations.

The main advantage of this is to get in a single board a solution you can use with many different ecosystems: Arduino, Nucleo / STM32, computer standalone.I hope the next version will come with an integrated FTDI chip to simplify the use of it and an USB-C that can support more than 15W since USB 3.1. Ok, they are details. Once you have read the documentation carefully you are ready to set it up.

The KIM1 module is a classical Radio module, the MCU (Arduino or STM32) will use AT commands set to interact with it. It will communicate over an UART line to send text commands for the different setup operations and to request sending messages to the Kineis network.

The integration is easy such a way. Kineis also distributes libraries with the kit to make it simpler. Cool !

The programming environment is Arduino, nothing more simple to get started.

Using the computer application

The best starting point is to use the computer application. This one developed in Java works well on MACOS as on Windows and Linux. Before starting to use it, we need to configure the board and connect it to the computer. Then it needs to be exposed outdoor and this is sometime the tricky part … Long USB cables can really help !! I’ve also made some tests indoor behind my Velux and get a working setting for testing purpose, so you can try behind a window for getting started.

Then we need to run the application. This application simply generate the AT commands typing with a graphical interface. This is basic and we would like to have a prediction of the satellites pass directly in it. For real we are just going to use it for the first step to understand the parameters and so on, so the basic of this software is good enough for this.

You need at first to select the serial port where the board is attached and connect. After this, you need to READ all the parameters from the board to identify the settings you need to make. We basically have the following information:

• ID, corresponds to the transmission ID, it is a different one than the subscription’s ID. It means you will receive your data on a different ID. This is a bit complex to manage as a human but it has some advantages like to reuse the transmission IDs in the future. (The ID is 28bits, it’s not really long).
• BAND, this selects the frequency band to be used. There are 8 bands between 399.9Mhz and 401.7MHz. We usually use the Band B1. In this band it is recommended to select a frequency out of the Argos 1 central part as this zone have all the historical devices. The frequency selection is made with the next parameter.
• FREQ OFFSET, this indicate the Transmission frequency related to the Band origin with a step of 100 Hz. So it is basically the radio channel in the band. 0 is 401.62MHz ; 100 is 401.63MHz. to avoid being in the Argos 1 radio band, it is better to select values from 0 to 200 and 400 to 600. There is no specific “channel” recommendation for the dev kits in the previously given values. Just to select one of them and to keep it for getting benefit of native positioning service based on Doppler effect (see below).
• POWER, this allows to select the transmission power from 250mW to 1W.
• PAYLOAD is the message to transmit, it is an hexadecimal string with a minimum of 3 bytes. Additional blocks are 4 bytes each. The maximum is 31 bytes. 0 padding is added to complete block or shorter messages.

Once everything is setup, you can start firing a message…. but to have a chance of receiving it, you need to have a satellite around!!

When to Fire a message?

There are different ways to find the right time to fire a message with Kineis, here we are looking at the manual way as it is the purpose of the step. So the first way is to get the pass prediction from the Kineis dashboard, indicating your location, so you get a table of schedules you can export as a CSV and import into the Kineis application.

Honestly, this tool is not really easy to read, it is UTC time and even if you have UTC time on top of the application it’s not really convenient, the next pass is always yellow even when you are between two of them. I think it could be color changing depends on where you are in the slot for a better readability, eventually get a countdown for the next transmissions. At the end, it is better than nothing.

As you can see, I had many communications slot during that day, just had a big break between 12:00 and 15:00. As explained previously, the fleet is composed by 8 satellites and 25 more are coming.

As this panel did not satisfied me to understand where the satellites are, I’ve used an smartphone application “Satellite Tracker”. You can select the satellites you want to track, and you get the information related to your position.

It helped me to get a better understanding of the table above and understand if the satellite was more on the EAST or WEST side as the sky view from my roof is better from the EAST than from WEST. That said, my first message has been capture on the WEST side so… it worked well. This information of azimuth can be found on ArgosWeb if you don’t want to use a third party tool.

You can also search for each of the different satellite on stuffin.space website. The list of satellites can be found in the documentation provided or on wikipedia. “A” is Angel, “Mx” are METOP-x, Nx are NOAA-yy.

Honestly, that’s for me the beauty of such IoT solution, looking to the sky and searching for these mobile gateways turning around to capture our messages. So much fun!

So basically, with all these information we, now, have a good idea about when to fire messages and get the network able to capture it. We can look to the rest of the application to send the first messages.

Fire first messages

From the application we have different ways to fire messages: We can do manual transmissions by clicking on “One shot transmit payload“. We can also automate transmissions.

• By entering a Tr period we are going to send a message on every time period.
• By enabling Tr periodic Transmit this will be enable
• By enabling Use of prediction pass segment, the system will only schedule transmission at time period rate during the pass segment and sleep rest of the time.
• By enabling Tr transmit time jitter, the systems add a random time in transmission period (I assume, it should avoid repeating collisions with other systems)

If you want to get your device positioned, with a high accuracy, you need to have, at least, 4 frames received during a single pass, so you need to setup your repetition period for this. Less communications will reduce the precision.

Getting your first message

Once fired, your message will be reported to the Kineis backend. This backend will be soon upgraded to a new version more IoT’s industry oriented. The message is not immediately displayed in the dashboard. This will be improved with the next Kineis fleet. The message needs to be transmitted to a base station from the satellite. This is currently completed at the end of the satellite pass over a ground station. This is particularly affecting the devices located in the middle of nowhere like desert or ocean. Before getting message from them, you need to unload messages to a ground station. This point is also important when selecting an IoT satellite solution: make sure they have a strong ground network. Kineis have one.

This is a difference with terrestrial networks. Basically this is usually not critical as your devices are commonly deployed on ground, not so far from civilization and communicates on regular basis, you don’t really need real-time communication in most of the use-cases. But when you are prototyping, testing the technology, it makes a difference, it can be a bit frustrating today to wait for communicating and crossing finger to see your data appearing in the next minutes. You need to remind it will change in the next two years with the larger fleet, larger base stations and streamed communications between satellites and ground.

It is also possible to access the message payload for platform integration. Bellow you see an example of messages (you have different type of messages): one for the transmitted raw data and one for the computed position:

RAW Message
{
   "TYPE":"DEVICE_RAW",
   "MODE":"BASIC",
   "VERSION":1,
   "DATA":   [{"DEVICE_ID":"206089",
   "MSG_DATE":"2021-06-01T20:07:30.518Z",
   "MSG_ID":21130XXX,
   "RAW_DATA":"010000"}]
}

DOP Message
{
  "TYPE":"DEVICE_DOP",
  "MODE":"BASIC",
  "VERSION":1,
  "DATA": [{"DEVICE_ID":"20XXXX",
    "LOC_DATE":"2021-06-01T17:30:24.655Z",
    "LOC_ID":144519964,
    "LONG":3.12602,
    "LAT":45.78583,
    "ALT":385.0,
    "LOC_CLASS":"B",
    "MSG_IDS":[21122XXXX] }]
}

Computed position

The system can compute a high accuracy position from 4 messages received in a single satellite pass; to be efficient, these different messages need to come from different phases of the satellite pass:

The doppler effect is used to compute the device location by using the frequency change to detect the device position. Basically you can compute the center frequency and by identifying for each of the received messages the frequency variation and knowing the satellite position and speed, you can deduct where the device needs to be to conduct such results. When the messages used for the computation are spread all along the Doppler curve shows above the location can be really precise.

You can see that the precision is really good, It has been a LOC_CLASS 2 position, meaning the estimated error for this computed position is below 500 meters. Such a position is precise enough to identify an industrial location, a customer… for many business use-cases.

Pilot the KIM module with and Arduino

Now, it is time to make a standalone system running on Arduino. Let’s start by configuring the board differently. For making this test, I’ve used an Arduino Leonardo I had in stock. In my point of view the dev-kit could contain an STM32 board or an Arduino board to be immediately ready for use. We currently see solution’s dev kit including some boards and sensor as a ready to go dev-kit. I have in mind what Rak Wireless do with Helium and this is quite interesting.

Dev-Kit configuration with Arduino

As you can see, the KIM hat perfectly fit with the Leonardo board. The jumper configuration makes the module power to be controlled by one of the Arduino GPIO. So when powering up the Arduino, the KIM power led will stay off. No worry! In this setting, power supply comes from USB cable, at least during the programming phase. Then I’ll be able to use a power bank in place of the computed USB source. In the previous test I’ve seen my USB port was able to supply power for 750mW communication so I should be able to make it working like this. Eventually, if your USB port is not able to deliver the right supply, you can go with 250mW transmission during the test phase.

Arduino Environment SETUP

The Kineis KIM Arduino library is directly accessible as a standard library. You need to go to library manager and search for KIM and install it.

Once done, in the examples, you can find one for KIM module. This is a good way to start.

When using a Leonardo board, currently you need to tune the library as the SoftSerial is using a pin not compatible for this board. Fortunately, the Leonardo Hardware Serial can be used, that’s why I like Leonardo more than UNO. So, if using Leonardo, add in the library file Kim.h the following lines:

// Edit the following lines to add other boards :
#elif defined(ARDUINO_AVR_LEONARDO)
  #define ON_OFF_KIM_PIN 	4
  #define RX_KIM 			0
  #define TX_KIM 			1
  #define softSerial 		false
...

With Leonardo, you will also need to setup STM32 as UART Source to have it working.

Then we have a code as simple as the following one to create a prototype of dumb tracker, just sending a frame on every 90s.

#include "KIM.h"

#define INTERVAL_MS     90000
const char data[] = "0001";
KIM kim(&Serial1);

void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);
  uint32_t w = 0; while (!Serial && w < 2000) { w = millis(); }
  Serial.print("Kim Setup...");
  
  if( ! kim.check() ) {
    Serial.println("failed");
    while(1);
  }    
  kim.set_BAND("B1",2);  // strange way to integrate,
  kim.set_FRQ("100", 3); // use string followed
  kim.set_PWR("750", 3); // by the string len
  kim.set_TCXOWU("5000", 4);
  Serial.println("success");
}

void loop() {
  kim.set_sleepMode(false);
  if(kim.send_data(data, sizeof(data)-1) == OK_KIM){
     Serial.println("Message sent");
  } else {
     Serial.println("Error");    
  }
  kim.set_sleepMode(true);
  delay(INTERVAL_MS);
}

Car Tracking experience

With this small program, I’ve made some test of vehicle positioning, from inside a car. I’ve positioned the device on the rear windshield of my vehicle.

On the top right where I had lots of points, I’ve keep the Class 1-2-3 positions, you can see the high level of precision, with in the center, the green point marking the real position.

On the bottom left you also have in green the real position and in blue the Class 3 points. In Red you can see the Class B positions.

Most of the position were class B in my test. It means most of the communications has been lost from the inside of the car, not allowing Kineis to compute a position with enough frame.

In another place, I’ve got only Class B positions during the 2 hours the vehicle has been parked. The result is less precise than what we could get on the previous map but it stays really good as the error is some hundreds of meter only. All the given points were in that area.

The impact of being inside the vehicle seems to be important. I’ve made tests at 500mW and 750mW with no big differences. I should try 1W but honestly I think the best way is more to use an outdoor antenna. So this is the next step of my experimentation.

Positions are provided with an estimated error and are categorized in classes to ease the user handling. Class 0 are low precision location with more than 1.5km estimated error. Class 3 are best in class location with less than 250m estimated error. Usually 4 messages are required in a single pass to obtain a high accuracy location. Less precise locations will also be generated with 3 messages identified with Class A and 1 or 2 messages identified by a Class B.

To get a better radio performance, I ordered an outdoor 400Mhz antenna to use on my vehicle. The characteristics of that antenna compared to the Kineis one:

The two antennas sounds really equivalent in terms of frequency adaptation. Both have a resonance frequency around 380Mhz. The SWR for the magnetic antenna at 400Mhz is 2,02:1. This is good with less than 20% loss.

The antenna can be placed outside the car with the cable going to the kit for being able to get communication while driving.

In the next test, I had a long trip to the south of France. I apparently did not had valid communication during the first hour (it’s possible we did not had sat pass). Then from Saint-Etienne to Hyeres, you can look to the position reported. The pink line is the real position, the yellow marker are corresponding to the reported position.

As you can see, it is easy to follow, in real time the vehicle progression. As I previously seen, when the device is moving, a certain level of error appears, particularly when some of the messages are lost during a single pass. The system is considering the previous position to compensate the missing messages received in a single pass to improve the accuracy. When the device is moving fast, like in a case of a vehicle, it adds a bias in the computation. On top of this, the vehicle speed have a direct impact on the Doppler effect computation, particularly when the vehicle direction changes between transmissions, impacting the accuracy. This is what you can see with the maker with 50-80km error on this map. The error is decreasing when I leaved the highways.

The next step is to optimize this, more messages per pass is a solution and a bit more power. During my next trips I did some new measurements:

In the following picture, you see the result of the position capture during my different trips, there are 4 trips Clermont – Orleans, then Orleans – Clermont, then Clermont – Alpes, then Alpes – Clermont. The large lines show the road and the points are the one reported by Kineis platform.

We can see, in most of the case a precision in tenth of kilometers in most of the case when moving. Once the vehicle is stopped, the position is getting really better, the final position where the device has been stopped during multiple satellite pass have a hundred of meter precision.

This is what we can see on the zoomed part of the above map. Here, the highest position class in green on top have a lower than 300m precision. The Blue one are about 2-3 km.

On the bottom part, the position is also really good, from 50 meters to 600 meters, even, with a low accuracy position class.

Basically, when the device is not moving, the position is refined during the different communication coming from the same place and the position is converging to the real position.

The speed of the vehicle have a direct impact on the accuracy in movement as illustrated by the end of the trip when the speed in mountains road, shown on the above picture) was really lower than previously on highways. The zenithal satellite passes ( max elevation >~70°) can also impact the accuracy due to fast variation in a shot time of the Doppler measurement observed by the satellite.

When going to Alpes, the point are green marker, when coming back, the points are bicycles marker.

My conclusion of this test, is that Kineis is a good solution to track moving assets, wherever they are on earth. Slow moving like boats may be really precise. High speed move are less precise but you can view the progression on large area without any issues. At business application level, reporting information like “in movement” / “on stop” communications (using an accelerometer), can help to filter accuracy, on top of the Kineis accuracy classes.

During this test, I did nothing about the error correction code, this sounds also really important to implement to preserve the largest number of messages. However this have no impact on the location calculation. Kineis Doppler Location only uses the device ID to compute the location and this one includes a correction code solution internally. As a consequence message with CRC invalid can be processed for getting the device location.