Thread: For Guino: USB Radio FM with RDS from Silabs

Originally Posted by RRMobile

FMode is correct. My "idea" of diversity is probably slight different from the standard market.

This summarize the idea:

The first dongle:
1) does an endless scan of the band getting a list of the available station with all the RDS information available.

2) For the ones that have also carry TMC information read and store them in a file for TMC/GPS specific plugin.

3) drive the second dongle to the best (greater signal) frequence for the currentry selected station (same PS).

4) force the second dongle if one of the station is trasmitting a TA message.

The second dongle:
1) tune to one of the 1° dongle station list where the user can also filter the list according to "National" or "Regianal" station and/or current program played (PTY)

forget the word "dongle" or "silabs" ! - you mean radio-tuner

(2)to get the TMC information to the "GPS/TMC" plugin (you mean destinator, ... ?) you have to modulate the RDS datas onto a virtual serial Port along with the NMEA from the GPS mouse.

(4)could also be done if you only have one RADIO-TUNER (not dongle! "Silabs dongle" is a "subgroup" of Radio-Tuner) and you are listening to a station with EON.

(3) a common module can do that without knowing specific radios (HQCT, Silabs) without being recognized by Frontends (Roadrunner, Centrafuse, ...)
So this common module can be programmed later because a change in the frontends and radio drivers is not necessary.
This common module can fill up the EON list with your list of the available stations from point (1). The frontend thinks it is a large EON list ! But it isn't

Originally Posted by RRMobile

In effect i was in the stage to find the TMC specification but I only found sites that sell them at 60€-90€

I also have a very old Pascal source code that I'm using as a guide.
...anything can help

Why Stick on Silab?
Dunno actually I want to start from something that I have in hands.
...life is too short!!!

60-90Euro for ONE of SIX Chapters !

Do you have the locationID's and such from the pascal source ? I have the string-table for Germany (Read my thread please !).

Is life too short to copy+paste your source into a seperate module using my interface definition ? (I like discussions about ! I may have forgetten much... I also like any other common interface definition we don't need to take mine ! only the same - and thats the point)
May be Centrafuse (example) users may also like your Silabs driver ?

Originally Posted by RRMobile

The second dongle:
1) tune to one of the 1° dongle station list where the user can also filter the list according to "National" or "Regianal" station and/or current program played (PTY)

That is frontend implementation ! to give an example what is driver and what is frontend.

I should draw a Visio ? Because noone has fully understand the (my) concept behind it.... (?)
My interface (definition) is like a "Radiatorplugin" only enhanced with RDS.
And it doesn't give you the type problems between a C++ integer and a VB integer because it is written in .NET (and so it gives the freedom to use VB, C#, Delphi .NET, ...) .

Can you (all) imagine what it means if windows wouldn't have any printerdrivers and Office has to support the printers directly ?

Originally Posted by guino

Radiator already offers a plugin interface... The current RR versions do support a "generic" interface through the sendmessage API -- just needs to be documented. I do however want to make a "Standardized" COM/ActiveX interface for this, it only needs a handfull set of functions and properties.

Should we use RR as a radiodriver ? Are you serious ?

But you mean you wannt to copy that generic interface to a COM/ActiveX ?
That is excatly my FMRadioHAL idea.
I like the handling of ActiveX's and COM in the IDE but gives some type problems with C and stuff so I decided to do it in .NET ...

I just got my usb radio Monday it works nice, a lot better then Radio Shark also a lot smaller I would be happy to test any Beta plugin for RR if they are ready

Thanks

FM-RDS & silabs

It looks like some had noticed the RDS data given over USB has some issues with the silabs products.

My steps:
1. Using source code from silabs.com, I edited it to dump all the registers to a file when RDS came in. Basically, overrode the FIFO function to write to a file all 16 registers instead of using a FIFO for four.

2. Read the RDS spec and cleaned up their CRDSData class a bit. Did not introduce errors, just documented each step of their parsing and mapped the group stuff into a more descriptive enum type.

3. Noticing the following discrepancy between the RDS Spec and the CRDSData class code.

------------------------------------------------------------------
RDS Spec:
An important feature of type 2 groups is the Text A/B flag contained in the second block.

Whereby, RadioText Type 2A looks thus:
Block A (Block 1):
._.._.._.._.._.._.._.._.._.._.._.._.._.._.._.._.
0 1 2 3 4 5 6 7 8 9 A B C D E F

PI Code


Block B (Block 2):
._.._.._.._.._.._.._.._.._.._.._.._.._.._.._.._.
0 1 2 3 4 5 6 7 8 9 A B C D E F
|Group Type|| || |-----PTY---|| |--Addr-|
.0..0..1..0..1.| |TP / \
/ \ A/B
B0

Etc.
------------------------------------------------------------------
Source Code:
Where:
registers[0xB] == RDS Read Chan
registers[0xC] == Block A (1)
registers[0xD] == Block B (2)
registers[0xE] == Block C (3)
registers[0xF] == Block D (4)

case RDS_RTO_2A:
// RDS Block B == 0xD
addr = (registers[0xd] & 0xf) * 4;
// RDS Read Chan == 0xB
abflag = (registers[0xb] & 0x0010) >> 4;
// RDS Block C == 0xE
update_rt(abflag, 4, addr, (BYTE*)&(registers[0xe]), errorFlags);

Notice the 5th bit of the Read Chan register is used rather than the 5th bit of the Block B register for the A/B Flag? I tried to update it to use the Block B register 0xD and the text failed to decode.
------------------------------------------------------------------

Using the above information, is it safe to say the chip or firmware is incorrectly updating the Readchan when it means to reference Block B? Is this fixable in the firmware? I also noticed other areas that gave a strange result when I tried to interpret the RDS specification literally.

I live in USA. Might this be due to the case of the USA RDS format being different than the actual RDS spec I hold? You'd think that they'd keep consistency in the block, especially with regards to the fact that READ CHAN is a chip specific register and not mapped directly to something given off the RDS Data stream over the air.

I tried to read the firmware, but it looks like the registers are read from the chip, so I don't feel I am able to influence the correct capture of the A-D RDS Blocks. Can anyone clarify? If you had updated the firmware to support RDS properly or found a workaround for the other group types that seem to have problems; then I am all ears! I appreciate your reading in this far