HQCT Module (new thread following HU RDS/RDBS)

[emumanXM]

Actually, designing software should be pretty easy. You need to tell the USB micro to do whatever on the i2c bus. I'm not sure what the code on the USB micro does, but it should simply parse data and commands to and from the i2c bus. It should read the bus for RDS data, fieldstrength level USN, WAM, IF readout, and send commands to the i2c bus like configuration, frequency change, band change, audio setting change, etc.

It's easier because the i2c overhead is taken care of with the USB micro. So, communication with a HID device is all that is needed. I'm not a programmer by any means, but I think it should be as tough as it seems.

Jonathan

[JC-S60]

Developping a framework is always more work than just developping natively.

Only if you wanted to support a lot of different hardware, it would make sense. Since there are not many radios out there, I think it complicates stuff a lot, without adding much value.

If the "market" were bigger, it would certainly be the way to go!

[TheLlama]

Quote: Originally Posted by racemier

Quote: Originally Posted by TheLlama

Do you guys know a HID library that works in C or C++? I found a few, but I figured someone here must have some insight.

we will take a look.

regards,

Have you guys found anything? I looked at http://www.frogmouth.net/hid-doco/linux-hid.html It is a HID device. So, it is up to the userspace program to implement the actual protocol. I'm still thinking it would be better having the whole driver as a single device.
I'm not even that familiar with what HID is. I know it stands for Human Interface Device. But is it a communications standard or just a classification of device? I mean, the radio really isn't a human interface.

I've looked at the specification for controlling the HQCT and I'm familiar with the parts that are documented. Looks like Hiddev might be a great way to go, but I really need to experiment with the actual device (hint hint).

Edit: I found an ebook on programming USB device drivers in Linux using Linux's USB-core. It looks like the USB system is fairly simple as far as hardware APIs go.

Regards

[pradecki]

so any updates on when the tuner will be shipped? - planning on building my system over the next two weeks so i'm planning on integrating one of these tuners. oh has the price been finalized yet? looks pretty awesome jsut can't wait to get one

[FMode]

Quote: Originally Posted by antimatter

I dont give a crap how it works or how the front end developers choose to integrate it... as long as they do. And for them to do that it is pretty typical to have a test unit hence my original statement.

ultimately it is up to raciemer and co

You will not get rid of a "driver" - if it is extern or internal in the frontend integrated - the internal driver could be buggy - *you* can't replace it with a new version and if the author of your favorite (free) frontend has no intention to continue development - then your opinion may change...

Quote: Originally Posted by JC-S60

Developping a framework is always more work than just developping natively.

In case your program looks like:

Code:

Function Something()
Redraw Buttons
DoingStuff
...
If Button="Tune up" then
Serial.Send "HQCT_Tune_up_blahblah...", COM1, 57600
Serial.Wait "HQCT_Tune_up_Ack"
End if
If Button="Tune down" then
Serial.Send "HQCT_Tune_down_blahblah...", COM1, 57600
Serial.Wait "HQCT_Tune_down_Ack"
End if
End Function

(you have mixed up internal programm logic with radio-control logic)
in this case you are right - but this is bad code as it violates the modularisation-rules and you have to be kicked in your butt that it hurts

Code:

Module Blah()

Function Something()
Redraw Buttons
DoingStuff
...
If Button="Tune up" then
 Call Radio_TuneUp
End if
End Function

Function Radio_TuneUp()
Serial.Send "HQCT_Tune_up_blahblah...", COM1, 57600
Serial.Wait "HQCT_Tune_up_Ack"
End Function
End Module

In this case it means to create a "ClassLibrary-Project", to cut and paste Function "Radio_TuneUp" into the Class Libary and to reference the ClassLibary from the Frontend - one hour work ?

Quote: Originally Posted by JC-S60

Only if you wanted to support a lot of different hardware, it would make sense. Since there are not many radios out there, I think it complicates stuff a lot, without adding much value.
...

If you think it is complicated than just have a look at my proposal: shows how stuff works for COM (VB6) and .NET (VB.NET) with a minimal-frontend
(and believe my that was not complicated ).
i have also screenshots on my site from the "frontend-programmers-view"
http://netsh88.hades.net-build.de/fm...diohal/vb6.jpg
If I get some reactions like "tried your Radiator driver and works" then I will put up a HQCT driver...

[bugmenot13]

xtronic.be says end of march, the end of march has come and gone...

[0l33l]

I haven't been on the boards for like a week or two and there still hasn't been any development.

[JC-S60]

Quote: Originally Posted by bugmenot13

xtronic.be says end of march, the end of march has come and gone...

Sorry, that was what I was expecting... updated the site, hoping this time we'll get it right!

[TheLlama]

Quote: Originally Posted by FMode

You will not get rid of a "driver" - if it is extern or internal in the frontend integrated - the internal driver could be buggy - *you* can't replace it with a new version and if the author of your favorite (free) frontend has no intention to continue development - then your opinion may change...



In case your program looks like:

Code:

Function Something()
Redraw Buttons
DoingStuff
...
If Button="Tune up" then
Serial.Send "HQCT_Tune_up_blahblah...", COM1, 57600
Serial.Wait "HQCT_Tune_up_Ack"
End if
If Button="Tune down" then
Serial.Send "HQCT_Tune_down_blahblah...", COM1, 57600
Serial.Wait "HQCT_Tune_down_Ack"
End if
End Function

(you have mixed up internal programm logic with radio-control logic)
in this case you are right - but this is bad code as it violates the modularisation-rules and you have to be kicked in your butt that it hurts

Code:

Module Blah()

Function Something()
Redraw Buttons
DoingStuff
...
If Button="Tune up" then
 Call Radio_TuneUp
End if
End Function

Function Radio_TuneUp()
Serial.Send "HQCT_Tune_up_blahblah...", COM1, 57600
Serial.Wait "HQCT_Tune_up_Ack"
End Function
End Module

In this case it means to create a "ClassLibrary-Project", to cut and paste Function "Radio_TuneUp" into the Class Libary and to reference the ClassLibary from the Frontend - one hour work ?



If you think it is complicated than just have a look at my proposal: shows how stuff works for COM (VB6) and .NET (VB.NET) with a minimal-frontend
(and believe my that was not complicated ).
i have also screenshots on my site from the "frontend-programmers-view"
http://netsh88.hades.net-build.de/fm...diohal/vb6.jpg
If I get some reactions like "tried your Radiator driver and works" then I will put up a HQCT driver...

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.

[Diogenes]

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

[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]

Quote: Originally Posted by TheLlama

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