For the longest time I have been wanting to use Evernote to store my notes. But one major issue has been preventing me from doing that every time I tried to switch from a bundle of markdown files to Evernote: the fact that Spotlight search in Evernote notes didn't work.
There are many comments and suggestions out there but I finally found a solution that worked for me:
I needed to make a Bluetooth LE device that required a more secure pairing with the companion iOS app than just "Click Pair to connect…".
This can easily be implemented in BTLE using a bonded, encrypted connection with man-in-the-middle protection enabled. But the device needs either a display to show the code which should be entered on the iOS device, or a keypad to enter the code shown on the iOS device. If the device has neither, then only the "Just works" method can be used. And this will not prompt for a passkey/PIN code.
"But can't I just hardcode a PIN code in the firmware," I asked Google. And Google said, "No, fixed-passkey authentication is not supported in Bluetooth LE."
But it turns out that there is a solution: pretend the BTLE device has a display and specify a hardcoded passkey in the config.xml file. That way, instead of generating a random key to display to the user, the hardcoded passkey will be generated instead.
UPDATE: BLE112 firmware source code can be downloaded here: BLE112 iBeacon firmware. It should be pretty well documented so please try to figure it out yourself before asking :)
Here's a snap of the first two "production" iBeacons (not really production models but a lot prettier than the previous mess-o-wires prototype). They are based on BLE112 Bluetooth modules and contains nothing more than a coin cell battery, a tiny DIP switch for configuring the device identifier without re-flashing the firmware, a capacitor and a diode for reverse polarity protection when external power is used instead of the coin cell battery. And a BLE112 module, of course.
Here are the Eagle files for schematic and board:
The firmware source code can be downloaded here: BLE112 iBeacon firmware.
Yea and verily! I've successfully flashed a BLE112 with firmware that makes it behave as an iBeacon that can be used for iOS 7's Bluetooth LE location services.
By using a CC2540 USB Dongle and TI's SmartRF Packet Sniffer application and an iPhone running a sample app provided by Apple on the Development site, I reverse engineered the iBeacon protocol and made a firmware project for a BLE112 using a minimal GATT profile and a BGScript to set the custom advertising data required for a iBeacon.
I guess I'd better design a PCB for a minimal circuit containing a BLE112, a 3 V coin cell and a programming header.
Looking at some of my old schematics, I can see that I haven't been entirely consistent when naming components. Nowhere near consistent, actually.
Sometimes I have used "T" as prefix for transistors and sometimes "Q". And especially IC's that are prefixed either with "U" or "IC" – often I have used both in a single schematic. And also connectors that are named "CON" or "J" or "JP". Sloppy…
Well, no more! This page on Wikipedia has a nice table with designators for various component types (even though it does not comply with with IEEE- or ANSI-whatever standard).
So this is what I will use henceforth:
|D||Diodes – all types including Zener, Schottky and LEDs|
|U||IC's of all kinds. Technically it is used for "Inseparable Assemblies".|
|J||Connectors. The more fixed part of a connector pair (often the part soldered to the PCB).|
|P||Plugs. The less fixed part of a connector pair (i.e. the one on the wire).|
|Q||Transistors – all types including MOSFETs, IGBTs, BJTs etc.|
|Y||Crystals and oscillators|
|X||Transducers/sensors (no, X is not for crystals anymore).|
|JP||Jumpers. Not connectors but only actual jumpers that are linked or unlinked.|
|TP||Test point (pad or pin for measuring)|
|MP||Mechanical parts (standoffs, screws, mounting hardware etc.)|
Apple has announced the introduction of Bluetooth LE-based positioning in their iOS 7 framework. Apps can now get notified when entering a region which basically is defined as being close enough to a BTLE beacon with a specific identifier.
The iOS framework already supports the concept of regions and notifications when entering regions, but until now the system has relied on GPS and WiFi positioning. Which will not be able to provide very accurate positioning data when used indoors.
Bluetooth LE-based positioning, however, will work just fine. And will be able to provide very accurate positioning data. Right down to "you are standing in front of this particular sculpture in the museum" or "you are standing at check-in counter number 18". Nice.
In keeping with the classic Apple way of doing things, Apple has decided not to use the existing Bluetooth Proximity Profile but do things their own way.
Since Apple has not published the specifications for the iBeacon protocol yet, I had to snif the Bluetooth packets from an iBeacon device (using a TI CC2540 USB Dongle and their SmartRF Packet Sniffer – http://processors.wiki.ti.com/index.php/BLE_sniffer_guide).
Apple puts all the required information into the advertising packets in a "Manufacturer Specific Data" field of connectable undirected advertising events.
Apple's iOS 7 pre-release documentation shows what properties are available for iBeacons (but I'm not going to tell you since that information is still under NDA) so they are fairly easy to spot in the advertising data and so it should be easy to copy – and if necessary modify – that data and put it into a BLE112 of my own.
I'll keep you posted as to how it works…
How, oh how did I ever live without it?
Just before Christmas I finally caved in (to myself) and got myself a decent bench-top power supply. A TTi PL303-QMD (datasheet/brochure here).
Yes sure, there are more advanced units out there but this one suits my needs just fine: dual 3 ampere outputs (which can be paralleled together for a total of 6 amps), voltage span setting (so the voltage dial only adjusts voltage from e.g. 3.0 to 3.4), 500 mA mode (allowing much finer control over the current setting up to 500 mA).
And now I can't imagine how I ever got by without it. So if you are considering splurging on a decent PSU, consider no more and get this one right now!
Success! I have managed to write and compile firmware for the FTDI Vinculum-II (VNC2) USB host IC so I can read HID reports from a Saitek Cyborg EVO joystick, parse the data into values for the X, Y, rotation and throttle axes and button states and transmit any change in values by UART which can be received by an MCU.
This is what I did:
First, I got a V2DIP1-32 development module. This is basically a VNC2 (the 32-pin version) on a PCB along with a 12 MHz crystal, a USB A socket, a 3.3 V voltage regulator, an LED and a couple of capacitors and resistors. In other words, only basic support components.
Next, I installed the Vinculum-II Toolchain (the development IDE) version 2.0.0 and then updated to SP1.
The IDE works ok. Especially the application wizard works well and gives you a good starting point for your own firmware by adding the necessary libraries, headers and scaffolding code based on your selection of IC, USB ports in use and required drivers.
But the IDE is Windows-only software… *sigh* I hate that. Fortunately I have my old MacBook Pro with Windows 7 on a Bootcamp partition.
Note: you don't need the VNC2 Debugger/Programmer Module to flash the VNC2 – the USB-to-UART cable is sufficient – even though the FTDI website states that the Debugger/Programmer module is required for initial programming.
On to the firmware itself. I did start by wasting a couple of hours by not reading the VNC2 dev board's datasheet closely enough to notice that the USB socket on the board is connected to USB port 2 and not – as I figured – port 1. After tweaking the supplied example project 'USBHostHID' and reading the documentation I pretty quickly had some firmware that did what I wanted: wait for a HID device with the specified VID/PID to be connected, read HID data, parse the data into corresponding X, Y, Rz, Z and button values and, if any values change, send the new values over the UART connection.
Here's the complete firmware project (including compiled .rom file).
And here is a sample dump of the UART output. If a line starts with a "S" it is a status message, if it starts with "E" it is an error message and otherwise it is a value update.
If you want to use this project to read data from your own joystick (and it's not a Saitek Cyborg EVO), you'll have to change:
- The VID/PID for the joystick:
// find VID/PID of Saitek Cyborg EVO device
hc_ioctVidPid.vid = 0x06a3;
hc_ioctVidPid.pid = 0x0464;
parse_hidmethod to match your own joystick's HID descriptor.
As part of using a USB joystick as input device to an MCU I needed to parse the raw HID data of the joystick into values on the various axes and button states.
This is the first time I have had to manually get from a HID descriptor and some raw data to something that makes sense.
For the Airsoft Round Counter project I need some way of detecting when a round is fired and (like most people suggest) a photo interrupter is ideal for the purpose.
Basically, a photo interrupter consists of an LED (usually an IR one) and a photo transistor. A photo transistor works like a normal transistor but instead of a current at the base, it requires light to turn on the collector-emitter current flow. In a photo interrupter the LED and the photo transistor are mounted in small posts and when nothing interrupts the beam, the transistor turns on, passing a current from the collector to the emitter. When the beam is interrupted, the transistor turns off.
A photo interrupter has four leads or connectors: anode and cathode for the LED and collector and emitter for the photo transistor.
To use it in as a digital input for a microprocessor, you can create a circuit like this:
R1 limits the current to the LED (using the normal LED calculations having obtained information about the LED forward voltage and desired current from the datasheet – typically something like 2.0V and 20 mA).
When the photo interrupter is not interrupted, the input reads 0. When an object blocks the beam, the input reads 1.
This document from Lite-On has some excellent information about using photo interrupters (after the list of their products).
A microprocessor needs a component that generates clock signals which basically control when and to which beat everything happens.
The ATmega MCUs have a built-in "RC oscillator" but you can also use an external resonator or crystal. The easier the solution, the less precise clock signals will be generated (ain't no such thing as a free lunch :-).
The easiest solution is to use the built-in RC oscillator, the second easiest is to use an external resonator which doesn't require any other components and the lastly you can use an external crystal and a pair of "load capacitors".
If you don't need precise timing the internal RC oscillator is completely adequate but if you use serial communication or other tasks where precise timing is required, you should use a crystal or a resonator.
Read this excellent guide to choosing a clock source: Why you need a clock source - an introduction to choosing and using clock sources.
When using a crystal two capacitors need to be connected from the crystal to GND. Usually a "load capacitance" is specified in the crystal's datasheet but this is total load capacitance so you need a different capacitance for the two parallel capacitors. To find the required capacitance (rLC), the following formula can be used:
rLC = 2 x (LC-PC)
where LC is the specificed total load capacitance and PC is parasitic capacitance (from nearby wires and circuit board etc.) which is usually between 7 and 10 pF.
Another useful formula is this one which is used to calculate the load capacitance when using two capacitors of a capacitance of rLC:
LC = rLC^2 / 2rLC + PC
An example: this 16.000 MHz crystal requires a load capacitance of 30pF. Using the first formula yields using a rLC of 40 pF:
rLC = 2 x (30pF - 10pF) => rLC = 40pF
However, if you don't have all exact size capacitors in stock (I know I don't) you can choose the nearest and use the second formular to check what the load capacitance will be. So for two capacitors of 39 pF (again using a value of 10pF for PF) we get:
LC = 39 pF x 39 pF / 2 x 39 pF + 10 pF => LC = 1521 pF / 78 pF + 10 pF => LC = 29.5 pF
which is close enough.