LoRaWAN "RADIOLIB_ERR_NETWORK_NOT_JOINED" bypass possible?? ('blind' uplink required)

[K4KDR]

Greetings! Based on the LoRaWAN_Starter example, I have a fully functional ESP32 end device (TTGO LoRa32 v2.1 marked T3_V1.6.1 + Display) connecting perfectly to an existing application in Things Industries.

This was done to confirm all settings, payload format, etc. all the way from Arduino sketch to ESP32, over-the-air to a nearby US915 LoRaWAN gateway, and visible as a received payload on the Things Industries dashboard.

However, the REAL need here is to have a 1-way, blind LoRaWAN transmitter that will transmit to an RX-only IoT/LoRaWAN satellite. The satellite is RECEIVE-ONLY... there is no downlink on 915 MHz.

In testing, I commented out the JOIN lines to see what the behavior would be absent any downlink from a gateway.

//  Serial.println(F("Join ('login') to the LoRaWAN Network"));
//  state = node.beginOTAA(joinEUI, devEUI, nwkKey, appKey, true);
//  debug(state < RADIOLIB_ERR_NONE, F("Join failed"), state, true);

.. the result is:

19:21:39.417 -> Setup ... 
19:21:39.417 -> Initalise the radio
19:21:39.417 -> Ready!
19:21:39.417 -> 
19:21:39.417 -> Sending uplink
19:21:39.417 -> Error in sendReceive(-1101)

RADIOLIB_ERR_NETWORK_NOT_JOINED (-1101)
Unable to restore existing LoRaWAN session because this node did not join any network yet.

... which of course is not a surprise.

For a test such as this, how can the UPLINK:

  // Perform an uplink
  int state = node.sendReceive(uplinkPayload, sizeof(uplinkPayload));

... be executed when there has been NO JOIN or other communication from the network / gateway?

I am working in the Arduino IDE environment with RadioLib 6.5.0 installed.

Many thanks as always!

-Scott, K4KDR

[StevenCellist]

Hey Scott, welcome to RadioLib × LoRaWAN! Satellites are interesting... and so sounds your usecase.
As you mention yourself, it is no surprise that you can't send an uplink without joining a network. The starter example shows OTAA, but there's also ABP. ABP works by telling both the node and the server all relevant keys, which in turn doesn't require a dowlink (however, an official v1.1 LNS will send a massive downlink to configure your node anyway, which looks mostly like an OTAA-join).
Now I don't know any of the specifics of the satellites you mention, and I don't know what they expect. So if you have a link to details on what the satellites listen for, we may be able to provide more useful feedback. But in general, this is what ABP can be used for.
However, keep in mind that RadioLib only supports LoRaWAN v1.1, so depending on what kind of processing the satellites do, they may drop packets that don't look like what they expect. Once again, we'd need details on the satellites there.

[K4KDR]

Thanks a million for the reply, Steven!

Well, unfortunately it's very common when dealing with proof-of-concept satellites from (often) very new business ventures and/or University projects that not all information is available. Language barriers are one common issue, as well as that we frequently encounter a situation where the owners of the satellite do not fully understand how their platform works. I do realize how strange that sounds, but MANY of these efforts are by first-timers, students, you-name-it.

But enough of that; the important things here are how to work with the technical aspects the project. In short, I do not know all the answers around what it will take to successfully uplink to this satellite - but the fun is in trying to figure that out. Even the RF parameters are still an open question; but that's not a RadioLib issue. Hopefully that explains why I can't simply copy/paste here a table of all the necessary settings for good folks like you to help me put into practice. (there is no such table YET)

As for the hard-stop issue that caused me to post this request for help, than you SO much for pointing to ABP as a possible way to get around that while still working withing the RadioLib framework. I will pause all the reading thru the RadioLib documentation & code that I've been doing around things like 'isJoined', 'sendreceive', and 'uplink' and will focus my attention on learning all I can about ABP. Thanks again for the direction!

[StevenCellist]

When dealing with satellites, be very cautious with the RF parameters indeed. The official LoRaWAN specification mandates the use of some specific uplink frequencies, but these may be completely different to what the satellite is listening at. And maybe the coding rate is different.. and maybe the bandwidth..

Are you sure that you are looking for LoRaWAN, and not plain LoRa? Because LoRaWAN is encapsulated in a lot of details for terrestrial stuff. I know about Lacuna Space and will be looking to try and use their satellites in a couple of months. But I already know that I will have to change the LoRaWAN specs at multiple points to get something through!

Please report on your progress: I am curious to see how it'll go and happy to think along where possible.

[HeadBoffin]

as well as that we frequently encounter a situation where the owners of the satellite do not fully understand how their platform works.

Both myself & @StevenCellist have sent packets via satellite, me far more than Steven, so you'll have to bear with me but REALLY?

Given the cost of a satellite, the admin around getting all the permissions, the testing etc plus the no small cost of getting one in to orbit, I've not yet met anyone who's got one in to orbit that we are not worthy to even say their name. So it is with some trepidation that I invoke the name of the repro owner, @jgromes, who has actually participated in getting a satellite in to orbit that uses LoRa tech.

Working on the assumption that you have legitimate access or there is open access published somewhere, to save us all a whole pile of messing about, just tell us everything, provider, link to details, satellite being accessed (so we can see the TLE), your inside leg measurement, eggs over easy, etc etc. As @StevenCellist (reminder, he's sent messages up & got them back) says, ABP is the ONLY option for LoRaWAN via satellite (unless it has realtime access to the internet with sub-5 second delay aka what is called an L shape pipe, none flying as far as I'm aware). This stuff is full mega-geek stuff, you'll need to know LoRaWAN 101 the same way you breath, antennas are a whole degree level, timing is everything, hacking is futile, precision & planning is everything due to the gaps between passes.

Happy to assist, but it can't realistically be done without lots and lots and lots and lots of information, ie all of it.

[K4KDR]

Huge thanks to both of you. I'd be asking the same questions - wish I knew more on this particular project; trying to get more info.

I've also worked quite a bit w/ LoRa in general & received/decoded quite a bit of telemetry. Have also assisted numerous Project Teams by serving as uplink station at their direction to get commands up to sats in orbit. And yes, as you're no doubt aware, many of the sats going up now are indeed attempting to find a place in the IoT/LoRaWAN world, and that's the case here. That's why I'm learning a new aspect of RadioLib. Have used RadioLib for years now for my general LoRa needs across various microcontroller platforms, but many of the sats going up now aren't simply using LoRa modulation, but are attempting to be IoT/LoRaWAN gateways. Can't thank you enough for pointing me to the ABP flavor of End-Device to get past the normal terrestrial requirement for 2-way comms. Working on getting a test device setup for that now. As for any LoRaWAN satellite comms, I'll have to gather many more details before finding out if that's actually do-able in this case. Will of course share anything that's published so anyone properly equipped can give it a try!

[K4KDR]

And just to close the loop on the hurdle that prompted this post - SUCCESS! Once the end device was deleted & re-create as type 'ABP', I confirmed proper "Normal" operation by uploading bytes to Things Industries via a regular LoRaWAN gateway.

But NOW, my ESP32 will transmit absent any gateways to communicate with. So, at least in theory I have a configuration that can be used for IoT/LoRaWAN uplink to an RX-only satellite. Obviously now the trick will be to figure out what parameters they are using - all I got on the initial contact was "we are listening for uplinks if you have a LoRaWAN device on the ground". Well, I don't have to tell anyone reading posts in the RadioLib repository that we need a BIT more information than that to communicate to their gateway. Thanks again to everyone and as I said before, if I get any useful info, I'll certainly post it. -Scott, K4KDR

[HeadBoffin]

all I got on the initial contact was "we are listening for uplinks if you have a LoRaWAN device on the ground"

So there's no harm in you actually telling us what project this is as emphatically suggested above - maybe we have detailed files.

[K4KDR]

Oh sure thing! I'm talking about MicroOrbiter-1, a recent deployment from the ISS. While their mission plan talks about uplinks on the "920 MHz" band, they specifically list 922.100 in their ITU filing. However, it would be no surprise if that one frequency is not a complete listing - if they really want to hear generic End-Device ground stations in one of the bandplans (AS923?), they I'd guess they are monitoring more than the one uplink frequency. As for their 400.960 MHz downlink, it's only been CW thus far. I inquired and at least for now, the reply was that they only downlink other modes over Japan. So, short on specifics but at least a general idea of what the proof-of-concept is that they're trying to accomplsh.

[HeadBoffin]

I'd wonder why they'd turn the receiver on over anywhere other than their target area given the size of the sat. Other providers have a schedule for frequency & modulation parameters, presumably so they can run filters to focus on signals meant for them, so just one frequency isn't unusual. And the use of a pretty directional antenna means that most off-the-shelf devices aren't in the running.