[Community] GTA04A5 ready to be pre-ordered
neilb at suse.de
Thu Nov 7 22:48:33 CET 2013
On Thu, 7 Nov 2013 18:14:48 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:
> Am 07.11.2013 um 00:02 schrieb NeilBrown:
> > On Wed, 23 Jan 2013 12:20:01 +0100 "Dr. H. Nikolaus Schaller"
> > <hns at goldelico.com> wrote:
> > Seeing you are considering trying again for the GTA04a5, I thought I might
> > re-visit these issues:
> >> Am 22.01.2013 um 12:29 schrieb NeilBrown:
> >>> On Tue, 22 Jan 2013 10:02:38 +0100 "Dr. H. Nikolaus Schaller"
> >>> <hns at goldelico.com> wrote:
> >>>> Preliminary (there may still come minor changes coming from PCB
> >>>> Layout tuning and from first production feedback) schematics can be found here:
> >>>> <http://projects.goldelico.com/p/gta04-main/downloads/48/>
> >>> Thanks!
> >>> One thing that has always bothered me a little bit is that the FM transceiver
> >>> is wired for digital IO rather than analog. That means that the CPU needs to
> >>> be active to copy sound around in order to listen to the radio. If the
> >>> LOUT/ROUT pins were connected to the line-in pins on the audio chip you
> >>> should be able to listen to the radio with the CPU off.
> >> Yes, that should be possible.
> >>> It would mean that you couldn't get the same fidelity if you wanted a digital
> >>> copy of the broadcast, but I wonder if that really matters.
> >>> What is the expected use-case of the FM radio? If it is just for listening
> >>> to, the current config doesn't seem to be optimal.
> >> Well, the TX direction is more interesting since it can play sound (incl. navigation
> >> information) to a car radio. By using text2speech. And mix with sound.
> >> Connecting to the Audio in is a problem since we have already connected them
> >> to the headset jack. So that it is possible to record sound fed into the headset
> >> jack. I.e. portable audio recorder...
> > Is the "portable audio recorder" use case more valuable than the "FM radio
> > without excessive power usage" use case? I would be happy to sacrifice the
> > stereo-aux-in if it meant I could listen to the radio for longer.
> > For the price of another analogue switch like the one you use to isolate the
> > headset outputs (U703) you could support both FM and AUX inputs. Maybe that
> > price is too high??
> I will check. It is probably less a cost issue (such chips are around 50ct) but space
> and (shielded) wiring. But since headset jack and the Si4721 are not far away
> from each other it could work.
> >> And the FM-analog out are multiplexed with the digital interface on the Si4721.
> >> So we would need some analog/digital switching circuits where we don't have
> >> space for :(
> > I wouldn't suggest enabling both the analogue and digital interfaces. Just
> > the analogue. Digital might be nice but isn't really necessary.
> Well, it gives a better S/N since the signals are already A/D converted in the Si4721
> and just need to be arecord >file if you want to capture signals.
I'm willing to accept that the A/D converter in the Si4721 will suffer less
noise than the A/D in the twl4030 as the analogue signal travels a shorter
distance. But I would be surprised if it were noticeable.
With the FM sound coming through the TWL4030 you would only need an extra
"alsactl restore -f 'fmradio'" before "arecord > file" would work.
> >>> Related: have you thought about connecting the bluetooth PCM interface
> >>> directly to the TPS chip in the same way that the Modem's PCM interface is
> >>> connected?
> >>> That should allow the use of a bluetooth headset on a phone call without any
> >>> CPU intervention.
> >> Yes, that could work to add these 2 wires (at least in the schematics - I don't
> >> know if we can squeeze them into the PCB wire hairball). And I have checked
> >> that these two pins at the TPS65950 come up in GPIO (input) mode, i.e.
> >> don't interfere.
> >> One issue could be that there is no BSP clock for that interface on the TPS side.
> >> I.e. it is shared with some other interface and I am not sure how to operate it correctly.
> >> So we might have to wire up something else to really make it work.
> > The clock for the bluetooth interface and the voice interface are shared.
> > So the clock from the GSM module drives the whole chain from bluetooth
> > through TWL4030 to GSM.
> Well, we likely can't use the BT PCM to play music from memory? I put it on the checklist as well.
Both the OMAP's McBSP port and the TWL4030's BT port can be tri-stated, so we
can do the same trick as with the GSM chip and wire all three ports together.
That would let us play music via McBSP -> BT and have phone calls TWL4030 ->
Playing music puts a very different load on the CPU as latency is not an
issue. In theory the CPU could decompress a full second of music and then
arrange for DMA to move that out the McBSP port into the bluetooth while the
CPU goes to sleep for 800msec.
With a voice call you don't want any sample to stay within the CPU for more
than about 30msec, so there is much less opportunity for the CPU to sleep.
Thanks for considering these alterations.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 828 bytes
Desc: not available
More information about the community