HQCT software development - Page 5

Kosti · 06-09-2007, 09:25 PM

Keep it up Putput!

Thanks for the tips

Putput · 06-10-2007, 08:01 AM

Quote: Originally Posted by Kosti

Keep it up Putput!

I can assure you, thats where it is!

(but not al the time, only when needed)

Quote: Originally Posted by Kosti

Thanks for the tips

Your welcome.

Putput

mischka76 · 06-12-2007, 11:51 AM

Quote: Originally Posted by Putput

Sorry for the delay, family bussiness got in the way. So update not finished yet, still working on it. The hibernate problem is solved but needs some more testing, and any changes in CPCTuner are also reflected in the DLL because both use the same HQCT component as a base. This also means that the settings form will be available in the DLL. (see image) AF and traffic/news are also still under construction. The volume buttons are implemented and the registry call is made read only. Are there any other improvements that you expect?

Putput

hi

any progress on this yet?

cockie55 · 06-12-2007, 12:03 PM

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.

seninha · 06-12-2007, 02:37 PM

Putput. I want to try your version of the HQCT drivers, problem is that I use Roadrunner as frontend.
At this moment I use the Mauri skin, wich already has a radio skin in it.

Is it possible to make this skin use your HQCT driver instead of the original one??

Putput · 06-12-2007, 03:19 PM

Quote: Originally Posted by mischka76

hi

any progress on this yet?

Yes there is! Sending first beta today to a couple of users (Datalex, ...) to be tested for:
- HQCT_eA support/settings
- Brand new settings screen (with almost all tuner settings available) included are:

- All tuner parameters like AGC, Bandwith, IF, Reference freq, DAA values, Center frequency, Level start, Level slope, Freq. offset, Freq. gain, Local/Distant
- Mute on exit
- Detect hibernation
- COM port/signal for automatic antenna control (thanks to DR Dave!!)
- Seek sensitivity
- Region settings for EU/USA/JAP
- AM/FM stations list
- Treble
- Bass
- Loudness
- Fader
- Channel switching
- RDS enabled/disabled
- AF regional
- RT Overwrite
- AF sens. level
- Viewing AF list and EON data

And HQCT_eA settings form (only available when a HQCT_eA is connected):
- Channel switching
- Thermal warning level setting
- Clip detection level
- Amplifier gain channel 1&2
- Amplifier gain channel 3&4
- Amplifier on/off
- Visualisation per channel for:
** Load short circuit
** Output offset
** Short to Vp
** Short to GND
- Visualisation for:
** Thermal warning, temp > 120C
** Thermal alarm, temp > 175C
** Power on reset (Amplifier off)
** Temperature too high (Amplifier off)

- AF (needs still a little tuning)
- Improved RDS
- Up/down volume buttons next to volume slider
- Support for all HQCT modules : _i, _e, _eA

I think that this is a pretty good overview on what I've worked on for the last couple of weeks, perhaps it also explains why it took a little longer then a few days.

As soon as the HQCT_eA stuff is tested (I personnally don't have an HQCT_eA) the new version will be released. I'm using it right now in my car and it works pretty good.
Keep you all informed about the progress in this project!
ATA: end of the week.

Regards,
Putput

blk02si · 06-12-2007, 03:39 PM

Awesome news. I am still using build 43 of your software on my embedded system and its been flawless since it was installed. Looking forward to see what you've been cooking putput

I think I speak for all the end users when I say thank you for your time and devotion to the software

Putput · 06-12-2007, 03:41 PM

Quote: Originally Posted by seninha

Putput. I want to try your version of the HQCT drivers, problem is that I use Roadrunner as frontend.
At this moment I use the Mauri skin, wich already has a radio skin in it.

Is it possible to make this skin use your HQCT driver instead of the original one??

Hi Seninha,

Yes it is possible, have a look at post #30 in this thread. It describes how to replace the original files with CPCTuner for support in RR. If your RR+skin works with the original software it will also work with CPCTuner. You can find all you need here. There is also a RRHQCT.EXE replacement available that prevents CPCTuner from showing its splash screen, scroll down a few lines and look for "RRHQCT replacement for RoadRunner without splash screen showing".

Success!

Putput

PS Another possibility is that someone with knowledge of RR and VB uses my HQCT.DLL to integrate native HQCT support in RR. In this way there is no need anymore for a third party application running in the background when using HQCT. Volunteer anyone ... ???

Putput · 06-12-2007, 03:51 PM

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.

Thanks for the credit!! Let it rock over there!!!!

(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 ...

)

mischka76 · 06-12-2007, 05:10 PM

thats great news putput! I'll be looking forward to the release of the new dll ..

Quote: Originally Posted by Putput

Thanks for the credit!! Let it rock over there!!!!

(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 ...

)

i think the north is generally up and the south is under? so they are below us in that sense.

btw, you know how an australian kiss goes?

!rednu nwod tub ,hcnerf eht ekil

PaulKaye · 06-12-2007, 06:38 PM

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

Putput · 06-13-2007, 01:53 PM

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

PaulKaye · 06-13-2007, 05:50 PM

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?

Putput · 06-14-2007, 03:59 PM

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

), 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

PaulKaye · 06-15-2007, 06:10 PM

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

User Name		Remember Me?
Password