Author Topic: open source GPIB adapter  (Read 77739 times)

0 Members and 2 Guests are viewing this topic.

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter
« Reply #175 on: April 09, 2024, 11:17:35 am »
Hi
OK I have made those changes.
I should add a cap to the second gpib connector but that would mess up my text layout. 
I don't intend fitting the C/R, unless I have to.
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 

Offline Kean

  • Supporter
  • ****
  • Posts: 2468
  • Country: au
  • Embedded systems & IT consultant
    • Kean Electronics
Re: open source GPIB adapter
« Reply #176 on: April 09, 2024, 11:46:39 am »
I don't intend fitting the C/R, unless I have to.

Nope, C/R not really needed.  Just leave shield connection intact through the cable and keep it separate from logic ground, and obviously use the logic ground for the LA/scope connection.
It doesn't hurt to have the 1M resistor between shield and ground as you have it, but that may also already exist in one of your other devices on the bus.

If you have extra PCBs/connectors than I'd be happy to contribute some $ towards one or two and the cost of postage to Sydney.
I have a bunch of GPIB/HPIB gear in the office lab and at my home, spread across several benches, and with some still needing repairs.
 

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter
« Reply #177 on: April 10, 2024, 11:14:13 am »
If you have extra PCBs/connectors than I'd be happy to contribute some $ towards one or two and the cost of postage to Sydney.

I was planning on selling the spare ones on the local auction website.  I know  there are a few people watching my blog posts.  It will be easy enough to send one over the water. 

I am also looking at putting the pcb design into pcbway projects.  Mine would be the only project on pcbway that includes "gpib" so I am probably about 30 years late in designing a break out board.

I try and do pcbs in batches to reduce shipping costs. I may be a while before I am ready to get them made. 
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 
The following users thanked this post: Kean, pdenisowski

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter
« Reply #178 on: April 11, 2024, 05:22:01 am »
Hi
OK I have settled on a final version of the gpib breakout board.

The most significant change is the addition of notches that are almost mounting holes.
I usually include mounting holes, but I think if anyone makes one of these, they are unlikely to make an enclosure.
If they want to 3D print an enclosure, they can include keys in the print to match the notches, or
they can use M3 screws.

I have refined the text on the silk screen to make it easier to use.  It should not be necessary to refer to standards or pinouts to use this board.
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 
The following users thanked this post: Kean

Offline tautech

  • Super Contributor
  • ***
  • Posts: 29813
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: open source GPIB adapter
« Reply #179 on: April 11, 2024, 06:37:08 am »
Test is it ?
Unconnected NET pin 1 J3.  :P
Avid Rabid Hobbyist.
Some stuff seen @ Siglent HQ cannot be shared.
 

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter
« Reply #180 on: April 11, 2024, 08:44:33 am »
Test is it ?
Unconnected NET pin 1 J3.  :P

No not quite.  The pcb is correct.  That pin, and the one on the other header are "V" on the HP logic analyser 40 pin pseudo standard.  "V" is not connected on my scope.  So this connection would only be active if a HP LA was connected, and the other header was connected to something that needed "V". That is extremely unlikely but it didn't cost anything to add the track, and the other LA signals not used by the scope.  So all good.

Also pin 5 is NC on the HP standard.

Edit: On closer inspection, the line indicates the "J3" label is linked to the connector, because I had selected the J3 label.  So no problem but well spotted.
« Last Edit: April 11, 2024, 09:07:32 am by dazz1 »
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 29813
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: open source GPIB adapter
« Reply #181 on: April 11, 2024, 09:14:13 am »
Test is it ?
Unconnected NET pin 1 J3.  :P

No not quite.  The pcb is correct.  That pin, and the one on the other header are "V" on the HP logic analyser 40 pin pseudo standard.  "V" is not connected on my scope.  So this connection would only be active if a HP LA was connected, and the other header was connected to something that needed "V". That is extremely unlikely but it didn't cost anything to add the track, and the other LA signals not used by the scope.  So all good.

Also pin 5 is NC on the HP standard.

Edit: On closer inspection, the line indicates the "J3" label is linked to the connector, because I had selected the J3 label.  So no problem but well spotted.
Not what I spotted.....the little arrow on the Pin 1 trace that the ratsnest link connects to.
I believe with your editor this indicates a not fully terminated NET.
Avid Rabid Hobbyist.
Some stuff seen @ Siglent HQ cannot be shared.
 

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter
« Reply #182 on: April 11, 2024, 09:23:44 am »

Not what I spotted.....the little arrow on the Pin 1 trace that the ratsnest link connects to.
I believe with your editor this indicates a not fully terminated NET.

It's a warning about pin 1 pad attributes not matching the symbol.  Not an open net and not a problem.
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 
The following users thanked this post: tautech

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter : Shared on PCBway
« Reply #183 on: April 12, 2024, 04:22:44 am »
Hi
I have shared my GPIB breakout board on PCBway here:
https://www.pcbway.com/project/shareproject/GPIB_Break_Out_Board_f7812b3e.html

I have order parts for 5x boards, because of MOQ's so I will have 4x for sale.
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 
The following users thanked this post: Kean, pdenisowski

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter : Shared on PCBway
« Reply #184 on: April 25, 2024, 03:39:07 am »
Hi
I have edited this post  because I have made a new version 2.0 of the GPIB breakout board.  I have scrapped the version 1.0 boards.

The version 2.0 has the termination network required by HP for digital inputs.  The resistors and capacitors on each signal line are SMD fitted between the pins of the headers.  These pins provide some physical protection for the components to stop them getting knocked off.  The capacitor/resistor are stacked to keep the pcb design simple and neat.    There are 3 smd components but it looks like only 2 in the photos.

This breakout board allows direct connection to an HP logic analyser, I don't have, or my HP54645D oscilloscope. 
The other header provides direct connection to all of the raw GPIB signals.    This allows for an adapter to be made for another instrument that is not an HP.

I have shared my version 2.0 GPIB breakout board on PCBway here:
https://www.pcbway.com/project/shareproject/GPIB_Break_Out_Board_f7812b3e.html

I have made the first two version2.0  GPIB breakout boards.
I only need one breakout board and I have a bag of parts I don't need.  I could make up a kit set to sell if there is any interest.

« Last Edit: May 25, 2024, 09:42:43 am by dazz1 »
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 
The following users thanked this post: Kean, pdenisowski

Offline julian1

  • Frequent Contributor
  • **
  • Posts: 773
  • Country: au
Re: open source GPIB adapter
« Reply #185 on: June 19, 2024, 11:28:30 pm »
Thie attachment shows the ethernet to GPIB adaptor that I use (sitting ontop of the inevitable HP box). As you can probably see this one was hand soldered (!)  The central LQFP-144 is the STM32F439ZET6 and the SOICs to right the bus drivers. Voltage regulators on left and the ethernet PHY chip is on the underside.

This looks pretty interesting.
What part was used for the two transceivers? I count 20pins so perhaps 75ALS160/75ALS161 for 48mA drive and electrical compatibility with the ieee-488 standard.

Was the code ported from the AT-megato the stm32f4?
Perhaps the schematics/ footprints are hosted on github/gitlab? 
 

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter
« Reply #186 on: September 11, 2024, 12:07:19 am »
My version of the GPIB USB adapter, based entirely on the Xyphro project, has two LEDs (red and green) but remains fully compatible with Xyphro firmware.  The firmware only lights up the RED led.
the Xyphro version 2 adapter now has two LEDs on the same pins as my design.  In addition, Xyphro has grounded pin xx to allow software detection of whether the hardware is 1 or 2 LEDs.

I have chosen to use two separate LEDs for Red and Green because they are readily available and cheap.  My PCB design includes a footprint for a surface mounted bi-colour LED.  This gives the option of two styles of LED, but not both installed.

My plan is to modify the firmware to accommodate two LEDs, while maintaining backward compatibility with the one red LED versions. 
I am a "C" programming virgin, but I have done something in C-like languages.
My plan is to incrementally develop the software.
  • Include a compiler switch to select 1 or 2 LEDs mode at compile/build time.
  • Use a bit of the eeprom to select 1/2 LEDs mode.  This would allow a user to select 1/2 LEDs.

The compiler switch is the easier option and also has the advantage that I don't have to test the LED mode in run time, that would lead to delays.
I plan to maximise use of interrupts to switch the LEDs, but I will still need to do some bit bashing in run time.

My first problem has been to setup the development environment. 
With some guidance from here and running Ubuntu:  https://community.platformio.org/t/can-i-create-a-platformio-avr-project-from-existing-code-including-the-lufa-library/42538/2
Install GCC: 
Code: [Select]
>sudo apt install gcc-avr avr-libc

Clone the LUFA  repository into the git folder: 
Code: [Select]
git clone https://github.com/abcminiuser/lufa 
  It should end up in the
Code: [Select]
/home/user/git/ 
folder.  The repository will be called
Code: [Select]
LUFA
Clone the  UsbGpib.,,,,,repository into the same git folder :
Code: [Select]
git clone https://github.com/xyphro/UsbGpib.git
.  It should end up in the
Code: [Select]
/home/user/git/ 
folder. The repository will be called
Code: [Select]
UsbGpib

I then renamed the
Code: [Select]
LUFA
folder to
Code: [Select]
LUFA_repository
From the LUFA_repository folder, I moved the LUFA folder into the ~/git/UsbGpib/ folder. 
From the
Code: [Select]
~/git/UsbGpib/SW/MassStorage
folder run
Code: [Select]
make

That will build the bootloader. 

If you look on my Github repository here  https://github.com/dazz100/UsbGpib
You will find a Linux script in the SW folder that compiles the code, then loads the firmware onto the usb-gpib adapter.
There is also a Windows batch file that just loads the firmware onto the adapter.
Both would need to be modified to match your directory structure.

I am going to edit this post as I progress to building the app.

« Last Edit: October 26, 2024, 08:24:32 pm by dazz1 »
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter : Version 2.0 software for 2x LEDs
« Reply #187 on: October 23, 2024, 02:33:49 am »
Hi
I have successfully modified the firmware for 2x LED (Red and Green) operation.

After some experimentation, I think I have arrived at a user friendly signalling system.
  • Slow flashing red LED = no GPIB device connected or connected but no power.
  • Steady green LED = GPIB device connected, switched on, but not active.
  • Fast flashing green LED = GPIB device communicating over the bus.

Simple and easy to interpret. 

I have failed to figure out how to do a pull request to Xyphro's github site.  Reading the instructions doesn't help.  Only used Github to download files.  Never used it for code development.  Also my first ever crack at "c" code.  Lots of opportunity to get it wrong.    So although I may have messed up with Github, the code is working.

I have attached the upgraded 2x LED firmware to this post if anyone would like to try it out. 



Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 
The following users thanked this post: croma641

Offline Kean

  • Supporter
  • ****
  • Posts: 2468
  • Country: au
  • Embedded systems & IT consultant
    • Kean Electronics
Re: open source GPIB adapter : Version 2.0 software for 2x LEDs
« Reply #188 on: October 23, 2024, 10:51:50 am »
I have failed to figure out how to do a pull request to Xyphro's github site.  Reading the instructions doesn't help.  Only used Github to download files.  Never used it for code development.  Also my first ever crack at "c" code.  Lots of opportunity to get it wrong.    So although I may have messed up with Github, the code is working.

I have attached the upgraded 2x LED firmware to this post if anyone would like to try it out.

I'd suggest forking the xyphro code base and applying your changes to your own repo.  Then link to the repo here.  If Xyphro is interested, it is easy to create a pull request from your fork.

PS. you didn't attach anything.  As I mention, a link to your forked repo might be better.
 

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter : Version 2.0 software for 2x LEDs
« Reply #189 on: October 24, 2024, 02:14:51 am »

I'd suggest forking the xyphro code base and applying your changes to your own repo.  Then link to the repo here.  If Xyphro is interested, it is easy to create a pull request from your fork.
I figured out I forked a fork of xyphro so that messed things up.  I have deleted to forked fork from GitHub and directly forked xyphro.

PS. you didn't attach anything.  As I mention, a link to your forked repo might be better.

I am aiming to put the modified code on my fork then request that Xyphro pull my version.
I have used compiler directives to produce ver 1 or ver 2 firmware from the same source code.  Any updates to the single source code will compile for ver 1 or ver 2.

For ver 2, the red LED is only on when green is off.  I found that both-on doesn't look good and is confusing.  The slow flashing red LED is proof of life.
The green LED is toggled by an interrupt driven timer only when there is data transfer.  The green flashes indicate activity and not quantity.  A single instruction toggles the green LED only on timer ticks and only for data.  Near zero added processor load.   I think the RED/GREEN led pair is easier to interpret.

Next task is to get the modified firmware into my fork of Xyphro. 
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter : Dazz100 Version on Github
« Reply #190 on: October 26, 2024, 10:23:26 am »
Hi
I have created a repository on Github.  https://github.com/dazz100/UsbGpib
It contains the Kicad PCB design and the firmware for a 2x LED version of the Xyphro USB-GPIB adapter.
My version 2 of the firmware and hardware are compatible with both the Xyphro ver 1&2 hardware and software.

My version 2 is a slightly different flavour of adapter with slightly different design goals. 

I have raised a pull request with Xyhpro.

I just need to finish the enclosure.
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 
The following users thanked this post: croma641, coromonadalix

Offline Kean

  • Supporter
  • ****
  • Posts: 2468
  • Country: au
  • Embedded systems & IT consultant
    • Kean Electronics
Re: open source GPIB adapter : Dazz100 Version on Github
« Reply #191 on: October 26, 2024, 05:16:51 pm »
Hi
I have created a repository on Github.  https://github.com/dazz100/UsbGpib
It contains the Kicad PCB design and the firmware for a 2x LED version of the Xyphro USB-GPIB adapter.
My version 2 of the firmware and hardware are compatible with both the Xyphro ver 1&2 hardware and software.

My version 2 is a slightly different flavour of adapter with slightly different design goals. 

I have raised a pull request with Xyhpro.

I just need to finish the enclosure.

Excellent work.  If I hadn't already built a few AR488 boards, I'd make some of these.

https://github.com/xyphro/UsbGpib/pull/67/commits
Code: [Select]
119 changed files with 49,735 additions and 97,702 deletions

Oof... they are probably not going to accept that pull request for obvious reasons.
Xyphro hasn't actually acted on a pull request for a couple of years in any case, and some of those were much smaller.
But at least the pull request can be found by others who may be interested - although I suspect they are more likely to find your repo link from here.

Just some suggestions:
It is best to submit pull requests in small chunks that can be quickly reviewed and ideally also quickly tested.
The white space cleanup is great, but makes the pull request a nightmare to review.  Painful, but that would be best separated.
Deleting the older V1 files is not ideal as they are still relevant to others.
 

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter : Dazz100 Version on Github
« Reply #192 on: October 26, 2024, 08:09:53 pm »

Excellent work.  If I hadn't already built a few AR488 boards, I'd make some of these.
I can feel my head swelling already  :)

https://github.com/xyphro/UsbGpib/pull/67/commits
Code: [Select]
119 changed files with 49,735 additions and 97,702 deletions

Oof... they are probably not going to accept that pull request for obvious reasons.
Xyphro hasn't actually acted on a pull request for a couple of years in any case, and some of those were much smaller.
But at least the pull request can be found by others who may be interested - although I suspect they are more likely to find your repo link from here.
OK but not obvious to me.    I haven't yet figured out the Github etiquette   This was an all or nothing change.  I wanted to submit a complete and completed package,  not a series of half baked code changes.  If Xyphro is not processing pull requests, the point is moot. 

Just some suggestions:
It is best to submit pull requests in small chunks that can be quickly reviewed and ideally also quickly tested.
The actual code changes are minor.  The biggest changes were to the supporting documentation.  Most users won't look at the code.  They will look at the documentation and are likely to judge the quality of the software and the project as a whole based on the supporting documentation.  In too many projects I have reviewed, too much good information is buried in forum posts.  So I have made a point of updating the supporting documentation for users.

The white space cleanup is great, but makes the pull request a nightmare to review.  Painful, but that would be best separated.
OK.  I now know that. 
My editor highlights redundant white space so it is really annoying to leave in.

Deleting the older V1 files is not ideal as they are still relevant to others.
When making a pull request, I was expecting to have the option to mark the files to pull.  It seems that the pull request is for the whole of my fork. If there is a way to mark files for pull, I haven't found it yet.  I am still on training wheels for Git and Github.  So it wasn't my intention that Xyphro deletes the version 1 stuff.  When I edited the README file, I did not delete any version 1 stuff.

There is no point in me retaining any Ver 1 stuff in my repository so I have started cleaning it out so it ends up containing only my Ver 2.  That will include the README file.  The enclosure is the last design work I need to finish.  I am learning FreeCAD to do that.

My aim has always been to keep my modifications compatible with the Xyphro versions 1 & 2 hardware and software.  Probably need to change my version numbering to something like ver 2e  (e=enhanced) to avoid confusion.  I have been in communications with Xyphro for a long time so he has already included some of my suggestions in his code and hardware.  There isn't that much difference between the two version 2's, which was always the intended outcome.  More than that, I was hoping that my contributions would be rolled into the Xyphro project to make my fork redundant. 

So naturally I consider my version to be the best version but only because I tweaked the design to match my design goals.  :D   Someone else might choose another version that better suits their needs.  That is the really nice feature about open source designs.  It gives people choices.
« Last Edit: October 26, 2024, 08:13:56 pm by dazz1 »
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 

Offline coromonadalix

  • Super Contributor
  • ***
  • Posts: 7014
  • Country: ca
Re: open source GPIB adapter
« Reply #193 on: October 27, 2024, 10:50:43 am »
if your design suit your needs  :-+   and for sure i  would love more leds / indicators


i have 2x of the Xyphro adapters, no complaints ... works fine ... but sometimes i would have loved more leds to get the connection status  ...



i hope you'll do some tests with wingpib  or other gpib softwares,  the id string can play tricks  ...
 

Offline Kean

  • Supporter
  • ****
  • Posts: 2468
  • Country: au
  • Embedded systems & IT consultant
    • Kean Electronics
Re: open source GPIB adapter : Dazz100 Version on Github
« Reply #194 on: October 27, 2024, 10:58:44 am »
OK but not obvious to me.    I haven't yet figured out the Github etiquette   This was an all or nothing change.  I wanted to submit a complete and completed package,  not a series of half baked code changes.  If Xyphro is not processing pull requests, the point is moot. 

No better way to learn than have a go, and you've proven yourself to be someone that does that.

I'm no expect on Github either, and I've only done a few pull requests.  You can make some changes to the pull request once created, either via command line or the web interface - but it will be via changes to your fork.  Sometimes the best way is to create a branch for the pull request, which you can delete later.
 

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter
« Reply #195 on: October 27, 2024, 07:31:22 pm »
if your design suit your needs  :-+   and for sure i  would love more leds / indicators


i have 2x of the Xyphro adapters, no complaints ... works fine ... but sometimes i would have loved more leds to get the connection status  ...

I find more LEDs is an essential feature.
If I show SWMBO something with no LEDs, her eyes instantly glaze over as she ponders what will happen in the next episode of Coronation Street. ::)
If I show her something with LEDs, I can hold her attention for at least a few seconds.  8)

i hope you'll do some tests with wingpib  or other gpib softwares,  the id string can play tricks  ...
None of my test equipment is young enough to have an ID string, so I can't help there.  Of course if anyone would like to donate any test equipment for testing, it would find a good home here. :-DD
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter : Dazz100 Version on Github
« Reply #196 on: October 27, 2024, 07:52:20 pm »
OK but not obvious to me.    I haven't yet figured out the Github etiquette   This was an all or nothing change.  I wanted to submit a complete and completed package,  not a series of half baked code changes.  If Xyphro is not processing pull requests, the point is moot. 

No better way to learn than have a go, and you've proven yourself to be someone that does that.

I'm no expect on Github either, and I've only done a few pull requests.  You can make some changes to the pull request once created, either via command line or the web interface - but it will be via changes to your fork.  Sometimes the best way is to create a branch for the pull request, which you can delete later.

If Xyphro isn't processing pull requests, the only incentive to creating pull requests is to alert others that there is some ongoing development. 
I have already stripped out all version 1 stuff from my fork so that it is dedicated to the enhanced version 2e. My current understanding is that will effectively block acceptance of any future pull requests by Xyphro because it would wipe out all the version 1 stuff that should be kept on Xyphro's site.    I think it would require Xyphro to create a new branch that he would pull in and clone my version 2e branch.  That might be desirable, not-essential if people can just get the version 2e files they need from my site.
« Last Edit: October 27, 2024, 08:17:11 pm by dazz1 »
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 

Online eliocor

  • Supporter
  • ****
  • Posts: 531
  • Country: it
    • rhodiatoce
Re: open source GPIB adapter
« Reply #197 on: October 28, 2024, 12:02:04 am »
here it is a (v2e) BOM for buying components from LCSC or for PCB assemby by JLCPCB.
BOM contains indicative prices (€) and MOQ

For PCBA by JLCPCB the file should be slightly edited:
- delete line(s) LED1 or LED2.3 according to your choices
- it seems U1 can be chosen in two different cases: leaded and leadless. Is it correct*?
- priority was given to components in the BASIC list


*) was the PCB designed to accept leaded and leadless cases for U1?
 

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter
« Reply #198 on: October 28, 2024, 12:10:17 am »
was the PCB designed to accept leaded and leadless cases for U1?

Thanks for the BOM.
The Ver 2e PCB is designed only for the leaded version of U1.  The first versions I made were for the leadless MCUs but I had issues with soldering them.   The leaded version is much easier to hand solder.
I will add your BOM to my Github site.
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 

Offline dazz1

  • Frequent Contributor
  • **
  • Posts: 851
  • Country: nz
Re: open source GPIB adapter
« Reply #199 on: October 28, 2024, 01:17:28 am »
Hi
I have just updated my ver 2e BOM because some parts I purchased from Aliexpress and those might not be an option for an assembly service.  I have now identified parts from element14 that are equivalent to the Aliexpress parts. 
The exception is the usb-c connector.  element14 don't stock the HRO part.  I am reasonably sure there are equivalents by other manufacturers that fit the same foot print.  I just don't know the part IDs.

I have pushed the update BOM to Github.  Would you like to check that against your BOM against my updated version before  I push yours to Github?
Dazz

Over Engineering: Why make something simple when you can make it really complicated AND get it to work?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf