PowerComms 1.3.0 preview

Personally I don't think they will have much affect across the output of a PC power supply that is connected via a disc drive cable. If I were building it I would just use 100n.

---

[www.hydraraptor.blogspot.com]

i've attached the most recent version of the board. i think a couple of those changes have already made it into the board. please look at it, and let me know what changes should be made (or ideally attach a modified schematic and description)

i like the idea of using 0.1uF (100nF) caps... the small the number of unique parts, the better (so long as it makes sense electronically)

on the new BOM i sourced a 2200uF 25V capacitor. as per adrians suggestion, there are spots for two of them... one is optional.

thanks guys!

looking at RC3 (hopefully not outdated at time of comment)

Change C7 still needs to become a 0.1uF

Add C9 next to c8 and c6 as a 0.1uF

d0ubled Wrote:
-------------------------------------------------------
> looking at RC3 (hopefully not outdated at time of
> comment)

nope, rc3 is the current one.

> Change C7 still needs to become a 0.1uF
> Add C9 next to c8 and c6 as a 0.1uF

added to the TODO.

okay, done... heres the latest version (i'm also checking my changes into subversion, but i dunno how familiar you guys are with that.)

hopefully there are no more changes, and i can get this board sent off to goldphoenix on friday. its fun to look at whats been done so far:

[reprap.org]

I did some more testing on the integrated programmer today and it's still behaving itself. When using the switch, it seems to program as well as my stand-alone programmer and communicate normally. No big surprise, the two circuits are isolated.

I experimented a bit with removing the switch from the circuit. It worked surprisingly well. The Vpp LED which was pretty bright dropped to dim to dark when the switch was omitted. It still programmed my PIC, but it failed maybe 10% more than usual. It was still usable, you just had to program the chip two or three times to get it to take. The comm side seemed unaffected when the switch was removed. Anyway, my vote is keep the switch in there. We can replace it with a non-polarized three-pin header and a jumper. They're dirt cheap and don't take up much real estate on the PCB.

Those tests were on two of my desktops. I had meant to test all this stuff on my laptop as well, but my docking station has gone missing so I'm stuck without a second serial port until it turns up again.

awesome.

would you mind posting the modified kicad file? i dont know enough to pass judgement on the technical design, but if it works, it works! also, it would be nice to have the rest of the team look over it. i'm definitely okay with delaying the v1.3 release a week if it means getting onboard programming working.

this might be a stupid question, but how are you testing it? is there a socket on-board to put a PIC into? or are you working with an ICSP modified universal 1.2 as well?

"if it works, it works!"

Trial and error is not really a sound basis for designing electronics. If you design something which meets all the specifications and then test it you can have confidence it will always work. If you get something wrong it is not guaranteed to fail the test but it may do when you make enough of them to see the full spread of compenent tolerances or use it long enough to see component failures.

---

[www.hydraraptor.blogspot.com]

thats why i want him to post it... so you guys who really know this stuff well can look at it. i'm not going to make any changes on the design until everyone is in agreement that it is a technically sound design. dont worry. =)

ZachHoeken Wrote:
-------------------------------------------------------
> would you mind posting the modified kicad file?

I'll try to get it kicad-ified tonight. There's nothing elegant about it. If you want a sneak preview, load up the 1.3.0 schematic on the left half of your monitor, the JDM schematic from the wiki on the right half, and cross your eyes =)


> this might be a stupid question, but how are you
> testing it? is there a socket on-board to put a
> PIC into? or are you working with an ICSP
> modified universal 1.2 as well?

I was mostly testing against the ICSP modified Universal (original one-diode mod, I haven't tried the proposed mod for universal 1.3). I've also have an ICSP-to-ZIF socket board I can connect to test other PICs. I plugged it in and programmed a 18F2450, but most of the testing was on the 16F628As in my Universal board. I think they're more of a challenge for a programmer since they are set up for internal oscillator and MCLR disabled. I didn't design in a socket just to save board space.

cool, getting it into kicad is a pretty essential step towards getting it approved and into the v1.3 rev.

also, its a very good idea to test it against the current v1.3 universal board design.

one final thing: does it harness the fact that the powercomms board is powered? i know that some of the serial port JDM programmers rely on voltage from the serial port which is a very unreliable way of doing things. for example, most laptop serial ports dont work well with it, etc.

ZachHoeken Wrote:
-------------------------------------------------------
> also, its a very good idea to test it against the
> current v1.3 universal board design.

Yeah, we'll want to test design with a few programmers before it goes to production.

> one final thing: does it harness the fact that
> the powercomms board is powered? i know that some
> of the serial port JDM programmers rely on voltage
> from the serial port which is a very unreliable
> way of doing things. for example, most laptop
> serial ports dont work well with it, etc.

Sorry if I gave you the wrong impression. The programmer I integrated was dependent on the serial port voltages, so it's likely to fail on many laptops and USB->serial converters. Strangely, it works pretty well on mine. The other options all involve designing and testing a new programmer and possibly software, and that just doesn't seem worth the effort.

About the only easy thing we could do to make this better for low-power serial ports is to add a header and resistor where they could inject power from two 9V batteries, or maybe the -12 & +5 rails of the PC power supply. I've never tried this, but it's supposed to work.

Or we can scrap it and worry about integrating programmer when we make the leap to USB...

I think I mentioned before: I think this is what we need to get a cheap reliable VPP

[www.romanblack.com]

---

[www.hydraraptor.blogspot.com]

emf,
It should be possible to make it reliable without having to change the software. If you post a schematic of what you have I will have a go at integrating the roman black VPP.

---

[www.hydraraptor.blogspot.com]

yes, please post the schematic. there are quite a few people here willing to help, but we cant really do anything unless we have the schematic to work from.

i know kicad can be a pain in the butt... but once you learn its strange little quirks, it actually isnt too bad. i've logged more hours than i'd like in it... so feel free to ask me any questions you have.

Or just a PDF or PNG, etc, out of Eagle would be enough.

---

[www.hydraraptor.blogspot.com]

Sorry guys, I was away from fast net access this weekend. I'll try to get the schematic posted at lunch.

I'm not sure how well it's going to work though. The programmer really is just a JDM2, I promise. One of the suggestions JDM makes on his site for low-power serial ports is to put 18V over C2, with a current-limiting resistor. Usually my laptop works fine with an unpowered JDM2, but occasionally it gets irritable and refuses to work (I have no idea if these failures are related to voltage/current, they could be timing problems). I tried adding the batteries to mine one time it was acting up and they didn't make any difference. Unless someone else has a low-voltage port that they can get to work by applying this fix, I don't think there's much sense in designing it in.

Doing a ground-up redesign of the programmer would be (for me) a lot of work and need a lot of testing, and it just doesn't seem worth the time or complexity.

Yes the JDM programmer is a bit weird in that is gets the 13V by taking some RS232 lines low and some high. That means PIC VSS is at a negative voltage so I think you cant do ISP programming unless the UCB is disconnected.

Given that we have a proper RS232 level changer with spare channels and a stable 5V rail I don't think the JDM circuit is well suited to what we are try to achieve.

Perhaps a better idea is to use the spare channels in the MAX and the RB VPP generator. I think this could be made compatible with the JDM s/w but not having any of this stuff to play with cannot be sure.

---

[www.hydraraptor.blogspot.com]

hmm... well it seems that this design is not something we'll be able to thoroughly test and get to an ideal state in a short amount of time.

how do you guys feel about leaving out the integrated programmer for the v1.3 release, and instead working on a v1.4 w/ integrated programmer. that way you guys can take your time, and get a really nice, rock solid design going. that would give you 3-4 months to come up with a new design, and we would be free to explore some interesting options without any sort of major time constraints.

This is by way of supporting Zach's stand.

Reprap is starting to have some real problems from a "get it out of the door" standpoint. Guys, when you are designing a real product you have a "drop dead" date where you freeze the design. Any design changes after than are allowed only to fix bugs in the frozen design, not to add new features.

If you don't do that you get the kinds of cost overruns and design abominations that the American Pentagon used to get when they funded new weapons systems.

> Yes the JDM programmer is a bit weird in that is
> gets the 13V by taking some RS232 lines low and
> some high. That means PIC VSS is at a negative
> voltage so I think you cant do ISP programming
> unless the UCB is disconnected.

Right. When we put out a board with ICSP header, we'll need to put a big warning to disconnect anything that provides a ground (power, tx, rx).

> Given that we have a proper RS232 level changer
> with spare channels and a stable 5V rail I don't
> think the JDM circuit is well suited to what we
> are try to achieve.

I agree. My first choice was to go off a com84 design, which assumed you'd have a regulated 13 & 5V rail, but it didn't seem to work when I tried it. My best guess is com84 design leaves Vdd at 5V all the time, which lets the chip start executing code before we raise Vpp to enter programming mode. JDM was the only other design I've come across that works over the serial port by bit-banging. If you know of any others, they're worth a look.

> Perhaps a better idea is to use the spare channels
> in the MAX and the RB VPP generator. I think this
> could be made compatible with the JDM s/w but not
> having any of this stuff to play with cannot be
> sure.

That would be the ideal solution. After reading JDM's detailed functional description and not finding any clear explanation of what signals the software generates for each type of operation, I decided it was beyond my abilities.

It's something I should be able to do as I have a DSO and if need be access to logic analyzers at work. The only thing I don't have is time at the moment so I think Zach's suggestion of leaving it to the next version is a good one.

---

[www.hydraraptor.blogspot.com]

ZachHoeken Wrote:
> how do you guys feel about leaving out the
> integrated programmer for the v1.3 release, and
> instead working on a v1.4 w/ integrated
> programmer.

Sounds good. I had never intended this to be a newly-designed works-for-everyone programmer, I just failed to communicate that at the outset. If you want to add in a programmer identical to the one on the wiki, that's easy and I think it's safe enough to do at this point in time, but, it will fail in exactly the same circumstances as the one listed on the wiki. If you want to do anything more than that, we're setting off into new territory and it's not appropriate to do on a short deadline.

Personally, I'm for shelving the development of a decent programmer until we make the leap to USB. At least there we've got a pretty good idea of what to expect from the hardware.

okay, that sounds good to me. i'd like to get this design out the door, and that means it can happen sooner.

if you guys want, it might be worth starting another thread to put forth ideas for a v2.0 of the powercomms card. if you're excited about it, you might as well ride the momentum.

i sent in a test order to goldphoenix for the latest version of the boards. i'll let you guys know when they get here. now to update the BOM for v1.3. i already got most of it done, i just need to double check.

Did you add the extra cap d0ubled and I recommended and did you do anything about the power connectors being too small for the required wire gauge?

---

[www.hydraraptor.blogspot.com]

1. if the suggestion was to add a 0.1uF capacitor in parallel with the large caps between +12 and G, then yes.

2. no, i havent addressed that yet. do you have a recommendation as to what sort of power connectors we should be using? we need something that is keyed. perhaps just a larger version of the .100 headers?

if you get me part numbers, i'll make it happen =)

also, what is the minimum gauge of wire required? i think the max we're planning on driving to each board is something like 4A, dont quote me on that though.

I posted the wire guages in the other thread a while ago [forums.reprap.org]

For 4A you need 24/0.2 cable which is slightly smaller than 18 AWG. I can't think of a 0.1" connector that takes that guage. I used a 0.2" connector I salvage from the inside of a PC PSU.

Wasn't the previous connector a bigger pitch? Could you just use a 2 pin version of that and either space them appart slightly or turn them 90?

---

[www.hydraraptor.blogspot.com]