HQCT Module (new thread following HU RDS/RDBS) - Page 9

TheLlama · 03-18-2006, 12:37 PM

Ok, Curve ball:

Racemier and Diogenes, I've been looking at the code some more, and I think it would be a heck of alot easier to just build my driver from the specifications instead of based on someone else's code. I understand the basics of the transactions. 32 byte packets containing either control sequences or a status report. Are the more detailed software specifications available yet? If not, can you point me toward the right region in the source?

I just wanted to mention, to any Linux users, that I am writing a driver that runs as a kernel module and is exposed to the user environment as a character device. So you can just pipe stuff to and from /dev/radio for example.

Thanks guys, great work!

emumanXM · 03-18-2006, 10:00 PM

Lets stop acting like children and a$$holes. The radios will be ready when they are ready and a price will be determined when a price will be determined and thats that. For all you who are pooping your pants about the software, I have something that will save your drawers. I have the philips control software which will control the TEF6892 and the Microtune tuner containing the TEA6849. You need to build a 74LS05 parallel port I2C interface to interface the I2C port to your parallel port. The software tunes and aligns the tuner, configures the audio processor, and decodes all RDS/RBDS data and has a radio text display. A pic of the software in action is at the bottom of page 4. A link is also there too. If anyone wants to host it, please let me know if the link is dead. Please don't ask me for support, as I am not in the position to give any because I know very little. The TEA6849 and TEF6892 datasheets should answer all your questions.

Jonathan

TheLlama · 03-18-2006, 11:08 PM

Quote: Originally Posted by emumanXM

I have the philips control software which will control the TEF6892 and the Microtune tuner containing the TEA6849. You need to build a 74LS05 parallel port I2C interface to interface the I2C port to your parallel port. The software tunes and aligns the tuner, configures the audio processor, and decodes all RDS/RBDS data....

Why do we want to do that if they have a usb pic controlling the thing already?

Diogenes · 03-19-2006, 05:10 AM

Right,

besides, we supply the unit WITH software that does work, software WITH source code so it can be modified to anybodys particular taste.

Diogenes

camsgs3 · 03-19-2006, 09:04 AM

Quote: Originally Posted by emumanXM

Lets stop acting like children and a$$holes. The radios will be ready when they are ready and a price will be determined when a price will be determined and thats that. For all you who are pooping your pants about the software, I have something that will save your drawers. I have the philips control software which will control the TEF6892 and the Microtune tuner containing the TEA6849. You need to build a 74LS05 parallel port I2C interface to interface the I2C port to your parallel port. The software tunes and aligns the tuner, configures the audio processor, and decodes all RDS/RBDS data and has a radio text display. A pic of the software in action is at the bottom of page 4. A link is also there too. If anyone wants to host it, please let me know if the link is dead. Please don't ask me for support, as I am not in the position to give any because I know very little. The TEA6849 and TEF6892 datasheets should answer all your questions.

Jonathan

please tell me how is that carPC friendly?? + alot of people on this forum will have no idea how to set that up(what u descibed above)myself included

Ther are alot of peps, like myself that cant develope ****, like what u mentioned above sounds like all starwars **** to me, i would have no idea where to begin...and if im paying money for the hardware i would like a plug and play device that would let me load up any frontend and start working

TheLlama · 03-19-2006, 11:37 AM

Quote: Originally Posted by Diogenes

Right,

besides, we supply the unit WITH software that does work, software WITH source code so it can be modified to anybodys particular taste.

Diogenes

Yup. Things a difficult now because the software appears to still be in its first draft and the damned module hasn't even been released yet. How can we complain about software support for something that cannot be purchased?

Diogenes · 03-19-2006, 11:47 AM

Hi,

camsgs3 should not only write posts but also read what is written by others, if you can copy an exe file to your carPC and if you can make that exe run you have all you need to use the HQCT. You also need to know how to hook up power to it, an antenna is needed and the audio output must be connected to some kind of amplifier...

Diogenes

TheLlama · 03-19-2006, 12:39 PM

Quote: Originally Posted by Diogenes

Hi,

camsgs3 should not only write posts but also read what is written by others, if you can copy an exe file to your carPC and if you can make that exe run you have all you need to use the HQCT. You also need to know how to hook up power to it, an antenna is needed and the audio output must be connected to some kind of amplifier...

Diogenes

I think he was referring to the idea of interfacing i2c over the parallel port, etc..

ccsnet · 03-19-2006, 04:09 PM

Guys - found this... not sure if its any use but allows NMEA / TMC output...

CTRM-03 FM RECEIVER MODULE WITH RDS/TMC

Quote:

The CTRM-03 is a small and sensitive FM digital receiver module that
decodes RDS and TMC information with stereo sound output.
It can be easy integrated into devices for mobile navigation suchs as
PDA’s, PNA’s etc. The SMD PCB can be soldered directly onto
another PCB.

Main Features
- Digital FM-PLL Synthesized high sensitivity receiver
- Frequency FM 87,5 MHz – 108MHz. high quality stereo output.
- Integrated RDS/TMC decoder, with TTL output
- Universal Open TMC protocol and NMEA protocol.
- Power save function and low power consumption
- Spacing for USA and EU possible
- RDS (EU) and RBDS (USA-Japan) decoding
- Sensitivity 3uV or better
- Small SMD single side component pcb of only 16 x 32 x 2,7mm

Terran

alpha_maverick · 03-19-2006, 05:08 PM

shouldn't that go on the original thread?

0l33l · 03-20-2006, 12:57 AM

This is better. Also has AM. That site has a few more modules

TheLlama · 03-20-2006, 01:17 AM

Quote: Originally Posted by 0l33l

This is better. Also has AM. That site has a few more modules

Except that it lacks the usb interface and who knows about cost (but who knows here either?)

Quick Question, I see the HQCT1 module is around 100x50mm. How deep is it?

Diogenes · 03-20-2006, 02:20 AM

Quick answer,

30 mm deep (100 long and 56 wide)

mounting holes are 49 mm apart on short side and 93 on long side and have 3.5 mm diameter.

Thanks for the links about tuner modules, i'm looking into them, so far only interesting pictures, nothing tangible (yet)

diogenes

lchatela · 03-20-2006, 03:39 AM

We have to undestand that this is a project and not a true commercial product (perhaps later but not now). The delivery of the hardware is a step of the implementation. Then we will have to wait for software or better: work on it.
At the end of march we won't have a plug'n'play solution, we will have to wait further software implementation to have full support in all front ends.

If people wants to have support for a particular front end, they have to pay a unit and send it to the developpers of the front end. The original team can't send free unit to everybody (unless they have a serious business plan and think that the units will be sold at high volume but I am not sure that is the case).

That means 2 things:
- we have to work on the sotware part to add support for frontends
- the price of the first units should be adapted to all this things (strong hard testing will be made by first users and software will be at a beta state) (and that's perhaps why it's is hard for them to give us a price now).

This project is a great improvement for the community so we have to support them for this step.

FMode · 03-20-2006, 05:29 AM

> "supported-frontents-by-HQCT-discussion" ...

The problem is not new...
Many frontends do something which is clever:
They use Radiator !
Oooops no RDS suppport !

So why don't we learn from Radiator ?
Why don't we extend the Radiator-protocol with RDS or something like that ?

I have done it and called it FMRadioHAL (see it as a proposal!) (it is for .NET and for COM):
http://netsh88.hades.net-build.de/fmode/radiohal/

This thing gives the frontend a radio which could be "tuned" and delivers field-strength and RDS data in RAW format (!) - no decoding only error correction... Then the frontend could use an RDS decoder module to get Station-name etc...

Or do you know which cool ODA (OpenDataApplication)-Services in the RDS-stream every radio-station in the world transmitts ? - so don't implement a RDS decoder in HAL

!

And BTW one ODA service is TMC. So it would be nice if the RDS module starts a virtual COM Port (this could be done in a later version) gets NMEA stream from the gps mouse and merges it with the TMC data (in GNS protocol style) - (in an later version) - so also no RDS decoder in Frontend !!!

So what could be done ? :

I have looked at the Delphi Sources and could implement a (FMRadioHAL) version (means: frontend coders could test it just now with my FMRadioHAL version for Radiator I can add a RDS simulation if you like, also means Frontend coders didn't need to buy a HQCT) OR the coder rewrites it in Delphi .NET then Frontends could use it directly - if he splits the radiocontroll-part into a seperate assembly.