Return-Path: X-Spam-DCC: paranoid 1290; Body=2 Fuz1=2 Fuz2=2 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on lipkowski.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DNS_FROM_AHBL_RHSBL, HTML_MESSAGE,RATWARE_GECKO_BUILD autolearn=no version=3.1.3 Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by paranoid.lipkowski.org (8.13.7/8.13.7) with ESMTP id u1KAVk6H025370 for ; Sat, 20 Feb 2016 11:31:46 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1aX4lA-0006Hi-Et for rs_out_1@blacksheep.org; Sat, 20 Feb 2016 10:27:32 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1aX4l9-0006HZ-Vm for rsgb_lf_group@blacksheep.org; Sat, 20 Feb 2016 10:27:31 +0000 Received: from mout3.freenet.de ([195.4.92.93]) by relay1.thorcom.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86) (envelope-from ) id 1aX4k5-0006YU-2o for rsgb_lf_group@blacksheep.org; Sat, 20 Feb 2016 10:27:30 +0000 Received: from [195.4.92.140] (helo=mjail0.freenet.de) by mout3.freenet.de with esmtpa (ID dl4yhf@freenet.de) (port 25) (Exim 4.85 #1) id 1aX4jl-0006c9-J5; Sat, 20 Feb 2016 11:26:05 +0100 Received: from localhost ([::1]:41517 helo=mjail0.freenet.de) by mjail0.freenet.de with esmtpa (ID dl4yhf@freenet.de) (Exim 4.85 #1) id 1aX4jl-0002hQ-Ej; Sat, 20 Feb 2016 11:26:05 +0100 Received: from mx11.freenet.de ([195.4.92.21]:57542) by mjail0.freenet.de with esmtpa (ID dl4yhf@freenet.de) (Exim 4.85 #1) id 1aX4gu-0002F8-38; Sat, 20 Feb 2016 11:23:08 +0100 Received: from x4d08efb7.dyn.telefonica.de ([77.8.239.183]:49251 helo=[192.168.178.20]) by mx11.freenet.de with esmtpsa (ID dl4yhf@freenet.de) (TLSv1.2:DHE-RSA-AES128-SHA:128) (port 587) (Exim 4.85 #1) id 1aX4gt-0003yP-LD; Sat, 20 Feb 2016 11:23:08 +0100 To: rsgb_lf_group@yahoogroups.co.uk References: <56BDED97.5060308@freenet.de> <56BE0364.6070503@gmx.net> <56BE1134.7060205@freenet.de> <56BE1D9E.6060200@freenet.de> <56C4DEFF.5060709@freenet.de> From: =?UTF-8?Q?Wolfgang_B=c3=bcscher?= Cc: rsgb_lf_group@blacksheep.org Message-ID: <56C83E8A.5020503@freenet.de> Date: Sat, 20 Feb 2016 11:23:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: X-Originated-At: 77.8.239.183!49251 X-Scan-Signature: b3f8fb035a284b2b872f787d60d4607d Subject: Re: : Re: [rsgb_lf_group] Re: LF: PIC-based GPSDO with A/D converter / supported serial baudrates ? Content-Type: multipart/alternative; boundary="------------020508040400030504050609" X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Scanned-By: MIMEDefang 2.56 on 10.1.3.10 Status: O X-Status: X-Keywords: X-UID: 6902 This is a multi-part message in MIME format. --------------020508040400030504050609 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello all, I can now confirm that the USB <-> UART (RS232) adapters with FTDI work *much* better than the old one with the 'Prolific' chip. At the village's local computer store, we found one labelled 'Delock Adapter USB 2.0 > 1x Serial' which even had the info 'FTDI chipset' on the cardboard. It runs happily also at non-integer multiples of 115200 bit/sec, e.g. 500 kBit, and so far not a single byte has been lost. The driver has an extra configuration screen to adjust the USB packet to up to 4096 bytes, i.e. the hardware(?) buffer is large enough for a dozen milliseconds even at large sampling rates. Gives some confidence that there is no bottleneck, and no samples get lost on the USB. The CIC decimator (which decimates the 12-bit ADC values by 8) produces a few additional bits for each output sample, which I don't want to sacrifice in the frame format. So simply sending out 16 bits per sample, least significant byte first, should do the job. The plan(!) is that the receiver (PC) can start or stop the data acquisition by sending a single-character "command", so when the digitized samples start pouring in, the receiver always knows the first received byte contains bits 7..0 of an analog sample. Plus, it prevents that the stupid windows plug-and-play system accidentally thinks the input from the A/D converter is a 'ballpoint mouse'... 73, Wolf . Am 19.02.2016 um 23:34 schrieb Andy Talbot andy.g4jnt@gmail.com [rsgb_lf_group]: > > > Oddly, that is very nearly exactly what I'm doing now with the test > PIC module > Digitising at 40kHz and sending the results as a 12 bit word. The > first byte carries the 6 lower bits with its highest two set to '00' > > The second byte carries the upper 6 bits with its two MSBs set to > '11'. Its actually only a ten bit word as that is all the A/D > converter in the PIC can manage, the mechanism is in place for a 12 > bit value. > > 40kHz sampling is enough to digitise the entire 475kHz band and leave > enough margin for filter transition bands, and even at 10 bit > sampling, is fast enough to make decimation worthwhile to expand the > dynamic range. > > I only did it as an exercise to prove the serial communication link > would work at that rate, but may be a useful module to have on the shelf. > > Andy G4JNT > > On 19 February 2016 at 21:17, ik2pii@gmail.com > [rsgb_lf_group] > > wrote: > > My more crazy idea: > > > 12 bits can be divided in two 6 bits chunk. > > If you transmit 8 bit words you have 2bit/chunk spare. Set te 8th > bit to 0 for the less significant chunk and 1 for the most > significant chunk. The receiver can now recognize and assemble the > 12 bit word. > > Of course the sender CPU must have some idle time for splitting > the 12 bit word. > > More: if you transmit two 7bit word you can increase a little the > data rate. > > 73 de Claudio ik2pii > > > > > > > __._,_.___ > ------------------------------------------------------------------------ > Posted by: Andy Talbot > ------------------------------------------------------------------------ > > > Visit Your Group > > > > Yahoo! Groups > > > • Privacy > • > Unsubscribe > > • Terms of Use > > > __,_._,___ --------------020508040400030504050609 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello all,

I can now confirm that the USB <-> UART (RS232) adapters with FTDI work *much* better than the old one with the 'Prolific' chip. At the village's local computer store, we found one labelled 'Delock Adapter USB 2.0 > 1x Serial' which even had the info 'FTDI chipset' on the cardboard.
It runs happily also at non-integer multiples of 115200 bit/sec, e.g. 500 kBit, and so far not a single byte has been lost. The driver has an extra configuration screen to adjust the USB packet to up to 4096 bytes, i.e. the hardware(?) buffer is large enough for a dozen milliseconds even at large sampling rates. Gives some confidence that there is no bottleneck, and no samples get lost on the USB.

The CIC decimator (which decimates the 12-bit ADC values by 8) produces a few additional bits for each output sample, which I don't want to sacrifice in the frame format. So simply sending out 16 bits per sample, least significant byte first, should do the job. The plan(!) is that the receiver (PC) can start or stop the data acquisition by sending a single-character "command", so when the digitized samples start pouring in, the receiver always knows the first received byte contains bits 7..0 of an analog sample. Plus, it prevents that the stupid windows plug-and-play system accidentally thinks the input from the A/D converter is a 'ballpoint mouse'...

73,
  Wolf .
 

Am 19.02.2016 um 23:34 schrieb Andy Talbot andy.g4jnt@gmail.com [rsgb_lf_group]:


Oddly, that is very nearly exactly what I'm doing now with the test PIC module 
Digitising at 40kHz and sending the results as a 12 bit word.  The first byte carries the  6 lower bits with its highest two set to '00'

The second byte carries the upper 6 bits with its two MSBs set to '11'.    Its actually only a ten bit word as that is all the A/D converter in the PIC can manage, the mechanism is in place for a 12 bit value.

40kHz sampling is enough to digitise the entire 475kHz band and leave enough margin for filter transition bands, and even at 10 bit sampling, is fast enough to make decimation worthwhile to expand the dynamic range.

I only did it as an exercise to prove the serial communication link would work at that rate, but may be a useful module to have on the shelf.

Andy  G4JNT

On 19 February 2016 at 21:17, ik2pii@gmail.com [rsgb_lf_group] <rsgb_lf_group@yahoogroups.co.uk> wrote:
 

My more crazy idea:


12 bits can be divided in two 6 bits chunk.

If you transmit 8 bit words you have 2bit/chunk spare. Set te 8th bit to 0 for the less significant chunk and 1 for the most significant chunk. The receiver can now recognize and assemble the 12 bit word.

Of course the sender CPU must have some idle time for splitting the 12 bit word.

More: if you transmit two 7bit word you can increase a little the data rate.

 

73 de Claudio ik2pii






__._,_.___
Posted by: Andy Talbot <andy.g4jnt@gmail.com>



__,_._,___

--------------020508040400030504050609--