CED3505HP COM interface

Discussions and questions about any CED hardware issues not covered above
James Colebatch
Posts: 20
Joined: 02 Jul 2008, 00:27

CED3505HP COM interface

Unread postby James Colebatch » 11 Apr 2022, 07:19

I was planning to write some software to control the 3505HP via the USB/COM interface.
It is very suitable for AC-VEMPs but needs a dedicated interface like the 1902 one.

The USB-emulated COM port all installed OK and I was able to control it via a C# program.
When I tried to use a Lazarus Pascal serial COM program it became clear that the 3505 hardware was not setting the CTS line,
which I think meant that LP serial software would not send or read anything to the interface
(there are other possible causes with CRLFs that I have not totally eliminated I confess).
I checked with the C# program and it too returned the CTS line as not being set but it was happy to
run and ignore it.
Unfortunately the Laz Pascal software seems to have a bug and will not allow the handshake to be ignored.
Is this an oversight as it does make controlling the COM port more difficult?
There is a reference to an XON/XOFF control option but I could find no further details in the handbook
nor is it clear what the default protocol is.

PS A minor point - the 3505 returns that it has 4 steps of 20dB and 4 steps of 5 dB but it can only attenuate 95dB.
It seems that there are really only 3 steps of 5 dB, the 4th being the 20 dB attenuator.

Peter Rice
Major contributor
Posts: 183
Joined: 19 Jun 2008, 15:49
Software used: Spike2 and Signal
1401 type: Many 1401 types
Location: Cambridge, UK

Re: CED3505HP COM interface

Unread postby Peter Rice » 11 Apr 2022, 12:04

I've had a quick look at the CED3505 firmware and the 3505 hardware design. Referring to the FT232 signals, the incoming CTS (from the serial line) is not connected, but the RTS (outgoing) is held asserted. RTS/CTS are often cross-connected in a protocol-controlled serial line system, so what your PC software sees as CTS should be the transmitted RTS signal. Because it's a virtual com port, it's difficult to verify the settings by probing with a meter or a scope. I did check the operation when the 3505 major change version 2 was introduced, so if you find it's incorrect in your revision, please let me know.

I looked to see if there were known problems with Lazarus, and the only reference I could find was the following:

Code: Select all

##LazSerial v0.1 ##Serial Port Component for Lazarus (windows and linux). ####by Jurassic Pork 03/2013 and
Patch for LazSerial to work with OS-X by rphoover

see: http://forum.lazarus.freepascal.org/index.php?topic=32632.0

As a part of the patch, a new property was added to the TBlockSerial class in synaser.pas, added as NonBlock. The NonBlock property is for Unix users (Linux and OS-X included).
When NonBlock is True, the call to the FpOpen method in TBlockSerial.Connect will not block when an of CTS, DSR, or Carrier are not active.

The 3505 default protocol is none. You can set it to use XON/XOFF protocol by enabling options bit 2. Send the one-time command "OP21", as described on p16 of the manual (V4). You only need to send an options bit when you need to make a change, as the current values are stored in the 3505 EPROM memory.

Regarding 3505 LS and MS attenuations, it may be that the word "step" is the problem. A 3505 unit built with 5dB LS steps has 4 different LS attenuations: 0, 5, 10 and 15dB. The MS attenuations are similarly at 20dB intervals, starting at 0dB. The "AT" command takes a user-required attenuation and computes (and then uses) the appropriate LS and MS figures. The actual dB value in use at each setting can be read back using the "?AT" command. The intention was to have a scheme that would give nearest attenuation values in a script or program on a 3505 built with a given set of attenuation step sizes, but usable in a different lab on a 3505 that might have a different set of step sizes. We usually recommend that researchers record the returned dB figures so that results from different labs are more easily comparable.

James Colebatch
Posts: 20
Joined: 02 Jul 2008, 00:27

Re: CED3505HP COM interface

Unread postby James Colebatch » 11 Apr 2022, 22:55


Surely the 3505 is not configured as DTE but rather as DCE?
As oyu said, being a virtual port makes it all much more difficult.

I will check my firmware version (if I can) later today and let you know.

The troublesome Lazarus Pascal call is this:

(uses serial)


the last parameter (here []) is defined as TSerialFlags and insists upon a set of values so that no single option can be set.
I think there has been an oversight with TSerialFlag not being defined as one of the values (eg RTSCTSFlowControl as one option).
If I can't solve the problem I will just have to use C#, but the LP serial module is very good otherwise.

Return to “General”

Who is online

Users browsing this forum: No registered users and 1 guest