Jeffrey

Follow up.... I have been running the same session/configuration of DAQami as my last post. it has now been running for more than 3 hours. Over this past 3 hours, I have periodically looked at the displayed data. The strip charts continue to be immediately responsive to new data points and manual changes to the displayed timebase.

I have set up a USB-2416-4AO with the same configuration you show, 4 TC channels and 2 mV channels, in the same order. I have DAQami running on a windows 10 computer, with the update rate set to 4 Hz, using separate strip chart displays for the grouped TC and mV channel types. It's been running for 30 minutes now, DAQami is constantly updating the screen. if I change the strip charts' time bases, the strip charts each update immediately, there is no lag. DAQami is a very popular app for folks needing to log data using MCC products. There are no other reports of this phenomenon. I believe the problem to be something on/about your computer. As a test, please try a different computer.

one more question please, How long has this session been running when you change the time windows setting?

Hello Xin Yu, This is the address I have for you via the forum and is the one I can use. Per your requested email, I now see you are in Singapore. I cannot issue you an RMA for repair because you are not in the U.S. This is due to import/export laws, and because of agreements with distributors in various countries. Please contact the firm you purchased your MCC 172 for further assistance.

Personal information exchange will needed, so conversation will be continued via private messaging.

Have you tried the MCC 172 on the Pi outside of the case to rule out any mechanical interference? I recommend you try it with a fresh OS install outside of the case.

please close the MCC 172 control panel. From the MCC DAQ HAT Manager, left mouse click "Read EEPROM's", and follow the on screen prompts. please post that picture.

Based on your test results, it appears there are some performance issues with model RPi Zero2W. As you stated in your original post, you don't see the noise issue when you use the Raspberry Pi 3B when used with this same MCC 172, only with the Pi Zero2W. Since the problem is not shown on Raspberry Pi model 3B but only a different Raspberry Pi model, I conclude the problem is not the MCC 172. I recommend you contact the makers of the Raspberry Pi Zero2W, and provide them with your test data for both the RPi's 3B and Zero2W

Please take a look at the attached picture of the one I include here. Note that the GPIO header pins fully push through the MCC 172's connector by approximately .175 inches. This is the proper installation and seating. no please take a look at your mounting and also your 2.jfif pic, and your last picture from your previous post. Note that the GPIO pins do not fully push through the connector, the device is not properly seated. I recommend, until you have it working correctly that you remove the Raspberry Pi from that PICAMERA mount. Regards, Jeffrey

Good day Xin, Your 1.jfif shows you have all options enabled. My Pi has only these interface options enabled: SPI, I2C, and Serial console. Just as a test, please disable all others on your Pi. Your 2.jfif shows the MCC 172 not fully seated on the GPIO header. This is a possible reason for no operation. With the Pi powered off, please seat it fully. If you have any other hats mounted on the stack, please remove them. Are any other applications running when you have the problem? if so, please terminate them. Some things to try: One customer had this same issue, turned out he did not install the daqhats software BEFORE he added his hats to the stack. Another customer had a bad SD card. Once replaced (and fresh Raspbian, DAQHATS loaded, etc.) correct operation restored. Regards, Jeffrey

Hi @Brooose, I am deferring this question to @Fausto, he is expert on Data Translation software and hardware.

no, it does not.

Unfortunately no.

Hello @Xin Yu, Perhaps you missed this step? Update the EEPROM images If you change your board stack, you must update the saved EEPROM images so that the library has the correct board information. You can use the DAQ HAT Manager or the command: sudo daqhats_read_eeproms Note this includes the first time you add a DAQHat to the stack. Failing that, please verify that your Pi has both SPI and I2C enabled. These settings are found by clicking Raspberry Pi Start Icon >> Preferences >> Raspberry Pi Configuration. When the control panel displays, click on the Interfaces tab. If not already enabled, enable both SPI and I2C kernel modules. Regards, Jeffrey

Hello @DJQ Answers to your questions: A missing ground connection. if you are using the PCIe-DAS1602/16 in differential mode, you still need to apply a ground. For example, if you are using differential channel pair CH0 High (CH0H) and CH0 Low (CH0L), you will still need to attach a ground reference (LLGND). When set to differential inputs, this device and most other A/D boards take 2 measurements; CH0H referenced to ground, and CH0L referenced to ground, then subtract the low from the high. To be clear, they are not true differential inputs i.e. not needing a ground. If your signal source is single ended (2 wires), and you have the device configured for differential, you need to tie the CHx Low input to ground (LLGND). If your signal source is differential (3 wires), as stated above, you need to connect all 3 wires: CHxH, CHxL and LLGND If your signal source does not have a 3rd wire, the recommended practice is to install a 100K Ohm resistor between CHxL and LLGND. More often than not, and regardless of the manufacturer, PCB mounted trim pots do not have hard stops at the ends of their wiper/screw travel. one benefit is it keeps them from being damaged by over zealous technicians trying to get 'just a little more range from the trimmer.' I was a bench tech in the early 1980's where my job was to calibrate devices with multiple trim pots per unit. Even then trim pots would allow themselves to be turned way past their physical travel. But since they were larger than those made today, there was a faint click your fingers could feel when you reached either end of the travel. Today's surface mount trim pots are much smaller and the wipers have less distance to travel so it is just about impossible to discern (or feel) the end of travel. In short, this is normal behavior. Regards, Jeffrey

Hello @Bababooey, Do you have other apps running while DAQami is acquiring and logging? if so, please end them and see if that makes a difference. If it does not improve performance, please answer the following: What model MCC data acquisition device(s) are you using? What is the sampling rate, etc.? What version Windows OS? I'll need to set this up and test. Is there anything else I need to know? Regards, Jeffrey

Hello @K Henderson SN 200CD0F decodes to it being purchased November 2021 making this device in warranty. Since further conversation will require an exchange of personal information, this will be transitioned to private messaging. Regards, Jeff

Hi @Jordan Glad to hear that!!! I was in the process of installing the latest 32 bit Raspberry Pi OS and run through the procedure of installing DAQHats software and that data_logger app to see if something changed. But you got it working. Good for you!

Hello @Bob Scholz, I see that as well, it defaults to 1 hour from present. However I can change the start time using the arrows to the right of the start time. I am able to set it to the current time in needed. Regards, Jeffrey

Hello @skycraper3, I asked one of our MCC Hat design Engineers to review this. His response: "I looked at the schematic for that device, and it has hardware conflicts with the MCC 172 on GPIO26 (HAT address), GPIO19 (shared clock), GPIO16 (reset), and GPIO20 (IRQ). It is not possible for them to use the 3rd party hat with the MCC 172." Sorry for the bad news. Regards, Jeffrey.

Hello @jkr You do need to upgrade to a newer version of QuickDAQ, available here: https://mcc.download.ni.com/?oid=193#downloads/DTSoftware/QuickDAQ/ Regards, Jeffrey

The second from the last picture is 'ringing'. it is most often caused by a bad ground somewhere. There is something amiss with your Pi Zero2W. You stated previously, you have 2 different models of Raspberry Pi computers, one shows the problem the other does not. If the same problem was seen on both Pi's I would say the issue is the MCC 172, but since it does not. I have to conclude it is the Pi Zero2W, and recommend you contact the vendor of the Raspberry Pi Zero2W. Regards, Jeffrey

Hello @Jordan There is a readme.md file in the folder for the mcc 172 /data_logger with instructions for installing the required dependencies. Viewed on Github: https://github.com/mccdaq/daqhats/blob/master/examples/c/mcc172/data_logger/README.md Install required packages: sudo apt install libgtk-3-dev at-spi2-core autoconf libtool Install GTKDatabox: cd ~ git clone https://github.com/erikd/gtkdatabox.git cd gtkdatabox ./autogen.sh ./configure sudo make install Run ldconfig after installing the dependencies. sudo ldconfig Running the example To run the example, enter the following commands: cd ~/daqhats/examples/c/mcc172/data_logger/logger make ./logger Regards, Jeffrey

Hello @SunnA Setting the analog inputs to SE/DI was deemed a software function so it is not documented in the hardware manual. This can be configured in InstaCal and also is documented in the Universal Library manual https://www.mccdaq.com/pdfs/manuals/Mcculw_WebHelp/ULStart.htm From the Contents, Go to Hardware Reference >> Analog Input Hardware >> USB-1208FS and USB-1408FS topic. Scroll down to the Configuration section, and locate "Input Mode". From the help file: UL: cbAInputMode() UL for .NET: AInputMode() Python for Windows: a_input_mode I don't know what IDE you are looking for but here is an example for VB.NET or C#.NET (add a ";"): Daqboard.AInputMode(MccDaq.AInputMode.SingleEnded) Daqboard.AInputMode(MccDaq.AInputMode.Differential) Note: This feature is not supported when using DASYLab nor LabVIEW with ULx for NI LabVIEW. Analog input channel configuration can only be performed via InstaCal.

The signal adaptation module needs to have the fastest data signal on its input 0. you have a single pulse that shows up once every 20 seconds. I have modified the data inputs and outputs to the worksheet attached. please make the same changes to your worksheet, and see if that resolves it. 1312025806_exampledasy2xDT9857E_B.DSB