LAUNCH ANNOUNCEMENT - BRISTOL, Saturday 16th July 2022. 14:00-17:00

121 views
Skip to first unread message

Sean Fitzgibbon

unread,
Jul 13, 2022, 6:20:56 AMJul 13
to UKHAS
We (Westbury Park Primary School Coding Club) are hoping to launch an 800g balloon this weekend, with 300g payload comprising 2 GPS radio trackers, LoRa and RTTY, with SSDV on the main tracker.  Estimated burst altitude is 34-36km and the general direction of the flight is currently predicted to be SE towards Shaftesbury.

The main tracker is on 434.225MHz, payload ID AETHER, LoRa Mode 1, telemetry and SSDV.

The backup tracker is dual LoRa and RTTY, with loRa on 434.450MHz Mode 1, and RTTY on 434.400MHz, 300 baud 8 N 1, 440Hz shift.  Telemetry only no SSDV.  The tracker generally sends a couple of packets on LoRa then a couple of RTTY, but periodically it also sends out a calling mode message (433.650MHz mode 3).  For RTTY you'll probably miss the start of the first packet as the decoder wakes up, but the second packet should be fine.

To follow the action on the HABHUB map, use this link which includes both payloads plus one chase car: https://tracker.habhub.org/#!mt=roadmap&mz=11&qm=All&f=ZURG&q=AETHER;ZURG;M0RPI*

John Laidler

unread,
Jul 13, 2022, 6:28:02 AMJul 13
to uk...@googlegroups.com
Best wishes for the flight.  I'll try and track it from near Plymouth.

John

--
You received this message because you are subscribed to the Google Groups "UKHAS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukhas+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/c5c3985c-8103-4474-9af7-aefc815ac4b6n%40googlegroups.com.

Sean Fitzgibbon

unread,
Jul 13, 2022, 6:50:16 AMJul 13
to UKHAS
Thank you! This is my first flight.  Thankfully we have the generous assistance of Dave Akerman or else I don't think we would have even got this far!

John Laidler

unread,
Jul 13, 2022, 7:08:15 AMJul 13
to uk...@googlegroups.com
In my limited experience the most nerve-wracking bit is the descent. It seems to take ages!

John

Sean Fitzgibbon

unread,
Jul 13, 2022, 7:23:03 AMJul 13
to uk...@googlegroups.com
Fingers crossed we get that far :)

Antal Vincz

unread,
Jul 13, 2022, 11:16:38 AMJul 13
to uk...@googlegroups.com, Sean Fitzgibbon

Good luck!

Can you tell me which mode is what? I'm lazy to search.
The link is good for me.

Thank you

Tony

--
You received this message because you are subscribed to the Google Groups "UKHAS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukhas+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/c5c3985c-8103-4474-9af7-aefc815ac4b6n%40googlegroups.com.

Mentes a vírusoktól. www.avg.com

Steve

unread,
Jul 13, 2022, 11:18:38 AMJul 13
to uk...@googlegroups.com

} LoRaModes[] =
{
    {EXPLICIT_MODE, ERROR_CODING_4_8, BANDWIDTH_20K8, SPREADING_11, 8,    60, "Telemetry"},            // 0: Normal mode for telemetry
    {IMPLICIT_MODE, ERROR_CODING_4_5, BANDWIDTH_20K8, SPREADING_6,  0,  1400, "SSDV"},                // 1: Normal mode for SSDV
    {EXPLICIT_MODE, ERROR_CODING_4_8, BANDWIDTH_62K5, SPREADING_8,  0,  2000, "Repeater"},            // 2: Normal mode for repeater network   
    {EXPLICIT_MODE, ERROR_CODING_4_6, BANDWIDTH_250K, SPREADING_7,  0,  8000, "Turbo"},                // 3: Normal mode for high speed images in 868MHz band
    {IMPLICIT_MODE, ERROR_CODING_4_5, BANDWIDTH_250K, SPREADING_6,  0, 16828, "TurboX"},            // Fastest mode within IR2030 in 868MHz band
    {EXPLICIT_MODE, ERROR_CODING_4_8, BANDWIDTH_41K7, SPREADING_11, 0,   200, "Calling"},            // Calling mode
    {IMPLICIT_MODE, ERROR_CODING_4_5, BANDWIDTH_41K7, SPREADING_6,  0,  2800, "Uplink"},            // Uplink mode for 868
    {EXPLICIT_MODE, ERROR_CODING_4_5, BANDWIDTH_20K8, SPREADING_7,  0,  2800, "Telnet"},            // 7: Telnet-style comms with HAB on 434
    {IMPLICIT_MODE, ERROR_CODING_4_5, BANDWIDTH_62K5, SPREADING_6,  0,  4500, "SSDV Repeater"},        // 8: SSDV Repeater Network
};

John Laidler

unread,
Jul 13, 2022, 11:46:58 AMJul 13
to uk...@googlegroups.com
Tony,

If you mean the LoRa mode there is some detail on the page linked to below but I don;t think you should need this as whatever gateway you are using just needs to be told the mode to use.

John


Steve

unread,
Jul 13, 2022, 12:01:38 PMJul 13
to uk...@googlegroups.com

John,  I had assumed that Tony was talking PITS LoraModes - given AETHER is distinctly looking like a pi in the sky on the tracker ?

The libelium LoRa Modes seem to be a completely different set of choices Bandwidth, Coding rate and Spreading factor.

    Steve

Sean Fitzgibbon

unread,
Jul 13, 2022, 12:06:33 PMJul 13
to uk...@googlegroups.com
Hi All

The primary tracker in AETHER is a FlexTrak operating at 434.225MHz LoRa Mode 1.  I am afraid I don’t know any more about LoRa modes.

Cheers, Sean

David Akerman

unread,
Jul 13, 2022, 12:31:05 PMJul 13
to UKHAS
It's a flextrak rather than pits, but the same modes apply, and as you say Steve those are completely different to the ones in the page that John linked to.

Anyone using any of my programs - the Pi LoRa HAB gateway, the Windows HAB Base program, or my Android HAB apps - just needs to set the frequency and mode.  For other software set the individual spreading factor etc values as the table that Steve posted.

Dave

David Akerman

unread,
Jul 14, 2022, 10:51:21 AMJul 14
to UKHAS
I've removed the calling mode from the backup "ZURG" tracker as it has a bug which I don't have time to fix.  So the tracker details are now:

Payload ID
LoRa
RTTY 
SSDV
Notes
AETHER
434.225MHz Mode 1
-
Y

ZURG
434.450MHz Mode 1
434.400MHz 300 baud 8 N 1 440Hz
N
3 LoRa packets then 2 RTTY packets in approx 10s cycle

Dave

Mark Jessop

unread,
Jul 16, 2022, 9:43:54 PMJul 16
to uk...@googlegroups.com
What ended up happening on this flight?

AETHER showed up on the ground, and appeared to have lost contact just after launch.
ZURG never showed up on the habhub tracker. I guess this might be due to an invalid payload document?

ZURG did show up on amateur.sondehub.org, but only because there was a listener (G8FJG) using Horus-GUI to decode the RTTY, and because amateur.sondehub.org doesn't have payload documents, so just displayed what was received. It was only tracked to the limits of that station however, so only down to 2km altitude.

73
Mark VK5QI

Sean Fitzgibbon

unread,
Jul 17, 2022, 4:00:16 AMJul 17
to uk...@googlegroups.com
Hi Mark

The flight did take place and we successfully recovered the payload from a wheat field between Upavon and Amesbury.  

As you thought, AETHER (the primary tracker) worked perfectly on the ground but we stopped receiving anything a few minutes into the flight.  We are not sure why at this stage.  Upon recovery the tracker was still running, and there was lots of photos on the SD card.  The aerial looked OK and was connected.  I did check continuity of the aerial before launch.

Thankfully, ZURG (the backup tracker) was still operational allowing us to chase the flight. However, a list minute change to the payload document meant that it could not be viewed on habhub tracker,

All in all, a mostly successful first flight.

Cheers, Sean

j.r.h...@gmail.com

unread,
Jul 18, 2022, 4:10:33 AMJul 18
to UKHAS
Hi Sean,

What altitude did you lose the AETHER tracker? We lost ours around 200 meters and we have checked the continuity of the antennas we put on the payloads and have no shorts.

Cheers
Jonathan

Sean Fitzgibbon

unread,
Jul 18, 2022, 5:07:26 AMJul 18
to uk...@googlegroups.com
Hi Jonathan

I don’t have the exact number to hand, but I think our last packet was received at about 260m.

Cheers, Sean
 

You received this message because you are subscribed to a topic in the Google Groups "UKHAS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ukhas/w9NxH6_6nL0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ukhas+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/52f1eee1-6709-4070-8563-841179111703n%40googlegroups.com.

Ross G6GVI

unread,
Jul 20, 2022, 8:28:00 AMJul 20
to UKHAS
I've been thinking about the recent flights where the radio links failed a few hundred metres into the ascent. Given that the radios were seen to be working OK on the ground (in close proximity to the receiver),  I guess that the problems in flight must be due to either a fault on the antenna (including its connection to the transmiter) or the transmitter itself (giving out much less than its rated power)?

So I had an idea for a simple pre-launch test which would validate the performance of the entire downlink system - at least for LoRa, whose receiver reports its RSSI (Received Signal Strength Indication) in dB. If you carefully measure the received signal strength at a short distance (e.g. 15 metres) from the payload, it should be straightforward to calculate the expected range, using the inverse-square law.
For example, comparing the received signal powers from 15m to 60km range: the distance is 4000 times greater, so the signal will be 16 million times weaker, i.e. -72dB (= 10x log 16000000). So if you'd measured a local signal level of -50dBm at 15m, then at 60km range it would drop to -122 (= -50 -72), which should still be within the receiver's capability. But if  you'd measured only -100dBm  before launch, you'd be struggling to receive it at a height of more than a few hundred metres.
But note that when measuring the signal with the payload still on the ground, the path losses can vary a lot due to reflections - best get one of the launch crew to hold up the payload and move it around a few feet whilst you find the peak received value.

Hopefully this test will prevent disappointment in future flights.
Regards from Ross.

Dave (G1OGY)

unread,
Jul 20, 2022, 9:12:06 AMJul 20
to ukhas
On Wed, 20 Jul 2022 at 13:28, Ross G6GVI <ross....@gmail.com> wrote:
>
> - best get one of the launch crew to hold up the payload and move it around a few feet whilst you find the peak received value.
>

Balloon and a long piece of string?

Mike Sharps

unread,
Jul 20, 2022, 9:24:12 AMJul 20
to uk...@googlegroups.com
If you have access to a drone that can be used for a range (scuse the pun) of tests. We have been checking out a few designs of trackers and ground receivers using a drone which can be launched as far away as you like and even doing some mock retrieval exercises which in itself can be quite educational and challenging.

--
You received this message because you are subscribed to the Google Groups "UKHAS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukhas+un...@googlegroups.com.

John Laidler

unread,
Jul 20, 2022, 11:21:13 AMJul 20
to uk...@googlegroups.com
I'm grasping at straws but 255 can be expressed as an 8 Bit binary number, once you get to 256 you need a 9 Bit number.  If for some reason there was an overflow because not enough space had been allocated for altitude it might cause the program to stop.

This could only happen if the software was somehow different to what is normally flown as that of course works up to much higher altitudes.

John



Ross G6GVI

unread,
Jul 20, 2022, 12:09:04 PMJul 20
to UKHAS
I've just checked the logged telemetry, and the last recorded altitude of SpaceEAL was 234, whereas AETHER did just make it to 256 (100 Hex):
"$$SpaceEAL,323,08:34:40,51.84309,-0.96446,234,12,5998,37,23,0.00000,0.00000*7D94"
"$$AETHER,992,14:14:06,51.47604,-2.61023,256,12,5865,46,27,0.00000,0.00000*AD4C"

Nigel VH

unread,
Jul 20, 2022, 12:13:23 PMJul 20
to uk...@googlegroups.com
Not going to jump to conclusions, but I’ve also had issues with altitude overflows in the past, which is why I made a point of logging a flight’s NMEA data and now I play that back from my computer to the flight board to run a simulated flight and catch those sorts of issues ahead of time.

Definitely worth doing if you’re involved in the code IMO.

Nigel

--
You received this message because you are subscribed to the Google Groups "UKHAS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ukhas+un...@googlegroups.com.

David Akerman

unread,
Jul 20, 2022, 12:58:07 PMJul 20
to UKHAS
Well, it's lovely to see all the speculation, but this is what happened.

Somehow (and I don't know exactly how yet) a pre-release binary got onto those trackers in the production run.  That binary was mistakenly built without the required library code for floating point printf format expansion.

With the tracker on the ground, none of the code requires fp printf support.  However once the tracker code detected a launch, it enabled the landing prediction code which printf's the results to the serial port for monitoring/debugging.  With the library code missing, printf fell over in a heap (probably literally).

This never showed up in firmware testing (which does include playing back NMEA from a real flight) because that testing was done with the correct build that includes printf floating point support.

It never showed up in production testing since that didn't involve running through an emulated flight.

We're in the process of getting the correct firmware sent out to customers, by return/swap and/or by sending out free ST-LINK programmers.

Dave

Steve

unread,
Jul 21, 2022, 4:31:41 AMJul 21
to uk...@googlegroups.com

I'm reminded of a joke:

Four engineers get into a car, It won't start:

The Mechanical engineer says "its the starter motor."

The Electrical engineer says "its the battery."

The Chemical engineer says "impurities in the petrol."

The IT engineer says "try turning it off and on again"

Reply all
Reply to author
Forward
0 new messages