HQCT software development

HQCT-eA vol control from RR etc

Hi Putput,

I've been working on extending and fixing the Datalex code for my HQCT-eA. It's mostly working now (although I've not yet got TA done). I originally planned to do a DLL, but it seems you've beaten me to it!

So far as the eA version is concerned there are a few things that I thought might be worth mentioning that might be of interest to you:

- It's really useful to control the amplifier settings from RR etc. So, I've added a number of new windows messages to RRHQCT.exe - things like selecting the input source, changing volume, treble, bass etc. I've amended RR to use these rather than the usual Windows mixer which of course doesn't work with the eA (actually, I guess one could fix the eA's volume level and then adjust the sound card vol level, but this wouldn't work when the radio was selected and there would still be no bass/treble/fader support).

- It's a similar story with FreeDrive when one wants to hear a sat nav voice guidance - one needs to temporarily switch the amp's input source to the sound card and then back again to whatever was selected before. I've added a message to RRHQCT and changed FreeDrive in the same way as RR (which was easy since it's basically the same code as RR - thanks CDRSkull!)

If these are useful to you, let me know and I'll forward the details. I'm also happy to contribute the RR & FreeDrive changes back to whoever is maintaining them.

Finally, I have a (perhaps stupid!) question for you on AF. In my testing I noticed that it can sometimes take some time for the best AF frequency to be acquired (in my case 94.5MHz when tuned to a weak alternative on 93MHz). I noticed in your test program (RDS.EXE) that there is a column called 'This' which in my testing seems to have the best frequency (94.5) shown in all rows. What exactly is this column? If this is a dumb question then I my only defence is that I'm using Diogenes's code for AF and haven't yet delved into the RDS spec (all 150 pages of it)!

Thanks in advance,

Paul

Quote:

Originally Posted by PaulKaye

Hi Putput,

I've been working on extending and fixing the Datalex code for my HQCT-eA. It's mostly working now (although I've not yet got TA done). I originally planned to do a DLL, but it seems you've beaten me to it!

So far as the eA version is concerned there are a few things that I thought might be worth mentioning that might be of interest to you:

- It's really useful to control the amplifier settings from RR etc. So, I've added a number of new windows messages to RRHQCT.exe - things like selecting the input source, changing volume, treble, bass etc. I've amended RR to use these rather than the usual Windows mixer which of course doesn't work with the eA (actually, I guess one could fix the eA's volume level and then adjust the sound card vol level, but this wouldn't work when the radio was selected and there would still be no bass/treble/fader support).

- It's a similar story with FreeDrive when one wants to hear a sat nav voice guidance - one needs to temporarily switch the amp's input source to the sound card and then back again to whatever was selected before. I've added a message to RRHQCT and changed FreeDrive in the same way as RR (which was easy since it's basically the same code as RR - thanks CDRSkull!)

If these are useful to you, let me know and I'll forward the details. I'm also happy to contribute the RR & FreeDrive changes back to whoever is maintaining them.

Finally, I have a (perhaps stupid!) question for you on AF. In my testing I noticed that it can sometimes take some time for the best AF frequency to be acquired (in my case 94.5MHz when tuned to a weak alternative on 93MHz). I noticed in your test program (RDS.EXE) that there is a column called 'This' which in my testing seems to have the best frequency (94.5) shown in all rows. What exactly is this column? If this is a dumb question then I my only defence is that I'm using Diogenes's code for AF and haven't yet delved into the RDS spec (all 150 pages of it)!

Thanks in advance,

Paul

Hello Paul,

About the new messages you've added to RR and FreeDrive; if you forward these messages to me I will add them to CPCTuner, no problem.
But I want to ask you another question about RR and any other frontend for that matter, would it not be a lot easier to use the DLL and just build an interface between RR and the DLL? Of course the current way of communicating (Windows messages) between RR and RRHQCT (or CPCTuner) could remain the same for events and stuff. I just think that using a DLL has more advantages then working with a separate application like CPCTuner or RRHQCT. David already uses my DLL for HQCT support in Centrafuse and Mischka76 is also using it for his frontend.
Perhaps we can start a discussion here on what needs to be in the DLL and how we want to interface with it. Then I can alter/extend my code to meet this requirements and everybody that wants to add HQCT support to any software could use this as a standard interface. What do you think?
A possibility could be that the DLL uses tcpip sockets, once the device is activated via the frontend a server socket will be created in the DLL on 127.0.0.1 with a specified port to interface with the outside world. Messages like volume controle and RDS can easily be exchanged in this way and there will be no problem with things like calling conventions between different compilers. Let me know what you think of it, I believe that it would be best to start with what messages needs to be send between the frontend/application <-> DLL and then we can discuss on what sort of interface we are going to use. I can start with a list of the commands that my DLL uses that can we can extend. I'm not saying that we MUST use my DLL, I'm simply suggesting this because the DLL already exists and I have source code to control almost all HQCT functions, including a working RDS engine and eA support (TMC is on my agenda).

Please let me know what you (and any other developer) thinks of this!

Regards,
Putput

Here is a list of the DLL functions that I used:

Code:

Calling conventions: The DLL exports its functions in stdcall = Windows API calls // Init the software/module function InitHQCT : longbool; stdcall; external 'HQCT.DLL' // Stop the software/module procedure FreeHQCT; stdcall; external 'HQCT.DLL' // Change FM frequency procedure HQCTSetFMFrequency(FM_Freq : integer); stdcall; external 'HQCT.DLL' // Change AM frequency procedure HQCTSetAMFrequency(AM_Freq : integer); stdcall; external 'HQCT.DLL' // Switch betweeontn FM/AM band procedure HQCTSwitchBand(FM_On : longbool); stdcall; external 'HQCT.DLL' // Mute - unmute sound procedure HQCTMute(Mute_On : longbool); stdcall; external 'HQCT.DLL' // The THQCTData type in the next function is a simple array of 128 bytes!! function HQCTReadDataBuffer : THQCTData; stdcall; external 'HQCT.DLL' // Search up for next available station function HQCTScanUp : integer; stdcall; external 'HQCT.DLL' // Search down for next available station function HQCTScanDown : integer; stdcall; external 'HQCT.DLL' // Search up for next available station (async method) procedure HQCTScanUpAsync; stdcall; external 'HQCT.DLL' // Search down for next available station (async method) procedure HQCTScanDownAsync; stdcall; external 'HQCT.DLL' // Frequency 1 step higher (step value depends on settings in .ini file!! procedure HQCTStepUp; stdcall; external 'HQCT.DLL' // Frequency 1 step higher (step value depends on settings in .ini file!! procedure HQCTStepDown; stdcall; external 'HQCT.DLL' // Seek sensitivity, 0 = very sensitive seek, 4 = low sensitive seek for up/down scan functions procedure HQCTSetSeekSentive(Sens_Value : integer); stdcall; external 'HQCT.DLL' // Select the sound source for the audio output, 0=Tuner; 1=CD; 2=Phone; 3=Navigation procedure HQCTSetSoundSource(Src_Value : integer); stdcall; external 'HQCT.DLL' // Set the sound volume for the audio output, 0 = low; 68 = high procedure HQCTVolume(Volume_Value : integer); stdcall; external 'HQCT.DLL' // Set the sound loudness for the audio output, 0 = low; 68 = high procedure HQCTLoudness(Loudness_Value : integer); stdcall; external 'HQCT.DLL' // Set the sound bass for the audio output, 0 = low; 7 = high procedure HQCTBass(Bass_Value : integer); stdcall; external 'HQCT.DLL' // Set the sound treble for the audio output, 0 = low; 7 = high procedure HQCTTreble(Treble_Value : integer); stdcall; external 'HQCT.DLL' // Get current frequency function HQCTGetFrequency : integer; stdcall; external 'HQCT.DLL' // Get FMBand function HQCTGetFMBand : longbool; stdcall; external 'HQCT.DLL' The return buffer of the HQCTReadDataBuffer function has the following structure: begin byte end byte format Description - 0 7 char Station name, when in FM mode with RDS () - 8 87 char RDS text, when in FM mode with RDS - 88 91 32 bit integer The actual FM frequency between 8700 and 10800MHz, no decimal point!! - 92 95 32 bit integer The actual AM frequency in KHz - 96 96 byte 0 = mono; 1 = stereo - 97 97 byte 0 = sound; 1 = mute - 98 98 byte Seek sensitivity 0 = very sensitive 4 = least sensitive - 99 99 byte Reception level - 100 100 byte Sound source 0=Tuner; 1=CD; 2=Phone; 3=Navigation - 101 101 byte 0 = AM; 1 = FM band - 102 127 reserved Reserved for future use The following calls are implemented for Radiator but can be used by all other programs as well: (Please look at the Radiator documentation for use/results of these calls) function GetModuleComment: PChar; stdcall; //description, copyright etc. procedure TuneFreq (Freq: LongInt); stdcall; //matches FM_TUNE; //frequency in kHz (88.2 MHz -> 88200 kHz) procedure TuneFreqMuted (Freq: LongInt); stdcall; //matches FM_TUNEMUTED //frequency in kHz (88.2 MHz -> 88200 kHz) procedure SetMute (Mute: Boolean); stdcall; //matches FM_MUTEUNMUTE function ScanStation (DirectionUp:Boolean; FreqToSearchFrom: LongInt): LongInt; stdcall; //matches FM_SCANSTATION //parameters are //direction (up to high range or down to low range //and current frequency to search from //it returns new frequency function GetVolume: Word; stdcall; //matches GETVOLUME procedure SetVolume (Left,Right: Word); stdcall; //matches FM_SETVOLUMEBYVALUE procedure VolumeUpDown(Step: Integer); stdcall; //matches FM_SETVOLUMEBYVALUE procedure SetBass(Bass: Word); stdcall; //matches FM_BASSTREBLE function GetBass: Word; stdcall; //matches FM_BASSTREBLE procedure SetTreble(Treble: Word); stdcall; //matches FM_BASSTREBLE function GetTreble: Word; stdcall; //matches FM_BASSTREBLE function IsStereo: Boolean; stdcall; //matches FM_ISSTEREO procedure SetStereo (Stereo: Boolean); stdcall; //matches FM_SETSTEREO function GetSignal: Word; stdcall; //matches FM_GETSIGNAL procedure ConfigurationDialog; stdcall; //matches FM_CONFIGURATIONDIALOG

HQCT messages

Quote:

Originally Posted by Putput

Hello Paul,

About the new messages you've added to RR and FreeDrive; if you forward these messages to me I will add them to CPCTuner, no problem.
But I want to ask you another question about RR and any other frontend for that matter, would it not be a lot easier to use the DLL and just build an interface between RR and the DLL? Of course the current way of communicating (Windows messages) between RR and RRHQCT (or CPCTuner) could remain the same for events and stuff. I just think that using a DLL has more advantages then working with a separate application like CPCTuner or RRHQCT. David already uses my DLL for HQCT support in Centrafuse and Mischka76 is also using it for his frontend.
Perhaps we can start a discussion here on what needs to be in the DLL and how we want to interface with it. Then I can alter/extend my code to meet this requirements and everybody that wants to add HQCT support to any software could use this as a standard interface. What do you think?
A possibility could be that the DLL uses tcpip sockets, once the device is activated via the frontend a server socket will be created in the DLL on 127.0.0.1 with a specified port to interface with the outside world. Messages like volume controle and RDS can easily be exchanged in this way and there will be no problem with things like calling conventions between different compilers. Let me know what you think of it, I believe that it would be best to start with what messages needs to be send between the frontend/application <-> DLL and then we can discuss on what sort of interface we are going to use. I can start with a list of the commands that my DLL uses that can we can extend. I'm not saying that we MUST use my DLL, I'm simply suggesting this because the DLL already exists and I have source code to control almost all HQCT functions, including a working RDS engine and eA support (TMC is on my agenda).

Please let me know what you (and any other developer) thinks of this!

Regards,
Putput

Here is a list of the DLL functions that I used:

Code:

Calling conventions: The DLL exports its functions in stdcall = Windows API calls // Init the software/module function InitHQCT : longbool; stdcall; external 'HQCT.DLL' // Stop the software/module procedure FreeHQCT; stdcall; external 'HQCT.DLL' // Change FM frequency procedure HQCTSetFMFrequency(FM_Freq : integer); stdcall; external 'HQCT.DLL' // Change AM frequency procedure HQCTSetAMFrequency(AM_Freq : integer); stdcall; external 'HQCT.DLL' // Switch betweeontn FM/AM band procedure HQCTSwitchBand(FM_On : longbool); stdcall; external 'HQCT.DLL' // Mute - unmute sound procedure HQCTMute(Mute_On : longbool); stdcall; external 'HQCT.DLL' // The THQCTData type in the next function is a simple array of 128 bytes!! function HQCTReadDataBuffer : THQCTData; stdcall; external 'HQCT.DLL' // Search up for next available station function HQCTScanUp : integer; stdcall; external 'HQCT.DLL' // Search down for next available station function HQCTScanDown : integer; stdcall; external 'HQCT.DLL' // Search up for next available station (async method) procedure HQCTScanUpAsync; stdcall; external 'HQCT.DLL' // Search down for next available station (async method) procedure HQCTScanDownAsync; stdcall; external 'HQCT.DLL' // Frequency 1 step higher (step value depends on settings in .ini file!! procedure HQCTStepUp; stdcall; external 'HQCT.DLL' // Frequency 1 step higher (step value depends on settings in .ini file!! procedure HQCTStepDown; stdcall; external 'HQCT.DLL' // Seek sensitivity, 0 = very sensitive seek, 4 = low sensitive seek for up/down scan functions procedure HQCTSetSeekSentive(Sens_Value : integer); stdcall; external 'HQCT.DLL' // Select the sound source for the audio output, 0=Tuner; 1=CD; 2=Phone; 3=Navigation procedure HQCTSetSoundSource(Src_Value : integer); stdcall; external 'HQCT.DLL' // Set the sound volume for the audio output, 0 = low; 68 = high procedure HQCTVolume(Volume_Value : integer); stdcall; external 'HQCT.DLL' // Set the sound loudness for the audio output, 0 = low; 68 = high procedure HQCTLoudness(Loudness_Value : integer); stdcall; external 'HQCT.DLL' // Set the sound bass for the audio output, 0 = low; 7 = high procedure HQCTBass(Bass_Value : integer); stdcall; external 'HQCT.DLL' // Set the sound treble for the audio output, 0 = low; 7 = high procedure HQCTTreble(Treble_Value : integer); stdcall; external 'HQCT.DLL' // Get current frequency function HQCTGetFrequency : integer; stdcall; external 'HQCT.DLL' // Get FMBand function HQCTGetFMBand : longbool; stdcall; external 'HQCT.DLL' The return buffer of the HQCTReadDataBuffer function has the following structure: begin byte end byte format Description - 0 7 char Station name, when in FM mode with RDS () - 8 87 char RDS text, when in FM mode with RDS - 88 91 32 bit integer The actual FM frequency between 8700 and 10800MHz, no decimal point!! - 92 95 32 bit integer The actual AM frequency in KHz - 96 96 byte 0 = mono; 1 = stereo - 97 97 byte 0 = sound; 1 = mute - 98 98 byte Seek sensitivity 0 = very sensitive 4 = least sensitive - 99 99 byte Reception level - 100 100 byte Sound source 0=Tuner; 1=CD; 2=Phone; 3=Navigation - 101 101 byte 0 = AM; 1 = FM band - 102 127 reserved Reserved for future use The following calls are implemented for Radiator but can be used by all other programs as well: (Please look at the Radiator documentation for use/results of these calls) function GetModuleComment: PChar; stdcall; //description, copyright etc. procedure TuneFreq (Freq: LongInt); stdcall; //matches FM_TUNE; //frequency in kHz (88.2 MHz -> 88200 kHz) procedure TuneFreqMuted (Freq: LongInt); stdcall; //matches FM_TUNEMUTED //frequency in kHz (88.2 MHz -> 88200 kHz) procedure SetMute (Mute: Boolean); stdcall; //matches FM_MUTEUNMUTE function ScanStation (DirectionUp:Boolean; FreqToSearchFrom: LongInt): LongInt; stdcall; //matches FM_SCANSTATION //parameters are //direction (up to high range or down to low range //and current frequency to search from //it returns new frequency function GetVolume: Word; stdcall; //matches GETVOLUME procedure SetVolume (Left,Right: Word); stdcall; //matches FM_SETVOLUMEBYVALUE procedure VolumeUpDown(Step: Integer); stdcall; //matches FM_SETVOLUMEBYVALUE procedure SetBass(Bass: Word); stdcall; //matches FM_BASSTREBLE function GetBass: Word; stdcall; //matches FM_BASSTREBLE procedure SetTreble(Treble: Word); stdcall; //matches FM_BASSTREBLE function GetTreble: Word; stdcall; //matches FM_BASSTREBLE function IsStereo: Boolean; stdcall; //matches FM_ISSTEREO procedure SetStereo (Stereo: Boolean); stdcall; //matches FM_SETSTEREO function GetSignal: Word; stdcall; //matches FM_GETSIGNAL procedure ConfigurationDialog; stdcall; //matches FM_CONFIGURATIONDIALOG

Hi Putput,

Thanks for the reply.

1) Messages between RR and RRHQCT. This is what I'm using:

Inbound:
- switching amp input source:
"source;xxxx", where xxx is "radio", "aux1", "aux2", "nav" or "phone"
- volume control:
"setvol;xx", where xx is vol value from 0 to 99
- bass control:
"setbass;xx", where xx is base from 0 to 99
- treble control:
"settreble;xx", where xx is trable from 0 to 99
- mute control:
"setmute;x", where x is 0 or 1 (1=muted)
- temporary input switch (for sat nav to interrupt whatever is currently selected)
"switchInput;on;xxxx" (switches to xxx input, whatever is currently selected)
"switchInput;off" (reverts to previously selected source)

Outbound:
- volume report:
"rvol;xx", where xx is volume from 0 to 99
- bass report
"rbass;xx", where xx is bass from 0 to 99
- treble report
"rtreble;xx", where xx is treble from 0 to 99

2) Should we use a DLL or an app with a UI?

I agree that a DLL is better than an app with a UI. That was my original plan. If the DLL is good enough and the front-end has the necessary UI elements, then a separate UI is pointless. I'm not a great VB coder but I'd be happy to hack RR to work with your DLL. I don't think I have the latest RR source but I'll do some digging and get it. Can you send me your latest eA-enabled DLL (and front-end for that matter) and I'll get on with it?

3) What's the best interface technology between app and DLL?

Using a local IP connection is great idea since as you say it avoids issues about calling conventions between dev environments. If we want to make it really flexible, we could use an XML-based message exchange over the socket - that way we can extend it easily and it's sort of 'standard'. Maybe it's a step too far since we'll need XML parsing which might be real overkill. What do you think?

4) What should the API be?

Your current DLL list looks like it's pretty comprehensive. I'd like to see some calls to turn on/off AF, TA etc but that's all I can see that's missing. The temporary input switcher that I've mentioned above would be useful too (the reason for this is that I'm getting FreeDrive to ask the HQCT amp to select the sound card input so that the nav command can be heard. Once the announcement is over I want the amp to go back to whereever it was and of course only the HQCT control s/w knows this - FreeDrive has no idea).

Hope this helps!

Paul

PS Do you have any comments about my AF question?

Hello Paul,

I'm not using the quote button anymore .. the message is already more then long enough!
1. I've added the new RR messages into CPCTuner, you know where to find the test version, I updated the zip file.

2. I changed my HQCT 'core' component and changed CPCTuner to work with the newly added functions. That’s why I would like to test the new features with CPCTuner first before I start to work on the DLL. It will take some time for me to also change the code for the DLL. However, changing the DLL is only creating an interface between my HQCT component (as used in CPCTuner) and the DLL calls, this should be ready in a few hours. (Mischka76 stay tuned!) Why don't you already start with the current version, available for download on my website?
When CPCTuner works ok with HQCT_eA I'll change the DLL, so I need test results before I continue.

3. Not sure if we need to use XML for this, it creates a lot of overhead in the code and we only need a handful of messages to be sent between client and server socket. I would suggest that we use simple text based messages like with RR. Using the sockets opens up other possibilities as well, more then 1 client can connect to the server socket to send/receive data. For example the TMC data for navigation programs could be broadcasted over sockets.

4. I will add all other CPCTuner functions to the DLL as soon as the latest version of CPCTuner is tested.

5. About AF, I wrote in my post #66 that 'AF still needs a little tuning', I'm having the same problem. My plan was to use the AF function to test all frequencies in the list for 2 or 3 cycles, save the levels in an array and then search for the highest level to find the correct frequency. The 'This' column is in fact the home frequency to start from, you are tuned to a frequency in the 'This' column? Then look for other frequencies in the 'Frequency' column. But if I manage to get all this working in the DLL you don't need to re-invent the wheel again. Of course feel free to do so, 'the challenge' of writing good HQCT software and my most loyal beta tester (DR Dave :buddy:), brought CPCTuner (and the DLL) to its current level.
And finally about RDS, I wrote my own decoder (RDS.exe uses an older version, the current is much better) and there are others available in .Net and C. I don't think that we need yet another version. It consumes a lot of time to write a good RDS library, believe me, I know and there are already libraries available. But yet again if you want to do it and you have the time for it, don't let me stop you!

Thank you very much for your help!

Best regards,
Putput

Hi PutPut,

Thanks for reply.

1&2) Great thanks - I'll try the new version and let you know how it gets on with the eA too.

3) Yes - I agree. The XML idea popped into my head and even before I finished the sentence I wasn't so sure!! As you say, all we need is some simple messages. Using the RR definitions is good enough.

4) OK - thanks.

5) AF, RDS etc - I really don't want to write another RDS decoding library. Hacking around with the HQCT stuff is fun, but my objective is a good in-car PC with a HU-quality radio, not endless programming! In the UK, AF is vital since the national BBC stations (all I ever listen to) change quite a bit as you drive around.

My frustrations with AF at the moment are twofold:

- At low signal levels RDS data becomes corrupt very quickly - to the point where no AF list is available. I think this is due to PSU noise. When I do the install in the car I'll add some filtering. I may even ditch the M2-ATX PSU since there seem to be lots of posts about it being a noisy unit.

- When I do get an AF list I find that there are often many more frequencies than I was expecting - up to 12 with BBC radio 4 for example. Most of these are junk and since my current strategy is to poll round the list at the rate of one station every 2-3 seconds (to avoid too much muting interference) it sometimes takes quite some time to get a better frequency. On my current HU, if I select a weak frequency, it'll find the best one within a second or two. One idea is to persist the AF list to disk so that I could keep a recent record of frequencies and levels allowing fast startup - this may help.

Regarding your 'First' column - I thought that it was finding 94.5 as an AF since I was tuned to 93.0. However, I could be mistaken (it awas late...)

Regards,

Paul

Quote:

Originally Posted by cockie55

Kosti Team Belgium assure me HQCT's already up and running successfully here in Australia.

With the benefit of the grand work from dudes like Putput I am about to splash out this week and purchase the eA (amp) model and a Centrafuse front end (released this week with Oz maps) ...and the tail end of a runaway 6 months carPC spending spree and leaving me with only mid 90's/OBDI ECU nut to crack.

Great, ok when r u going to order yours as I am cashed up and ready, if your in Sydney, then maybe we can reduce shipping cost and order 2 at the same time?

Feel free to PM to dicuss

Quote:

Originally Posted by Putput

Thanks for the credit!! Let it rock over there!!!! :tune::tune::tune: (I was planning to say down under but here's a question: who says that you guys are under and we are up?? Can someone prove what is up and what is down?? Perhaps I'm under and you are up ... ;))

LOL - glad to see u have a sense of humour..

:peace:

Quote:

Originally Posted by PaulKaye

My frustrations with AF at the moment are twofold:

- At low signal levels RDS data becomes corrupt very quickly - to the point where no AF list is available. I think this is due to PSU noise. When I do the install in the car I'll add some filtering. I may even ditch the M2-ATX PSU since there seem to be lots of posts about it being a noisy unit.

If I may give you an install tip for HQCT in your car:
Connect the HQCT directly to your battery 12V and use a 7805 for the 5V. I did the same and have almost no problems with RDS. Also look for the filter circuit that Diogenes posted in the HQCT hardware thread, I installed that one too with 1 small change. Divide the value of the 12V resistor by 2. Also my latest RDS version should handle RDS errors a lot better, it processes errors per block now instead of per message of 4 blocks.

Quote:

Originally Posted by PaulKaye

- When I do get an AF list I find that there are often many more frequencies than I was expecting - up to 12 with BBC radio 4 for example. Most of these are junk and since my current strategy is to poll round the list at the rate of one station every 2-3 seconds (to avoid too much muting interference) it sometimes takes quite some time to get a better frequency. On my current HU, if I select a weak frequency, it'll find the best one within a second or two. One idea is to persist the AF list to disk so that I could keep a recent record of frequencies and levels allowing fast startup - this may help.

Regarding your 'First' column - I thought that it was finding 94.5 as an AF since I was tuned to 93.0. However, I could be mistaken (it awas late...)

You're not mistaken, actually the first column is the base frequency that the station is transmitting. Here for example we have Studio Brussels transmitting in Brussels at 100.6Mhz and uses 5 other frequencies in the Flemish part of Belgium in the AF list. The first column in the table is always filled with 100.6Mhz for each entry. AF can be transmitted in 2 ways (methods), this information is available in the RDS data. I've added radio buttons to my Settings screen (AF Method, unknown, A type, B type) so that the type of AF is visible for the user. When method A is used (for example Studio Brussels) one stationlist is available with 1 base frequency. When method B is used the station broadcasts AF info for several stations (network) then the list containes entries for all stations and frequencies.

I hope that my explanation is understandable for you.
Just a small thing, if you want to switch stations when looking at the settings screen, click a station in one of the station lists. You can add entries to the station list with the scan function. Make sure that you set the seek sensitivity to the correct level before starting to scan.

Regards,
Putput

Maybe this question should be for the designers, but is there any option to support HD radio?

Quote:

Originally Posted by Kosti

Maybe this question should be for the designers, but is there any option to support HD radio?

You gave the correct answer to your own question, please post this in the hardware thread. Diogenes can give you an answer for this.

Regards,
Luc