It’s worth noting that our beacon packets also contain a 0.8 second CW message at the beginning of each transmission. This is to aid in folks searching for the inherently wide bandwidth LoRa packets.
A shame the proprietary LoRa modulation was used. This means there is pretty much zero chance of a software demodulator ending up in SatNOGS, due to the concerns around LoRa patents.
I understand the ‘ease of integration’ of the LoRa chipsets… but the proprietary nature of the modulation goes against a lot of what SatNOGS and libre.space stands for.
I’ve added a CW transmitter for each of the satellites, so people know about this transmission too. Just to confirm, it is on the same frequency, 915.600MHz, right?
Understood… and I share your concerns around the proprietary nature of LoRa modulation. However, the ‘easy of integration’ as you put it and the advantages it affords university science-based missions can’t be denied. LoRa makes it easier for an amateur satellite team to close link. period. In many scenarios, it lowers the barrier of entry for amateur teams to have robust long range coms.
I’m optimistic that a GNU radio pipeline will be released to demod packets … I hope we can find a way to have SatNOGS demod LoRa without facing legality concerns.
@vk5qi what could the community be doing/advocating to improve the situation? Let’s either educate and provide an alternative to LoRa or find a way to apply pressure where it matters
Sadly I can’t point you at a ready-to-use system which is a single chip. Open source communities don’t have easy access to silicon foundries to produce such a thing. libre.space is working on a radio board based around an AX5043 chip I believe, which is capable of doing FSK and BPSK-based modulations.
Unless you can get a ‘OK’ in writing from Semtech, or provide other legal advice that it’s fine to use a reverse engineered implementation of one of Semtech’s patents without exposing us to legal issues, I don’t see a project like SatNOGS ever including a LoRa decoder. You can continue to push received packets into the DB for display, but don’t expect to be able to call on the large ground-station network for support. (Also being on 915 MHz really doesn’t help with that either - what made you choose that band?!)
It’s also worth noting that existing modulations schemes like the forward-error-corrected BPSK modulations used on the Funcube sats are just as, if not more, robust than the LoRa modulation, and they are not incredibly bandwidth inefficient like LoRa is. I’m sure someone like @EA4GPZ could provide more detail on that.
LoRa was designed for a congested ISM-band environment, having to deal with many co-channel interferers. In the amateur space segment, LoRa uses up huge amounts of bandwidth for no good reason (62 kHz or 125 kHz for what data rate?!), and has the potential to interfere with other users. If LoRa continues to be used on the amateur band, it should be relegated to a corner of it where it is less likely to cause issues.
In fact I tweeted precisely about this a while ago.
Regarding the use of 915 MHz, I think that band is not allocated to the Amateur satellite service. It’s allocated to the Amateur service in ITU region 2 only. This means that most Amateur satellite enthusiasts and trackers don’t have the equipment to receive on 915 MHz.
UVSQ-SAT is already in DB. The rest are going to be added by @BOCTOK-1 later today. @XtopheSwl please let us know if you have any preliminary TLE or any info about the orbit that will help us to create a TLE set.
… I hope we can find a way to have SatNOGS demod LoRa without facing legality concerns.
