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.0 required=5.0 tests=BAYES_00,DNS_FROM_AHBL_RHSBL, HTML_MESSAGE,HTML_TINY_FONT 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 u1HLYkj7016518 for ; Wed, 17 Feb 2016 22:34:46 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1aW9gt-0005gk-T0 for rs_out_1@blacksheep.org; Wed, 17 Feb 2016 21:31:19 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1aW9gt-0005ga-CU for rsgb_lf_group@blacksheep.org; Wed, 17 Feb 2016 21:31:19 +0000 Received: from mail-wm0-f42.google.com ([74.125.82.42]) by relay1.thorcom.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aW9ft-0004U6-Or for rsgb_lf_group@blacksheep.org; Wed, 17 Feb 2016 21:31:18 +0000 Received: by mail-wm0-f42.google.com with SMTP id g62so181637726wme.1 for ; Wed, 17 Feb 2016 13:30:02 -0800 (PST) X-DKIM-Result: Domain=gmail.com Result=Good and Known Domain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dr37AER32Ze0QH0Lk0OyQ1YSY9IRTfAxY+NSVPvI56U=; b=RXT0Hc4SHPDPVUVwfJB25w4OBh2YVGDQONhydfjegVVk9jzvHiOYipyy+zXWGnWzDH ytYqqhL9Cpz8yaZu87IcuTV62AnoMSGQfd4MyoBhj04m6yXIZ/XEeEjkKPHDb09L4k8r YorjhZjUM3J9Dp7qL/Q1Ej4caWLO9HNU9tQoWmJw+Gc4LLv6Mdv98meoCsH1gMg0mG0Z 87NEEf9N59gm3W/fnG58Xu7LsucYARP7p4qlaI8G1AT/i5565oM+ODNU433qBLgL6GIR WyNLVOXaLHE64QDf5NTkgLxRMREM7NTs2C+tTSQ+zPqnlXirfUo2aDxYdzTAC5nzm13/ S2jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dr37AER32Ze0QH0Lk0OyQ1YSY9IRTfAxY+NSVPvI56U=; b=PnhRKTEwy/mxYufIIKDMknHxyVdNsTeZONJFhtgYyWJx7mnjy2S8WPfCpjdjUCOSxI Hg48FyEZXNi8E2YorF0jF2GAHuMIUIa0zoFQb4/M4faNBQVuNhmmvq45HNPFmYyCReoa W+DJRMfDH7pARWsyvpZHDaFq9J8+5PSe48b+NPvbU0PVCB9ww16D9pceHl9iXfgEgOrd WweVFyjqmMZcATSu3TUpDJ92MfYhknbfJhmSzLr1UD8oMN8RuXDXj2aWY/kTkFIiS/Ok lgD31sUZvKjnggskgVCvy33j123/cEyOueKkKQQhWMjWefoToUWmejAuWpoKZdUf0/A6 EQlw== X-Gm-Message-State: AG10YOQoBngIXkOVoJZviEM7eLjr8gjWDW72dXQizxTB1XkTzNQ3cLCvx849hoVrKL4f5EKAhX/wSXf44E92Sw== MIME-Version: 1.0 X-Received: by 10.28.12.80 with SMTP id 77mr5894260wmm.19.1455744556728; Wed, 17 Feb 2016 13:29:16 -0800 (PST) Received: by 10.28.187.213 with HTTP; Wed, 17 Feb 2016 13:29:16 -0800 (PST) In-Reply-To: <56C4DEFF.5060709@freenet.de> References: <56BDED97.5060308@freenet.de> <56BE0364.6070503@gmx.net> <56BE1134.7060205@freenet.de> <56BE1D9E.6060200@freenet.de> <56C4DEFF.5060709@freenet.de> Date: Wed, 17 Feb 2016 21:29:16 +0000 Message-ID: From: Andy Talbot To: rsgb_lf_group@yahoogroups.co.uk Cc: rsgb_lf_group@blacksheep.org X-Scan-Signature: 917bb99d4b5d86797eb255ea29aa077f Subject: Re: [rsgb_lf_group] Re: LF: PIC-based GPSDO with A/D converter / supported serial baudrates ? Content-Type: multipart/alternative; boundary=001a11443e4a3009d5052bfdf181 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: 6875 --001a11443e4a3009d5052bfdf181 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Real "RS232" (precisely) isn't specified for speeds faster than 115200, so if you are using drivers specified for them (with plus / minus voltages) that might explain the poor wave shape. RS422 / RS485 is a differential mode and good for speeds of 10MB/s (or faster in some cases) FTDIChip do ready made RS422 modules, and the FT232 chip has all the interface pins to directly connect to RS422 transceiver chips Andy On 17 February 2016 at 20:58, Wolfgang B=C3=BCscher dl4yhf@freenet.de [rsgb_lf_group] wrote: > > > 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 a= t > 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 fro= m > a CIC filter for effectively 16 bits per sample. 20 kHz * 2 bytes * ( 1 += 8 > + 1 ) bits =3D 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 byt= e > (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 ca= se > 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 bee= n > 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 old= er > PIC16's didn't have... makes efficient programming in assembler a bit > easier, even though the CIC filter (with N=3D4, R=3D4, N=3D2) consume alm= ost 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 arbitra= ry > 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. Th= is > 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 =3D 2 to 16384, plus two spe= cial > cases on N =3D 0 and N =3D 1 for 3Meg and 1Meg rates respectively. Thi= s > 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=C3=BCscher < > 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: =3D?UTF-8?Q?Wolfgang_B=3Dc3=3Dbcscher?=3D > ------------------------------ > Reply via web post > > =E2=80=A2 Reply to sender > > =E2=80=A2 Reply to group > > =E2=80=A2 Start a new topic > > =E2=80=A2 Messages in this topic > > (4) > Visit Your Group > > > > [image: Yahoo! Groups] > > =E2=80=A2 Privacy =E2=80=A2 > Unsubscribe > =E2= =80=A2 Terms > of Use > > . > > __,_._,___ > --001a11443e4a3009d5052bfdf181 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Real "RS232" (precisely) isn't specified for= speeds faster than 115200, so if you are using drivers specified for them = (with plus / minus voltages) that might explain the poor wave shape.
RS422 / RS485 is a differential mode and good for speeds of 10= MB/s (or faster in some cases)

FTDIChip do ready m= ade RS422 modules, and the FT232 chip has all the interface pins to directl= y connect to RS422 transceiver chips

Andy


On 17 February 2016 at 20:58, Wolfgang B=C3=BCscher dl4yhf@freenet.de [rsgb_lf_group] <= rsgb_l= f_group@yahoogroups.co.uk> wrote:
=20
=C2=A0
=20 =20

=20 =20 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 =3D 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 limit= s (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 ha= s 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=3D4, R=3D4, N=3D2) 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,
=C2=A0 Wolf .

=C2=A0 =C2=A0

Am 17.02.2016 um 16:23 schrieb Andy Talbot andy= .g4jnt@gmail.com [rsgb_lf_group]:
=20 =20
I've just made some tests on the FTDI232 chip=C2=A0at high= baud rates.

Using a custom routine=C2=A0written in=C2=A0=C2=A0PowerBasic (= CC) , I used that language's own interpretation and interface to the drive= r to pass arbitrary baud rates to the chip.=C2=A0=C2=A0 With the de= vice set for 8 data, =C2=A01 stop bit and no parity,=C2=A0I=C2=A0repea= tedly send the character 0x55 in a continuous loop.=C2=A0 This pattern of bits, if sent contiguously (characters are sent LSB first) =C2=A0should therefore result in a square wave being generated=C2= =A0at a=C2=A0frequency exactly equal to=C2=A0half the specified baud ra= te.

The FTDI232 data sheet states that baud rates are determined based on a 3MHz input to a divisor of (N + M/8, where=C2=A0N =3D 2 to 16384, plus two special cases on N =3D 0 an= d N =3D 1 for=C2=A0 3Meg and 1Meg rates respectively.=C2=A0=C2=A0 This se= tting is hidden from my application, and happens transparently based on the baud rate I specify beign passed to the driver via PowerBasic.=C2=A0

The following results were obtained :

Requested=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Freq= uency
Baud rate=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Generated

1M=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 500000
2M



On 12 February 2016 at 17:59, Wolfgang B=C3=BCscher <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.
=C2=A0=C2=A0=C2=A0

=20

=20

=20 =20
__._,_.___
=20 =20 =20 =20
Posted by: =3D?UTF-8?Q?Wolfgang_B=3Dc3=3Dbcscher?=3D <dl4yhf@freenet.de> =
Reply via w= eb post =E2=80=A2 Reply to sender =E2=80=A2 Reply to group =E2=80=A2 Start= a new topic =E2=80=A2 Messages in this topic (4)
=20 =20
Visit Your Group
3D"Yahoo!
=E2=80=A2 Privacy =E2=80=A2 Unsubscribe =E2=80=A2 Terms of Use

=20 =20 =20 =20
=20
.
=
= =20
__,_._,___
=20

--001a11443e4a3009d5052bfdf181--