Since the last post was made, a lot of progress has been made. 2 device manufacturers have reached the stage where they are investigating supply chains for individual components on the board, and 2 agencies that facilitate FCC/CE certification have given the initial green light for the device specs.
Yesterday, I established contact with a company that has launched LoRa satellites into low Earth orbit already. They have assured me that our devices can indeed communicate with their satellites as a relay. We are looking at using Meshtastic by bouncing data off a satellite. Once our initial prototype is materialized, we will commence testing with the satellite constellation to judge performance and reliability.
We will probably need to exploit the 7.25 or 10 kHz bandwidth option to achieve this. Your inputs are welcome.
UPDATE June 29, 2022: We were able to speak to Lacuna Space and they confirmed that we can use standard LoRa modules in the 868/915 MHz ranges. There is a delay in message relay, between 9 to 90 minutes as of now. This will improve in the future as they launch more satellites and establish more ground stations. For now, it is confirmed that our communicator will be able to send out SOS messages with location data, for example, if you are stuck at sea or on an island.
Are these two frequencies available from the FCC for this purpose? Will the user be required to obtain a HAM operator license? How much of an investment would are you thinking about?
I checked out some custom channels a while ago using the narrower bandwidth options and even with supposed “china tcxo” included on my boards it was obvious there would be difficulties.
Looking at the chirps with an SDR you can clearly see how the center frequencies are not well aligned. I can’t seem to find the images I saved but I remember seeing >7kHz deviations regularly.
Makes me wonder if there is any ability to sync center frequencies based on the RX packets but I highly any of these PHYs are capable of any of that.
@desertdweller59 Which two frequencies? Users won’t’ need a license. We don’t need to invest anything from our side, these sat comm companies have a monthly subscription usually.
@costo I have still not received a briefing about the exact parameters and frequencies they use but with that said, they have tested it with conventional LoRa devices like sensors used for farming, etc. and they worked. So I can only assume that conventional low-power LoRa devices will work with these satellites. I said we will “probably” need to use lower bandwidth to get the signal to space. You are correct about the doppler shift and from what I know there is some sort of solution to mitigate this.
@kalestew I would love to send a prototype out to you when it’s fabricated. You seem like the perfect person to assess the flaws in our device and your feedback will be valuable! Is there any TCXO that performs better than the mentioned subpar “china TCXO”?
Ofcourse you must be able to see/calculate your frequency differrence from the needed frequency.
A SDR will be very helpfull for that.
I have experimented with the frequency_offset and it turned out the parameter was in MHz.
So if your offset was -7kHz the parameter in the CLI needed to be -0.007
Now this is an interesting area of discussion that probably involves tests that I am not qualified or capable of performing but I think it hits at what I see as a need for better understood hardware that matches data sheets and has support. This is a main reason I see a more polished commercial option like you describe here as so valuable to this community.
I am under the impression that my newest TBeams with the latest and most powerful modems from Semtec have a are advertised with a tcxo crystal source. Not an expert in the area personally but I know Crystal sources come in many many flavors and the impression I have gained from this community and my limited experience so far with the hardware is that nobody has put much together with polished components and have mainly aimed for easy profits; what’s out there from lillygo is impressive but sometimes lacking with the performance the community is after. I really suspect that someone with more RAK or other manufactures equipment they will see tighter performance on the SDR. As Costo pointed out, there is a way to correct for an offset and I’m curious how this will preform with the existing lillygo products. I look forward to testing this with my hackrf.
@Neil is also making new interesting commercial products and I am sure he is using a good crystal source.
I would be so happy to test any hardware! I am rather new here but I have a good breadth of knowledge to put these sorts of devices through their paces.
I think after reading this thread the main thing you have to decide for the project is if you aim to maintain compatibility with vanilla Meshtastic 2.0 devices. While you definitely don’t need to, those efforts should surely be the most beneficial and exciting to this community, openness aside.
After all my community finally has my repurposed tbeams setup as Wi-Fi clients setup as routers at their houses, I really want a polished commercial product to enjoy my network!
Humm I think I must have glossed over that section in the docs. I would love to test some more to confirm and maybe make a few simple edits to the docs. — might be my motivation to get going on my python courses and contribute more
Is the off set dramatically affected by temperature? If so would it be possible to use the esp32 (or other processors) internal temperature sensor to select different offsets?
The most basic use case that came to mind is typical day vs night temperatures. In many parts of the world large temperature ranges (and thus offsets) are common. When I’m in Bend, OR sub zero temperatures are common during the winter season, and in summer stay inside with the AC on high temperatures are also common.
@tinkberbot Thanks. There are a lot of amazing people from the community chiming in along with ODMs that are helping out, so all credit goes to them.
@Spor7biker I think temperature-induced deviations can be mostly corrected by a good TCXO if I am not wrong.
@costo I was finally able to establish a lengthy dialogue with Jon from Lacuna space. They are using 868/915 MHz and they said that for the doppler shift “we take care of that in the satellite SRD”. Not sure what it means but I will get on a call with them soon to discuss more details. I think the SRD could be the specs or LoRa config that we need to use to compensate for the Doppler shift, so I think you are right, 7 kHz bandwidth will not be feasible.
UPDATE June 29, 2022: We were able to speak to Lacuna Space and they confirmed that we can use standard LoRa modules in the 868/915 MHz ranges. There is a delay in message relay, between 9 to 90 minutes as of now. This will improve in the future as they launch more satellites and establish more ground stations. For now, it is confirmed that our communicator will be able to send out SOS messages with location data, for example, if you are stuck at sea or on an island.
Defiantly, my understanding is that is the point of a hardware based TCXO. Unfortunately many inexpensive LORA devices have no TCXO, let alone a good one.
I remember several posts from users attempting to build networks for remote communities. Several users have been concerned about sub zero temperatures. A cheep relay node may have better performance on the fringes of range if it can account for big swings in temperatures be it on top of a mountain with day / night temperature swings or a mobile device that is used inside a heated home and also taken out on a snow mobile where the temperatures can drop so low the battery stops working.
I just brough this us since the feature was mentioned and is being worked on right now. I’m not a proficient programmer so I don’t know how hard or time consuming it would be to extend this particular feature.
Hi, I just quickly went through Lacuna Space website and what I can see is that they basically mention LoRaWAN and not just LoRa. I guess the meshtastic LoRa packet differs from LoRaWAN- packet and thus is not routable.
I do not just have Meshtastic LoRa devices, but also several other devices that send LoRaWAN compliant packets and once they reach one of the gateways, they are forwarded to, in my case, the things stack and I can then collect the data with mqtt-client.
So, it is correct that we could send LoRa-packets to satellite, but whether it is able to forward those meshtastic packets somewhere remains unclear to me
I wonder how hard it would be to support the native Meshtastic mesh implantation and similar to the MQQT gateway an option to relay messages with a LoRaWAN gateway, terrestrial or satellite.
I don’t think I get it.
Lacuna-Space is working in the field of IOT using LoRaWAN.
Many devices (nodes) sent messages to a gateway and few messages are sent back to the IOT devices.
While Meshtastic is about a mesh network without gateways and nodes, every device has the same function and is redundant.
I would go for a satellite phone, more reliable and certainly affordable when your life may depend on it.
