to access those one needs to read the files /sys/bus/iio/devices/iio:device0/in_voltage0_raw, /sys/bus/iio/devices/iio:device0/in_voltage1_raw etc , where the number corresponds to the ADC number in this pinout. Not sure this can be done straight from Pd without causing mode switches and dropouts, so one may have to write a bit of C++ code to wrap those. What would you use in Pd to read a file on disk? We can give that a try first.

Does the file "...in_voltage0_raw" have some extension? Just making sure I'm getting it right - the file gets automatically updated every now and then and holds a latest value of a given pin?

Regarding reading files in PD I've tried something among these lines:

alt text

with the [textfile] object, but it's unfortunately for text files exclusively. There's gotta be some other way, I'll look into it.

    krzysztofcybulski Does the file "...in_voltage0_raw" have some extension? Just making sure I'm getting it right - the file gets automatically updated every now and then and holds a latest value of a given pin?

    that's correct. It's a virtual text file (without a newline at the end). The value you read is a string containing values between 0 nad 4095. Every time you read it, it goes and takes a measurement of the ADC and returns that value. So it's not real-time safe at all. As it's a virtual file, it seems that Pd is having trouble to read it. We'll have to make a C++ workaround I guess.

      OK I have something working: drop this render.cpp file in your Pd project and use something like this with [unpack] or similar:

      [r bela_lowResAnalogIn]
|
[print]

      It reads every 50 ms more or less, not sure how much faster than that it can go.

      As mentioned before, use the pinout here and triple check that you do not send more than 1.8V to each of the 1.8V inputs. You can use P1.18 "REF+ AIN 1.8V" as a 1.8V voltage reference to drive your potentiometers/sensors. I am not 100% sure whether this is properly buffered. Wire up a few pots/sensors and see if you are getting any crosstalk between them, as that would be an indication that you need a buffer on that voltage reference.

        giuliomoro You must forgive me, but I'm totally dub when it comes to Linux, command line etc.
        By "drop this file" you mean dropping it by using the Bela IDE? I've done it and the file is visible, yet, when I try to run the project on Bela, I get the following:

        Makefile:483: recipe for target '/root/Bela/projects/test_czytania_pliku_analog_in_dodatkowe/build/render.o' failed

        and:
        'libraries/libpd/libpd.h' file not found column: 10, line: 33

        Not sure how to deal with it.
        Apologies again, cuz it's probably bread and butter for anyone familiar with Linux coding...

          a month later

          giuliomoro Just a short postscript: I tested the solution (using the "hidden", original PocketBeagle analog inputs within Pure Data) and it works great - everything's ok and the readings are stable, the only thing that is less than satisfactory (altohough exactly just like you've described it) is the frequency of the readings - between 19 and 20 per second). I was just wondering if there is a possibility of a simple tradeoff - i.e. if I would only like to read 3 out of 8 inputs, would the readings be faster? Or it doesn't matter and it would be still the same frequency?

            The reading loop in the code is:

            	while(!Bela_stopRequested())
	{
		for(size_t n = 0; n < gLowResAnalogIn.size(); ++n)
		{
			path[x] = '0' + n; // int to char
			std::string ret = IoUtils::readTextFile(path);
			gLowResAnalogIn[n] = std::atoi(ret.c_str()) / 4096.f;
		}
		usleep(kLowResAnalogInSleepUs);
	}

            and the kLowResAnalogInSleepUs constant is defined as:

            static constexpr size_t kLowResAnalogInSleepUs = 50000;

            which is what's driving your sampling period. Change it to, e.g.: 10000µs to get about 100Hz.