Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: : Re: [rsgb_lf_group] Re: LF: PIC-based GPSDO with A/D converter / s

To: [email protected]
Subject: Re: : Re: [rsgb_lf_group] Re: LF: PIC-based GPSDO with A/D converter / supported serial baudrates ?
From: Wolfgang Büscher <[email protected]>
Date: Sat, 20 Feb 2016 11:23:06 +0100
Cc: [email protected]
In-reply-to: <CAA8k23TfU3b2xrsi-fGE=t5QgTUgikHOkO8GpCj1RQYXCD2V0A@mail.gmail.com>
References: <[email protected]> <[email protected]> <[email protected]> <CAA8k23S4yT+pAfLGGaMH8XnPGa4WPNS4YZHJNKc4WQpydSsu9g@mail.gmail.com> <[email protected]> <CAA8k23SSF0vfOaRgwU_56yFmksVYLsZ-yfGpFvP9=-LEDCxHCA@mail.gmail.com> <[email protected]> <[email protected]> <CAA8k23TfU3b2xrsi-fGE=t5QgTUgikHOkO8GpCj1RQYXCD2V0A@mail.gmail.com>
Reply-to: [email protected]
Sender: [email protected]
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
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 [email protected] [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, [email protected] [rsgb_lf_group] <[email protected]> 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 <[email protected]>



__,_._,___

<Prev in Thread] Current Thread [Next in Thread>