In Germany it's a pleasure to use RDS with all it's functions.
But only once my AF worked. Oh yes, I thought of setting the RDS-thing in Hijack correctly and everywhere switched it on but it doesn't work. Is it broken? I use 3alpha and Hijack 340.
The one time it worked was with Version 2beta2 and Hijack 340.

Then I would like to understand how those RDS-signals are stored. I could imagine it's stored in the flash. What exactly is stored there? Should I wait for a strong signal to gather all RDS information before storing? Are the AF-frequencies stored, too? Or does AF work in another way?

Technical questions, maybe wrong here, don't know.
But I think the internals of how the tuner is working (with RDS) should be of interest for many people here.

Rolf

I am very intereted in this as well.
I am very happy that there's no unwanted station change in alpha3, still i don't think the AF is working at all. I can't help you more than this, unfortunateluy.

I don't know how AF exactly works. But maybe the problem depends on the signal strength. Why should it change the frequency if there's a strong signal (full power)...
Maybe it's because of my antenna booster, the signal is higher than the first time I put the tuner in the car.
I'm sure we can fix this, whenever :-).

Rolf

Ok, I am sorry and to some extent stupid. My AF was off.

So, the only way I have to find out if it works is next time I am on a highway, that is in two days. I'll post again. Meeanwhile, is there anybody who noticed a proper change of frequency while driving?

I guess I need some more coffee...

It seems that the alternative frequencies (AF) are not stored on the player. After switching the player on you have to have a strong signal to receive RDS and AF messages.

Version 3.0a3 (same for 2.0 betas) tries to switch to an alternate frequency whenever the signal is below a certain level for a period of time. In some cases after several tries it seems to hang and never switches again. (bug?)
On some pca tuner modules the receiption level is far too high, so maybe the tuner isn't switching at all.

In version 2.0 final, the tuner tries tuning to another frequency quite a lot (about every second), but you won't hear the switching. (You can see it on the display) This works quite well for me, but others seems to have problems with that.

I would love to see a version 3.0a3 with the tuner functionality of version 2.0final with the following changes:
- Remove bug where preseted stations don't work correct with AF
- Remove the very short interruption of the audio signal while searching for alternative frequeny (if possible).

2,00 final has another major bug which simply prevented me from using the radio at all: it would switch to the WRONG STATION continuously. So it seemed not to detect the station ID properly. If that was not happening to you (you would have noticed immediately, of course!) I guess it means that different countries uses different ways to ID stations. Here in Italy I had to switch back to b13 or my radio would not stay on one single station for more than few minutes. Some times swicthes to other stations occurred every 4 seconds. Terrible!

I saw this effect one time. The tuner tuned to a completly wrong frequency, but after a few seconds it switched back to the correct one. (Because it detected no or a wrong RDS id) It seems that it stored the wrong frequency and tried it again later. The correct behaviour would be to block that wrong frequency for a while, before trying again.
It should also delete AF frequency that are not transmitted for quite some time.

Another bug for me in 2.0 final is the erase of all the RDS information (RDS text, RDS Station ID, ...) when switching the frequency (which is quite a lot). So the title information in the RDS text data does always disapears.

I'm in Switzerland.
Actual RDS information from Switzerland can be found on http://rds.cnlab.ch/

Played a lot with the link above from Alex25 (it's in German). Very interesting, even for Germany. So I see the following needs:

- storing the AF frequencies
- getting TMC working (will be hard, I think)
- (personal opinion: re-inverting the bottomline in tunermode)

I could imagine that coding can be done in hijack, isn't it? I'm not sure if all festures of the tuner can be controlled via some hijacks. On top of this, it shouldn't be a big fun for Mark to code this, because he lives in the USA (is it?) and therefore cannot receive those RDS signals.
I would like to assist an experienced Empeg coder, myself don't know enough for this (no /dev/rds where I can read things from).

Rolf

I think I should be able to provide the raw tmc data at a linux device (/dev/tmc for example). But the problem is, you have to decode the raw hex values from there. That's no easy part! If someone wants to do this... (I can provide you with some test datas)

I haven't found an open source tmc implementation. I only see a chance to implement a tmc solution for the empeg if there is already such a project underway. (sourceforge for example). But even then we must have the different event and location conversation tables. These are country depended and not free (I think)

I have the source (c++) of the cgi of the url I posted above. (because I'm the administrator of this box) But even these sources doesn't help me.

Obviously the TMC-sheets are not open source. Don't understand why. Nevertheless I would like to play with a /dev/tmc device. Together with some test data it should be possible to gather some information from this source.
It's worth a test.

Rolf