ARGOS (ARTIC R2) Satellite Communication Guide
Looking for a satellite communication board for your next project? We've got three to pick from!
The ARGOS Satellite Transceiver Shield - ARTIC R2, is the biggest of the three and the easiest to get your fingers around. It has the same footprint as our Feather-compatible Thing Plus boards and is designed to stack directly on top of a Thing Plus for easy development. If you are looking for a board to allow you to get to know how ARGOS satellite communication works, or are just starting out on your product development, or want a board you can plug into breadboard, or are not worried about making your tracking system as compact as possible, then this is the board for you.
IOTA - the Integrated Open source Transceiver for ARGOS - is ideal if you are ready to incorporate an ARGOS transceiver into your design. Its castellated pads can be reflowed or hand-soldered as required. It also has slots for an RF screening can, should your certification process require one. The antenna connection is available on both a castellated pad and a u.FL connector. You will find an Eagle symbol and footprint for IOTA in the SparkFun Eagle Libraries RF Library.
The smôl ARTIC R2 is the baby of the three, but it still packs the same punch as its larger siblings. If you are developing a compact dart for whale tracking, or a small backpack for avian tracking, or a very discrete satellite tracker, then the smôl ARTIC R2 is the one for you.
All three boards use the same ARTIC R2 satellite transceiver chip. All three have the same power amplifier, with the same maximum output power and adjustable gain. All three have the same receive sensitivity. All three have on-board flash memory containing the ARTIC R2 firmware and Platform ID. All three are supported by our comprehensive Arduino Library which includes a full set of tried-and-tested examples.
This guide provides background information about the ARGOS satellite system and the ARTIC R2 satellite transceiver chipset. If you are looking for specific information about our three boards, you can open their individual hookup guides by clicking on the buttons below:
The ARGOS Satellite System
The ARGOS satellite system has been around for quite a while. It was created in 1978 by the French Space Agency (CNES), the National Aeronautics and Space Administration (NASA) and the National Oceanic and Atmospheric Administration (NOAA), originally as a scientific tool for collecting and relaying meteorological and oceanographic data around the world. Today, ARGOS is revolutionising satellite communication, adding a constellation of 25 nanosatellites to complement the 6 traditional satellites carrying ARGOS instrumentation. The first of these, ANGELS, is already in operation and SparkFun were among the first users to transmit data to ANGELS in October 2020. When the constellation is complete, there will be a maximum of 10-15 minutes between satellite passes.
ARGOS uses a constellation of Low Earth Orbit (LEO), polar-orbiting satellites to provide worldwide two-way data communication. A global network of terrestrial receiving stations and two data processing centers provide support for continuous, round-the-clock operation.
ARGOS can determine the location of a transmitter using Doppler location. By simply transmitting a unique 28-bit serial number (Platform ID), ARGOS can determine where the transmitter is located without needing GPS / GNSS. This is a big deal since it means the data transmissions can be kept very short, dramatically extending your transmitter's battery life. The more times you transmit the better the positioning accuracy becomes, but ARGOS can estimate your position from a single transmission.
ARGOS is also optimized for low power operation. ARGOS transmission (uplink) is centered on 401MHz, towards the bottom end of the Ultra High Frequency (UHF) radio band. The downlink from the satellites is centered on 466MHz. The receivers on the satellites are very sensitive, which means that you can transmit using much lower power compared to other satellite systems, again dramatically extending your transmitter's battery life. We have seen the satellites reliably receive messages with receive signal strengths as low as -140dBm!
Here are the details of the seven satellites carrying ARGOS instrumentation:
|NOAA-P||NP (or NN')||NOAA-19||2009||ARGOS-3|
The new kid on the block is ANGELS - Argos NEO Generic Economic Light Satellites. Launched in December 2019, ANGELS A1 became operational for ARGOS data in October 2020. ANGELS is a 12U nanosatellite weighing in at only 20kg! ANGELS is important as it supports ARGOS-4, which supports even lower signal strengths further extending your transmitter's battery life. The ANGELS nanosatellite format will be used for the next 25 ARGOS satellites.
* Note: ANGELS A1 carries ARGOS-NEO (ARGOS-4 Light) instrumentation. It does not support A4 HD and does not have an A4 downlink.
The satellite instrumentation is backwards-compatible. ANGELS supports ARGOS 2, 3 and 4. The METOP satellites support ARGOS 2 and 3.
Who can use ARGOS?
At the time of writing, the ARGOS system is currently limited to programs which are related in some way or other to environmental protection, awareness or study, or to protecting human life.
If your project qualifies, then the ARGOS satellite system and our ARTIC R2 products are the perfect solution. The ARGOS instrumentation on board the satellites is extremely sensitive, meaning that your equipment can transmit ARGOS-4 VLD at 100 mW and even lower, extending your battery life considerably. The power draw of our ARTIC R2 products is much lower than equivalent Iridium or Swarm products.
However, the environmental limitations for ARGOS are about to change! Kinéis, heir of the ARGOS System, are in the process of testing a new frequency band between 399.9MHz and 400.05MHz on ANGELS in preparation for the launch of the new constellation of 25 nanosatellites. This new MSS (Mobile Satellite Service) band is not restricted to environmental programmes. Kinéis will become a true Internet-of-Things communication provider - open to all!
The new 399.9MHz to 400.05MHz band is subject to national certification, and so may not be available in all countries.
It is an exciting time for satellite communication. You may enjoy the following news links:
How much does it cost?
The currency that the fees are charged in depends on your geographical location. If you are in the USA or Canada, the fees are charged in US Dollars. If you are in Europe, the fees are charged in Euros.
There is a monthly fee per active platform, plus a daily fee for any day on which you transmit. However, the daily fee is capped allowing unlimited monthly usage for a competitive fixed fee - currently: 87 Dollars/Euros per month for Regular, Commercial or Individual users; 63 Dollars/Euros per month for Governmental or Institutional (Educational) users. *
You can access your data via ARGOS Web for free, or choose to pay an additional fee to receive your data via email, FTP or SMS.
How does this compare with other service providers? A direct comparison is tricky. Here is one way of looking at the numbers:
- A Swarm data plan (750 packets, 192 bytes per packet = 144000 Bytes) costs $5 USD per month
- Swarm allows you to stack up to 4 data plans per device (3000 * 192 = 576000 Bytes) costing $20 USD per month
- The cost per 1000 Bytes is $0.035
- Iridium communication through Rock7:
- Costs are £12 (GBP) per month line rental plus £0.13 to £0.04 per message credit, depending on how many credits you buy in one go
- One message credit is charged per 50 bytes sent (or received) - or part thereof
- Sending 144000 Bytes per month would cost: £12 plus £115.20 (at £0.04 per credit) = £127.20 (approx. $169)
- The cost per 1000 Bytes is approx. $1.17
- ARGOS (Commercial / Individual):
- ARGOS charge monthly plus daily fees independent of data use
- A3 HD supports message lengths up to 4636 bytes (see ARGOS Message Formats below)
- Transmitting say ten times per day: 10 * 4636 bytes per day = 46360 Bytes per day = 1390800 Bytes per month for $87 per month *
- The cost per 1000 Bytes is approx. $0.063
Notes: Exchange rates and prices correct at December 2nd 2021. Prices exclude taxes.
* Please note that ARGOS pricing for 2022 is still being reviewed. For lower transmission rate, large volume of platforms, or Proof Of Concept, a discount may apply.
The ARTIC R2 is an integrated, low-power, small-size ARGOS 2/3/4 single chip transceiver. ARTIC implements a message based wireless interface. For satellite uplink communication, ARTIC will encode, modulate and transmit provided user messages. For downlink communication, ARTIC will lock to the downstream, demodulate and decode and extract the satellite messages. The ARTIC can transmit signals in frequency bands around 401MHz and receive signals in the bands around 466MHz, in accordance with the ARGOS satellite system specifications.
The ARTIC R2 supports:
- ARGOS 2/3/4
- ARGOS 3/4
ARGOS Message Formats
The table below summarizes the properties of each ARGOS message format as supported by the ARTIC R2:
|Message Format||Mode||Data Rate|
|A3 HD||ARGOS-3||4800||60||4636||HD = High Data rate|
|A4 HD||ARGOS-4||4800||992||4960||HD = High Data rate|
|A4 MD||ARGOS-4||1200||480||960||MD = Medium Data rate|
|A4 VLD||ARGOS-4||200||28||84||VLD = Very Low Data rate|
# The data bit rate quoted in the table is the bit rate before convolutional encoding (where used)
* The message lengths quoted in the table include the 28-bit Platform ID but exclude the message length identifier or any required tail bits. The ARTIC R2 always calculates and transmits the FEC for A3 HD and the FCS for A4 HD/MD. The quoted maximum message lengths exclude the FEC/FCS.
The ARGOS-4 VLD mode is exciting since the uplink can use much lower transmit power (100mW or even less) compared to the other modes. The message are short, including only the 28-bit Platform ID, or the Platform ID plus 56 bits of user data. However, 56-bits is enough to encode GNSS position (latitude and longitude) to 4 decimal places and accurate to ±5.55m at the equator.
ARGOS-3 ZE and ARGOS-4 VLD (Short) messages contain only the 28-bit Platform ID. ARGOS is still able to calculate the position of the transmitter using Doppler location.
If you want to dig further into the message formats and encoding schemes, they are defined in the CNES Physical Layer Requirements:
|Message Format||CNES Physical Layer Requirements|
|A3 + ZE||AS3-SP-516-274-CNES|
Satellite Pass Prediction
There are currently only seven satellites carrying ARGOS instrumentation. This means that there are frequently times when there are no satellites overhead and that you need to wait until the next satellite rises if you want to avoid wasted transmissions.
Depending on the capacity of your battery, how complex you want your tracker to be, and where you are transmitting from, you may decide that simply hoping there is a satellite overhead when you transmit is the best way forward. However, being able to predict when the next satellite will rise is of course very beneficial.
There are two main ways to do this:
When you log into your ARGOS Web account, you can use the Satellite pass prediction tool to generate a table or spreadsheet of the times of the satellite passes for the coming days. You can generate the table based on a chosen latitude and longitude, or based on the last known location for an individual ARGOS ID.
The Latitude and Longitude are entered in degrees. Longitudes west of the meridian are entered as negative numbers. The prediction tool asks for the altitude (in km) too. You also need to enter the minimum satellite elevation: 5 degrees is a good minimum if you have a clear view to the horizon; for urban or forested areas a higher elevation is sensible.
Click on Simulate, and the satellite passes are calculated and displayed:
By default, the table lists the satellite passes in date/time order, but you can choose to list them by satellite, middle (highest) elevation, pass duration etc..
The Middle date/time is the date and time when the satellite will be at its highest elevation - the peak of its pass. The time is in UTC (Universal Time Coordinate), you will need to add/subtract your time zone to convert to local time.
The Middle elevation indicates how high the satellite will be in the sky at the peak of the pass. Higher passes are of course better.
The azimuth data shows the heading where the satellite will rise, peak and set. The azimuth is relative to geographic north, not magnetic north. If your view of the sky is obstructed in a particular direction, you may choose to ignore passes where the middle elevation is low in that direction.
The Duration is useful. It indicates how long the satellite pass is from rise to set. Longer durations will allow you to attempt more transmissions. ARGOS transmissions are normally made 90 seconds apart (the "repetition interval") with a mandatory ±10% jitter or dither on the interval. On a typical pass, there is usually time for five transmissions. You should not attempt to transmit more frequently than your repetition interval.
You will notice that - for 55 degrees north - there is an interval ('dead zone') from 12:10 until 17:12 when there are no satellites overhead. That is normal at the moment. When the ANGELS constellation is complete, there will be a maximum of 10-15 minutes between satellite passes.
You can click on the Export button to export the data in a variety of formats.
Pass Prediction Code
Being able to use ARGOS Web to predict the satellite passes is useful, but what if you want your tracker to be able to predict the passes for itself? Never fear! Our ARGOS ARTIC R2 comes to the rescue! Our library contains a pass prediction calculator based on code kindly provided by CLS. If you have included a GPS / GNSS receiver in your tracker project, you can use the latitude, longitude and time to calculate when the next satellite pass will take place. Several of the library examples include pass prediction.
If your tracker will be confined to a particular geographical region, you may not need a GNSS receiver. Knowing the time alone would be enough to predict the next pass.
AOP (Adapted Orbit Parameters)
The pass prediction code also needs to know the orbit parameters for the satellites in order to predict each pass. You will see the parameters included at the start of the "WithPrediciton" examples:
language:c const char AOP = " MA A 5 3 0 2020 10 1 22 7 29 7195.569 98.5114 336.036 -25.341 101.3592 0.00 MB 9 3 0 0 2020 10 1 23 21 58 7195.654 98.7194 331.991 -25.340 101.3604 0.00 MC B 7 3 0 2020 10 1 22 34 23 7195.569 98.6883 344.217 -25.340 101.3587 0.00 15 5 0 0 0 2020 10 1 22 44 11 7180.495 98.7089 308.255 -25.259 101.0408 0.00 18 8 0 0 0 2020 10 1 21 50 32 7225.981 99.0331 354.556 -25.498 102.0000 -0.79 19 C 6 0 0 2020 10 1 22 7 6 7226.365 99.1946 301.174 -25.499 102.0077 -0.54 SR D 4 3 0 2020 10 1 22 33 38 7160.233 98.5416 110.362 -25.154 100.6146 -0.12";
The orbits of the satellites do change or drift over time. The AOP data remains valid for up to six months, but Kinéis recommend updating every 2 to 3 months.
You can download the AOP data from ARGOS Web by clicking the Download satellite AOP button on the satellite pass prediction page. You can then copy and paste the AOP data directly into your code.
Alternately, you can download the orbit parameters in JSON format. Click on the System button and then click on the Satellite Allcast Info option. You will then see an option to download the allcast data.
Example 9 in our ARGOS ARTIC R2 library demonstrates how to use the JSON format data. It is heavy on RAM use, so we do not recommend it for Arduino platforms with limited RAM.
The satellites themselves also broadcast their AOP data, so your tracker can update the orbit parameters in the field without needing access to ARGOS Web. Example 7 in our ARGOS ARTIC R2 library demonstrates how to download the data and record it in the format needed by the pass prediction code.
Encoding Latitude and Longitude
We normally think of GNSS Latitude and Longitude as both needing 32-bit storage, either as an integer or a floating point value. So, is it possible to send both Latitude and Longitude in the 56-bits available in a single ARGOS-4 VLD (Long) message? Well, yes, of course it is! But you have to be a little bit crafty about how you do it.
If we want to encode latitude and longitude to four decimal places, giving us an accuracy of ±5.55m at the equator:
- Longitude is in the range ± 0.0000 to 180.0000 degrees
- If we allocate one bit for the sign (plus/minus or east/west)
- And if we multiply the longitude by 10000 and turn it into an integer
- We need 21 binary bits to encode 180000010 (21 bits can encode values up to 221 - 1 = 2097151)
- Including the sign, we need 22 binary bits to encode the longitude
- Latitude is in the range ± 0.0000 to 90.0000 degrees
- If we allocate one bit for the sign (plus/minus or north/south)
- And if we multiply the latitude by 10000 and turn it into an integer
- We need 20 binary bits to encode 90000010 (20 bits can encode values up to 220 - 1 = 1048575)
- Including the sign, we need 21 binary bits to encode the latitude
We use that same format in our ARGOS ARTIC R2 Arduino Library examples. If you ask CLS or Woods Hole Group to apply the SPARKFUN_GPS template to your account on ARGOS Web, the latitude, longitude, south and west fields will appear in your data automatically:
Now, what should we do with those left-over 13 bits!? We'll leave that up to you. You might want to encode altitude as m above sea level. 13 bits would allow you to encode altitudes up to 8191m. For high altitude, you might want to encode altitude as 10's of m?
Each ARGOS transmitter has a unique Platform ID number. When you buy an ARGOS ARTIC R2 board from SparkFun, you will receive a card with it which shows:
- Your decimal Platform ID
- This is used and displayed in ARGOS Web
- The 28-bit hexadecimal Platform ID
- This is programmed into the ARTIC R2's flash memory and used in all transmissions
- The transmission repetition interval
- The default interval is 90 seconds
You will need to ask CLS / Woods Hole Group to add the Platform ID to your account in order to see your data.
You will need to seek special permission from CLS / Woods Hole Group to use a repetition interval shorter than 90 seconds.
We were instructed by CLS to program the (hexadecimal) Platform ID into flash memory, so that the wrong ID could not be entered into code by accident. (Entering the wrong number has happened - a polar bear that was being tracked via ARGOS suddenly appeared to be in Africa!)
Resources and Going Further
- The ARGOS System
- How ARGOS works
- Register as an ARGOS user
- ARGOS Publications and Resources
- ARGOS Web Login
- Kinéis IoT everywhere
- ARGOS Chipset Info Sheet
- ARTIC R2 User Datasheet v1.1
SparkFun Hookup Guides: