Post reply

Message icon:

Unregistered users must pass a verification.

Please enter the number from the picture :

shortcuts: hit alt+s to submit/post or alt+p to preview

Topic Summary

Posted by: jpeter
« on: September 12, 2013, 07:51:48 pm »

Thanks for your response. Please send the utility to my private address linked to this mail.
Posted by: Jan
« on: September 12, 2013, 05:55:06 pm »

There's any implementation possible which does not violate with existing features of the RDS encoder. The PIRA32/P132 uses two radiotexts, RT1 and RT2. Currently only RT1 is filled by UECP. It is possible to fill the other RT in the case that previous RT is already filled and buffer configuration (bits 6..5) is 1 0. This will effectively maintain full compatibility with original UECP RT command if the number of Radiotexts in the bufer does not exceed two.

It would be nice if you can provide me a sample of UECP data for further analysis so I could issue a binding opinion. I can provide a utility for saving serial data.

Let me allow a short comment: Original special arrangements defined in the UECP, like "spinning wheel" or "RT buffer" are deprecated. They have never been used widely, especially after internet connectivity has became available everywhere. Today's RDS encoders are not limited to be only simple UECP machines, there's an independent set of ASCII commands, special text features, volatile and non-volatile memory etc. Keeping the RDS encoders based on old UECP arrangement is not eligible. For anyone writing control application it is convenient to send data transparently rather than filling and flushing buffers and rely on correct transmission.
Posted by: jpeter
« on: September 12, 2013, 04:15:02 pm »

Jan, I have realized that the problem is that the control bits 1 to 7 are ignored. We are using 20 pcs. of the PIRA32 and plan to replace them with PIRA132. It would be important to be able to use them with our RDS server which uses the control bits. Please let me know if there is chance for the implementation in the near future.

Posted by: Jan
« on: August 26, 2013, 01:59:43 pm »

Radiotext command in UECP protocol does not carry any information about actual RT type (A or B). In other words transparent mode for the RT type is not possible because it is not defined in the UECP protocol. Depending on bit 0 in first MED of the RT command, the RT type toggles or not. This feature works independently of any settings.
Please note that PIRA32 supports only transparent mode for Radiotext. Radiotext on the output is equal to the last Radiotext sent via UECP, regardless of the buffer configuration bits. See the pdf manual for more details about the UECP implementation.
Posted by: jpeter
« on: August 26, 2013, 11:29:51 am »

Hello Jan,

We have RTA and RTB in the UECP stream feeding the PIRA32 encoder, but only RTA comes out of the device. How can I configure the encoder to work transparent. I use Magic RDS for configuration.