Since things have slowed down quite a bit with Empeg related tasks, I've turned to developing some related audio bits. One such device is an SPDIF wireless transmitter. It has TOSLINK on both receiver and transmitter and is about 1 inch square including chip antenna. It's only a prototype so far but at least it works. I need to work on improving the range (about 5-10 meters through floors and walls) and make it auto select sample rates, but otherwise it seems to be great.

The nice thing about it is that it does not depend on any particular application like the Airport Express and also is lossless with error correction.

Stu

Dude.

Where's my wireless S/PDIF?

That sounds interesting, please keep us informed of progress!

How is it powered?

Also, when you feel the product is mature enough, the folks here may be interested.

Thanks. Currently it's powered by a wall-wart type supply. See attached picture.

Stu

That is so a better idea than Bluetooth A2DP SBC for wireless headphones. (Or is it too power-hungry for battery applications?)

Peter

The power level is adjustable in firmware and is purported to be better in terms of power usage than Bluetooth with better audio peroformance to boot. I have it set to maximum power for my application though. It uses about 17 mA at this setting for transmitting and 23 mA for receiving. At the lowest setting, this drops to 15 mA for TX with a 20 dB drop in signal.

It would be cool to see something like this in headphones for sure.

Stu

Also the difference in processing an A2DP stream vs. versus the variety of audio streams that SPDIF can encapsulate.

Well, I wouldn't expect it to do forms of SPDIF other than stereo PCM, and stereo PCM is surely easier to deal with than SBC. (Of course even SBC is trivial when compared to the radio modulation, but the chip used presumably internalises all that complexity.) I'm sure 95% of users would be happy with just 44.1KHz/16bit stereo PCM, and adding 48/16 would clean up most of the other 5% (i.e. the DAB/DVB listeners). People who want 96/24 can be accommodated at an alternative price point

Peter

I'm not sure if there is any handshaking on an SPDIF connection — I suspect there's not — or, if there is, how it might work. What would happen if a different stream was sent? If the headphones assumed PCM, it would be noise. If it doesn't assume, then we're back to processing it at least enough to recognize whether it's PCM or not.

All of that may be cheap, but I don't know.

It's not handshaking as such -- the receiver doesn't get to tell the sender what it's capable of -- but the stream is self-describing. Unless either the sender or the receiver is Doing It Wrong, non-PCM streams can't be misinterpreted as PCM.

Peter

If anyone is interested in reading more about this, the chip I'm using is the Nordic nRF24Z1 . It supports up to 24-bit (with compression) or 16-bit uncompressed 48 kHz and S/PDIF or I2S and also wireless SPI and I2C for control.

Currently I am dealing with a frustrating problem of the device not working with anything but 44.1 kHz sampling rates no matter how it's programmed. It may be that it only does 44.1 kHz over S/PDIF and I have to resort to using I2S via S/PDIF receiver and transmitter ICs to get the other supported rates.

Stu

Any chance of an option to power the transmitter via USB?

I can see this as being a good way to play music stored on a laptop for example.

Funny you should ask . The first design was mainly a proof of concept; it works! Yes, the next design which I started yesterday actually will feature USB and TOSlink connectivity on the transmitter end as well as some enhancements to the layout to both ends.

Now I have to decide whether it's worth it to buy a $2000 license for a USB vendor ID!

Stu

Heh, you could always borrow the empeg one. Pretty sure that isn't going to get re-used, so you could use invent a new PID and use the empeg VID

After all, each empeg owner obviously paid a little less than $0.50 toward the VID fund!

Hugo

Cool.. Perhaps I'll do that for my Frankenswitch controllers, too!

I want dibs on DIDs 32->48 !

Something that has particularly annoyed me, we have our own VID but spending $2k on a number is just a tad outrageous, now if somebody at the USB organisation went and looked at the the mechanism that the IEEE use for MAC addresses then it would be a far more pleasant purchasing experience.

You still have to pay the IEEE for an OUI or IAB. It is just cheaper if you're not going to be making many devices as an IAB is 1/3 the price of an OUI.

Yes, I'm aware of that, but you can purchase MAC addresses in much smaller blocks for a much smaller fee, what a brilliant idea.

How many companies who purchase a VID actually use all 65535 PID's available to them? How many just use a handful, say up to 32?

Sub licensing blocks of PID's would be a good thing for everybody.

It isn't quite the same however. If you have an IAB then you're limited to 4096 devices in total. If you have a VID with a tiny PID block you can reuse that as many times as you want.

Sub licensing PIDs would make sense though but there would have to be some incentive not to just buy lots of little blocks if you're a big manufacturer.

FTDI apparently offers that concept to users of their chips: unique DIDs under FTDI's VID.

Sensible.

They do indeed, we have in the past used FTDI chips in products where we've used microcontrollers that do not have USB built in.

Microchip also provide PIDs (for free) for products if you are using a PIC with USB, you just fax over a form and in return you get some PIDs allocated to you.

Just a shame that the people at the top (the USB-IF) want to charge $2k for a huge block that for most people is way over the top. (And it's also delightfully described as an "admin fee")

So is it permissible to sell a product that spits out a default PID from the manufacturer of a USB IC or is it mandated that all commercial USB based products have a unique PID? From what I've read it depends on the marketing of the prpduct and its use of the USB logo.

Stu

No, some of the "big boys" have agreements with the USB-IF that allows them to sub-license their VID to customers, in every single instance I've seen this done it's been for free and there is no charge. However, it always involves requesting your PID's (or block) from the manufacturer, it's a painless process and much less painless than handing over $2K.

You can pay your straight $2K and forego the signing of the agreement that allows you to use the "USB Logo" after your product has passed compliance testing, we went down this avenue, couldn't give a monkey if we can use the fancy USB logo on the product or not, the license agreement runs for 1 or 2 years (can't remember which) after which time you need to pay the "admin" fee again to be able to continue using the USB logo - although your VID is yours forever.

Everybody can apparently sub licence PIDs, I've seen the request page to do so on the USB-IF site, but it's on a specific product by product basis and you have to give quite a lot of detail out about it and I think that you have to be the "developer" of the product for a third party.

If you can get away with using a PIC (shudder, I just got cold sweats) then provided it has a USB interface, you can get a PID for free. I'm sure there are many more microcontroller manufacturers with similar agreements in place, just none of the ones we just so happen to use.

Adrian

Does anybody actually look for the USB logo when buying stuff?

The average user out there will look for the rectangular plug and whether it says USB on the box. They won't care whether it has the official USB logo on it. It isn't like the bad old days of first gen USB hardware with a million and one bugs.

Exactly, who cares about a tiny pretty logo? This is one of the reasons we decided not to trigger the logo license agreement. We just use the letters USB on documentation and stuff, the whole thing is a big con.

(Lets not also forget that the USB protocol was designed by sadists)

I look rather specifically for the "Hi-Speed" logo.

Cheers

Is that the fast one? I get confused

I got completely fished in by that when I got my first digital camera: something about how the spec was worded made me think it was USB2, so I went out and got a USB2 card for my laptop, but of course the camera was only USB1.

Mind you, I've never been totally pleased with USB support on cameras: the one I just got is USB2 at least, but it isn't mass-storage. (I thought, how could I have missed that on the spec sheets at dpreview.com?, but it turns out they don't even list whether cameras are mass-storage or not.) And while I'm not sure whether my first camera was designed before or after mini-USB was invented, the new one definitely doesn't have that excuse for its proprietary connector.

Peter

I've never had a problem with USB support. I leave the USB cable in the box and buy a card reader, like any(I thought) sane person.

Say what's wrong with a PIC? They seem more than capable of powering some of our (fairly) capable projects...

Stu

My first digital camera had a serial port to get pictures off it. There weren't any USB ports on my computer to plug a card reader into, not that you could buy a cheap CF->USB adaptor in those days.

I actually used to use IrDA to get stuff off it instead. You just put the camera in PC mode and left it on the desk pointing at the screen which had a little IrDA port stuck underneath.

My first camera had SmartMedia cards and it was before USB card readers, so I had a 3.5 inch floppy based card reader. Insert SmartMedia card into reader, insert reader into floppy disk drive. I think I've still got it in a box somewhere.

I've never got on with them, sure people have done some impressive stuff with them, but we've consigned (barring a couple of design we did recently) 8 bit micros to history. Incidentally, the USB on the pics is good, LOADS of endpoints on them which is something that our favoured ARM processor is lacking.

I've also never found a C compiler that works properly, I normally end up finding incorrect code generation almost immediately, I don't have time to hand hold the compiler with every line of code I write and given the problems with incorrect code generation I'd be very worried about what could lurk inside shipping firmware.

The last compiler I used was microchips own C compiler and I managed to get that to generate incorrect code with a convoluted type cast after only a few hours of coding, not a good start.

I've never personally seen a single compiler problem with gcc for arm and the development environment I use (crossworks) is fantastic, I seriously have no idea how people use MPLAB because after 2 minutes of using it I was ready to tear my hair out...seriously...it's 2009 and they have workspace and project windows as MDI children rather than as separate panes.

I'll concede that most of my gripes come not from the PIC micro itself but from the supporting tools. Rowley do have a version of crossworks for pic and I'm assuming it's probably of the same quality as crossworks for ARM, so if I ever need to use a PIC in anger again they'll probably be getting an order from us, but thankfully I should never have to touch the source to the firmware on the PIC stuff ever again.

Well that explains it ! We program in assembly and are admitedly moving on to ADI Blackfins (in C and C# I believe)for another project so the 8-bit micros are certainly not always the best but they have their place.

Stu

Speaking of 8-bit micros and other ancient stuff, my dropped-out classmate from university write/sells excellent "everything" development kits for quite reasonable prices. Mention my name for fun.

Cheers

I've now updated the design with USB audio and whip antennas for a little better range. I realized that the radios in these are really only Bluetooth class 3 devices, so range is limited to 30 feet or so. Still, it's cool to be able to plug these into USB and stream anything playing on your PC to a high quality stereo with no loss of quality and one cable for power and signal. The 44.1 kHz sampling rate restriction remains, but I'm working on that.

Anyone interested once the last of the bugs get worked out?

Stuart

It looks like I've worked out the bugs in the code. The device can now stream 44.1 kHz, 48 kHz via USB or TOSlink and Dolby Digital and DTS via TOSlink over roughly 30 feet to a TOSlink output.

Is there anything else anybody would like to see before commit to a design?

Stu

DVI/HDMI?


(ducks and runs for cover)

I thought I'd update everyone on the status of this project. I decided to add quite a few features to make it more useful. Perhaps the most significant is that the power has been increased from 0 dBm to 25 dBm (320 milliwatts) for much better immunity to ambient WiFi signals. I also threw in analog in/out and some other tweaks!

It's currently being built up in Colorado. I'm hoping there are no major faults with the design and that the relatively simple firmware develops quickly.

I'll post updates as they develop.

Stu

Sounds like it is progressing well Stu, is the receiver still powered by a wall-wart or have you got it running on battery power now? If so (battery), will there be an option for both e.g. battery power for headphone usage and a wall-wart for longer term hi-fi connections? This is assuming the receiver has enough output to drive headphones. Apologies if this has been covered already, I have just caught up with this thread after a few weeks absence and it is a bit late here to go back and read through it again. Thanks.

This device wasn't really conceived as a portable solution- more of an unobstrusive semi-permanent one. It certainly can run off of batteries via the power jack but with such a high power radio, I wouldn't expect you would get over 10 hours from 8 AAs. As for driving headphones, it's not designed for that but it has a pretty high quality DAC with a high voltage output so you may have success with many headphones.

It this answers your questions!

Stu

Did you have fun reading the USB audio spec stu? What a document that one is! I've just had the misfortune of reading it as I've just added a "PC interface" to our doppler radar (aka speed detector) interface and decided the nicest way of doing it was to pass the "doppler audio" straight into the "PC".

All I can say is that I'm glad that they include sample descriptors in the usb audio document otherwise I think I'd still be trying to decipher what exactly is needed in them!

Thanks Stu, one more question:
Now that the radio power output has been increased, how much more range can you get over the 30' that was previously mentioned?

We glossed over some of the general USB specs but since the actual code is executed in silicon I guess the specifics of the audio protocol were of little concern. You make it sound like a great read though. I might just check it out!

By the way, the USB org has decided that mini AB connectors such as we have used in our prototypes are illegal now (they decided this after development started). So now if we ever want to certify our device we must go to a micro AB connector. Yay!

Stu

We'd have to test it first but I would guess a solid 100% pop free performance could go to roughly 75-100' with a still very usable link reaching out to 300-500'. This all depends a great deal on the application as well as ambient RF environment.

Stu

That sucks. I hate the micro connectors. They're really hard to align when you're plugging them in.

I hate them too. I thought the minis were a good compromise between size and user friendliness, but the USB folks thought it was too confusing to have all the different connector types out there. Plus it seems the micro design is more durable.

Edit: It seems this only applies to portable devices using the "USB On the Go" logo which this isn't because it cannot be a host as the standard dictates and has actually been enforced since May 2007, so I just missed it during board layout. Still it looks like they outlaw the use of Mini-AB connectors in favor of the less flexible Mini-B.

Stu

That's good since I prefer rock, blues and swing, to pop.

Seriously, that is a pretty good range, enough for any room or house even!

Hi All. I'm just posting an update for those interested. We've gotten the high power version back from Colorado and populated the remaining 'easy' parts. We haven't yet tested the max range with the device but have observed 75 feet of rock solid performance through multiple walls and roofs.

We've also gotten the analog output to work on the receiver side. We are quite impressed with the sound produced by this DAC even with a 300 mW transmitter less than an inch away. The only issue was an annoyingly vague labeling of the DAC outputs as 'Output A' and 'Output B' which wasn't as we thought it would be. Thankfully we were able to swap them in software.

We haven't been able to test the ADC on the transmitter side due to a vendor issue with the mini-optical jack but hope to rectify that soon.

Left is the software routine and any remaining hardware tweaks that may be needed.

Stu

That wouldn't be Sparkfun would it?

No although we did have them process a pool order to Gold Phoenix once with this project. AFAIK they don't offer assembly services. We would have used them again save for the fact that the requirements for the PA layout didn't fit the design constraints.

We had the fine pitch QFNs, 0402s and some miscellaneous other parts machine placed and baked by Advanced Assembly in Aurora, CO. They do top notch work with quick turnaround time.

A few months back we had our pick and place machine commissioned, seriously impressive to see it banging down chips at the speed it does, it's a revelation having complete control of the manufacturing process from start to finish now.

Can you make your own boards in-house too? Some of those laser-based systems look pretty impressive for low volume prototype work.

Stu

You mean the LPKF machines? Some of those are pretty nice....and with hefty price tags to match!

We have a CNC machine which was built for us which is extremely accurate, if we have a need to prototype a circuit, generally we'd use isolation routing and do a test layout that way. (http://empegbbs.com/ubbthreads.php/topics/308403/4)

We did use to do a lot of prototyping through pcb pool, but we have found a chinese PCB manufacturer who gives us many more boards for not much more than we were paying for a single prototype from pcb pool, so we tend to prototype through them now and get production boards for other products bundled in.

The youtube video below is the next board that we're about to get the pick and place machine to do, trust me, soldering all those surface mount leds is not fun!

http://www.youtube.com/watch?v=E7huEauTA2o

Yep. Those are the very same. Last I saw some of their more tasty machines were north of US$30K.

Stu

That looks like one of those speed-sensing warning signs you find in built up areas and accident blackspots around the UK?

If so, can you answer this: Are they typically set just below the speed limit? I.e. 29MPH in a 30MPH zone? My reason for asking is that I am very careful to keep to the speed limits in residential areas, typically 30 and 40MPH zones, and even then a lot of them flash up the speed limit (not the actual measured vehicle's speed) seemingly to chastise me for speeding! With one in particular that I go past every day, I know that if I go past it at 25MPH it won't illuminate.

To be honest, I have no idea how they (i.e the councils) select their trigger speed, it's more than likely that they do set them lower by a percentage because the indicated speed on your speedo will be higher than your actual speed. It's also possible that they set them lower to provide some buffer with regards to the cosine error (which is always in the motorists favour) so that a slightly incorrect installation will still be spmewhat accurate.

All I can tell you is that while we were developing this and its companion doppler radar board, we got some long stares from motorists as they drove past us!

Neat, but how many speedometers are calibrated in hex.

Do you suppose I could convince a cop that I was going 100 MPH because I thought the speed limit was 0x65?

If a cop wants to give you a ticket he's going to give you a ticket. It doesn't matter how fast your car was going or even if it's a speeding ticket while your car was parked.

Now, the courts on the other hand... I'd love to read about someone explaining they're so overworked at programming that they instinctively think in hex. Though I'm sure someone would ask why the motorist then assumed the speeds marked in their dash were in decimal and needed to be converted.

You might have a better chance explaining that you thought "I95" was a new speed sign because everything now has an "i" attached to it.

Stu, just found this thread and am overjoyed. This is exactly what I am looking for to avoid standard crappy RF headphones.

Quick question: is the DAC stage just for analog support? In other words, if I just want to go S/PDIF and use my DacMagic, is it transparent end to end?

Good luck, and keep us posted!

The DAC provides analog support for the receiver, but there is also optical S/PDIF available from the same jack. Same goes for the transmitter as well but with an ADC which by the way has been tested now and verfied to provide CD-quality performance. But, if you plug in a digital interface on both ends (TX and RX), you should get a bit-for-bit copy on the receiver end.

We've made a few changes to the hardware to make it simpler to build and to use as well as designed an enclosure for it (learning CAD is so fun!)

Hope that answers your question.

Stu

Fantastic work, but one question.. Does the DAC you've created support A2DP to SPIDF?

I already have a Sony USB to SPIDF (which, from your status, actually works. :oP ), but want to eliminate the cables purely to send all stereo audio from the MacBook to the stereo. With the USB Adapter, OS X automatically handles the switch when the cable is plugged in... Would this work in the same manner with BT?

I've been searching around, and no one seems to have achieved this (perhaps for a good reason) but would be a great feature to have... And sure is one that I'm looking at the moment...