{hhr 220110}

The three interfaces are now connected at the same time—capacitive via single I/O pins, ADS1115 for the LDRs via i2c, PN532 via SPI. I haven't built a loop yet that collects all data together, but individually polling them is no problem. It might still be that the PN532 will go on the main Pi via UART-to-USB in the end, if it turns out that it doesn't nicely multi-task with the sensor inputs. But this was to confirm that all would work on the Pico. The SPI for the PN532 is best wired as shown for the Arduino, i.e. 3V3 and GND on the left side, and the four SPI spins on the header. The chip select must be connected to GPIO 4 (Pin 7).

{hhr 211219}

The two types of sensors I want to use are LDRs (light dependent resistors), and capactive touch. They should deliver some continuous signal rather than being switches, so the LDRs have to go into an ADC. I had an ADS1115 but it's in use, so I ordered two more for testing; sadly one came out defect, this one is working as expected. The min/max of the LDR are around a few dozen Ohms when covered and 1.5 to 2 mOhms when exposed to bright light, but the curve is not linear, perhaps logarithmic, so the voltage divider is here set to 200 kOhms now. Not sure this can be optimised, but the ADS1115 is 16 bits, so probably I have more than enough detail.

For the capactive sensing, there is a flurry of videos online, with all sorts of circuit designs and tweaks. Seems like it is strongly depending on the environmental conditions, down to the pecularities of the boards, cabling etc. A number of small ICs/boards are available that implement the sensing already, so that all you have to do is connect a single digital switch pin, or an I2C signal. The switch pin of course means you don't get a continuous signal. MPR121 seems a popular choice of an I2C device with up to twelve electrodes, and apparently you can read the raw values, which are counting values. Basically a pin is set to output HIGH for a quick charge, then back to LOW, then turned into high-Z input mode (no pull-up/down), then counting starts until the charge has disappeared. With bodies present, discharge is much slower, yielding higher counts. I don't know yet how to precisely count on the Pi; a quick pi4j hack using System.currentTimeMillis with the pin listener didn't produce anything useful, I guess because I need much better time resolution, and it's unclear whether it will be possible at all given the jitter of the JVM. But then, the main Pi will be consumed by the HyperPixel, and since the break-out I2C doesn't really work, in any case I would use the Pico, so that could either go directly – as shown in this repository – or by connecting additional ICs such as the MPR121. Wendy from Constant vzm has done an interesting project based on SMD type switch ICs called MTCH101. She also advised me on using shielded cables if the chips are removed from the antennas, otherwise I'd pick up a lot of extra noise. Many designs advise on adding an additional small capacitor in parallel, which I'll have to order, as I don't have any in the studio right now. Alternatives to copper foil would be conductive paint or mesh.

{hhr 211206}

testing one of the small Class-D amplifiers. There is another one, smaller and cheaper, but its screw terminals are too small for the standard speaker wires, so it'll have to wait until I have patience to make thinner cables. Daniele also gave me a third amp for testing.

{date: 211211}

testing a sticker radio frequency readable/writable tag, as a possible vehicle between two rogues. Works from a few centimetres distances without problem. The Python examples are extremely slow writing, but the C code can dump and write much quicker. The NTAG215 can store around 0.5 kilobytes of data.

Prototyping

{date: 211211}

first trial with ceramics mold. Later, some pieces broke off the form as the clay shrunk when drying, so we'll have to use a more elastic layer inbetween, like a piece of foam.

{hhr 220109}

The capacitive sensing is basically working now, with caveats. To get started quickly, I settled on CircuitPython for now, which makes it easy to iterate, as it mounts the Pi as a USB file system, and you can update a basic code.py file over and over again. I am not a fan of Python at all, mostly notably you have zero compile time guarantees, but for now it does what it should; when you introduce a typo, the Pico just halts, and then you'll have to figure out where the error is.

I started with 4.7 MΩ resistors, and I'm still waiting for the capacitors, so they are missing. With two sensors connected, one can see some regular pulses or spiking, as if some internal rhythm was imposing itself on the measurements. After connecting six sensors, a weird new behaviour emerges. There is a “circular” movement across the sensors, as if they were “elastic”. Proximity sensitivity becomes very low, at least visually you can barely notice it (have to try thesholding), whereas a clear signal (of course) emerges when you touch a copper foil. In that case the circular movement also stops. You can also notice that all sensors are interdependent now, which is not too bad, in a way it is a nice outcome that resonates with the overall ideas behind the project. In any case, it will pose a challenge to separate this oscillation from the movement of objects towards and away from the sensors.

It could also be, however, that the circular motion comes from the fact that the Python library will probe one sensor after the other. Probably a better approach would be to conduct the sensing of all sensors at once. For that, one would have to replace the default touchio code, perhaps this is possible with the existing infrastructure in Python, or one has to move on to C.

It took me a while to understand how to send the sensor values back from the Pico to another computer. Since that other computer will be a Pi 4B without GPIO, it would need to arrive via USB. As CircuitPython uses the Pico's USB for REPL and file system, I thought one would have to do without it, and began with the UART serial wires, and using a TTL-to-USB adapter. Eventually, I was made aware of a second serial “data” device provided by CircuitPython, so one can hang on to the Pico's USB connection.

For a while, I was scratching my head about perceived drop-outs and also choppy transmission, when encoding the sensor values in binary format (which I thought would be more efficient than translating to text strings). It turned out that configuration via stty enabled a default “canonical” policy which includes an editing buffer flushed by newlines, and interpreting two dozen ASCII characters specially. Eventually, I used a serial communication library directly, which by default gives you a raw reception without “line disciplines” or anything else that gets in the way of direct binary transmission.

{hhr 211219}

the "HyperPixel 2 inches round" is a very nice display that will be used in the object. Its only disadvantage is that it needs a full GPIO connection instead of just using HDMI or solely some SPI pins. The stereo moons was just an image for testing.

I found very beautiful semi orb (plano-convex) glass lenses that have just the right size to sit on top.

{date: 211207}

the two moons was perhaps an "accident", but then… this seems like a useful way to think about the singular orb.

Circle packing.

“If even one closed Steiner chain is possible for two given circles (blue), then infinitely many Steiner chains are possible, all related by rotation.”

{hhr 220116}

More parts have arrived. Started to transfer from broadboard to strip board soldering. I put a 220Ω resistor now before the GPIO pins for protection. Using the capacitors (e.g. 4.7pF) doesn't work, because the CircuitPython library cannot initialise the pin correctly, so I skipped them for now (would have to adapt the code myself). The good news is, all six sensors now behave very stable and independent from each other, although I used 1MΩ instead of 4.7MΩ, as it scaled better into the usable value range, and now proximity sensing is almost lost, one almost has to touch the leaves.

{hhr 211219}

I haven't been lucky with the "break-out" I2C of the HyperPixel, yet; about to give up. First tests show you can talk to the board via USB serial if you configure it for UART and use a TTL-to-USB adapter. I'm not sure yet this will fully work; alternatively I could use the I2C on the Pi Pico.


Naya called them “feathers”.

{hhr 220120}

After a good experience with a 2D abstraction layer with backends both for the JVM and JS in in|fibrillae, I wondered if I could incorporate that in Lucre (and thus SoundProcesses/Mellite), so I started an experiment Lucre2D. With some basic API one can almost copy verbatim Processing sketches when they use only 2D primitives (and no pixel manipulation). But while it runs smooth on the laptop, the test today on the Pi 4 showed that the performance is insufficient. I guess it is possible to improve by a factor of three or so, but that will be a lot of work, so for Rogues I guess it will be back to hand-coded graphics or using Processing indeed, which runs smooth. The video shows an example sketch of Daniel Shiffman, first at the weak performance of Lucre2D, following by Processing 3.

{hhr 220117}

Before adding the light sensor input to the strip board, I’m testing all components. Two ADS1115 are responsible for three sensors each, and they can be connected in parallel when you differentiate their ADDR pins which give the i2c address. I was wondering why I had written 220 kΩ in an earlier sketch, as the LDRs go up to MΩ range I think. But the curve is non-linear, and since I forgot to buy 220 kΩ, I tried with 22 kΩ, and they worked nicely down to the low voltages. If I calculated correctly, I’d still end up in the magnitude of 0.1 mA of current. The sensors are now on copper wire and a piece of microphone cable, just like the capacitive sensors.

{hhr 220304}

Naya got me a hot air gun, so I made a first hull attempt with chicken wire and bees wax plates. You actually need a lot of them, you can feel the weight. Gravity tends to draw them down while working in rotational fashion applying the sheets. I switched to pressing the plates inwards to be slightly immersed in the wire.

{hhr 220125}

I cleaned up the studio to be able to spread out all the “organs” of a Rogue on the floor. Everything is also working properly electronically, although it took me a while to get a clean signal from the audio amplifier. Before the photo, I had a different one (Lazmin) attached, and it produced extremely loud crackling and squeaking. I swapped it for the one depicted now (Ruizhi), which has a volume trimmer which is needed as the amplification is way too high for the transducer. But the crackling persisted. Then I inserted the little black box, an electrical decoupler, which magically solved the noise issues. Now I wonder whether I should have picked a two channels amplifier? But perhaps it is a good constraint to stick to the single channel idea.

{hhr 220126}

I wasn’t sure about the single channel digital image ; we were always thinking to have multiple glass orbs on the object. Today I tried one of the Tremex 3W RGB LEDs that I have obtained a while ago for a project never implemented that way. They run fine on the 5V output of the 12V-to-5V buck converter, and with 3.3V data input from the Pico.

We’ll have to think about the “mask” or milk screen to spread the light before entering the lens.

{hhr 220310}

While cleaning up the studio’s deposit, I looked at the upright weirs, and I wonder if they shouldn’t form the body of Rogues this way? I wonder if Naya would agree to adopt them from schwärmen

{hhr 220130}

The prospect of building the second “partner” Rogue—to send it to artists collaborating with us in spring, or to try the bridge between two—led me to learn KiCad to design a PCB that now went to print. On the one hand, it means to “settle” on a configuration, as it is not economical to create individually differing boards, on the other hand, this should make it more robust and long-lived. Perhaps it signifies a transition to ‘technical object’ in Rheinberger's terms.

{hhr 220215}

The PCB came back from print. Soldered one, and it works flawlessly. I'm only missing 1-pin and 2-pin screw terminals. The control LEDs could have been spaced to not be halfway under the USB cable, but it’s a minor detail. I still have to test if the positions of the mounting holes are good for the audio amplifier and the Pi 4.

{hhr 220222}

Finally assembled the ”stack”. I hadn’t thought of the screw terminals needing vertical space to plug and unplug the cables, so the mounting holes were not smartly put, and I inserted some resin bonded paper layers. Also the power converter had no mounting holes and thus had to be glued on top of a paper piece.