SX1262 – Improved LoRa Device

NiceRF recently released a module using the Semtech SX1262 LoRa module. This is for UHF use and seen as an upgrade to the SX127x devices. I designed Mikrobus module for it so I could test the device.

Edit: 28/10/19

I have published an Arduino library for the SX1261 and SX1262, it can be found here; SX126x Library. This library is very similar to the library for the SX1280 2.4ghz library which can be found at the same location.

Standard LoRa modules such as Hope RFM98 and Dorji DRF1278 based on the Semtech SX127x RF chip generally use low cost crystals which whilst it makes the modules cheaper, using LoRa bandwidths below 62500Hz is difficult. If the transmitter and receiver differ in transmission frequency by more than 25% of the bandwidth in use, they wont communicate. At these lower bandwidths even if two devices communicate on the bench when they are at the same temperature, large temperature differences can cause communications to fail.

This frequency error problem is going to be worse at 868MHz than it is at 434MHz, so its no surprise that The Things Network uses a bandwidth of 125000Hz, it leads to reliable communications with low cost devices..

The Semtech SX1262 has internal firmware support for a temperature compensated crystal oscillator which should allow the lower bandwidths to be used.

Lower bandwidths potentially provide longer range, at the expense of packets taking longer to send. Significantly in a lot of countries the duty cycle for less that 25kHz channels is often 100% , but the higher bandwidths commonly used by current LoRa modules are normally restricted to 10% or even 1% duty cycle. So the lower bandwidths can provide a greater data throughput since you can run the transmissions continuously.

It is possible to get the standard SX127x modules to communicate at the lower bandwidths. Once packets are being received the transmitter and receiver can be kept close in frequency (mitigating developing temperature differences) by using the estimated frequency error produced by the SX127x to adjust the set frequency of the receiver. However packet communications does need to be established in the first place either by a manual adjustment of frequency or by initially receiving packets at a higher bandwidth.

The NiceRF SX1262 modules I had worked out of the box at the lowest possible bandwidth of 7810Hz, which was a surprise, practical operation at that low bandwidth was just to difficult with the previous generation SX127x modules.

So how would the modules cope with large differences in temperature? A transmitter was setup for bandwidth 7810Hz at spreading factor 7 (SF7) using 10dBm of power. The transmitter was put in a freezer that goes down to -20C. After a couple of hours in the freezer I was still receiving packets on the bench receiver at +20c, so the use of the TCXO allows the lowest bandwidth of 7810Hz to be used even with large variations in temperature, 40c in this case, between transmitter and receiver.

So what is the amount of frequency shift of the SX1262 modules when the temperature goes from +20c to -20c? I theorised you could identify the lower and higher limits of working reception by adjusting the set frequency of the receiver till reception of packets stopped.

I was using a frequency of 434.5MHz. So by adjusting the frequency of the receiver I determined the low frequency for working receptions was 434,498,250Hz and the upper frequency was 434,502,050. This is a range of 3800Hz or +/- 24%, which is closely in line with the data sheet specification of 25%. Centre frequency was 434,500,150Hz. This was with the receiver at +20c and the transmitter at -20c.

The transmitter was allowed to return to room temperature, +20c, and the frequency limit test carried out again. This time the lower frequency of reception was 434,497,950Hz and the upper frequency was 434,501,700Hz. This is a range of 3800Hz or +/- 24%. Centre frequency was 434,499,850Hz.

Thus the shift in frequency of the transmitter in the temperature range of +20c to -20c was 300Hz or 7.5Hz per c. So if there was a difference in temperature of say +30C to -60c between transmitter and receiver the frequency difference between them due to temperature would be 675Hz.

It therefore seems feasible to use a bandwidth of 20830Hz without worrying about frequency errors and over a wide temperature range.

At 434MHz, a bandwidth of 62500Hz SF12 would normally be used for a location tracker and changing to using a lower bandwidth of 20830Hz should, according to the data sheet, provide an additional gain of 4.8dB, equivalent to increasing the reception distance by 74%. Moving bandwidth from 62500Hz SF12 to 20830Hz SF12 would increase on air time of a 12 byte location packet from 1982mS to 5948mS.

So how well does the SX1262 actually perform at the 20830Hz bandwidth, and how to carry out a real world test?

I have some link test software that will send packets at reducing powers, the SX1262 has a range of 22dBm to -9dBm. Imagine you want to compare the effectiveness of two antennas. You will first need to attenuate the transmitter output in some way to cut the range to a practical value, you can use an SMA attenuator (20dB possibly) between the transmitters LoRa module and antenna or attenuate transmissions in some other way by putting the transmitter in a tin or wrapping it in aluminium foil.

At some distance from the transmitter you attach antenna A to the receiver and you note it stops receiving packets sent at -2dBm, no lower power packets are received. The power level a packet is sent at is made part of the payload so the receiver knows the powers of the packets received.

Keeping the receiver in the same position and orientation you fit it with antenna B. This time you receive all packets down to -5dBm. Thus the real World performance of antenna B is 3dBm higher (i.e. it has 3dB more gain) than antenna A.

You can use the same testing method to compare the effectiveness between two sets of LoRa modem configurations. I set my link test software to send descending power packets

first at 62500Hz SF12 and then at 20830Hz SF12. The receiver software flips reception between the two settings automatically and displays the results on a display and logs to micro SD card for later review. The transmitter was placed on top of the mast on my shed and I took the portable receiver to a hillside overlooking the city where I live and 4.4km away.

The results were interesting, over about 10 test loops the average of results were;

62500Hz SF12 reception down to 0dBm

20830Hz SF12 reception down to -6dBm

So there was a practical difference. I did notice that there were more packet failures at 20830Hz SF12. At the limit of reception these time wise longer packets are probably more susceptible to corruption from noise etc.

Looking at a comparison of bandwidth 62500Hz SF7, which is a data rate of 2735bps at 10% duty cycle you can only send at an effective 273bps. At 62500Hz 20830Hz SF7, the data rate is lower at 910bps, but since you can send at 100% duty cycle you have over 3 times the data throughput. You also pick up around 5dB of signal gain. Winner all round really.

In summary the SX1262 is a very useful addition to the LoRa family, it can be used for longer range applications due to the TCXO making lower bandwidths practical. The other probable application is using the 20830Hz or lower bandwidth to send data on a continuous basis and avoid duty cycle restrictions.

To carry out the above tests I needed to build a suitable Arduino library and whilst the methods of controlling the SX1262 are completely different to the SX127x devices, the SX1262 is very similar in operation to the SX1280 for which I had already produced a suitable Arduino library. There are only some slight differences in commands so my testing programs originally written for the SX1280 worked with only minor changes on the SX1262.

On point to note; the SX1262 now goes down to SF5 and both SF6 and SF5 now support the use of explicit and implicit header types. However the changes made to produce these new features mean that the SF6 output produced by an SX1262 cannot be read by the earlier SX127x devices. Which is a big shame.

Perhaps of particular interest to those using TTN applications is the almost identical SX1261 device which apparently (according to the data sheet) uses the switched DC-DC converter to significantly reduce power consumption dureing transmissions. This if it proves to be true could yield a significant improvement in battery life for projects so powered.

Stuart Robinson

August 2019

SX1280 Arduino Library

The Arduino library I was working on for the SX1280 has had a couple of flights running a high altitude balloon tracker, and the tracker transmitter and receiver both worked. The library is available for download here;

Its only been used by myself so far, so test any applications you use it for carefully. The ranging function needs some further investigation, I have seen some instances of invalid results returned.

2.4Ghz NiceRF SX1280 LoRa Balloon Tracker – Update – Now 89km Achieved !

Although I have launched a few pico, foil party type balloons, I had not participated in the launch of a ‘real’ high altitude balloon (HAB) the latex type that rises to 30km or so then bursts and comes back to ground.

There was a HAB workshop planned for 25th/26th July in Braunton Devon so I signed up.

Bill, who was running the workshop agreed to give one of my new 2.4Ghz LoRa trackers a ride up to altitude. The tracker was a simple design using an ATmega328P processor used with my own Arduino library for the Semtech SX1280 LoRa device.

The tracker board itself (left in picture above) is not specifically designed as a radio frequency (RF) tracker and does not have connections for directly mounting an RF device. Instead it has the pins to allow a Mikrobus compatible module to be fitted. Mikcroelectronica produce a range of Mikrobus boards under the ‘Click’ brand;

Click Boards

I make my own Mikrobus compatible boards for the Hope RFM9x, DRF127x, RN2483 LoRa devices and most recently one for the NiceRF SX1280 LoRa devices. The simple Arduino board can then be used for 434Mhz, 868Mhz or 2.4Ghz LoRa devices just by using the appropriate Mikrobus board. The boards can either plug in on sockets, good for testing or last minute changes, or be soldered permanently in place for a more compact tracker. The components needed are all wired through hole types, so the board is very quick and easy to assemble.

The assembled 2.4Ghz tracker is fairly compact and I choose to use a standard small Wi-Fi antenna connected to the RP SMA socket.

The assembled tracker has pin headers for connection of a GPS and\or sensors such as BME280 I2C types.

The board can be used with just two AAA Lithium energisers which will supply around 2.9V for most of the batteries life. The basic board has a very low quiescent current regulator so can be used with 3 x AA batteries and still keep the sleep current of the board below 2uA.

The tracker was fitted into the HAB payload box, shown below at top left with the small L70 GPS at top right. The antenna poked out of the top of the box which was not ideal but

the Raspberry Pi in the Sky (PITS) tracker had two antennas on the bottom, one for FSK RTTY and another for LoRa.

This is the balloon being filled with helium at the launch site.

And the balloon shortly after launch with the payload below.

My tracker setup was fairly simple, a low cost Wi-Fi yagi on a tripod and one of my LCD receivers with a SX1280 Mikrobus module in place. The receiver has its own GPS so when it receives the location data from the tracker can calculate the distance and direction to the tracker.

When the tracker was last received on 2.4Ghz LoRa it was one its way down at a distance of 89.237km and an altitude of 6895km. From the field tracking location on the North Devon coast the balloon was tracked till just short of landing using 434Mhz LoRa and FSK RTTY.

The balloon, call sign Vincent, landed after crossing the Bristol Channel from North Devon to land near Newcastle Emlyn, a distance of around 108km.

The 2.4Ghz LoRa settings used were bandwidth 406khz and spreading factor 12. The lower bandwidth of 203khz should provide a bit more range with a bit of fine tuning.

One point to note is that the L70 GPS used, bought at very low cost from China, stopped working and lost lock when the balloon went above 10km. It was seen to recover when the balloon was on the way down at 6895m. The GPS was put into balloon mode so further tests are required to identify the cause of the problem.

The flight was an interesting test of the limits of 2.4Ghz LoRa and whilst its not going to replace the standard UHF LoRa devices for HAB tracking, as the in air range is only just adequate, reception distance at ground level especially with trees around is limited to a couple of hundred metres or so.

The ranging or distance measuring is an interesting feature and the device is capable of some fairly high data rates, 203kbps for LoRa and the FLRC mode should cover the same distance but at a data rate of 975kbs.

It was fun to experiment, thanks to all those involved for the workshop with a special thanks to Bill Harvey who organised it.

Stuart Robinson

2.4Ghz NiceRF SX1280 LoRa Balloon Tracker – 85km Achieved

I have had the basic send and transmit function of my Arduino Library for the SX1280 working for a couple of months, but I was keen to subject the code to a real World test before publishing it. So I built a small GPS tracker (25g) to use on a high altitude balloon.

The SX1280 LoRa devices can calculate distance by measuring the time of flight of a special packet exchange, I wanted to see how far this ranging feature would work, I had previously tested it to 40km in a hilltop to hilltop test.

So I set about converting some balloon tracking code I had originally written for the SX127X LoRa device to use my SX1280 library. This software runs as a GPS tracker typically using an ATMega328P as on an Arduino Pro Mini. The receiver can also be powered by a Pro Mini, but to run the Micro SD data logging, display and receiver’s GPS requires a processor with more memory so I normally use a version of my LCD receiver that has an ATMega1284P processor.

Changing the code to run on the SX1280, including the remote control functions took a month or more and with it eventually working I added the SX1280 Ranging capability. For this function the remote balloon tracker would transmit a short command that the receiver identifies as a ranging request. The receiver then initiates the ranging packet exchange process and displays the results as a distance.

I eventually had a chance to test the tracker on the 22nd July, weather conditions looked suitable and the small tracker was fitted to a Qualatex 36” foil balloon and launched from the Black Rock picnic site between the two Severn bridges on the West side of the Severn.

I was not using the longest range mode of the SX1280, I chose a LoRa bandwidth of 406khz as I wanted to avoid potential issues if the tracker got very cold and the TX and RX became more than 25% of the bandwidth apart in frequency. Its possible that further work will show that the lower bandwidth of 203khz, which would give more distance capability, can be used. I am also looking at implementing an AFC capability in the software.

The balloon rose slower than expected and was moving horizontally quite quickly. A 2.4Ghz magnetic mounted antenna on my car’s roof was not receiving strong enough signals to be able to follow the pico in the car, so I stuck to tracking it from a playing field with a cheap Wi-Fi yagi.

The balloon rose to 7903m where it apparently burst and descended. I lost contact with it when it was at 3259m altitude and the GPS calculated distance was 85.325km, direction 57degrees. The ranging function measured the distance as 85.133km, so with ranging now known to work at that distance, the flight was a success.

The point of lost contact was over the River Stour near Sutton-under-Brailes.

I hope within the next week or so to be able to send the 2.4Ghz LoRa tracker to around 30km altitude on a latex balloon launch.

The Arduino library seems to work well, with perhaps some improvements required in the ranging code and an AFC capability. I particular I need to write a note on how I carried out the necessary ranging calibration.

Stuart Robinson

July 2019

SX1280 Fast LoRa

The SX1280s LoRa modules can use far higher data rates than the UHF band SX127Xs. At the fastest settings, spreading factor 5 and bandwidth 1625khz, the effective data rate is 203kbs.

High gain antennas such as yagis are very low cost for 2.4ghz since so many are produced for use on WiFi. The yagi below cost me £4.50 delivered from a UK supplier.

At what distance would a pair of these yagis, one for each transceiver allow a line of sight (LOS) data link to operate at 203kbs ? I decided to find out.

I configured my custom link test software to run at the 203kbs setting, put the link test transmitter on the mast on my shed and went to the receiving location North of Cardiff, 4.4km away that I have used for the SX1280 ranging tests described in a previous blog.

With the yagi connected to the NiceRF module on my receiver, I was getting packets down to -3dBm.

So at the maximum TX power the SX1280 can provide, 12dBm, there would be 15dBm of link gain, which suggests a LOS range at that power of around 25km. Which would be impressive.

I exchanged the yagi antenna I was using for the receiver of the test packets to a simple 2dBi one, see below;

I was then receiving packets down to +5dBm, so the receiving end yagi was providing me with 8dBm of gain.

The implication was that the simple 2dBi antennas fitted either end would be on the verge of working over the 4.4km link. So I swapped the transmitting end yagi with a simple 2dBi one and tried again. Much to my surprise it worked, I received all the 12dBm packets. This  also shows how useful the decending power method of testing can be in predicting actual link performance.

So with the simplest of antennas a pair of SX1280 LoRa modules can communicate at 4.4km at 203kbs using only 12mW of transmit power, impressive.

Semtech SX1280 2.4ghz LoRa Ranging Tranceivers

The Semtech SX1280 LoRa devices bring long range LoRa technology to the 2.4ghz bands. The devices allow for much higher data throughput than the lower frequency LoRa devices, data transfer speeds are up to 203kbps.

The SX1280 also has a ranging mode that can measure distance by recording the time of flight of a special packet exchange between two SX1280s.

I have designed some plug in Mikrobus boards for the Ebyte and G-NiceRF SX1280 LoRa devices. The larger green PCBs are an ATMega328P based Mini Logger I also designed. It can be fitted with a single plug in Mikrobus compatible board, see the picture below;

The Mikrobus PCBs shown, the yellow ones, are breadboard friendly so will plug into a standard 0.1″ breadboard, very useful for prototyping.

A complete Arduino based transceiver fitted with an G-NiceRF SX1280 device is shown on the left of the picture above, complete with 2dBi WiFi antenna. The board was programmed in the Arduino IDE.

Semtech publish sample code for the SX1280 but its not directly suitable for the Arduino environment so I used the Semtech code as a basis for writing some Arduino library files.

First Ranging tests

I used a large open field to test the ranging, these were the results;.

Actual Distance     Indicated Distance.
0                               4.4M
50M                         57.6M
100M                       103M
150M                       148M
200M                       201M
250M                       253M

So not too bad, the results did seem to be consistent for large open areas. So short distance ranging seems OK, what about longer distances ?

4.4km Ranging test

North of the Cardiff where I live there is a ridge and the location is around 150M higher than where my shed is located in the city. With a SX1280 transceiver on top of the 6M mast attached to my shed there is a relatively clear line of sight from the ridge to the device on the mast, the distance is 4.4km.

I wrote ranging software that would first transmit a ranging request at high power (10dBm!) and report whether the ranging request completed. The transmit power was then reduced and another ranging request made.

Over the 4.4km link the ranging worked down to -14dBm. Thus if the full power was used, 10dBm, this test indicates the ranging may have potential to work at over 69km.

40km Ranging Test

There is a location North of Cardiff (altitude 264m) suitable for a 40km link test to Black Down (altitude 325m) in the Mendips, the other side of the Bristol channel.

At the Cardiff end there was a SX1280 ranging receiver fixed to a pole and another for a basic link test. The view from here towards the Mendips is below;

At the Mendips end I had a matching set of devices, one as the ranging test instigator/transmitter and another for receiving basic link test packets. The results were logged to a micro SD card for later analysis. Basic 2dBi antennas were used at both ends.

At the Mendips end the ranging request transmitter would emit a long beep at the start of the test sequence, send a ranging request at 10dBm, then 9dBm, 8dBm etc. If the ranging request was successful then the would be a short beep. Thus to work out the power level when the ranging stopped working you only had to listen for the long beep and then count the short beeps.

The LoRa settings for the ranging were SF10 and bandwidth 406khz, the longest range settings that the SX1280 allows for ranging mode.

Ranging calculations

The path used for the ‘4.4km Ranging test’ mentioned above was used to test and calibrate the ranging function. The ground distance was 4.42km as measured on Google maps. The average ranging result from the SX1280 was 24515. This gave a conversion factor to metres of 0.1803.

The average ranging result for the Cardiff to Mendips link was 225982. Applying the 0.1803 conversion factor gives a distance of 40.745km. The distance taken from Google Maps was 40.650km. So the SX1280 ranging produced a measurement of +0.2% over actual. Not bad.

Summary – Distance Potential of the SX1280 ranging and point to point.

The ranging requests were received down to 4dBm over the 40km link. This would imply a potential range of 80km LOS at 10dBm. Even modestly improved antennas at both ends (see antenna comparisons above) could double this range.

The longest range settings for point to point mode, SF12 and bandwidth 203khz should have a link advantage of 8dBm over the ranging settings described above, SF10 and bandwidth 406khz. Converting this 8dBm link advantage over the ranging settings, suggests a potential range for point to point LoRa in the 200km region.

SX1280 Program Code

Semtech publish source code in C++ and a development kit for the SX1280 based on ARM\MBED.   I have adapted the code to work under the Arduino IDE, its been tested on ATMega328P and ATMega1284P. There is still some work to do on the ranging part of this code, when it it ready it is my intention to publish it as an Arduino library. 

All the parts used in these tests were self funded, no complimentary parts were used.

GPS Performance Comparisons

I have carried out a performance review of the common available GPSs that you might use for a LoRa tracker.

In most cases you will run the GPS in hot fix mode, and unfortunately most of the common GPS breakout boards that you get on eBay etc, are not suited for this in a power miser tracker that needs to survive on batteries for a month or longer. The reasons are explained in the article.

There is data of the performance of 12 common GPSs, signal strength (antenna effectiveness), real world power consumption and hot fix performance over an extended period. There are notes on methods of reducing tracker power consumption.

Choose the wrong GPS and your tracker, powered by a 2800mAhr battery, might only last 14 days. Choose the GPS wisely and the same battery can last 200 days.

The report is at the link below;

GPS Performance Comparisons

GPS backup issues 3 – Whats the alternative ?

So if we don’t use a a super capacitor or a small lithium rechargeable, then what is the alternative ?

We could of course use a non-recharegeable lithium battery such as a CR1216 but in the holders these have much the same issue as the super capacitor, they are physically large, see picture.

GPS and Battery

In addition even a battery as physically big as the CR1216 only has a capacity of circa 25mAhr, so that would only keep the GPS (@15uA backup current) going for 70 days. A tracker based on this setup would need it’s GPS battery replaced around every two months.

The answer to the problem is quite simple really. With the small lithium rechargeable or supercapacitor options, then the backup power for the GPS is actually coming from the projects main battery, so why not use the main battery as the backup power source for the GPS ?

All we need to do is take a 3.3V supply from the project and feed this voltage via a diode to the GPS Vbackup supply. We then need to ensure that the 3.3V supply is present when the project (using the GPS) is in sleep mode. This is not difficult even if the project is using something like a TPL5110 to switch off \on the battery supply to the project. A low drop out regulator such as the MCP1711 has a quiescent current of 0.6uA, so that can be used to go between the projects battery and the GPS Vbackup supply without having a significant impact on total GPS backup current consumption.

Whilst the solution to providing a long term GPS backup current is simple to implement, very few GPS breakout boards provide access to the GPS Vbackup pin, so you cannot feed in an external backup supply. For this reason I designed my own GPS breakout boards for the Quectel L70 and L80 GPS. These are low cost high performing GPSs with substantially lower power consumption than most other GPS modules, see a detailed report here;

 GPS performance comparisons


L70 and L80 Breakout

The L80 GPS has a slightly worse power performance than the L70, but it has its own ceramic patch antenna and easy to include in PCB designs and solder in place, I like it. The L70 has a balloon mode, for use up to 80km.

GPS backup issues 2 – Super Capacitor ?

If a small lithium battery is not suitable;  what about a super capacitor that can at least be charged fairly quickly so it might accrue enough charge during a short hot fix power on to last for several hours ?

There is a web site which is an online super capacitor charge and discharge calculator;

Super Capacitor Calculator

First lets see what size of super capacitor we need. Assume a maximum backup time of one day, a fully charged voltage of 3.0V and a minimum volts for GPS backup of 1.5V, a  GPSs backup current of 15uA which is  typical for a Ublox GPS for instance. The calculator suggests a capacitor of 1Farad would last a couple of hours longer than one day.

If the hot fix gap was 10 minutes and the hot fix takes 5 seconds with a GPS backup current of 15uA, then assuming no charge\discharge efficiency losses the charge current needs to be 600/5 times the backup current or 1.8mA. That’s manageable.

So if we are to use a 1F super capacitor how big would it be ?

Checking on the Farnell web site a 1Farad 3.6V super capacitor would be around 20mm, perhaps a bit more, in diameter and 5mm high. That’s really quite big, see picture for how big the 5.5V version 1F capacitor is. The GPS shown is one of the larger 25mm ceramic patch antenna types.


GPS and SuperCapacitor

There are some small super capacitors around the same size as the Seiko MS621, but these super capacitors are of very limited capacity and would only provide a couple of hours backup (based on practical tests).

So if a super capacitor is too big to be practical and we have allready dismissed small lithium rechargeables, then what is the alternative ?

GPS backup issues 1

A modern GPS will normally get a fix from cold in 30 – 60 seconds when it has a good view of the sky. Once it has downloaded enough information on the GPS satellites the main GPS power can be turned off and as long as a voltage is supplied to the GPS backup pin it will retain the satellite information in GPS memory. When the GPS power is then turned back on the GPS can acquire an updated fix in as little as 2 – 5 seconds, this is called ‘hot fixing’.

In backup mode the GPS may consume only 5uA to 20uA, so clearly there are significant power savings to be had if we only want intermittent fixes from the GPS. A GPS that only needs to run for a few seconds to get an updated fix every 10 minutes or longer will use a lot less power that an GPS that is left running all the time.

A very common way to supply the backup supply to a GPS is to use a small Lithium battery, typically a Seiko MS621. However this is not without problems, the MS621 has a capacity of only 5.5mAhr and a max charge current of 100uA. So when first used with the GPS you need to leave it powered for 55 hours, just over two days, to fully charge the battery which is not very convenient. In addition you need to consider the cycle time. A typical GPS will consume 15uA in backup mode, so the MS621 will only last 15 days or so when fully charged. If the tracker is to use hot fixing for longer than 15 days then the backup battery needs to be charged, or it will just run out and hot fixing will fail.

If we are taking a GPS fix every 10 minutes and the hot fix takes 5 seconds, there is only 100uA x 5 seconds = 500uA seconds going into the battery. But in 10 minutes there is 10min x 60seconds x 15uA = 9000uA seconds going out. Thus the battery is draining 18 times faster than it is charging and will inevitably discharge quite quickly.

Although fitting an MS621 battery is common with GPS modules, its not suitable as a backup method if the GPS is to be used for a couple of weeks or more. A different backup strategy is needed.

Stuart Robinson

January 2019