Ronnie

Thanks, we are working on a heatsink experiment. Do you guys have any plans to support an "industrial" version of your product? We are deploying a prototype that includes your product in the Oil and Gas sector, but that means its running outdoors in an explosion proof enclosure.

Hello @attila Do you know if the AD3 includes the "C", "I" or "Q" version of the Xilinx Spartan-7 FPGA? The part number of the FPGA includes a last letter that identifies whether its an commercial, industrial or expanded version of the FPGA.

I found that maybe I need to set https://docs.rs/dwf/latest/dwf/dwf/constant.DwfParamTempLimit.html# param 11, which seems to work. Let me know if any gotcha on this? Some background: We are using the AD3 in an outdoor environment, on a hot day -- we are looking into ways to help us with thermal issues, but need to go beyond 85c for now. How hot can we go before this thing breaks? :P

If we set this value in Waveforms, will it remember it for API usage? through reboot. Thanks

Hello, Do you know what the default would be if not using Waveforms software (only using API to control)? and anyway to set the Temp Limit programmable via API?

Hello, Is there is a maximum board temperature that causes the AD3 to shut down? Example: 72c? Does the AD2 have any such max temp restrictions?

Hello, Do you have any plans to support the BeagleV Fire? It has a RISC-V CPU architecture but I didn't see any drivers to download for this CPU architecture (Waveforms, etc.). We use the Python API to interact with Analog Discovery 3. Thanks!

Hi @attila -- Thanks for all the help, we got things working well for now on BB Black. Out of curiosity, do you have any plans to support the BeagleV Fire? It has a RISC-V CPU architecture so we couldn't get a waveforms that would install correctly.

Thanks, I set it up this way as a test... but on BeagleBone (arm 32bit of software) only, I still needed to run FDwfAnalogOutConfigure after the first scan of the loop before it "stuck"... I am not sure why. I guess we can live with it, just a strange behavior.

Thank you, I did figure out one of the bugs. I found why I had to run FDwfAnalogOutNodeOffsetSet twice. I guess the Offset is a c_double, but I was sending a c_int. That seemed to matter on the BB more than others. In Windows and 64bit Linux it did not matter, but in arm 32bit -- it did matter and didn't give me an error, just didn't work correctly. I am still looking into a difference in data on the BB, which seems to clear up if I run FDwfAnalogOutConfigure before each scan (very odd). I am still wrapping my head around it. I sent you a private message to help with some more code review tips if you have some time : )

Thanks @attila, this experiment helped a lot. It seems that BB does give me the right results here, and so I started digging into our "bigger" python code to see why I am getting inconsistency with the data on the slower BB in comparison to Windows. In our program, we basically setup everything and then have a loop that just scans data constantly. If I add these two lines each time we scan, everything looks a lot better on the BB, but it adds so much latency. If you don't have any hints of things to try, I could send over our full script but of course you would only be able to do code review (not run it). I would have to send it in Private Message. One more thing to add, we have autoconfigure on -- I really don't think I should need to Configure each time I scan... We our muxing between each scan though to switch a channel. dwf.FDwfAnalogInConfigure(device_data.handle, ctypes.c_int(-1), ctypes.c_int(1)) dwf.FDwfAnalogOutConfigure(device_data.handle, ctypes.c_int(-1), ctypes.c_int(1))

@attila maybe you could help me re-create the situation with a simplified script rather than all of our other stuff mixed in. I have an AD2 (and an AD3) that does "loopback" I believe from ch1 to ch2. I have attached a picture. I also modified an example py script that reads the third column in a CSV record and loads this. However, I just need a little help "completing" the code to see if I can re-create and see it in the data response. I have attached the Py Script and CSV file and the constants file I am using for the loopback test. I am still learning about the SDK so any pointers could be useful. See attachments. PS: you can comment out numpy import dac.csv dwfconstants.py simple_bb.py

Also if you know a way I can validate the data that was loaded from (FDwfAnalogOutNodeDataSet), is there an API that would give me the exact array I sent back to me?

@attila you may be able to help me with one issue. Its sort of strange and only occurs on the BB. I'm going to insert some code to show you something interesting. When I load my Voltage and Current data using AnalogOutNodeDataSet, some reason I have to execute this code twice in order to get visualization to (almost) properly work. Do you know if I should be delaying somewhere or have any clues? Could I be dropping data when trying to send to the AD2 and the second time around helps with that? This doesn't happen in Windows or Linux (64bit), but it does happen in BB Linux (arm 32bit). # Voltage dwf.FDwfAnalogOutNodeDataSet(device_data.handle, ctypes.c_int(0), constants.AnalogOutNodeCarrier, voltages_buffer, ctypes.c_int(dac_points)) dwf.FDwfAnalogOutNodeFrequencySet(device_data.handle, ctypes.c_int(0), constants.AnalogOutNodeCarrier, ctypes.c_double(dacfreq)) # 10 Hz dwf.FDwfAnalogOutNodeAmplitudeSet(device_data.handle, ctypes.c_int(0), constants.AnalogOutNodeCarrier, ctypes.c_double(voltage_absmax)) # amplitude=1 dwf.FDwfAnalogOutNodeOffsetSet(device_data.handle, ctypes.c_int( 0), ctypes.c_int(0), ctypes.c_int(0)) # no offset # Currents dwf.FDwfAnalogOutNodeDataSet(device_data.handle, ctypes.c_int(1), constants.AnalogOutNodeCarrier, buffer_current, ctypes.c_int(dac_points)) dwf.FDwfAnalogOutNodeFrequencySet(device_data.handle, ctypes.c_int(1), constants.AnalogOutNodeCarrier, ctypes.c_double(dacfreq)) # 10 Hz dwf.FDwfAnalogOutNodeAmplitudeSet(device_data.handle, ctypes.c_int(1), constants.AnalogOutNodeCarrier, ctypes.c_double(current_absmax)) # amplitude=1 dwf.FDwfAnalogOutNodeOffsetSet(device_data.handle, ctypes.c_int( 1), ctypes.c_int(0), ctypes.c_int(0)) # no offset Below is executing the above code once (bad data): Next is executing above code multiple times (better data seems to occur the more times I run it, but still has a weird "tail/ending" part of the data stream):

It seems that everything still "works" like Waveform etc. but I get that error if you turn on kern.log in rsyslog.conf... every time I communicate with the AD2 or AD3 (tried both) on this specific OS: Linux BeagleBone 5.10.168-ti-r73 #1bullseye SMP PREEMPT Wed Nov 29 00:30:50 UTC 2023 armv7l GNU/Linux. I had to turn off this specific logging because it happens so much. I tried different cables and power usb. Very strange issue. I do not get this error on another Linux Ubuntu load that I have. I am not sure why so many -121 errors, as even basic commands cause it. I am getting some strange data on this same BeagleBone kernel, but might not be related to this... still trying to figure it out. The data coming from this kernel is just a little bit off in comparison to Windows and the Ubuntu system.