Anti-Papparazzi Hat

I've just added an initial rendering of what's on my breadboard for the moment (omitting all unused components :-).

Component values are to be decided. Right now the PLL takes about 30 sec to get into lock, a little to long time for my taste. I assume the rotational speed of the scan head will vary when carried around mounted on a hat. So the PLL probably needs to be a little more agile. I'm also not sure if I drew the feedback filter the same way as it is connected...

There is also a first draft of layout and routing of a board. I've not yet decided if this will be a custom board or just built on some veroboard, so I've tried to keep most connections "in line".

The instructions were to have at least 4 log posts. So here goes...

Everything is built on a breadboard. Schematics will come but only exists in my head for the moment. There is nothing that couldn't be deduced from the system design except perhaps for the revolution sensor that is darlington connected for amplification and fed into a comparator with hysteresis feedback. There is 3 unused comparators in that capsule so perhaps I will use one of them for conditioning the main sensor.

The main sensor isn't yet mounted in the head so I haven't been able to determine the viability of this project yet. Is the emitted laser light enough energy and in the right wavelength to get a retro reflex? Is the sensor sensitive or fast enough to detect the reflex?

Other things on the todo-list is to build a lock-detector for the PLL and only turn on the laser when the head is actually spinning (a tiny bit more eye friendly) and implement an app for the phone.

Another display solution could be to map detections onto a led ring that the user wears on the wrist as a watch.

I will try to explain some small quirks in the software implementation of the uart.

First looking at it it loads a value of 9 into a variable "putch_cnt", but the comment says "1 start bit + 8 bit + 1 stop bit" which is 10. The reason is that the loop-checks are done at the end of the loop not in the beginning, compare do...while(); and for(){...} loops in C. On the first iteration the counter is 9 and on the last it is 0, but the loop exits only when the zero:th iteration is executed.

The variable containing the output char is used as a 1-bit 8-deep shift register. 

Before going into the first iteration the Carry is set high, to eventually output a stop bit, and output pin is set low, to output a start bit.

The first part of the loop a bit delay busy-wait inner loop.

Then the next bit value is shifted into the carry flag (thereby shifting the "stop bit" into the "shift register", and that will come out again on the last iteration.

The carry flag is double checked to avoid glitches in the output.

The loop counter is decremented and te loop starts over with the bit delay.

Due to the delay in the beginning of the loop the last iteration (stop bit) will get no delay, so an extra delay loop is placed afterwards together with some 2-cycle NOPs (goto $+1). The extra delay is to make sure that the stop bit is the same width as all other bits.

This will document some decisions on the divide by 360 function in the mcu.

I wanted the reaction time to a full 360 count to be as small ass possible, to minimize the jitter to the PLL comparator that will introduce oscillation in the feedback loop.

As the value 360 is greater than 8-bit max (255) an 8-bit timer would need some software bit extension to make it a needed 9-bit, with some cumbersome reloading of counters. Also the Capture/Compare/PWM module is connected to timer 1 and that looked from the onset as a function that would be useful.

That is why I choose to implement the counter on timer 1, as it is 16-bit wide. It is configured in external synchronous clock mode. I would like to use asynchronous mode (again to reduce jitter) but it is not recommended for use with the compare module.

To count 360 pulses the Capture/Compare/PWM module is set in compare mode, with an interrupt generated when timer 1 is equal to 360. The hardware is responsible for resetting timer 1 to 0.

An alternative would be to preload the counter with 35535-360 and use the counter overflow, then the CCP-module could be set to capture mode upon receiving a detection, but I couldn't get it to work that way. It would also mean that timer 1 would have to be reloaded on every overflow and perhaps the value trimmed to account for the delay of reloading the timer.

To further minimize jitter the compare interrupt is the only interrupt. Serial communication is bit-banged in a bussy-wait loop. The "interrupt-on-change" function is used as a SR-latch on the detector input but isn't allowed to actually interrupt the processor.

I have made the sources for this available at github. https://github.com/LeHonk/antipaparazzi

And hopefully will be making a video tonight just minutes before dead line :)