I have been launching long distance floater balloons connected to The Things Network for a year now. Most successful flight was up for 20 days and is likely to have flown around the world. We received transmissions over Europe, Japan, America and Canada. Launch report is here: Link. The design files can be found on our github repo.
Concerning your geofencing problem, we used the Things network map to create a geofence map: The raw map data can be found here. The map is used to tell the tracker which LoRaWAN frequency to transmit on: EU868 when over Europe, AS923 when over Japan, US915 over North America.
From our last 2 flights, we know that it works over Europe, Japan, Canada and America since our packets were received there.
In the flights, the trackers only transmitted and did not receive. It transmitted only its current position in each packet which meant we did not know where it was when it was outside radio coverage. We have since launched another flight on 17 Dec which saves a position to EEPROM every 20 minutes, and sends 12 past positions in each transmission, allowing us to know where it was when it was out of radio coverage. We are yet to hear from it so hopefully it reappears and tells us where it was!
I’m also thinking about adding an LF output (since the SX1276 can output and input both 433 and 900MHz) for the Chinese TTN frequnecy.
I don’t think there are any gateways in China listening in on 470-510Mhz or 779-787Mhz. Our transmissions over China on both those frequencies have never been picked up.
That’s definitely a posibility, though we wan’t to deploy a bit complicated system. We will save the data when needed into flash and later on, try to create a hive network of different probes, which could extend the range of each other.
Such a shame, the TTN map displays some stations there. We have the transmissions for that area turned of anyway at the moment.
I think saving the data is very very important. On our flight ICSPACE22, we got transmissions over Europe, exactly 4 transmissions over Japan, and around a dozen over Canada and America. We don’t know where it was in between so we cannot be 100% it flew around the world.
I am quite skeptical about creating a mesh network of balloons. My estimate says that the balloons have to be within 700km of each other to have line of sight communication. The balloons quickly seperate. We did a pair of flights launched minutes apart. Launch report. Within one day, one was in Austria and the other in Slovakia.
Definitely. I just don’t want to do it randomly but at least approximately detect when it’s necessary to save it and when to transmit the saved packets.
Yes, that’s why there would need to be more than two for this to work efficiently. We just want the software and hardware adapted to that, it might be useful in the future. We are running many simulations of such meshes, they don’t seem to be super stable but should be possible.
I don’t think that’s an issue. First off there can be an interrupt when receiving a packet. Second, the time can be synchronised pretty well via GNSS. Third, since we are using solar power during the day, there’s not much limit to power. Meaning if we can use the receiver at all we can run it continuosly for the the most part.
More probably, you want to save all of the data routinely (flash is really cheap) but perhaps track what you think you’ve successfully downlinked. However you really cannot do that by location, but only by having some knowledge that you’ve recently gotten some sort of general confirmation from the network. LoRaWAN simply doesn’t accommodate acking everything but if you get an downlink every once in a while, then there’s a decent chance that enough (but by no means all!) of the uplinks you’ve sent in between have been received that if your repetition scheme has a good interleave, you can probably reconstruct most of your flight.
First off there can be an interrupt when receiving a packet.
You can only get an interrupt if you’re powering a receiver. Typically a LoRaWAN node only does so for milliseconds around the expected header of a reply downlink; if no pre-amble is seen it shuts off again.
Second, the time can be synchronised pretty well via GNSS.
If you have the power budget to run that receiver, then yes, you potentially have a timebase to coordinate peer-to-peer receive windows.
The raw map data can be found here. The map is used to tell the tracker which LoRaWAN frequency to transmit on: EU868 when over Europe, AS923 when over Japan, US915 over North America.