S/PDIF over 5.8GHz radio link

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Hi guys,
I'm looking for some help with a radio transmission problem, but it pertains to digital audio.

Basically my use case is that I have a pair of mobile soundsystems on wheels, which need to be able to play the same music at the same time, whilst in motion, within a range of up to 20 metres. My budget precludes using any of the industry-standard wireless audio equipment from eg Sennheiser or Shure.

I've had moderate success using domestic 5.8GHz "AV Sender" transmitters and receivers to create a radio link that transports an S/PDIF stream over the analogue video channel (yellow RCA connector). Reception is very clear and the range is up to 50 metres, but only when the two stations are not moving. As soon as there is significant relative movement between TX and RX, the audio signal starts to break up unacceptably. This situation is improved somewhat by using circularly polarised antennas, but remains an issue. It is not improved by using a higher-powered transmitter - the original system radiates 25mW, but even moving to an 800mW TX does not make a lot of difference to the movement problem.

I've been analysing the signals in the system on my 50MHz Tektronix scope and have a couple of questions (pictures included below).

1) The first picture is the S/PDIF waveform as measured at the input of the TX. It is reasonably square, but should there be so much ringing at the transitions?

2) The second picture is the signal as measured at the output of the RX, terminated into 75 ohms. It is obviously quite badly degraded, although the DAC can still lock onto it with surprising accuracy and reconstruct a good audio signal....most of the time. Should I expect to see a better-looking received signal, given the bandwidth of a composite video channel?

3)Having observed these signals, it is easy to see on the scope that physical movement of either station causes a large timing deviation in the received signal, which I suppose would constitute a massive amount of jitter in the digital bitstream. Given that, is this system doomed to failure, or could I re-clock at the receiver and gain an improvement?

Thanks in advance for any help you can offer :)
 

Attachments

  • transmitted.jpg
    transmitted.jpg
    424.6 KB · Views: 233
  • recieved.jpg
    recieved.jpg
    407.8 KB · Views: 230
Using S/PDIF as RF transmission signal with a standard (analog) AV RF link is not a good idea for several reasons!
1. The S/PDIF fundamental clock frequency is around 1.7 MHz - thus the video bandwidth will definitely degrade the signal as a square wave signal is composed of the fundamental and many many higher harmonics which will be 'cut' by the AV bandwidth. Your scope images clearly show this
2. The S/PDIF signal must be highly stable and have low jitter as the signal is directly used to sync the local clock oscillator at the receiving end to reclock the signal. Any increased jitter will lead to degraded sound quality or to a total loss
3. The wavelength at 5.8 GHz is a mere 6.5 cm - this means that especially in cases where you may have signal reflections like in a room or some other objects around- you will see strong signal strengths modulation by slight movements of the receiver. Small shifts may already lead to a total signal null independent of the transmission power - this was also one of your observations as increasing transmission power did not improved signal quality a lot.
 
Thanks for all your replies :)

Yes I am rapidly appreciating that I know very little about GHz radios; about as much as i know about any other type of radio, come to that.

I am using circularly polarised antennas, which are omnidirectional, and reject multipath interference (in theory). So there shouldn't be any issue with reception of the carrier over my intended range, but the symbols encoded on it are arriving at fairly random times when either station is moving. Hence my question about re-clocking (from a local clock, presumably, the timing information in the original signal having been largely compromised....)

Wifi streaming has been mentioned - eg using a Chromecast system; it's probably what I'll look into next. Disadvantage is that it requires the establishment of a Wifi network to stream the data over, which in some environments eg busy music festivals may be difficult. And the latency may be difficult to predict, and certainly non-zero - which when one system is the left channel and the other is the right, will certainly be a problem.

I've been told that applying signal conditioning at the receiver (eg a Schmitt trigger to square up the waveform) would be pointless as the DAC has such circuitry at its input anyway. Is that correct?
 
I've been told that applying signal conditioning at the receiver (eg a Schmitt trigger to square up the waveform) would be pointless as the DAC has such circuitry at its input anyway. Is that correct?

Dac circuits typically do recondition the SPDIF waveforms before they go into the actual dac chip. However, if the signal is jittery what happens inside the dac depends on the type of dac. Most dacs try to sync a PLL to the incoming SPDIF stream and so it may go hunting around if there is excess jitter. ESS Sabre dacs use a state machine instead of the typical PLL to figure out what the waveform should look like and effectively reconstruct it as it should be. There may be dac chip register settings that affect PLL bandwidth and could affect tolerance for jittery signals. Firmware in dacs may leave such settings at the defaults, but even if you could make some change at that level it could only help so much.

Looking at other potential possibilities, there is software and or hardware to send audio over ethernet by various means, which may include wireless networks. A streaming audio software system may have enough buffering to be able to handle timeouts due receiver motion. The issue in that case might be that receivers can get out of sync with one another if they are operating in the same open space.

It looks like if you want to get into figuring out what might be done, it really depends on your application. Are people walking around playing music on cellphones, are there moving robots playing streaming audio to entertain guests, are they COW systems (computer on wheels) which are desktops or laptops on mobile carts, etc?

Other than the foregoing, you might want to look at some of the options here to see if any might suit your needs: Audio Networking Explained | Sweetwater
 
Member
Joined 2004
Paid Member
I think you can make this work with the right TX/RX combination, but I don't know enough about the available products to steer you in the right direction. Charlie Laub did a lot of experimenting with transmitting the SPDIF signal, and I believe he found a good combination for unobstructed transmissions. You might want to email him for some advice.

Here is the problem: SPDIF audio from a device like a CD player is formatted as 2 32-bit streams (left and right) at 44.1KHz. That's an information rate of 2.822MHz. However, the signal is then Manchester encoded to embed the clock, and that results in an effective bit rate of 5.6448MHz. If the signal is getting sent as NTSC-M, channel spacing is 6MHz and there is usually a filter in the "AV sender" receiver to limit the signal to 4.5MHz. So, sure, the signal is going to look crappy at the input to the SPDIF receiver. Any SPDIF receiver is going to provide good conditioning, but as you might guess, trying to send a 5.6MHz signal through a 4.5MHz pipe is going to be a problem.

Charlie found some RX/TX modules from the radio-control world that were capable of transmitting higher quality video. I know that the channel spacing for 5.6GHz RC systems is 20MHz, so there should be a working combination that isn't limited to 4.5MHz. Also, you might be able to use multiple channels to get more bandwidth. You need to find one that allows more than 525-line NTSC. These systems are designed to be used with drones and other RC vehicles, so they should have the right antennas for sources that are moving. Sorry, I don't know specifically which ones to look at, but I'm guessing that there will be a low-cost solution that will work.

Another possibility is to use a pair of WiFi modules like the ones from Parts Express (WFA02/WFA28). These are mesh routers that provide audio synchronization. That is, they can be paired, with the main module receiving packetized audio, and the "slave" unit gets audio directly from the master without using the TCP/IP protocols. So you would send packetized WiFi audio to the master, and then the master sends low-latency digital audio to the slave. If that connection between the master and slave can work while the units are moving, it might solve your problem. The WFA28 has two antennas vs one for the WFA02, so that might be the better option. You can open up these units and connect a different antenna, as they have a standard U-FL connector. (see picture).

You might find this discussion useful: Open source Active Wifi speaker project

WFA02.jpg
 
Last edited:
Administrator
Joined 2004
Paid Member
Latency could be a problem, yeah. Unless it's less than the delay in the air. ;)

There are some long distance Bluetooth TX/RX units out there that ought to do the trick. Not sure about splitting left and right, tho. Bluetooth usually only pairs one to one, but there are some units that will do more.

Is sending high quality analog an option? That might be easier. I've done that a lot for shows and it works pretty well.
 
Thanks guys this is all marvellously helpful. @Neil that is exactly the information I have been trying to find - what the bandwidth requirements of S/PDIF actually are. It totally makes sense that the video channel isn't quite wide enough.

I am actually using an "FPV" transmitter designed to relay a composite video signal from a flying RC model to a ground based receiver. It's an Eachine TX5828 (Eachine TX5258 5.8G 72CH 25/200/500/800mW Switchable FPV Transmitter Support OSD Configuring) and I have the recommended RHCP antenna attached.

It can transmit on 9 different bands, some of which are divided into 20MHz channels and some into 40MHz. I guess it's not going to be using the *whole* channel, but even so I would have thought half the available bandwidth would be a reasonable assumption? So 10MHz at least. It's at moments like this that I wish I had access to a GHz band spectrum analyser, because I could answer these questions in about five minutes.....

My current receivers seem to be band A only. I've no idea if they have any bandwidth limitations, or will just demodulate everything they can from a given carrier - I guess the latter is what I need.

@Pano - I haven't found any one-to-many Bluetooth systems, do you have any links?

And yes I've tried the analogue audio channels - range is better and there are fewer dropouts, BUT the level of broadband noise behind the received signal is really, REALLY bad. Plus, when signal is briefly lost a very loud PHUT! transient is generated, which tends to activate the loudspeaker protection circuit on my amplifiers, requiring a power cycle to bring the sound back....far from ideal!
 
I suggest you try to use the lowest feasible sample rate for your application. When I was trying to send SPDIF over the video channel of an AV sender as a way to do whole-home distributed audio back in 2013/14, I found that 48kHz was barely doable, and 44.1kHz slightly more reliable. If you can drop to 32kHz, which some DACs will still accept, you might have better luck. The waveform shape should be better preserved. The lower you can go the better it will be, since the time that the spdif signal spends at either the high or low states will increase as sample frequency decreases.
 
Thanks Charlie. I've just looked at my ADC and DAC modules, which arrived without documentation, and although the mfr. has helpfully lasered all the numbers off the ADC chip, the MCLK crystal is 12.288MHz which suggests a sample rate of 48KHz. So I guess I will look into modifying that. Is it as simple as swapping out the crystal for an 8.192MHz unit?

The DAC can accept 32kHz signals, so there shouldn't be any issue there.

Quick run of the numbers suggests that a 32kHz, 32 bit signal will have a bandwidth of about 4.0MHz, so ought to survive transmission a LOT better.

Looking more closely at the specs of my transmitter, it claims 18MHz bandwidth for the video channel; I don't think I'm seeing that at the receiver, so it's probably safe to assume it *is* filtering down to the expected domestic video signal bandwidth. So, a better receiver might also be in order....
 
Member
Joined 2004
Paid Member
After thinking about this a bit, I' not sure you have a bandwidth problem. You said the audio was reliable until you started moving, and you are using one of the RC transmitters that has wide bandwidth. The problem Charlie and I were seeing initially was from using a baby-monitor type RX/TX pair at 2.4GHz, and I'm fairly certain those were limited to the 4.5MHz NTSC signal. But you were getting a good signal without movement, so I'm not convinced bandwidth is your problem. If that's the case, then lowering the sample rate with the 5.8GHz RX/TX pair won't help any.

I'm guessing that the problem is more due to multipath from bouncing off nearby objects while the source or receiver is moving. That effect will be more pronounced at 5.8GHz than at 2.4GHz. So if you can find a wide bandwidth RX/TX pair at 2.4 GHz, you might have more success with those moving radios.

I know that the Dayton WiFi modules use a 2.4GHz carrier and they transmit 16bit 44.1KHz audio between units when they are synchronized. They use standard WiFi waveforms, so bandwidth shouldn't be an issue. The app lets you send either Left, Right, or Left+Right to the sync'ed device, so this approach might work if you don't need stereo at the receiving unit. I have no idea how far these signals can travel or whether this approach would be significantly better than what you are already using, but it's an idea...
 
Hmmm. I'm using circularly polarised antennas specifically to avoid multipath interference - the theory is that the polarisation of reflected signals is opposite to that of the transmitted signal, so the RX antenna is much less sensitive to them. I'm not sure how well that translates into reality.

I also have tried some straight whip antennas, from 5.8GHz AP's, and it certainly works much better with the circular ones.

2.4GHz is probably worth exploring I guess - the reason I went with 5.8 is that the spectrum is less crowded by Wifi transmissions. On music festival sites there is commonly a very robust "Production" Wifi network and also usually one related to the ticket/wristband scanners. These tend to be set up with very powerful 2.4GHz AP's and I was worried they would cause me interference, or that I would interfere with them - Nothing more guaranteed to get you banned from a festival than messing up their ticket control system or the office Internet!
 
Administrator
Joined 2004
Paid Member
The Wifi seems like a good idea. :checked:

As to Bluetooth, just have a look on eBay for BT transmitters. They normally come in a set with a receiver. You might have to use 2 sets, one for left, one for right. They are plentiful and cheap on eBay and maybe other places. When I do BT from my phone, I've found that BT receivers with an external antenna are much more solid than the antenna on the PCB types.

I used to have a couple of units that sent 4 channels of digital audio (48 kHz) over infrared. Worked like a charm in the same room - not a good option for you, I would think. :)

There are also a lot of wireless headphone and assisted listening systems you could hack, if the WiFi or BT don't work out.
 
Agree that bandwidth may not be the problem. Regarding multipath theories, question is are there null locations where reception drops out, or are the symptoms in fact a function of motion and not position? Also, do receivers have multiple antennas that are actively combined to optimize reception?
 
Well, when I started out, I may have been using an FM transmitter with a bit more power than is strictly allowed...thankfully for my criminal record, it never sounded good enough for me to want to carry on using it ;)

I should add that the eventual goal here is to develop a system to allow mobile soundsystems to easily play together at festivals, without needing spaghetti wires. The movement (haha) is pretty healthy in the UK right now but link-ups are quite rare due to the logistics of it. If I can get this working, that will be a lot easier. So the TX can get complicated, but ideally the RX should be an off the shelf item.
 
The Wifi seems like a good idea. :checked:

As to Bluetooth, just have a look on eBay for BT transmitters. They normally come in a set with a receiver. You might have to use 2 sets, one for left, one for right. They are plentiful and cheap on eBay and maybe other places. When I do BT from my phone, I've found that BT receivers with an external antenna are much more solid than the antenna on the PCB types.

I used to have a couple of units that sent 4 channels of digital audio (48 kHz) over infrared. Worked like a charm in the same room - not a good option for you, I would think. :)

There are also a lot of wireless headphone and assisted listening systems you could hack, if the WiFi or BT don't work out.

If you want to use WiFi, I have a complete solution for you that runs under Linux. Streams from a "source" or "server" computer to any number of "client" computers over WiFi. I developed this after I got sick of all of the problems I had with the analog RF link type connections you are trying now. You can use very inexpensive hardware for each RX - a Raspberry Pi zero W will work great. It's an ongoing project that keeps evolving, but I have a stable version that you could try out. Requires Gstreamer on both server and clients, but this is easily available via the common Linux distros.

I also have integrated DSP into the client side. In my application stream PCM 48kHz audio to multiple clients, implement DSP on the client (for a crossover) and then output N channels to amps connected to a loudspeaker.

Functionality on TX and RX machines is easily reconfigured for different sample rates, etc. by editing via text files. A text based multi-client interface is used to control the streaming (e.g. toggling which clients are active). After the initial OS load and set up I just use SSH (a terminal emulator) to connect, and SCP to edit files, all from my main Windoze desktop.
 
@CharlieLaub that sounds great!

Could the server be another R-Pi? I really need something that accepts either analogue line level or audio over Bluetooth as an input. Incorporating a laptop into the TX setup would be a little difficult in the field. I suppose a very small micro-PC could be shoe-horned in.

If other people wanted to get themselves a R-pi Zero W for a receiver, would it be as simple as providing an SD card with the software on it, pre-configured to "just work" - or would it always require configuration via SSH?

Can the transmitting and receiving stations be synchronised? What kind of latency do you get from TX to RX?

I briefly looked into a piece of Linux software called "JACK" which purports to achieve the same thing. However, it requires BeagleBone hardware to run, which is quite expensive, and configuration looked like it would be FAR from straightforward for anyone wishing to "join the party" so to speak.

I've got a festival next weekend so I'll be using the current RF solution for that. It will be a proper test of range vs fidelity with the new transmitter, which hasn't really been used "in anger" yet.
 
With my WiFi approach, for every RX in the system you need to program the TX side to send audio to it. This is unlike the RF audio solution that you are using now, in which anyone can buy an RX module and "listen" for the broadcasted signal. To add new RXs you need to both add the RX and program the TX for it. You also need to set up a WiFi hot spot, and this also takes some knowledge and hardware. My system uses fixed IP addresses unless there is a way to lookup the IP address from the machine name (this functionality is not always available in your average home network). So adding a new RX is not a problem, but doing it in the field without a keyboard and monitor would require some careful planning and testing.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.