Ronan,
In the context of a microphone, the cable length is pretty much set; most
of them are no more than 2/3 of a meter in length, so the effects of
noise on the system would be minimal. Even if we split the radio and
used USB for both the microphone and the display to transceiver
connection, it shouldn't make the system unusable.
Matthew Pitts
N8OHU
>________________________________
> From: Ronan Paixão <ro...@dapaixao.com.br>
>To: freetel-codec2@lists.sourceforge.net
>Sent: Wednesday, December 7, 2011 7:12 PM
>Subject: Re: [Freetel-codec2] How to build microphones with device control
>buttons
>
>
>At least with I2C we have the option to use stronger pull-ups and lower speed
>for noisy cases. For USB there's no such option and cables are limited to 5
>meters for USB FS and 3 meters for USB LS.
>--------------8<--------------8<-------------
>Ronan Paixão
>
>
>
>
>2011/12/7 Bruce Perens <br...@perens.com>
>
>On 12/07/2011 03:21 PM, Ronan Paixão wrote:
>>
>>For example, the Idle current on the $4.40 Atmega32u2, an AVR microcontroller
>>which has USB support, is ~250uA@1MHz, with as little as 4.6uA on Power-down.
>>Probably add a little for the USB peripheral.
>>>
The power drain is going to be the cost of bus signalling. There's a short
discussion at http://www.beyondlogic.org/usbnutshell/usb2.shtml
>>
>>
>>
>>>For simplicity's sake and easy hardware implementation and availability, I'd
>>>go for I²C support.
>>>
Except that then we have to implement new software to drive devices on I²C that
are already really well-handled on USB.
>>
>>
>>Atmega48PA, with 7uA@128KHz/2V on Idle, including the Internal RC Oscillator.
>>>
For I²C on the 10-foot cable they use for dance-pads, there is a power cost for
driving the bus. It's not going to be really high impedance, low-power-drain,
without having noise problems.
>>
>> Thanks
>>
>> Bruce
>>
>>------------------------------------------------------------------------------
>>Cloud Services Checklist: Pricing and Packaging Optimization
>>This white paper is intended to serve as a reference, checklist and point of
>>discussion for anyone considering optimizing the pricing and packaging model
>>of a cloud services business. Read Now!
>>http://www.accelacomm.com/jaw/sfnl/114/51491232/
>>_______________________________________________
>>Freetel-codec2 mailing list
>>Freetel-codec2@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>
>>
>
>------------------------------------------------------------------------------
>Cloud Services Checklist: Pricing and Packaging Optimization
>This white paper is intended to serve as a reference, checklist and point of
>discussion for anyone considering optimizing the pricing and packaging model
>of a cloud services business. Read Now!
>http://www.accelacomm.com/jaw/sfnl/114/51491232/
>_______________________________________________
>Freetel-codec2 mailing list
>Freetel-codec2@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
>
------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2