• Bug Feedback

  • AF does not work properly

I'm ashamed to admit it, but the best performing AF is the Mediatek Helio P65 on the Junsun V1 radio. Is it possible to improve AF in Europe to search for alternative stations? Navradio AF works great, you can't ask the developer how to fix it. Generally, the problem is that Af searches for alternative frequencies, but has a problem returning to the previous one. Or the opposite happens - it does not search for an alternative station. Radio reception often deteriorates when driving with AF on. It is not as stable as in the Mediatek Helio P65 processor - every time it looks for alternative stations, it hits the alternative station perfectly. I know that radio FM is becoming a thing of the past, but it will continue to work in Europe for a long time.

I second this, the RDS AF handling is not ideal right now. For me, I have to say, it's somewhat working, but only partially, with some glitches. I don't know whether the AF search function is done by Dudu or is handled by MCU, so it's developed by FYT, but in that case I hope at least Dudu can ask them to do some fixes.

  • From my experience over time it seems like the AF table includes wrong frequencies, from other stations. It seems that when swiching preset or tuning to other station the AF table retains frequencies from previous stations and then, when signal goes low, the AF function tries to tune to that wrong frequencies. This happens to me really often.
    Correct behaviour should be that when tuning to another frequency/station, the AF table should be allways cleared and newly read from RDS data from currently tuned station. Then, when the signal drops below specified value (would be nice if that value could be adjusted by user in settings), start scanning through those frequencies in the AF table, tune to those with better signal and check for the station PI code from RDS and stay on than frequency only if the PI code is the same with currently listened station. If the PI code cannot be read from RDS, its maybe weak frequency or just some interference, then let's try another ones from list. If the PI code is different, then the checked frequency belongs to another station and then remove it from current AF list and check another ones.
  • It seems that when the checking for AF starts and there is some frequency where the signal seems to be better, but it's not correct station broadcasting (mainly stronger interferrence), AF routine tries to repeatedly tune to that frequency and does not move to another ones, even though I know there's better and working frequency in AF list (and I have to tune manually to that one). So as I wrote in previous point, when the AF function tries to check a frequency with seemingly better signal, but cannot obtain PI code from RDS, it should move on and try another ones from AF list.

As wybitny2 said, FM radio and RDS is really widely used in Europe and here in Czechia it will be used for at least another 10 years. So having it working correctly would be really appreciated. And I mean also other RDS function, for example TP (Traffic Program / Announcement), which is not working at all (even though on MTCD units it's working correctly, on Topway units also with some glitches), and I'm not mentioning EON, Radiotext+,...

RDS is really really old standard and it's a bit shame that a 30 years old simple Pioneer car radio I've used before could handle those functions way beter than this modern Android head unit loaded with functions... Yeah, I know, RDS is not used in China, so it's a bit difficult for developers to implement its functions correctly, but still...

So, pretty please, could you at least try to look on this and make some fixes? I can help with testing, if you'd like.
Thanks ;-)

    The developers are testing this currently since it's a critical problem.

      • VVladOst

        • Post #4
        • This post is in русский

        jamar
        Добавлю, что при достижении на работающей частоте критического минимума уровня сигала (триггер для перехода на AF), нужно отсортировать список AF по силе сигнала (от лучшего к меньшему), и затем начинать сравнивать на них PI. Т.к. в зоне может оказаться пересечение нескольких частот одной станции, и не всегда сильнейшая будет в начале списка AF передающихся от станции.

            wwest2
            Really? I didn't know they're already working on this, that's a good news! Thanks for the info.

              VladOst
              You're right. The 7708 chip should be able to tune frequencies fast enough to scan for signal strenght with barely noticeable dropouts. And I guess it's maybe already done this way, but as I said, sometimes wrong frequencies appears on AF list from previously listened station. And some stations broadcasts AF list of their whole network, so there is possibility, that some frequency in the AF table might be in use by another station in particular area. That's why the check for correct PI is really importat and if it differs from PI of currently listened station, don't check that frequency again and try another one.
              Today I was driving from my client between two cities, listened to some station and when the signal drops under level where AF kicks in, it starts trying a frequency with stronger signal, but from completely different station. And it kept trying it for at least minutes, cycling between station I was listening to and the different station within 1 second interval, forcing me to switch to another station, because it was sooo annoying ;-)

                  jamar What can I say is that the devs are working on it. But with this Chinese New Year holiday things might get delayed a bit.

                      Thank you for your tips, with more tips and people the developers can improve AF

                      • VVladOst

                        • Post #9
                        • This post is in русский

                        jamar
                        Я работаю техническим директором на крупной сетевой радиостанции в России, и прекрасно знаю, как работает RDS 🙂
                        К сожалению, в России нет стандартизации по присвоению PI радиостанциям (не знаю, как в Европе и других странах). Из-за этого может случиться так, что если разные радиостанции в соседних (или даже одном) регионах не договорятся, то могут использовать один и тот же PI 🙁 Приходится выезжать на полевые испытания, искать такие станции, и вести с ними переговоры о смене PI. К тому же PI иногда бывает принимается с ошибкой, и "совпадает" с чужим значением (бывает редко, но бывает).
                        Т.ч. ложное срабатывание AF не всегда является виной радиоприёмника. Поэтому мы рекомендуем своим слушателям отключать AF в зоне города или уверенного приёма, и пользоваться этой функцией, только если не знаете точной частоты передачи любимой станции на дальнем пути.

                            VladOst I understand that, but why can navradio read an alternative frequency or radio on the Mediatek Helio P65 processor at a given time. The problem is with sensitivity, it happens both ways. It searches and cannot return to the previous frequency or in the other direction it does not want to detect an alternative frequency. It also happens that the station disappears, there is no alternative frequency, the radio starts to receive worse when AF is turned on. However, the best AF has a radio on the mediatek helio p65 processor, there the radio and alternative frequencies are received flawlessly. So it's not the radio station's problem since the AF works perfectly on the Mediatek Helio P65

                              MihaiFlorin
                              No problem, I'll be of course patiently waiting. The most important thing is that the developers knows about this problem and are willing to make some fixes and adjustment. But of course let them enjoy the upcoming holidays ;-)

                                  VladOst
                                  Okay, fair enough ;-) Anyway, here in Czechia are PI codes assigned by state authorities (namely Czech Telecommunication Office), so PI conflicts really shouldn't happen. Of course, errors in reception and false PI decoding can happen, but I'm not sure what's the probability of this error, since RDS has some sort of CRC error checking and PI is transmitted in every RDS data group, so checking it's correctness by receiving it twice should't take longer than 200ms, if I'm not mistaken.
                                  On the other hand, I think I've never experienced problems with wrong AF switching with OEM headunits or with car radios from known brands over the years, so I really think this is a problem of Dudu7/FYT headunits...

                                    jamar Believe me, they know. 🙂

                                      20 days later

                                      I want to calm everyone down, developers are working on improving AF in dudu radios. They realize that the topic needs to be improved.

                                        wybitny2 I don't want to say "I told you so" 😁

                                            MihaiFlorin I only confirmed what you wrote

                                              The radio in dudu7 generally works very badly. the receiver sensitivity is worse than radios from the 80s/90s, AF doesn't work at all for me, TA can't be turned on... Generally, the radio in DUDU7 is like a simple receiver, which you can buy in a supermarket for a few dollars... This is not what you would expect from probably the most expensive station

                                                rafisz
                                                Hi, I can't fully confirm that. The sensitivity seems to be on the same level as it was with original headunit I had in my car. I just needed to add power injector for active antena (original headunit had it built-in). What can I say is that Dudu7 (and this seems to be true for all chinese headunits I had my hands on) is much more sensitive for picking up EMI interferrence. I've partially fixed it by adding EMI filter on power line, now I'm trying to find a way how to filter noise picked up from USB connected DVR (Dudu 2k). But otherwise sensitivity is fine.
                                                AF problems were discussed here (and in the ver 3.6 announcement thread) previously, it sort-of works sometimes, but it's far from ideal. The TP function is completely broken, you're right. So let the devs finish and fine-tune the AF function and then maybe they will correctly implement TP handling. And then maybe Radiotext+, and then, well, the sky's the limit ;-)

                                                    We will probably receive test version of improved radio app until the end of next week.

                                                      jamar
                                                      I installed DUDU7 in a Honda Accord 8th gen EU and I compare it to the original unit. In the Accord, no additional antenna equipment is needed, a regular Honda-ISO adapter is enough. The antenna amplifier is powered by a separate cable. The original Accord radio is much better than DUDU, which irritates me a lot. Where the original played cleanly, Dudu often hisses. On a long trip, you can forget about listening to radio stations or hearing traffic reports. I hope that after the corrections it will finally start working properly, the sensitivity probably cannot be improved, but maybe the rest will be OK...