----- Original Message ----- From: "Don Koster" To: "Georgs Kolesnikovs" ; "Great LoopList" Sent: Wednesday, May 14, 2008 9:24 AM Subject: Re: GL: Show your support for Great Loop List!

> http://www.ourfairdeal.org/ -- > View this message in context: > http://forum.openscad.org/STEP-support-Converter-tp11647.html Sent > from the OpenSCAD mailing list archive at Nabble.com.

Pascal On 06/06/2013 11:14, Ashwin Rath wrote: > Please see thread titled " > > > [pjsip] Regarding 64bit porting of PJSIP on windows" > > > > On Thu, Jun 6, 2013 at 2:32 PM, Pascal Lequeux > wrote: > > Hi, > > Is there a support from pjsip for Windows x64 (64-bit)?

Hi all, when i run pjsua.exe as two different clients and try to send dtmf to each other by following steps: - run pjsua.exe - type in(on both clients): Cp - type in(on both clients): PCMU 200 - type in(on one client): # - type in(on one client): 123 then i get the following message:pjsua_app.c Unable to send DTMF: Remote does not support RFC 2833 (PJMEDIA_RTP_EREMNORFC2833

We are in the process of updating > the rfnoc-devel branch with many changes from the master branch > including support for the TwinRX Rev C. We will be doing regression > testing of the rfnoc-devel branch with all revisions of the TwinRX next > week.

Maybe the problem comes from that the supported version of MATLAB is 003.005.001-vendor (according to the return value of getSDRuDriverVersion()). So, my question is, doesn't the current version of MATLAB support USRP X310 and is there any schedule for support if it is not supported currently?

Does anyone have a surplus Oscillator Support Board for the 5334A Option 010 counter? The part number is 05334A-60003. Nothing even close shows up on Ebay nor in a Google search. I'd like to get 2 or 3 if any are available. I guess I could homebrew it as a last resort, but I'd rather have the genuine article.

Hello list, I would like to announce support for the MIMO cable with UHD. The support is experimental, so its not in the mainline yet, and is only available for USRP2 at the moment.

On Wed, Jul 11, 2012 at 03:48:52PM -0400, paul swed wrote: > David > Read your comments and have been traveling. So finally a chance to email. > > I read the document also and walked away with what I shared. > In your reading would you believe the following. > Its an absolute phase and that when it switches to 0 there is 1 transition > at the beginning of the second to 180 degrees staying that way to the next > bit or flipping again to 0 degrees if its a 1 at the 1 sec tic??? What I mean by absolute phase is that a 1 is always 180 degrees and a zero always 0 degrees. In your example this would imply that the two ones in a row would result in two seconds of 180 degree phase without a flip after the first 1. The document is confusing, but the best I can do with its language is to conclude they are talking about absolute phase. Normally when one talks about baseband waveforms one is referring to absolute I and Q components relative to an unchanging carrier phase, not relative I and Q with respect to the last bit phase. So I take their language to mean a zero is 0 degrees and a 1 180 degrees relative to an unchanging carrier. Differential encoding is the opposite, a 1 is always the opposite phase from the last bit, a zero always the same phase as the last bit (or sometimes the inverse where a zero is the transition and a one is not). > Is there a way to sense from the document that there is a bias towards 0 > lets say. Differential encoding tends to have little "DC" component or bias toward either one or zero or one phase or the other, absolute encoding does if the data it encodes does. -- "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either."

The L109 photos look like > perhaps a DDS chip is > being used for this, and if so I have a strong > interest in hacking the > box to produce a precision 64 MHz clock for a > gnuradio USRP board... > obviously even the capability to go to 16 MHz > instead of 15 would be > very nice... > > -- > Dave Emery N1PRE, die@dieconsulting.com DIE > Consulting,