I'm considering a number of possibilities for rfkill functionality in the next Anelok version. I already asked about the switch a while ago and there didn't seem to much enthusiasm either way. Let's do one more check.
What we had in Anelok version 0: a bulky switch that would add a resistor to the power supply path, thus ensuring the system can't draw more than very little current - not enough to do anything "bad". Problems with the approach include that the MCU must react very quickly to this change, since it'll just empty the capacitors and stop working if entering extreme low-power mode takes too long. Also, "stop working" may be an unstable state, with the MCU oscillating through reset. What we have in Y-Box: a much smaller switch that shuts down the RF chip by conecting its positive supply to ground. The MCU is not affected by this switch (except that it can detect the state of the switch and react correspondingly.) One consequence of this design is that, while the MCU remains fully operational, it no longer receives a crystal-derived clock from the RF side and therefore - lacking a crystal of its own - can't maintain USB communication. In the case of Y-Box, this hardly matters because all the MCU does here is relay things between USB and RF, and process data related to RF. So - in Y-Box - if RF is dead, the MCU can take a nap, too. For the next Anelok board, there are several options; 0) no rfkill functionality at all, 1) "soft" rfkill by just politely asking the RF chip to refrain from going on the air. The user would select rfkill via the GUI. For this to work, we need to be able to trust MCU and RF. 2) "semi-soft" rfkill by controlling the RF chip through its debug interface. Again, the user would select rfkill via the GUI. In this case, we need to trust the MCU and the RF hardware. 3) "three quarters hard" rfkill. As above, but there would be a mechanical switch that asks the MCU to take down RF. Same trust requirements as for 2). 4) "hard as a crowbar" rfkill. The Y-Box approach. Since we'll probably want to be able to use USB while rfkill is set, the MCU would need its own crystal. 5) like 4, but when detecting that rfkill has been applied, MCU voluntarily shuts down, too. The switch would thus act more like an on/off switch, but allowing the MCU to still run an oscillator for timekeeping. This would be similar to what I tried to do in board 0. No extra crystal needed in this case. Note that options 0 to 4 differ from the dubious contraption in Anelok board 0 by only disabling RF but allowing the MCU to do whatever else it wants. Since we have to largely trust the MCU anyway, this doesn't seem to be a major loss. Implications for hardware design: - 0, 1, and 2 don't need any extra hardware. - 3, 4, and 5 add back a switch, though this time I'd use the small one from Y-Box, not the monster from Anelok board 0. - 4 adds a crystal, too. The switch occupies about 36 mm^2 of PCB space (including pads and clearance, not counting traces), a crystal occupies at least 33 mm^2 (crystal, load capacitors, minimum ground ring). BOM cost is USD 0.46 for the switch (Digi-Key, 1000 units), and the crystal is 0.42 @ 1000. Reel prices are 0.416 @ 2500 for the switch and 0.382 @ 3000 for the crystal. The cost of the load capacitors tends to be negligible. Opinions ? - Werner _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
