Jump to content

nbv

Members
  • Posts

    6
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

nbv's Achievements

Newbie

Newbie (1/4)

0

Reputation

  1. Hi, so far when I needed a TTL using the MCC152 I used a Python script loop to change the state of an output pin from low to high and back with a time command between them. with the GPIO pins of the Pi, one can generate a CMOS signal using a PWM command which is, I guess controlled by the Pi clock. But I can't do this at the TTL (0-5V) level. is there a way to combine the two? using the CMOS PWM from the pi GPIO pins as an external trigger for TTL signal from the MCC 152? or using the clock of the pi? in other words, I need a way to generate a TTL from the mcc152 without setting high and low in every cycle. thanks!
  2. Thanks Nick, to follow up on what Fausto wrote, one last test I did was to connect the damaged mcc 152 in address 1 on top of a working mcc 152 in address 0. the result is again that both do not respond. i.e. the damaged mcc 152 prevents the working one from responding regardless of which one is in address 0.
  3. Hi, not exactly. I'll explain it again chronologically. 1) a new RPi 4 (not sure what is the name of the OS but it was the one recommended by RPi at the time) was setup as per instructions. 2) 3 MCC boards were mounted and installed (MCC 152 on address 0, MCC 152 on address 1, MCC 118 on address 2). all jumpers and OS configurations as you wrote. The setup worked perfectly well for more than a year both with the manager app and with my scripts. 3) one day (this last Monday) it simply didn't work anymore. it didn't work in the way I explained in the original question i.e. "board not responding" (both of the MCC 152 on address 0 and 1, the MCC 118 continued to work). 4) The only thing that happened between the last time it worked and this Monday was the weekend during which the pi was turned off. I usually turn the pi off over the weekend. so the boards were not moved or removed or flexed. I only started manipulating them after the "not responding" error. 5) as part of troubleshooting I unmounted all three boards and mounted back only the first one (mcc 152 address 0) - it didn't work. 6) I tried it on another RPi - it didn't work. 7) I tried it again on both pi's after disconnecting all the wires. - didn't work. 8) NEW UPDATE: took one other mcc 152 scavenged from another system and connected it to my RPi 4 in the original setup (without any jumper in address 0) - this works perfectly well. next step, I took the second mcc 152 (the one that was before in address 1) and mounted it on top of the "new" mcc 152. now both of them work. I continued and mounted the mcc 118 in address 2 (as before) and it also works (as it did before). 9) my (strange) conclusion is: for whatever hardware-related reason, the mcc 152 in address 0 failed. it was identified and the EEPROM can be read but it could not respond (could not be opened in the manager app). This caused the second mcc 152 in address 1 to also not respond in the same exact way, although it is not damaged. ones I put in the same address but with a "new" mcc 152 below it, both respond. Even stranger - this problem didn't affect the mcc 118 in address 2. does this make any sense?
  4. Hi Fausto, thanks for your reply. first, a correction - I am using Raspberry Pi 4 (not 3). both SPI and I2C options are indeed enabled. the setup worked perfectly asi-is a week ago. without disconnecting the wiring I did the following: - Rebooted - Unmounted all three boards - Remounted only one and tried again - no success. - Installed everything on a new Raspberry pi 4 based on your github readme (side note: installing on the latest OS is a nightmare) and connected the MCC 152. As with the other (older OS) pi, the HAT manager app reads the chip in address 0 but the board is not responding. * I can try to repeat everything without the wires if you think this could make a difference. UPDATE: Tried with the wiring off. same result. the board is not responding. it is (like before) identified in its address when asking the app for a list of devices and the EEPROM is also found. But it can not be opened (with using my script and also with the HAT manager app).
  5. Hi for about a year I have running 2 mcc 152 boards (addresses 0 and 1) and one mcc 118 (in address 2) on a raspberry pi 3 without any problems. Operating System: Raspbian GNU/Linux 10 (buster) Kernel: Linux 5.10.103-v7l+ Architecture: arm today I got the two 152: daqhats.hats.HatError: Addr 0: boards Board not responding daqhats.hats.HatError: Addr 1: boards Board not responding using the MCC DAQ HAT Manager app, both boards do respond to clicking on open but no error message appears. The 118 in address 2 opens without a problem. clicking on "list devices" shows all three of them (see below). I ran sudo daqhats_read_eeproms in the terminal and received "Found EEPROM at address 0" (and the same for addresses 1 and 2). reading EEPROMs from the MCC DAQ HAT Manager app shows the same (see below). any suggestion for a solution? is there a way to run a test on the boards without unmounting them? thanks
  6. Hi I'm using MCC 152 DO to send a TTL with a fixed pulse width (5 msec) and frequency (100 Hz). I use a Python script with a loop using time.sleep() for the "ON TIME" and "OFF time". when looking at the output with a scope it seems that the signal is not stable and with a lower actual frequency. is there a way to do that differently with a clock (I think the MCC 152 doesn't have one), perhaps from the pi? A small added complexity is that I need to synchronize an analogue read (using an MCC 118) with the TTL pulse. thanks
×
×
  • Create New...