R0 Board issues -- Open tracker item to track issue found on the R0 board.

[jmlzone]

This tracker is to list any hardware issues found on the R0 board. Please see the related trackers issues for:

• Things still to be tested on the R0 board.
• Suggested changes for the R1 board.

Once the root cause or solution for an issue is found please also list it here. Number issues I#, Root Cause RC#, Solution S#

I1) Digitial pots, power and ground swapped. VDD = 17 = +5 VSS = 7 = GND. RC1) Schematic Symbol error S1) Update before next board spin

I2) R308 and R309 refence voltage divider for ADC. Placement and values swpapped silk vs schematic.
RC2) Confirmed with Seeed support, they followed the silk screen and not the POS file. S2) We will either fix the silk or possibly change to a precision 2.048v reference part.

I3) link connector missing 2v5 for terminating link audio lines. S3) See ideas for updating this on the next board

I4) De9 connectors are too far from the board edge.

I5) When powered before the software is started, the PTT lines are low. RC5) I think the BSS138's have a lower V that the 2n7000's used in the hand built prototype. S5) Add 2.2k pull down resistors on the gates of Q201, Q401, Q105, Q105 PTT's

I6) The Discriminator in pot is working backwards. RC6) the A and B pins of section B of the digital pot, Pins 8 and 10 are reversed. pin 10 should be 'A' the high side Pin 8 should be 'B' the low side. S6) Correct before next board spin

I7) The front panel pixel and old connectors are inaccessible under the USB connectors. As is the J311 expansion connector.

I8) the polarity of the SPDT soft witches were reversed. S8) Inverted in software.

[jmlzone]

I9) Ic20 bus is not accessible on the latest PI3's. S9) Those external IO's need to be moved for the old and the aux-io connectors need to be moved to I2C bus1.

[n1ist]

I'm guessing "axiom" should be aux_IO.  I'll move them (as well as RTC and OLED).  Would we want to add a switch to allow the Pi to isolate the external connectors if there's a problem?  U108 has two unused switches; I haven't used transmission gates on i2c before but I think it should work.  We could use one of the two GPIOs that are now I2C0 to control it./mike

  From: jmlzone <notifications@github.com>

To: jmlzone/PiPtr PiPtr@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Sent: Sunday, February 4, 2018 3:16 PM Subject: Re: [jmlzone/PiPtr] R0 Board issues -- Open tracker item to track issue found on the R0 board. (#23)

I9) Ic20 bus is not accessible on the latest PI3's. S9) Those external IO's need to be moved for the old and the axiom connectors need to be moved to I2C bus1.— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jmlzone]

I have corrected the typo axiom to aux-io.
I had not thought about isolation.
For testing I have cut the traces to pins 1&6 of ESD protection to the AUX-IO connectors, they run next to each other in a wide open area of the board. I then wired pins 1&6 to the proper connections on Q101 and Q103 and it looks like I can talk to an external device on the I2c with about 2 feet of wire.

With regards to isolation, since any user of an external I2C device (me) would need to be sure it all can work, and we already have the ESD isolation, I would think that adding isolation just adds a failure point, but lets keep it open for discussion before we finish the R1 board. Right now I face the issue of if I have 2 of my external I2C board (that currently don't have addressability) they would both be on address 0x20 if I had one plugged into each aux port. I think thats my problem and I need to cut a trace on that board to make some of them have a secondary address. This would be the case of having a PiPtr with 2 link or remote base radios using my I2C frequency control board.

[n1ist]

I was more worried about an external fault (ie. mouse shorted the cable) taking out local i2c.  If we use an I2C switch like PCA9540B, we can select which port (if any) is active at one time and therefore could have the same addresses on both ports.  It would even do level translation so the two aux ports could have different rails./mike

  From: jmlzone <notifications@github.com>

To: jmlzone/PiPtr PiPtr@noreply.github.com Cc: n1ist n1ist@arrl.net; Comment comment@noreply.github.com Sent: Monday, February 5, 2018 10:35 AM Subject: Re: [jmlzone/PiPtr] R0 Board issues -- Open tracker item to track issue found on the R0 board. (#23)

I have corrected the typo axiom to aux-io. I had not thought about isolation. For testing I have cut the traces to pins 1&6 of ESD protection to the AUX-IO connectors, they run next to each other in a wide open area of the board. I then wired pins 1&6 to the proper connections on Q101 and Q103 and it looks like I can talk to an external device on the I2c with about 2 feet of wire.With regards to isolation, since any user of an external I2C device (me) would need to be sure it all can work, and we already have the ESD isolation, I would think that adding isolation just adds a failure point, but lets keep it open for discussion before we finish the R1 board. Right now I face the issue of if I have 2 of my external I2C board (that currently don't have addressability) they would both be on address 0x20 if I had one plugged into each aux port. I think thats my problem and I need to cut a trace on that board to make some of them have a secondary address. This would be the case of having a PiPtr with 2 link or remote base radios using my I2C frequency control board.— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.