OptoSensor
As David Murphy mentions, a stepper motor solution needs to know where the arrow is pointing when the device starts up. Looking in the spares box, I saw I had a Omron EE-SY310 reflective sensor from an old tachometer project, I used the phone camera to test the IR LED was working. This device has an open collector output so it will pull a floating signal to ground.
There does not seem to be any configurable pull-ups on the Azure Sphere so I added my own pull up resistor between O and V on the above diagram. The LED anode was wired to one GPIO via a current limiting resistor and the cathode to ground. The sensor output was connected to another GPIO. I used the second header so not to clash with my stepper motor wiring. The code was adapted from the blink, using the EPOLL timers which seems to be a Linux like way of handling timers.
See https://www.systutorials.com/docs/linux/man/2-epoll_ctl/
The sensor output was simply mirrored onto the red LED on the board so I could confirm it was working.
I need to solder in my pull-up and then create a way of mounting a the sensor next to the motor. I'll likely design something that can be 3D printed as I already have some of the designs from another project. Whilst I'm doing that I'll design an arrow to point the way too.
Once I've got a working motor with slotted sensor disk, I'll merge my opto-sensor code into my stepper code and add a "home" feature.
More on this weeks SDK and Device update
One of the things mentioned in the new features post is an external MCU update. This is a sample app that demonstrates uploading code to a Nordic nRF52 Development Kit over UART (bluetooth). The approach for this is to include the data for the external MCU as a "resource" in the code. This allows both the application code for the sphere and the external MCU to be deployed via the same mechanism. I'll look into how hard this is to do and see if it can be used for configuring the GNSS receiver. A lot of the code in the sample app seems to be specific to that Nordic dev board so I suspect my example could be a lot simpler.
Another thing mentioned is that the default the "Strict" option for the C which is why some of the code changed for blink. However there are also some changes around how the timers are coded so the APIs are in flux too. It's also possible to target some of the "Beta" interfaces which I suspect will be changing even more so I'll be avoiding those if I can.
Reviewing the board update process I do believe I got the expected outcome. The notes suggest that future updates will be simpler and automatic (assuming you are on the network).
Motor Mount
I've put together a design for a mounting plate for the motor and sensor using Fusion360. I'll also be creating a pointer and and reflector before printing them out.
There's a few issues with this initial design. I needed to trim back the holes for the mounting lugs as I'd undersized those. Also the tray for the sesor is not quite right so I'll dremel this one and reprint if necessary.
