![\"LOS\"](\"http:\/\/www.daveakerman.com\/wp-content\/uploads\/2015\/10\/LOS.jpg\")
<\/a><\/p>\nOn previous flights my LoRa trackers have transmitted continuously, but this obviously won’t work if they are meant to listen to other trackers. \u00a0I opted for a very simple and widely used technique called TDMA<\/a> (Time Division Multiple Access), with\u00a0all trackers taking turns to transmit on the same frequency. \u00a0Timing was taken from the GPS which every tracker has anyway. \u00a0Time slots are static and written into the code for each tracker; during non-Tx periods, each tracker listens for packets from other trackers.<\/p>\n I set the frame time to 20 seconds, which conveniently divides exactly into 1 minute, making it much simpler to mentally convert from a time to a slot number. \u00a0Within those 20 seconds there are 10 usable 1-second slots and 10 1-second guard periods (to prevent transmissions from overlapping). \u00a0The frame\u00a0begins on the minute, and there are 3\u00a0frames per minute.<\/p>\n I programmed\u00a03 trackers for the flights, with each tracker having 1 slot to transmit its own position, and 2 slots to re-transmit packets from the other 2 trackers. \u00a0So together they can use\u00a0up to 9 slots (3 direct, 6 repeats) out of the 10 available.<\/p>\n Here’s an SDR screenshot showing packets being transmitted every 2 seconds; the packets occupy\u00a0a bit less than 1 second so there is slightly more than 1 second between packets:<\/p>\n On my previous LoRa flights the packets have taken rather more than 1 second. \u00a0This time I opted for a wider bandwidth (62.5kHz instead of my usual 20.8kHz) to reduce the packet time to about 1\/3rd.<\/p>\n There’s another reason for going to 62.5kHz. \u00a0The LoRa modules that I’ve used have been offset from each other up to 4kHz which, if using a 20.8kHz bandwidth, is enough to stop packets being received. \u00a0Since the allowed offset is a proportion of the bandwidth, then using a wider bandwidth reduces or eliminates the problem.<\/p>\n The downside of using any bandwidth > 20.8kHz, on the 434MHz band in the UK at least, is that transmissions must be\u00a0limited to a duty cycle of 10%; at least it is according to my reading of IR2030<\/a>. \u00a0I measured the Tx time of my tracker’s transmissions and, with 3 slots in 20 seconds, it works out at a duty cycle of just over 8%, so comfortably the right side of legality.<\/p>\n Another downside is that the available power is now spread across a wider bandwidth, so reducing the S\/N ratio at the receiver, and thus the link budget. \u00a0Whether this is an issue or not would become clear during the flights.<\/p>\n For the flights, I programmed 3 trackers provided by Anthony Stirk<\/a>. \u00a0Each has an ATmega 328P, UBlox MAX M8Q, HopeRF RFM98W, \u00a0and cutdown circuitry (not used this time).<\/p>\n Each ran the same code but with different settings for payload ID, primary slot number, and secondary (repeater) slot numbers. \u00a0Each went into a Hobbycraft foam egg<\/a>, total weight with a plastic Estes 18″ parachute was about 70 grams.<\/p>\n LORA1 went up with a 500g balloon. \u00a0I then watched the incoming packets and saw that is was still happily repeating LORA2\/3. \u00a0At about 4km altitude the first of the other ground stations (Phil Crump<\/a>‘s LoRa gateway at his WebSDR site) started to receive LORA1 directly, and LORA2\/3 indirectly; in fact the first packet received there was LORA2 –> LORA1 –> Phil’s gateway:<\/p>\n Next up was LORA2 under a 350g balloon. \u00a0Very impressively, this\u00a0was received by Phil’s gateway when\u00a0at just over 1.1km altitude, which is rather below his radio horizon:<\/p>\n I think that pretty much puts to bed any worries about LoRa range at this bandwidth.<\/p>\n I then\u00a0checked my LCARS LoRa receiver, which was happily showing the position of both airborne trackers as well as LORA3 (still on the bench):<\/p>\n Finally, I launched LORA3, again under a 350g balloon. \u00a0The planned burst altitude for this one was about 28.5km but, as sometimes Chinese latex completely\u00a0ignores specifications and goes rather higher. \u00a0Usually that’s just an extra 2km or so, but this time it was 10km higher than calculated!<\/p>\n After the flight I received several receiver log files, and so far I’ve only had time to do some analysis on Phil’s. \u00a0From that file, the following chart shows the altitude plots for LORA1 and 2 (100 on the chart = max altitude for LORA1) and fraction of packets received (10 on the chart = 100%) directly from LORA1, or indirectly via LORA2:<\/p>\n During the portion of the flight where both LORA1 and LORA2 were high enough to be in range of Phil’s gateway, 82% of LORA1’s packets were received directly, and 58% were received indirectly via LORA2.<\/p>\n LORA1 was heading for a field as it came into land. \u00a0Now, normally the actual landing position isn’t known because the range of a landed tracker is typically about 1 mile. \u00a0There have been exceptions, where either the chase car is close or the payload lands in a tree or on the side of a hill, but for the vast majority of flights the actual landing position is not known till later when the chase car arrives (and then only if the car receiver is uploading via GSM). \u00a0One of my aims, or at least hopes, for these flights was for one or both of the still-flying trackers to continue to repeat packets from the remaining tracker after it has landed.<\/p>\n So as LORA1 approached that field, all eyes were on the telemetry to see “how low can we go?”. \u00a0As the flight gets lower, static receiving stations start to drop out because the tracker is below their line-of-sight, till finally the closest station gets the last packet when the flight altitude is at maybe 500 metres or so (LORA3 for example was lost at 998m). \u00a0Of course this time we also had 2 mobile repeater stations in the form of LORA2 and LORA2, in good position to relay LORA1’s telemetry. \u00a0Here’s part of the conversation on our IRC channel which, to me at least, felt like waiting for Apollo 13 to come out of radio blackout!<\/p>\n And just to prove it, here’s a screenshot from the tracking map, showing a large list of receivers all receiving LORA1 after the latter has landed:<\/p>\n<\/a><\/p>\n<\/p>\n<\/a><\/p>\n<\/a><\/p>\n11:52:31 $$LORA2,161,11:52:27,51.95024,-2.54456,00141,0,0,12*C46E\r\n11:52:35 $$LORA3,161,11:52:33,51.95029,-2.54451,00142,0,0,11*9985\r\n11:52:41 $$LORA1,164,11:52:41,51.96063,-2.57614,03953,7,0,12*99C2<\/pre>\n
12:23:47 $$LORA2,255,12:23:47,51.94375,-2.53650,01190,1,0,12*2AA3<\/pre>\n
<\/p>\n<\/a><\/p>\n<\/a><\/p>\n[15:14] <daveake> 861 repeated \r\n[15:15] <daveake> 639m repeated \r\n[15:15] <daveake> suspense is killing me lol\r\n[15:17] <daveake> 344m repeated \r\n[15:17] <fsphil> .... \r\n[15:17] <Upu> go on :) \r\n[15:17] <fsphil> *tension* \r\n[15:17] Action: fsphil puts on dramatic music \r\n[15:17] <Upu> jcoxon - LORA1 is about to get repeated\r\n on the ground from a flying balloon \r\n[15:17] <daveake> this is like watching apollo 13 re-enter \r\n[15:17] <daveake> we hope \r\n[15:17] <daveake> 146m \r\n[15:17] <Upu> haha \r\n[15:17] <Upu> nice \r\n[15:17] <Laurenceb__> woot \r\n[15:18] <jcoxon> Upu oooo thats amazing \r\n[15:18] <Upu> nice one daveake \r\n[15:18] <Upu> have a beer :) \r\n[15:18] <craag> 80 \r\n[15:18] <daveake> 80m WOOOO \r\n[15:18] <fsphil> lol \r\n[15:18] <craag> next one will be ground \r\n[15:18] <craag> 46!!! \r\n[15:18] <Laurenceb__> yes \r\n[15:18] <daveake> Exccellent :) \r\n[15:20] <craag> and another to confirm! awesome work \r\n[15:20] <jcoxon> the dream of hunting payloads with other payloads\r\n[15:20] <fsphil> hah, that was definitly on the ground \r\n[15:20] <DL1SGP> Lora1 still being rxed \r\n[15:20] <craag> getting repeated by both too it seems \r\n[15:21] <daveake> hah \r\n[15:21] <daveake> Wow, this is great :) \r\n[15:21] <daveake> Can anyone confirm defintely repeated by both ? \r\n[15:22] <craag> I've received two copies of the same sentence... \r\n[15:22] <dbrooke> me too \r\n[15:22] <daveake> excellent \r\n\r\n<\/pre>\n