svofski
Further details can be found in the project logs.
Visitar URL original
Yet another Nipkow disc apparatus
Already have an account? Log in.
To make the experience fit your profile, pick a username and tell us what interests you.
Further details can be found in the project logs.
My TTP223 boards came without a capacitor. Found a 0603 capacitor kit. It was a bit tricky to fit them there over 0402 pads which I previously buried in hot glue, but I managed.
Touch feels as expected now. I guess a similar result could be achieved by making the plastic layer thicker.
My video was inexorably buried alive by youtube algorithm, such a shame. Anyway..
Spent a bit of time transferring the breadboard part of the circuit onto a perfboard. When working on projects without any CAD projects to back them up, I find it very helpful to mark the sockets with colours of the wires. For that I have a set of some smelly paint markers and some acrylics.
BTW, this is a Pi Pico clone that has USB-C connector, 16 megabytes of flash (!) but incompatible pin layout. Pretty good anyway and for a project like this 16 megabytes of flash comes very handy. With zx0 compression I can put a few demo videos without needing any external storage.
I designed the case to house the two main boards and a set of touch sensitive buttons on top. Touch sites are debossed and filled in with paint, then UV resin. These TP223 modules are extremely sensitive by default as I found out a bit too late. I'll need to move them farther from the surface, or use capacitors to keep their sensitivity in check.
All of this looks relatively clean and almost easy to assemble. But at the moment of putting on the lid the wires really don't want to stay near their conduit. While drilling mounting holes in the perfboard the wires caught on the drill and I ripped half of them, which I had to repair. Just a scratch..
Incredibly it still works after such unceremonious stuffing into the new box.
This time I managed to prepare a full video before it exploded. I welcome you to watch it and enjoy.
(It's still fine, I'm referring to some of my less lucky projects).
I really want to make it something that can be put on a shelf and retrieved at convenience, like a schoolroom prop. There's some risk of destroying it during repackaging though.
Adding RGB seemed almost uneventful at first. I had to dial down the red channel (10 ohm for GB and 30 for R) seems to be pretty well balanced.
A surprising thing was that DMA transfers would go out of sync and produce tearing. It didn't happen with B&W. Even weirder that it doesn't happen with my test frame. Any video frame however begins tearing even if it's a freeze-frame. Anyway... the fix for this was to sacrifice one line. If you think of it, it makes sense, sync needs some stretchable time.
OpenCamera app has adjustable shutter speed which is tremendously helpful for filming spinning discs.
My PDM sound idea didn't work out so well, 81khz is not enough for clean 1-bit audio, you can barely hear it. So I discarded that idea. Kept the format though: it's still 2048 bytes/frame except that every two consecutive pixels now encode a 8-bit PCM sample at 10khz.
This works much better. I decode the buffer and output the samples via a GPIO pin using PWMAudio library. Unfortunately changing sample rate on the fly is a bit difficult in that library because it has to factorize coefficients for the DMA controller and it's very slow.
Maybe I'll make my own PIO-based PWM audio later. At the moment it could be a better idea to spend the time on making the connections a little bit more permanent.
While waiting I updated the pixel format to support colour and sound.
The original format: 1 byte per pixel encodes 9 grayscale levels with the number of bits.
00000000 0 10000000 1 11000000 2 ... 11111111 8
This is a bit wasteful, especially when transitioning to colour.
My new format encodes just the value in 4 bits. The number of possible values is technically 16, but I keep it to the old 0..8 for the time being. So each RGB pixel takes 12 bits to encode. I could leave it at that but why not use the remaining 4 bits to add sound?
I like 20fps frame rate, not too flickery, not too crazy to sit near the disc. 32x32x20 = 20480 pixels per second. Or we could make it 20480 4-bit samples per second. Or 10240 8-bit samples per second.
I remembered a demo for Vector-06c that I made a year ago. I added sampled drums with a beeper using a very low sample rate. With PWM it would have been hopeless and it would whistle. However with PDM, which is a result of delta-sigma modulation, it's noisy but the noise tends to be much more pleasant. It worked reasonably well even at 15625 Hz sample rate.
Here I can afford 81920 Hz sample rate. I used the old script with updated parameters. Simulated reconstruction sounds quite good. Updated video conversion scripts to mux video and audio together.
So the pixel stream is now saved like this:
rrrrggggbbbbtttt
With 4-bit values of RGB and T for Tone.
And in the pico each 16-bit packed value is expanded to interleaved 32-bit value. Each column is pushed out to its respective PIO GPIO pin.
R1 G1 B1 T1 R2 G2 B2 T1 R3 G3 B3 T2 R4 G4 B4 T2 R5 G5 B5 T3 R6 G6 B6 T3 R7 G7 B7 T4 R8 G8 B8 T4
Because T is not saved as value but raw PDM bits I think I'm going to just repeat each bit twice. This is of course subject to experimentation and change.
With this more advanced data format and added sound, the old code that pushed the bits to PIO seemed wasteful. I updated the PIO to output 4 bits in parallel, and set up a DMA channel to push out the frames to PIO. The CPU doesn't have much to do other than preparing new frames now. The hardware and software is pretty much RGB-ready, just waiting for the LED and speaker.
Continuing demoscene tradition I thought of packing the stream to zx0 format using salvador. My test stream compressed down to approx 57% of its original size. If I make a fast enough unpacker it would be nice to have.
Even though I don't really have any good material to show.
Tried a few things.
Plain holes, like the old dudes with their lathes tend to make from giant discs of metal. Or at least old records. This works very poorly because it needs a good diffuser. I tried paper, it's okay but dim. Tried a milky plastic bag. That was bright but you can't look straight on because the diffusion is not enough.
Diffusing dots but thinner layer. I printed the first layer at 0.1mm vs the usual 0.2. Somehow I can't tell the difference in white PLA translucency. Initial 0.1mm layer is doable but seems to be prone to other problems, I think it's not a great idea.
Idea maybe worth exploring: keep diffusing dots at 0.2mm, but make the wells conically shaped. Add lenses on the LED side to collect more light. I don't have any translucent PLA at hand but I could try with UV resin.
FreeCAD had a major brainfart on my project. All my sketches were fully constrained. Yet somehow it flipped them over, flipped the lines to the opposite side in some (distance inversion). And it wasn't a singular thing but basically my entire project got messed up and I had to remodel a large portion of it. It happened to me before on a smaller scale, but this time it was really annoying because pretty much everything got destroyed and the only warning I got was because a dependent model references broke. Anyway...
The motor adapter part I didn't even bother fixing because it was fine in v1 and I just made sure that the holes line up more or less properly with the receptacle. Really dig the two-colour look of it now.
The main post, ST188 adapter and the LED housing though were given a slight remodeling. Now that I know where exactly they sit, it was easier to add the right cutouts and holes in the model and the assembly is now pretty solid.
With some effort the entire post + sensor + LED housing thing could be made a single part. But probably only printable with supports and I like a shiny screw here and there.
Speaking of screws. Despite of disproportional romanticisation of heat inserts by innumerable youtubers I still find them annoying and troublesome. They have their place of course: here the spindle adapter uses M2 screws with heat inserts for example. But more often than not it is better to make pockets for plain old nuts. It looks amazing, it actually takes less space sometimes and can have a better holding force. And best of all you don't need a special tool or a strong vocabulary assisted soldering iron to make them sit exactly right.
Looks amazing I think. Even though FOC boards are soon going to arrive in the mail I'm not going to change this project to use them. Stripboard BLDC driver has its special charm. I'll get rid of the breadboard of course, but otherwise this is it.
32x32 is not a huge resolution as it turns out and short of select Betty Boop excerpts and Steamboat Willie there's not much that remains recognisable at this resolution.
Adding sound to this would be interesting, considering how flexible it is with regards to frame rate, and therefore sample rate.
Enough of green rabbits.
Designed some parts to fix the sensor and the light properly.
Sensor mount with the LED cover.
A rear view. This version uses final version of the disc with spokes/sync offset by 1/4th of a frame. Also note that the light assembly is offset to be directly above the motor axle.
I heard somewhere that white LEDs are not good for this job because the phosphor has afterglow and it makes fast switching impossible. Maybe there is such effect on some white LEDs, or maybe it was said about very fast switching speeds. The one that I happen to have here (which looks absolutely like nothing special, a 5mm clear LED) has no problem whatsoever keeping it up even at 30+ fps.
This picture makes it easier to see the offset. No photo of the disc with sync offset.
The offset spoke allows VSYNC detection slightly before the top hole comes into the frame. A small adjustment of 1/8th of a line is then added in code, something like
add_alarm_in_us(frame_time/num_lines/8, start_frame_cb, nullptr, false);
I think I overpower it slightly, it feels a bit warm to touch.
I'm a bit apprehensive of adding SD card support because my earlier attempts of setting up SPI with Philhower core were not very successful. Maybe SPI was doing well, I'm not sure, but it killed my motor control. Maybe a poor choice of motor control pins, not sure.
I fashioned an ST188 optical sensor. I thought I'd use it for reading line sync. Things did eventually play out completely differently.
Reading a reflective optical sensor reliably can be challenging. Not having learned anything from my frustrations with the Split-Flap displays, I used an ST188 reflective sensor with 180 ohm in LED to ground and 47K in emitter to ground. ST188 is good here because it sees things at a substantial distance. I also used them in the Library For Ants projects to detect SD cards presence.
It doesn't pick up printed white marks particularly reliably. Or rather, it was really hard to adjust it for reliable reading. It would pick up one sector multiple times. Anyway after a lot of trial and error I ended up with a much simpler setup.
The sensor looks at the spokes, and one spoke has a piece of white paper glued to it (could just print it in white later, but..).. The large white squares are not working here and probably never will. A better fixture will be needed for the sensor of course.
I experimented quite a bit with counting pulses and dividing by seconds to get RPS reading, both Hall and optical, but that only gave ballpark figures and I never could get a reliable steady picture.
What actually works is measuring microseconds between the optical sensor (frame) interrupts. Use this to estimate FPS as 1.0e6 / frame_time_us and use this number to compute PIO clk_div. This recipe works really well and gets a rock solid picture regardless of any fluctuations in rotational speed.
Spectral but steady bunnies at any FPS between 10 to 40, although at 40 my LEDs get really dim, probably a limitation of long wires.
It is well known how unfilmable such displays are. In person they can be very ethereal.
Moved to Philhower core because it seems to be more PIO-friendly. Under Linux and platformio it works well. I'm using my Radxa Rock 5c as a dev machine for this.
Rather than making a large LED diffuser or projecting it on a screen, I tTried to embed diffusion into the disc itself: let the printer fill the holes with white plastic. I think it works, though 0.4mm was maybe too dense for this plastic and my weak LEDs. Will try thinner layers next time, maybe even a single layer.
PIO seems like a really nice tool for pushing out pixels. I prepared a checkerboard pattern and I'm spitting it out based on hall interrupt alone. What's interesting is I can adjust PIO clock divider based on current speed measurement rather than set speed.
Line and frame sync are still needed but I can already output a recognizable picture based on hall interrupt alone. Reduced rotation speed to 12.5 per second as it's generally more forgiving in every regard, including mechanical.
Funny thing, I don't seem to have any LEDs that are bright enough to test my disc.
Meanwhile I thought it might be useful to check out if I can use rp2040 PIO feature from Arduino. It seemed that Philhower variant is more pio-in-ide friendly so I decided to try and switch. Things really didn't go well from there.
Basically my picotool can't connect, UF2 upload kinda works, but the IDE hangs up indefinitely anyway, forced reboot still fails to boot, the COM port appears once out of 10 times I replug it. Only once did I manage to upload via picotool.
And when it booted, same code that controlled my motor somehow refused to spin.
I know this core is in fact a fairly good one and it's better in many regards. But I only used it with platformio in the past. I guess there's something rough around the edges with Arduino IDE integration.
Anyway, back to mbed for now.
I need something like a long SPI. For example for 32 pixels with 16 levels of brightness I need to push out 512 bits. Some SPI peripherals can do that, but I'm really not sure if the combination of rp2040 + mbed + arduino ide is the best choice for things like that.
Unfilmable bunny photographed. Oscilloscope in the background shows white paint spoke reflection (large) and black spoke reflections (small).
Rock solid bunnies.
