I have a bluetooth keyboard that I use on a regular basis. It has a Logitech logo, but is manufactured by ZAGG and has model number Y-R0023.
I have paired the keyboard with my Ubuntu desktop and it works great.
Upon powering up my computer and keyboard, I can sometimes reconnect without having to pair again, but other times I have to remove the existing pairing and reconnect before Ubuntu can receive keystrokes.
Extra information: Ubuntu displays a bluetooth symbol as a status when it connects (regardless if it is able to receive keystrokes or not). This symbol will appear and disappear roughly every 10 seconds until the two devices are able to successfully negotiate a valid connection.
I notice that I have best success when I press 'delete-delete-enter-enter' after powering the ZAGG keyboard up. (Sometimes, just repeatedly pressing a key every second or so seems to work too.)
I am wondering if the "delete-delete-enter" keystroke combination (or some other that I haven't discovered) is recognized by the Logitech BIOS as a special sequence to help retry a paired re-connection. I'd be interested in finding out if this trick works for devices other than those made by ZAGG. Otherwise, it would help just to know if there is a reliable script I can run that calls bluetoothctl to help improve the re-connection. (I want to avoid having to enter a pairing code on subsequent connections).
ZAGG sites and Logitech ones don't say anything about this key combination. So I don't think it's recognized as a special sequence, only advice they give is to re-pair the device when it's not working.
In summary I'm sure they would include this troubleshooting option in manual and/or troubleshooting guide if it was present.
I have an (Adafruit Feather Huzzah) ESP2866 WiFi module which has an (EN) pin to disable the 3v3 output on the chip. This pin is pulled up by default and normally you would just connect it to GND in order to switch off the 3v3 regulator (and disable the peripherals).
What I am trying to achieve is that when the ESP2866 is in "Deep Sleep" mode that the 3v3 output is disabled. Ideally if there was a pin that was pulled down by default when the device is asleep then I could just hook that into (EN) pin but I don't think this exists. However, there are pins that are pulled high by default when the device is fully awake.
What I was considering doing was using a high value resistor to create a weak pull down on this pin by using this to join GND to (EN). Then I would also directly join another pin that is pulled up when the module is on to "cancel out" the pull down. I have a feeling that I might need to end up using a transistor (or a few components) to toggle this low.
Reading the Adafruit forums I have since discovered that pulling the EN pin also switches off the ESP2866 internal circuitry so it will never come back out of deep sleep. On this basis there is no solution to this specific question as there will never be a high pin (without some form of external circuitry).
Thanks to those who bothered to read.
I'm working on a project with Android and Arduino and am trying to figure out how on the Arduino side to tell if the Bluetooth is connected or not.
I'm using one of these Bluetooth Modules to connect. I know I can send a command through Android, but I'm trying to have an action happen automatically when they connect and not have to run a background application on the Android if possible.
Using the module supplied and nothing else you cannot: notice the module has four connectors:
Power (Vcc)
Ground
Tx (send)
Rx (receive)
Given this interface the only way to determine whether the bluetooth module is paired is to send something to the paired device and have it respond in such as way that your Arduino knows that it is connected. For instance, if your Android program always responds with "Hi there!" when it receives a string "Hello?", then by seingin "Hello?" your Arduino will know that it is paired with your Android phone/tablet. Your Arduino could poll (send the interrogation string) every minute (or every five seconds) to see if it is paired with your device.
There is a better way, but it will require some soldering on your part. If your module is HC-03/HC-05-based, then the PIO9 pin is the "paired indicator LED" (see datasheet here). You could connect that pin to an Arduino input pin and read the level: reading digital 1 will indicate that the device is paired, while reading digital 0 will indicate that it is not. It is possible, though not certain, that the pin on your module labeled STATE is exactly this kind of a pin, i.e. it indicates the paired status. Unfortunately. this pin it isn't connected to the header, so you'll have to solder a wire to the correctponding pad to connect it to your Arduino. You should test it first by connecting a multimeter in voltage mode to that pad and measure the potential between that pad and ground in paired and non-paired state. If this is the pin that responds to the paired state then you are golden. It might be that it indicates power (like the HC-03/05 PIO8 whilc blinks when on). If it turns out that the STATE pin is not the pairing status, then you should request a datasheet from your supplier, and use that to find the status LED connection: one is likely to exist. Once you found the correct pad, verify its function using the voltmeter again. Then solder a wire to that connection and read it from your Arduino.
IMPORTANT: Make sure that your Arduino never puts out a digital 1 on the Arduino pin connected to the bluetooth module status pin: these bluetooth modules run on 3.3V, and connecting any unprotected pins to 5V will be damaging. The Vcc and Txd pins are voltage shifted in the module you bought, but the LED/Status lines are likely not to be. So if the Arduino pin connected to "status" on your Bluetooth module is configured as output and you digitalWrite(HIGH) to it, you will likely damage the Bluetooth module.
Unfortuntaely, the HC-05 will switch states when paired, but won't output a 1 until it's actually connected to something.
For instance, I can unpair my phone from the HC-05, pair again, and then the LED will change state, but the output of the STATE pin is still 0. If I open up an app, and connect to the device manually then the LED, and STATE pin will change state. The LED will periodically blink twice, and the STATE pin outputs a 1 to the Arduino.
If you would like to read the the value of the STATE pin, connect a wire to any of the inputs to the arduino, and code Serial.println(digitalRead(inputPin)); inputPin being the wire to the input of the Arduino.
I've been fighting this thing for months, and have yet to find a way to make this thing automatically connect to my phone. It won't even allow for me to connect to it from my phone to the HC-05 unless I download an app onto my Android. It's possible to bind the HC-05 to a certain address, but even this did not work for me. I want to mess with the "AT+CLASS" command, but the documentation behind the instruction has hindered me thus far.
From the HC-05 datasheet we see that the connection status depends on the output from PI09. Apparently sending "AT+BIND?" to the module will return the status of PI08 & PI09 in the form,
"+ POLAR=PI08,PI09" however this makes no sense to me because in order to get this you must enter AT mode and entering AT mode will disrupt the paired connection, hence it will always send PI09 marked as "not connected".
THUS in order to see if the connection is still live from the arduinos POV I can only see 2 feasible ways:
Program arduino to, every so often, send a "hello?" and if it doesn't receive the expected "Hi back" response, then it is to assume that it isn't connected.
Connect PI09 to an arduino input pin and read it's value whenever you want to check if the connection is live or not
AT+STATE? will return the current state of the connection. Yes you will need to enter at mode, that is done by bringing up pin 11 HIGH on the HC05 module. It does require soldering but it's kinda worth it. It then allows full AT control of the device, then set it LOW to return it to normal working mode.
Another option, which I don't fully understand, is the AT+MPIO? command, which returns the state of all the pins in some strange masked format I don't understand yet.
I use the first option above so that I can terminal (Bluetooth) from my phone to the HC05 and switch on a led/relay etc (ie bring up pin 2 to HIGH) on the HC05. This required entering AT mode (pin 11 HIGH), sending the command AT+PIO=2,1 and then setting pin 11 to LOW to return to normal working mode.
Note: I noticed I had to put a 200ms delay in between high and AT and LOW commands. Angela's solution is nice - I use a cheap XBEE Bluetooth module (HC-05 Bluetooth Bee Master & Slave Module with Bluetooth XBee for Arduino uk2015) 2 units(HC05/6) for 5Stg which are laid out in XBEE format - handy for the 3.3v.
I have an SPI signal output from a SPI device. I wonder why the data output (MOSI) goes to 0 half cycle before the actual data is written on the bus? Is it a must condition for an SPI device? If it does not go to zero, would there be any problem on the data transfer?
I use spidev32766.1 on linux (ubuntu 12.04 - kernel 3.7.1), the processor is imx233
Thank you in advance!!
The slave device doesn't care what happens on the data line except for a very short period (usually <1ns) either side of its active clock edge (this window is defined by the setup and hold time specifications for the interface).
I have no idea why your system would put out that "wiggle" though!
When I press a keyboard's key on some GTK application under Linux, what happens exactly? How does a key get received (from which device), interpreted, passed to the program, and then handled?
It's actually rather a complex process...
The keyboard has a 2D matrix of key connections and its own microprocessor or gate array containing a microprocessor. It is constantly scanning the matrix to find out if any keys are pressed. (To save pins, the keys are not individually tested.) The keyboard micro speaks a protocol with the keyboard controller in your CPU and transmits a message indicating a keypress.
The keyboard controller notes the code and interrupts the CPU.
The keyboard driver receives an interrupt, reads the keycode out of a controller register, and places the keycode in a buffer that links the interrupt side of the kernel to the per-process threads. It marks the thread waiting for keyboard input as "runnable"
This thread wakes up. It turns out, this is the X server. The X server reads the keycode from the kernel.
The server will will check to see which window has keyboard focus. The window will be connected to one of various clients.
The server sends an event to the client that displayed that specific window. (Note that to the server, every textbox and such is a "window", not just entire applications.)
The event loop in the client is waiting for the next server event message. This connection could be via TCP or it could be a local Unix feature. It uses read(2) or a socket op to actually get the next event message.
The low-level xlib routine passes the keypress up to higher level widgets, eventually getting to a GTK function of some kind.
The GTK API element hands the character to your program.
I glossed over language mappings, console multiplexing, and a few other things...
Update: So, /dev/input/* and in fact all of the /dev/* things are things called block or character special files. The important thing is that they have no stored data in the filesystem, just a major and minor device number that serve to look up a driver in the kernel in a table. It's almost that simple. If you ls -l /dev/input you will see a major and minor device number instead of a file size. The major number identifies the device driver and the minor number is a sort of instance-number that is passed (within the kernel) as a parameter to the driver.