Australian Student looking to experiment with budget lora tech

I’m a student in melboune and would love to begin experimenting with TTN here. I’ve been hearing about lora/lorawan for a couple of years and would love to learn by experimenting. Looking at australian forum posts I’m struggling to find information on a budget gateway setup thats newer than 2019/2020. Could someone point me in the right direction please as I’m just barely starting to wrap my head it but am still a complete newbie?

As a first project I would like to add a GPS tracker to my mountain ebike using the device below:

I selected the device above as I can program the esp32 chip to derestrict the 25km/h speed limiter on the bike for offroad stints as per this link

along with hiding the setup inside the frame (curious to see if being inside the alum frame helps or hinders the antennas).

I would also like to add a gateway to the network. Initially I thought something like the Things Industries Indoor Gateway 915MHz TTIG-915-AU
would get me started, but is there a newer better budget option? Most of the time it would be plugged in upstairs near a window but I liked the idea of adding an antenna and powering it off usb-C for a mobile device.

I would love some advice on my choices above and any better budget options that I haven’t come across.
Also, I’d really appreciate of someone could give me an in a nutshell insight to the items below
1/ v2 vs v3 stack, should I ensure whatever gateway I select is compatible?
2/ For the ESP32/LoRa device above, if I select the 915MHZ version, should this theoretically work on both US and AU networks or do I need an AU specific one?
3/ Single or multi channel gateway

Any advice would really be appreciated

Putting the antennas inside the alluminium frame will stop both the LoRaWAN and the GPS from working.

Only multi channel gateways are acceptable and supported. The TTIG is a reasonable budget option.

A ‘portable’ Gateway would still need an internet connection.

1 Like

Thank you for the reply. I’ll go ahead with the TTIG then and figure out the mods I need to make as I go along.
Much appreciated

I have been working through adding a rear hub drive to my old titanium mountain bike and I did think about adding a GPS tracker, the bike is worth quite a bit.

However although I live in a largish city in the UK, the LoRaWAN coverage is nowhere near universal and would cease completly as you get out of the urban area.

For this reason, for my area, a TTN based tracker would not be of much use, far better to buy one of the mobile phone based trackers, far far better chance of getting coverage.

Before deciding on a controller, you need to think through the power consumption and battery life, making a GPS tracker last an acceptable period on battery is not so easy.

1 Like

I’ll probably add a gsm module to the esp32 as a fallback that only switches on if there’s no Lora coverage, as it is where I live in Melbourne has decent ttn coverage.
The board I’ve chosen can charge the attached 18650 battery through the 5v pin and the ebike battery supplies 5v to the display which I’m hoping to hijack. This way the battery should charge when I’m out and about but the main battery switches off when the display controller is of so shouldn’t drain when I’m stopped. I’m thinking the 18650 should give me a few days of GPS updates.
All this is great in theory but from experience it won’t be so straight forward :wink:

If you want to use a T-Beam (whether that is the best device for your application or not) and you want to develop with the Arduino framework, be aware that there is still very little LoRaWAN Arduino library support for the SX1262. A SX1272 based version will still be a better choice for Arduino.

1 Like

Much appreciated, I’ll have a look to see if I can find something similar with that chipset.

There exist devices that are SX1262 based and have Arduino support. E.g. Heltec has a CubeCell device with GPS which has Arduino support.
And there may be others.

But at least for T-Beam boards I would suggest the SX1276.

1 Like

I’m getting excited now at finally trying out Lora. It’s great to have such a helpful community. Cheers everyone for the advice!

One issue to plan for, right from the start, is the amount of air time your ‘node’ occupies when transmitting.

The TTN fair use policy limits you to 30 seconds of air time a day.

Best to plan for maximum distance mode, which would imply a typical air time of 1.25seconds per transmision, so you get a max of 25 position indications per day.

For a stolen bike, location transmissions whilst its on the move may not be much help, the Police are unlikly to put a helicopter out for you. So perhaps a couple of position indications when the bike first moves, and then wait until its stationary before transmitting again.

Will do Cheers. How much txt could I transmit in 1.25 secs? I could take multiple GPS readings and only batch send them every X hour/s?
Or If there is a familiar Bluetooth/wifi signal nearby it would only send once a day unless I send it a message to enter stolen mode which would send as much info as allowed?
Cheers for the heads up

About 12 bytes.

"so you get a max of 25 position indications per day"

TTN is not a service for moving significant amounts of data around…

As mentioned earlier the GSM method is probably the way to do it but I really want a project to learn about LoRa so I guess I’ll persevere :wink:

If your close to a gateway then the amount of data you can send rises quite a bit, to maybe 550 position indications a day.

However for a moveable object you cannot be sure how far away the gateways will be so it makes sense to plan for the maximum range and with a stolen bike you really only need to know where it is when its come to rest, so you can then send law enforcement to visit.

You could add a byte to the payload that is a movement indicator, 0 = not moved in the last hour, 255 = lots of movement. So when you start getting no movement messages you might assume the thief has it stored somewhere …

1 Like

@hidara - do not do as the bulk of the engineers in the world do, which would be:

  • Skip the reading
  • Start with a multi-part project
  • Use the bare minimum of components
  • Skip the reading
  • Ask questions on here without any indication of prior research

LoRaWAN has many parts to it, try not to have too many elements being worked on in parallel unless you have plenty of duct tape to reseal your head when your brain explodes, but a good running order would be something like:

Order a gateway and TWO different device platforms - I’d go with one of the TTGO boards with a LoRa & GPS module - plus what feels like it’s pricey but has first class support for the software stack, an Adafruit Feather M0 RFM95


Which makes using this so much simpler:

Setup your un-modded gateway, get both devices working on ABP on the v3 console.

Leave the Feather alone so you have a “is it working” device - I have one on my desk with a pushbutton so I can “is any of this stuff actually working / online / hearing me” when I’ve disappeared up my own backside.

Create a new project for each sensor / add-on, get each one working.

Use a personal Git to preserve known good code bases so you can roll back and do releases for code base that is deployed.

Then start to merge the code base, one item at a time, testing each time.

At some point when you know your Feather is reliable, crack open the TTIG to add a serial console AND an external antenna connection.

At some point, do some OTAA setup on the Feather so you know about OTAA - the preferred connection method for static devices, a bit useless for trackers.

Setup Data Storage so you have a back-up of your uplinks.

Figure out a way to get your data out, these work:

Do not try out TTN Mapper YET - it’s the coverage mapper but it is being fettled for v3 and you will have enough on without trying to figure out if it’s you or TTN Mapper (it will be both).

And then you will be in the top 10% of LoRaWAN makers in the world. Really!

They are v2 docs, but this makes a good reading list:

I’ll figure out the links for the v3 equivalent soon. The Working with Bytes in the devices section will be important for you.

If you can copy & paste output, do that, pictures of text are bad. Screen shots of things that won’t copy & paste are OK:

Airtime calculator which will fill in the blanks on the above:

As an aside, there are various WiFi location lookup services around - thanks to Google StreetView. Adding a simple GSM module for simple web gets or using SMS on to the TTGO won’t be trivial but is a good upgrade path.

Give us regular progress reports here or on blog!


Thanks for gathering that info into one spot! It’ll give me plenty of reading to do while the bits get posted.

Any progress? First link goes to teh Lorawan page with a youtube video witha lot of info so will have to watch a few more times. Is there a lite version?

Are the recommendations for ttig and ttgo still valid? and last q, is there a better map than the globe on the home page, or way to zoom in.

Sorry, no, if only because the first link has lots in it and yes, @Johan does a good job of blowing people minds but in the medium term it’s the level of knowledge that will stand you in good stead.

The other links that go to the v2 docs still have lots of relevant info in - you just have to take it in context - LoRaWAN is a huge topic with many moving parts, so baby steps and lots of reading and trying things out is indicated.

The TTIG is great as your known-good-gateway - you can add a serial output so you can see a little more detail on what it is doing, but I’d go with at TTIG and then perhaps add a RAK7246 (a Pi based gateway) which will let you see the logs on device and try other things out. TTGO recent version works very well with LMIC-node (which was invented here) or Adafruit Feather M0 RFM95 (works the LMIC-node as well as the lower level MCCI LMIC). But I’m also recommending having a known-good-device to hand - something simple & low cost that you leave running so you can tell if it’s you or the gateway/infrastructure/whatever that’s glitched - something like the Dragino Door or Water sensor on AAA batteries.

Map available here: - FireFox or Chrome, close most of your other tabs to keep it quick - there’s a lot of data to load.