Re: gEDA-user: Wireless comms options
On 8/2/2011 1:57 PM, John Griessen wrote: On 08/02/11 03:44, Chris Smith wrote: I'm developing an application that needs to send a stream of data from one device to another, but I don't have much experience with wireless Not so sure about the data rate... what does the above translate to in serial data bits per second? 800x600x24 all x 30fps? that's 345 Mega bits/sec! Can you compress it and then expand at other end with your hardware? John H.264 (which you snipped) is a standard for compressed video. Sampled composite video is not likely to be easy to transmit as you have pointed out. That is why no one does it digitally outside of a wire. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: help needed; asymmetric load after rectifier seems to disrupt its working.
It's also hard to see how the circuit could work with C1 in series with the transformer current. Why is a capacitor needed if you use the transformer? Maybe there is some effect that will balance things out, but if the two currents are unequal, actually it would be the integral of the two currents that need to be equal, the peak value is unimportant, the voltage on the capacitor will grow without limit... until something limits it. In the circuit with the transformer, is there some effect that will balance the positive and negative currents in the primary? Rick On 6/30/2011 4:06 AM, Andy Fierman wrote: Good point Rick, I should have explained that even though the larger inductance reduces the rms current in the primary significantly, the positive and negative peak currents are highly asymmetric. Simulating with a sinewave input, the positive peak current is about 110mA whilst the negative is about -390mA. Hence the transformer has to have a considerably higher peak current rating than the rms values might suggest. Robert originally said his input is bandlimited 15KHz to 28KHz but all his circuits include some form of discrete bandpass filtering. I suspect what Robert intends is that C1 and some combination of the transformer primary - as in his later posting - or a single inductance to ground or an additional series inductance - as in the original circuit posted - forms a bandpass filter centred on about 23kHz. In any case it is difficult to see how C1 can be removed without adding some sort of active buffer stage between the rectifiers and the filter, which then requires some sort of bootstrap supply to bring up the buffer to drive the rectifiers. Andy. signality.co.uk On 29 June 2011 23:54, rickmangnuarm.g...@arius.com wrote: The transformer allows a DC path to exist on the secondary side, but you still have the capacitor on the primary side of the circuit. If the positive and negative pulse currents are not equal, you will still have a problem on the primary side. You need to remove the cap C1. I still can't tell exactly what is going on in your circuit because you don't provide any labels on the o'scope diagrams. It would also be useful to see current waveforms from the simulations and waveforms from the loads. As was asked for previously, we still have not seen your requirements so I can't tell exactly what you are trying to do with this circuit. How large is the DC offset in the source? Why don't you include that in your simulation model? What voltage do you need out of this supply? I really can't tell what is needed in your design and what is just wrong. Rick On 6/24/2011 7:10 AM, myken wrote: This is strange in my simulation the attached circuit works fine. In real life it kinda works but the signals are distorted like you can see. I think that has something to do with the fact we used a pulse transformer to try the circuit. If we disconnect Vx the signals stay the same, so the distortion is in the transformer. If you say it doesn't work then why doesn't it work? On 22/06/11 22:39, Andy Fierman wrote: Sorry Robert, Both Wojciech and I are wrong. His suggestion about adding a choke is basically the same as mine of using a transformer. The idea of both is to add a dc path to ground at the rectifier inputs. The difference is that the transformer adds DC isolation - which if you include your bandpass filter - you do not need. Sounds like the thing to do but sadly, the simulations show the reality! A choke does not do what you want and neither does a simple 1:1 transformer. However, if you use a 1:1:1 transformer then it all comes together. You can use a transformer with a 1:2 turns ratio, centre tapped and keep to the original half wave rectifier scheme. If you use a three winding transformer of 1:1:1 then you can use two bridge rectifiers. Using bridge rectifiers doubles the ripple frequency so allows lower smoothing C for the same ripple voltage. The attached (not very good quality) pdf shows the non-working choke and 1:1 transformer ideas and the working 1:1:1 transformer versions. Note the 1u smoothing capacitor values. These were reduced to make the simulation reach a steady state sooner than with the original 100uF values. Andy. signality.co.uk On 22 June 2011 01:12, Wojciech Kazubski [1][1]w...@o2.pl wrote: Hello all, I would appreciate some expert advice. I have a system which rectifies a sine wave input signal of 20Khz after a LC filter (see Rectifier_sim.jpeg) Everything works fine if LOAD_1 and LOAD_2 are equal. Vx is then (almost) the same as Vin. And Vcc and Vss are equal to the positive or negative part of the sine wave (less the DC losses) (Vss = -Vin_top and Vcc = Vin_top). BUT if LOAD_1 and LOAD_2 are not equal (like in Rectifier_sim.jpeg) it seems that Vx is lifted (DC component added) and Vss moves to the 0V and Vcc is lifted to twice the
Re: gEDA-user: OT: help needed; asymmetric load after rectifier seems to disrupt its working.
The transformer allows a DC path to exist on the secondary side, but you still have the capacitor on the primary side of the circuit. If the positive and negative pulse currents are not equal, you will still have a problem on the primary side. You need to remove the cap C1. I still can't tell exactly what is going on in your circuit because you don't provide any labels on the o'scope diagrams. It would also be useful to see current waveforms from the simulations and waveforms from the loads. As was asked for previously, we still have not seen your requirements so I can't tell exactly what you are trying to do with this circuit. How large is the DC offset in the source? Why don't you include that in your simulation model? What voltage do you need out of this supply? I really can't tell what is needed in your design and what is just wrong. Rick On 6/24/2011 7:10 AM, myken wrote: This is strange in my simulation the attached circuit works fine. In real life it kinda works but the signals are distorted like you can see. I think that has something to do with the fact we used a pulse transformer to try the circuit. If we disconnect Vx the signals stay the same, so the distortion is in the transformer. If you say it doesn't work then why doesn't it work? On 22/06/11 22:39, Andy Fierman wrote: Sorry Robert, Both Wojciech and I are wrong. His suggestion about adding a choke is basically the same as mine of using a transformer. The idea of both is to add a dc path to ground at the rectifier inputs. The difference is that the transformer adds DC isolation - which if you include your bandpass filter - you do not need. Sounds like the thing to do but sadly, the simulations show the reality! A choke does not do what you want and neither does a simple 1:1 transformer. However, if you use a 1:1:1 transformer then it all comes together. You can use a transformer with a 1:2 turns ratio, centre tapped and keep to the original half wave rectifier scheme. If you use a three winding transformer of 1:1:1 then you can use two bridge rectifiers. Using bridge rectifiers doubles the ripple frequency so allows lower smoothing C for the same ripple voltage. The attached (not very good quality) pdf shows the non-working choke and 1:1 transformer ideas and the working 1:1:1 transformer versions. Note the 1u smoothing capacitor values. These were reduced to make the simulation reach a steady state sooner than with the original 100uF values. Andy. signality.co.uk On 22 June 2011 01:12, Wojciech Kazubski [1][1]w...@o2.pl wrote: Hello all, I would appreciate some expert advice. I have a system which rectifies a sine wave input signal of 20Khz after a LC filter (see Rectifier_sim.jpeg) Everything works fine if LOAD_1 and LOAD_2 are equal. Vx is then (almost) the same as Vin. And Vcc and Vss are equal to the positive or negative part of the sine wave (less the DC losses) (Vss = -Vin_top and Vcc = Vin_top). BUT if LOAD_1 and LOAD_2 are not equal (like in Rectifier_sim.jpeg) it seems that Vx is lifted (DC component added) and Vss moves to the 0V and Vcc is lifted to twice the value I would expect (Vss = 0 and Vcc = Vin_toptop) (see rectifiersmp.eps). Our real life prototype shows the same behaviour as the simulation. I need this set-up for my system to work and I can not guarantee that the two loads always will be equal. Vin can be anything between 10Vtt and 90Vtt. I have tried adding a resistor from Vx to ground and that seems to help but increases the current drawn from the source (V1) to a unacceptable level. It should be a low power solution. If I short-circuit C1 everything works fine again (V1 has a low resistance output) but of course will disable the filter, which we don't what. Is there anyone here who can explain to me how and why this is happening and if available can anyone suggest a solution to me. I have been wrestling with this problem for a couple of days now, so any help will be very much appreciated. Many thanks, Robert There is no DC patch from Vx to ground. If both loads are equal, both rectified curreant are equal and cancel one another. If the loads are different, the imbalance current charges Vx node until both output currents become equal again. To avoid this place a choke between Vx and ground. Wojciech Kazubski ___ geda-user mailing list [[2]2]geda-user@moria.seul.org [3][3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list [[4]4]geda-user@moria.seul.org [5][5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. [6]mailto:w...@o2.pl 2. [7]mailto:geda-user@moria.seul.org 3. [8]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 4. [9]mailto:geda-user@moria.seul.org 5. [10]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: help needed; asymmetric load after rectifier seems to disrupt its working.
What is the purpose of C1 and L1? If you want to filter anything, it should be AFTER you rectify the signal to DC. A series cap is going to remove low frequencies... like DC which is attenuated very highly. So much in fact that you can't draw a DC signal through a capacitor. That is why your circuit is not working. If you remove C1 and L1 the circuit will work the way you want it to I believe. Also, with an input frequency of 15 kHz or higher, you won't be needing 100 uF output filter capacitors for a light load. How many mA is your load? How much ripple can you allow? Use those two values to calculate the value of output filter capacitor you need. Once I fix your circuit by removing the input filter I measure 19.14 volts out and 38.2 mA of current into a 500 ohm load. Is that what you are shooting for? The 100 uF cap gives around 10 mV of ripple. With lighter loads or more ripple the cap can be smaller. Rick On 6/17/2011 4:44 AM, myken wrote: Yeap, it should be a very low power power supply. Vx is not important Vcc and Vss are. Vin can be anything from 15Khz to 28Khz so a transformer is not the most desired option. I have designed two SMPS for Vcc and Vss but there load to the rectifier are not the same, with the described result. I will try the options suggested in this list today. Robert. On 17/06/11 04:13, gene glick wrote: On 06/16/2011 02:30 PM, myken wrote: Hello all, I would appreciate some expert advice. Are you trying to make a low current power supply? I agree with DJ - the unequal loading on + and - cycle will average to something other than zero (unequal capacitors, unequal diodes, etc) If Vx must always be average zero - you'll need to do something else. If you can handle a little voltage drop, don't care what happens to Vx, and don't mind adding a few parts, make a cheapo regulator with a zener and BJT? (Or maybe use TL31 instead of zener) What about a small transformer, one winding on primary, center tapped on secondary. Add a diode and a cap for each leg - and there you go! Anyway, there's lots of ways to do this. If regulated output is what you want, a little more work is required. gene ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: zview/ngscope
On 4/19/2011 5:26 AM, Kai-Martin Knaak wrote: rickman wrote: By suitable I meant suitable in all ways. You'll have to test yourself. If the code is not going to be available, I guess that disqualifies it unless I want to pick it up and run with it. G in xmgrace is for GPL. Even if the Weizmann site were down, there would still be the Debian repository. I meant if the code is not complete I would have to do the work myself. I'm just batting around some ideas and would like to find some software to base an o'scope UI on. You mean some kind of code re-use? As opposed to code disuse? I'm not sure what you mean. As opposed to use of the application. Did I mention, there is a C api? I have been looking for a good commercial mixed mode oscilloscope/logic analyzer (...) ~300 MHz (...) Agilent (...) home brew oscopes (...) Not sure, What you are aiming at. This discussion started about a project to view the data produced by circuit simulation. You seem to be looking for something different. Yes, and I asked if the software would be suitable for a real time update for an o'scope type application. I am looking at what it would take to roll an o'scope project. I seem to find a lot of projects that have been started but not finished and others that are far below what I would like. The hardware of a good quality o'scope/logic analyzer would not be easy, but for me the software would be the hard part. Providing a real time display with a high update rate would be a challenge for me. If that part is done, then the first major hurtle is done. Some part of the hardware design depends on what the software requires to facilitate the real time data transfer. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: zview/ngscope
On 4/17/2011 5:00 PM, Kai-Martin Knaak wrote: rickman wrote: When I had the need for an interactive waveform viewer that could also be driven by an application, I had good success with xmgrace http://plasma-gate.weizmann.ac.il/Grace/ It is fully scriptable and can produce publication quality plots, too. Would any of these be suitable for a real time update of an o'scope display? This is what I meant by the preceding comment: There is an api to xmgrace that allows any application written in C to feed values to the GUI and make it update the graphs. So the GUI can show the data while they pour in. The user still has full GUI control over zoom, pan and the various aspects of graph scaling. Graphs can be linear, log scale, rectangular, or polar. Data points can be all kinds of shapes, with or without error margins. No 3D-imaging, though. Be aware, that there is a down side: The project has grind to a virtual stand still since a few years now. The proposed, complete rewrite that would be grace6 looks like it will never be finished. By suitable I meant suitable in all ways. I can only assume that this code would run fast enough to work well. But the idea sounds right. Can it display analog data as well as logic data? What about the others? If the code is not going to be available, I guess that disqualifies it unless I want to pick it up and run with it. I'm just batting around some ideas and would like to find some software to base an o'scope UI on. You mean some kind of code re-use? As opposed to code disuse? I'm not sure what you mean. I have been looking for a good commercial mixed mode oscilloscope/logic analyzer and have not found one that has a fast analog front end (meaning ~300 MHz bandwidth), at least 16 bits of digital input and is well under a kilobuck (USD). Most of what I've found are not as functional as I would like or are the same price as a self contained unit or both. Agilent has one but I think they are asking around $2,000 and it has some short comings that I bet their stand alone units don't have. The low cost units all seem to fall very short in the analog input department. I guess I never realized that an oscope analog front end is expensive to build. I figured the price had more to do with the marketing, development and other costs. The small companies don't have many of those costs and I figured they could produce something fairly good at a fraction of the price. They seem to provide up to around 100 MHz bandwidth ok for a few hundred USD, but faster than that and the price jumps up really fast. Maybe it is a marketing issue and there just aren't enough sales of the faster units to amortize the costs. All that aside, I was looking at some of the home brew oscopes and there are more than one project that has potential. I was thinking of piggybacking off of what ever I could find to see what could be produced. The software seems to be one of the weak points and likely one of the most important points at the same time. A poor UI will make a great hardware design pretty worthless, so it is just as important. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: zview/ngscope
Hi Alex, I don't have any ideas really. I just know there are some commercial products I won't use if they are given to me... one was and I'm returning it. The basic o'scope control panel works pretty well actually. I'm not crazy about emulating round knobs, but the controls do what the user needs done mostly in an intuitive way. But that may be outside the scope of a waveform viewer. Control of the scope is not the same as viewing the waveform. I'm not sure I really have the time right now to think about this. If I spend some time with this I'll drop you a note. Rick On 4/17/2011 5:39 PM, A.Burinskiy wrote: Rick, I wrote ngscope to suit analog designer need, including update of plots on fly. So far it is possible to do through menu. If you have any interface in mind I may easy include it into my code. Additional features includes - choose any X-axis, equation driven interface, support for user defined functions library. I'm working on it adding new features. If you have some particular in mind - let me know please. Thanks, Alex. On 04/17/2011 01:15 PM, rickman wrote: On 4/4/2011 11:44 PM, Kai-Martin Knaak wrote: A.Burinskiy wrote: I did not saw satisfactory analog viewer for ngspice. Could you please send me a link or project name? Over the years several waveform projects have been tossed around on this list: gwavehttp://gwave.sourceforge.net/ gtkwave http://gtkwave.sourceforge.net/ KJWaves http://sourceforge.net/projects/kjwaves/ dataplot http://www.h-renrew.de/h/dataplot/dataplot.html When I had the need for an interactive waveform viewer that could also be driven by an application, I had good success with xmgrace http://plasma-gate.weizmann.ac.il/Grace/ It is fully scriptable and can produce publication quality plots, too. Would any of these be suitable for a real time update of an o'scope display? I'm just batting around some ideas and would like to find some software to base an o'scope UI on. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: zview/ngscope
On 4/4/2011 11:44 PM, Kai-Martin Knaak wrote: A.Burinskiy wrote: I did not saw satisfactory analog viewer for ngspice. Could you please send me a link or project name? Over the years several waveform projects have been tossed around on this list: gwavehttp://gwave.sourceforge.net/ gtkwave http://gtkwave.sourceforge.net/ KJWaves http://sourceforge.net/projects/kjwaves/ dataplot http://www.h-renrew.de/h/dataplot/dataplot.html When I had the need for an interactive waveform viewer that could also be driven by an application, I had good success with xmgrace http://plasma-gate.weizmann.ac.il/Grace/ It is fully scriptable and can produce publication quality plots, too. Would any of these be suitable for a real time update of an o'scope display? I'm just batting around some ideas and would like to find some software to base an o'scope UI on. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Spam Email to This List
I use a separate email address for this list and that address received a spam email. It doesn't look like that email came through this list, but rather the list was somehow harvested for email addresses and the message sent directly. Did anyone else get an email from s...@jxtpcb.com with the name Chinry? He is hawking PWB manufacturing. I've gotten messages from this same guy at other addresses, but this email address isn't used anywhere else at any time. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Spam Email to This List
On 4/13/2011 8:56 AM, ge...@igor2.repo.hu wrote: On Wed, Apr 13, 2011 at 01:02:40PM +0100, Andrew Seddon wrote: Yes I got this. OT: I'm new hear so please feel free to ignore this comment, but might it be worth switching to google groups or similar? The interface is nice and you can use it like a traditional mailing list if desired. Last year we tried that for challenge24 to remove some load from our servers during the contest. It works fine as long as you are using web and especially if you have google account, but for a plain, non-google user with email only it wasn't that good. I can not recall what exactly went wrong, but I remember we had to switch back to mailman running on our own server. I personally would be more happy to keep the mailing list private - of course I am not the one who contributes hosting, bandwidth or admin time. I hope this thread doesn't go on too long. I had received email from this guy at another address so I wasn't sure if the problem had something to do with my security or if he had harvested from this group. I guess it was the latter. I think there is a lot of private email sent as a result of things discussed on this list. So making the list private might not be the best way to handle the spam. In fact, I've only gotten one spam email from this list that I can remember so clearly the problem isn't very bad. That isn't why I posted about this. I respond to business related spam by asking them to call me. If they are lucky they get the answering machine. If they get me, I ask them a million questions about how they got my email address. That always seems to piss them off measurably. If everyone did this, they would soon change their thinking about sending spam for business purposes. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
On 4/7/2011 1:13 PM, Stephan Boettcher wrote: rickmangnuarm.g...@arius.com writes: I have to say I am philosophically opposed to any feature that allows a design to pass DRC when the layout differs from the schematic. Just to get the terminology right: DRC has no business to care about the schematics at all. There shall be a tool to check if the layout implements the schematics netlist, but that is a different issue. PCB implements this distiction properly. DRC checks consider coper structures as layed out when evaluating the rules, without regard to the netlist. The Rat's-nest (O-key) ignores DRC rules when checking connectivity. Ok, if you want to be pedantic the net list is not the schematic, but if the netlist differs from the schematic, then you have another problem. DRC is a part of my design process which includes a verification that the layout matches the net list. In fact, my number 1 design rule to be checked is that they match. What button I push to get the tool to do my required design rule checking is irrelevant. It is just a tool and does not define my process. So my point is that adding an attribute to any copper to tell the tool to ignore the connectivity violates my idea of design rule checking. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
On 4/8/2011 12:57 PM, Mark Rages wrote: On Fri, Apr 8, 2011 at 11:39 AM, rickmangnuarm.g...@arius.com wrote: On 4/7/2011 1:13 PM, Stephan Boettcher wrote: rickmangnuarm.g...@arius.comwrites: I have to say I am philosophically opposed to any feature that allows a design to pass DRC when the layout differs from the schematic. Just to get the terminology right: DRC has no business to care about the schematics at all. There shall be a tool to check if the layout implements the schematics netlist, but that is a different issue. PCB implements this distiction properly. DRC checks consider coper structures as layed out when evaluating the rules, without regard to the netlist. The Rat's-nest (O-key) ignores DRC rules when checking connectivity. Ok, if you want to be pedantic the net list is not the schematic, but if the netlist differs from the schematic, then you have another problem. DRC is a part of my design process which includes a verification that the layout matches the net list. In fact, my number 1 design rule to be checked is that they match. What button I push to get the tool to do my required design rule checking is irrelevant. It is just a tool and does not define my process. So my point is that adding an attribute to any copper to tell the tool to ignore the connectivity violates my idea of design rule checking. Rick Rick, your idea about DRC and the pureness of connectivity is wrong. Connectivity is insufficient for real world designs, which is the point of all this discussion. It's possible to have a design with perfect connectivity that doesn't work. Any analog or RF design, and a lot of high-speed digital designs, require a lot more attention than getting connectivity right. So the desire to tag certain nets / connections as controlled impedance, no DRC, equal trace length, etc. Regards, Mark markrages@gmail I don't know how you get from my statements to suggesting that I don't agree that tags should be used. Controlled impedance and equal trace length have nothing to do with what I said. If you have some portion of your design that you need to exclude from DRC, I would suggest that you need to adjust your design rules. It may be that the tool is not sophisticated enough to accommodate the needed design rules, but saying that it is desirable to exclude portions of a design from design rule checking is a very poor way of dealing with the limitations of a tool. I would much prefer to have the design rule violations reported and then allow the designer to sign off that these violations are not a problem. It can be too easy to make a mistake when excluding a design rule check and missing a violation that results in a problem. Too often people confuse the functionality of a tool with the process of verifying correctness of a design. I done't want a tool dictate my design rule process. If the tool has limitations, I prefer to have it report problems that I can then manually verify are not problems than to run the risk of missing problems that cost time and money. The problem of connectivity of nets can be handled without violating design rules. I do this using a part footprint that connects the two nets. This shows up on the schematic as the single connection point between the two nets, is reflected in the netlist as the only point of connection of the two distinct nets and can be verified in design rule checking that the nets are connected no where other than by this footprint. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
On 4/7/2011 5:34 AM, Kovacs Levente wrote: On Wed, 06 Apr 2011 22:37:05 -0500 John Griessenj...@ecosensory.com wrote: Yes, Levente's way of handling that after the fact is practical and what I like to do, since then you keep all your DRC's working against error, and have one more step to do after DRC complete. Perhaps that method could be scripted with a makefile? Can commands from a script make a layer invisible and not part of DRCs? If so, then the starpoint connecting copper could be on a special layer for that purpose alone, and merged in by using visibility or not. Yes. There is a patch which adds the ability to ignore DRC. http://archives.seul.org/geda/user/Mar-2011/msg00096.html Else merge it in with gerbv as RS274-X only. I don't like this idea. You have to have control over connections at least at PCB level. I'd have it in gschem level. Levente I have to say I am philosophically opposed to any feature that allows a design to pass DRC when the layout differs from the schematic. By allowing a connection on the PCB between two nets that are separate on the schematic, without warning, this can result in a disaster. I have seen expert PWB designers make a mistake that shorted two power planes that should not have been shorted because they were working manually, bypassing DRC. If such a feature is used, the DRC should at least flag a warning that a feature is being used that is not being checked, including all the info you would otherwise get if it were flagged as an error. I prefer to add a component to my designs that IS the short between two nets. I have a symbol in my library that has pads for jumper pins on 0.1 centers along with a connection between the pads. The schematic symbol shows that connection which is different from jumper pins that are by default open. This footprint can include the short between the pads on any layer, but it is not so sophisticated that it can be on an inner layer only. That would be ideal. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: US Distributor for Balloon Board
On 4/5/2011 7:46 PM, John Griessen wrote: On 04/05/2011 09:04 AM, Patrick Doyle wrote: Hi Rick, The GA144 sounds quite interesting for a very specific application that may be coming down the pike pretty soon, but I don't have any good killer app ideas for it. On Tue, Apr 5, 2011 at 9:47 AM, rickmangnuarm.g...@arius.com wrote: Does this sound interesting to you? I also have an interest in testing the Green Arrays GA144 multiprocessor. This device has 144 processors running at 666 MIPS each consuming less than a Watt with all running full bore. They are async processors and stop on a dime when waiting for input dropping power consumption to virtually nothing I'm on the GA144 interested list, but not a peep out of Greg Bailey since November when they were proposing bootstrapping by asking for preorders of 10 chips/$100. I believe the $100 is just the deposit and the total price is $200 per 10 chips. I expect the production price will be much less, but I don't know for sure. They have prototyped a GA4 and a GA32 I believe. These will certainly cost much less. They've been working with no income so far. I'm not in a position to gamble on seeing if colorforth/greenarray-forth runs on a linux box until they get flow... Many of C Moore's chip projects have stalled and never become a viable product. Hope this one does though. Heard anything since November? John Griessen They have been updating the web page periodically. They currently have received some thousands of chips and are in the process of developing tests. From Chuck Moore's blog, Here's GreenArrays' latest receipt of GA144 chips: 12 wafers; 14561 chips; 2,096,784 computers. I seem to recall that a wafer costs roughly $1000 to process and assuming close to 90% yield that would put the raw chip cost below $1 each for the GA144. I have confidence that they will develop useful chips. My concerns have more to do with the business aspects. There are a couple of issues about the company, for example, they should have a pretty clear idea of target applications. I have read little about this. I would also expect more app notes and even the fact that they received chips but are not ready to test them concerns me. It all rather reminds me of Ross Perot's run for the presidency. I hope I am wrong. I think these devices are unique in the computing world and may be the start of a new paradigm in embedded systems. BTW, this is rather off topic here. Perhaps anyone who wishes to continue this discussion should take it up in the comp.lang.forth newsgroup? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: US Distributor for Balloon Board
On 3/26/2011 8:50 PM, Patrick Doyle wrote: Hi Folks, I'm looking for a US distributor for a Balloon Board (http://www.balloonboard.org/) or it's equivalent -- perhaps one of you may have designed and sell your own equivalent. Basically, I'm looking for a standalone board with a processor (with it's associated flash SDRAM) and an FPGA. I'm not terribly picky about the FPGA -- any reasonable Xilinx or Altera device should suffice. Does anybody on this list have any recommendations? I would prefer to buy from a gEDA supporter, and it will be logistically easier if I can purchase from someplace in the US. Thanks for any pointers. --wpd Patrick, I don't see where you responded to any of the replies to your post. Did you find something that met your needs? I am considering laying out a design that would include a Freescale Kinetis device and an FPGA. I am in the US and this would be an open source design using open source tools. I haven't picked the details yet, but I have a preference for the Silicon Blue FPGAs. They only make small versions, but they are very, very low power which is my goal. I had not been planning to include external RAM, but the K60 has a DDR interface and can be included easily. I assume that if you need that much RAM it means you intend to run Linux on it. Is that right? I don't know if Linux is ported to the K60, but I expect it would not be at all difficult to do since the K60 is an ARM CM4 (CM3 + DSP and SIMD instructions). Does this sound interesting to you? I also have an interest in testing the Green Arrays GA144 multiprocessor. This device has 144 processors running at 666 MIPS each consuming less than a Watt with all running full bore. They are async processors and stop on a dime when waiting for input dropping power consumption to virtually nothing (100 nW per processor) able to resume processing at full speed in a fraction of a ns. They just need to identify a killer app and these devices will take off. The one aspect that may turn off a lot of potential users is the tiny on-chip memory, only 64 words in each processor. But external memory can be connected of course. This chip is not programmed in C, so you can do a lot more with very little memory. I think of it more like an FPGA than an MCU. A Field Programmable Processor Array, FPPA. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: transition of pcb internal units to metric (SI, mm)
On 2/8/2011 12:23 PM, Colin D Bennett wrote: On Tue, 8 Feb 2011 07:27:01 -0800 Edward Hennessyehen...@sbcglobal.net wrote: On Feb 7, 2011, at 10:41 AM, DJ Delorie wrote: * nanometer internal units * 32-bit values on 32-bit machines, 64-bit on 64-bit. * configure option for 64-bit values regardless of machine in case you need a board larger than seven feet across. What about storing both imperial and metric? This way, the measurements are ket separate until the very last moment when they need to be converted to one value. A metric element can be manipulated on screen in an imperial grid and no errors build up. What problem does this solve? It certainly makes things much more complex and will impact performance for no benefit. Exactly, it solves no problems. Working with 1 nm internal units preserves the exact inch dimensions down to 0.01 mil. Of course, this is convertible back in to inches with no loss of accuracy. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: transition of pcb internal units to metric (SI, mm)
On 2/8/2011 11:24 AM, Andrew Miner wrote: From: David Smith[1]dave.sm...@st.com Date: Tue, 8 Feb 2011 14:32:24 + I am not an expert on ASIC manufacture, but I think that you've made some incorrect assumptions there. Yes, the standard wafer at current cutting-edge processes is 300 mm (although for older and non-standard processes, smaller wafers are common); however, I don't believe that you'd be able to get a mask (a.k.a. reticle) set that would cover the entire surface of that wafer. A reticle will only cover a proportion of the wafer's surface, and to cover the whole wafer surface, the reticle will be used to expose the surface of the wafer repeatedly, using a piece of equipment called a stepper. Okay, I was not fully awake this morning, so I did make some mistakes. Yes the 300 mm wafers use steppers, and that is how they can get down to the 65 nm and finer resolutions. In that case you would have a small portion of the die image. I was still half asleep and thinking along the um scale technology we have at my (former) university with a 4 wafer line that uses a full 4 mask. There were some masks there that had many unique designs over the whole 4 mask (not just step and repeat), and we were able to fab those on wafers in house. One of the companies that currently offers this service is MOSIS [2]http://www.mosis.com/about/whatis.html and as I remember they did offer great prices for students as this albeit old pdf shows: [3]http://users.ece.gatech.edu/rincon-mora/research/mosis_submsn.pdf You would need to quote out current prices, but a student use to get a custom ASIC for as little as $3250. Commercial prices would be higher especially as you approach 90 nm or finer. Andy Minerhttp://www.seul.org/cgi-bin/mailman/listinfo/geda-user This is past the point of being silly. IC design was brought into this conversation to justify changing the tools to record dimensions down to picometer levels. None of this is a justification for that. To need picometers you would need to not only be willing to pay huge amounts for a mask set, far beyond anything even in production today, but you would need the capability of actually designing transistors with feature size resolution below 1 nm... in terms of the models. Then you will have to pay equally huge amounts to get such a device into the production line considering that such a fab will likely cost in excess of 10 billion USD with each wafer having equally high processing costs. Not to mention that no one is even thinking of working with standard devices and techniques at feature resolutions below 1 nm. It is really starting to look like we may not pass 10 nm for standard production chips. With all of that going on, do you really think there is even a remote justification for these tools using dimensions smaller than nm so that they can be used for advanced IC design? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New Column: From the CAD Library
On 2/7/2011 11:21 AM, Peter C.J. Clifton wrote: On Feb 7 2011, rickman wrote: The real question is does the current method cause any problems? When this was discussed a few months ago the answer was no. So why worry about 1 part in a million error? Engineering is all about tolerances. We do have some problems with rounding and 45-degree lines, but I'm not convinced metric units internally is a magic bullet for that. Display of accurate coordinate in metric IS a problem though. How so? I thought the dimensions in these tools are done with 10 microinch resolution. Isn't that enough for anything on the visible horizon? Actually, I wouldn't think the display is the problem, but rather the problem would be generation of rounded data for output such as Gerber files. What are people using this software for that requires better than 10 millionths of an inch accuracy? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: transition of pcb internal units to metric (SI, mm)
On 2/7/2011 2:04 PM, Colin D Bennett wrote: On Mon, 7 Feb 2011 13:41:12 -0500 DJ Deloried...@delorie.com wrote: Please don't start the discussion again; we already came to a reasonable conclusion last time. Sorry, I was trying to show that this thread is heading toward duplicating that discussion. * nanometer internal units * 32-bit values on 32-bit machines, 64-bit on 64-bit. * configure option for 64-bit values regardless of machine in case you need a board larger than seven Well, I understand your points above as being *exactly* what I just said. As I said before my comments, I was primarily trying to summarize the resolution of the prior discussion and the rationale in a productive way since it sounded like this thread was heading in the same direction as the previous discussion. So this present thread about using mm internal units is really going to be resolved when the nanometer-unit solution previously identified is actually implemented. Ok, so without discussing it again... I know that using metric internally is the optimal way to go, but if I understand it correctly, this is NOT what the current software does and there are NO plans to change any of it. Is that correct? Are there any issues significant enough to justify actually changing the software? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: transition of pcb internal units to metric (SI, mm)
On 2/7/2011 4:05 PM, Markus Hitter wrote: Am 07.02.2011 um 19:37 schrieb Colin D Bennett: This has been discussed on the list before and the proper answer is to use 64-bit integers representing length in nanometers. Isn't a nanometer pretty big when doing chip design? Others might have more/any experience in this area. No, you have a misapprehension. The finest devices in production today are on the order of 20 nm. That will decrease, but not too much further. If not limited by physics, by economics. From Wikipedia: The cost to [1]tape-out a chip at 90 nm is at least US$1,000,000 and exceeds US$3,000,000 for 65 nm.^[2][40] Do you expect these tools to be used to design chips costing far, far over $3 Million just for the mask set? Rick References 1. http://en.wikipedia.org/wiki/Tape-out 2. http://en.wikipedia.org/wiki/Moore%27s_law#cite_note-39 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New Column: From the CAD Library
On 2/6/2011 10:24 AM, Peter Clifton wrote: On Sun, 2011-02-06 at 10:55 +0100, Bert Timmerman wrote: One of Tom's issues that is to be kept in pcb are most of the mil grids because of the bazillion perf board and mil based parts on the market, to be bought for cheap by hobby-ists, or for Quick-and-Neat proto boards (we don't play or do dirty ;-). Just my opinion on the subject. Imperial parts are not a problem for a sufficiently fine metric grid. I don't think we should remove the option of working on a Mil grid though. I do it most of the time, even though I realise it is a habit best got out of. I don't think you understand the intent. I don't think anyone is suggesting any changes to what a user sees. The issue is what base units are used internally and in libraries. By using metric values, imperial (is that really the right term?) measures (aka inches and mils) can be represented and calculated with no loss of precision. However, when inch type units are used as the fundamental measurement, it can be harder to get adequate precision to represent metric units. 1 inch = 25.4 mm... exactly 100 mm = 3.937007874016... sort of. In reality if you use enough precision in the base units you can always get close enough which is what engineering is about. But some folks have an issue with not working in the best possible manner. I'm not sure this is really an issue. There would be significant pain making the change now. If the change is to be made at a later time, will it really be any more painful? So if there is no significant reason to switch and the pain does not increase if delayed... why bother with it now...? Way forward: Metric nm grid internally, parts defined in whatever units the vendor's controlling dimensions are in. This might require relative origins to be used between the part design coordinate and the board's snap-grid, but that seems to be mandated by various IPC standards anyway. Parts should match the rest of a system I think. The dimensions of a part can be stored in the units that best suit the system. It seems silly to store a part as metric and let the system round it off to inches on the fly rather than to do the round off when the part is created. But that's just my opinion. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Thermals on Pads
On 1/30/2011 4:47 PM, Martin Kupec wrote: On Sun, Jan 30, 2011 at 04:37:17PM -0500, rickman wrote: What geometry problems do you have? There are plenty of references in regard to thermals. I don't recall seeing any other than bridges that span a uniform gap around the pad. The only variation I can recall is the number and rotation angle of the pattern. But most, if not all that I have seen use four bars either along the x and y axes or at 45 degree angles. I think there are even some built in commands for this in the RS-274X Gerber file spec. Or am I missing something? We already do support bridges with rounded corners. And what we do not support is anything suitable for TSOP package pads(long thin pads near to each other). But the big problem with you current implementations is the size of the bridges. The size is somewhat magicaly calculated from the size of pin and from the size of clerance. But this is neighter working nor probably right. With big clerance the shape becomes completly bogus(at least for the rounded versions). That surprises me that the bridge width would be calculated rather than specified. What's the idea behind that? Isn't it a simple matter to let the designer pick the dimensions both for the width of the bridge and the width of the clearance? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Thermals on Pads
On 1/31/2011 10:33 AM, Martin Kupec wrote: On Sun, Jan 30, 2011 at 11:13:27PM -0500, rickman wrote: On 1/30/2011 4:47 PM, Martin Kupec wrote: On Sun, Jan 30, 2011 at 04:37:17PM -0500, rickman wrote: What geometry problems do you have? There are plenty of references in regard to thermals. I don't recall seeing any other than bridges that span a uniform gap around the pad. The only variation I can recall is the number and rotation angle of the pattern. But most, if not all that I have seen use four bars either along the x and y axes or at 45 degree angles. I think there are even some built in commands for this in the RS-274X Gerber file spec. Or am I missing something? We already do support bridges with rounded corners. And what we do not support is anything suitable for TSOP package pads(long thin pads near to each other). But the big problem with you current implementations is the size of the bridges. The size is somewhat magicaly calculated from the size of pin and from the size of clerance. But this is neighter working nor probably right. With big clerance the shape becomes completly bogus(at least for the rounded versions). That surprises me that the bridge width would be calculated rather than specified. What's the idea behind that? Isn't it a simple matter to let the designer pick the dimensions both for the width of the bridge and the width of the clearance? I would not argue against it. So shall we change the code in a way, that older files gets current calculation and newer ones has thermal specification in file? This opens discussion how/what to specify. Martin Kupec Is there a way to support both compatibly? If the data is to be specified, it will need to be stored in the design file. If that info is there, use it, if the info is not present let the software determine the values be used? I would think the only issue is determining a file format that would allow the info to be optional yet compatible with existing formats without the info. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Alternate Platforms
On 1/30/2011 9:58 AM, Bob Paddock wrote: Still - most places I went to do a repair, I'd want to take a laptop or at least a tablet. Getting out that remote without a computer seems like as well thought out as going to do said repair and forgetting to pack your soldering iron. Some places like Coal Mines (Been there, to many times), and Military Installations (Horror stories from colleague doing that now) etc. have very restrictive policies on what you can bring with you. The list of allowed devices often excludes cell phones with cameras! Still, something smaller than a laptop can be very useful. When I am with a customer it is frequently a problem finding a spot to place a laptop. A pad device would really be useful if it supported proper software. Maybe I am stuck in a rut, but I see things as heading in that direction. At one time I thought a laptop was a luxury and now I won't be without it. I can see a pad replacing my laptop under most situations. There is nothing that says you can't connect a mouse and keyboard for desktop type work is there? On occasion I connect a second monitor to my laptop. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Thermals on Pads
On 1/30/2011 3:39 PM, Peter Clifton wrote: On Sun, 2011-01-30 at 21:12 +0100, Martin Kupec wrote: On Sun, Jan 30, 2011 at 12:54:23PM -0700, asom...@gmail.com wrote: I'm a novice to the pcb code base, and I couldn't find much developer documentation, but I am willing to try to add this feature. I need a little help though: the pcb code base is too large for me to grok all at once. Could someone please tell me where to start? What would I have to modify to allow this? Actualy, there already is a patch. It can be found here: https://bugs.launchpad.net/pcb/+bug/699495 This patch has some issues as mentioned in the bug report, but it should be usable. I am willing to fix and extend the patch, but I do have exams period(or how is the english word for it) :-( I should be on that issue in few weeks(like 2-3). I've been looking at some brokenness with our normal thermal shape generation recently, so if I get a chance I could look at your patch - and possibly work from it. The main problem I have is not code, but deciding what such geometry needs to look like it and how to specify it. Whatever we decide we have to live with, as we can't go changing geometry on users with existing boards. That is the problem I'm hitting now. Harry's clipper branch (a long time ago) without comment, changed the thermal generation formulas in (IMO, a retrograde way). I can't change it back (or fix the geometry calculation) for fear of possibly breaking all the users who have made boards since then. What geometry problems do you have? There are plenty of references in regard to thermals. I don't recall seeing any other than bridges that span a uniform gap around the pad. The only variation I can recall is the number and rotation angle of the pattern. But most, if not all that I have seen use four bars either along the x and y axes or at 45 degree angles. I think there are even some built in commands for this in the RS-274X Gerber file spec. Or am I missing something? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On 1/26/2011 12:34 PM, Stephan Boettcher wrote: Peter Cliftonpc...@cam.ac.uk writes: On Mon, 2011-01-24 at 07:48 -0800, Ouabache Designworks wrote: The special symbols is supposed to fuse netnames as issued on the netlist, not labels on the schematic. --- If you are also fusing the copper on the board then I would kind of like to see that when I am viewing the schematic. You want to give the user a choice. If I pull up a component view then I want to see the signal names from the original designer. If I am traversing a hierarchy and open an instance view then I want to see the signal names that match the names in the parent instance. John Eaton For a loop antenna, for example, the solution needs to be in PCB.. allow footprints / functional groups which implement RF components by placing copper on some layer. For me, this raises a very interesting design question: How do I go from abstract inductor / transmission line / (capacitance even?) representations on a schematic, to correctly DRC'd board layout? This will probably require an additional tool. The tool needs to extract the properties of the wiring from the layout via some techology file that describes the properties of the board materials (layer stack, etc). The schematic will have attributes on nets that spec what to check for. IMHO, net segments should be explicitly marked with the short-symbol that was discussed. A gnetlist backend will provide a netlist to the verification tool that includes the attributes and net segments. The PCB gnetlist backend merges the net segments. How to split out the net segments during extraction is probably not easy. The inductor will end up as a shaped piece of copper tracking, and at this point, you realise that net is a very DC term! The inductor could be a subschematic with shorted pins via two short symbols, with a net in between that asks for an inductance check of some sort. We would need to have some way to demarcate the start and end of the inductor in PCB, or to draw it on a layer, or with an attribute which causes the copper making up the component to be disjoint from either net connecting to that section. That piece of board layout becomes a component, not an interconnect between components. The DRC could be told to treat certain layers in a group as component copper. One might imagine a similar method being useful to join two hierarchically shorted nets together... have a link component which joins AGND and DGND, which is implemented by copper drawn on the board between those two power planes. This would then allow preservation of important DRC checks such as making sure the correct plane / return path is used for signals. I guess I am missing something significant with this. Why wouldn't the inductor just be a component on the schematic and a component in layout just like any other inductor? The only difference is that the footprint defined for the component would be the copper that makes up the antenna. It would have a pad on each end for the signal connection. Is arbitrary copper in a footprint not supported? As to DRC, I would think design of an antenna would be a pretty complex thing to analyze automatically. A 3D field solver comes to mind. Is any of that capability currently interfaced with these tools? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb: possible to have multiple silk layers?
On 1/26/2011 1:23 PM, Colin D Bennett wrote: Is there any way to set up multiple silk screen layers in pcb? The idea is that I want to be able to turn off display of the extra text/graphics on the silk layer that I have added to the board, but still be able to see the component outlines. For the same purpose I also wish we could group objects together https://bugs.launchpad.net/pcb/+bug/699592 so that my imported text/graphics I add to the board (output from pstoedit, which are composed of many separate polygons) can be easily moved, rotated, or deleted as a unit. A trick that I use is to put extra stuff on a copper layer. This layer can be turned on and off easily. When I make the board, I just toss the Gerber file of that layer. In your case, this extra copper layer can have just the outlines and the silk will have the full outlines and text. Then the full silk layer can be turned on and off while working, but it is what will be printed to the board as the silk layer. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On 1/26/2011 1:42 PM, DJ Delorie wrote: the footprint defined for the component would be the copper DRC sees that as a short circuit, not an element DRC will complain if pads are touching? Can you create arbitrary shaped pads? But they can't touch each other Do you have a way of creating jumper components, two through pin pads connected by narrow copper? I use these often in my projects. Default is connected, but as an option the trace can be cut. Once the narrow trace is cut, a jumper block can be added and the pads reconnected if needed. The antenna could work the same way. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On 1/26/2011 1:55 PM, DJ Delorie wrote: Sure, you can use pads to make arbitrary traces in your element. But, you must also connect the two pins in the schematic, or DRC will complain about a short circuit. Once the nets are shorted in the netlist, it's not always easy to figure out which connections go to which side of your antenna Then I think the answer is no, at least I really wouldn't want to do that. I've never seen a layout package that checks for connectivity between pins *inside* a footprint. Actually, I guess the stuff I use doesn't check copper for shorts. It will not let you make trace connections between nets. Then it also checks the DRC spacings of traces, clearance around copper areas, etc. But I don't think shorts are checked exactly and I know pads within a part are not checked for spacing. I would think the pads of a footprint would not be checked against one another with the same rules as traces. Is that what you are saying? Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On 1/26/2011 7:00 PM, Stephen Ecob wrote: A similar track is component scenario: PCB fuse track - a dirty trick I've seen in some Honywell boiler controllers.. where a deliberately thin trace is used to act as a fuse. That certainly is a dirty trick! (But on a very tight budget it could make sense). So there are several use cases for treating copper as non-connecting: * low value resistors * fuses * low value inductors * aerials * contacts for solder switches (eg SPDT in solder) Similar to the last is a jumper location that is connected by copper by default to be cut if an open is needed. Consider this to be a 1 bit PROM. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
On 1/26/2011 3:50 PM, Peter Clifton wrote: On Wed, 2011-01-26 at 13:33 -0500, rickman wrote: I guess I am missing something significant with this. Why wouldn't the inductor just be a component on the schematic and a component in layout just like any other inductor? The only difference is that the footprint defined for the component would be the copper that makes up the antenna. It would have a pad on each end for the signal connection. Is arbitrary copper in a footprint not supported? Not currently supported. PCB would also need to treat that copper differently in its own connectivity scanning code, otherwise it would merrily extract the whole DC-connected netlist (shorting either side of the inductor). As to DRC, I would think design of an antenna would be a pretty complex thing to analyze automatically. A 3D field solver comes to mind. Is any of that capability currently interfaced with these tools? Perhaps I was going a bit far to suggest full DRC for the actual antenna design. What I really meant was not loosing information for net connectivity checking leading up the antenna. I agree 100%. Having to combine nets in layout that are not combined in the schematic netlist sounds like a bad idea to me. I don't plan on designing any antennas in the near future (or the far future), but I often use the trace connected jumper positions. I would like to be able to do that without mucking about the netlist. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
