Hi,
Every now and then we try to fly an TTN tracker on an High Altitude Balloon.
Average airtime 57 mS, one packet every minute, no transmission during night time, so with 30 seconds each day I can transmit about 500 packets in a day, which would mean about 1000 minutes , that would be over 16 hours which covers about twice the flight duration.
So far so good I would say. The last flight (sunday 24th of may above the Netherlands) I guess my tracker failed on me, the first launch it dropped from the balloon at 300 meter altitude and came down on the parachute, landed close to home so was recovered. Same payload, same day, other balloon, GPS fix OK (blinking led on the GPS) so we let go of the payload. Last TTN reception was on 65 m altitude, 14 receivers or something, but no reports after that. The RTTY tracker on the same balloon kept working so the balloon could be tracked, Some hours later the balloon bursted at 22 km altitude, and came down with about 2.5 m/s. Suddenly at around 5 km altitude near Limburg (the Netherlands) the bz-ttn-v2 tracker appeared on the map again with over 30 receivers and was received to about 1100 meter altitude close to Scheid in Germany.
Is there a possibility that the registration of the flying payload has been stopped / blocked because of to much receivers or does that nog make sense? (Payload has not been reported so I can not check the conditions)
Next sunday the new bz-ttn-v2 should fly again in a bit better weather conditions.
Hi Ben, discounting the curvature of the earth problem we have in England that we have discussed before, I doubt anyone had time to react to do any blocking of your tracker - Iâve had students using LoRaWAN set their home-brew devices to 15 seconds and leave it running on the bench whilst getting coffee before Iâve had a chance to intervene and no one at TTN head office appears to notice - although Iâm sure they would if we really did have 10 devices going at it for more than a few hours.
Was the GPS serving both RTTY & LoRaWAN? Maybe itâs just good old v1 build issues? Can you interleave LoRa with LoRaWAN on the same radio so you can tell if the LoRa radio is OK?
Once Boris says we can go outside to play, Iâve a whole range of modules to fly âŚ
PS, I donât think the fair access policy is about number of listeners, but glancing at the basic numbers for a DR5/SF7BW125 57ms packet, you can do 22 an hour to stay in limits. Thatâs only a 7 byte payload. Calculator here:
Hi NIck, thanks for your reply. I donât think the tracker design is an issue Itâs a diycon pcb with Arduino pro mini and 868 MHz rfm module with atgm336h GPS module. I did remove the HDop from the software to add altitude on the basic design and have left it running under the roof here, with 4 to 5 receivers and up to 13 satellites. The tracker did have a bent GPS connector after the first landing which I did âclean upâ before launch and I added some force to have the power connector good in itâs place.
I just wanted to make sure there is no ânumber of receivers overloadâ somewhere, because one week before there was a flight with the same hardware design from another radio amateur, who added 8 solar panels to the tracker, one Li-Ion charger and one battery, which transmitted from 09:30 to 10:30, then magically disappeared from the map. That same day. 20:30 local time the tracker re-appeared on the map above France, with less receivers but transmitted for another 6 hours that night. That was also one of the reasons I wondered if one payload on âto many receiversâ could block the registration.
The 22 an hour was what I was aiming for, with 2 minutes between the packets, power on the GPS, wait for fix and transmit. However the ATGM336h gets itâs fix withinn 7 seconds so I might change the interval to 3 minutes between packets. However with the very great coverage I would like to add some extra packets when below 500 meter
Going to program for 3 minutes now and do some measeurement on the current it draws.
Another thing to look at would be the Frame Counter Check - if there is any possibility that the device reboots, TTN will play dumb until the count reaches the last number it heard.
Well it might do hot fix in 7 seconds most of the time, but most all GPS I have looked at the hot fix time will occaisionaly take much longer. Be sure the software can handle this.
In a very respectful manner I would like to pose a question: clearly if youâre launching balloons then the âfree stuffâ guiding principle isnât a priority for you. Why not use another great non-U.S. success company for the data stream - BGAN; the modems are super cheap on eBay and low data one-month subscription also isnât terrible. So then what makes the choice of TTN a winning one?
How is the âGPS backupâ powered?
In most GPS units there is a very small rechargeable battery for the data used to get a quick fix.
However, that battery takes longer to charge then getting discharged.
And if those quick fix settings are lost, it may take a while for the GPS to get a fix again.
Is the GPS on that long, to be able to get a fix, which sometimes may take up-to 30 minutes when the GPS is not moving?
The data is not shown on TTN-mapper if it has unreliable GPS data.
So maybe you can see it in the application tab of the console, with a data store integration enabled, so you can fetch all data thatâs received.
Or does your node not send out anything if it hasnât got a fix?
If a GPS, with one of those small batteries or supercaps has been left unconnected for a while then it wont work as a backup for very long when used in âhot fixâ mode since the powered period (when the backup can be charged) is a very short period compared to when its being drained in backup mode.
If the backup is discharged then the GPS will revert to cold fix mode where by a working GPS should get a fix in 40 seconds or so.
If you want to use a GPS in âhot fixâ mode for such an application then make sure the battery is fully charged and that it is a batery not a supercap.
It is for the schools I do it with for free, lending them my kit, for free, I donât do commercial launches, only educational/science ones. Hard costs for a launch are around ÂŁ150, using GBP as Iâm in the UK, so ~$40/month for a data subscription would be an extra overhead plus the cost of balloon & gas to take it for a ride - these things are huge (relatively).
@pe2bz, the OP, has far more experience than me in building trackers, but probably not as much as @LoRaTracker, either way, Iâd be confident that the GPS isnât the issue.
As to why send data via LoRaWAN when we already have known working solutions using LoRa P2P and RTTY and other gizmos is, why not, advances the art & science all round and as long as we respect the usage limits, adds another dimension to it all. This sort of add-on is particularly useful when you want to stretch an experienced student team with going through an engineering cycle of investigate, evaluate, implement. Donât worry, we wonât be littering the sky with beeping nodes!
If there was, it would be of the nature of a âbugâ in the de-duplication code (or even the output code that lists the gateways) being unable to handle a huge number of reports, and not a âfilterâ - but there probably is neither.
What it would make sense to do would be to see if for the next flight you can arrange to directly collect logs from a couple of gateways along the flight path. Especially those under the highest altitude part or wherever it is expected to have the highest count of receivers.
If you saw valid raw LoRa packets at those gateways with the nodeâs device address continuing through a time period where the application level messages decoded by TTN ceased, then and only then there might be reason to suspect some sort of server side issue.
The launch of a balloon during the recent virtual conference didnât suffer from this and the tracking information was received by dozens (and more) gateways and processed without issues.
The GPS fix sounds like a likely cause. For moving GPSes getting a cold fix can take minutes, based on my car navigation⌠Stationary it will get a fix within the minute, but who wants to sit waiting In a car for the navigation to get a fixâŚ
On a general comment, I suspect that when the fair access rules were concieved, and based on the use of the backend to forward messages, they did not have in mind a node in a high altitude balloon generating many many times the backend traffic of a normal ground based node.
However I have noted that the various distance record attempts have been promoted on here, so one presumes they approve âŚ
As for a potential issue with a GPS, whilst it cannot be discounted, there are quite a lot of HAB flights in the UK that have used point to point LoRa and FSK RTTY, the tracking there in general seems reliable.
Ben, the OP, is an honorary member of the UK flying community - tracking our flights and frequently keeping us in awe by flying all sorts of developmental trackers so with all that experience Iâd suspect there is just some wrinkle that needs ironing out - second time lucky.
A bit of the story untold, the ttn tracker which I flew was not covered, bare PCB. 2 Energizer AAA batteries as power, the tracker âhiddenâ inside the parachute. There was rain that morning but the tracker after recovery was completely dry. Another possible issue could be that I was the only one running the habbridge script, which I wil make sure there are 2 locations where this runs next sunday.
The GPS has no backup battery. In this version of the tracker, with 40 mAh consumption, I did not find it necessary to switch the GPS on and off so itâs always powered on. GPS antenna (groundplane type) was soldered to the GPS antenne connector, receiving 6 to 9 satellites inhouse. The tracker (indeed) does not start transmitting if there is no GPS lock so that could be the major problem, something with the GPS antenna as source .
I indeed do fly lora and rtty trackers and althoug the receiving network is big, the TTN has even a bigger coverage, and I am testing the tracker to prepare an ultra light weight version with solar and a supercap to fly around the world (which involves geo fencing, switching bands, turning TX of in no airborne allowed areaâs and so on)
Next sunday I hope to fly the next version of the same tracker, this time itâs coverd in foam isolation, going to run from an CR123 battery which should last over 30 hours, and being part of the altitude record try to reach 40 km altitude that flight might even reach the UK this sunday.
The payload from last sunday magically disappeared from the tracker at around 6000 meter altitude when ascending, and 3.75 hours later it re-appeared on about 30 km altitude keeping transmitting for some time. The payload was recovered by an UK radio amateur who wired it to the Arduino IDE and did some tests. All was working OK. Then I asked him if he had freezing spray around. He blew the freezing sprak in the isolation tube the tracker was in and the tracker went totally crazy. Great numbers of resets, transmitting (valid) gps postitions every 10 seconds, crashed (as in stopped working) and started again after warming up. I might have used a bad chinese clone somehowâŚ
Tracker is on itâs way back and I will try to narrow down the part which is responsible for the bad behaviour.
The 24th may flight was naked. Hiding in the parachute on ascent.
The 31th may payload was in tube isolating, with bubble foil on top and bottom locked with Mac Gyver tape. The processor temperature reported when ascending on this flight was 10 degrees C when the reports stopped.
The PCBâs where not coated with plastic spray or something.
Itâs a diycon pcb with Arduino pro mini and 868 MHz rfm module with atgm336h GPS module. I did remove the HDop from the software to add altitude on the basic design and have left it running under the roof here, with 4 to 5 receivers and up to 13 satellites. The tracker did have a bent GPS connector after the first landing which I did âclean upâ before launch and I added some force to have the power connector good in itâs place.