Part 21: Assignment #8: Virtual Reality Buzzer

Virtual Reality Buzzer





Ooh, this seems like a cool idea. And— man, I gotta congratulate David in person when I next see him!
Now, let's see what the specs are for this thing.







Uh-oh.
The bit with the radio seems straightforward. That's not the problem. As the datasheet says...


What the problem is is that the buzzer isn't a straight on-off output like I expected. You have to pulse it. And 'off' packets can come in at the end of a pulse or right before the beginning of the next one, so it looks like ignoring input until the start of a new pulse is right out.

I think the best way to do this might be to join two MCs together (I knew this'd be the case sooner or later). MC #1 samples info from the radio, and sets its output pin to on or off depending on whether the buzzer is supposed to run. MC #2 pulses the buzzer whenever its input pin is on.

Seems pretty simple, when broken down. What could go wrong?

[ ~ ]



 

This is the first prototype. It behaves exactly like I described above (the tcp in the first MC lets it check for 0, 1, and -999 without having to store the value from the radio), but you might notice something strange about the second MC.
It turns out there's something I didn't know, or didn't realize, about chip timing:

Suppose you have two MCs connected two each other, by simple I/O ports. Chip #1 sends a value to Chip #2 midway through its script.
Chip #2's script is still running while Chip #1 gets its value ready to send.

Let's say Chip #2 is supposed to read the value that Chip #1 sends. If the "read data" instruction is earlier in Chip #2's script than the "write data" instruction is in Chip #1's, the write will happen after the read and the read will get the old value from the pin.

This is what happened to me while I was building the prototype. The effect was to make the buzzer start pulsing late.

 

This is what the 'nop' instructions are for in MC #2. 'nop' stands for "no operation" - literally, "do nothing". They're just there to make MC #2 wait for MC #1 to tell it what to do.
There's an unfortunate side effect of 'nop'. Unlike 'slp' instructions, 'nop' instructions do consume power at the usual rate. I'm paying electricity to have the chip stand around idle, and it shows. The simulator says the design has an average power usage of 348 units, which feels kind of high for this application.

There has to be a better design out there - but what? I'm going start by going back to the drawing board and trying to do it all with just one MC, maybe a MC6000. The script'll be a bit more complex, but it'll almost certainly be more efficient.

[ ~ ~ ]





Here's what I came up with. It's 10 lines of code, so it does need the MC6000, but the simulator says it's more efficient (284 average power - about a 20% savings over the original). Slightly cheaper, too, so that helps it as an impulse buy.

The first few lines are like MC #1 from the original prototype - testing the radio input, then setting dat to indicate whether the buzzer's on or off. acc is used to store the current state of the buzzer - it's set to 100 when the buzzer's switched on, set to 0 when it's turned off, and pulsed with the not / moved to the output the rest of the time.
I'm still not that satisfied with this design, though I can't see a good way to improve it. It looks like you do have to check the radio every cycle to be able to stop the pulses on time, and that's the real stumbling block here... right?

Let's send it out and see what response I get.



Just a note: that's David's first response, and it does work great for him 'cause he's got a quality headset. Regarding selling it to act as an accessory, David did note that some of the lower-powered VR headsets on the market might not quite be able to drive the current version's power requirements - the device needs to use at least 30% less power* to be compatible with everything. It feels like a better-optimized version is out there somewhere... but how?

_{*About 200 units or less, on average.}

Readers, can I ask for your help with this?
(I'll post a Engineer's Corner about the ways you can wire MCs together once we get this sorted out.)