MsPacMan
in [Design]
|
Prev: Contemporary Auditing Real Issues and Cases by Knapp 8th edition (2011) Solution Manual is available for purchase at affordable prices. Contact me at allsolutionmanuals11[at]gmail.com to buy it today.
Next: statistics folly
From: krw on 18 Jul 2010 18:11 On Sun, 18 Jul 2010 15:00:09 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: >krw(a)att.bizzzzzzzzzzzz wrote: >>> ... have anyone there who has >>> the time and inclination to do a bit of a skunkworks project? >> Nope. Not at all. They're stressed just getting the scheduled >> product changes done[*]. AIUI, the runner-up was the BlackFin (the >> guys still wear their blackfin T-shirts when the TI guys show up). A >> complete G729 package wasn't available for it. > >Long-term you might think about rolling your own CoDec? G.729 does seem to be >pretty good, but it still has more latency than some people seem to prefer. >Probably the reason why a lot of wireless mics are still using plain old >analog FM? (The unfortunate downside though is that it's rather difficult to >cook up a good CoDec without stepping on someone's patented IP in the process, >and a lot of the IP owners aren't interested in talking with you if you're >only looking for, e.g., hundreds or thousands of licenses per year.) Since we're only looking at 1/20th of that, or so, rolling our own doesn't make much sense either. From what I'm told, the guy that did program it is top notch. Yeah, as we've discussed before, we're at the fringe of acceptable delay now. A lot of work was done to mitigate the problems but it's really hiding the issue. There are places to cut down some buffering but latency certainly is a problem. >I like Wikipedia's description of G.729 annex B: "If transmission is stopped, >and the link goes quiet because of no speech, the receiving side may assume >that the link has been cut. By inserting comfort noise, analog hiss is >simulated digitally during silence to assure the receiver that the link is >active and operational." "Comfort noise" -- that's great! :-) There is some comfort it's not a "comfort squawk", I suppose. ;-) >> [*] We have a new manager, who asked me if I wanted to help out with >> the firmware. "Nope, I don't know how to spell 'C'. If you want it >> done in assembler or VHDL, fine." Besides, I have Xenocryptophobia. > >I generally only volunteer to do firmware when it's a small enough project >that I can do the entire thing myself -- e.g., a smart battery chargers or >whatever. :-) Yep. I do hardware, but if there is a little code needed to get it to work, I'm fine with it as long as I own it all.
From: John Larkin on 18 Jul 2010 18:51 On Sun, 18 Jul 2010 14:26:45 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: >krw(a)att.bizzzzzzzzzzzz wrote: >> Sure. The issue is two-fold, really. First, the thing works. A >> good chunk of the possible savings is a newer DSP (savings of $6-7 >> per), but they had so much trouble with TI getting this one working >> that the owner is afraid of touching another unknown. > >I've often heard that the Analog Devices SHARC DSPs are rather "friendlier" >and work better (in terms of the actual behavior relative to what the data >sheet claims)... have anyone there who has the time and inclination to do a >bit of a skunkworks project? > >We're sticking with TI DSPs as well for the moment, though -- not enough spare >people/time to be contemplating a change right now. > >---Joel So far, we've been happy with a 68K or an ARM for the slow stuff and an FPGA for the fast signal processing. That's a different way to slice peoblems. John
From: krw on 18 Jul 2010 18:55 On Sun, 18 Jul 2010 15:51:54 -0700, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >On Sun, 18 Jul 2010 14:26:45 -0700, "Joel Koltner" ><zapwireDASHgroups(a)yahoo.com> wrote: > >>krw(a)att.bizzzzzzzzzzzz wrote: >>> Sure. The issue is two-fold, really. First, the thing works. A >>> good chunk of the possible savings is a newer DSP (savings of $6-7 >>> per), but they had so much trouble with TI getting this one working >>> that the owner is afraid of touching another unknown. >> >>I've often heard that the Analog Devices SHARC DSPs are rather "friendlier" >>and work better (in terms of the actual behavior relative to what the data >>sheet claims)... have anyone there who has the time and inclination to do a >>bit of a skunkworks project? >> >>We're sticking with TI DSPs as well for the moment, though -- not enough spare >>people/time to be contemplating a change right now. >> >>---Joel > >So far, we've been happy with a 68K or an ARM for the slow stuff and >an FPGA for the fast signal processing. That's a different way to >slice peoblems. Different problems, different solutions. Certainly there is an overlap, but it's not all that much.
From: John Larkin on 18 Jul 2010 19:24 On Sun, 18 Jul 2010 17:55:09 -0500, "krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: >On Sun, 18 Jul 2010 15:51:54 -0700, John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >>On Sun, 18 Jul 2010 14:26:45 -0700, "Joel Koltner" >><zapwireDASHgroups(a)yahoo.com> wrote: >> >>>krw(a)att.bizzzzzzzzzzzz wrote: >>>> Sure. The issue is two-fold, really. First, the thing works. A >>>> good chunk of the possible savings is a newer DSP (savings of $6-7 >>>> per), but they had so much trouble with TI getting this one working >>>> that the owner is afraid of touching another unknown. >>> >>>I've often heard that the Analog Devices SHARC DSPs are rather "friendlier" >>>and work better (in terms of the actual behavior relative to what the data >>>sheet claims)... have anyone there who has the time and inclination to do a >>>bit of a skunkworks project? >>> >>>We're sticking with TI DSPs as well for the moment, though -- not enough spare >>>people/time to be contemplating a change right now. >>> >>>---Joel >> >>So far, we've been happy with a 68K or an ARM for the slow stuff and >>an FPGA for the fast signal processing. That's a different way to >>slice peoblems. > >Different problems, different solutions. Certainly there is an overlap, but >it's not all that much. We just did a Spartan6 design that runs 16 channels of A/D conversion, each channel having an SPI interface to its A/D, two programmable 8-pole lowpass filters, a data interpolator, and a 4K FIFO. The FPGA also does our VME interface and some trigger logic that you couldn't do in a DSP. Brutal parallelism is nice sometimes. Using a separate uP and FPGA partitions the problem nicely, at the cost of interconnect pins. John
From: Joel Koltner on 18 Jul 2010 19:29
<krw(a)att.bizzzzzzzzzzzz> wrote in message news:ug17465nsqejfu252efn3rm6ehjk8ci7o2(a)4ax.com... > On Sun, 18 Jul 2010 15:51:54 -0700, John Larkin > <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>So far, we've been happy with a 68K or an ARM for the slow stuff and >>an FPGA for the fast signal processing. That's a different way to >>slice peoblems. > Different problems, different solutions. Certainly there is an overlap, but > it's not all that much. ....and I don't think any of John's stuff is battery powered, whereas Keith's and mine is. G.729 is also a pretty complex algorithm; it'd be a awful lot of work to put the bulk of it into an FPGA. ---Joel |