SINUS RDS PROJECT

[radium98]

I have found a scheme for a digital filter , sadly the IC is not found in my place .

[3metrejim]

Drawing a blank on that IC, comes back as an amplifier for that number.

Maybe an upgrade of the simple transistor chopper, followed by a filter will clean up the sinus rds enough.

Here is most of a 'peripheral device' that I've been working on, just needs a pll for 57kHz, and be fed with (phase shiftable) 19kHz and 38kHz. Still needs the supply to the modulator and filters raising, limited to 5v with the simulator library, but made in parts so different bits can be used for other versions. Intended to be a hardware peripheral for ex. a small (old) PIC or an Arduino, so the processor doesn't need to do so much real-time work.

I guess I just like designing things that are over-complicated, and using 40 year old IC's...

Peripheral.png

[Albert H]

There's nothing at all wrong with 40-year-old ICs - as long as they're still widely available! The NE5532 & NE5534 (two of my favourite op-amps for audio work) date back to the late 70s, and there are few devices - even today - that can provide better performance. They have low distortion, extremely low noise, have a good, sturdy, low impedance output and cost pennies!

I've been playing with better modulation schemes for RDS, and earlier in this thread, I put up a circuit using the same PIC, but using a diode modulator. The purity from this is exceptional (especially compared to use of a simple transistor chopper), and I've had no problems at all synchronising and integrating it with a stereo coder. There is NO "RDS Noise" at all in the stereo signal, and the RDS signal is robust enough to be received even when the S/N ratio is poor.

[radium98]

Another easy scheme i found , from another forum .

[3metrejim]

Yes Radium, the transistor part, the 4046 and 4017 (or any other divide by three arrangement) is the missing piece to the 'peripheral'. I don't have a 4046 model to place into the simulator, but it's got so wide tolerances that it would need building to verify anyway.

Albert, I think that part of the problem with the RDS not being decoded unless there is a good s/n ratio is likely that the data stream is over filtered, making the 'eye diagram' become corrupted. If starting out with a relatively clean data stream, then you can use the correct 'gentle' filtering to avoid corruption (I tried to go for bessel filter)- the really old KD2BD pacsat modem transmit part could almost be used as-is, the only difference being 1187.5 Hz compared to 1200Hz (hardly a difference), with the addition of a differential encoder for the data then the 57kHz modulator. I like to start with all the logic showing, and then you can program parts of it away into a PIC.

It would be interesting to see the data shape from the two pins of the SINUS coder and modify the firmware to use more pins for a better sinewave shape on the data. I am adverse to running the RDS software to get the HEX code as even if it scans safe, it's been compressed and may harbour some sort of virus (and I hate cleaning viruses). With the hex code, I can disassemble it (the old MPLAB allows you to load a hex file and get a disassembly),and re-code the part that generates the data stream, to make it a bit cleaner.

[3metrejim]

Radium, did you find the hex files you were asking for from the Russian site? I got hold of them rather than running the setup program.
Kindly posted by Eger, here:
https://vrtp.ru/index.php?showtopic=11345&st=1350&
at bottom of page, "other Information.zip"

[radium98]

Radium, did you find the hex files you were asking for from the Russian site? I got hold of them rather than running the setup program.
Kindly posted by Eger, here:
https://vrtp.ru/index.php?showtopic=11345&st=1350&
at bottom of page, "other Information.zip"

if u have correctly understood , so yes i use the same hex

[3metrejim]

A gift for those that like to correct bugs. Disassembled and commented (by myself) code from the monRDS (Laston).hex
Looks like it has a bug that makes the data stream run slightly too fast, can check by probing pin 11 (PORT B, 5), there are some other bugs to fix too.

[radium98]

3meterjim thanks for the effort puts on I will it later and I will make the hpf raised by Albert. I would like to ask if you have the .asm 16f84a of t rdvv transmitter the one of hjhsoft.thanks

[3metrejim]

Sorry Radium, I don't have that. If it already works well, and you have the hex file, then it' not really worth disassembling. The transmitter PLL programmer chips don't usually do much apart from read a set of switches, convert into frequency programming for a PLL and then send the result to the PLL. It's not that difficult to program from scratch if needed.

I only disassembled the RDS generator because it has some issues (apparently) and also I was curious. I thought it would be good to share so that someone could do some improvements (bug fixes) or just to see how it works (read the code along with the RDS standard EN50067, and the PIC data sheet), for learning purposes (or coding your own variant).

[Albert H]

Looking at the '628 code, it's remarkably similar to that written for Broadcast Warehouse (though there's only so many ways of writing the code!).

Have you tried adding an extra NOP to the main program loop, to fractionally increase the cycle time?

As I remember, the timing on a couple of the coders I've seen was largely done by huge numbers of NOP steps.

[rigmo]

Turn down the RDS level! You only need a really tiny amount of RDS signal for the receiver to detect it.

The easiest way to set the level is to:

• Turn off your transmitter,
• Turn the RDS level preset all the way DOWN,
• Set your transmitter to a new frequency (you'll see why in a moment),
• Turn on the transmitter into a dummy load,
• Tune your receiver to the new transmitter frequency,
• Very slowly turn up the RDS level until the data appears on the receiver display,
• You're done! You should now find that the RDS data signal is inaudible.
• Tune your transmitter to the frequency you actually want to use.

The reason for selecting a new frequency is that your receiver may "remember" that the old frequency contained particular RDS data, and "helpfully" display it even if no data is received! My Sony portable sometimes does that.

If you find that there's still noise evident, you have a problem with the coder producing subharmonics of the 57kHz subcarrier. If this is the case, add a 56kHz highpass filter to the output of the RDS coder (NOT to the whole modulation path). This will strip off any lower subharmonic images from the RDS signal, whilst still letting through the crucial 57kHz subcarrier. Here is a simple circuit for an op-amp filter:
56kHz HPF.jpg

Is your transmitter stereo? If it is, you need to synchronise the 57kHz RDS subcarrier with the 19kHz stereo pilot tone, to eliminate any spurious "beat" products. I put a suggested circuit on here (earlier in the thread) to synchronise the RDS subcarrier.....

If you still have problems, let us know!

[3metrejim]

Looking at the '628 code, it's remarkably similar to that written for Broadcast Warehouse (though there's only so many ways of writing the code!).

Have you tried adding an extra NOP to the main program loop, to fractionally increase the cycle time?

As I remember, the timing on a couple of the coders I've seen was largely done by huge numbers of NOP steps.

Not quite (and I've never seen the BW code for the old kit RDS coder, not sure how you did, unless you were the author)

The 57kHz is generated by the 628's CCP module in PWM mode, and will not quite be 50:50 duty cycle due to hardware limitation when running with a 4.332MHz clock. The data rate is derived from a timer0 overflow interrupt.

Bug list so far, just from reading the code, and with a quick look, looks like both versions of the 628 code have similar issues.

* The data rate is generated by a timer 0 overflow interrupt intended to be running at 4x the data rate (except that when you calculate the rate, the reset value the counter should take is slightly different from that in the disassembly)
* There is a dodgy interrupt context save/restore (possibly from the old compiler used)
* AF (alternate frequencies) transmitted are indeterminate.
* Wasteful use of memory (also the fault of the compiler).
* Changing the PI code and Program type will likely not work.
* Attempting to send a time update will likely not work (do pirates really need this?)
* Little error checking on supplied data (not a great problem if the intended program is used with it)
* RDS output will stop when the current settings are saved to EEPROM. (a major re-write needed to fix that one, but probably not a problem in normal use)

I think that is most of the bugs that I've found so far.

If someone can run the program and provide a loopback dump (serial output to serial input of a terminal program) of the commands sent (everything bar PS name change and RT, which seem to be ok), it will help in fixing most of the bugs.

[3metrejim]

* The data rate is generated by a timer 0 overflow interrupt intended to be running at 4x the data rate (except that when you calculate the rate, the reset value the counter should take is slightly different from that in the disassembly)

Actually I was wrong about this. I forgot to count the cycles leading up to the counter reset and interrupt latency. No adjustment required here.

[3metrejim]

* The data rate is generated by a timer 0 overflow interrupt intended to be running at 4x the data rate (except that when you calculate the rate, the reset value the counter should take is slightly different from that in the disassembly)

Actually I was wrong about this. I forgot to count the cycles leading up to the counter reset and interrupt latency. No adjustment required here.

Turns out I was also wrong about the PI and program type possibly not working. Made a mistake deciphering the code that a compiler produces (not always obvious).

However, the time function can fail under certain circumstances (when the data contains an 0x0A as that is also used to signal end of input)

[radium98]

thanks rigmo

[radium98]

thanks 3metrejim

[3metrejim]

Some information from the disassembly regarding what to send to the MonRDS/SINUS coder. Could come in handy if you want to dynamically change the radiotext (assuming you can obtain/write the needed software that sends text to the serial port on demand). There may be errors, but done to the best of my ability.

Serial Comms for MonRDS / SINUS
Version: MonRDS628(LastOn).hex (other versions may be similar)

Serial settings: 9600 N,8,1

Set Program Service name

PS[8 bytes of PS Name],0x0A
Note: Use all 8 bytes, fill empty bytes with spaces

Set Radiotext (different versions may have different length limits)

RT[35 bytes of RT text],0x0D,0x0A
Note: Use all 35 bytes, fill empty bytes with spaces. Must end in 0x0D
A bug means some garbage may be transmitted or text in the wrong place.

Set or clear Traffic Anouncement flag

TA[x],0x0A
Note: x is a single digit decimal number (0 clear, 1 set). TP flag should be set first

Set or clear Traffic Programme flag

TP[x],0x0A
Note: x is a single digit decimal number (0 clear, 1 set)

Set or clear Music / Speech flag

MS[x],0x0A
Note: x is a single digit decimal number (0 clear, 1 set)
There is no error checking so ONLY use 0 or 1 here.

Set Decoder Information

DI[xx],0x0A
Note: xx is a two digit number from 0 to 15. There is no error checking so anything outside of this range may result in odd/wrong behaviour.
Possibly useful values:
00 for mono, 01 for stereo.
See RDS spec EN50067 for more information

Set Program TYpe

PT[xx],0x0A
Note: xx is a two digit decimal number between 0-31, numbers outside will likely cause the wrong Programme TYpe to be transmitted.

Possibly Useful values:
10 = Pop music
11 = Rock music
15 = Other music
20 = Religion
24 = Jazz Music
25 = Country music
26 = National music
27 = Oldies music
28 = Folk Music

See RDS specification EN50067 for other options

Set PI code

PI[xxx,yyy],0x0A
Set PI code bytes, xxx and yyy are three digit decimal numbers between 000 and 255
Note: There must be no space between the digits and the comma. Only use the digits between 0 and 9 and numbers less than 256 to avoid improper operation

(Wrong PI code).

TI[bbbbb],0x0A
Note: Sets clock time data to bytes b, in order, and transmits a single clock time group. A bug means that any byte equal to 0x0A will break this command.

Restore from EEPROM, loads last saved settings

RM,0x0A

Save current settings to EEPROM

SM,0x0A
Note: RDS output will stop during this operation.


Square brackets are NOT sent, commas outside of the brackets are NOT sent...

[Albert H]

"Not quite (and I've never seen the BW code for the old kit RDS coder, not sure how you did, unless you were the author)"

The BW firmware came from (AFAIK) HJH Software in the Netherlands. There was HJH code on the 'net years ago (might be on the Wayback Machine), and I think that I've got an early version here on a drive somewhere (from the days of 16C series PICs!). It was quite limited, and didn't allow all groups to be set - some were fixed. There was a later version that transmitted TOD extracted from an off-air clock module (receiving DCF77!), and there was a commercial version of this coder from an Italian manufacturer in the early 90s. I've got one here in the junk pile.

Our earliest coder used a data stream from a PC into a hardware coder - later put on the 'net as "ERDS" - and several pirates used this approach - particularly where they were using a PC for automated playout of programmes.

[radium98]

HJH and rdvv original code arent on wayback until you have a working link Albert