Closed andimik closed 1 year ago
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
b) a sorted list of frequencies of the same program and then
c) a sorted list of regional variant, maybe marked with an R
like that:
"alt_b_kilohertz":[89300:88800,99500,101700,102600R,89000R]
"alt_b_kilohertz":[99500:89300,99500,104800R,89100R]
cat ./A203_2023-05-13.spy | redsea -hEp | grep alt_kilo | uniq -c | sort > /tmp/A203_2023-05-13.spy_af_groupb.txt
A203_2023-05-13.spy_af_groupb.txt
from IEC 62106 page 45
Examples of an AF method B coding:
F1 F2 Commentary # 11 89.3 Total number (11) of frequencies for tuning frequency (89.3) 89.3 99.5 F2 > F1 hence 99.5 is an AF of tuned frequency 89.3, and is the same programme 89.3 101.7 F2 > F1 hence 101.7 is an AF of tuned frequency 89.3, and is the same programme 88.8 89.3 F2 > F1 hence 88.8 is an AF of tuned frequency 89.3, and is the same programme 102.6 89.3 F2 < F1 hence 102.6 is an AF of a regional variant of tuned frequency 89.3 89.3 89.0 F2 < F1 hence 89.0 is an AF of a regional variant of tuned frequency 89.3 # 9 99.5 Total number (9) of frequencies for tuning frequency (99.5) 89.3 99.5 F2 < F1 hence 89.3 is an AF of tuned frequency 99.5, and is the same programme 99.5 100.9 F2 > F1 hence 100.9 is an AF of tuned frequency 99.5, and is the same programme 104.8 99.5 F2 < F1 hence 104.8 is an AF of a regional variant of tuned frequency 99.5 99.5 89.1 F2 < F1 hence 89.1 is an AF of a regional variant of tuned frequency 99.5
What do you think?
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 alt_frequencies_a
or alt_frequencies_b
.
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:
0A group
(PI flags AF PS) AF code Decode Completed JSON list
--------------------------------------------------------------
A203 0549 E70C 4F45 0xE7 (231) # 7
0x0C ( 12) 88.7
A203 054A 0C1D 2033 0x0C ( 12) 88.7
0x1D ( 29) 90.4
A203 054F 050C 2020 0x05 ( 5) 88.0
0x0C ( 12) 88.7
A203 0548 0C15 2020 0x0C ( 12) 88.7
0x15 ( 21) 89.6 "tuned_frequency":88700, "same_programme":[88000, 89600, 90400]
A203 0549 E5C3 4F45 0xE5 (229) # 5
0xC3 (195) 107.0
A203 054A 1DC3 2033 0x1D ( 29) 90.4
0xC3 (195) 107.0
A203 054F 5FC3 2020 0x5F ( 95) 97.0
0xC3 (195) 107.0 "tuned_frequency":107000, "same_programme":[90400, 97000]
A203 0548 E30C 2020 0xE3 (227) # 3
0x0C ( 12) 88.7
A203 0549 0C1D 4F45 0x0C ( 12) 88.7
0x1D ( 29) 90.4 "tuned_frequency":88700, "same_programme":[90400]
A203 054A E57B 2033 0xE5 (229) # 5
0x7B (123) 99.8
A203 054F 047B 2020 0x04 ( 4) 87.9
0x7B (123) 99.8
A203 0548 167B 2020 0x16 ( 22) 89.7
0x7B (123) 99.8 "tuned_frequency":99800, "same_programme":[87900, 89700]
A203 0549 E37C 4F45 0xE3 (227) # 3
0x7C (124) 99.9
A203 054A 0D7C 2033 0x0D ( 13) 88.8
0x7C (124) 99.9 "tuned_frequency":99900, "same_programme":[88800]
A203 054F E36F 2020 0xE3 (227) # 3
0x6F (111) 98.6
A203 0548 6F78 2020 0x6F (111) 98.6
0x78 (120) 99.5 "tuned_frequency":98600, "same_programme":[99500]
A203 0549 EF78 4F45 0xEF (239) # 15
0x78 (120) 99.5
A203 054A 1D78 2033 0x1D ( 29) 90.4
0x78 (120) 99.5
This is great!
$ cat A203_-_2023-06-09_09-15-35.spy | redsea -hE | jq -c ".alt_frequencies_b" | sort | uniq
null
{"tuned_frequency":100700,"same_programme":[88000,89100,90400,102600]}
{"tuned_frequency":101200,"same_programme":[90400,98100,100900]}
{"tuned_frequency":102500,"same_programme":[88800,90400]}
{"tuned_frequency":102600,"same_programme":[100700]}
{"tuned_frequency":103300,"same_programme":[88600,89100,90400,98400]}
{"tuned_frequency":107000,"same_programme":[90400,97000]}
{"tuned_frequency":88000,"same_programme":[88400,88700,89100,89600,90400,98300,98700,99000,99800,100700,103100]}
{"tuned_frequency":88000,"same_programme":[98600,99500]}
{"tuned_frequency":88100,"same_programme":[90400]}
{"tuned_frequency":88600,"same_programme":[103300]}
{"tuned_frequency":88700,"same_programme":[88000,89600,90400]}
{"tuned_frequency":88700,"same_programme":[90400]}
{"tuned_frequency":88800,"same_programme":[90400,99900,102500]}
{"tuned_frequency":88900,"same_programme":[89200,98700,99500]}
{"tuned_frequency":89100,"same_programme":[88000,89600,90400,90700,99300,100700,103300]}
{"tuned_frequency":89600,"same_programme":[88000,88500,88700,89100,90400,90700,99300,99500]}
{"tuned_frequency":90400,"same_programme":[87900,88000,88100,88800,89100,89200,89600,97000,98300,98400,99500,102500]}
{"tuned_frequency":90400,"same_programme":[88600,88700,89500,90700,98600,98800,99300,100700,101200,103300,107000]}
{"tuned_frequency":90700,"same_programme":[89100,89600,90400,99300]}
{"tuned_frequency":97000,"same_programme":[90400,101200,107000]}
{"tuned_frequency":98200,"same_programme":[87900]}
{"tuned_frequency":98300,"same_programme":[88000,88400,99800]}
{"tuned_frequency":98300,"same_programme":[90400,99500]}
{"tuned_frequency":98400,"same_programme":[88600,90400,99300,103300]}
{"tuned_frequency":98600,"same_programme":[88000,90400]}
{"tuned_frequency":98600,"same_programme":[99500]}
{"tuned_frequency":99300,"same_programme":[89100,89600,90400,90700]}
{"tuned_frequency":99300,"same_programme":[90400,98400]}
{"tuned_frequency":99500,"same_programme":[88000,88900,89200,89600,90400,98300,98600]}
{"tuned_frequency":99800,"same_programme":[87900,89700]}
{"tuned_frequency":99900,"same_programme":[88800]}
With this method a technician can check if the AF list is complete or needs to be fixed.
Or this one:
$ cat A3FF_-_2021-07-18_18-56*.spy | redsea -h | jq -c ".alt_frequencies_b" | grep -v null | sort | uniq
{"tuned_frequency":103700,"same_programme":[91600,98400,100800,103400,105300,106200,107600],"regional_variants":[101900]}
{"tuned_frequency":105300,"same_programme":[91600,103400,103700,106200,107600],"regional_variants":[101900]}
{"tuned_frequency":106200,"same_programme":[103700,105300,106600,107600],"regional_variants":[101900]}
{"tuned_frequency":106600,"same_programme":[91600,100800,103700,106200,107600]}
{"tuned_frequency":91600,"same_programme":[103400,103700,105300,106600,107600]}
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)
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.
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)
---/ Alternative Frequencies \-------------------------------------------------
AF Method A:
AF Method B:
List 1 = [#11, 106,6 MHz] 91,6 MHz, 106,6 MHz; 100,8 MHz, 106,6 MHz; 103,7 MHz, 106,6 MHz; 106,2 MHz, 106,6 MHz; 106,6 MHz, 107,6 MHz
List 2 = [#11, 106,2 MHz] 106,2 MHz, 106,6 MHz; 103,7 MHz, 106,2 MHz; 105,3 MHz, 106,2 MHz; 106,2 MHz, 107,6 MHz; 106,2 MHz, 101,9 MHz (RV)
List 3 = [#17, 103,7 MHz] 103,7 MHz, 106,6 MHz; 103,7 MHz, 106,2 MHz; 91,6 MHz, 103,7 MHz; 98,4 MHz, 103,7 MHz; 100,8 MHz, 103,7 MHz; 103,4 MHz, 103,7 MHz; 103,7 MHz, 105,3 MHz; 103,7 MHz, 107,6 MHz; 103,7 MHz, 101,9 MHz (RV)
List 4 = [#11, 91,6 MHz] 91,6 MHz, 106,6 MHz; 91,6 MHz, 103,7 MHz; 91,6 MHz, 103,4 MHz; 91,6 MHz, 105,3 MHz; 91,6 MHz, 107,6 MHz
List 5 = [#13, 105,3 MHz] 105,3 MHz, 106,2 MHz; 103,7 MHz, 105,3 MHz; 91,6 MHz, 105,3 MHz; 103,4 MHz, 105,3 MHz; 105,3 MHz, 107,6 MHz; 105,3 MHz, 101,9 MHz (RV)
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 sort | uniq
like in the example above?
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.
Left: A numerical sorting algorithm was applied (the same text as above). Right: no sorting, frequencies are in the order they were received
This is good. I feared that the not-sorting leads to multiple tuned_frequency
lines for the same frequency.
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.
$ cat /dev/ttyUSB0 | redsea -i tef -E | grep alt
{"pi":"0xA540","group":"0A","ps":"KAERNTEN","alt_frequencies_b":{"tuned_frequency":96100,"same_programme":[95700,101100,102100,104300,104900,107400]},"bler":0,"di":{"stereo":true},"is_music":true,"prog_type":"Pop music","ta":false,"tp":true}
{"pi":"0xA540","group":"0A","alt_frequencies_b":{"tuned_frequency":101100,"same_programme":[95700,96100,102100,104300,104900,107400]},"bler":0,"di":{"artificial_head":false},"is_music":true,"prog_type":"Pop music","ta":false,"tp":true}
{"pi":"0xA540","group":"0A","alt_frequencies_b":{"tuned_frequency":95700,"same_programme":[96100,101100,102100,104300,104900,107400]},"bler":0,"di":{"compressed":false},"is_music":true,"prog_type":"Pop music","ta":false,"tp":true}
But will have additional new lines and the word null
when you use it together with jq
$ cat /dev/ttyUSB0 | redsea -i tef -E | jq -r ".alt_frequencies_b.tuned_frequency"
null
null
null
null
null
null
null
null
null
null
104300
null
null
null
null
null
null
null
null
null
102100
null
null
null
null
null
null
null
null
null
null
$ cat /dev/ttyUSB0 | redsea -i tef -E | jq -r ".alt_frequencies_b.same_programme"
null
null
null
null
null
null
null
null
null
[
95700,
96100,
101100,
102100,
104300,
107400
]
null
null
null
null
null
null
null
null
null
[
95700,
96100,
101100,
102100,
104300,
104900
]
jq has the option -c
(compact output) that prints everything on one line. It prints null
if the line did not contain the requested key. But I found this: https://blog.nem.ec/code-snippets/jq-ignore-nulls/
So your command could become something along these lines: cat /dev/ttyUSB0 | redsea -i tef -E | jq -cr ".alt_frequencies_b.same_programme | select( . != null )"
Or you could use grep
before jq
: cat /dev/ttyUSB0 | redsea -i tef -E | grep same_programme | jq -cr ".alt_frequencies_b.same_programme"
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
orcat ./A201_2023-05-13.spy | redsea -hE | sort | uniq -c | grep kilo