Yes! Currently i try to make a joystick.
UPDATE: 2015/1/13
I finsihed joystick control UI.
Thanks for release of protocoll
I wrote a windows phone app for my personal use.
You can find the official protocol sheet here: https://social.sbrick.com/wiki/view/pageId/11/slug/the-sbrick-ble-protocol
(We are filling up the wiki pages, not published yet)
My BLED112 arrived and here is a quick guide on how to use it with the sBrick (in case that someone else orders it, too):
PREPARATION:
-Plug the Bluegiga Bluetooth Dongle into the USB Port
-Install the driver for it (see "PC Tools"): https://www.bluegiga.com/en-US/products/bluetooth-4.0-modules/bled112-bluetooth-smart-dongle/documentation/
-Download and install the "Bluetooth Smart Software (see "Software Releases")
-Start the application
-Press "Connect" to connect to the Bluegiga Bluetooth Dongle
-Press "Scan" -> "Start" to search the dongle
-Select found device and press "Connect"
-Press Encrypt (optional)
-Press "GATT"
-Press "Descriptors Discover"
-Search Uuid "02b8cbcc0e254bda8790a15f53e6010f" and select it
-Enter command into the command prompfor your SBrick
-Press "Write Command"
MODE:
00: Break
01: Motor Control
Motor Control Mode:
01 01 01 FE
MODE PORT REV? Speed
MODE:
Select the right mode
PORT:
00-03: One of the four motor ports (you can find the port on the attached image)
04: Lamp
REV?:
00: Not reversed
01: Reversed
Speed:
Speed between 00 (0) and FF (255)
Note: only to FE with the stock FW due to a bug
Break Mode:
00 01
MODE PORT
PORT:
00-03: One of the four motor ports (you can find the port on the attached image)
DO NOT USE WITH LAMP
There will be a workaround in the App, the new iOS app already has a workaround, and I put that into the Android yesterday afternoon (along with a few fixes including the dreaded discovery bug).
V3 protos can't be updated via air, only by specific programming hardware. And that would break them, since they have slightly different hardware.
The V4.1 can safely be updated, but there's little difference between the 4.1 proto and production firmware. Actually so little I did not bother bumping the version either.
The factory firmware on the chips is V4.0, that's the firmware with the "dark LED" misfeature. :)
OTA will be required for the security function, the battery and temperature reading, and the more advanced features too.
[blockquote]Tamás Fábián said:
The 255-STOP is a BUG with capitals :(
A firmware fix is already available, "only" app support is missing at the moment. Actually the current iOS version can do OTA OK, but we're still waiting for Apple to allow our last update.
[/blockquote]
Fine! I wrote about this issue also in the Beta Testers group.
Thought the change was intentional and that you need to update apps to range from -FE to +FE only.
Quite unlucky for you to have made such error in the FW exactly when you was shipping a few thousands of them. Then you need all users doing the OTA to upgrade their firmwares.
That's why I thought you were going to solve the issue via app, or there was a major plan to use FF value for soemthing else. :)
But if there is a new FW available to upgrade now via iOS, I think I'll risk my first OTA upgrade tonight. :)
Can you tell me if it is also safe to try the upgrade with the V3 and V4.1 prototypes?
It would be also nice to have a read command that tell us which is the FW version installed in the SBrick.
Also the version of the app installed, acessible from the app main menu. ;)
Best,
Fernando
It seems a «feature» of the actual firmware. Beta SBrick firmware accepted and used 255. First production SBricks do nothing with 255 (both rotation directions).
Set max to 254 AND wait for next firmware. Future firmware versions may change again so its good if your app tolerates that. I'm not sure if the chipset they're using allows them more than 8 bit resolution for the PWM control... if it does, changing to 12 bit would mean changing MAX to 4095.
I`m testing own application too (for iOS).
When I send command "01 00 00 255" - full thrust on channel 1 (00), it`s not working. But for values "01 00 00 0-254" it works very well. Because I do it as slider it`s same "bug" as SBrick port tester - in maximal values it`s not working.
It`s wrong on protocol or firmware side? In other works - I have to change maximal values to 254 (is very quick fix) or waiting to next firmware?
Thanks for answer.
Nice playing with SBricks for everyone :-)
After several days of testing, I finally succeeded in using WP connect to SBrick.
The following is the code:
DeviceInformationCollection devices = null;
Guid remoteControlService = new Guid("4dc591b0-857c-41de-b5f1-15abda665b0c");
Guid remoteControlCharacteristic = new Guid("02b8cbcc-0e25-4bda-8790-a15f53e6010f");
devices = await DeviceInformation.FindAllAsync(
GattDeviceService.GetDeviceSelectorFromUuid(GattServiceUuids.GenericAccess));
if (devices.Count > 0)
{
DeviceInformation device = devices[0];
BluetoothLEDevice bleDevice = await BluetoothLEDevice.FromIdAsync(device.Id);
GattDeviceService gattDeviceService = bleDevice.GetGattService(remoteControlService);
GattCharacteristic gattCharacteristic = gattDeviceService.GetCharacteristics(remoteControlCharacteristic)[0];
}
The suggested bluetooth dongle https://www.bluegiga.com/en-US/products/bluetooth-4.0-modules/bled112-bluetooth-smart-dongle/ has it's own bluetooth stack and software interface. I will probably use that one first. After that I'll think about integrating support for other sticks (which probably need Windows 8).
Wow, that seems quite sufficient.
Technicmater0 I'd love to know what you're going to use to communicate with a BLE device. There don't seem to be a lot of libraries available for that, but to be honest, I haven't dug into it a lot yet.
As a C# developer it would be peanuts to make an application to play around with.
Very interesting information, I'm ordering the BLE dongle as we speak. Hoping to do some testing with building an Windows application myself, first tests with Nordic Semiconductor's nRF Master Controller were very promising. Only thing I'm a bit worried about is if there's a big chance to 'brick' my brick in case I'm making mistakes and send wrong commands to it? This will be interesting...
By the way, if anyone is already building something, feel free to share your work on github or alike ;-)
[blockquote]Tamás Fábián said:
Hello,
we're still making minor changes to the protocol, we'll going to release a full description in january.
There is a provisionary descriptoin here:
https://social.sbrick.com/groups/topic/view/group_id/2/topic_id/4/post_id/10
I'll just C+P it here:
Dear testers and hackers,
I hereby describe how you can "talk" to the SBrick. With the help of this description you'll be able to build your own application that can control an SBrick.
Since SBrick works over Bluetooth Low Energy / Bluetooth 4.0 or BLE for short, you will need a device that speaks BLE.
For the PC or an USB-capable embedded hardware we recommend using BlueGiga's BLED112 BLE dongle. Bluegiga is the same manufacturer who supplies the BLE modules for us, so compatiblitiy is guaranteed with them. Also, this is the same dongle we will potentially use as the solution for our users with smartphones without BLE but with OTG capability.
First, you need to learn a few basics about the BLE protocol in general. You need to understand at least the following:
Given all these basics, the SBrick is a BLE peripheral. It advertises itself shortly after it's turned on. In the first 30 seconds after reset or disconnect, it transmits an advertisement packet in each 20ms or 50 times a secons to facilitate reconnection.
After the first 30 seconds, it sends advertisement packets about twice each second to conserve battery and bandwidth.
The advertisement data contains the device name and the TX power (0dB).
The SBrick is a connectable, general discoverable device, it means you can connect to it with a central device.
A central device usually reads the services and characteristics immediately after a connection has been established.
This is needed to determine the handles for each characteristic, because you can use the handles to read / write data from / to the device.
The BLE characteristics (which act like API endpoints) are identified with UUIDs. Widely used profiles use short, two-byte IDs.
Since SBrick is a rather new device without official profile, we use full UUIDS for the remote control service and characteristics. Full UUIDS are used for the OTA service, wich can be used to upload new firmware to the brick. This is compatible with BlueGiga's OTA service and therefore the BleGUI application.
For now, I would strongly discourage anyone trying to upload a custom firmware, since this can put the brick in a state where the OTA stops working, so you can easily brick your brick ;)
Certain BLE APIs can list the characteristics right away without having to deal with services, but others need service UUIDS first to give you a list of characteristics.
The UUID of the remote control service is 4dc591b0-857c-41de-b5f1-15abda665b0c
What you need for remote control is the remote control characteristic, which is 2b8cbcc-0e25-4bda-8790-a15f53e6010f
This is where you have to send remote control commands. We recommend using "write without response", or "write command" mode to send data. In this mode the peripheral must not answer, so you need less bandwidth and you'll get smaller latency.
A command has an identifier, or a "command code" and some paramters.
A remote control command can be the following:
DRIVE, command ID 01
The drive command sets a channel's drive level from 0 to 255. It currently has three paramteres:
Where COMMAND ID is currently 1, channel is a channel number from 0 to 4, channel #4 being the identify led, and can only be turned on or off (off means it's constantly on, on means it's blinking ;) so it's not the LED that's being turned on or off, but the identification functionality).
So if you issue the folloing bytes (each byte is two digit, hexadecimal, sent from the left to the rigth):
01 00 00 255
It will turn on the first channel (the "channel zero"), and give it full thrust.
01 04 00 01
Will turn on the identification function: the identify LED will blink
Sending a 00 drive to any channel will Hi-Z the motor drived MOSFETs, so the motors will be cut off power, and slowly decelerate to a halt.
This mode is called "freewheeling". If you manually try to turn the motor's axis, you wil feel little resistance.
BREAK, command 00
The break command works like this:
So issuing a
00 01
Will "engage break" on channel 01, (that's the second channel, 00 being the first ;) ).
Do not issue a break command on the identification LED.
The break commands connects both the motor leads to the power supply, short circuiting the motor. Since DC motors act like generators when they are forced to turn, a current will flow in the motor's coils wich will try to stop the motor, effectively breaking it. The higher the RPM, the greater the breaking force.
Use this function to quickly stop a motor. Use "drive zero" to slowly stop a motor.
HOW TO TEST THIS?
If you have an Android smartphone, use Nordic Semiconductor's nRF Master Controller application to connect to the brick through BLE.
Look for "unknown service" with UUID 4dc59...
Open up the service.
Look for "unknown characteristic" with UUID 02b8cb...
Tap on the upwards-pointing arrow symbol next to the chracteristic, to open up a dialog box where you can enter the command byte by byte.
There are many general-purpose BLE application for all smartphone platforms you can try with SBrick.
Tell us about your experience with testing the protocol, we are ready to help you if you're stuck.
[/blockquote]
Thanks for that Tamas. I now know that there is nothing wrong with the Sbrick itself as I can control it through the nRF Master Control Panel on my Samsung Galaxy S3 running Android 4.3.
This means that it is only the Android app that totally doesn't work as I cant even discover a brick using it!
Hello,
we're still making minor changes to the protocol, we'll going to release a full description in january.
There is a provisionary descriptoin here:
https://social.sbrick.com/groups/topic/view/group_id/2/topic_id/4/post_id/10
I'll just C+P it here:
Dear testers and hackers,
I hereby describe how you can "talk" to the SBrick. With the help of this description you'll be able to build your own application that can control an SBrick.
Since SBrick works over Bluetooth Low Energy / Bluetooth 4.0 or BLE for short, you will need a device that speaks BLE.
For the PC or an USB-capable embedded hardware we recommend using BlueGiga's BLED112 BLE dongle. Bluegiga is the same manufacturer who supplies the BLE modules for us, so compatiblitiy is guaranteed with them. Also, this is the same dongle we will potentially use as the solution for our users with smartphones without BLE but with OTG capability.
First, you need to learn a few basics about the BLE protocol in general. You need to understand at least the following:
Given all these basics, the SBrick is a BLE peripheral. It advertises itself shortly after it's turned on. In the first 30 seconds after reset or disconnect, it transmits an advertisement packet in each 20ms or 50 times a secons to facilitate reconnection.
After the first 30 seconds, it sends advertisement packets about twice each second to conserve battery and bandwidth.
The advertisement data contains the device name and the TX power (0dB).
The SBrick is a connectable, general discoverable device, it means you can connect to it with a central device.
A central device usually reads the services and characteristics immediately after a connection has been established.
This is needed to determine the handles for each characteristic, because you can use the handles to read / write data from / to the device.
The BLE characteristics (which act like API endpoints) are identified with UUIDs. Widely used profiles use short, two-byte IDs.
Since SBrick is a rather new device without official profile, we use full UUIDS for the remote control service and characteristics. Full UUIDS are used for the OTA service, wich can be used to upload new firmware to the brick. This is compatible with BlueGiga's OTA service and therefore the BleGUI application.
For now, I would strongly discourage anyone trying to upload a custom firmware, since this can put the brick in a state where the OTA stops working, so you can easily brick your brick ;)
Certain BLE APIs can list the characteristics right away without having to deal with services, but others need service UUIDS first to give you a list of characteristics.
The UUID of the remote control service is 4dc591b0-857c-41de-b5f1-15abda665b0c
What you need for remote control is the remote control characteristic, which is 2b8cbcc-0e25-4bda-8790-a15f53e6010f
This is where you have to send remote control commands. We recommend using "write without response", or "write command" mode to send data. In this mode the peripheral must not answer, so you need less bandwidth and you'll get smaller latency.
A command has an identifier, or a "command code" and some paramters.
A remote control command can be the following:
DRIVE, command ID 01
The drive command sets a channel's drive level from 0 to 255. It currently has three paramteres:
Where COMMAND ID is currently 1, channel is a channel number from 0 to 4, channel #4 being the identify led, and can only be turned on or off (off means it's constantly on, on means it's blinking ;) so it's not the LED that's being turned on or off, but the identification functionality).
So if you issue the folloing bytes (each byte is two digit, hexadecimal, sent from the left to the rigth):
01 00 00 255
It will turn on the first channel (the "channel zero"), and give it full thrust.
01 04 00 01
Will turn on the identification function: the identify LED will blink
Sending a 00 drive to any channel will Hi-Z the motor drived MOSFETs, so the motors will be cut off power, and slowly decelerate to a halt.
This mode is called "freewheeling". If you manually try to turn the motor's axis, you wil feel little resistance.
BREAK, command 00
The break command works like this:
So issuing a
00 01
Will "engage break" on channel 01, (that's the second channel, 00 being the first ;) ).
Do not issue a break command on the identification LED.
The break commands connects both the motor leads to the power supply, short circuiting the motor. Since DC motors act like generators when they are forced to turn, a current will flow in the motor's coils wich will try to stop the motor, effectively breaking it. The higher the RPM, the greater the breaking force.
Use this function to quickly stop a motor. Use "drive zero" to slowly stop a motor.
HOW TO TEST THIS?
If you have an Android smartphone, use Nordic Semiconductor's nRF Master Controller application to connect to the brick through BLE.
Look for "unknown service" with UUID 4dc59...
Open up the service.
Look for "unknown characteristic" with UUID 02b8cb...
Tap on the upwards-pointing arrow symbol next to the chracteristic, to open up a dialog box where you can enter the command byte by byte.
There are many general-purpose BLE application for all smartphone platforms you can try with SBrick.
Tell us about your experience with testing the protocol, we are ready to help you if you're stuck.