Three new SDRs in the shack

Phil philmt59 at aol.com
Tue May 30 13:29:46 EDT 2017


Fourth factor - data compression?

Phil M1GWZ


> On 30 May 2017, at 18:19, Joe palsa via Tacos <tacos at amrad.org> wrote:
> 
> Food for thought-------
> The size of an audio file is determined by three factors: sampling rate, bit resolution and channel count.
> 
> Let's take an example audio file which was recorded at 44.1kHz, mono, and 16 bit resolution. The bit rate for this file is calculated as: 44100 x 1 x 16 = 705,600 bits per second. Divide that 705,600 by 8 and you've got 88,200 bytes per second. Divide that 88,200 by 1024 and you end up with 86 kilobytes per second. Multiple that by 60 and you get 5167 kilobytes per MINUTE. Or 5.047 MB per minute.
> 
> The audio with more activity I would expect to require more MB.
> 
>  
> 73's
> Dr Joseph Palsa k3wry
> ARRL-Virginia Section Manager
> Virginia State Government Liaison
> K3WRY at ARRL.ORG
> 804-350-2665
> 
> NOTICE: The information contained in this electronic mail transmission is intended for the use of the named individual or entity to which it is directed and may contain information that is privileged or otherwise confidential. It is not intended for transmission to, or receipt by, anyone other that the named addressee. It should not be copied or forwarded to any unauthorized persons. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply E-mail. 
> 
> No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced "You are what you do, When it counts"
> 
> "When the disaster is at its worst, communications should be at its best"
>  
>  
> In a message dated 5/30/2017 12:54:22 P.M. Eastern Daylight Time, beatnic at comcast.net writes:
> I was thinking this morn, probably the coffee.  
> So if you record to disk I would think that if you captured a portion of the spectrum with many stations that the file size would be greater than a less busy part of the spectrum.   Is that true? Then I thought if you recorded a part of the spectrum with noise at a certain level and then recorded another part of the spectrum with a higher noise level, then would the 2 files sizes be the same or different? I'm ignoring OS overhead.
> I'm sure there is a mathematical explanation for this and if need be I WILL drink more coffee...
> 
> Terry Fox wrote on 5/29/2017 8:46 PM:
>> 
>> I have recently purchased three new SDRs for testing and playing with.  Up front:  I have NO RELATIONSHIP with any of these companies, other than being a customer, who paid full-price for everything. 
>> 
>> 1/2:  BooyaSDR 
>> The first two are BooyaSDR units.  These are different than almost all other SDRs available to RF enthusiasts at the moment, in that they sample the RF input directly, then send ALL those samples to the host computer.  No FPGA or other device to reduce the amount of samples.  The host computer then does all the computations to show the FULL bandwidth of their respective input.  The software shows this spectrum display in a series of waterfalls stacked on top of each other.  I purchased one of the 100MHz full SDR & antenna, and then a 16MHz digitizer set, less antenna.  I also have a 64MHz oscillator that I can put in place of the socketed 100MHz oscillator, so I can test the boards at that lower rate. 
>> 
> ----------------------snip--------------
> -- 
> 
>     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>        No electrons were harmed in the creation of this message
>          --------------------------------------------------------
>  ~~~******************* Alex Fraser *******************~~~
>          --------------------------------------------------------
> [[[[[[~~^^^#___=>>>```/\/\**O**/\/\```<<<=___#^^^~~]]]]]]
> 
> 
> _______________________________________________
> Tacos mailing list
> Tacos at amrad.org
> https://lists.amrad.org/mailman/listinfo/tacos
>  
> 
>  
> _______________________________________________
> Tacos mailing list
> Tacos at amrad.org
> https://lists.amrad.org/mailman/listinfo/tacos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.amrad.org/pipermail/tacos/attachments/20170530/c3f081fe/attachment-0001.html>


More information about the Tacos mailing list