I am the lead developer of the FossaSat-1 pocketqube satellite launching into LEO this october aboard an Electron. We just got coordinated a frequency of 437.600 MHz by the IARU for the satellite so I though it was an appropriate time to start asking the community.
For those that don’t know the project, this 5cm sided cube will mainly test the use of the LoRa modulation in space. (https://Fossa.Systems explains the project pretty well). Its a mostly open source and crowdfunded project.
Our LoRa configuration as default is SF11, CR4 at 125KHz. We can however change some of these settings for experimental purposes. RTTY is simple 45 baud ASCII stuff, seems like there’s no decoder for SatNOGS though.
Now regarding its function, the satellite mainly functions in a loop as follow:
LORA RX on ISM band (experimental ping/pong style commands or messages to be repeated)
LORA RX on amateur (same as ISM but higher power and control commands)
LORA TX Repeated messages / ping pong
Sleep depending on batt voltage (couple s)
Every couple loops the following occurs:
RTTY Telemetry Packet TX on amateur band
GFSK RX on amateur (commands)
The loop is a couple of s so the latency between repeated messages is not much. LoRa can be recieved on the ground using a copper wire and a 3€ module, it would be great if reception could also be carried out on satnogs though. There has been some work on a LoRa GNU decoder which seems to work with SF11 but I still have a lot of testing to do and not enough time. I am guessing the RTTY should be easy to integrate considering the amount of external decoders.
Just wondering.
When you say LORA RX on ISM band does this mean it is going to receive it then during the LORA TX repeated repeat that stuff?
Same question for the LORA RX on amateur.
I’ll have to do some reading on LORA before I provide too much comment however I’m interested in your choice of RTTY. I’m assuming when you state “LORA Telemetry” you actually mean “FossaSat-1 Telemetry” as it would appear that the LORA protocol is proprietary and closed and therefore would not normally be sanctioned for use within the Amateur Satellite Service. If in fact you do mean 'FossaSat-1 Telemetry", then I’m interested in why RTTY when AX25 packet would be easily receivable for most amateur satellite stations (including those running linux using something like FLdigi or DireWolf). I’m also interested in your main loop structure, as this would imply that your ‘command’ transmissions will need to be critically timed to be within the ‘LORA RX on ISM band’ and ‘LORA RX on amateur’ windows, likewise for your GFSK RX window. Also, how do you expect the SatNOGs community to receive LORA signals?
SatNOGS may not be able to incorporate a LoRa decoder due to the patent issues.
Yes, there is a GNURadio decoder: https://github.com/BastilleResearch/gr-lora
However this is reverse engineered, and I guess is in breach of the patent? Not sure how that works for open source projects.
As a bit more philosophical question, I’m not sure we would want to be encouraging the use of proprietary/closed data modes for amateur radio satellite communication. I understand why LoRa is a possible good choice for sat comms (should be resilient to doppler, good in-band interference rejection due to the FMCW modulation, etc), but maybe not on the amateur bands?
“LORA telemetry” reffers to FossaSat-1 telemetry transmitted in LoRa modulation. LoRa is indeed proprietary, millions of devices capable of decoding LoRa exist on the market though and the link budget possible using lora is particularly interesting for people that cannot afford large setups. A 3$ chip from ebay and a copper wire will get you a link on 10-100mW at LOS. RTTY and GFSK are implemented simply as a backup incase LoRa gives us issues, RTTY was simply chosen due to its ease of use in the amateur community (Particularly in Spain). The loop takes around 4s, simply listen in and time your transmission or transmit for a maximum of 4s to be sure your command is recieved.
Could be an issue, I understand the patent breach would only be an issue if the technology is being sold / comercialised.
The idea with LoRa is that amateurs can test cheap and low power links, for example for IoT sensors. A student or school for example could afford a 3$ chip but not an SDR and an antenna. You can read the link budgets for yourself though, quite impressive.
Thanks for the info. A patent breach is a patent breach - in most jurisdictions it doesn’t matter whether there is financial gain of not - there is a material loss to the patent owner.
Understand the intent - just not sure of the legalities around the use on the amateur bands.
In that sense developing a decoder would be considered a patent breach. Using semtech chips though is the intention anyways taking in consideration their better sensitivity and inexpensive price. Regarding RTTY though, would there be a way of implementing a decoder for Satnogs or just rely on people using FLDIGI or MMTTY?
I suspect that better LoRa receive performance could be achieved using an already well-performing antenna & SDR setup, which has been optimised for low noise figure. There’s only so much you can do in a $3 chip. Plus there’s the whole idea of re-using existing ground-station setup.
Unfortunately the patent issues make that difficult.
A RTTY decoder would be possible I guess, the issue is knowing what data is valid due to no FEC.
I’m not sure if I’ve understood correctly, but from your description it seems to me that FossaSat-1 will receive LoRa messages from unlicenced users in the ISM band and retransmit them over the Amateur satellite service. If so, this is probably a violation of the Amateur service regulations that forbid third party traffic.
In this case the IARU does not permit communication on behalf of a third party. The communications transmitted on the amateur band from FossaSat-1 are intended for the purpose of self-training, intercommunication and technical investigations without pecuniary interest, without broadcasting anything specifically for the general public (ie: television signals, sound etc) . Amateurs are the only intended receptors (although other non-amateurs may also receive data).
Guess it depends on the jurisdiction: "The original organizational purpose of the American Radio Relay League or ARRL which was organized in the early 20th century (1914–15) was mainly for the purpose of relaying third party messages. In many parts of the world outside North America, it is illegal for amateur radio operators to pass messages on behalf of third parties. { https://en.wikipedia.org/wiki/Amateur_radio_net }
Personally I am using hoperf LoRa modules with TheThingsNetwork and have sent packets about 9km on the low power they use, just not in any way related to ham radio, only ISM band (913.7MHz)
Indeed, I agree with EA4GPZ. Although I am not sure on the situation of Amateurs transmitting on ISM band. What can indeed be done is experimental Ping/pong on ISM (return RSSI or SNR) for non amateurs. Repeating non amateur messages on messages band is not legal though. We would need to apply for an experimental / commercial ITU frequency to repeat non amateur ISM messages.
Given it looks like FossaSat-1 is getting closer to launch, I’m wondering if there’s been any further thoughts on the LoRa aspect of this. While gr-lora does exist, is this really something that can be safely integrated into SatNOGS with the patent issues? Would we even want to, given LoRa’s proprietary nature?
It’s also worth noting that if we even want to just log IQ from this satellite, all of the current decode chains are running at too narrow a bandwidth to capture all of the 125 kHz BW.
Any further work here? LoRa is a compelling technology with cheap radios that work to LEO. It seems the patent issues are argumentative. Why not enable a LoRa interface that uses existing single chip radios and move on? Completely eliminates any patent discussion and allows for use of an existing low cost radio technology at scale.
You can always feed raw data packets into the DB via the SIDS interface. This is modem-agnostic and has been around forever.
As for supporting LoRa elsewhere… well LoRa is essentially a dead-end in terms of experimentation. You get the modem chips, configure it, and thats it. Yes, I can see the appeal in terms of simplicity, but that’s all it has going for it. Want to tweak low-level modem parameters to improve performance? Good luck, you’ve probably just broken compatibility with other receiver chips (e.g. FossaSat-1). Want to upgrade the FEC to something modern? You’re pretty much locked out from doing that.
The features that make LoRa appealing for terrestrial applications (robustness to in-band interference) are less of an issue for satellite applications. You just end up using far more bandwidth than is necessary for a given user bit-rate. You’re using tens of kHz (or even 125 kHz…?!) for something that should really only take up a few kHz of bandwidth.
As an open source community, we should, and can do better than this. Modem development is not black magic. As an example, David Rowe (codec2/freedv) and I went and designed our own modem for telemetry from high-altitude balloon flights ( https://github.com/projecthorus/horusbinary ), and are currently working on an upgrade to switch from Reed-Solomon FEC to LDPC which should improve performance.
In terms of hardware, there already exist chips (e.g. AX5043) which perform the basic modulation/demodulation (nFSK, PSK), upon which can be layered more complex FEC schemes for improved performance. Any modulation produced by these chips can be demodulated using open source software, allowing it to be integrated into the SatNOGS network.
