I wish to track my balloon with The Things Network (using LoRaWAN). I don't have my own TTN gateway device, and I understand now you can no longer use simple homemade single channel devices such as those made with RFM9x modules.
I could just have my balloon RFM9x module transmit to LoRaWAN only, but as far as I understand only LoRaWAN gateways will be able to parse that information. That means that I can't receive that data on my private tracking device (which won't be a LoRaWAN device).
My thinking is that I can have my balloon transmit one LoRaWAN transmission so I can take advantage of the TTN network, and also a second transmission which I will be able to parse using my own device.
Is this something that others do? And is there another way to ensure one can track a balloon privately (i.e. not including anything TTN), and also rely on the TTN network for tracking at the same time?
Yes. Do file an FAA flight plan, include a radar reflective target if the body isn't, and follow signal frequency restrictions based on altitude. Among other things.
Be aware that using TTN for tracking balloons is not really that friendly to the community network, you are in effect spaming perhaps thousands of Gateways since the packets might be received by all gateways over an area of 200,000+ square miles.
What your suggesting would be difficult, its the nature of the TTN\LoRaWAN code that lots of stuff, system variables and the like, is stored in memory and there are particular setups in the LoRa device registers. Thats all going to be lost if you swap between a LoRaWAN library, such as LMIC, and a point to point LoRa library.
I did once try something similar, saving all the LoRa device registers to an array and transmiting a point to point LoRa packet which did work. However I could not re-establish the LoRaWAN service.
Having said that, I can think of a way of doing it, I have written code that allows a TTN node to recover its OTAA session state from FRAM, the purpose being to allow the node to recover, without a re-join, from a power down or watchdog processor reset. In theory you could at startup, send the point to point LoRa, recover the OTAA session from FRAM act like a LoRaWAN node and power down again.
There was a way around the tracking, in that enthusiastic listeners could listen for LoRa point to point and push the receipts into HABHUB which would track on a map. HABHUB also accepted FSKRTTY type data (which an RFM95 can send) which can be recieved by listeners (HAMs) with a suitable SSB reciever or just a low cost SDR.
But me thinks HABHUB may have just gone out of use.
Thanks @srnet that's really helpful. I was considering to use the TTN/Sondehub (formerly Habhub) bridge here, but I will reconsider now that you mention about the spamming of the TTN gateways - that hadn't crossed my mind.
Before LoRa came, in the UK, FSKRTTY was the de-facto way to track balloons, very popular it was too.
But then in 2015 LoRa came about and it became the most popular way of balloon tracking as it was so easy, receivers were real cheap to make, and of course you could also use the FSKRTTY.
I have been looking at doing a LoRa + FSKRTTY HAB tracker program for the board used for the OTAA session reset recovery, this board might be ideal for a HAB tracker, easypeasy to build, small light, cheap, very low sleep current;
It is possible to limit the reception area, the distance record stands at 830km, suggesting the balloon tracker was using SF12 at full legal power, 14dBm.
However at SF12 the fair use policy for TTN, which is 30 seconds air time per day, limits you to around one location transmission an hour, not very useful.
You could cut the reception range by a factor of 10, so the area covered is down to 1/100th, by using SF7 at reduced power level. SF7 also has much shorter air time so you could send location packets maybe once every 3 minutes.
.
