-
Notifications
You must be signed in to change notification settings - Fork 79
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
Passing raw UECP packets to rds_ctl #66
Labels
Comments
This is certainly something I'm going to implement. Making PiFmAdv compatible with existing protocols would be pretty nice. Hopefully I'll get to it soon. |
That would be great! Thank you! I would be happy to collect and share some example UECP packet data for testing if that would be useful. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I use this really clever tool to output radio stations from digital satellite on FM.
For some of these, as they are feeds designed to feed actual FM transmitters (either broadcast or via cable), RDS data is carried in the digital satellite transport stream in the UECP format. I have a Python tool which collects and reassembles the data in the stream into the UECP packets (they are in the format described here - http://www.katruud.nl/katruud_site/downloads/RDS_UECP_6_02_final_060912.pdf ). They contain the relevant RDS group (e.g. 0x02 for PS, 0x0A for RT) as well as with the actual data to be transmitted, along with some other ancillary data.
Currently I then also use the Python tool to decode the UECP packets and for ones supported by PiFmAdv, pipe them to rds_ctl in the right format (e.g. converting an 0x02 packet to PS STATNAME, 0x0A to RT RADIO TEXT INFO, etc.)
I'm just thinking it would be easier and more streamlined if we could pass the raw UECP packets straight to rds_ctl without decoding them and making PiFmAdv recode the RDS data itself. Then it could also potentially support transmitting any other RDS data contained in the UECP stream such as RDS-TMC and the clock time (rather than setting this from the system time).
Do you think this would this be possible?
Thanks!
The text was updated successfully, but these errors were encountered: