[note: cross posted to multianalyzer group and piclist]
>I agree with you. It sounds like the project is getting an impossible list
> of features before design even starts. The way it's going, it will never
> get off the ground because people will get overwhelmed and lose interest
> as
> month go by with no real progress.
>
> I'd like to see a fairly basic model working before even attempting adding
> frills. Things like ethernet will add complexity while not adding
> anything
> useful. Insanely high sampling rates will make every aspect of the design
> needlessly difficult and expensive.
>
> The project sounds very interesting to me and I did join the yahoo group.
> It's very disappointing to see it running into these problems already.
>
> Jason
I am getting a little nervous myself that few have stated a willingness to
work on this project. There seem to be plenty of people who are waiting to
see how it goes, with hopes of building one once it is working.
As far as 'rampant featuritis' is concerned, I think we are avoiding that
pretty well. We *are* making an effort to make the design flexible enough to
support more in the future, but a minimum implementation isn't really all
that complex.
At this point, the design includes both USB 1.1 (via FTDI chip) and
Ethernet. It is likely that the initial implementation will not support
Ethernet, although first prototypes should include the hardware.
As far as sample rate is concerned, that largely depends on what kind of
FPGA and/or analog talent we can get. I expect that our initial system will
be quite a bit slower than 100MS/s. However, for this to be useful to many
of those who are interested in it (including myself) it needs to be a lot
faster than 100KS/s. I'd personally be pretty happy with 10MS/s.
> >I agree with you. It sounds like the project is getting an impossible
list
> > of features before design even starts. The way it's going, it will
never
> > get off the ground because people will get overwhelmed and lose interest
> > as
> > month go by with no real progress.
I do not thing that it is that bad at all... It is more complex than I
would want also but not impossible at all... We just need 2 more people
working actively at it and we can finish it in 1 or 2 months ! We need a
experienced FPGA guy and a good analog enginner to make the high speed front
end.
> > I'd like to see a fairly basic model working before even attempting
adding
> > frills. Things like ethernet will add complexity while not adding
> > anything
> > useful. Insanely high sampling rates will make every aspect of the
design
> > needlessly difficult and expensive.
I also thought that in the beggining but 100 Msps is not all that hard,
except in the front end and 10 Msps would be quite easy to achieve.
> > The project sounds very interesting to me and I did join the yahoo
group.
> > It's very disappointing to see it running into these problems already.
Please come back and help us make it happen... What is your area of
expertise ? We can use more hands for sure. We will always have people
saying that they want to go to the moon when we talk about open projects. It
does not make that much difference in pratical terms. We only need a group
of 5 to 10 people effectively working to make this thing really happen in a
short time frame. Please join us in the effort..
> I am getting a little nervous myself that few have stated a willingness to
> work on this project. There seem to be plenty of people who are waiting to
> see how it goes, with hopes of building one once it is working.
We have 67 members at the group and if it's basically Bob's project up
to now... And Gus... If the speeds were slower I could help more but 100's
of megahertz is not the kind of speed I can handle easily with my
knowledge.. And I do not work with FPGA's and use AVR's and not PIC's.. But
I will help with the "phisical" design of the board and schematics.. I was
not under the impression that we would have a whole bunch of people actively
working on the design. I was really just hoping for 5 to 10 people and that
is enough.. Too many people on the same project is not worth it.
> As far as 'rampant featuritis' is concerned, I think we are avoiding that
> pretty well. We *are* making an effort to make the design flexible enough
to
> support more in the future, but a minimum implementation isn't really all
> that complex.
Let's hope we can keep it that way... We have a simple way of dealing
with it. If anyone want's a feature we can let them design it in....
> At this point, the design includes both USB 1.1 (via FTDI chip) and
> Ethernet. It is likely that the initial implementation will not support
> Ethernet, although first prototypes should include the hardware.
We are pretty much "sane" on that. The PC interface is growing nicely.
> As far as sample rate is concerned, that largely depends on what kind of
> FPGA and/or analog talent we can get. I expect that our initial system
will
> be quite a bit slower than 100MS/s. However, for this to be useful to many
> of those who are interested in it (including myself) it needs to be a lot
> faster than 100KS/s. I'd personally be pretty happy with 10MS/s.
If we are satisfied with something between 1Msps and 10Msps I thing I
can jump in and try to design the analog front end.. At those speeds I think
the 74HC4052 still work and the AD converters are much less "exotic". If no
one else jumps in to do the FPGA and analog front end I think I can handle
those speeds with a LPC2104 and quite "normal" op-amps and multiplexers at
the front end.. At 100Msps I would not even try..
For the people listening... We still need a good analog guy and a FPGA
guy...
> I do not thing that it is that bad at all... It is more complex than I
> would want also but not impossible at all... We just need 2 more people
> working actively at it and we can finish it in 1 or 2 months ! We need a
> experienced FPGA guy and a good analog enginner to make the high speed front
> end.
Isn't this a bit like wanting to build a race car but needing a good
engine guy and a good chassis guy? Perhaps I'm confused, but those
seem like the two largest and most critical pieces of the whole
project.
> > I do not thing that it is that bad at all... It is more complex than
I
> > would want also but not impossible at all... We just need 2 more people
> > working actively at it and we can finish it in 1 or 2 months ! We need a
> > experienced FPGA guy and a good analog enginner to make the high speed
front
> > end.
>
> Isn't this a bit like wanting to build a race car but needing a good
> engine guy and a good chassis guy? Perhaps I'm confused, but those
> seem like the two largest and most critical pieces of the whole
> project.
Not quite.. We are all engineers and we can search, find references,
simulate, prototype and do both the analog front end and the FPGA stufff but
for a open source project it makes more sense to look for someone that can
do it faster and better because of bigger experience in the specific area.
It is a matter of spending 10 hours with the right person or 100 with less
experienced people. The most time consuming part on the project is protocol,
communications and PC program and we are making good progres there.
I will start to prototype a input circuit and see how it goes. But I
would still preffer someone with more hands on high speed analog
experience....
> Hi,
>
> > > I do not thing that it is that bad at all... It is more complex than
> I
> > > would want also but not impossible at all... We just need 2 more people
> > > working actively at it and we can finish it in 1 or 2 months ! We need a
> > > experienced FPGA guy and a good analog enginner to make the high speed
> front
> > > end.
> >
> > Isn't this a bit like wanting to build a race car but needing a good
> > engine guy and a good chassis guy? Perhaps I'm confused, but those
> > seem like the two largest and most critical pieces of the whole
> > project.
>
> Not quite.. We are all engineers and we can search, find references,
> simulate, prototype and do both the analog front end and the FPGA stufff but
> for a open source project it makes more sense to look for someone that can
> do it faster and better because of bigger experience in the specific area.
> It is a matter of spending 10 hours with the right person or 100 with less
> experienced people.
Fair enough! It certainly makes good sense to spend a little bit of
time finding a good person before spending a lot of time learning
yourself.
> The most time consuming part on the project is protocol,
> communications and PC program and we are making good progres there.
I was actually going to comment on this, as this is likely going to
require the largest amount of development time.
Has anyone considered using a PIC-based setup for a simple, low-speed
version that would implement the full control protocol? This would
allow the PC programmers to begin work on control software that could
proceed in parallel with the more difficult analogue/FPGA/fab stuff.
> > The most time consuming part on the project is protocol,
> > communications and PC program and we are making good progres there.
>
> I was actually going to comment on this, as this is likely going to
> require the largest amount of development time.
>
> Has anyone considered using a PIC-based setup for a simple, low-speed
> version that would implement the full control protocol? This would
> allow the PC programmers to begin work on control software that could
> proceed in parallel with the more difficult analogue/FPGA/fab stuff.
That is exactly how we are dealing with it.. Bob is doing the PIC and
protocol definitions and as soon as people are satisfied with it I will make
the boards and everybody can jump to make the PC side of things work. In
parallel I will be experimenting with the front end design to see how hard
that will be... And, also in parallel, we are trying to find more people to
help in the project...
> Has anyone considered using a PIC-based setup for a simple, low-speed
> version that would implement the full control protocol? This would
> allow the PC programmers to begin work on control software that could
> proceed in parallel with the more difficult analogue/FPGA/fab stuff.
Actually, I expect that I will be able to get the MHI portion of the MA
project working without having to have any other components. This will allow
me to develop its interface with the host, and for me and/or others to get
the host programs well along.
Who knows, maybe I'll even have the MHI able to do some slow sampling on its
own so that we would have a low-end solution.
> the boards and everybody can jump to make the PC side of things work. In
> parallel I will be experimenting with the front end design to see how hard
> that will be...
Since I don't (and won't) participate in anything Yahoo-based, what is the
bandwidth you desire for the frontend? Does the project have a non-Yahoo
web page?
> > Has anyone considered using a PIC-based setup for a simple, low-speed
> > version that would implement the full control protocol? This would
> > allow the PC programmers to begin work on control software that could
> > proceed in parallel with the more difficult analogue/FPGA/fab stuff.
Alexandre Guimaraes replies:
> That is exactly how we are dealing with it.. Bob is doing the PIC and
> protocol definitions and as soon as people are satisfied with it I will make
> the boards and everybody can jump to make the PC side of things work. In
> parallel I will be experimenting with the front end design to see how hard
> that will be... And, also in parallel, we are trying to find more people to
> help in the project...
Ok, you've convinced me to join the group. ;-) Even if the high-end
stuff gets delayed, it sounds as if the "development tools" for the
project may be exactly what many of the people here are really looking
for...
> > the boards and everybody can jump to make the PC side of things work. In
> > parallel I will be experimenting with the front end design to see how
hard
> > that will be...
>
> Since I don't (and won't) participate in anything Yahoo-based, what is the
> bandwidth you desire for the frontend? Does the project have a non-Yahoo
> web page?
We have not made another webpage but if you want to join I can arrange
to send you all the files by email or put them up somewhere else.. Yahoo is
just a convenient and cheap way to get this things rolling...
We are aiming at doing 100 Msps at the AD converter and it would be nice
to have somewhere between 80 Mhz to 1 Ghz bandwitdh at the front end.. The
higher we go the more we have chances of implementing repetitive sampling to
get higher than 50 Mhz signals. The essential would be 50 Mhz bandwidth. It
would be nice to have attenuators at 2, 5 and 10 times to make the viewing
nice and make better use of the 8 bits converter.
> Ok, you've convinced me to join the group. ;-) Even if the high-end
> stuff gets delayed, it sounds as if the "development tools" for the
> project may be exactly what many of the people here are really looking
> for...
I'm in about 17 of them at last count and they are some of the best
technical resources I have for several different areas of interest.
Some people cite privacy or spam issues. I use throwaway email
adressess just in case and gave them no personal info when I signed up.
I also get *zero* spam from them.
Just curious...
Matt Pobursky
Maximum Performance Systems
On Tue, 28 Sep 2004 12:47:26 -0700 (PDT), Bob Blick wrote:
> Since I don't (and won't) participate in anything Yahoo-based, what
> is the bandwidth you desire for the frontend? Does the project have a
> non- Yahoo web page?
I've been watching this discussion with interest but held off
commenting until I got a good feel for the direction things were going.
As background, I have a TEK 2232A Analog/Digital sampling scope and a HP/Agilent 54645D mixed signal scope. They each have their strengths and weaknesses, but both are excellent tools. Ideally, I'd love to have a cross between the two. The TEK has a higher sampling rate, but very
little sample memory. The HP has deep sample memory, 2 analog/16
digital channels and phenomenal triggering capabilities but could use a
higher sample rate.
On Tue, 28 Sep 2004 07:08:46 -0400, Bob Ammerman wrote:
>
> I am getting a little nervous myself that few have stated a
> willingness to work on this project. There seem to be plenty of
> people who are waiting to see how it goes, with hopes of building one
> once it is working.
I might consider working on the project, but all of a sudden my
consulting work has taken off (a nice problem after about 18 months of
hit and miss business).
> As far as 'rampant featuritis' is concerned, I think we are avoiding
> that pretty well. We *are* making an effort to make the design
> flexible enough to support more in the future, but a minimum
> implementation isn't really all that complex.
>
> At this point, the design includes both USB 1.1 (via FTDI chip) and
> Ethernet. It is likely that the initial implementation will not
> support Ethernet, although first prototypes should include the
> hardware.
The USB and Ethernet hardware should be pretty much cut 'n paste. The ethernet software could be fun, although if you stick with something
simple like UDP it should be straightforward and not overly burden the
PIC (and that's always a killer with a PIC and ethernet).
I'd definitely use the biggest 18F PIC possible. You can't have enough I/O pins and memory for this application. CPU cost is pretty much
irrelevant in the overall scope of an instrument like this.
I'd look at using the FT245 on the PIC side -- I've found it's about 10
times faster than the FT232. You also save your USART for other useful
things...
> As far as sample rate is concerned, that largely depends on what kind
> of FPGA and/or analog talent we can get. I expect that our initial
> system will be quite a bit slower than 100MS/s. However, for this to
> be useful to many of those who are interested in it (including
> myself) it needs to be a lot faster than 100KS/s. I'd personally be
> pretty happy with 10MS/s.
This is an area I have strong feelings about, based on personal experience. My HP scope (which is the best and most useful tool I've ever owned!) is great in regards to number of inputs and triggering. The usefulness of deep sample memory can't be overstated. The one fault I have with the 54645D is the sample rate. 200MS/s is fine for 4MHz or less microcontroller work, marginal for 10-16MHz and woefully inadequate for 20MHz+.
Whenever I want to look at an edge/transient type signal I break out
the TEK scope with much higher sample rate (but much much less sample
memory).
You really need to have about 20x samples/sec of your frequency of
interest (or edge rate) if you want to see useful information. And that
only gives you 10 sample points over your period of interest. Trying to
measure the rise time or ringing of a 10MHz clock signal at 200MS/s is
marginal and pretty much worthless at anything above that.
On the logic analyzer side, 200MS/s will only get you about 10nS glitch
capture capability. 10nS glitches (or faster) are something you'd
really want to see with today's logic families and clock rates as they
can play hell with your circuits and NOT being able to see them could
cause lots of lost hair in debugging.
One thing I've learned about DSO's is a feel for when they are "fooling
you" and not displaying what's really there. The higher the sampling
rate and deeper the memory, the less you'll be fooled.
Well, those are just some of my thoughts, I would love to see your
group develop a reasonably priced instrument that could be built as a
kit. I would certainly be interested in one to supplement my existing
tools. As much as I love my HP mixed signal scope, I realize most
people can't afford the $3500-$5000 they cost and frankly they
shouldn't cost that much even though they're worth it... ;-)
> Why the strong bias against Yahoo groups?
>
> I'm in about 17 of them at last count and they are some of the best
> technical resources I have for several different areas of interest.
>
> Some people cite privacy or spam issues. I use throwaway email
> adressess just in case and gave them no personal info when I signed up.
> I also get *zero* spam from them.
It's completely a privacy issue. SBC and Yahoo are a team, and they are
working hard. Fake names do not fool them - they can distill it and track
it with their extended partnerships with ad placement companies.
David Lazarus had a good series of articles about SBC at sfgate.com a
while back. I will not get a yahoo email account or subscribe to one of
their groups. I don't want a gmail account either!
Until they start paying me - I saw a web page with approximate costs for
personal information :)
>Whenever I want to look at an edge/transient type signal I break out
>the TEK scope with much higher sample rate (but much much less sample
>memory).
In the way I see this we are working at a scope to solve everyday
problems and not those "crazy" transient that drives us nuts when they
happen.. For that we will still need Tek, HP and Gagescopes. The idea is to
have a tool for "usual" problems and as a software debugging aid.
>Trying to
>measure the rise time or ringing of a 10MHz clock signal at 200MS/s is
>marginal and pretty much worthless at anything above that.
Those things will still need a "professional" scope. 100 Msps is not
enough for that... That is why I would be satisfied with a 1Msps scope... I
already have a 200 Msps available :-) The small one would be the one to be
taken on the Notebook case everywhere...
>
>It's completely a privacy issue. SBC and Yahoo are a team, and they are
>working hard. Fake names do not fool them - they can distill it and track
>it with their extended partnerships with ad placement companies.
> I'd look at using the FT245 on the PIC side -- I've found it's about 10
> times faster than the FT232. You also save your USART for other useful
> things...
Hi Matt,
Yes, I'm so smitten with the FT245BM! I'm really impressed with it.
You can even go wild with the fairly recent FTDI FT2232C chip -- 1/2 of it
would be dedicated to programming the PIC in-circuit using its Multi
Protocol Synchronous Serial Engine (MPSSE) and low-voltage programming for
upgrading firmware without a bootloader. The other 1/2 of the FT2232C would
be used to implement the '245 parallel interface. I have not played with the
FT2232C yet, but it looks like a killer part.
> Matt Pobursky wrote:
>
> > I'd look at using the FT245 on the PIC side -- I've found it's about 10
> > times faster than the FT232. You also save your USART for other useful
> > things...
>
> Hi Matt,
>
> Yes, I'm so smitten with the FT245BM! I'm really impressed with it.
FTDI's serial parts are great, but I'm still interested in IEEE 1394.
With 400 Mbps isosychronous (sp?) transfers it should be able to do
continuous sampling 8bit A/D at 50 MS/s. Sure, two channels would bring
that down to 25 MS/s, and adding 16 bits of LA would drop it further to
~12MS/s. 10 MS/s is still adequate for my needs.
The real upside is the digital hardware mostly goes away, just a clock and
a handful of logic to multiplex the data. Memory, address gen, triggers,
pre & post trigger counters, all move to PC software. Wouldn't even need
variable sample rates, just sample as fast as possible all the time and
have the PC software throw out anything you don't want.
All depends on finding a suitable 1394 interface solution... (suggestions
welcomed)
>I will start to prototype a input circuit and see how it
>goes. But I would still preffer someone with more hands
>on high speed analog experience....
You may want to have a look at the issue of Elektor that has just come out.
Has a FET follower probe which is claimed to go to about 1GHz. May even give
you some idea of how to do the input front end circuitry.
However I suspect that what you are looking at doing here is the area where
most scope development is done - the analogue front end and input
attenuator. The effort involved in keeping that with a flat frequency
response over a wide attenuation range is not trivial.
For the project to get off the ground, I would suggest that from the ADC
backward, i.e. the conversion and digital circuitry, it should be possible
to make a real high speed system quite readily. However do the analogue
circuitry as a separate piggy-back board, with a low speed one initially
(say 10-20MHz capable - something you could use around a PIC) and then later
do an all-singing dancing version capable of pushing the ADC and digital
circuitry to its limits.
This gives the project an easy and rapid start up point, which most people
would be able to build, and then if people want to go further with exotic
devices, and feel they are up to building and calibrating it, then they can
go further as time and money allow.
The conversion side looks like it should be easily done. Analog Devices seem
to send me a sheet every month with yet more higher speed, more accurate
devices in it, and with large fast memory around, with an FPGA to handle the
interfacing, the data capture side wouldn't be too difficult. Maybe someone
needs an 18F USB pic for the PC interface :) Are they being sampled yet?
