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

Reply via email to