projecthorus / horusdemodlib

High Altitude Balloon Telemetry Library
GNU Lesser General Public License v2.1
55 stars 26 forks source link

Request a payload ID #35

Closed 9A4AM closed 3 years ago

9A4AM commented 3 years ago

Hi, I like to Request a payload ID for 9A4AM-4FSK.

Thanks!

darksidelemm commented 3 years ago

Allocated ID 58 to 9A4AM-4FSK

darksidelemm commented 1 year ago

Hi Mario, not sure if you'll get this but I'll try!

Just wondering if you know what happened on the recent 9A4AM-4FSK flight (3rd September 2023)? some very odd things occurring in the map, and it almost looked like there were 2 payloads in the air going by the frame count.

9A4AM commented 1 year ago

Hi Mark, thanks for info. I don't know what happening with flight data error, I was look on SondeHub and all looks ok. After flight was finished, I will download flight data from Grafana and analyze flight. Just for info, flight use RS41HUP with deep sleep mode, maybe this make error on data! With best regards. Mario

ned, 3. ruj 2023. u 09:20 Mark Jessop @.***> napisao je:

Hi Mario, not sure if you'll get this but I'll try!

Just wondering if you know what happened on the recent 9A4AM-4FSK flight (3rd September 2023)? some very odd things occurring in the map, and it almost looked like there were 2 payloads in the air going by the frame count.

— Reply to this email directly, view it on GitHub https://github.com/projecthorus/horusdemodlib/issues/35#issuecomment-1704033869, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGAHOND2M7N6GBMGZID7X3DXYQVSFANCNFSM46M3OYGQ . You are receiving this because you authored the thread.Message ID: @.***>

-- Mario Ančić 098/256-372

darksidelemm commented 1 year ago

Ahh it could be something to do with deep sleep mode. I never got that working correctly in RS41HUP, so I don't recommend it to be used! I ended up with too many issues with the payload not acquiring gps lock...

9A4AM commented 1 year ago

Basically, the deep sleep mode works well in terms of consumption and I didn't have a problem with GPS Lock in my flights, the only thing is that sometimes it sends incorrect data, but as far as I can see, SondeHub filters it out well. I hope you don't mind that we send payload with RS41HUP and deep sleep mode. RS41NG spend more energy. Flight in Croatia is with Vaisala RS41 with only one battery (usually used from orginal flight and picked out immedetly after landing) and in floating for about 15-20 hours.

ned, 3. ruj 2023. u 23:23 Mark Jessop @.***> napisao je:

Ahh it could be something to do with deep sleep mode. I never got that working correctly in RS41HUP, so I don't recommend it to be used! I ended up with too many issues with the payload not acquiring gps lock...

— Reply to this email directly, view it on GitHub https://github.com/projecthorus/horusdemodlib/issues/35#issuecomment-1704407352, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGAHONF5C3AQ3JYUFWZRX43XYTYLNANCNFSM46M3OYGQ . You are receiving this because you authored the thread.Message ID: @.***>

-- Mario Ančić 098/256-372

darksidelemm commented 1 year ago

There are recent changes in RS41ng that enable GPS PowerSave mode, but the deep sleep mode is not in there as we found it too unreliable. As you said, it sometimes sends incorrect data - we really want to avoid this happening.

I definitely won't be supporting any more changes to RS41HUP, so you are unfortunately on your own with that...

darksidelemm commented 1 year ago

Definitely something wrong with the times being reported by the payload. It results in flight paths that look like this:

Screen Shot 2023-09-13 at 15 40 21

This issue is quite obvious here in the following table: telegram-cloud-photo-size-5-6055244142184871533-y

This has been sorted by frame number. If you compare the 'datetime' field (date/time from the payload telemetry) vs 'upload_time' (when the packet hits SondeHub), and 'time_received' (local time at the receiver), you can see the payload-reported datetime is going wonky.

I suspect this is a deep sleep issue, with the GPS not behaving correctly when being woken up. I'd suggest trying a flight with just the regular powersave mode to confirm this is the case.

darksidelemm commented 1 year ago

Also, on the point of deep sleep, I suspect that the energy savings in using deep sleep vs using powersave mode might not be all that much. In powersave mode the GPS goes into a halted state for most of each second anyway... I'd suggest trying just regular powersave instead of deep sleep, hopefully these issues go away.

9A4AM commented 1 year ago

Hi Mark, yes I agree with you, probably Deep Sleep is the problem, next flight I will use Power Saving mode. By the way, what about the 16 byte V2 in RS41ng. In Horusdemodlib I read about it.

sri, 13. ruj 2023. u 08:17 Mark Jessop @.***> napisao je:

Also, on the point of deep sleep, I suspect that the energy savings in using deep sleep vs using powersave mode might not be all that much. In powersave mode the GPS goes into a halted state for most of each second anyway... I'd suggest trying just regular powersave instead of deep sleep, hopefully these issues go away.

— Reply to this email directly, view it on GitHub https://github.com/projecthorus/horusdemodlib/issues/35#issuecomment-1717012198, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGAHONB2TXP5CL2XLJALQ6TX2FFY5ANCNFSM46M3OYGQ . You are receiving this because you authored the thread.Message ID: @.***>

-- Mario Ančić 098/256-372

darksidelemm commented 1 year ago

The 16-byte message format isn't going to happen any more, I decided there was little need for it, and it was more useful to have the larger packet format allowing custom sensor data.

9A4AM commented 1 year ago

Too bad, for sensorless, position-only flights and limited power resources, 16-byte would be great. This is the reason why we often fly the Horus V1, energy saving.

sri, 13. ruj 2023. u 08:30 Mark Jessop @.***> napisao je:

The 16-byte message format isn't going to happen any more, I decided there was little need for it, and it was more useful to have the larger packet format allowing custom sensor data.

— Reply to this email directly, view it on GitHub https://github.com/projecthorus/horusdemodlib/issues/35#issuecomment-1717024024, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGAHONHWQAPMX4S2UD3HGSTX2FHGRANCNFSM46M3OYGQ . You are receiving this because you authored the thread.Message ID: @.***>

-- Mario Ančić 098/256-372

darksidelemm commented 1 year ago

If you are only transmitting once a minute, the shorter packet really isn't going to do much to your overall energy consumption. Also the 8-bit payload ID was getting too limiting. If I had stuck with that we would have run out by now!

You would be better off trying to save power by lowering your transmitter power - looking at the SNR plots your receivers have plenty of excess SNR, so you could drop your transmit power by 3dB (or even more!) and save power that way.

On Wed, 13 Sept 2023, 16:07 Mario Ancic, @.***> wrote:

Too bad, for sensorless, position-only flights and limited power resources, 16-byte would be great. This is the reason why we often fly the Horus V1, energy saving.

sri, 13. ruj 2023. u 08:30 Mark Jessop @.***> napisao je:

The 16-byte message format isn't going to happen any more, I decided there was little need for it, and it was more useful to have the larger packet format allowing custom sensor data.

— Reply to this email directly, view it on GitHub < https://github.com/projecthorus/horusdemodlib/issues/35#issuecomment-1717024024>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AGAHONHWQAPMX4S2UD3HGSTX2FHGRANCNFSM46M3OYGQ>

. You are receiving this because you authored the thread.Message ID: @.***>

-- Mario Ančić 098/256-372

— Reply to this email directly, view it on GitHub https://github.com/projecthorus/horusdemodlib/issues/35#issuecomment-1717032298, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH57EYNV3N56RDC5JTNRT3X2FIEPANCNFSM46M3OYGQ . You are receiving this because you modified the open/close state.Message ID: @.***>

9A4AM commented 1 year ago

Yes, the SNR is high, but we have excellent equipment and a good position in Croatia and Serbia :), I use Power 4 (approx. 11 dBm), with Power 3 (approx. 8 dBm) there is a problem with the receivers (for example in Romania or Bulgaria) and this is the reason to use a little more power. We are still testing with the settings.

sri, 13. ruj 2023. u 08:48 Mark Jessop @.***> napisao je:

If you are only transmitting once a minute, the shorter packet really isn't going to do much to your overall energy consumption. Also the 8-bit payload ID was getting too limiting. If I had stuck with that we would have run out by now!

You would be better off trying to save power by lowering your transmitter power - looking at the SNR plots your receivers have plenty of excess SNR, so you could drop your transmit power by 3dB (or even more!) and save power that way.

On Wed, 13 Sept 2023, 16:07 Mario Ancic, @.***> wrote:

Too bad, for sensorless, position-only flights and limited power resources, 16-byte would be great. This is the reason why we often fly the Horus V1, energy saving.

sri, 13. ruj 2023. u 08:30 Mark Jessop @.***> napisao je:

The 16-byte message format isn't going to happen any more, I decided there was little need for it, and it was more useful to have the larger packet format allowing custom sensor data.

— Reply to this email directly, view it on GitHub <

https://github.com/projecthorus/horusdemodlib/issues/35#issuecomment-1717024024>,

or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AGAHONHWQAPMX4S2UD3HGSTX2FHGRANCNFSM46M3OYGQ>

. You are receiving this because you authored the thread.Message ID: @.***>

-- Mario Ančić 098/256-372

— Reply to this email directly, view it on GitHub < https://github.com/projecthorus/horusdemodlib/issues/35#issuecomment-1717032298>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAH57EYNV3N56RDC5JTNRT3X2FIEPANCNFSM46M3OYGQ>

. You are receiving this because you modified the open/close state.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/projecthorus/horusdemodlib/issues/35#issuecomment-1717044321, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGAHONDZOK7EDBHKTG4B5XTX2FJMHANCNFSM46M3OYGQ . You are receiving this because you authored the thread.Message ID: @.***>

-- Mario Ančić 098/256-372