In some of my previous post, I did talk on Kineis IoT satellite solution. The competition is that area is large and one of the other player is Astrocast. I really thanks them for getting me in the program to explore this technology (and I apology to have been a bit long to start using it).

Astrocast is a Swiss company launching nanosatellites to currently provide Europe, Asia, Africa coverage for IoT. It uses L-Band (1-2 GHz) radio. The transmission period will be 15 minutes once the constellation will be fully deployed. The current constellation is 10 satellites for a target of 100 satellites by 2025.

Some more details about the technology

Satellite fleet

Astrocast is composed of LEO (Low Earth Orbit) satellites, between 500 and 600 km above Earth. The Astrocast fleet will be on equatorial orbit for 20 of them and polar orbits for the 80 others. Currently 2 orbital plan have been launched on polar orbits only.

Event if 12 have been sent to space, only 10 of them are used today (on 2 orbital planes). The 2 others satellites were launched earlier for mission demonstration. On each of the orbital plane, we see that multiple satellites forming a sort of train, close to each other. This allows to extend the transmission windows for a single pass. As a consequence, currently, the Astrocast constellation is offering about 5 transmission windows per day, in Europe and offer coverage all over the world (in theory). Each of them is about 1-2 minutes actually. The minimum elevation for the satellite should be around 40° for the communication to start.

When the equatorial constellation will be operating, each of the satellites may pass over a single point about 14 times a day but this will be limited to the equatorial area that suffer of less transmission windows per day with polar orbits.

The satellite life duration is about 3-4 years before renewal. This is an important point for LEO satellite and service perpetuity, it requires a constant investment to launch satellites and all can be off in a short period of time. The use of nano satellite drastically reduced the running and replacement costs. The estimate is a cost for $500k per satellite to be manufactured and launched. This is about a need of yearly recurring revenue about $18M to renew a fleet of 100 satellites every 3 years.

According to some documentation found on Internet, 14 ground stations will be deployed to cover the satellite to Earth communications globally, currently the satellites needs to pass over one of these ground station to report the communications back to the cloud platform. Inter-satellite communication will provide a real-time sat-to-ground communication, later there is apparently no given date for this service.

Transmission technology

The communication with Astrocast constellation is bidirectional, the size of an uplink packet is from 1 to 160 bytes when the downlink communication can be 8 or 40 bytes. The communications are operated in the L-Band (1GHz-2Ghz) in a global band owned by Thuraya. Thuraya is a satellite voice communication system. They are using 34MHz from 1.525GHz to 1,559GHz for downlink and 34MHz from 1,6265GHz to 1,6605GHz for uplink. Astrocast should be in these sub-bands too. Currently, the use of Thuraya is limiting the coverage on the Europe, Asia, Africa, Middle-East. Americas are not yet covered. The service will be fully open on 2024 for a global coverage.

GPS, GALILEO frequency is 1575.42Mhz, basically in between the Uplink & Downlink frequency. For this reason, Astrocast proposes to share the patch antenna for GNSS reception.

The communication power is 14-16dBm, this is low power and also allow use of small cells that only have to deliver about 80mA during transmission. The module is detecting the satellite approach and manage the synchronization. Thanks to this, there is no need to have the satellite schedules knowledge at the device level. Once the full fleet will be deployed, this will be really power efficient. Currently, as the number of pass is limited to 5 a day, it can be a bit consuming, but it is just a transition.

As you can see on the above diagram, until the satellite pass over the device, it wakes up on every 17 seconds to listen on sat signal and goes back to sleep if not there. When the satellite is detected, the transmission can start, a reception confirmation is sent to the device with a potential downlink. This make it really easy to implement !

After the first communication, the device obtains information related to the constellation and UTC time. That way, the device can go deep sleep for a while between two different satellite passes. The device will wake up sufficiently before the satellite pass to make it working even when the device is moving.

The modulation used is QPSK (4 different phases shifts are used) at a speed of 400 bps for the communications. This is basically low speed and this is allowing long distance with reduced power.

The payload is splitted in fragments, each of them have 30 bytes, but 18 can be used for the payload. each fragment also have a CRC and a “Turbo Code”. At the end, a fragment is transmitted in 1.36s. Each of the fragment can be repeated independently if not correctly received. The way it’s done, you just need one fragment for transmitting a payload under 4 bytes. Then 2 fragments for a payload between 4 and 21 bytes… so we have an overhead up-to 14 bytes in the fragment. In this overhead we have some ID information and also the timestamp of the message. So when multiple messages are queued, you can receive, in the backend, the submission time. A satellite pass, depends on the elevation allows between 10 to 40 fragments transmissions.

Getting started with the kit

I did start with the Astronode DevKit, it contains an IP68 modem, connected to a USB Serial adapter over a really long cable. This is important as you need to have you kit outside, pointing to the sky if you want to make any development. the 1-2GHz frequency will not really support the idea to pass through any wall. As the satellite pass are limited to 5 per day currently, the development can be made a bit complex. For this reason, Astrocast propose a clone of the Satellite modem using WiFi instead.

The kit is ready to go but it will need a computer to be used. You can tweak the modem to add you controlling system but the box will be quickly too small for this. I regret to not have a battery holder and an Arduino in it to get a ready-to-go device for experimenting the solution. By-the-way it’s good for firmware developer who are in parallel creating a board with the Astrocast module in it.

On the middle and top of the kit picture you can see the Astrocast modem unit. This is an IP68 enclosure where you have the modem and the patch antenna. It will be connected to your computer with a long RS232 cable terminating with and USB connector to be compatible with any computer. On the middle and bottom, you see the WiFi unit that can be used as a virtual satellite transceiver to make your developments and integration with the backend.

Modem board details

The modem board is mostly composed by the modem module (the big one in the center), the rest are the different interfaces to communicate with it. It responds to serial line (like AT but not AT) commands, as usual. You can use RS232 (great with long cables) or UART + some GPIO used to control the module and to be alerted.

On the other side of the board you can see the patch antenna used for the communication. One of the big advantage of the 1.56GHz communication is the compact size of the antenna. This antenna is specifically tuned for uplink and downlink bands is not a standard GNSS antenna even if the frequencies are really closed.

Getting Started using the GUI

To get started with the board, Astrocast has made a GUI tool to communicate with the modem. This is requiring Windows 10 and .NET 5.0 framework. In my point of view a multi-platform solution would have been a plus, I hate to have to start a VM ;).

The GUI is really simple but just what you need to send your first message without having to consider reading the documentation and this is good to me.

You just click on “Queue Message” and the message will be sent to the module. The GUI then poll the module to get the send confirmation.

As a reminder, the module is waiting for a signal from the satellite for the synchronization of the transmission. The message is only sent once a satellite pass has been detected. The module have an embedded low energy process to wake up on regular basis, check the satellite synchronization, then fire the message. This is why messages are queued and transmitted when possible. The host will get notified once the messages will be transmitted / acked. I’ve experience some GUI crash during waiting process (but they have been disappeared since I updated my VM). In any case, you need to know that the module is keeping the queue alive even if you close the GUI or if it crashes. Up to 8 messages can be stored in the queue.

Once the message has been sent, be careful, the transmission windows are UTC time – until you specify it differently in your profile settings – and not local time, you still need to wait for the satellite communication to the ground. In my case it has been about 2 hours after the transmission. During my test, all the messages I’ve transferred have been received. I’ve done test during 3 satellite passes and non of them have been missed. Something I’ve been a bit surprised in a really positive way as my device is not 90° to sky, it is just on my roof with many equipment making noise around, particularly my GPS repeater 1 meter around. Multiple messages (queued) have been transmitted autonomously. This approach is interesting when you have 1h messages to report but a limited number of transmission windows. The Astrocast module manages this, you don’t care.

As you can see, the timestamp of the message (time I put it in the queue) as been sent to the network allowing to manage periodic communication transparently.

Astrocast Backend

The Astrocast backend is built on Azure, features are currently basic but the quality is good. You can get a quick access to the next transmission windows for a device (I’m not sure how it works when you have 5-10…), check you traffic and access your different devices.

When you go on a specific device, you can access the device detail and the next transmission windows for this device. You can access the last message received. Honestly, the platform still needs some improvement, you need to make many click to access important information but as it is really young it sounds normal to me.

I did not yet found how to export the data like with a callback on reception. the reason it is not yet implemented so you currently need to integrate with an API call, this is not really efficient way to be integrated when you get messages 3-5 time a days, but it is a temporary situation.

The Astrocast WiFi Board

When I received the kit, it has taken me some time to understand what this second board was.

This board, simply composed by an WiFi module, is an Astrocast emulator. Basically you interact with it exactly like with the Astrocast satellite module but this one is transmitting your payload over WiFi. So you don’t need to wait for a transmission windows. The data are loaded in the Astrocast dashboard the same way as it came from the sky. That way you can develop your integrated solution is a simple way.

This is a really great idea. Debugging satellite IoT can shortly be a mess if you need to wait 6 hours to make a test – even 15 minutes is boring. Also a good point to not stand under the rain with your hardware until the satellite pass … This solution really helps for the software development, it’s smart.

To use it with, you need:

• To create an access token on the Atrocast portal (in the Home page scroll down to Access token area). Create a token with WiFi DevKit role. The token GUID will used. Be careful the token will be printed a single time on the top of the home page.

• Connect the board with the FTDI cable
• In the Astrocast GUI, set the WiFi credentials, the token and “Set WiFi config”

Now you can use the WiFi kit the same way as the satellite kit but you immediately get the data in the backend.

Overall experience feedback

The time to get started has been really fast on Astrocast network, thanks to the queuing mechanism and the satellite pass detection making the use really simple. What have been the most impressive to me has been the communication quality. I did not lost any of the transmission windows I had. The latency is currently a bit long but, as designed. The really limited power supply required for the transmission, is a key point in my point of view, as the possible compact design thanks to the patch antenna.

I’ve been also surprised to succeed in transmitting behind a roof top window, a test I did because the weather was not good enough to let the windows open. Positive result. Just perfect !