Forums » Suggestions

Back To Topics

Release of the protocoll

  • February 25, 2015 9:34 PM CET

    looks great! I was trying to access the SBrick with BLE and universal app. I manage to get access to the basic data (version, etc) but writing data do not work at all. I must do something wrong somewhere. Do you plan to share the code of the app at some point?

    thanks

    • 6 posts
    January 12, 2015 3:45 PM CET

    Yes! Currently i try to make a joystick.

     

    UPDATE: 2015/1/13

    I finsihed joystick control UI.


    This post was edited by Likol Lee at January 13, 2015 2:05 PM CET
    • 171 posts
    January 12, 2015 2:16 PM CET

    Great work Likol! :)

    Does it run smooth?

    • 6 posts
    January 12, 2015 6:46 AM CET

    Thanks for release of protocoll

    I wrote a windows phone app for my personal use.


    This post was edited by Likol Lee at January 12, 2015 6:48 AM CET
    • 26 posts
    January 10, 2015 10:52 AM CET

    But I still can't find the update file to update the sBrick with the Bluegiga BLED112.

    • 270 posts
    January 9, 2015 5:28 PM CET

    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)


    This post was edited by Lénárd Pásztor at January 9, 2015 5:28 PM CET
  • January 9, 2015 5:27 PM CET

    nice info, thank you

    • 26 posts
    January 9, 2015 3:12 PM CET

    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


    This post was edited by Technicmaster0 . at January 9, 2015 5:15 PM CET
    • 26 posts
    January 7, 2015 10:04 PM CET

    Great. But where can I get the update file?

    • 171 posts
    January 7, 2015 9:53 PM CET

    There's already a solution. Bluegiga's own BLEGUI program's DFU function can be used to do OTA. We use a solution that is compatible with Bluegiga's solution.

    • 26 posts
    January 7, 2015 2:16 PM CET

    Do you have an idea when/if there will be an "update via air" solution for the computer? I don't have a smartphone but the BLE dongle is on it's way.

    • 171 posts
    January 7, 2015 10:47 AM CET

    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.

    • 57 posts
    January 6, 2015 4:33 PM CET

    [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

     


    This post was edited by Fernando Correia at January 6, 2015 4:35 PM CET
    • 2 posts
    January 6, 2015 2:10 PM CET

    Thanks for answers. I do temporary fix to 254-GO and look foward to next official iOS app :-)

    • 171 posts
    January 6, 2015 10:11 AM CET

    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.

    • 87 posts
    January 6, 2015 8:45 AM CET

    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.

    • 2 posts
    January 6, 2015 2:20 AM CET

    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 :-)

    • 6 posts
    January 5, 2015 7:08 PM CET

    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];
    }


    This post was edited by Likol Lee at January 5, 2015 8:04 PM CET
    • 26 posts
    January 2, 2015 11:04 PM CET

    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).

    • 10 posts
    January 2, 2015 10:11 PM CET

    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.

    • 26 posts
    December 30, 2014 12:33 AM CET

    I will try to write a remote in c# for windows and maybe other systems.

    • 10 posts
    December 30, 2014 12:19 AM CET

    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 ;-)

    • 26 posts
    December 29, 2014 12:23 PM CET

    Seems like it's finally worth to buy a BLE dongle.

    • 24 posts
    December 29, 2014 12:15 PM CET

    [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:



      • Central

      • Peripheral

      • Advertisement

      • Profile

      • Service

      • Characteristic

      • Handle

      • Reading and writing characteristics, write and write without reponse mode


    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!

     

    • 171 posts
    December 29, 2014 8:19 AM CET

    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:



      • Central

      • Peripheral

      • Advertisement

      • Profile

      • Service

      • Characteristic

      • Handle

      • Reading and writing characteristics, write and write without reponse mode


    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.