HQCT Module (new thread following HU RDS/RDBS)

[TheLlama]

Diogenes: What mode of input and output does the unit? Control, Isochronous, or Bulk transfer?

I'm guessing it is all just control strings.

[FMode]

You are completely right about separating everything into layers and that is what we plan to do. However, a COM object is not enough because not everyone will be using Windows. Therefore we have the .DLL that can be used by Windows applications and a kernel module for Linux. However, these interfaces haven hardened yet considering none of the developers have received parts yet.

The DLL is also a used by Linux (x86) ?

DLL's suxx - they can't tell you something about theirself - a COM Object can do it pretty nice (Object-Browser).
But to do things right you have to use .NET (on Windows) - advantage in simple words:
different language (your favorite!) - same (data)types !
and in my meaning the COM Object is only a wrapped .NET Assembly.
The COM Object is only there because it is easy to build (one line source code) and because there are some oldfashioned people using VB6 ...

[Peoples]

if the kernal mode driver is open source, and the DLL is well documented, shouldnt be a problem. I doubt they don't want to market this thing to their market (.....that being us). Without sourcecode, none of use are going to want it. Most of our apps are not in .NET, don't see a reason why this would be.

[TheLlama]

Yes, the Linux kernel module will be open sourced as well as a sample app. Since the code is implemented within a driver, user applications will not have to implement any of the protocol. In fact, you could update to a newer version driver without updating the application.

As far as Windows goes, I believe placing the code in a DLL is the best option. It can be used by programs written in any language for Windows including C, C++, and more. Plus, it would not be hard to wrap a COM object around the DLL. However, the Winblows solution does not work that way. There is only one DLL that is used for accessing the USB port. The code to interact with the unit must be reimplemented by every frontend.

Now, this is where things stand currently. The units haven't even been released yet. I am doing the development for Linux but not for Windows so I don't know what the development path is.

[bugiman]

This links may come in handy:

http://libusb-win32.sourceforge.net/

http://www.sharpdevelop.com/OpenSour...b/default.aspx

[FMode]

if the kernal mode driver is open source, and the DLL is well documented, shouldnt be a problem. I doubt they don't want to market this thing to their market (.....that being us). Without sourcecode, none of use are going to want it. Most of our apps are not in .NET, don't see a reason why this
would be.

Without sourcecode, software is crap ! (=agree)

I love .NET discussions !

M$ does a lot of crap I know...
BUT also some really powerful things:
- the network-neighborhood where you see all your computers (yes somewhat stolen from Apple and then "pimped" I guess?)
- .NET

IMO: you are programming under windows without .NET - your problem !
I don't take care of anything outside .NET because you will/may find your favorite language under .NET and also if its not VB.NET our modules could work together as they were coded in the same language ! No more fiddling around with datatypes.(What is a "C" uint in Delphi ?)

You could also document your modules with a 1000 page-book - .NET Assemblies or COM Object are easier to handle in the development environemt and i don't need any documents if the functions (and their vars)have a sensefull name.

...However, the Winblows solution does not work that way. There is only one DLL that is used for accessing the USB port. The code to interact with the unit must be reimplemented by every frontend...

To be precise a .NET Assembly is a DLL in the filesystem.

But if you are creating your DLL as native DLL then its your effort and I can live with it and i am also interested in it.
May be its a good idea to look in my proposal - to get "missed" attributes of such a Radiolayer (Tuningfrequency, RDS, Fieldstrength, ...) - Whats missing ? ) I don't think mine is complete but if more coders think about it chances are better to get everything.

[antimatter]

Quick status update, its over midnight and i want to go to bed!

As posted previously we got the first batch of 100 modules in and fitted with SMD components, i rigged up a test stand so i could do a preliminary functional test on them. Tested the first one, it passed, mounted the rest of the components and switched it on: it worked. So fase 1 is OK, i then devoted my time to finishing the firmware, got it right, and just finished preliminary testing on another 23 modules, 20 OK, 3 failed (partially). We'll be assembling those and the remainder (that pas the prelim. test) these coming days.

Quick reminder on features:
- all settings have to be done via USB
- the module is a USB HID device, VID is $04D8, PID is $000A
- the module sends and receives 32 byte reports
- unit 'remembers' last settings when switched off
- require both 5 and 12 V DC, connector is disk drive type
- output is via SIL header, same as sound header of cd player
- additional 12 pole SIL header to connect Aux, Phone and Nav sound input
- on same header a digital signal to switch to phone or nav system is provided, this signal is forwarded to the PC via the USB channel
- the module sends a report periodicaly, this carries the reception level signal, stereo indicator, sync indicator (for RDS), overflow (RDS) IF count (indication of reception quality), WAM and USN figures and RDS data if any.
- at switch on and on demand, the module send the tuner module alignment data that has to be used to calculate the tuner settings.
- The HQCT software (that you get with the unit, runs under windows) takes care of these signals and puts them on a display, has input boxes to select frequencies, FM or AM, inc and dec freq., switch to aux, phone or navigation, station identity and decodes RDS data (some of it), since it comes with source code you can adapt it to your likes (some people posting here think it is easy... so have a go at it... )

Diogenes

Glad to see things moving along and thanks for the update.

I do however think it is very bogus that you guys havent posted a price. There is no way you dont have the pirce narrowed in on this late in the game. So spill the beans. Whats the price?????????

[alpha_maverick]

at the very least, a price range would be nice.

[TheLlama]

IMO: you are programming under windows without .NET - your problem !
I don't take care of anything outside .NET because you will/may find your favorite language under .NET and also if its not VB.NET our modules could work together as they were coded in the same language ! No more fiddling around with datatypes.(What is a "C" uint in Delphi ?)

I agree. But .NET isn't really as great as many people claim.

You could also document your modules with a 1000 page-book - .NET Assemblies or COM Object are easier to handle in the development environemt and i don't need any documents if the functions (and their vars)have a sensefull name.

Thats what I use Doxygen for, I can generate HTML and PDF documentation of all the code and interfaces.

To be precise a .NET Assembly is a DLL in the filesystem.

But if you are creating your DLL as native DLL then its your effort and I can live with it and i am also interested in it.
May be its a good idea to look in my proposal - to get "missed" attributes of such a Radiolayer (Tuningfrequency, RDS, Fieldstrength, ...) - Whats missing ? ) I don't think mine is complete but if more coders think about it chances are better to get everything.

I guess that is true. My point is that keeping all of the driver logic separate could be a better choice because frontend authors do not need to keep their radio code consistant with the newest release. What is worse is if the authors have modified the code to suit it instead of just building on interfaces.

[aeroanderz]

sorry to interrupt the language discussion, but I have a wuestion that I havent quite figured from the existing FAQ's..

Will the 2.0 and 3.0 versions have balanced or unbalanced outputs?..

I guess it'll have unbalanced since I imagine it will require less hardware (equals cheaper), but since my amplifier take balanced inputs and the car is full of possible disturbance, it would be nice...

Also, will the european site (xtronic) sell all three versions or just 1 and 3? (I need v2)

Thanks!