FORD HD RADIOS FACTORY-INSTALLED IN '09

[rbrucecarter5]

Based on over-the-air HD tests conducted near Toronto, the DRCG concluded that the reliable range of HD2/HD3 broadcasts corresponds to the 3 mV/m contour (approximately 70 dBu, aka "city grade" under FCC rules), which agrees closely with my personal experience.

The reason HD2 lock-up takes several seconds has a lot to do with the "interleaving" of data blocks in the digital signal, which helps to increase immunity to multipath and interference from the analog host. I suppose the acquisition time could be improved, but then the signal would be less robust -- just one of many trade-offs that had to be considered to make digital radio feasible in-band.

That still sounds like "you have to be near the towers to get HD" to me. Just what I have been saying. There may be pockets of 3mV out in the suburbs - there are nodes and nulls all over the place. Out in the middle of nowhere, tune to any FM frequency and you can hear occasional fade-ins from hundreds of miles away. If a suburbanite happens to be in a node, they will get HD. But statistically, the chances fall off dramatically as you increase the distance from the tower.

As for lock time, I'd have to look at the code. But any algorithm can be improved if you write it in assembly instead of a high level language. All you have to do is make some quick assumptions - like there is an HD signal, grab it and hold it no matter the quality - then drop out quickly if it isn't usable. Then go back into the high level routines and do complex detection, error correction, the consumer pressing the HD-2 button, syncing with itunes, lighting the light, do RDS / HD text, etc. Nobody cares about all that stuff if they can't hear the ____ music. I've done a lot of similar things on unrelated software projects - there is usually a very common scenario that can be quickly detected and used, then if it isn't true, go back and check the rest. In the cast of HD-2, a fast algorithm can remember that is what was locked last, and appropriate fast detection and locking algorithms used. I refuse to believe - in the world of fast microcontrollers today - it takes several seconds to detect and lock onto a digital signal of any sort. You can excuse millions of lines of code a second - what the heck are they doing that takes so much time???? Wasting time comes to mind - probably running all that other display, keyboard, iTunes sync, text decoding, error correction stuff - in interrupt routines, timed by a silicon operating system (which is usually a great way of slowing things down to begin with). Probably software contracts outsourced to India or something. I patch up poorly designed code from India and poorly designed circuitry from India all the time. Why companies still outsource there is a mystery to me given the poor quality of work coming back.

 

[Mike Walker]

I understand (correct me if i'm wrong...it's happened!) the "several seconds" isn't to "lock onto" the signal, and has nothing to do with the codec. It's for BUFFERING, so audio doesn't immediately drop out when the signal does.

 

[rbrucecarter5]

I understand (correct me if i'm wrong...it's happened!) the "several seconds" isn't to "lock onto" the signal, and has nothing to do with the codec. It's for BUFFERING, so audio doesn't immediately drop out when the signal does.

I think you could probably start the audio immediately and steal CPU cycles - even with a silicon operating system - to slowly build up that several seconds of audio.

 

[scanman1]

I understand (correct me if i'm wrong...it's happened!) the "several seconds" isn't to "lock onto" the signal, and has nothing to do with the codec. It's for BUFFERING, so audio doesn't immediately drop out when the signal does.

I think you could probably start the audio immediately and steal CPU cycles - even with a silicon operating system - to slowly build up that several seconds of audio.

That would create that cool sounding "delay effect", like when the stations use the "dump button" and the buffer is refilling. 8)