Hello everyone!
I have been reading this forum for a couple months as it is related to what I am doing but have never actually posted, I have a lot of questions since RF is not exactly my field of expertise but here is one.
In a short sentence, We are developing a small 5x5x5cm satellite with its communication based on an SX1278 using the LoRa protocol. We are also using FSK and Direct mode with RTTY in order to have a backup and expand the communication options for users. LoRa is the main Focus though.
This has been proven to work on TTNsat-1 using 125khz bandwidth at SF11 and 160mHz.
However, due to bandwidth limitations by the IARU and the increased range of lower bandwidth we are aiming for the lowest bandwidth possible. The only obvious problem with this is the limitation of the transmitters crystal. Another issue to take in mind is the Doppler effect which causes approximately 10khz of deviation during a pass.
We are currently using the DRF1278 Modules at 62.5khz that have a crystal accuracy of -+10PPM, based on the Lora calculator this is within the range of the required crystal. Tests show that they maintain communication with a temperature differential of approximately 60ºC. I am unsure on how much each PPM of difference will make to the frequency offset, it looks to be correct though taking in consideration Lora can tolerate a 20% frequency offset of the bandwidth.
With Doppler and the more extreme temperatures of the earth, this would most likely not give us enough headroom for proper communication unless we increase the bandwidth.
We have implemented higher bandwidth AFC tuning packets but are unsure on whether we will be allowed to use them.
The clear solution to this is the use of a TCXO LoRa module. However, we cannot seem to find a TCXO LoRa module on the market, and the best crystals we could find where ±10PPM.
We can probably manufacture our own custom module for the satellite in the future but for the moment would rather use a proven working module.
Ideally we would use 7.8khz but realistically with the temperatures of space and Doppler shift it would be impossible. 62.5khz can handle 12.5khz of frequency shift, leaving us with 2.5khz for the crystal. Not sure if a TCXO could handle it.
125khz is well within our link budget however we are unsure on whether the IARU would approve it, I would rather go higher to avoid issues and guarantee some margin for error.
I was curious about whether you had checked on the SX1276 errata. Looks like 62.5kHz is halfway without massive WARs, but anything else is. gives me kind of a lot of grief along with frequency hopping.
I’ll put up some code for the Murata CMWX1ZZABZ in a few days for direct Radio access in Arduino … perhaps something to take a peek at for testing. This module has a TCXO, so good to use as a sandbox …
I actually had not taken a look at that document, are you referring to 2.3 table 1?
I had a look at the Murata device but unfortunately, it does not operate on our require frequency, not sure if it could be used with an Arduino like we are doing now.
The RFM95TW uses a TCXO though right now all our system is based on the Semtech chips.
Could we just replace the crystal with a higher quality one or a TCXO crystal with the same footprint?
Power consumption is not an Issue, we are experimenting with deployable solar panels so there is power to spare.
Technically if the pins are the same we could just replace the Crystal. We have no problem designing or just replicating an existing SX1278 module, the issue is that the smd components used are smaller than what we can solder ourselves and space is a premium.
For terrestrial applications then a TCXO might well be the answer for low bandwidth operation.
Whilst a TCXO might help a little bit for a satellite operation for such low bandwidths, it cannot be the whole answer.
The capture range of LoRa is specified as 25% of the bandwidth, in practice I have seen it a bit lower than that, maybe closer to 20%. Now I understand the possible issue with the IARU in using wide bandwidths for small sattelites, so its possible they could restrict you to 20.8khz bandwidth.
At a capture range of 20% TX and RX are going need to be within around 4Khz of each other. Doppler for the satellite is going to be +- 10Khz over the pass, therefore even with perfect crystals you may not get reception. So you need a reception method that works with a +-10Khz TX frequency variation and if that is solved then TCXOs may not be necessary at all.
My suggestions;
Contact the IARU as soon as possible, get a licensed radio amateur to do this. You might find you will be able to use wide bandwidths after all.
Static frequency variations in crystals (used on LoRa modules) are very easy to compensate for, what you need to do is measure this temperature varaition. This is also easy to do. Assume a satellite temperature variation of +-30C over an orbit. Your average freezer will go down to around -20C. Program the LoRa modules to transmit an FM tone, measure the frequency when warmed to 30C then when its been in the freezer a while. You can measure the frequency of this with a low cost handheld frequency counter, the type with a small antenna.
Hey Stuart,
Indeed after looking at your temperature data, we could just compensate for temperature, this would not compensate if it was different to what we expect and adding a TCXO is not that complicated from what I understand. I have been doing some freezer tests with a temperature difference of 60c as you say and have compensated accordingly.
As long as the IARU and the Spanish authorities allow us to use a bandwidth of 41.7kHz or above we should be fine, I just passed my HAREC amateur radio operator exam yesterday and will contact the IARU once I receive my callsign, Problem is the Spanish authorities also need to approve the satellite before we apply to the IARU so we’ll have to ask both.
I’ll see what is the highest bandwidth we can use with them though 62.5kHz to 12kHz is something we would be comfortable with to leave some margin for error for ground stations.
Just a suggestion. Why not work around the doppler effect by using multiple receivers in parallel with a small frequency offset. Just like a LoRaWAN gateway with it’s multiple channels. Then you only have the frequency stability on the transmit side to worry about. And a trick question, do you have to take in account the doppler effect according to the regulation, or do you just have to transmit on the right frequency and bandwidth? Why not receive on the satellite on a wider bandwidth and transmit on a small bandwidth?
Hey,
Well we have thought of connecting the ground stations to a server where it could receive live info on the satellite’s pass based on its position and your position, therefore it would compensate during the pass. I don’t think this is too hard to do and the Doppler effect is well documented at different elevations for our altitude of 600km.
The satellite will not regulate its frequency at all and will be fixed in frequency, if you transmit from the ground station as uplink you also need to compensate for doppler.
Thats sort of a solution, you could use the frequency error on receipt to compensate for doppler and temperature variations.
But that would only apply to a single receiver at one point of the globe and the compensation would be wrong for other locations.
There are programs designed to take a set of satellite orbit parameters (TLEs) and use them to shift the frequency of Amateur radio receivers that have the appropriate interfaces. Not seen any adaptions for LoRa devices and a LoRa device has a very low frequency shift tolerance, 1-2% of bandwidth, during actual packet transmission, so you would need to be sure not to shift frequency when a packet reception was in progress.
That’s what we are trying to implement, though just having a high enough bandwidth for it to work would be ideal and hugely simplify the reception process. A combination of the high bandwidth AFC packets and an automatic correction based on the pass of the satellite could probably fix our issue if we would have limitations on higher bandwidth duty cycle.
I used these modules in a project where also only 25 kHz max. bandwidth of transmission was allowed. They worked quite well down to 7.8 kHz BW with SF12 where on-air time for a single (few bytes) telegram is in the region of tens of seconds.
Of course you will need two devices with TXCO to get this working well.
What never worked well (even in labratory conditions) was mixing quartz and TXCO modules for narrowband operation with high SF setting.
So for 160 MHz you could use these modules but the price was about 30 Euros each.
Their 433 and 868 Versions do not have TXCO.
For what we need, Ideally we would like to use the 433mhz band since cheap 433mhz LoRa modules are readily available, worst case scenario we can modify some 433mhz modules or design our own modules to use TCXO crystals. We are trying to make the ground stations the cheapest possible so anyone can receive the signals.
The IARU just replied and they are apparently fine with us using a bandwidth under 100kHz and may even accept slightly higher (i.e 125kHz) if it does not cause major interference. They are just worried about the fact that the LoRa signals will be encoded, we will inform them that we will make all our decoding information available regarding the setup of SDR decoders and DIY ground stations. Will that be enough?
The worries about ‘encoded’ signals did prevent spread spectrum being used under Amateur rules in times gone by. There were very specific restrictions in the US, but these disappeared some years back, the IARU may not appreciate that.
In this case LoRa is propriety so the exact method of encoding may not be available to be specified but given that you will be making the LoRa parameters used known, just reassure them that LoRa ‘decoders’ are widely available in several forms and that millions must be in use by now, receivers are very easy to build. Be sure to tell them you will be publishing DIY plans for Amateurs to build there own receivers.
With LoRa the transmit power is spread over a wide bandwidth so in the relatively narrow band of a FSK signal (3-5khz) there is very little signal to cause interference. Its unlikely that you will cause interference, especially as LoRa is typically operating at least 10dB below the noise level of most other systems.
Of the FSK data systems one of the most sensitive is FSK RTTY and It would be simple enough to do a practical experiment to see how weak FSK RTTY signals are affected by a relatively high power local LoRa transmission. The HAB software I wrote has a FSK RTTY test included, I used it to compare the effectiveness of FSK RTTY versus LoRa. It would be straight forward to use it for such a test, and the IARU would appreciate that you have investigated the possibility of interference.
On point to consider, is that if the satellite has command and control capability you need some method of ensuring its not accessible to third parties. After all LoRa transmitters are easy to build, and you do not want your satellite hacked.
Hey Stuart,
I’ll make sure to reassure them regarding the accessibility of LoRa receivers and our intention to publicly share all parameters and guides on how to receive the satellite.
We are potentially looking at implementing a “repeater” aspect where the satellite may be used by third parties for testing uplink or sending messages. We still have a lot of development ahead regarding security concerns on how we can avoid getting our satellite “Hacked” and it is still just an idea.
I am however very reassured by the fact that they are potentially allowing us to use 125khz and will be able to use 62.5khz, this was the single largest concern since our satellite is based on LoRa.
As far as testing is concerned we still have a lot to carry out before we make the request, are you referring to LoRa interfering with FSK RTTY signals externally of the satellite or on the satellite itself? ( As we are have RTTY integrated)
We will now start writing all the documentation for the IARU request and coordinate with the Spanish authorities, I’ll send you an email with our documentation before we formally send the request.