Last modified: 2024-11-18 15:53:38
< 2024-11-16 2024-11-18 >I have this in CAD:
A slotted disc on the balance shaft, with slots 4 deg. wide, so there are 45 slots and 45 antislots. The phase changes every 4 degrees. So to get the sensors out of phase they need to have a difference of 2 deg. mod 4. I have them 14 degrees apart, which should do the job.
So now I need a housing, but I was wondering where to put the microcontroller, and what microcontroller to use.
I could drive the light gates directly with a Raspberry Pi. That has the advantage that it comes with wifi access so I can easily hook it up to serve over the network regardless of where I put it, potentially reduces overall component count.
But if I want to work with the data on my desktop, then it might be more convenient to just have a microcontroller writing data over USB serial. That can always be consumed by a Pi at a later date if necessary.
And if I use a microcontroller then I can put the microcontroller in the same housing as the light gates, and just run a USB cable up to the housing. Whereas a Pi is a bit more bulky so I'd probably want a custom cable going up to the housing, and the housing would only hold the light gates.
One benefit of a microcontroller is I might get more precise timing because I can use interrupts more easily, and I will have the consuming side on the PC (or Pi) correct for drift by syncing with NTP or something.
I think I need to know whether I am going to use a microcontroller or not before deciding where to put it. And I need to know how to use the light gates before deciding whether to use a microcontroller. So the next thing is to get it hooked up and working on a breadboard.
There is no documentation to say which pin is which. Ah, it is marked on top:
I expect I need a current-limiting resistor to drive the LED.
I found this pic on DuckDuckGo image search, I'll start with that:
Lol great, the eBay listing has:
Does that mean the sensing side is wired backwards compared to the other diagram?
According to https://electronics.stackexchange.com/questions/247266/can-i-reverse-bias-the-base-emitter-of-a-bjt-transistor it is probably safe to reverse-bias it, so I can just test both and see what works.
OK, I have it working. It is indeed opposite to the picture from DuckDuckGo, matches the one from the eBay listing. I have a 220R resistor on the LED and 3k3 pull-up on the output.
I'm going to use an ESP32 in the housing.
I have put this together:
What a mess! I should have made a PCB for it probably.
This is running off 3.3v instead of 5v, so it is possible it won't work. Fingers crossed though.
Next step is get the ESP32 tooling installed and see if I can get it to read the light gates. Then finalyl model the housing to hold it all in place. I remember the ESP8266 ran quite hot, maybe I should glue a heat sink to this and make sure the housing has vents.
https://docs.espressif.com/projects/arduino-esp32/en/latest/installing.html
I got the tooling installed and wrote the program to the device, and I know it is running because it is writing 0's to the serial port, but it isn't detecting any light interruption :(.
There is a VUSB pin, I wonder what happens if I connect this stuff up to VUSB instead of 3.3v?
Are the input pins 5v safe? Let's just try it and see what happens. Hasn't helped, still just reading zeroes.
Ah, do I need to set pinMode to INPUT? Perhaps I could have ditched the pullup resistor by using INPUT_PULLUP.
Setting pinMode to INPUT has worked! And it seems to be working on VUSB so I'll just leave it. Working
on both encoders.
So now I need to see if I can get them to trigger interrupts.
Good, works. I have:
volatile int num = 0;
void inc() {
num++;
}
void setup() {
Serial.begin(9600);
pinMode(D5, INPUT);
pinMode(D8, INPUT);
attachInterrupt(digitalPinToInterrupt(D5), inc, CHANGE);
attachInterrupt(digitalPinToInterrupt(D8), inc, CHANGE);
}
void loop() {
Serial.println(num);
delay(10);
}
And as I slip a bit of paper in and out of each light gate, the number goes up each time.
So I'm satisfied that I can make a quadrature encoder with this. Next step is making the housing.
Current mood:
It has a couple of M6 mounting holes, a slot in the back for the USB-C cable, and is hollow inside to hold the electronics. Needs some screw holes to allow affixing the bottom cover, and then I think print this now before designing the bottom cover, see how the parts fit inside, and design the bottom cover to clamp everything nice and tight. I'm rapidly losing any idea of making a second one of these. If I want to make more I should use a PCB or some other method to make sure everything is in a consistent place.
Maybe I should have done the thing about putting holes in the inside of the housing to wrap components around? Basically like mounting holes for through-hole components, except there's nothing to solder to, you just use it to constrain the components and solder them together with wires.
I have written the code to implement the sender and receiver, and captured this:
Result! It is working perfectly. X axis is microseconds, Y axis is quadrature ticks. I still don't have the actual housing so I was just holding it by hand, bumping the slotted disc, etc., but this is really promising.
And I now have a realtime javascript web viewer.
The web viewer wants:
Great success, got that. This is getting pretty good.
Longer-term I think I'll want a quite different type of web UI that will just show amplitude and frequency over time, and not individual encoder readings. But for now this is good. Once I have it inside the actual housing and mounted on the frame I will work on getting it to show live amplitude and frequency readings.
https://github.com/jes/clockwatcher
< 2024-11-16 2024-11-18 >