| Pages:
1
2
3
4
5
6
..
12 |
12AX7
Post Harlot
Posts: 4803
Registered: 8-3-2005
Location: oscillating
Member Is Offline
Mood: informative
|
|
My guess is somewhere between 1 and 50W for drive. Maybe more for big samples? The actual absorbed power should be extremely small, which suggests
high VSWR. Ugly. Still, not hard to do at a single frequency, with a single load, with a reasonable RF transistor and some other junk (oscillator,
driver, pulse gate).
An MCU is marginal but sufficient for pulse generation (~microsecond timing). An analog timer (set by DAC) would have a much finer range, and perhaps
less repeatability, but a well designed one could easily have even less jitter than the MCU pins.
A small MCU isn't a good idea for DSP, not one that isn't intended for DSP anyway. Just for bandwidth purposes, I would suggest a DSP-something, or
something ARM level (AVR32, DSPic, ARM, etc.). Something with enough RAM to buffer things, while writing data to external buffers as needed (you
could easily tack on a 1M SRAM and not care about RAM anymore, downside is you can only access it through routines, since you have to drive the bus
interface from I/O pins).
Quote: Originally posted by not_important  | | Uh, Tim, did you notice the text about the sound card I commented on came from un0me2 , and it said "why can't it be used to synthesize (or
alternatively simply play) a prerecorded pulsed signal" Ditto regards the programmable oscillator, and RF front end comments. By the time you
add in the outboarded PLL and other stuff, you might as well go with a DDS chip. |
Yes, if you demand an adjustable local oscillator, you might as well DDS it. Otherwise, it can be straight through with a fixed ratio.
As for the sound card, notice the maximum sample rate is 44kHz (maybe 48 or 96 on the fancy ones). A 1us pulse requires a 1MHz sample rate, so that's
obviously out of the question. Besides, the step response of a sound card is particularly awful, most of them anyway, due to the Nyquist filter.
(How this is implemented may be tantalizing, but good luck hacking the soundcard to use oversampling directly and avoiding the filter.)
| Quote: Originally posted by arsphenamine |
Soundcards and USB:
If you up-convert by enough Hz to get out of the way of a soundcard's AC
input coupling, then remove the upconversion digitally, a consumer grade
soundcard can be plausibly used. |
YES!!
So you downconvert it to 1kHz (not 0) and FFT that. Ignore all the bins under 1k and over 1.5k or whatever (give or take any strange ppm's you're
looking for). You need a relatively large number of samples, because of all those bins you don't care about. You need enough to give sufficient
resolution in the band of interest. Offhand, 0.1ppm at 40MHz is 4Hz, or at least 250 bins / 1kHz. At 11.025kHz sampling and 2 seconds, you get
22,050 samples and what, 0.5 Hz/bin? So a window of 32768 (FFTs work best in powers of 2) would work the best.
Tim
|
|
|
un0me2
aliced25 sock puppet
Posts: 205
Registered: 3-2-2010
Member Is Offline
Mood: No Mood
|
|
Just reading, this note caught my eye.
The biggest difficulty I am having is the amount of processing power that is being required off-board the PC/Laptop is increasing drastically as the
designs progress. As this echoes the advent of the netbooks built on the same processors (once you go beyond ARM, etc. you get into the CAP end of the scale), all that will end up happening is that these will end up a mini-stand alone systems, with a display and keyboard & the
magnet carefully tucked away inside the design.
Interesting thought process in fact, that leads to the thought that then the device (+ Li ion battery of course) would be truly mobile (whereas before
it was going to be a USB device, not a standalone system). The yardstick keep shifting. FGPA's are dying a lonely death if they don't have a mini-CPU
built onto the board to control them, so we are progressing into the prohibitively expensive end of the spectrum (pun intended).
Fuck, we were still reading about MOSFET based designs one or two pages ago.
As to the soundcard, why bother up & down converting into the Soundcard when you could more easily send a digital input stream in via ethernet/usb
& deal with that using DirectSound (MS OS - so it will not be pushed aside easily).
Ok
How about 128K of memory and 16K of RAM? Shitloads of options, in a single chip in terms of control (its a USB 2.0 compatible microcontroller)? Nice. Then there is this, A signal processor IC with two amplifiers, two 12-bit ADC's, etc. all in one chip as well. That's what, $11 so far? With more timing signals, pulse width modulators & unused PLL's then you could
poke 10 sticks at...
[Edited on 23-9-2010 by un0me2]
quam temere in nosmet legem sancimus iniquam
|
|
|
arsphenamine
Hazard to Others
Posts: 236
Registered: 12-8-2010
Location: I smell horses, Maryland, USA
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by un0me2 | The biggest difficulty I am having is the amount of processing power that is being required off-board the PC/Laptop is increasing drastically as the
designs progress.
(...)
The yardstick keep shifting. FGPA's are dying a lonely death if they don't have a mini-CPU built onto the board to control them, so we are
progressing into the prohibitively expensive end of the spectrum (pun intended). |
A risk of cheap computing is that one tends to throw it at a problem
whether it's a good fit or not.
Two, as we examine the problem, our understanding of it will change
unless we are ideologically blinkered fools -- Tea Party members are
unlikely scientists. IOW, the FPGA may not have been the best fit either.
I opine that a reasonable mix of stupid microcontroller and bone-head
power RF can manage the control and data acquisition without hideous
expense.
| Quote: |
Fuck, we were still reading about MOSFET based designs one or two pages ago.
|
They didn't go away; the excitation coil needs them absolutely.
| Quote: | | As to the soundcard, why bother up & down converting into the Soundcard when you could more easily send a digital input stream in via ethernet/usb
& deal with that using DirectSound (MS OS - so it will not be pushed aside easily). |
That obligates a faster bigger-word controller for formatting
raw ADC output as SP/DIF or similar.
| Quote: | | How about 128K of memory and 16K of RAM? Shitloads of options, in a single chip in terms of control (its a USB 2.0 compatible microcontroller)? Nice. Then there is this, A signal processor IC with two amplifiers, two 12-bit ADC's, etc. all in one chip as well. That's what, $11 so far? With more timing signals, pulse width modulators & unused PLL's then you could
poke 10 sticks at... |
It isn't the chip cost so much as the implementation+development costs.
The 56F8006 eval board is only $50; with the debugger tap: $100.
Software IDE and libraries appear adequate, but the off-board USB
debugger hardware is $500.
If you've done professional embedded work WITHOUT a debugger,
then you know you need+want one badly. Finally, I see very little open
source support for this chip, so technical support will need to be paid for
if you need it.
There are equivalent Atmel XMEGA+USB 2.0 full development systems for
much less. Ditto for a Microchip PIC dev kit.
The DDS chip, say an AD9851, may cost $20 ... but a useful DDS
implementation seems to run $80.
A project must have finite length.
I don't like reinventing the wheel or reaching for the unknown with both
hands. OTC hardware is good, but it's even better when it comes with a
metric buttload of development software. I prefer to pursue a goal more
directly while minimizing the unavoidable groveling over minutia.
At this point, the prospect of running a pulsed 100 watt RF amplifier in a
manner that doesn't send the FCC into colonic spasms should get a little
more pixel space.
|
|
|
12AX7
Post Harlot
Posts: 4803
Registered: 8-3-2005
Location: oscillating
Member Is Offline
Mood: informative
|
|
| Quote: Originally posted by arsphenamine |
At this point, the prospect of running a pulsed 100 watt RF amplifier in a manner that doesn't send the FCC into colonic spasms should get a little
more pixel space. |
Can't be too bad. The FCC would shit themselves if they had been checking out GSM cellphones while a clock radio played in the same room. Damn GSM
gets into everything.
Tim
|
|
|
arsphenamine
Hazard to Others
Posts: 236
Registered: 12-8-2010
Location: I smell horses, Maryland, USA
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by 12AX7 | | Can't be too bad. The FCC would shit themselves if they had been checking out GSM cellphones while a clock radio played in the same room. Damn GSM
gets into everything. |
@#$%&!<br>
The FCC <s>extorted</s> received big money from Cell providers for that spectrum block,
so I guess that makes it okay.<br>
OTOH, a bunch of DIY NMR enthusiasts crapping up a frequency band
forbidden for public or corporate use ...
|
|
|
Trifluoroacetic
Hazard to Others
Posts: 128
Registered: 6-8-2008
Member Is Offline
Mood: No Mood
|
|
Just in case anyone is interested I am currently working on a large water cooled magnet with two 8.5 inch diameter pole faces. I am planning on
generating a 1.2 tesla field in a 2.5 inch air gap.
|
|
|
not_important
International Hazard
Posts: 3873
Registered: 21-7-2006
Member Is Offline
Mood: No Mood
|
|
You should crunch the numbers on the amount of data in the digitized signal (audio) vs the amount in the useful part of the FFT generated. Remember
that you need to oversample generously if you plan to be doing quality filtering plus good FFT work. Also beware of digital-audio formats that use
compression to get the bit rate down; your ear gets by with the stronger signals in the mix but a spectrum analysis might suffer from the loss of
data.
Stability and repeatability of events is important if you want decent performance. Frequency drift and variations in sample acquisition timing lead to
line broadening and artifacts; field homogeneity and stability is critical as well. Remember your dealing with a fraction of to maybe 25 ppm in the
raw signal, doesn't take much to mess it up.
The MC56F family is a nice DSP-MCU; I've used it in an interface to multiple phone lines, and in a controller for the TECs in a solid state UV laser
where the PWM were handy. Haven't had to do with them, the cases where they were suggested turned out to need more horsepower than that family
provided and we went with the PPC8xx line. The ADuC7060 is another useful A/D/A/DSP system on a chip. 24 bit ADCs with MUXs, ARM7DTMI core, 14 bit
DAC, handful of timers, decent amount of Flash and some RAM. Intended for instrumentation with signals in the DC-audio range; not as powerful and
feature rich but a nice fit for some applications.
|
|
|
un0me2
aliced25 sock puppet
Posts: 205
Registered: 3-2-2010
Member Is Offline
Mood: No Mood
|
|
Ok, well for the home-hobbyist, we really don't want to get too sidetracked onto electronics do we? How about starting from something like the CUI32 PIC32MX Development Stick which has it's very own open-source Stick-OS with a forum and a Google-code repository address. I mean, it is directly programmable from the USB 2.0 port, has the PIC32MX460F512L Microprocessor built in and is what, $40? Kicks the living
shit out of Arduino doesn't it?
I'm thinking that the DDS/Programmable Oscillator with that (or have a good close look at the capabilities of that mini-CPU & see what it can do)
then amplify the piss out of the signal to get it to where we want it, collect it, filter out the transmission, then convert the noise+resonance to
digital and store them onboard for processing.
quam temere in nosmet legem sancimus iniquam
|
|
|
arsphenamine
Hazard to Others
Posts: 236
Registered: 12-8-2010
Location: I smell horses, Maryland, USA
Member Is Offline
Mood: No Mood
|
|
Not unless I need to, and particularly not if the inexpensive OTC stuff is sufficient.
That PIC's ADC is only 10-bits.
What happened to your 16-bit criterion?
It's not about "kicking CPU x's ass", but about getting adequate results
before the sun cools. Since it's a prototype project, the trinity need only
be good enough, soon enough, and inexpensive enough.
If you'd draft your project specs first, you wouldn't need to wade through the abundance of choice.
Practical Matter:
A much-glossed design figure is that your basic saddle coil has
only microvolts output. Johnson noise is a particular problem in the
saddle coil if the wire is too fine=resistive. One can't simply gen up
1000 winds of #42 and expect it to be quiet at zero field.
You may be lucky to get 50 winds of #32.
I leave the calculation of Johnson noise at 35 MHZ to you, but it looks
like noise will be an unsurmountable problem unless the saddle
coil is part of an RLC resonant circuit.
Given that you want this to be noticed by
a 1 volt input sensitivity, a net gain of 100dB between coil and
audio card is your target, to be divvied between RF preamp,
downconverter and assorted buffer stages.
If the preamp were tuned to the essential spectrum of interest,
the chore is reasonable. Fortunately, there is ample reference
info for that should a shrink-wrapped solution be unavailable.
|
|
|
12AX7
Post Harlot
Posts: 4803
Registered: 8-3-2005
Location: oscillating
Member Is Offline
Mood: informative
|
|
The noise of a 50 turn #32 coil at 30MHz will be very low indeed. Why? Because the parasitic capacitance will all but filter it out.
At 30MHz, you're looking at coils closer to 5 or 10 turns. 18AWG will be suitable. The inductances and capacitances are on the small side. For
example, at a Q of 10 and a transmission line of 50 ohms, a parallel resonant tank has an impedance of +/-j5 ohms for the L and C respectively, or
only 26.5nH and 106pF, respectively. Actually, 26.5nH will be even fewer turns; around a test tube, it might be a single turn (copper foil could be
used for improving Q).
In series resonance, the impedances are 500 ohms, or 2.65uH and 10pF (most easily attainable as a helical resonator).
Assuming 50 ohm transmission line, at a bandwidth of 500Hz, at room temperature, the johnson noise is only 20nV RMS. LT's Jim Williams has trouble
measuring 200nV, so it's safe to say this is quiet as all fuck.
Tim
|
|
|
un0me2
aliced25 sock puppet
Posts: 205
Registered: 3-2-2010
Member Is Offline
Mood: No Mood
|
|
The "actual" frequency will be either ~44MHz (1T) / ~53MHz (1.25T), so the calculations will have to be based around that. The use of the PIC32 design
allows for Fast Fourier Transforms, etc. and advanced Digital Signal Processing.
As to the job at hand, what details do you need?
Personally I'd like a USB 2.0 port for communication/programming, a controller with the grunt to do what is necessary (overkill doesn't bother me
provided it is cheap enough). I'd prefer 16-Bit sampling, trouble is I cannot find anything directly suited that is available. But in terms of the
project design - the magnets I'm taking care of - the electronic side of it should be as bullet proof as possible, while allowing for expansion/other
tasks.
I'm sure if enough people ask SparkFun nicely they could implement the same design using thedsPIC33FJ256GP710A DSP which increases the utility of the design in this application (given it is a dedicated digital signal processor built on
the PIC architecture). The OEM software available includes dedicated noise-suppression and echo cancellation (amongst others), plus multiple 16-bit PWM channels. The chip has the same footprint available, perhaps sparkfun could be asked to supply a board populated with everything but the 100
pin chip (but with the pad).
That would allow for high-capacity signal processing, ADC, FFT and pulsed on-off for the signal generator (there is a paper where they use exactly the
same concept as the pulse programmer, completely on, completely off). That leaves the signal generation and reception and from the looks of it,
another look at coil design.
PS On the back end, how about one of these? The MAX2306 (CDMA IF VGAs and I/Q Demodulators with VCO and Synthesizer), which would appear to be the closest thing I've seen to a complete back end
system (well, with the outputs going to the PIC32) yet for the 40MHz-300MHz range. Single chip (although it is a *#@# QFN/TQFN package).
[Edited on 25-9-2010 by un0me2]
quam temere in nosmet legem sancimus iniquam
|
|
|
12AX7
Post Harlot
Posts: 4803
Registered: 8-3-2005
Location: oscillating
Member Is Offline
Mood: informative
|
|
These things look quite fancy. I'm surprised they have such high fT yet manage to fit in an SOIC. I'd think they might be unstable in something
that large. A lot pricier than the old MC1496 though. Man, I'm amazed they even have any in stock.
Being a classic balanced mixer, you feed in your local oscillator (which comes from an OCXO + DDS, optionally with some filtering to make a nice sine)
and RF, and out drops the IF. With a very close frequency setting possible, a single stage can be used, bringing IF down to 1kHz or so. Remaining RF
is filtered with some chokes and caps. Finer filtering can be supplied by familiar op-amp circuits, or ignored since frequency response is the only
thing we're ultimately interested in anyway.
I have not seen a microcontroller with more than 12 bits ADC, or maybe 14. I haven't seen a single one with specified accuracy better than 2 LSB,
either. Internal ADCs SUCK. Get a standalone ADC, or use the sound card.
There is still no need for a high power microcontroller. USB interface can be bit-banged from an ATmega, or provided by an FTDI chip, or comes
integral with many higher level processors, like ARM. The processor is only required to generate pulse timing, program the DDS, and maybe turn the
lights on and off. A PC can handle the heavy lifting of ADC, and FFT, and graphical interface, and chemical identification, and printing, delegating
only the pulse generation to the microcontroller. If I2C devices are used, an ATtiny will suffice for handling the USB interface.
If you require that a complete device fit inside one box, without using an ITX motherboard, then you're on your own programming the DSP and LCD.
Tim
|
|
|
watson.fawkes
International Hazard
Posts: 2793
Registered: 16-8-2008
Member Is Offline
Mood: No Mood
|
|
Dedicated A/D conversion is a lot easier to prototype by non-experts in electronics than it used to be because of the relatively recent chip-to-chip
networking protocols. All the communications timing etc. is taken care of for you. The common such bus that's useful for data acquisition is SPI, a
synchronous 4-wire interface. The ATmega on the Arduino has it. Many A/D chips have it. Picking a convenient representative, there's the AD7765; it's a 24-bit, 156 kSPS, 112 db dynamic range Σ-Δ converter. It has an SPI interface. It's about $15 in single-unit
quantities. It's specifically designed to go down to DC. Hook up the four wires, do a little configuration in software, and you're digitizing.
|
|
|
arsphenamine
Hazard to Others
Posts: 236
Registered: 12-8-2010
Location: I smell horses, Maryland, USA
Member Is Offline
Mood: No Mood
|
|
@12AX7
I agree that the johnson noise for a 500Hz window is quite low,
but neither the initial preamplification nor the saddle coil
will be that notchy -- the preamp will necessarily see a
weak signal at the Larmor frequency. The net amplification required
before the FID signal is downconverted may be enough to
make noise a factor.
The Exstrom earth field NMR (admittedly, an orange in this apple basket)
uses a total gain of ~4,000,000 for their sensor coils and addresses the
ambient+johnson noise issue directly.
re: internal ADC suck-osity, oversampling mitigates that 2 LSB error
if you are willing to wait for it, although 16x oversampling is
admittedly (cough!) suboptimal.
re: bit banging any protocol
Get serious.
It's a WOMBAT.
If your MCU can't handle USB, find one that DOES.
Drool-proofed $20 OTC implementations abound.
@watson.fawkes
A 24 bit ADC obligates a 32 bit SPI frame. Translation to a USB
stream would make things easier and inexpensive solutions exist.
There are inexpensive MCU that do both protocols in hardware, but
throughput varies widely. With the AD7765 Sampling at 48kS/s, you
need a ~1.5MHz SPI bus clock so must select the MCU accordingly.
A few chips even run I2C and SPI off the same clock: 400 kHz or
~12kS/s for a 32 bit SPI frame, an obvious non-starter. My
<s>heuristic</s> rule-of-thumb is to select bandwidth for a 40% use factor.
@un0me2
There are abundant implementations of FFT code for x86 processors
and it would be good to take advantage of them, FFTW is one fine example.
Unless you like endlessly adjusting an embedded FFT implementation for the
application, it is simpler to use proven code as a pro-active hedge against
the "Shit Happens" Law. Using proven implementations means you have
more time for unexpected problems.
Once you've acquired the spectrum of interest, there
are methods for examining subsets of it in greater detail.
http://www.exstrom.com/journal/sigproc/index.html
Exstrom has source code and theory for the Goertzal FFT method.
re: magnet strength
When did it become 1T, up from the original 0.8T?
[Edited on 25-9-2010 by arsphenamine]
|
|
|
watson.fawkes
International Hazard
Posts: 2793
Registered: 16-8-2008
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by arsphenamine | There are inexpensive MCU that do both protocols in hardware, but
throughput varies widely. With the AD7765 Sampling at 48kS/s, you
need a ~1.5MHz SPI bus clock so must select the MCU accordingly. |
Standard Arduino will do SPI at either 2
MHz or 4 MHz. Collect data at 2 MHz from SPI and ship data out the USB. Serial operations on each side have hardware control, so there's only a few
instructions per byte transferred overhead. I'd guess that over half the CPU time is still available, plenty enough for other control tasks.
|
|
|
arsphenamine
Hazard to Others
Posts: 236
Registered: 12-8-2010
Location: I smell horses, Maryland, USA
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by watson.fawkes | | Standard Arduino will do SPI at either 2 MHz or 4 MHz. Collect data at 2 MHz from SPI and ship data out the USB. Serial operations on each side have
hardware control, so there's only a few instructions per byte transferred overhead. I'd guess that over half the CPU time is still available, plenty
enough for other control tasks. |
Standard Arduino also has a 1ms Time-of-day interrupt to contend with
the hoped-for repeatability, and an FTDI serial-to-USB chip that I'm not
entirely happy with above 19.2 kBaud.
AtMega SPI I/O is a little idiosyncratic, too, as you must write a byte to the
slave for every byte you wish to receive. (grumble)
Did I mention the "Shit Happens" Law?
There are, fortunately, Arduino work-alikes with built-in USB 2.0 that can
spew as fast as they are fed, and the time-of-day ticker interrupt can be
shut off while you run the process in insomniac mode (no sleep()).
If only it had DMA.
UPDATE
The XMEGA cpu series is more capable, has a few DMA channels
to handle the data acquision chores, is available as an
aftermarket development board .
[Edited on 25-9-2010 by arsphenamine]
|
|
|
watson.fawkes
International Hazard
Posts: 2793
Registered: 16-8-2008
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by arsphenamine |
Standard Arduino also has a 1ms Time-of-day interrupt to contend with
the hoped-for repeatability, and an FTDI serial-to-USB chip that I'm not
entirely happy with above 19.2 kBaud. |
The AD7765 uses a sync pin to start the data collection and SPI to
gather the results. Jitter in the SPI doesn't affect time of digitization. Sync generation, though, should probably done with a divider off the system
clock. I believe one of the AVR timers can be configured to do this completely asynchronously; in the worst case, an external divider could be used.
And although it's not fully fair, the new Arduino UNO came out yesterday, replacing the old FTDI chip with another AVR chip with built-in USB.
|
|
|
not_important
International Hazard
Posts: 3873
Registered: 21-7-2006
Member Is Offline
Mood: No Mood
|
|
| Quote: | ...
I have not seen a microcontroller with more than 12 bits ADC, or maybe 14. I haven't seen a single one with specified accuracy better than 2 LSB,
either. ... |
(sigh)
| Quote: | | The ADuC7060 is another useful A/D/A/DSP system on a chip. 24 bit ADCs with MUXs, ARM7DTMI core,... |
Too slow for this application, though; more aimed at scales, pH and high resolution temperature measurement, and so on. True on the LSB accuracy,
although a surprising number of stand-alone ADC chips have similar performance issues.
un0me2 - I wonder if that dspPIC has the needed oomph for this task, there's a fair amount of DSP work needed. The 12 bit ADC is borderline as well.
The MAX2306 might be useful, though you'll still be outboarding at least a TCO if not OCXO as even simple xtal oscillators aren't going to cut it.
For this application stand-alone ADCs plus real a DSP likely is the best combination. While I favour higher integration designs than Tim does, the
real drive behind the system-on-chip parts is the reduction in manufacturing costs - inventory control and parts count on the PCB - is often major
driving forces behind the highly integrated parts. Those factors aren't important to one-off home projects, although small size may be.
|
|
|
arsphenamine
Hazard to Others
Posts: 236
Registered: 12-8-2010
Location: I smell horses, Maryland, USA
Member Is Offline
Mood: No Mood
|
|
| Quote: | | And although it's not fully fair, the new Arduino UNO came out yesterday, replacing the old FTDI chip with another AVR chip with built-in USB.
|
Thanks for that one.
Massimo sez he named it UNO because so many non-Italians had trouble with Duemillenove.
I notice that the USB is handled by the suggestively named ATmega8U2.
|
|
|
arsphenamine
Hazard to Others
Posts: 236
Registered: 12-8-2010
Location: I smell horses, Maryland, USA
Member Is Offline
Mood: No Mood
|
|
Pay Dirt!
The MIT junior level physics experiments include a benchtop 10MHz NMR
spin relaxation experiment rev. 1 and the final revision.
rev 1, although truncated, contains interesting figures of merit while the
final rev shows has an annotated photo of the apparatus.
Mordant quote from rev. 1:
The NMR signal is expected to be of the order of -100 dBm,
so it needs to be amplified considerably before it can be observed
on an oscilloscope.
They used a commercial rf preamp having 55dB gain @ 1.2dB noise figure.
The phase detector was an OTC classical diode bridge between two
transformers. Gilbert cells may be a tad more sensitive.
Pulsing was initially achieved with a handful of 555 timers with a max pulse
width of ~100 us. The final pulse controller was a PIC basic stamp.
The sensor coil was blanked from the pulse by having its lead wire length
at 1/4 wave and clamping by a pair of crossed diodes.
These lab expts are also valuable for books they cite on
experimental techniques.
|
|
|
un0me2
aliced25 sock puppet
Posts: 205
Registered: 3-2-2010
Member Is Offline
Mood: No Mood
|
|
@ Arsphenamine
It got up to ~1T several posts ago, it doesn't appear to have been noticed (actually 0.989 +/- 0.001T based upon a hexagonal section through the
sample area according to FEMM, the inhomogeneity is in the center of the design (east-west given the top & bottom are North & South)).
@not_important,
I hope the dsPIC does have the oomph to do the job, it is perhaps the most promising of the easily purchased designs in that regard. I would prefer,
given the uncertainty as to transfer rates to (a) keep the data onboard & accessible as required and (b) if at all possible, perform the
mathematical computations on the board prior to transferring the information to the main PC/Laptop. Given the amount of computing power involved and
the speed of the sampling rate, I don't see why 10/12 bit sampling is sup-optimal. There is a HELL of a lot of information in a 10/12 bit digital
record, particularly when the sample rate is as fast as is promised by the dsPIC chip. That MAXIM chip requires an external ADC, which would of course
be provided by the dsPIC/PIC32 (it has shitloads of 'em to spare, plus then the digitized data is where we want it). The oscillator for the chip would
also be ported from the dsPIC/PIC32 which has several of them spare.
On-chip signal conversion would enable there to be very few none-IC components on the board, the digital synthesizer then the on-chip conversion of
the received signal takes care of most of it. The amount of binary data that can be stored in 32K of memory is HUGE (that is half the size of my first
PC).
quam temere in nosmet legem sancimus iniquam
|
|
|
arsphenamine
Hazard to Others
Posts: 236
Registered: 12-8-2010
Location: I smell horses, Maryland, USA
Member Is Offline
Mood: No Mood
|
|
| Quote: | | The amount of binary data that can be stored in 32K of memory is HUGE |
10 or 12 bit entities store as 16 bit words, only 16kword in this case.
Sampling 645 Hz bandwidth at 10x leaves 2.5 seconds of FID at best.
This doesn't leave much room for the FFT application's automatic data.
Issues like this are why it's easier to ship the data acquisition stream off
to a desktop workstation.
|
|
|
un0me2
aliced25 sock puppet
Posts: 205
Registered: 3-2-2010
Member Is Offline
Mood: No Mood
|
|
12-bit data entities are 12-bit data binary entities given that this is a Digital Signal Processor which is going to be storing the smallest addressable storage entity as a byte, whether that is a 16-bit or 12-bit unit.
If the results are stored as 16-bit (presumably address & time stamp are added), then that would be the basic unit, in the 16-bit architecture it is normally stored as 2-bytes so 32KB is going to go quite a long way, if not working out the internals of the multi-GB USB
external drives and adding a few GB of addressable memory directly to the board shouldn't be that difficult.
I don't understand where the 645Hz is coming from as a bandwidth.
The speed of the onboard processor/data capture is expressed in Hz (which is starting to pose problems), that is the speed of the sampling (as near as
I can tell), the number of samples (closed loop) per second. Each of which is captured as a 1.5 octal width expression, then the 0.5 octal width of
address/time stamp are added. I would suggest that the number of samples per second should make up for the smaller sample size. Using 10 channels
means that you would collect 10 comparable samples per period (or at least that is how it looks to me). A half-second long FID period would have 10
separate complete samples, comparison would give a representative average FID signal for the period. That average could then be shuffled off to
onboard memory, ready for further processing, while the rest of the ready access memory was overwritten by a further 10 samples. That at least is my
understanding of the process.
The averaged FID samples, would then be processed further by noise-reduction and echo-reduction algorithms, then compared to one another in order to
come up with an averaged FID signal across the various periods. That is what the FFT/FT would be run on, to give a single representative FT-FID signal
for the entire process.
The fact is I suspect more memory might be necessary given the sheer bulk of the signals being processed. Several GB of memory could be put on the
board fairly easily presumably. Trying to send that volume of signals up a congested pipeline in real time would become problematic fairly rapidly.
Addressing them using the onboard processor and then having the result-set accessible over the USB would be a better plan. There is obviously a reason
why the manifold groups involved in this are looking to utilize onboard processors, the advent of multiple sampling channels + the speed of sampling,
makes the real time transfer difficult.
quam temere in nosmet legem sancimus iniquam
|
|
|
arsphenamine
Hazard to Others
Posts: 236
Registered: 12-8-2010
Location: I smell horses, Maryland, USA
Member Is Offline
Mood: No Mood
|
|
A byte is still a byte irrespective of the processor's word granularity.
645Hz is the 15ppm chemical shift at 43Mhz/1.0 T Larmor frequency.
The 5x Nyquist sample rate is desirable for phase information
at the max bandwidth frequency.
|
|
|
un0me2
aliced25 sock puppet
Posts: 205
Registered: 3-2-2010
Member Is Offline
Mood: No Mood
|
|
Ok, thanks for that, the frequency of the shift is something I've no real knowledge of, that is something I'll have to learn later. If you had access
to the relevant thread, there are several papers where people have utilized either FGPA's or Microprocessors and FGPA's (I don't know why they used
both, essentially the frequency synthesizer is turned on & off periodically, the microprocessor should be able to do that without needing an FGPA). Quite frankly some of the larger leaps taken in this thread have been taken with knowledge of what has been successfully utilized by
others.
16-bit processors utilize 2-bytes of information, each record is 2-bytes (ie. the address, time information is added to each). As each 2-byte signal
is a binary-register of the voltage at that time (including the difference caused by the echo, the noise and the resonance), the speed of the sampling
rate is what makes the difference. With 10 ADC sample channels, that is 20-bytes per sample period, what would be a standard FID-duration? I'd like to
try and work out the number of samples that would be taken in that period. At least one group has reported successfully utilizing a Microprocessor
with a 0.3T field. Several other groups have used <1T fields.
A.Prof Takeda is currently working with a 1T magnet (with poor homogeneity reportedly, requiring X,Y,Z coils, or so I've been told) in order to try
and work out a portable, home built system. If we start from a break out board for the PIC32, then we have the microprocessor & USB 2.0 port on
one board, which puts us in front of where anyone in the attached papers has started from.
Attachment: Liang.Weimin.A.RF.Frequency.Source.Using.Direct.Digital.Synthesis.and.FGPA.for.NMR.pdf (375kB)
This file has been downloaded 1953 times
Attachment: Liu.Li.A.Microprocessor.Based.NMR.Spectrometer.pdf (119kB)
This file has been downloaded 851 times
Attachment: Takeda.Opencore.NMR.Open.Source.Core.Modules.for.Implementing.an.Integrated.FGPA.Based.NMR.Spectrometer.pdf (1.7MB)
This file has been downloaded 2513 times
Also, according to the PIC32 programming manual, a bit on that board is an 8 character data code, which, if I'm reading it right, would make the byte
on that board (which IIRC is 4-bits) a 32-character unit (if that allows for octal/hex digits it is HUGE).
[Edited on 26-9-2010 by un0me2]
quam temere in nosmet legem sancimus iniquam
|
|
|
| Pages:
1
2
3
4
5
6
..
12 |
|
![[*]](images/xpblue/default_icon.gif){kind=icon}
