The microchip devices have been available for over a year. Several boards with them have been released already. And there is a reference stack available, so no need to start from scratch,
Alright, I’ll look into it. Thank you for the suggestion.
Hi everyone! We’ve been using this data inside our API for quite some time and our systems kinda got dependent on it. Recently, these systems stopped working.
One of our team members who programmed the calls said that it’s likely that CORS was disabled for this data. Does anyone know why that would happen and how to fix it? Thanks!
The sx1276 and all its alternatives can already both transmit and receive.
What you need is software not hardware
a better idea would be to create a geofence map which would define the perimeter of the areas with good coverage and bad or no coverage.
That won’t work, as you don’t know if they are actually in operation at any given time
I need to reliably know whether the tracker is in an area with good or bad coverage.
Look at how ADR works; you might not be able to use it literally without modification, but the basic idea could work. Especially as you’d only want to do batch uploads of saved data when you had sufficient connectivity for a higher data rate, which is exactly what ADR is intended to determine.
Yes, but at the time there was no RF switch implemented so I couldn’t code my way trough that. The SX1276 has 5 distinct RF pins and only 1 of them was used at the time.
It’s supposed to give just a very rough estimate of this. It’s okay if it’s in covered areas and thinks it’s not. But it should not make mistakes the opposite way. The problem is that the majority of stations are in US and EU and are “covering” each others receiving areas. We now have a bitmap where the gateways are stored and each pixels contains the latitude and longitude. From this the probe can determine if it’s in a covered area (albeit only in a previous snapshot of gateways but that should be okay if we update it with each new FW revision).
Huh. From what I’ve seen the ADR process can quite some time to actually calibrate and work well. When the velocity of the transmitter can be up to 50 m/s and the angular velocity can be around 90 deg/s I don’t know when the calibration process can occur and how accurate it will be.
That’s precisely why it won’t work. Just because a gateway is on a map, or even was in operation when you launched, doesn’t mean it still is when you fly into its horizon.
From what I’ve seen the ADR process can quite some time to actually calibrate and work well. When the velocity of the transmitter can be up to 50 m/s and the angular velocity can be around 90 deg/s I don’t know when the calibration process can occur and how accurate it will be.
That’s why you might need to use the idea rather than the existing implementation.
But first you should have an antenna omnidirectional enough for rotation not to matter, especially as at the longer range spreading factors you’d see substantial rotation during a single packet.
In terms of ADR-like schemes, one thing you could do is operate in two modes, possibly even by being two virtual nodes. One would periodically transmit essential current data at the slowest spreading factor legal for the location. The other could attempt a more aggressive ADR at a faster SF. Possibly you could just periodically send out a solitary SF7 confirmed uplink - but be sure not to implement retry (which is what makes confirmed normally unwise). If you get an ack, then you blast out saved data. If you don’t, you wait ten minutes and try again.
Or something like that.
Ok, thanks for the info. We’ll try something like this.
Is there anyone who can advise on this?
What data do you refer to? It is probably obvious to you, but my crystal ball wore out long ago.
And you probably can rely on an answer appearing within hours. Given it a day or two…
Yes so first we have a gateway map where we can filter gateways trough their active dates and change thier radiuses where they can receive to better visualize the covered area. We also have our own public API which has the bitmap generator a mentioned earlier. The request documentation is not made yet though.
Yes of course I expect that, but the question got under 3 other posts so I wanted to keep it visible in the last one.
There should be no issue with CORS for a plain request from your PHP script gateway.php but it is reporting 502 bad gateway.
There are a number of questions about the architecture of the app but the main one would be regarding the gateway list - it doesn’t change fast enough to warrant requesting it for each access of your app - it may be you are being blocked due to too many requests. Perhaps look at grabbing the data every 6 or 12 hours, parsing it and turning it in to a static file.
If you have a repro we can see the code base, I’d be happy to look in to it further.
I see. Weird thing is that this worked before but just stopped now.
Okay, that makes sense. We were talking about caching this inside our API, but someone raised concerns about whether this data isn’t copyrighted. I suppose it isn’t at least for these purposes, or do you know something else?
Sure. We dont have a public repo but there are only two files for this. This HTML and then the gateways.php file:
<?php
if($_SERVER['REQUEST_METHOD'] === 'GET') {
$ch = curl_init();
if($ch === false) {
throw new Exception('failed to initialize');
}
curl_setopt($ch, CURLOPT_URL, 'https://www.thethingsnetwork.org/gateway-data/');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
$response = curl_exec($ch);
if ($response === false) {
throw new Exception(curl_error($ch), curl_errno($ch));
}
echo $response;
}
?>
I hope that this format is okay.
I’d not consider this copyright (but I’m no lawyer), apart from fair use, every data point is someone’s gateway so this is a compilation of public data and TTN is a community after all and you aren’t using it for commercial gain etc etc
The most obvious test is, can you run your script on a machine not on the same network as your proxy. I can run it on one of my web servers, so there is either an issue with yours or, as suggested and not unreasonably, TTN are rate limiting.
You can literally fix this now by replacing the gateways.php with the output from using your browser and then figure out an update scheme in the morning - cron based preferably, then there is no delay if a script sees an older file and goes to update it on the fly.
2 Likes
Thanks very much for the suggestions! I will write here about our results when we have them.
Hey Jakub I just saw your post.
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.
Very cool, thanks for the resources! You might want to look at our website picoballoon.org.
Yes, I created pretty much the same thing here.
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.
1 Like
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.
Even apart from that, there’s the issue of a mesh needing time synchronization. Or do you have the battery to run a receiver continuously?
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.