There is a TTN equiped Pico Balloon in flight from Cornwall if you want to follow it;
https://tracker.habhub.org/#!mt=roadmap&mz=8&qm=1_day&f=ttnwiv4n&q=!RS_*;
Looks to be sending out a tracker payload every 30 seconds …
1 Like
Do we click the heart button for sharing the link and then un-click it because someone launched with a 30 second uplink. Wonder if the battery will last all the way to the Artic …
Yes, a dilema. However its going to be put of range of The UK shortly, perhaps around the time its used up the 30 sec allowance.
Its a floater, designed to be airborne for a long time, its solar powered.
For something that moves so slowly, and can be picked up by a great many gateways, there is no compelling reason to transmit its location once every 30 seconds.
It will shortly be out of range of the UK, so the 30 second allowance might not be exceeded today, but if it comes back round over Europe …
The 30 sec allowance isnt UK specific it is TTN Network wide! Do I interpret the map/plot data as showing gateways and ad hoc receivers being pinged all over the map? I assume the outer blue circle demarks expected local horizon limit on LOS range at that point & altitude (333km with 8km+)? How big is the payload? What SF being used? If repeating on 30sec - I assume below DC Limit to stay legal, if not FUP. Do we know which mis-guided individual sent this up so we can educate them? I note (at time of this post) last heared near 4hrs ago so hopefully now well out of range or possibly ditched at sea?! 
Calm down, no need to panic, it’s been 4 hours out of touch now.
If it remains floating it will circle back over the UK at some point, down France and across to see Borat, the prediction is a bit of a hack as you can see from the debug log.
But if you are still feeling fruity, you can talk to @JohnLaidler about his little experiment.
And since the tracker is solar powered perhaps it does not TX at night ?
Looks like its just Lat,Long,Alt taken from the TTNMapper Log.
SF7
Apologies if my device is breaking any rules. The 30 second interval was what was in the code I borrowed from an example of a tracker I found on the Things Network website a couple of years ago. For simply tracking, such a short interval isn’t necessary but it can be useful at times. For example, as it left the Land’s End area of the UK yesterday it started to descend. I now think this was due to a ripple in the airflow caused by the wind leaving the land, which at that point is about 200m high before it drops sharply down to the sea. Even at a height of 8Km this caused a disturbance above the sea about the same distance from land. A bit like the ripples on a river caused by water flowing over a large boulder on the bed appearing downstream of the boulder. In hindsight I might have perhaps expected this bit of turbulence but it was interesting to discover it - atmospheric research on the fly so to speak and wouldn’t have been so easily discovered with a less frequent transmission interval. 
The payload is solar powered with a total weight of 10g. It stopped transmitting at almost exactly 18:00 UTC yesterday and I don’t expect it will start up again for at least 12 hours. However, if it is still flying it is unlikely to be within range of any gateways today and may not be heard from again until late tomorrow or even Saturday. This is because of the lack of gateways with outdoor antennas in the regions it is expected to fly. There are none on the Faeroes, only one on Iceland but that one is in the far west and probably too far away. The most likely gateways to see it next are on the Orkney Islands. Of course if it does return to the more populated areas of Europe it will be engaged by a lot of gateways but this won’t last for very long as it will be moving through.
If there is another flight I will turn down the interval.
There is a fair use allowance of 30 seconds airtime per day, this is part of the deal for TTN providing free access to thier backend.
A typical GPS tracker payload at SF7 will take around 60mS of air time, so 500 packets a day or an interval of around 172 seconds if your transmitting all the time.
1 Like
Possibly, possibly not - the prediction shot shows quite a lot of time over France.
We live & learn.
Thank you, as its only transmitting for about 12 hours a day I think in round terms it is probably using up about 90 or so seconds a day. Over the limit of course and if I make another I’ll set the interval lower. I’ve only just discovered the online airtime calculator and it’s been instructive!
But a sense of proportion* needs to be maintained as I’m not planning to sell thousands of these and flood the market. It’s a one-off device which by its nature will be short lived and may already have expired.
I flew an identical balloon last year at about the same time and no one pointed this aspect out at the time - so I guess this is a learning curve for everyone.
“*” On THIS Forum!!! 
Guys, sorry if anyone took offence to initial post…guess my humour fell flat, in response to Nick. As noted there is a FUP in play for anyone utilising the TTN infrastructure, though we all stretch a point now and again 
… both backend and the GW/network deployments (am sensitive on last point given have donated literally dozens of GW’s to the communities use.)
I quite enjoy the tests and antics of the HAB community within the context of LoRa & LoRaWAN, and followed and even encouraged some use from early days by the likes of Stuart and Dave Ack…et al… as I’m sure @LoRaTracker would confirm.
From FUP perspective yes it’s 30s uplinks per day, what isn’t obvious and I guess no one wants to get into specifying minutiae and details, is this is predicated on typical sensor use cases we see across the network where a sensor may well be seen by one or two or three local GW’s, poss a hand full or low teens in high density and some urban environments or where sensor is placed high with good view of many GW’s in surroundings. I have a few sensors myself which regularly see 10, 12, even 15 gw’s.
HAB users really should consider that in some cases (out of and control, give vagaries of the weather and wind, and even ducting effects) balloon message could be seen by dozens and even hundreds of GW’s each time… remember the backend has to deal with de-duping this peak load. Also none of us mind More extreme hits on a gw occasionally…what’s 60, 90, 180, 400ms between friends on a gw?! In more critical areas logic dictates deploy redundant GW’s in case of blocking on one. That way the users can have greater assurance of message getting through somehow.
Problem I realised during one HAB run a while back is that with height comes ability to blanket hit all the GWs in an area … and extensive one at that. IIRC there was one run pre-pandemic where gw’s across S.E England, N.France, Belgium, The Netherlands, Lux, even into Germany and again IIRC part of Denmark, though perhaps not all at same time…maybe it was across part of the track, but either way >>500gws were being pinged each time. Inc a half dozen of my own, loosing their inherent redundancy… just sayin, just food for thought!
FUP may allow for aro 3 min intervals in this case @ SF7, vs 30s, but as ever when considering LoRaWAN, and TTN, question should always be asked by users, “just ‘cause I can does that mean I should”!
In this case how would the local, SWIN and more importantly the TeviNET infrastructure providers and community of users down in the S.West feel if they knew there was even a, partial, DoS? We don’t want such users discouraged from deploying into & expanding TTN and going private instead. Again just saying
It’s a personal view, again as a GW provider, but I would respectfully ask that there is some backoff even again FUP, given the more extreme use cases represented by HAB…
1 Like
The presense of the TTN fair use policy has been mentioned before on the UKHAS forum.
Since there is the possibility of sending a message to the tracker, limited to 10 a day of course, it might be an idea if the tracker code allowed for the transmission interval to be remotely ‘adjusted’.
Do appreciate that a node on the ground that goes nuts and spams TTN, can be tracked down and dealt with, but its a bit harder if the node is floating around the World 8km up.
1 Like
I was aware of the 30 second rule but I didn’t know how to work out what my usage was likely to be until I found the online calculator today. TBH I didn’t ask the question so I can’t claim my ignorance as an excuse!
If the balloon survives it might reappear off the NE tip of Scotland tomorrow morning based on current predictions - but I’m not hugely confident it will. I’ve got my fingers crossed it might have survived but I might be outnumbered on here by those with fingers crossed it won’t survive!
I’m keen to see it turn up but not sure it will please our colleagues if it gets over mainland Europe.
I haven’t had any small people to launch balloons of late so I’ve not been around on UKHAS but hope to restart with schools in September. Perhaps between the two of us we can put a cautionary tale on the Google Group but without having you staked out at low tide.
Nick,
I think that’s an excellent suggestion, the idea of establishing some “best practice” guidelines for TTN balloons. It could be either a simple not more than once every X minutes or perhaps something more complex based on altitude. The reason for suggesting an altitude factor is a latex balloon which rises say above 30,000m is going to light up half of Europe whereas a pico balloon at around 10,000m.
(Short pause at this point to check my pulse as I’ve just seen ttnwiv4 has reappeared off the west coast of Scotland )
Continuing the post…
It would fairly easy I think to alter the transmission interval based on altitude. For example, up to say 1,000m every 30 seconds, slowing after that, perhaps in stages and for a latex balloon reverting back to shorter interval as it approaches the expected burst altitude. Or something like that.
1 Like
You could also arange to reduce the power level.
For instance if your tracker is over a densly gatwayed area, such as Holland, there is no particular need to be lighting up gateways over most of central Europe.
1 Like
Erm, please no! You have no way of controlling height and therefore no way of being certain what height will attain or sustain for any time… if you fix at SF7 (which is then not LoRaWAN compliant anyhow) it sounds like with current payload you are limited to >~3 min intervals… other comments and considerations above not withstanding. What if you floater catches in a tree, powerline, church steeple or side of a hill happily running off combination of battery & solar top-up and never recovered. You need to plan for bounded behaviour not push the boundaries of what is possible.
With respect you have been advised of the rules now please…
1 Like
Good point about the device getting caught on a tree. It has actually happened with a balloon using the WSPR system which landed in a forest in the Amazon and continued to broadcast for months afterwards.
I’m just canvessing ideas at the moment so all contributions welcome.
868Mhz TTN is OK over Europe, but its not a Wordwide band, so how do you deal with this ?