Open mrwish7 opened 5 years ago
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. Thanks!
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.
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!