Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

U4B Channel Format - Frequency Filtering #1

Open
KevWal opened this issue Feb 18, 2024 · 3 comments
Open

U4B Channel Format - Frequency Filtering #1

KevWal opened this issue Feb 18, 2024 · 3 comments

Comments

@KevWal
Copy link

KevWal commented Feb 18, 2024

Hi Mike

Firstly excellent work here and some great code. I am looking at ways we might get a permenant WSPR -> SondeHub integration in place with Mark et al (projecthorus/sondehub-aprs-gateway#10) and came across your code as a potential great starting point.

Looking through getU4B.py I dont see the frequency filtering required for Channel functionality as used by U4B and Traquito though, am I just being blind, or is this not currently included?

Thanks very much
Kevin

@k5map
Copy link
Owner

k5map commented Feb 26, 2024

@KevWal
Kevin,

To be honest, until a few days ago, all of the ham balloonist in my area only used the Zachtek and AB5SS trackers. The part of my code which supports the U4B/Tranquito was derived mostly from another ham who provided his code to me, but we've never fully tested it. This past weekend I received an email from my local ham balloonist advising me they have purchased a couple of Tranquito trackers. So, I'll be reviewing and testing that code in the coming weeks.

As for the WSPR -> SondeHub integration, please let me know if I can help in any way. My local balloonist use SondeHub almost exclusively to track their balloons.

@KevWal
Copy link
Author

KevWal commented Mar 7, 2024

Thanks very much @k5map let me know how you get on with the frequency filtering - there is some discussion of some more advanced ways of filtering it here: https://groups.io/g/picoballoon/message/13125

Re WSPR -> SondeHub integration, your code structure and cleanliness is way above what I can achieve as a hobbyist, so your input, or even perhaps even joining together would be amazing.

My thoughts that I have shared with the team about structure of this would be:

Find Balloons to track - save list in a database

Grab and decode WSPR Data

  • A. Scrape from wsprnet.org using BeautifulSoup? (SM0ULC and Bill example) - scraping isnt nice, but seems to be the only way to get the data from the original source?
  • Or B) SQL query from wspr.live? (As you do) - SQL is much nicer, but not the master source of the data?

Decode Balloon Data

What about positions not uploaded to wspr until later than we first check?

@KevWal
Copy link
Author

KevWal commented Mar 11, 2024

Hi

Just been looking at the frequency filtering. So in getU3B.py you currently have:

for i in range(0, len(jWSPRRec1)): try: aDateTime.index(jWSPRRec1[i]['time']) except ValueError: # If we havent seen a 1st packet for this time before aDateTime.append(jWSPRRec1[i]['time']) # save this time as now seen sDateTime = adjDateTime(jWSPRRec1[i]['time']) # find 2nd record time based on 1st record match = False for j, element in enumerate(jWSPRRec2): if element['time'] == sDateTime: # If the time is right for the 2nd slot then we have found a valid 2nd record match = True break

A slight potential issue with selecting the 1st record - you just select the first packet you find for that time slot - what if that packet is corrupted? There have been some issues with this. It would be better if possible to find all packets, and take the one that appears the most times to minimise any chance of corruption.

Similarly for the second packet, I would take all packets that are at the right time. Then we need to do the frequency filtering. My understanding is:

U4B does frequency filtering by first doing frequency correction on relevant packets - this allows it to get the corrected frequency to be accurate, but that’s a lot of work to build a database of frequency corrections for every reporter. It can then just filter on frequency between X and Y though.

Traquito does frequency filtering by finding two packets (1st and 2nd) from the same receiver, and checks the frequency is pretty close, and if it does it calls that a match - that seems to work for them.

Brill brown seems to take any 1st and 2nd packet and checks if the the rx frequency is within 20hz and that seems to work for him.

Anyway, some ideas of how it is done if that helps :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants