Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Absolute position #5

Open
JamesNewton opened this issue Oct 21, 2024 · 5 comments
Open

Absolute position #5

JamesNewton opened this issue Oct 21, 2024 · 5 comments

Comments

@JamesNewton
Copy link
Owner

JamesNewton commented Oct 21, 2024

The analog reading of our position in a single slot is an "absolute" position, not relative (like a standard quadrature encoder). Just being able to find position inside each slot doesn't tell us which slot we are in. With Single Track Grey Codes we can provide an absolute position to a single slot.

The STGC Explorer shows the know working codes, helps to validate possible new codes, visualizes the sequence and sensor position, and then produces the C code to decode the readings.

Single Track Grey Codes would allow us to know that with only one extra track. A new file has been added which incorporates this ability. It needs to be merged into the main file and holes for the sensors added to the support plate.

image

@JamesNewton
Copy link
Owner Author

JamesNewton commented Oct 26, 2024

STGC now incorporated into the full assembly. Still need to add holes in the base plate for the sensors
image

@JamesNewton
Copy link
Owner Author

Changed the setup to use the washer under the disk as a white paper STGC mask against the black primary slot disk with slots for the sensors in the base plate.
image

The sensor we are trying first is the OPB702

var stgcsens = square({size:[4.78, 12.2], center: true})

the idea is to partially stick the sensor into the base so that the focal point is about right. It wont take the full depth of the sensor for the normal mount, but just the little bit of the sloped part near the slot.
image

@JamesNewton
Copy link
Owner Author

JamesNewton commented Dec 16, 2024

From the datasheet at:
https://www.mouser.com/datasheet/2/414/OPB702-3241541.pdf

VF Forward Voltage (Infrared LED) ‐ ‐ 1.7 V when IF = 20 mA
IR Reverse Current ‐ ‐ 100 µA when VR = 2 V

From any basic USB supply I have a lot of current (a couple amps) at 5 volts, and about 0.2 amps at 3.3 volts from the Pi Pico's onboard regulator.

The number of LEDs is generally fixed, but may change. Probably 7 for now, but it might be 6, 7, 8 or 10.

So my first dumb idea is to connect them in series and add up the voltage drops which are 1.7 volts each. So I can run like 3 in a chain from the 5 volt rail: 5/3 is 1.666 volts. But that doesn't work well because I want 7 LEDs total. If I wanted 6 (or any multiple of 3) it would be just perfect.

But I'm not 100% certain I want 7... I might want 6 or 8 in the future. If it were 9... but it will never be nine. It will be 6, 7, 8 or 10. Probably 7. If I go to 6, I will revisit the serial chain.

So, better option, run each with its own current limiting resistor. Resistors don't cost anything, effectively. R = (Vsupply - Vf) / If; For 20mA and 1.7 Vf that is (5-1.7)/0.02 = 165 ohms. So pairs of 330 ohm resistors, or perhaps a single 220 would be good enough?

Ok, actual questions:

  1. Am I missing a trick? e.g. the individual resistance / LED pairs are best?
  2. Would a 220 work? Or do I really need to burn two 330s? Testing is in order.

@JamesNewton
Copy link
Owner Author

Using an Arduino UNO with my easy interactive script with the photodiode plugged into A0 and A1, the LED cathode on GND and a 220 ohm resistor from the anode to pin 5, and the setup string "14L15P5H" (A0 is pin 14 set to digital "L"ow, A1 is pin 15 set as an input with "P"ullup, Pin 5 is set "H"igh) I can send "?" and see A1 going between 200's and 900's when a bit of cardboard is held a few mm over the sensor.

@JamesNewton
Copy link
Owner Author

Updated the STGC Explorer to put out C code to initialize an array with the position for any read index.

It should be possible to read all the GPIOs with gpio_get_all
static uint32_t gpio_get_all (void)
and then extract just the ones we want. The order isn't documented, but we assume it returns values in order of GPIO number? Time will tell. As long as we get the bits we want all in one lump, it's easy to extract them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant