To: rsgb_lf_group@blacksheep.org
References: <56BDED97.5060308@freenet.de> <56BE0364.6070503@gmx.net>
 <56BE1134.7060205@freenet.de>
 <CAA8k23S4yT+pAfLGGaMH8XnPGa4WPNS4YZHJNKc4WQpydSsu9g@mail.gmail.com>
 <56BE1D9E.6060200@freenet.de>
 <CAA8k23SSF0vfOaRgwU_56yFmksVYLsZ-yfGpFvP9=-LEDCxHCA@mail.gmail.com>
 <56C4DEFF.5060709@freenet.de> <56C4F76A.8020401@gmx.net>
From: =?UTF-8?Q?Wolfgang_B=c3=bcscher?= <dl4yhf@freenet.de>
Message-ID: <56C4FCAD.2050109@freenet.de>
Date: Thu, 18 Feb 2016 00:05:17 +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: <56C4F76A.8020401@gmx.net>
Subject: Re: [rsgb_lf_group] Re: LF: PIC-based GPSDO with A/D converter /
 supported serial baudrates ?
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Status: O

Hello Tobias,

Well, I do exactly that already in the GPSDO-part of the PIC: Use the 
PLL to multiply the 10 MHz by four, to have a 40 MHz clock for some of 
the "on-chip peripherals", so there's no way to use another master clock 
crystal.
But it doesn't matter much because this PIC has a nice fractional 
baudrate prescaler, so the calculated bit rate error is really small 
(despite the high baudrate).

 > The computing power of this 8 Bit PICs is limited (even at 32MHz), so 
it cannot not do too much of computing beyond the serial communication 
task.
<

Well, mine computes a 4-th order CIC lowpass with a decimation ratio of 
four, two delay elements for each comb stage (running at f_sample=20 
kHz), and four integrators at the CIC's input section running at 
f_sample=80 kHz.
The PIC16F1783 requires 45 to 83 core cycles per sampling interrupt, and 
there are exactly 125 core cycles between two interrupts. Now going to 
sequeeze in a few more instructions to send the result out to the UART, 
which appears to be the easiest way for testing the decimator's 
anti-aliasing capabilities. Of course I know I am pushing the poor thing 
to its limits, but that's part of the fun ;-)

If you aren't afraid of an ugly mix between "C" and PIC assembler, the 
updated sourcecode is again at

http://www.qsl.net/dl4yhf/gpsdo/gpsdo_pic_main.c

73,
   Wolf .


Am 17.02.2016 um 23:42 schrieb Tobias DG3LV:
> Hi Wolf !
>
> The PIC16F1783 has an internal 4x PLL, which could be used in 
> conjunction with a typical 7.3728 MHz (external) crystal to gain 
> 29.491200 MHz Fosc for your PIC. This is just 16 times the baudrate of 
> 460800 Baud !
> The RS232 level converters aren't a good choice for those high 
> frequencies, as Andy pointed out : An RS422 / RS 485 level IC would be 
> much better and work across considerable distance without problems. 
> (Or simply use the TTL-level outputs without any level shifters = 
> bypass the existing level shifters on the PCB).
>
> The computing power of this 8 Bit PICs is limited (even at 32MHz), so 
> it cannot not do too much of computing beyond the serial communication 
> task.
>
> A simple protocol could e.g. use the highest or lowest Bit of each 
> byte to synchronize a 3-or more-Byte frame. At a high-high-low scheme 
> of these bits it's easy to get the payload decoded in correct sequence.
>
> The A/D converter may run on higher samplerates than "recommended", as 
> we are digitizing "audio" and not DC. The FFT will show how high you 
> can go before the degradation starts. The datasheets mostly are 
> conservative on their data to avoid legal action... For a 
> non-commercial project like this we can push the limits considerably 
> higher.
>
> 73 de dg3lv Tobias
>
> Am 17.02.2016 um 21:58 schrieb Wolfgang Büscher:
>> Ok then - so the FTDI-chip based interfaces are the ones to use.
>> In the meantime I got the serial port adapter working at 460800 bits per
>> second (where the communication with the PIC16F1783 looks good) but not
>> at 500000 bits/sec (where the PIC could realize the bitrate without any
>> error). The rise- and fall time of the RS232 level converters seem to be
>> different, so when sending a loop of 0x55 bytes the '0101010' pattern
>> doesn't look like a square wave with 50 % duty cycle at all.
>>
>> But anyway, for narrow band applications it's ok, and even the dsPICs I
>> have here at the moment (with 12 bits/sample from the ADC) are specified
>> for 200 kS/sec at the maximum (the PIC16F1783 was announced for 100 ksps
>> but the recent datasheet says its only 75 ksps). I will try to run it at
>> 80 ksps and decimate down to 20 ks/sec for the output, with some of gain
>> from a CIC filter for effectively 16 bits per sample. 20 kHz * 2 bytes *
>> ( 1 + 8 + 1 ) bits = 400 kBit/second (raw, including start + stop bit) -
>> that's close to what the 'Prolific' adapter can handle.
>>
>> Brings up a crazy idea: Since there is not enough bandwidth for a 3rd
>> byte (for a sample frame), the receiver could examine the amount of
>> 'noise' in the bits of each byte, to tell the high-byte from the
>> low-byte just in case an unknown number of bytes get lost on the way...
>> the least significant byte will have more toggling bits than the most
>> significant byte.
>> Well, it's good fun to push the 'midrange PIC' to its limits (haven't
>> been doing this for a long time, being more used to ARM controllers
>> these days). The PIC16F1783 has 4096 program steps, 256 bytes of RAM,
>> and (Andy will know what I'm talking about) it now has TWO 'address
>> pointers', FSR0 and FSR1 instead of only one, and an add-with-carry
>> instruction which the older PIC16's didn't have... makes efficient
>> programming in assembler a bit easier, even though the CIC filter (with
>> N=4, R=4, N=2) consume almost CPU time when running at 80 kHz sampling
>> rate. Oh well, there still is the option to use a dsPIC instead.
>>
>> All the best,
>>    Wolf .
>>
>>
>>
>> Am 17.02.2016 um 16:23 schrieb Andy Talbot andy.g4jnt@gmail.com
>> [rsgb_lf_group]:
>>>
>>>
>>> I've just made some tests on the FTDI232 chip at high baud rates.
>>>
>>> Using a custom routine written in  PowerBasic (CC) , I used that
>>> language's own interpretation and interface to the driver to pass
>>> arbitrary baud rates to the chip.   With the device set for 8 data,  1
>>> stop bit and no parity, I repeatedly send the character 0x55 in a
>>> continuous loop.  This pattern of bits, if sent contiguously
>>> (characters are sent LSB first)  should therefore result in a square
>>> wave being generated at a frequency exactly equal to half the
>>> specified baud rate.
>>>
>>> The FTDI232 data sheet states that baud rates are determined based on
>>> a 3MHz input to a divisor of (N + M/8, where N = 2 to 16384, plus two
>>> special cases on N = 0 and N = 1 for  3Meg and 1Meg rates
>>> respectively.   This setting is hidden from my application, and
>>> happens transparently based on the baud rate I specify beign passed to
>>> the driver via PowerBasic.
>>>
>>> The following results were obtained :
>>>
>>> Requested         Frequency
>>> Baud rate           Generated
>>>
>>> 1M                     500000
>>> 2M
>>>
>>>
>>>
>>> On 12 February 2016 at 17:59, Wolfgang Büscher
>>> <<mailto:dl4yhf@freenet.de>dl4yhf@freenet.de> wrote:
>>>
>>>     Thanks Andy. I wanted to keep it simple (but not necessarily
>>>     stupid), by using available hardware. In my case, the dreadful
>>>     (and, most likely, "faked") Prolific USB <-> RS232 adapter.
>>>
>>>
>>>
>>>
>>> __._,_.___
>>> ------------------------------------------------------------------------ 
>>>
>>> Posted by: Andy Talbot <andy.g4jnt@gmail.com>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>>
>>> Visit Your Group
>>> <https://uk.groups.yahoo.com/neo/groups/rsgb_lf_group/info;_ylc=X3oDMTJmN2w3cWZmBF9TAzk3NDkwNTA1BGdycElkAzg1MDgwODk1BGdycHNwSWQDMTY5MDA2MzEwOARzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0NTU3MjI2MjQ-> 
>>>
>>>
>>>
>>> Yahoo! Groups
>>> <https://uk.groups.yahoo.com/neo;_ylc=X3oDMTJldmU1ajBtBF9TAzk3NDkwNTAzBGdycElkAzg1MDgwODk1BGdycHNwSWQDMTY5MDA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQ1NTcyMjYyNA--> 
>>>
>>>
>>> • Privacy
>>> <https://info.yahoo.com/privacy/uk/yahoo/groups/details.html> •
>>> Unsubscribe
>>> <mailto:rsgb_lf_group-unsubscribe@yahoogroups.co.uk?subject=Unsubscribe> 
>>>
>>> • Terms of Use
>>> <https://info.yahoo.com/legal/uk/yahoo/utos/en-gb/details.html>
>>>
>>> __,_._,___
>>
>