SINUS RDS PROJECT
-
- proppa neck!
- Posts: 927
- Joined: Fri Aug 26, 2016 7:01 pm
Re: SINUS RDS PROJECT
I have found a scheme for a digital filter , sadly the IC is not found in my place .
You do not have the required permissions to view the files attached to this post.
- 3metrejim
- no manz can test innit
- Posts: 147
- Joined: Wed Feb 22, 2017 3:00 pm
Re: SINUS RDS PROJECT
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...
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...
You do not have the required permissions to view the files attached to this post.
-
- proppa neck!
- Posts: 2790
- Joined: Tue Apr 05, 2016 1:23 am
Re: SINUS RDS PROJECT
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.
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.
"Why is my rig humming?"
"Because it doesn't know the words!"
"Because it doesn't know the words!"
-
- proppa neck!
- Posts: 927
- Joined: Fri Aug 26, 2016 7:01 pm
Re: SINUS RDS PROJECT
Another easy scheme i found , from another forum .
You do not have the required permissions to view the files attached to this post.
- 3metrejim
- no manz can test innit
- Posts: 147
- Joined: Wed Feb 22, 2017 3:00 pm
Re: SINUS RDS PROJECT
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.
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
- no manz can test innit
- Posts: 147
- Joined: Wed Feb 22, 2017 3:00 pm
Re: SINUS RDS PROJECT
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"
Kindly posted by Eger, here:
https://vrtp.ru/index.php?showtopic=11345&st=1350&
at bottom of page, "other Information.zip"
-
- proppa neck!
- Posts: 927
- Joined: Fri Aug 26, 2016 7:01 pm
Re: SINUS RDS PROJECT
if u have correctly understood , so yes i use the same hex3metrejim wrote: ↑Sun Mar 12, 2023 5:10 pm 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"
- 3metrejim
- no manz can test innit
- Posts: 147
- Joined: Wed Feb 22, 2017 3:00 pm
Re: SINUS RDS PROJECT
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.
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.
You do not have the required permissions to view the files attached to this post.
-
- proppa neck!
- Posts: 927
- Joined: Fri Aug 26, 2016 7:01 pm
Re: SINUS RDS PROJECT
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
- no manz can test innit
- Posts: 147
- Joined: Wed Feb 22, 2017 3:00 pm
Re: SINUS RDS PROJECT
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).
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).
-
- proppa neck!
- Posts: 2790
- Joined: Tue Apr 05, 2016 1:23 am
Re: SINUS RDS PROJECT
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.
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.
"Why is my rig humming?"
"Because it doesn't know the words!"
"Because it doesn't know the words!"
- rigmo
- tower block dreamin
- Posts: 474
- Joined: Wed Jan 30, 2019 9:35 pm
Re: SINUS RDS PROJECT
Albert H wrote: ↑Wed Mar 08, 2023 5:41 pm 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: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.
- 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.
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!
You do not have the required permissions to view the files attached to this post.
- 3metrejim
- no manz can test innit
- Posts: 147
- Joined: Wed Feb 22, 2017 3:00 pm
Re: SINUS RDS PROJECT
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)Albert H wrote: ↑Tue Mar 14, 2023 12:42 pm 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.
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
- no manz can test innit
- Posts: 147
- Joined: Wed Feb 22, 2017 3:00 pm
Re: SINUS RDS PROJECT
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
- no manz can test innit
- Posts: 147
- Joined: Wed Feb 22, 2017 3:00 pm
Re: SINUS RDS PROJECT
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)
-
- proppa neck!
- Posts: 927
- Joined: Fri Aug 26, 2016 7:01 pm
Re: SINUS RDS PROJECT
thanks rigmo
-
- proppa neck!
- Posts: 927
- Joined: Fri Aug 26, 2016 7:01 pm
Re: SINUS RDS PROJECT
thanks 3metrejim
- 3metrejim
- no manz can test innit
- Posts: 147
- Joined: Wed Feb 22, 2017 3:00 pm
Re: SINUS RDS PROJECT
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...
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...
-
- proppa neck!
- Posts: 2790
- Joined: Tue Apr 05, 2016 1:23 am
Re: SINUS RDS PROJECT
"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.
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.
"Why is my rig humming?"
"Because it doesn't know the words!"
"Because it doesn't know the words!"
-
- proppa neck!
- Posts: 927
- Joined: Fri Aug 26, 2016 7:01 pm
Re: SINUS RDS PROJECT
HJH and rdvv original code arent on wayback until you have a working link Albert