Actions
Forum Thread Details
  • Replies 22 replies
  • Subscribers 308 subscribers
  • Views 2356 views
  • Users 0 members are here
Related
See a helpful answer?

Be sure to click 'more' and select 'suggest as answer'!

If you're the thread creator, be sure to click 'more' then 'Verify as Answer'!

Have a question about ADCs or DACs? Ask our Expert, Nick Gray

bluescreen

Don't forget to sign up for email notifications under the "Actions" box so you'll see when Nick answers your question.

 

image

 

Nicholas Gray

Nicholas has worked in the Semiconductor industry for over 30 years and has authored a number of published articles about data converters (ADCs and DACs) and signal integrity issues.

 

If not already, you'll need to

image or image

 


to ask your question.

Otherwise, click reply below.

  • Nicholas,

     

    I have been looking for an ADC for quite some time. Read here.

     

    Can you recommend some data acquisition systems that come with easy to use software? I don't want to spend a lof of time developing the backbone software or the GUI, so quick setup is key.

     

    Currently, my only option is the Picologger software and hardware. The software is fine, but it has a couple bugs and is complicated to use. However, the software is free, another deciding factor for me.

     

    Cabe

  • in reply to Catwell
    Hello, Cabe:

    It seems you are not looking for an ADC, but a complete data logging solution.

    The problem you are having finding the software you need is that every application is different and requires different software. It is not feasible for anyone to try to provide universal software that will work for every application, so manufacturers leave it to the user to provide his or her own software. Sometimes people contract this out to a software developer and there are many of those. If the system pointed out to you by Kris Demets seems to suit your needs, it may be quicker to wait for that system than to design, build, test and debug your own. Certainly being a Beta tester for Kris’ company, as you suggested, is a good idea, if they are open to it.

    The software that was pointed out to you that drives an LCD, which you can not use, could work if you modified the software to remove the LCD drive coding.

    Since the Picotech solution seems to be what you need, but with better software, you could try contact them and letting them know what bugs you found in the software and ask if there are any fixes or if revisions are planned to improve performance. You might find that they are working to fix the software. Go to the user forum as suggested by Kenny Millar. A more likely cause of the bugs is that a summer college intern who has little or no real software experience outside of school did the software and tested it in a single environment. He or she probably was never taught how to test everything in to coding and did not realize that some parts of the code were not tested. When he or she demonstrated it to the engineer mentoring him or her, the mentor did not think to enquire whether every part of the code was tested and what assurances were there that everything was properly tested. This is a common problem with work done by summer college interns as the person assigned to mentor the intern has his or her own job to do and is given the mentorship as extra work on top of what is normally required. A sad situation, but realistic in that this is what too often happens.

    It seems you have pretty much decided on using the PicoLog, but are not satisfied with the ease of use of the software. This makes me think that you may not be familiar with programming at all. If this is the case, I suggest contracting out software modification or development. I know of an excellent software guy in Roseville, California who almost definitely could do this, but I do not know if he has the time to do it as quickly as you need, or if he has the time to take on more work.

    I wish you every succes. Let me know if there is anything else I can do to help.

    - Nick Gray
  • My understanding is that a handful of companies are working on implementing analog-to-digital converters as IP in FPGAs. Do you have any thoughts about cost, performance and applications where this approach might be beneficial?
  • in reply to nickgray

    Nicholas,

     

    Thank you for the advice. I am going to contact Picotech and see if they can correct the bugs.

     

    As for programming, I could do it, but I want to finish this project and get it to market quickly. Writing a GUI and backend would take longer than I want to spend. If you could connect me with your friend in California, I would greatly appreciate it.

     


    Cabe

  • in reply to Catwell
    Send me a private message with yout contact information and I will get you in touch with a programmer.
  • in reply to nickgray

    Hello Nick,

    I have to monitor voltage of each battery in the battery stack of 150 lead acid batteries. Each battery have voltage range from 1.5V to 3V. Can you suggest me the best method.

     

    Balakrishna Nuthakki.

  • in reply to nickgray

    Mr Gray,


    I contacted Picotech, and they said that the software, "Picolog," is at the end of its lifespan. Only critical patches will be applied. And apparently, my concerns are not that.


    So, my search continues, and I need to deliver my product ASAP.


    Can you suggest another product like Picolog?


    Cabe

  • in reply to Catwell

    I am sorry that Picotech will not support their software. Unfortunately, I know of no one who is doing something similar. Hopefully, you and Rob can work something out. I sent him your email address. He is quite busy, but might be able to help you if the task is not too large.

     

    - Nick Gray

  • in reply to bnuthakki

    I am not really an expert in voltage monitoring, but I may still be able to help. What you do not indicate is just what level of monitoring do you need. Do you need to continually know the voltage level of each individual battery, or whether any battery in the stack is above or below a certain level.

     

    Monitoring each and every resistor is quite a task. The voltages of all but the one or two cells nearest ground will have to be divided down with a couple of resistors, then these voltages connected to an array of analog multiplexers before being presented to an ADC input. When cascading multiplexers, it is important to include a resistor to ground at the connection of the output of one multiplexer to the input of another multiplexer.

     

    If you only want to know if any voltage is above or below a certain level, the voltages will again have to be divided down, then use voltage comparators to determine if the voltages are above or below a threshold. You can use some OR gates after the comparators to present a single node to a processor or controller, perhaps to an interrupt pin. After an interrupt is generated, you could scan the entire array for the problem cell with a series of multiplexers.

     

    Any way you look at it, the circuit is going to be quite large if you must look at each cell separately.

     

    I do hope this helps. If not, please give me more detail as to what you are trying to do and I will try to help further.


    - Nick

  • in reply to GardenState

    I am sorry that I somehow missed your question.

     

    Yes, some manufacturers of FPGAs are attempting to implement ADCs in their FPGAs. My personal feeling is that this will be a little difficult for them to do because the digital noise generated by the gates will cause the die substrate (on-chip common) to be quite noisy, which will add noise to the ADC conversion. Noise will most probably also find its way into the ADC reference voltage, further exacerbating the noise problaem. There are ways to get around this, however, but the result in any case is a relatively low conversion rate. Cost wise it should be beneficial to the end user, especially since more than one company is doing this and competition should keep the cost down. Performance is another story. If the ADCs are 8 or perhaps 10 bit resolution, there should be little problem with reasonable performance, although a stand-alone ADC should perform better than an imbedded one. At resolutions of 12 bits and more, I believe that performance will be no better than perhaps 10 bits.

     

    What this means is, basically, that only the most significant 8 to 10 bits will be reliable, with the rest being mostly noise. The way around this would be to average many samples, but I doubt that this will increase performance beyond the 12 bit level, or 14 bit level at the most. And this would be satisfactory for most applications. Another approach would be to use converter topology that is relatively immune to noise, like a multi-slope ADC.

     

    The problem I see is that there may not be provision to adjust for the offset and gain error of the ADC and the manufacturers will have the task of being sure that the user knows how to do this to prevent a lot of complaints and disgruntled users. These companies are digital and may not appreciate the analog problems unless they hire the right analog engineers. Some of the offset and gain errors can be done with conditioning circuitry before the ADC input of the FPGA, but these errors can vary from one individual part to another, so could probably more effectively be handled in the system processor.

     

    As for applications where this might be beneficial, any system that takes input from the outside world and needs the versatility of an FPGA could potentially benefit.

     

    - Nick