-
Notifications
You must be signed in to change notification settings - Fork 38
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
AF shown too less in JSON even for error-free signals #88
Comments
Hi, thanks again for bug-hunting redsea! I believe redsea is not properly recognizing AF method B here. In Method B, several different lists are sent, corresponding to AFs of different tuned frequencies. The length of the list is encoded differently in these methods, which causes this weird behavior. This needs to be fixed for sure. |
I've tried that, but I fear we get too much results now (see below txt file). Due to the fact that the number of AFs (including the own) for a particular radio tower is transmitted (in the example below 9 resp. 11) I expect to wait until all data have arrived (= not partial) and then print a) the number of frequencies (see below) and then like that:
A203_2023-05-13.spy_af_groupb.txt from IEC 62106 page 45
What do you think? |
Redsea now decodes Alternative Frequencies transmitted with Method B. This is used to transmit any number of different AF lists associated with different tuned frequencies. Some of them may be transmitting programme that varies region-by-region at different times of the day. The JSON field alt_kilohertz was renamed to alt_frequencies_a. For Method B there is a new field called alt_frequencies_b.
Nice ideas! I made it print separately the tuned frequency, frequencies with the same programme, and regional variants. The whole thing is now (in the development branch) called either YLESUOMI for example, "alt_frequencies_b":
{
"tuned_frequency":94000,
"same_programme":[90300,95000,96100,97000,99100],
"regional_variants":[94300,96000,96900,97900,105800,107800]
} I'm just wondering whether sorting the list is the way to go. There might be some importance sorting done by the broadcaster that is lost if we sort numerically. For the Ö3 station, I believe there is legitimately a lot of results to print. They appear to be sending a large number of different lists (31 lists in fact) of different sizes. We are printing these lists as soon as they appear to be complete. Here's a snippet of the 0A groups the station is transmitting and how it translates to JSON:
|
This is great!
With this method a technician can check if the AF list is complete or needs to be fixed. Or this one:
That's what I have expected. In my mind I can see a map just looking at this JSON output :-) Because I know where (on which site) all these frequencies are transmitted and which AF is the neighbor transmitting site. For example this one (source: FMLIST)
Yes, this is the right way in my opinion. Because RDSSpy's log unnecessarily repeats the main frequencies (see above example with F1 and F2)
|
That's beautiful! By sorting I mean, we shouldn't necessarily order the frequencies from smallest number to largest ourselves if the station is sending them in a different order. Maybe they are sent in a specific order for a reason - say, they could be closest or more powerful stations first. So instead of this "regional_variants":[94300,96000,96900,97900,105800,107800] We could leave them in the original order: "regional_variants":[94300,96000,97900,96900,107800,105800] |
Good question. Can you repeat that with the original order and test if you get the same output with |
The output is the same, just that most of the same_programme lists have different order internally. |
Could you share the output? Don't exactly know what you mean. |
Redsea now decodes Alternative Frequencies transmitted with Method B. This is used to transmit any number of different AF lists associated with different tuned frequencies. Some of them may be transmitting programme that varies region-by-region at different times of the day. The JSON field alt_kilohertz was renamed to alt_frequencies_a. For Method B there is a new field called alt_frequencies_b.
This is good. I feared that the not-sorting leads to multiple So, I can say, the right column in your screenshot is fine for us. |
Just one hint: The normal output is printed in one single line.
But will have additional new lines and the word
|
jq has the option So your command could become something along these lines: Or you could use |
I made several experiments with various RDS signals, but the alternative frequency list (AF in group 0A) is shown only a few times in the JSON, whereas the EON frequencies (group 14A) are displayed regularly.
The help says,
When I enable
-p
they will appear quite often, but I don't think this makes sense here as in my case, the signal is error-free nearly all the time (parameter-E
)samples.zip
for example
cat ./A201_2023-05-13.spy | redsea -hE | grep kilo | grep 0A
resp.
cat ./A201_2023-05-13.spy | redsea -hE | grep kilo | grep 14A
or
cat ./A201_2023-05-13.spy | redsea -hE | sort | uniq -c | grep kilo
The text was updated successfully, but these errors were encountered: