Future Strategies for AU915 and AS923 in Australia

Hi

the other 4 (5) mine is off gateways are all owned by others that I grew up with, and we decided to dive in because of the potential of LoraWAN, now my main motivation i have put my support in is because if this or any other community first network is lost. we will all have to pay the overlords for the privilege of their solution. which will choke hobbyists, and see our younger generation never learn programming and experience what it is like to do something great for no reason but ‘because I can’.

It does pain me to say the DPI gateway pre-dates ours, but ours appear to function far more reliably and at a fraction of the cost. The devices RAK are pumping out are certainly some of the best for price. I also have found over the year or so that the Australian handler has been a poor performer. all the apps I have mucked with are located on the Singapore one. while TTN has been awesome because of the freedoms that we are all able to enjoy. I don’t find much use for trackers and the like when the nation is divided. and there appears to be arbitrary filtering on some gateways.

@Maj is it possible for meshed to get in touch with some of the government deployed gateway owners and compel them to upgrade to a dual radio gateway, because it appears to be the standard in which the community would like their support? You did mention it was their desire to provide access to the community. And as with all technology times change…

Yes, this is definitely doable. We are in discussion with our customers about application and gateway migration to V3 and we will open the dialog about dual band support for those gateways that are AS923 only.

Just thought I’d chime in. I attended a talk by Senquip the other day. They’re going with LTE and WiFi for their application - the primary reason they quoted for not including Lora? The complexity of the network. It added to much to their hardware engineering efforts, and was too complex for their target end users.

Here’s a direct link to that section of the livestream:

Who presumably have power available everywhere.

I’ve got some pretty messed up GSM/LTE setups that have evolved over the years and WiFi coverage can be a challenge. So even those can get ‘complex’ for users.

But neither can run off battery for very long without some sort of power source, either minion changing batteries or solar, which is what makes LoRa so special.

So whilst this company’s strategy is interesting, it is comparing Apples with Oranges.

These guys use a LiPo with Solar option, but he reckons even going with AAs could get a few years - theoretically a decade in an impractical best case scenario - thanks to the low sleep current and being able to only phone home if/when it needs to. Might be higher power while it’s on, but it doesn’t need to be on much.

Australian end users are familiar with LTE, and familiar with WiFi and if they get a device for Australia, it works in Australia - on any LTE network, wherever they are.

I think this kind of really blunt, honest feedback from someone who’s had a serious look at using LoRa for their application is really valuable. Saying it’s Apples and Oranges is not true and a bit of a cheap cop out.

IF TTN is going to get out of its rut in Australia, this is the kind of person who needs to see it as a viable choice - and I think it really reinforces the importance of standardising the network.

LoRa has a much lower cost per device, doesn’t come with any subscription charges per device and if coverage is poor, it is relative inexpensive to provision your own coverage.

I used GSM since 20+ years back. It has its time and place, as does WiFi, 2.4GHz modules, 433MHz modules, microwave, dialup (still), actual runs of cables and IP over Avian.

I’m not sure how saying they have considerable differences is a cheap cop out, for £15 (volumes around the 50 mark) I can build a device with batteries and have a good expectation it will just run for at least two, likely three, maybe four years without any other additional costs. I can’t do that with any other technology I know. So all I’m saying is, sometimes the extra effort is worth it.

If you disagree, I’d love to hear your views, particularly with your experience in the spread out environment which you are in, which parts of the UK due to patchy coverage mirrors at a microscopic scale. We still have some startling dead patches for any radio coverage (like the middle of the second most visited National Park in the world). I’d anticipate you can’t just get a new mobile tower setup, so what else would be available to you?

TTN in Australia, just like it is in the UK for me and everyone in every other country is us/you. If it’s in a rut, getting communities together to solve problems will move it forward. If along the way there are issues with provisioning & complexity, maybe we could collaborate to resolve them?

I think a business in the process of launching its product range is going to go for low hanging fruit like well provisioned areas and is inoculating, via marketing, potential customers coming to them asking for a LoRa version of what they offer. This sort of cherry picking suits me, as I pickup the work where larger companies can’t be bothered.

1 Like

First of all the community (don’t forget TTN is a community network) recognized the issue and is working on it. However forcing people to abandon their investments in existing nodes isn’t likely to win then over so this will take some time.

Second, LoRaWAN in Australia does not have nation wide coverage and given the community nature of TTN it will never happen for TTN (may-be for commercial providers but that’s doubtful as well). Technology using the same infrastructure people use for their (smart) phones will always have an advantage. Same for WiFi as it doesn’t require additional investments due to existing infrastructure.
Then there is the issue of TTN not having an SLA which for a commercial product might well be a deal breaker. All in all you are comparing apples and pears…

1 Like

@descartes don’t disagree with you, but I think you’ve missed my point entirely. I’m not arguing the technical merits of LoRaWAN vs LTE vs Wifi. I’m talking about long term strategy.

The technical benefits of LoRa are irrelevant if it’s too difficult to learn or access relative to what already exists - the reality is that for the majority of people the difficulty is not currently worth the effort. That’s why the dvorak keyboard layout has never taken off. We are in a very small minority of the population who have both the skills and inclination to use it.

@kersing This technology has so much potential benefit for society, but for the most part, LoRa is currently stuck in the realm of amateur radio and without serious investment it’s never going to leave that space in Australia. We just don’t have the population density to get it going purely on a community basis in the way it might be feasible in Europe. The best we can hope for is to piggy back off major projects - government or commercial - and that means making TTN in Australia enticing to people like Norman, but in a way which keeps the door open for public benefit.

How great would it be, if there was TTN Gateway coverage across the entirety of the State and National highway network, rail networks, transmission networks, or the NBN? What about the the TSR? Or national parks? We can get there, but not if you need the current level of RF legal and technical knowledge just to get going.

And that means both reinforcing and promoting the technical strengths of LoRa, softening the learning curve to an extent that may not even currently seem possible, and making sure that we’re at the discussion table when conversations are happening.

I’m not saying tear down everything that’s AS923. But I am very firmly in the camp of, it if it interferes with ease of adoption for newcomers, it should go.

Coming soon, LoRaWAN from space: https://lacuna.space

As well as LoRaWAN I also do High Altitude Balloons and fly sailplanes, they to require a commitment to get past the first few misfires, although LoRaWAN is the least dangerous of the lot but also the most likely to be packaged so that it can be accessible at an appliance level.

I can send out kit that’s pre-provisioned and as long as the technician doesn’t try to “install it” but just plugs it in, it all works fine. When they want to learn how to provision things, that’s where it gets harder, I can provide a user interface to sanitise much of it but I can’t stop them a, messing with the console or b, not learning what all the buttons are for before pushing them.

So we end up with a forum like this that has questions at all & every level that leaves people with the impression that this is Rocket Surgery. But as I said before, it’s up to the community - if we think this technology has benefits which we wish to share, then we need to come up with the tools to make working with it easier.

1 Like

Now this is a good idea - though standardising this will be an even bigger nightmare.

Perception is reality. It’s a real pain, but an fact of life.

110% on board there.

Many people believe their perception is reality but reality is absolute. It’s how people view the world that determines how they do things. I didn’t perceive any issues with LoRaWAN when I got stuck in to it in earnest a couple of years back. But then I’ve never forgot how to learn things and, to borrow a NLP phrase, I know the map is not the territory. [Nota bene my user name!]

LoRaWAN is harder than walking & chewing gum, but once people learn to learn, they can methodically pick up the basics in a day and progress from there. Still doesn’t stop us from helping them out by making the journey simpler.

Maybe, but people act on their perceptions of reality - whether or not those align with facts. That’s what I mean when I say perception is reality - you only have to read over this thread to see that!

TTN community is not going to deliver your investment required as you state yourself.

Covering Australia with gateways that have an average coverage radius of 30km is going to require a major investment and any commercial entity putting up that amount of money won’t use a network without SLAs. In my opinion best you can hope for is them peering with the TTN community network if they have sufficient business to cover the network cost and de not need to sell access (telco) to recover there investment.

Here is an interesting development that could be implemented in the AU915 band which is not possible in AS923. With the AU915 band, particularly for gateways in FSB1 to 5, having different receive and transmit frequencies allows the gateway to receive while transmitting.

I must admit the frequency separation between Rx and Tx frequencies in AU915 is smaller than in the US915 band and this will have an effect on performance. (FYI, scroll back to the beginning of this thread where you can see graphics showing the AU915 Tx frequencies overlap FSB 6,7 & 8).

Will be interesting to analyse and determine the requirements for external RF (antenna) filters required to prevent the transmitter overloading or deafening the receiver.

Semtech Unveils LoRa® Corecell Reference Design for Full Duplex Gateway Applications Enabling LoRaWAN® Gateways to Receive and Transmit Data Simultaneously | Business Wire

Some early ref designs had option for seperate Tx & Rx antenna ports - with no RF switch? If I recall I think some RAK? concentrator boards were like that - potential therefore possible for one GW site to have two ants physically seperated - horizontally offset by +/- say 10m on ultralow loss cable, with also vertical seperation (potentially more improtant if can keep them in respective vertical nulls - perhaps +2/-2m to +5/-5m, and potentially sith some level of RF attentauting material inbetween? May still require some filtering but make electrical task easier?

Hi Jeff, Just looking at Semtech data sheets and its only for the SX1302 chip (SX1303) and if I remember those early concentrator boards used the SX1301 chip.

Looks like the Tx-Rx isolation needs to be >50dB as this is the isolation they are using in the test diplexor. Fairly typical figure for a Full Duplex radio system so I expect the RF engineering (as you proposed) to be straightforward.
Limited reference design information currently published, some for CN430 and less for US915, but its a start and enough to get us thinking.

Yes but remember the SX130x (1,8,2,3) is the (Digital) BBand device and LoRa + legacy mod/demod not the actual RF where the black magic has to take place - there are seperate RF device(s) for front end (SX1256/7 etc. for most designs (think some used an equivalent from e.g. ADI)) depending on target band - typically handling 4/8 x 125Khz channels over 1Mhz spread IIRC and which can also be further isolated/shielded for RF TX/Rx path and interface to BBand is then just classic digital i/f -handling I/Q data. :thinking: time to dig into old notes and refresh as I’m starting to forget a lot of the early stuff! :wink:

Hi Jeff, my assumption this only applies to SX1302 (03) is based on the modified packet forwarder code which is available on github only applies to the SX1302 (03). In that code I can see an extra configuration parameter "full_duplex": true, or "full_duplex": false, which I assume sends immediate or queues the data in Half-Duplex.
As you correctly point out it could also apply to the SX1301(8), but I assume only if the associated packet forwarder is modified.

Are you sure? Last time I checked the newest packet forwarder supported all SPI based configurations.

Oh, did not know that. That’s the benefit of this Forum.

I’ve been looking in GitHub - Lora-net/sx1302_hal: SX1302 Hardware Abstraction Layer and Tools (packet forwarder...) and assumed (here I go again) it only applied to the 1302 series.

Thanks again for the heads up