[Moon-Net] eme video camera

Kenny Heernaert kenny at lambdaanttech.be
Sat Nov 5 16:52:12 CET 2016


Hi Doug , 

A moon camera depends on a few factors how to make the complete setup .

First you need to know the angular diameter of the moon , which is about 30'
or 0,5° .
Due the large size of the moon you need either a camera with a large chip
and then you can go for a telescope/telelens with a rather longer focal
point or a short focal length and a smaller chip .
Most cheap camera's like webcams or specialized astronomy cameras (video
capturing devices) have a small chip based on the sony ICXXXX one , those
are quite small and are meant small field of views .
The usegae in astronomy is mostly for making video captures of planets , due
the small angular diameter of planets compared to the moon a large focal
length telescope can be used .
Those cameras come quite cheap .

Larger chips can be found in the DSLR range cameras or specialized astronomy
models , but I assumed this is no option as a moon tracking camera : -)

Using a small chip mean using a short focal length , you can either use a
telelens like from Canon/Nikon or go for cheaper models .
I'm using a 300mm focal length ( telescope) to be able to capture the moon
completely with a DMK21 camera using a ICX098 chip , that has a size of
4,5mm in diagonal .

You can either look for a fixed focus lens or build something yourself with
a solid PVC tube and a lens and making a refractor type of telescope . 
Making it yourself is not that easy as you need to make some kind of focuser
and during winter/summer the contraction/expantion of the tube causing a out
of focus image or if you are handy you can electronical control the focusing
with a servo :-) 

On the second hand market there are several DMK types of cameras available
for a bargain , as well as DSLR lenses . This makes a very fine combination
to observe the moon and even you make some deepsky shots :-)

Here are some handy links if you want to further play around with numbers : 

https://starizona.com/acb/ccd/calc_pixel.aspx
http://www.astro-tom.com/technical_data/useful_formulas.htm


Good luck !

Kenny ON4DPX

-----Oorspronkelijk bericht-----
Van: moon-net-bounces at mailman.pe1itr.com
[mailto:moon-net-bounces at mailman.pe1itr.com] Namens
moon-net-request at mailman.pe1itr.com
Verzonden: zaterdag 5 november 2016 0:05
Aan: moon-net at mailman.pe1itr.com
Onderwerp: Moon-net Digest, Vol 286, Issue 23

Send Moon-net mailing list submissions to
	moon-net at mailman.pe1itr.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.pe1itr.com/mailman/listinfo/moon-net
or, via email, send a message with subject or body 'help' to
	moon-net-request at mailman.pe1itr.com

You can reach the person managing the list at
	moon-net-owner at mailman.pe1itr.com

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Moon-net digest..."


Today's Topics:

   1. Re: IQ+ PREAMP GAIN NEEDED (Roger Rehr W3SZ)
   2. Re: IQ+ PREAMP GAIN NEEDED (Edward R Cole)
   3. eme video camera (Douglas Johnson)
   4. Re: USB Soundcard Up-Date (Joe)


----------------------------------------------------------------------

Message: 1
Date: Fri, 4 Nov 2016 16:33:20 -0400
From: Roger Rehr W3SZ <w3sz73 at gmail.com>
Subject: Re: [Moon-Net] IQ+ PREAMP GAIN NEEDED
To: Moon-Net <moon-net at mailman.pe1itr.com>
Message-ID: <77034b0f-5c8d-65c1-38d3-01345465e311 at w3sz.net>
Content-Type: text/plain; charset=windows-1252

HI Ed,

Thanks for the note and the great comments.  I have a couple of
comments-on-your-comments that I think would be of general interest, which I
interspersed below.

> Its my understanding that one can record the soundcard audio stream as 
> a .wav file which you could then run on WSJT or MAP65, and compare how 
> well they decode.  I am less concerned that the signal level reported 
> is the same, than that the decoding thresholds are equal.  (actually I 
> am not that concerned as I have excellent performance from MAP65 and 
> WSJT10, both using the KV decoder.
But there is no need to make such a recording.  With the system which Alex
and I use to compare MAP65 and WSJT, the real-time signals as they are
received and sent to both programs are identical.  There is no reason to
make a recording to use for input.

You might say that other stations that couldn't do the proper evaluation of
MAP65 and WSJT in real-time as Alex and I did might want to make such a
recording in order to evaluate their systems.  But note that you can't use
one recording to directly feed MAP65 and WSJT, as they have different input
requirements.  MAP65 requires as input a 96000 Hz sampling rate wideband
signal, while WSJT requires a narrowband (2.4-5 kHz wide) signal at 11025 Hz
sampling rate.  So if you made a single recording to feed to both, it would
need to be a 96000 Hz sampling rate wideband signal that you fed into a
Linrad master which you then used to send timf2 data to MAP65, and that same
instance of Linrad would also have to produce processed audio reduced to a
narrow band signal at 11025 Hz sampling rate to feed WSJT.  That would be
essentially an identical system to what Alex and I use for our tests, but
with a recorded wideband file instead of off the air signals used for input
to Linrad.
(Actually it would be slightly simplified, using the master Linrad to
produce the audio signal for WSJT instead of using a slave Linrad to
feed multiple WSJT instances).   So if the station had the capability of
doing the experiment with a recorded file, that station could have also done
it in real-time. 
> I am a little surprised that WSJT-X is usable for eme; my take was 
> that it was designed for HF?
I was experimentally using a WSJT-X development version (v 1.7.0-rc1 r7219).
As an example of how this looked during the EME contest, I have put a screen
grab taken by me during the first leg of the ARRL 2016 EME contest at:
http://www.nitehawk.com/w3sz/Contest0821-10-22-2016.PNG

You will see 5 instances of WSJT-X running as well as MAP65 (and a few
other, irrelevant-to-this-discussion programs).

WSJT-X worked well for me during the contest with two caveats. 

The first caveat is simply that I did not use WSJT-X for transmitting at
all, because MAP65 took care of that.  So I can't report on the transmit
function of WSJT-X.

The second caveat is that there was some interesting behavior (with me using
both averaging and Deep Search simultaneously) where, once WSJT-X had
"decoded"/produced a message, the "Average Decodes" window would sometimes
continue to show that decode  recurring as a new message with new time
stamps, sequence after sequence, even though I had in fact changed frequency
and there was no possibility of my continuing to receive that message.  This
is just another example of the fact that operator attention and intervention
are necessary when using the WSJT modes, as with any other mode of
operation.  I mention it here only because the frequency of such messages
requiring "operator attention"
was much greater than I was used to seeing with WSJT or earlier versions of
WSJT-X without this averaging.  An example of this issue is seen on this
screen grab: 

http://www.nitehawk.com/w3sz/K1JT-2.PNG

I had completed working EI4DQ at 1340 and I changed frequency immediately
after that (he was at 144.117).  I worked K3RWR, completing at 1400 on
144.135 and K1JT, completing at 1409 on 144.108.  So I was NOT receiving ON
144.117 after 1340, and there was no way any instances of WSJT-X could
receive signals from EI4DQ after 1340.  But if you look at WSJT-X-135 you
will see in the "Average Decodes" window apparent new decodes of EI4DQ at
1342, 1345, 1348, 1353, and 1403.  And if you look at WSJT-X-Elecraft, you
will see in the "Average Decodes" window new decodes of EI4DQ at 1342, 1344,
1348, 1353, 1357, 1400, 1402, and 1403. 
During some of these periods I was transmitting, and in none of these
periods was either my WSE Linrad receiver or my Elecraft receiver on EI4DQ's
frequency.  Some of these "decodes" of EI4DQ were during odd periods, and I
believe that during this time he was only transmitting during even periods.
So there is no possibility that these were real decodes.  You can see other
examples of messages from other stations appearing in the "Average Decodes"
window that also occurred across a time span during which I hopped through
multiple receive frequencies, often without transmitting, so that there is
no way that these stations would have been similarly frequency hopping
following my receiver from frequency to frequency, and no way that these
messages were "real".  I tried using "Erase" and "Clear Avg" to stop these
repeating messages, but that did not seem to stop it in every case.  I
believe that the "d#"
designation for the "Average Decodes" messages in question indicates that
they are a product of deep search, and the numeral indicates the depth of
the search required to produce the message.  And I also believe that the
"f#" designation means that the FT decoder produced the message.  But I do
not know any of that for certain.  My memory is that this phenomenon was not
limited to "deep search" messages, but my recollection on that point may be
faulty, and in this screen grab the false messages are limited to messages
with the "d#" designation.

It is quite possible that this interesting behavior is due to lack of
knowledge or user error on my part.  It could also be that it was an issue
in the version of WSJT-X devel that I used and which has since been
corrected.  WSJT-X development is now well beyond the version of WSJT-X that
I used.  It may well be that this is just another example of why some user
attention/intervention is still important with the WSJT modes as it is with
any other mode, as has been pointed out so many times to us simple users by
the experts.  But I mention this interesting behavior here so that anyone
who is experimenting with a pre-release version of WSJT-X during the next
leg of the contest knows that they might see this behavior.  There are two
bottom lines here:  User attention and intervention are necessary with any
mode of operation, and the WSJT modes are no exception.  And don't
necessarily believe it if WSJT-X tells you that another station is following
you up and down the band trying to work you as you "search and pounce" on
other stations who
are calling CQ.   :)
 
> Yes, keep comparisons for same decoding sw.
No, I disagree on this one.  The appropriate objective now is to see how the
currently available version of MAP65 compares with the best available
alternative, and that means comparing (MAP65 with the KV
decoder) with (WSJT-X with the FT decoder).   Again, the comparison of
(MAP65 with the KV decoder) and (WSJT with the KV decoder) has already been
done with data including huge numbers of decodes by both Alex and me.  There
is no reason to repeat those experiments with what is a soon-to-be-obsolete
piece of software (WSJT) in order to show the same result yet again when
that result is clear and already 4 years old.  But a comparison between
(WSJT-X using the Franke-Taylor) decoder and (MAP65 with the KV decoder) is
a useful comparison to make, because those programs are what people will be
using until MAP65 gets the new decoder.  When there is a version of MAP65
with the FT decoder available to us, then comparing MAP65-FT to WSJT-X-FT
will be appropriate, and I am sure that several of us will be doing that
comparison at that time.
>
> That will be another topic.  Be interested to read about and try using.
Thanks!  I hope that that there will be an opportunity to do that soon! 
But the WSJT-X / MAP65 developers have quite a lot on their collective plate
at this time, so I am not holding my breath.  It will come when it does and
we can all enjoy the great gifts that the developers have already given us
until then.

Thanks again for the great comments, Ed, and

Very 73,
Roger W3SZ



------------------------------

Message: 2
Date: Fri, 04 Nov 2016 13:29:31 -0800
From: Edward R Cole <kl7uw at acsalaska.net>
Subject: Re: [Moon-Net] IQ+ PREAMP GAIN NEEDED
To: w3sz73 at gmail.com, Moon-Net <moon-net at mailman.pe1itr.com>
Message-ID: <201611042129.uA4LTSPq020242 at mail41c28.carrierzone.com>
Content-Type: text/plain; charset="us-ascii"; format=flowed

Roger,

OK, hadn't considered the difference in input sampling rates used, so bad
idea.

For guys like Serge who do not want to get into all the tech issues of
figuring out Linrad or installing and running all those instances, I thought
maybe I had an approach which would work.

As far as the averaging window, I ignore it.  My contacts are based on what
shows in the main window.
MAP65 provides more info than I can take advantage of in a contest.  Often
enough stations to work without use of deep search or averaging.  Often I am
under a huge pileup keeping busy writing down decoded calls and their DF.
This exists outside contests, too.

On 6m & 23cm I'm often working skeds so MAP65 display is unnecessary.

Better decoding will be nice just like a bigger antenna would.

I would like to help Serge get his IQ+ working up to potential.  It should
be at least equal to using an IC275.
It would only be better using a dual-pol array for input. But Serge is
satisfied with what he is using.

I feel I made a wise decision to buy x-yagis in the beginning.  I was lucky
to have the funds available in 1998.  Experience so much faraday on 6m,
waiting to see a signal.  More gain will help but not cure that.  On 1296+
using CP eliminates polarity issues.  One of the factors in deciding to skip
432.

Some day when the dust settles that I have time to go back looking at
Linrad, your help would be welcomed.

73, Ed
reading the mail

At 12:33 PM 11/4/2016, Roger Rehr W3SZ wrote:
>HI Ed,
>
>Thanks for the note and the great comments.  I have a couple of 
>comments-on-your-comments that I think would be of general interest, 
>which I interspersed below.
>
> > Its my understanding that one can record the soundcard audio stream 
> > as a .wav file which you could then run on WSJT or MAP65, and 
> > compare how well they decode.  I am less concerned that the signal 
> > level reported is the same, than that the decoding thresholds are 
> > equal.  (actually I am not that concerned as I have excellent 
> > performance from MAP65 and WSJT10, both using the KV decoder.
>But there is no need to make such a recording.  With the system which 
>Alex and I use to compare MAP65 and WSJT, the real-time signals as they 
>are received and sent to both programs are identical.  There is no 
>reason to make a recording to use for input.
>
>You might say that other stations that couldn't do the proper 
>evaluation of MAP65 and WSJT in real-time as Alex and I did might want 
>to make such a recording in order to evaluate their systems.  But note 
>that you can't use one recording to directly feed MAP65 and WSJT, as 
>they have different input requirements.  MAP65 requires as input a 
>96000 Hz sampling rate wideband signal, while WSJT requires a 
>narrowband (2.4-5 kHz wide) signal at 11025 Hz sampling rate.  So if 
>you made a single recording to feed to both, it would need to be a 
>96000 Hz sampling rate wideband signal that you fed into a Linrad 
>master which you then used to send timf2 data to MAP65, and that same 
>instance of Linrad would also have to produce processed audio reduced 
>to a narrow band signal at 11025 Hz sampling rate to feed WSJT.  That 
>would be essentially an identical system to what Alex and I use for our 
>tests, but with a recorded wideband file instead of off the air signals
used for input to Linrad.
>(Actually it would be slightly simplified, using the master Linrad to 
>produce the audio signal for WSJT instead of using a slave Linrad to
>feed multiple WSJT instances).   So if the station had the capability of
>doing the experiment with a recorded file, that station could have also 
>done it in real-time.
> > I am a little surprised that WSJT-X is usable for eme; my take was 
> > that it was designed for HF?
>I was experimentally using a WSJT-X development version (v 1.7.0-rc1 
>r7219).  As an example of how this looked during the EME contest, I 
>have put a screen grab taken by me during the first leg of the ARRL 
>2016 EME contest at:
>http://www.nitehawk.com/w3sz/Contest0821-10-22-2016.PNG
>
>You will see 5 instances of WSJT-X running as well as MAP65 (and a few 
>other, irrelevant-to-this-discussion programs).
>
>WSJT-X worked well for me during the contest with two caveats.
>
>The first caveat is simply that I did not use WSJT-X for transmitting 
>at all, because MAP65 took care of that.  So I can't report on the 
>transmit function of WSJT-X.
>
>The second caveat is that there was some interesting behavior (with me 
>using both averaging and Deep Search simultaneously) where, once WSJT-X 
>had "decoded"/produced a message, the "Average Decodes" window would 
>sometimes continue to show that decode  recurring as a new message with 
>new time stamps, sequence after sequence, even though I had in fact 
>changed frequency and there was no possibility of my continuing to 
>receive that message.  This is just another example of the fact that 
>operator attention and intervention are necessary when using the WSJT 
>modes, as with any other mode of operation.  I mention it here only 
>because the frequency of such messages requiring "operator attention"
>was much greater than I was used to seeing with WSJT or earlier 
>versions of WSJT-X without this averaging.  An example of this issue is 
>seen on this screen grab:
>
>http://www.nitehawk.com/w3sz/K1JT-2.PNG
>
>I had completed working EI4DQ at 1340 and I changed frequency 
>immediately after that (he was at 144.117).  I worked K3RWR, completing 
>at 1400 on 144.135 and K1JT, completing at 1409 on 144.108.  So I was 
>NOT receiving ON 144.117 after 1340, and there was no way any instances 
>of WSJT-X could receive signals from EI4DQ after 1340.  But if you look 
>at WSJT-X-135 you will see in the "Average Decodes" window apparent new 
>decodes of EI4DQ at 1342, 1345, 1348, 1353, and 1403.  And if you look 
>at WSJT-X-Elecraft, you will see in the "Average Decodes" window new 
>decodes of EI4DQ at 1342, 1344, 1348, 1353, 1357, 1400, 1402, and 1403.
>During some of these periods I was transmitting, and in none of these 
>periods was either my WSE Linrad receiver or my Elecraft receiver on 
>EI4DQ's frequency.  Some of these "decodes" of EI4DQ were during odd 
>periods, and I believe that during this time he was only transmitting 
>during even periods.  So there is no possibility that these were real 
>decodes.  You can see other examples of messages from other stations 
>appearing in the "Average Decodes" window that also occurred across a 
>time span during which I hopped through multiple receive frequencies, 
>often without transmitting, so that there is no way that these stations 
>would have been similarly frequency hopping following my receiver from 
>frequency to frequency, and no way that these messages were "real".  I 
>tried using "Erase" and "Clear Avg" to stop these repeating messages, 
>but that did not seem to stop it in every case.  I believe that the "d#"
>designation for the "Average Decodes" messages in question indicates 
>that they are a product of deep search, and the numeral indicates the 
>depth of the search required to produce the message.  And I also 
>believe that the "f#" designation means that the FT decoder produced 
>the message.  But I do not know any of that for certain.  My memory is 
>that this phenomenon was not limited to "deep search" messages, but my 
>recollection on that point may be faulty, and in this screen grab the 
>false messages are limited to messages with the "d#" designation.
>
>It is quite possible that this interesting behavior is due to lack of 
>knowledge or user error on my part.  It could also be that it was an 
>issue in the version of WSJT-X devel that I used and which has since 
>been corrected.  WSJT-X development is now well beyond the version of 
>WSJT-X that I used.  It may well be that this is just another example 
>of why some user attention/intervention is still important with the 
>WSJT modes as it is with any other mode, as has been pointed out so 
>many times to us simple users by the experts.  But I mention this 
>interesting behavior here so that anyone who is experimenting with a 
>pre-release version of WSJT-X during the next leg of the contest knows 
>that they might see this behavior.  There are two bottom lines here:  
>User attention and intervention are necessary with any mode of 
>operation, and the WSJT modes are no exception.  And don't necessarily 
>believe it if WSJT-X tells you that another station is following you up 
>and down the band trying to work you as you "search and pounce" on other
stations who
>are calling CQ.   :)
>
> > Yes, keep comparisons for same decoding sw.
>No, I disagree on this one.  The appropriate objective now is to see 
>how the currently available version of MAP65 compares with the best 
>available alternative, and that means comparing (MAP65 with the KV
>decoder) with (WSJT-X with the FT decoder).   Again, the comparison of
>(MAP65 with the KV decoder) and (WSJT with the KV decoder) has already 
>been done with data including huge numbers of decodes by both Alex and 
>me.  There is no reason to repeat those experiments with what is a 
>soon-to-be-obsolete piece of software (WSJT) in order to show the same 
>result yet again when that result is clear and already 4 years old.  
>But a comparison between (WSJT-X using the Franke-Taylor) decoder and 
>(MAP65 with the KV decoder) is a useful comparison to make, because 
>those programs are what people will be using until MAP65 gets the new 
>decoder.  When there is a version of MAP65 with the FT decoder 
>available to us, then comparing MAP65-FT to WSJT-X-FT will be 
>appropriate, and I am sure that several of us will be doing that comparison
at that time.
> >
> > That will be another topic.  Be interested to read about and try using.
>Thanks!  I hope that that there will be an opportunity to do that soon!
>But the WSJT-X / MAP65 developers have quite a lot on their collective 
>plate at this time, so I am not holding my breath.  It will come when 
>it does and we can all enjoy the great gifts that the developers have 
>already given us until then.
>
>Thanks again for the great comments, Ed, and
>
>Very 73,
>Roger W3SZ
>
>_______________________________________________
>Moon-Net posting and subscription instructions are at 
>http://www.nlsa.com/nets/moon-net-help.html
>
>
>
>-----
>No virus found in this message.
>Checked by AVG - www.avg.com
>Version: 2015.0.6201 / Virus Database: 4664/13347 - Release Date: 
>11/04/16

73, Ed - KL7UW
http://www.kl7uw.com
     "Kits made by KL7UW"
Dubus Mag Business e-mail:
     dubususa at gmail.com 



------------------------------

Message: 3
Date: Fri, 4 Nov 2016 22:40:05 +0000 (UTC)
From: Douglas Johnson <w9iix1 at yahoo.com>
Subject: [Moon-Net] eme video camera
To: "moon-net at mailman.pe1itr.com" <moon-net at mailman.pe1itr.com>
Message-ID: <2142583724.501825.1478299205321 at mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"

I would appreciate any comments on the type of video camera for eme. ?I
beleive it requires some telephoto lens. I have 2 9el on 2 and 2 21 el on
432 and should be on soon...Doug,W9iix
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.pe1itr.com/pipermail/moon-net/attachments/20161104/c2409166/a
ttachment-0001.html 

------------------------------

Message: 4
Date: Fri, 4 Nov 2016 18:04:19 -0500
From: Joe <nss at mwt.net>
Subject: Re: [Moon-Net] USB Soundcard Up-Date
To: Lloyd Korb <lloydk8dio at gmail.com>
Cc: "moon-net at mailman.pe1itr.com" <moon-net at mailman.pe1itr.com>
Message-ID: <f3c51487-9716-e31f-cccd-576df2de21d8 at mwt.net>
Content-Type: text/plain; charset="utf-8"

Hi Lloyd,
What computer do you use it with?
I got it this morning and no where does it say anything about Win 10

I plugged it in, and i get the usual beep boop that windows does when
something is plugged into a USB port. BUT........ it doesn't appear
anywhere.

Tried installing the drivers off the little CD, and it gets close to
installing but then always has an error before finishing.

So thinking maybe not win 10 compatible?

Joe WB9SBD
Sig
The Original Rolling Ball Clock
Idle Tyme
Idle-Tyme.com
http://www.idle-tyme.com
On 10/28/2016 5:14 AM, Lloyd Korb wrote:
> I have been using the SYBA SD-AUD20101 for several weeks. Comparing it 
> with my ASUS U5 the decoded numbers are the same on MAP65.  When I 
> have high elevation the local noise is low enough to decode stations 
> at -28/-29 with both sound devices. The only issue I have found was 
> that the small volume up and down buttons do not function.  You have 
> to go into the Windows settings to set the levels.
>
> Lloyd  K8DIO
>
> On Thu, Oct 27, 2016 at 11:40 PM, Joe <nss at mwt.net 
> <mailto:nss at mwt.net>> wrote:
>
>     How does one "Test" it's noise level anyway?
>
>     I ordered one. will see what it is like when it gets here.  This
>     is it. the price sure is right!
>
>
http://www.newegg.com/Product/Product.aspx?Item=N82E16812186171&nm_mc=KNC-Go
ogleAdwords-PC&cm_mmc=KNC-GoogleAdwords-PC-_-pla-_-USB+Converters-_-N82E1681
2186171&gclid=CKPqjcvW-88CFQipaQodf-gE_Q&gclsrc=aw.ds
>     
> <http://www.newegg.com/Product/Product.aspx?Item=N82E16812186171&nm_mc
> =KNC-GoogleAdwords-PC&cm_mmc=KNC-GoogleAdwords-PC-_-pla-_-USB+Converte
> rs-_-N82E16812186171&gclid=CKPqjcvW-88CFQipaQodf-gE_Q&gclsrc=aw.ds>
>
>     Joe WB9SBD
>
>     The Original Rolling Ball Clock
>     Idle Tyme
>     Idle-Tyme.com
>     http://www.idle-tyme.com
>     On 10/27/2016 3:41 PM, serge wrote:
>>     Joe I hope you are right. The ALL say low noise
>>     Serge VE1KG
>>
>>         ----- Original Message -----
>>         *From:* Joe <mailto:nss at mwt.net>
>>         *To:* moon-net at mailman.pe1itr.com
>>         <mailto:moon-net at mailman.pe1itr.com>
>>         *Sent:* Thursday, October 27, 2016 7:10 PM
>>         *Subject:* [Moon-Net] USB Soundcard Up-Date
>>
>>         After digesting everyone's suggestions on what to get.
>>         I started looking around and wow many were big buck items. (
>>         Well at least to me Big Buck)
>>
>>         But I found one that seems promising, the specs say low
>>         noise, and,
>>         Supporting stereo 24-bit resolution and up to 192 kHz sample
>>         rate, the USB Audio dongle features 2 stereo DACs which can
>>         achieve high performance 95 db Signal-to-Noise Ratio (SNR)
>>         and 2 stereo ADCs which can achieve high performance 90 db SNR.
>>
>>         Sound good? any comments?
>>
>>         Joe WB9SBD
>>         --
>>
>>         The Original Rolling Ball Clock
>>         Idle Tyme
>>         Idle-Tyme.com
>>         http://www.idle-tyme.com
>>
>>
------------------------------------------------------------------------
>>         _______________________________________________
>>         Moon-Net posting and subscription instructions are at
>>         http://www.nlsa.com/nets/moon-net-help.html
>>         <http://www.nlsa.com/nets/moon-net-help.html>
>>
>
>
>     _______________________________________________
>     Moon-Net posting and subscription instructions are at
>     http://www.nlsa.com/nets/moon-net-help.html
>     <http://www.nlsa.com/nets/moon-net-help.html>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.pe1itr.com/pipermail/moon-net/attachments/20161104/edd19f2c/a
ttachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CLEAN-IDLE-TYME-LOGO-120x96.jpg
Type: image/jpeg
Size: 9572 bytes
Desc: not available
Url :
http://mailman.pe1itr.com/pipermail/moon-net/attachments/20161104/edd19f2c/a
ttachment.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 9572 bytes
Desc: not available
Url :
http://mailman.pe1itr.com/pipermail/moon-net/attachments/20161104/edd19f2c/a
ttachment.jpe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 9572 bytes
Desc: not available
Url :
http://mailman.pe1itr.com/pipermail/moon-net/attachments/20161104/edd19f2c/a
ttachment-0001.jpe 

------------------------------

_______________________________________________
Moon-Net posting and subscription instructions are at
http://www.nlsa.com/nets/moon-net-help.html

End of Moon-net Digest, Vol 286, Issue 23
*****************************************



More information about the Moon-net mailing list