GPIB specifications

[artag]

Arrgh! No! This is probably exactly the thinking that resulted in so many non-compliant adapters out there.
"several expensive, unwieldy cables"
Actually, HP-IB cables are more or less free, because there are so many floating around. And it's how it's supposed to work. Please use the right driver chips.
Cost difference is not much, and with them you can still use an adapter per instrument if that's preferable.

I'm sure it is (the thinking). And I do sympathise, that it's good to have it 'done properly'. You even lose some features (like the ability to transfer data directly between targets .. but how useful is that ?).

I still think it's a sensible tradeoff. Nowadays, I'd rather buy an instrument with ethernet than GPIB - but I'd rather have GPIB than manual only, and this seems reasonable : connect module to each one rather than use the bus.

I agree, GPIB cables can be free. I've got a bundle. That doesn't make them small enough to fit in a cramped shelf, or cheap enough when I suddenly want a few more. The most expensive item on a single-instrument adapter is probably the 24 pin microribbon connector ..

[c4757p]

What's the argument against using the proper, intended driver chips?

[free_electron]

What's the argument against using the proper, intended driver chips?

hardware wise :

- Not being able to drive a long cable.
- Not being able to drive more than a few instruments.
- Requiring more than one adapter
- not being as robust in terms of protection ( those drivers can take a beating ... i've never known one to fry.. )

protocol wise :
not being able to execute group triggers due to the fact you can only drive a few instruments.
GPIB has a couple of mechanism whereby you can send commands to several machines to 'arm' them. they go in a mode where they wait for the 'group trigger command' to be sent.

let's say you got 4 multimeters two sample voltage, two current , because you want to do efficiency measurements on a dc/d c convertor so you need samples at the right time. , or you fire off the programmable load and want to trigger the scope at the same time.

you tell the machines to get ready by telling them to wait for GPIB trigger and you arm them. they all go into listening mode. once the group trigger command comes ( this is a specific toggling of some control lines, it is not a gpib command in the sense that no data is transferred) all machines fire off in sync.

so in that case if your adapter can only drive a few machines and you need multiple adapters the sync is lost.

other things are stuff like swapping CIC (controller in charge ) between your computer and another controller capable machine. ( some machines have a built-in instrument basic and can send commands to subsystems. the 75000 relay matrixes, almost all spectrum and network analysers can do that , so they can take control of their frontends.  At that point you need the drivers on the PC end to go tristate in the proper way or you risk damaging something...

i, know some of these things are pretty advanced and most hobbyists probably don;t have 4 gpib capable meters. but still. the cost of those two chips is minimal. Do it right.

[free_electron]

Hello

I's been a while, but i had time to work on the schematic and pcb lay-out

This is the initial schematic version, and a print screen of the current lay-out. I plan to try and have all component on one side of the board - so i can reflow it on a hot plate.
For now i can't fit the protection diodes - either i remove them from the design, or i keep them on the bottom layer and mount them by hand.

The lay-out is still a mess, the usb-connected part is mostly ready - i need to remove / clear all in-pad vias - there are quite a lot of them now

allright , care for some nit-picking ?

schematic :
------------
1) usb :

 -  d+/d- common mode choke + transils please. transils between d+/d- and system ground.
 - NEVER connect usb gnd and tab together. there needs to be a ferrite bead between them. TAB is chassis ground. it should NEVER be connected to your system ground. you are defeating the esd   protections. the TAB of usb can be connected to the shield of the gpib connector ( not the ground pins ! the metal shield on the connector )
 - diss the resonator and go for a real crystal
 - use GP1 of the mcp2200 to control a PMOS transistor that feeds power to the optocouplers and the dc/dc converter. as long as you are not enumerated you should not be drawing more than 0.5 milliamp... so in your schematic : the wire coming from pin 1 and going up , to the right the split off toe the led's and optos needs a pmos insrerted under control of GPI.
- dc/dc converters pull quite big pulse currents. you will need some bulk capacitance. like 100 uf right at its input.

idea's:
- for debug purposes you may want to bring one more GPIO across the isolation barrier attached to the cpu's reset pin.
- diss the optocouples (which are slow) and go for a digital isolator chip. analog devices and maxim have those. they handle much higher baudrates than opto's can. they typically have an on board isolated dc/dc converter as well.

CPU
- diss the resonator , go for a crystal.
- swclk swio and nrst need appropriate pull up / down so they are not floating when not in use.
-Vana needs bypass capacitor.
- reset circuit ?

gpib section :
  bulk caps for the drivers
 - is the stm32 5 volt tolerant ? you may need to insert series resistors for signals entering the stm32...


PCB :
-----------------------------------
usb section
- Vusb needs beefier traces ... everything is routed same width. not good ...
- micro usb ? puhlease .. no .. those are total crap. mini usb i can live with , but not micro. they are so flimsy they constantly break. this is lab equipment. it should take a beating. if at all : go for the full size connector. those are rugged.
- your routing in the usb section can be done single sided so backside is a nice ground pour. make a chassis ground ring on the perimeter of the board
- shunt system ground and chassis ground with ferrite right at usb connector.

cpu section:
---------------
- beef up your power grid. use a local 3.3 island in the cpu section and place the 3v3 regulator right there.
- use smd version of regulator. something like a dpak version. . give it a tab and shoot some via's to ground.
- you are not following electron flow. hit bulk cap first, then bypass cap then regulator in. from tregulatro out hit bypass first, then bulk cap and into local power island.
- the drivers need beefier power line and local bulk caps as they can send quite a bit of current ( transient) if the bus is heavily loaded.





 

[artag]

What's the argument against using the proper, intended driver chips?

hardware wise :

- Not being able to drive a long cable.
- Not being able to drive more than a few instruments.
- Requiring more than one adapter
- not being as robust in terms of protection ( those drivers can take a beating ... i've never known one to fry.. )

protocol wise :
not being able to execute group triggers due to the fact you can only drive a few instruments.
GPIB has a couple of mechanism whereby you can send commands to several machines to 'arm' them. they go in a mode where they wait for the 'group trigger command' to be sent.

All completely true. *but* I think only the protocol one is an issue (and then not for many people)

You can have a long ethernet cable (or USB, if you must).
You only need to drive one instrument : that's an issue if it's a $500 Agilent or NI adapter, not if it's a $10 micro.
More than one adapter : same argument
Robustness : if you never take it off the instrument it never sees nasty signals.

So I still think it's a valid approach, even though the proper way has its uses.

[free_electron]

What's the argument against using the proper, intended driver chips?

hardware wise :

- Not being able to drive a long cable.
- Not being able to drive more than a few instruments.
- Requiring more than one adapter
- not being as robust in terms of protection ( those drivers can take a beating ... i've never known one to fry.. )

protocol wise :
not being able to execute group triggers due to the fact you can only drive a few instruments.
GPIB has a couple of mechanism whereby you can send commands to several machines to 'arm' them. they go in a mode where they wait for the 'group trigger command' to be sent.

All completely true. *but* I think only the protocol one is an issue (and then not for many people)

You can have a long ethernet cable (or USB, if you must).
You only need to drive one instrument : that's an issue if it's a $500 Agilent or NI adapter, not if it's a $10 micro.
More than one adapter : same argument
Robustness : if you never take it off the instrument it never sees nasty signals.

So I still think it's a valid approach, even though the proper way has its uses.

it is exqctly this kind of thinking that gets us all that chinese crap. it works in most cases  it;s not really according to specificaton but the average user won't notice.

this is a pest in today's time and age. "it's good enough" lands us the crap we have today.

[SeanB]

There is "good enough" and " barely able to work". There is a world of difference between them though. Having one that works as GPIB for 95% of the applications you use all the time with 2 or more devices in a chain is "good enough", but those that only support a single device and then only partially is in the second group.

[ealex]

@free_electron

i'm back ( 2 weeks in the mountains - no computer in sight, just a trusty old "stupid" phone ).
i'll start working on the changes you proposed - but i already have some parts and i'll try using them - the DC/DC converter for example

"d+/d- common mode choke + transils please. transils between d+/d- and system ground" - got it

leaving the USB tab floating is acceptable ? I've seen this done in several ways in commercial products: floating / hard ground / via a ferite bead

digital isolator: Si8642 seems ok and will make a lot of extra board space

stm32f100 has internal pull ups on those lines - there is no need for external ones. also, his IO's are 5V tolerant if the internal pull-ups are disabled

for the PMOS switch i'll use the USBCFG Pin " The USBCFG pin (if enabled) starts out ‘low’ during power-up or after Reset, and goes ‘high’ after the device successfully configures to the USB. The pin will go ‘low’ when in Suspend mode and ‘high’ when the USB resumes" it seems it does what i need

for the LDO - i intend to use some parts that i have around - lt1117 has 5mA of stand by current - discovered it the hard way when trying to to something ultra low power. In this applications it should not matter -> lt117-3.3 in smd package

for debug - i might stick some leds / use another uart port - just the TX line. Most of the time i can manage with just JTAG

should i keep the protection diodes on the gpib lines ? i might be able to free up some board space to add thicker traces if i get rid of them, but they add extra safety

i'll use a crystal for the usb side.
still not sure if a crystal on the microcontroller side is required - gpib does not seem timing - critical

For the USB connector - i was looking at the mating cycles - i prefer USB-B connectors but i don't know if there will be enough board space available - i try to constrain everything in 100x50mm to get 2 boards in one order

i'll upload a new schematic with the changes i've done

[ealex]

Hello
i've updated the schematic / board with the proposed changes, sorry for the delay.
the protection diodes are gone
i've added some extra caps for the io chips
added usb protection diodes
added a debug serial port on the isolated side
added 2 extra leds
changed the LDO to a 1117 type
replaced the opto-isolators with an isolation IC
added a p-mos switch to start the 5V isolated supply only after the USB chip is registered
managed to get all parts on  the top layer, so i can make it on a hotplate

i'll take another look over the entire design and then order the pcb.

( why are .rar archives not allowed ? )

[ealex]

finally got the boards

i'll start assembling it once i have all parts - need to order some new parts according to the changed components.

It seems that i did not mess any pad / pin layout this time.
This is a picture from pcb-pool :

[malch]

Are you still trying for 488.1 specs or have you gone to 488.2 specs.

[ealex]

488.1 for now - i don't have equipment to test the implementation.
i don't remember if the 488.2 are electrically compatible - if they are, there is enough processing power in the micro to cover it.

for now i only have a device that behaves like a "basic listener" on 488.1
I'll assemble 2 boards - and once i get them running i'll try to find some around here that got the time and the equipment to help me on this.

[dom0]

Are you still trying for 488.1 specs or have you gone to 488.2 specs.

That doesn't make any sense. 488.1 is a physical interface and interface protocols and 488.2 is an application protocol.

[JohnnyBerg]

Looks nice 

No solder mask?

Perhaps this is asked before, what is the status of the "firmware" in the STM32F100 ?

[malch]

Are you still trying for 488.1 specs or have you gone to 488.2 specs.

That doesn't make any sense. 488.1 is a physical interface and interface protocols and 488.2 is an application protocol.

On the National Instruments drivers page for GPIB-PCII/IIA , they call for different drivers for 488.1 and 488.2
http://www.ni.com/product-documentation/5326/en/

[MarkL]

Are you still trying for 488.1 specs or have you gone to 488.2 specs.

That doesn't make any sense. 488.1 is a physical interface and interface protocols and 488.2 is an application protocol.

On the National Instruments drivers page for GPIB-PCII/IIA , they call for different drivers for 488.1 and 488.2
http://www.ni.com/product-documentation/5326/en/

.1 is mostly about the hardware, and .2 is mostly about the higher layer.  But you need both for a good implementation.  I have no idea why NI has different drivers.

From IEEE 488.1-2003:

This standard defines an interface with the objective to assure that messages may be accurately communicated between two or more devices in a system, but it does not guarantee that each device will interpret properly all possible messages sent to it or will properly generate all necessary messages. A wide latitude of interface capability is permitted within the scope of this standard, which may permit operational incompatibility among interconnected devices.

From IEEE 488.2-1992:

This standard specifies a set of codes and formats to be used by devices connected via the IEEE 488.1 bus. This standard also defines communication protocols necessary to effect application independent device dependent message exchanges and further defines common commands and characteristics useful in instrument system applications.
...
As well as defining a variety of device-dependent messages, this standard extends and further interprets certain interface functions contained in IEEE Std 488.1-1987 while remaining compatible with that standard.

[malch]

Here is a section from a programming pdf.

"class instruments.hp.HP3456a(filelike)
The HP3456a is a 6 1/2 digit bench multimeter.
It supports DCV, ACV, ACV + DCV, 2 wire Ohms, 4 wire Ohms, DCV/DCV Ratio, ACV/DCV Ratio, Offset
compensated 2 wire Ohms and Offset compensated 4 wire Ohms measurements.
Measurements can be further extended using a system math mode that allows for pass/fail, statistics, dB/dBm,
null, scale and percentage readings.
HP3456a is a HPIB / pre-448.2 instrument.
class MathMode"
I have read Tektonix instructions stating that they couldn't read a 448.2 card "448.1 only" 

P.S. bummer now I'll have to find the Tektronix pdf.
Got it! http://digital.ni.com/public.nsf/allkb/862567530005F09C8625609E004FBE7F
"The NI-488.2 language interfaces are not compatible with the NI-488.1 drivers"

[ealex]

no solder mask - it was cheaper by a significant amount( 40%). the board got a layer of nickel - gold plating so it will not oxidize, i can cover it with some clear acrylic lacquer once it's working and there is no need to probe traces anymore.

no firmware yet - i'll have all the parts today and i plan to assemble the board this week-end.

also, i've got no idea how it will interface with other tools - it's a simple serial interface - and i don't have access to other gpib equipment / software to study.

[JohnnyBerg]

also, i've got no idea how it will interface with other tools - it's a simple serial interface - and i don't have access to other gpib equipment / software to study.

Have you GPIB instruments to test with?

[ealex]

got a signal generator - "basic listener" - so i can at least test a basic scenario
i hope that the gpib interface on that signal generator is still working ....

[JohnnyBerg]

I've got several HP instruments. Perhaps I can be of any assistance?

[lincoln]

I can also help I have SRS and HP counters, HP 3457, LeCroy oscope, Tektronix TM5K gear as well.

 

[ealex]

managed to get the first board assembled.
the solder paste pulled a bad joke: somehow a bubble of flux separated and made a huge mess.
even with this, the board reflowed properly - just some bridges on the stm32f100 pins - quick fix with a ton of flux
i hate the lead free solder

first but: the USBCFG pin that i use to enable the power to the isolated section goes high, not low - i'm adding a simple transistor inverter now.

i'll post some pictures once i get better lighting.
a to-92 case looks huge along the tiny P-FET switch

[ealex]

and first assembly mistake: put the io chips upside-down
good thing i measured the 5V rail resistance before powering it

[malch]

Wow your fast!