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

[Sean Fitzgibbon]

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]

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]

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]

In my limited experience the most nerve-wracking bit is the descent. It seems to take ages!

John

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/65a56a1c-a020-4e91-9087-f8b6b2f73fd8n%40googlegroups.com.

[Sean Fitzgibbon]

Fingers crossed we get that far :)

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/CAJn3SCqK%3D_bnZ9waRdFwEKfD%3DCoRvRGwTJS9RS4FYz8Qr2KJ7w%40mail.gmail.com.

[Antal Vincz]

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]

} 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
};

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/5036a545-e949-1b22-fa65-dd6864550917%40gmail.com.

[John Laidler]

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.

https://development.libelium.com/lora_networking_guide/transmission-modes

John

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/5036a545-e949-1b22-fa65-dd6864550917%40gmail.com.

[Steve]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/CAJn3SCoKcUsuZB0DYOz_otbray0OAzHDXHz-UGj0vLLFy_HZJg%40mail.gmail.com.

[Sean Fitzgibbon]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/2c778869-a1db-0bc4-3193-3e697befb4eb%40randomaerospace.com.

[David Akerman]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/2c778869-a1db-0bc4-3193-3e697befb4eb%40randomaerospace.com.

[David Akerman]

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]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/CAN3_bBqa9Kb_yhqL_w89MS8rVXsgR7-SfQMCXPTuCRduzJSrpw%40mail.gmail.com.

[Sean Fitzgibbon]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/CABD2Lt0hrgjKLfEM4zxTB36nfJ3%2B0H-Rt%2BkWhRsGzbKZi4JsUA%40mail.gmail.com.

[j.r.h...@gmail.com]

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]

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]

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)]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/CAKOSXUFBduPsyO9%3D4%2BmadOQph0PJSbqaQsr0WpJzONdivuY8MQ%40mail.gmail.com.

[John Laidler]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/CACk6KX431tZgbuvtg%2BuVBccRS%2B6%3DYvGntwcsi1msLT5-NAQFKQ%40mail.gmail.com.

[Ross G6GVI]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/61ae5d15-6e2d-4e03-8983-9c1330513e60n%40googlegroups.com.

[David Akerman]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/AF668D36-31C3-425B-A471-807FA6D325F1%40gmail.com.

[Steve]

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"

To view this discussion on the web visit https://groups.google.com/d/msgid/ukhas/CAN3_bBqA08CLe9U0bWDtTHUz0KhJewMGa-tKHREAaRtbPQbigA%40mail.gmail.com.

Virus-free. www.avg.com