Announcement

Collapse
No announcement yet.

AMX Digital

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31

    Originally posted by Olly View Post
    For direct sampling perhaps an FPGA would provide the required horsepower, especially if coupled with a 24-bit, 2.5Ms/Sec ADC such as the AD7760. This is a combination I’ve successfully used in the past for very low noise current profile measurements.​

    Yes, available, rather costly but you only need one with direct sampling
    BUT
    data interface : 20 parallel pins!!!

    Would need to interface with a dedicated co-processor (FPGA is out of question here) external to the DSP processor.

    However, I think this is the best DIRECT SAMPLING architecture proposal yet.
    We should seriously consider this proposal.
    The cost of this ADC is balanced by avoiding the costs of 3 or 4 demod, Opamp, switch and multiplexed ADC components.
    The co-processor could make all the fast capture under DMA and feed a FIFO buffer in continuous mode. It could also integrate and filter the raw data.
    It could be connected to the main DSP processor with a serial link (SPI) to transfer the NET results​
    Last edited by Willy Bayot; 01-31-2023, 08:57 AM. Reason: typos

    Comment


    • #32
      Originally posted by Willy Bayot View Post

      Yes, available, rather costly but you only need one with direct sampling
      BUT
      data interface : 16 parallel pins!!!

      Would need to interface with a dedicated CPU (FPGA is out of question here) external to the DSP processor.
      Why is an FPGA out of the question?

      Comment


      • #33
        Originally posted by Olly View Post

        Why is an FPGA out of the question?
        I think that the FPGA programming is out of reach for most of the members of this project but I may be wrong.

        Looking at the latest developments of FPGA programming and capabilities on GOOGLE, I could indeed be wrong. I even see a C-to-HDL converter.
        But what about the costs and availability of components and development tools?

        Comment


        • #34
          …I posted that exact solution some time ago spartan 6 FPGA and ADC7760 …. It’s sitting on my desk shelf.

          DEJA VU :-)

          https://www.geotech1.com/forums/foru...595#post219595

          I have several of each board.

          moodz.

          Comment


          • #35
            Originally posted by Carl View Post
            All the elements of this project are not 100% known, there is some R&D to be done even after the architecture is defined and circuitry designed. This includes best methods of ground balance and possible methods of iron disc. So what you do is design for the R&D of those possibilities. Starting out with just a 2-channel design ties your hands immediately, and you are likely confined to a TDI-like detector.

            In ML GPX detectors, iron disc works when using DD coils and looking at the TX turn-on reactive signal. In CCPI that signal is only a few microseconds wide and is accompanied by several hundred volts of flyback (or flyforward?), so using it is a real challenge. But there is also the possibility of looking at the decay in more detail. Just like a VRM response has a different decay curve than an eddy decay, so does an iron target. To look at this you need at least 3 samples. If you direct sample the decays, well, then you have a ton of information to use, and iron disc might not be so hard.

            BTW, iron disc with nails is relatively easy because it's primarily a BH-curve response. Flat iron like bottle caps or the flakes of rotted cans are more difficult because they have substantial eddies. Which is why I want more information.
            Hi Karl .. (Flat iron like bottle caps or the flakes of rotted cans are more difficult because they have substantial eddies. Which is why I want more information)I didn't understand this, do you specifically mean rusty plugs or new ones​ flakes of rotten cans do you mean circles of iron with a hole​ ? Otherwise, I would say that I can have two channels, but if you have in the processor that you can choose between two channels and one channel that works only one channel, like tdi with two channels, very similar... I work with exactly such a device.​the second channel is discrimination, it takes a sample reactively before turning off the mosfet, it works with a DD coil​ I have a switch on the processor that I use to select when two channels work or one channel with different patterns and it works with one coil and has a geb like a tdi​.Regarding direct sampling, I agree that at least three are needed. Some of the well-known devices already use that.​

            Comment


            • #37
              Originally posted by moodz View Post
              …I posted that exact solution some time ago spartan 6 FPGA and ADC7760 …. It’s sitting on my desk shelf.

              DEJA VU :-)

              https://www.geotech1.com/forums/foru...595#post219595

              I have several of each board.

              moodz.
              "...... in the end I went back to $5 Pic32 chip ... it does a better job. ​..."

              ???

              Comment


              • #38
                That’s actually a very nice module, I have one I’ve been playing with and it’s very powerful despite its small size. Should me more than capable of providing ADC interfacing and control as well as integration functions with a lot to spare.

                Comment


                • #39
                  Originally posted by moodz View Post
                  …I posted that exact solution some time ago spartan 6 FPGA and ADC7760 …. It’s sitting on my desk shelf.

                  DEJA VU :-)

                  https://www.geotech1.com/forums/foru...595#post219595

                  I have several of each board.

                  moodz.
                  question 1: How was programmed the FPGA to make the data capture using the AD7760?
                  question 2: Why did you conclude as : "...... in the end I went back to $5 Pic32 chip ... it does a better job. ​..."​?
                  question 3 : If you did so, what type of PIC32 did you use?

                  Comment


                  • #40
                    I think we have to discuss the PRO's and CON's of the following decision tree:
                    Click image for larger version

Name:	dataurl284221.png
Views:	227
Size:	3.6 KB
ID:	409167​​

                    Comment


                    • #41
                      Originally posted by Willy Bayot View Post
                      I think we have to discuss the PRO's and CON's of the following decision tree:
                      Click image for larger version  Name:	dataurl284221.png Views:	23 Size:	3.6 KB ID:	409167​​​
                      I see that nobody has reacted yet to this post.
                      Let me start the discussion with a few structured observations:
                      • Integrated Sampling
                        • PRO
                          • Lower requirements in ADC speed since the demodulators are doing the job of integrating and filtering the raw signals--> Less costly and more widely available high resolution ADC's chips
                          • Complementary digital integration is still available provided the net sample rate is compatible with the speed of swing and size of targets
                        • CON
                          • More complex and costly receive circuits : MTPX, DEMODs , Switches, multiple ADC or ADC channels.
                          • More constrained on-the-fly updates on timing schedule and integration windows
                      • Direct Sampling
                        • PRO
                          • Access to as many digital demodulators as necessary by DSP.
                          • Simple Receive circuits : just input conditioning, pre-amp and final gain amp with possibly signal level adjustment before ADC.
                          • Fully Digital integration giving a net sample rate compatible with the speed of swing and size of targets
                          • Easy on-the-fly updates on timing schedule and integration windows
                        • CON
                          • High requirements in ADC speed to be able to precisely define the capture windows limits
                          • More costly and less available HIGH SPEED, HIGH RESOLUTION ADC's
                      • Single CPU module for capture and DSP
                        • ​​​​​​​PRO
                          • Simple physical architecture : Single PCB, single program--> less module interfaces
                        • CON
                          • ​​​​​​​The program has to deal with a mix of highly time-constrained fast processes (data capture) and interrupt-driven processes (essentially HIM)
                          • The most available HIGH SPEED, HIGH RESOLUTION ADC's come with a data interface using a high number of parallel digital pins (e.g. 20 pins) instead of the fast serial interfaces (SPI) taking only a few dedicated serial lines.--> Smaller selection of micro-processor packages with enough I/O pins
                      • Separate CPU's for capture and DSP
                        • ​​​​​​​PRO
                          • Highly time-constrained fast processes (data capture) are exclusively controlled from the data capture CPU while interrupt-driven processes (essentially HIM) are controlled from the other CPU's
                          • The data capture CPU can allocate all its General Purpose I/O pins to the ADC interface
                        • CON
                          • More complex architecture with more inter-module interfaces.​​​​​​​​​​​​​​

                      Comment


                      • #42
                        Originally posted by Willy Bayot View Post

                        question 1: How was programmed the FPGA to make the data capture using the AD7760?
                        VHDL … the ability to map just about any pin to any function and lots of io pins makes life easier. AD7760 really needs an FPGA so the data transfer and processing can be optimised.

                        question 2: Why did you conclude as : "...... in the end I went back to $5 Pic32 chip ... it does a better job. ​..."​?
                        For $5 you get a lot of capability … and to double it it’s $10. If your task is a flyswatter you don’t need a sledgehammer.

                        question 3 : If you did so, what type of PIC32 did you use?
                        I use pic32MX250B for most tasks. It’s a jellybean CPU fast enough for a PI … prob use a pic32MZ for heavy dsp.

                        moodz

                        Comment


                        • #43
                          I continue to lean toward direct sampling. If you consider the TX waveform I proposed in post 25 and accept 2 samples per 25kHz pulse then the ADC must sample every 10us, or 100kHz. The micro would need to pull in 24 bits of serial data every 10us. Many of the better micros have SPI that runs at 25-50MHz. Let's assume 25MHz; pulling in 24 bits will take slightly more than 1us. So sampling at 10us looks fairly easy.

                          Inside the micro we have data coming in every 1us. But a typical processing loop runs every 5ms or so, therefore 1us is way too fast. So you simply DMA the data to a fast array accumulator that bins the data you want to keep. Each complete TX cycle (1x5kHz + 5x25kHz) takes 400us, so if we make the processing loop 4ms then that is an even 10 TX cycles, or 400 ADC samples. So every 4ms you transfer the array data into the processing loop and work away. Or 6ms for an even 15 TX cycles, or 600 samples.

                          A key to making this work is to automate and autonomize everything possible. This means autonomous clocking (both TX & ADC), ADC DMA with an interrupt-triggered fast accumulator, and an RTOS-controlled processing loop.

                          I am not opposed to using an FPGA but HDL that is not one of my skills. Many years ago at White's I took a day-long hands-on FPGA lab but I don't remember any of it. I really think a good micro (and just one) can do the whole thing.

                          Comment


                          • #44
                            Carl, using direct sampling can the adc be controlled to sample precisely at the traditional points in time and duration? Like a sampling integrator?

                            Comment


                            • #45
                              That is just the way I did code on a PIC32MX to direct sample a PI.
                              The PIC hardware did all timing from TX pulse to ADC sampling with DMA.

                              A RTOS 'loop' summed 8 cycles of ADC data before processing. This also increased effective #bits from 12 to 14-16bits. With 32 bit words (memory) no problem.
                              The 'loop' also handled user IO and display, alternating tasks on each 32 cycles. This is plenty fast enough to be 'human real time'.

                              The ADC does 256 sample per TX pulse which then allows doing a log curve fit.
                              Integration is done is the software (did a simulated analog integrator like used in HammerHead). This has fully adjustable parameters.

                              I also was playing with creating a mulit-frequency using a PIC32MZ-EF. This processor has an FPU and I was very pleased with how fast it could run IIR filters and other DSP type calc's. Signal generation to ADC/DMA all done with the PIC's hardware.

                              Using the PIC's hardware features produces fast accurate timing without software overhead.

                              I can understand using an FPGA but that is way outside my level of expertise for something of this complexity.
                              .
                              I can post (to the Programming forum) any of the C code modules used if anyone wishes to see how they are done. PM a request.
                              Setting up the PIC32 OC is covered here: https://www.geotech1.com/forums/foru...ng-in-hardware

                              Comment

                              Working...