RDS2 brainstorming

[windytan]

RDS2 support has been requested. Indeed it would be fun to have at some point, albeit quite a bit of work, depending on the approach. Ideas for how to realize the best possible UX are welcome in this thread!

Complications

• RDS2 would be a diversion from how redsea currently works.
• Currently, redsea outputs numbers or very short strings in JSON line objects. These lines are normally < 150 characters long. Every JSON line is self-contained.
• RDS2 can send files of 163 kB in size, according to radioworld.

Solution ideas

1. Print Base64 to terminal?

163 kB in base64 would be ~217,000 characters on a single line, over a thousand times longer than the average redsea output line. If we print it in terminal it's 52 times the size of a 120x35 window; arguably not very good UX.

2. Write it on disk?

Another way would be to write the files on disk, separate from the main JSON output. Currently there's no file output in redsea, so this would be the most involved approach. Some things would need to be thought out first:

• Does RDS2 or the user give us file names?
• Should a newly received file always rewrite the old one?
• Or should there be a numbering scheme?
• Currently redsea does not exit on errors, except if the startup fails. What if the write starts failing / disk becomes full?
• Should redsea avoid filling up the disk after a certain percentage? Do we need a cross-platform way to request disk usage metrics?
• What if two channels (-c) wish to write into a file with the same name?
• How can we reliably unit test this?

3. Limited RDS2 support?

Yet another way to realize RDS2 would be just to detect the additional subcarriers and perhaps print some metadata, without actually decoding the files.

[andimik]

In a first step, I prefer idea 3.

Reason: Some enthusiasts are using redsea in a Raspberry PI recording FM (and DAB) either on a fixed place but also mobile (in combination with a GPS mouse).

https://github.com/hayguen/fmlist_scan

It would be good to have at least the information (for example thanks to the JSON output) that there is an additional carrier for RDS2. In a second step the authors (some radio friends of mine) need to modify his code.

Like:

{"pi":"0x1234","rds2":"stream1","ODA":"station_logo"}

(Station logo is 0xFF7F in RDS2 block B), see for example:

#S1 8000 FF7F 0904 1A74 @2024/02/19 22:33:02.91

see https://www.rds.org.uk/2010/pdf/R22_039_1_pw72.pdf (password is free of charge, but to be requested per mail from RDS forum, Mr. Kopitz)

In case you are providing a first try in a separate github branch, I can test it in my lab at home, as I can generate a RDS2 signal (MPX recording of existing Radio Gioconda from Italy) as well.

[sm3ulc]

Hi! My suggestion would to use base64-blobs inside json for files and other binary objects like logos etc. Just to keep it simple. Kind regards, // David Den tis 20 feb. 2024 21:36Oona Räisänen ***@***.***> skrev:

…

RDS2 support has been requested. Indeed it would be fun to have at some point, albeit quite a bit of work, depending on the approach. Ideas for how to realize the best possible UX are welcome in this thread! Complications - RDS2 would be a diversion from how redsea currently works. - Currently, redsea outputs numbers or very short strings in JSON line objects. These lines are normally < 150 characters long. Every JSON line is self-contained. - RDS2 can send files of 163 kB in size, according to radioworld <https://www.radioworld.com/tech-and-gear/whats-new-with-rds2>. Solution ideas 1. Print Base64 to terminal? 163 kB in base64 would be ~217,000 characters on a single line, over a thousand times longer than the average redsea output line. If we print it in terminal it's 52 times the size of a 120x35 window; arguably not very good UX. 2. Write it on disk? Another way would be to write the files on disk, separate from the main JSON output. Currently there's no file output in redsea, so this would be the most involved approach. Some things would need to be thought out first: - Does RDS2 or the user give us file names? - Should a newly received file always rewrite the old one? - Or should there be a numbering scheme? - Currently redsea does not exit on errors, except if the startup fails. What if the write starts failing / disk becomes full? - Should redsea avoid filling up the disk after a certain percentage? Do we need a cross-platform way to request disk usage metrics? - How can we reliably unit test this? 3. Limited RDS2 support? Yet another way to realize RDS2 would be just to detect the additional subcarriers and perhaps print some metadata, without actually decoding the files. — Reply to this email directly, view it on GitHub <#102>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AELU6KJFDTYDAGEBIGSQ2LDYUUCNPAVCNFSM6AAAAABDR2K6BKVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWGI2DKOJRG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sm3ulc]

To keep a nice UX a switch for only metadata (name, size) or vice versa could b e used.

[andimik]

Well, I've changed constexpr float kCarrierFrequency_Hz to 66500.0f (this is in file subcarrier.cc).

Now I can at least export the 1st stream:

$ cat /tmp/rds2-mpx-6255.wav | ./src/redsea -x -r 192k | head
---- FF7F 0904 1A74
---- 1100 0072 5110
2000 1200 0100 0000
---- FF7F 120A 9495
8000 FF7F 0904 1A74
---- 1704 0000 0001
2000 1800 0000 0000
---- FF7F 120D 43A1
8000 FF7F 0904 1A74
---- 1D61 696E 742E

rds2-mpx-6255.zip

or

$ more /tmp/53c5_rds2.wav | ./src/redsea -x -r 192k | head
---- ---- 1FB3 CA79
---- 33CA 577B ----
---- ---- 01A7 8108
---- 27E5 C3FE C01A
---- 71D5 DE11 A501
---- 6B43 EF08 538D
---- AEAE F101 5D08
---- 9498 343F 2EE1
---- FC4B 6868 FC4C
---- 8A14 9FBC F1BE

53c5_rds2.zip

For RDS-only carriers there is no output.

[vaizki]

Idea for files: for each file, exec a configurable program, pipe the file data to its stdin and if the program prints out a valid JSON object to stdout then add that to the redsea output JSON. This way everyone can make their own file processing.

[sm3ulc]

Care to elaborate? RFT implemented in redsea? RFT in the mentioned exec?

[andimik]

I've added another recording from Australia to #32

[andimik]

@windytan

Oona: any comments on our suggestions?

[windytan]

I think base64 is an interesting idea, raw hex output is also an interesting idea. Basically it's waiting for someone to pick up the task and write the implementation and tests :)

[windytan]

Or we could just detect the subcarriers and print metadata.

I would like to have this testing requirement for all new features implemented after 1.0, to catch obvious bugs and regressions; less work in the long run. The simplest test case would probably involve adding a very short clip of RDS2 MPX that we would run through redsea in Github Actions CI, and see that the JSON contains everything we want.

We haven't stored any test MPX in the repository before, but I'm thinking Git-LFS could be a relatively painless solution. I've used Git-LFS for stereodemux tests. The only downside is it seems to take a relatively long time to push new changes every time (is it uploading the files each time? I'm not sure) and also there is 1 gigabyte bandwidth limit per month for these hobby projects, including CI traffic and PRs, maybe even including forks. We should filter out any radio station audio to avoid copyright legal issues.

The build and static analysis pipeline is set up so that it will automatically check all pull requests for the master branch, and show the green check mark if the PR builds on Ubuntu, old Debian, macOS, and Windows without issue. Currently runs in 7 minutes. If CI does not accept the pull request, clicking on the red X and then going to Details will reveal some useful logs.

There is a somewhat strict clang-tidy policy in place, but clang-tidy (and clang-format) can also be run locally before making PR.

Hope this helps possible contributors! I'll help with the PR for sure. I myself may have some time for new features later this year, unsure.

[windytan]

I also added the AC to the issue thread, because some people (me) like to work with such clear requirements: #32 (comment)