open source GPIB adapter

[dreamcat4]

couple of things:

a) if there is something new and usedul in that zip file code... it should be up into github. and properly versioned / rebased. and or optionally pr (depends if worth the bother)

b) we can already see here (see pic) in the network graph. was things added in somebody else's fork in january. for example the usb-c connector is amongst one of those changes

https://github.com/xyphro/UsbGpib/network

although personally i am more interested in using an arduino micro board. and then vero boarding it together to the gpib connector. to see how that turns out... got the updated version of the arduino micro with usb-c on it.

[dazz1]

Hi
It is not my zip file and although I have a github account, I don't really know how it works.  I didn't know about the really useful network feature, so I didn't know what nipo had done. 

I think there are three improvements worth doing on the nipo fork:
1.  add anti-static protection on the usb lines.
2.  add a bi-colour LED which can display 3 distinct colours that can communicate quite a bit of information. 
3. a better 3D enclosure.

[dazz1]

Hi
I have used this project as an excuse to learn KiCad.
I have gathered together the good ideas of others to create the bestest and most marvelous version of the schematic and PCB for the USB-GPIB adapter.
"My" design is a combination of the best features I see in other designs, plus a couple of features I have dreamed up.

The fruits of my effforts can be found here:
https://github.com/dazz100/UsbGpib/tree/USB-GPIB-Dazz/HW/Dazz

The changes made include:

• Adding ESD protection,
• Adding USB-C connector,
• Used hand solder friendly larger 0603 sized components,
• Added 2x options for mounting bi-colour LEDs,
• Added 2x 3mm mounting holes to anchor the enclosure to the PCB.
• Used a rectilinear shaped PCB to make it easier to use on stiff connectors.

The USB-B connector is chunky and robust but relatively large.
The USB-micro may be too fragile for knocking around in the lab.
The USB-C seems to be the Goldilocks choice.

The larger 0603 sized components will make it easier for the visually challenged to hand solder this project.

I think the addition of a second LED can be used to convey useful status info to a user, much like the LEDs on an ethernet socket.
I have added a LED to a spare output of the MCU.  The original software will continue to drive one LED.  The software will need to be modified to enable driving the second LED.
I have found that there is no standard orientation of the rear panel connection.   Readily available bi-colour SMD LEDs point upwards.    I have added the option of fitting right angle LEDs on the end of the PCB (opposite the USB).  Regardless of orientation, these should always be accessible to see.

Centronics connectors can be stiff to insert/remove.  The addition of two mounting holes will allow the enclosure to be anchored to the adapter with 3mm screws.
For similar reasons, I have used a rectilinear PCB to make it easier to include finger grips in the design of the enclosure.  The PCB has been slightly extended so there is some bare PCB that can fit into a slot within the enclosure to further anchor the enclosure to the PCB.

The form factor of a "standard" GPIB cable assembly is side entry.   This is similar to the form factor of my PCB/enclosure design. I see no advantage in a stepped shape of the PCB.

I decided very early not to make any hardware changes (eg. pin allocations) that would require code changes.  This includes the bi-colour LEDs which will run as a single LED mode on the current software version.  So although this version is only similar in hardware design, it is not essential to modify the software.

I haven't yet decided whether the enclosure will be a one-piece "cup" or a two-piece clam shell. 


I think this is a really good project and the incremental development by others has only improved the outcome.    I have three items of old test equipment with a GPIB bus so this adapter will be a way of increasing their usefulness.

I am seeking feedback on the schematic and pcb designs.  Have I got it right??   Is there a feature missing??  Any feedback would be welcomed.

[coromonadalix]

personally love the usb-c variant

My 2 cent comment would have been to provide some pads for say rgb or 2 color led  3mm or 5 mm led (with their full lenght pins) being put on the side of the pcb  if you 3d print some enclosure, the smt led would not be visible ? and with an hole / windows 

it is not always easy to see them


and i would have used standard straight pins for the programming connector, the right angled one give me chills to solder and i would say they could break easier than going thru the pcb ??

annnd they are easier to source, any long straight header pins can do ...


thks

[dazz1]

Hi
Thanks for you feedback.

The header is already straight pin thru holes. See the attached 3D model.

The advantage of SMD LEDs is that I can slide the pcb into a one piece enclosure without having to worry about snagging LEDs that stick up through holes.
To get around the problem of poor visibility of the LEDs, I was thinking of adding  diffuse semi-transparent inserts in the enclosure.    A simple way to make inserts would be to take standard LEDs and drill out the leads and diode leaving just a coloured shell.  This could then be glued into the enclosure with no attachment to the PCB or smd LEDs.

I could add thru-hole led pads, but the LEDs would dictate a two piece clam shell enclosure in their current position.   I haven't designed the enclosure yet, but I am heading towards a one piece design that the adapter slides into.

I could fit the leaded LEDs along the left edge of the PCB (as drawn).  The LEDs could then slide into holes in the enclosure.  The advantage of leaded LEDs is that they are available everywhere.

[dazz1]

My 2 cent comment would have been to provide some pads for say rgb or 2 color led  3mm or 5 mm led ...

PCB mount indicators like this one:

https://us.rs-online.com/product/dialight/550-5207f/70081710/

look like good candidates.

I have had a quick tour through the code, and it looks like it would not be too difficult to add LED status for various actions.   

[coromonadalix]

a last comment  loll

would it be better to use a 10 pin variant of the jtag   ISP  instead of the 6 pin

because many many adapters / programmers come with the 10 pins and you have to do some battle  to get the 10 to 6 pin converter or find programmers in the 6 pin variants

happened to me and was frustrating  ...

another 2 cents


willing to buy assembled board ??  or you'll provide the bare board  gerbers  etc

[dazz1]

Hi
I have a programmer on order from Aliexpress, complete with the necessary adapter. 
The extra 4 pins of a 10 pin header would take up quite a bit of real-estate on the pcb.

[dazz1]

willing to buy assembled board ??  or you'll provide the bare board  gerbers  etc

I will buy the bare board and assemble myself for my own use.
I hadn't considered making/selling them.

Most parts come in 5's but I only need 3 adapters.   I expect to have at least 2 spare boards plus parts left over.
This is a very niche item.

[dreamcat4]

Hi
I have a programmer on order from Aliexpress, complete with the necessary adapter. 
The extra 4 pins of a 10 pin header would take up quite a bit of real-estate on the pcb.

Could please provide link to the programmer you ended up ordering? Many thanks

[dazz1]

Could please provide link to the programmer you ended up ordering? Many thanks

There are many shops selling the same item.  This is one of them.
https://www.aliexpress.com/item/1005004954482917.html?spm=a2g0o.order_list.order_list_main.89.23251802Ao05Ef

[dazz1]

Hi
I have now added the option of thru hole, right angle LEDs as shown on the attached screen shot.  I have designed for the Dialight 551-xx07F 3mm series.  The LEDs are orientated to point out the rear of the adapter to allow for a single piece enclosure.   The enclosure will be able to slide over the pcb and connector.

The option of the smd bi-colour LED beside the connector is still there.  The disadvantage of the SMD option is that the LEDs will only be visible one way up.

[dazz1]

Hi
The current version of the software is only designed for one red LED.  The software will not use the second green LED.   I think that two LEDs should be able to provide useful status information, especially for GPIB initial diagnostics.
I am hoping someone reading this will be interested enough to take up the challenge of modifying the code to improve visual status information from the two LEDs.  I would rather not do it myself because I haven't programmed this MCU before and I don't have the development tool chain setup.   I haven't written C code before.  I can understand it, but I haven't written it.

I propose the pair of LEDs display static on state to indicate power/connection and,
flashing to indicate activity as described below. 

Red on = Power On
Green on = GPIB device connected

Red flashing = writing data from the GPIB.  Achieved by turning off the LED for a moment.
Green flashing = reading data from the GPIB.  Achieved by turning off the LED for a moment.

There is a variable called   

Code: [Select]

s_device_stateWhen this has a value =

Code: [Select]

GPIB_DEVICE_CONNECTSTATE_CONNECTED   the adapter recognizes that the GPIB is connected to an active device and the green LED should be turned on.   The GPIB status is returned by a call to the function declared as 

Code: [Select]

bool gpib_is_connected  

The Red LED simply needs to be turned on to indicate that USB is available. 

Read/Write events can be signaled by setting booleans value each time a read or write function is called.  An ISR running at say 100Hz can turn off the related LED, then turn it back on again.  This would create an activity indicator.  Using a timer triggered ISR will minimise the computing load of the LEDs and display flashing at a rate slow enough to be recognized as flashing.


I don't think any of this would be too difficult.  It would just need some time and skill.

[dazz1]

Hi
In this world of virtual reality, I can safely say I have completed the bestest and most marvelous version of the GPIB adapter. 
Just marvel at the attached view 

Back in the real world, I have ordered the PCBs.  They will take a couple of months to get to me. 
In the mean time, I can design an an enclosure around the 3D model.  I have a 3D printer so I can try out different ideas.
I am thinking of going to a curvaceous  organically shaped enclosure because I can.  It will be a differentiating feature to the over-priced branded adapters. 

[dazz1]

Hi
OK I want to make a small modification to the C code for the adapter.   
At present, the single indicates different states:
LED blinking: The USBGPIB converter is connected to a measurement instrument, it is powered off or its GPIB port is disabled. In this state, the device is also not connected to USB and will not show up in the device manager or lsusb.
LED on: The device is connected to a measurement device and GPIB communication possible. It is also accessible over USB
LED off: The device is not connected over USB, or the PC powered off

Right now, I am still waiting for the pcb's to be delivered.  I have the necessary components to build the USB-GPIB adapter.
 
I want to program the 2nd LED to indicate read/write activity like an Ethernet connector.  The aim is to provide visual confirmation that the adapter is actively communicating with the device.
I think I can do this by triggering the LED off the GPIB-DAV signal.    Making this change would leave the code 100% compatible with the Xyphro original hardware design. 

I need to create a programming tool chain to do this.   I have been reading up on AVR compilers and there seems to be a wide choice. I don't need an IDE for the simple code changes I have in mind. The creator Xyphro appears to have used GCC.
Can anyone point to a guide on configuring GCC to compile the Xyphro code, and then programming the AVR.  I can do this with Win10 or Linux. 

 

[coromonadalix]

for the 3d case 

you could try some snapping effect between the 2 parts

for the programmer  avrdude is a preferred, avrdudess for windows ...


I would put myself in line to order 1 or 2 completed pcb's

[dazz1]

Hi
I have considered an snap enclosure, but the Centronics connectors requires too much force for such an enclosure to survive being pulled and pushed too often.

The strongest candidate I have found for a gcc based AVR tool chain is the Ubuntu version https://askubuntu.com/questions/581690/install-avr-libc

I have considered selling completed units but I had to close my child labour sweat shops.
So after factoring in:
the value of my time (I have never been paid more than half of my true value)
global warming,
carbon tax credits,
and of course the effect of inflation on the cost of wurled peas

I have a calculated a retail price of $328,231.17 plus shipping and sales tax.

Min order quantities required me to buy enough parts for 5x interfaces, but I only have 3x test equipment with a GPIB interface. 
There could be some wiggle room on the price 

To be serious for just a moment, I doubt that it would be worth me selling individual units at any price.  I didn't start work on this project with the intention of selling units.   By far the most expensive item is the cost of assembly.   To keep that within reasonable limits, I would need a reasonable number of orders to do at one time.  Given the niche nature of this adapter, that probably won't happen.

[tautech]

But Dazz, when last I visited you have one slave labor unit still at home, can you not put him to good use ?
Or is it  ?

[Gertjan]

Min order quantities required me to buy enough parts for 5x interfaces, but I only have 3x test equipment with a GPIB interface. 

Think out of th box!
The solution is not selling adapters, but acquiring two more test equipments with GPIB 

regards, Gertjan.

[dazz1]

Min order quantities required me to buy enough parts for 5x interfaces, but I only have 3x test equipment with a GPIB interface. 

Think out of th box!
The solution is not selling adapters, but acquiring two more test equipments with GPIB 

regards, Gertjan.

That is the plan 

[dazz1]

...
Or is it  ?

Yes it is  and 

[dazz1]

Hi
I have been reading into the code.  The code to drive the LED doesn't match the documentation that well. 

So if I am reading the code correctly (I am a C virgin) then:
if the USB is connected, the LED stays on
Code then goes into a loop.  The LED is switched off if no GPIB device is connected.
if no GPIB device is connected and off, the LED flashes at 2Hz until.
a GPIB device is connected and on, then the LED flashes at 5Hz.

It also flashes 250ms pulses when USB data is transferred.

So the LED indicates activity, but the LED is shared between GPIB and USB.


I am looking at changing the code to show USB status/power on the RED led, and GPIB status/data transfer on the GREEN LED.
So:
RED ON = USB power on
RED Flashing Slow = USB enabled
RED Flashing Fast = USB active

GREEN OFF = no GPIB device connected.
GREEN ON = GPIB device connected and off
GREEN Flashing Slow = GPIB device connected, on and enabled.
GREEN Flashing Fast = GPIB device active.

Thoughts?  Does this make sense??

[rssenior]

Do you have a bill of materials for your version dazz1? I thought I saw one once, but I'm not seeing it now.

[dazz1]

Do you have a bill of materials for your version dazz1? I thought I saw one once, but I'm not seeing it now.

I added a BOM for the Xyphro version in issues on his Git page.

Attached is a BOM for my version with part numbers from element14. 
I now have the parts and the PCBs, but not enough time to assemble yet.

[intabits]

I now have the parts and the PCBs, but not enough time to assemble yet.

Have you assembled and tried one yet?

I'm currently designing an adapter PCB for this same connector, and as far as I can tell, your connector is arse-about.
You would need to mount it to the bottom of the PCB shown in reply #61.

Or is it me that has it wrong?

I'm looking at these connector diagrams:-
https://www.hp9845.net/9845/tutorials/hpib/  (bottom of page)
http://www.hit.bme.hu/~papay/edu/GPIB/tutor.htm
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kIoVSAU
https://www.tmatlantic.com/encyclopedia/index.php?ELEMENT_ID=14204

All these have DIO1 at top-left when looking into the connector with the wide side at the left. And that would also go to the top-left pad on your PCB, but your DIO1 is at the bottom-left!?

I was just about to send my design to JCLPCB after a final check, but now I'm confused....